Thanks for your comment.

The idea of the post was to use a simple example to make it easier to follow. In this case, the default rules from mod_security had signatures to stop the generic XSS used in the example and it was not necessary to create a custom signature. However with this kind of technology, like with an IPS, you always should try to customise the rules for your application.

Regarding the concept of virtual patching, my interpretation of virtual patching is to apply a temporary fix to a vulnerability when there is no official patch available or it is not possible to apply it quickly. For example a signature in an IPS or in a WAF that blocks the attack that can exploit the vulnerability. Of course, if you are able to and have the time to create more accurate signatures to block everything that is not in a white list, it’s going to be more secure and reliable.

Angel

That being said, I would like to point out that one thing is adding additional layers of security, like a web application firewall using the default rules. This makes the life of the attacker more difficult because they have to spend time to bypass the firewall before they even know there is a vulnerability behind. But it must be noted this method is blacklist based: mod_security is trying to identify potential attacks to block them. There are obfuscation techniques that could potentially bypass this (although the effort is much greater).

My understanding of the concept “virtual patching”, at least performed correctly, would be a custom mod_security white list rule that would only allow the data expected by the vulnerable parameter. For example, if you have a field that is supposed to take a number you could create a rule that blocks everything that is not a number. This approach is much better than just using the mod_security core rules without customisation because a bypass is significantly harder and most likely impossible to bypass. I saw no custom rule in the video, it looked like you just enabled the core rules.

So, the distinction I would like to make is that what you show in the video is an additional layer of security which follows the principle of “defence in depth”, making a potential attacker waste time in the web application firewall and hopefully discourage them from attacking your site but it is definitely not a virtual patch for a known vulnerability. You can borrow some time with the default rules but a virtual patch (i.e. white list web application firewall rule) is a more robust approach for this.

I believe you knew all this but it is important to clarify this distinction.

Other than that nice post, keep them coming!

Thanks for the comment!

I should have been clearer in the blog but I meant that utilising something like mod security “all the time” in your infrastructure can help prevent common vulnerabilities being exploited. This blog was just a quick post to show how using something like mod security can also allow you to implement virtual patches as well as providing on going protection.

I completely agree with what you said, adding either the patch or mod security as a solution would require a large amount of testing.

Thanks,

Angel