5 ms·

Hard disagree on this, they certainly shouldn't be your only defence but I think for the vast majority of sites they are essential. Most site on the internet a

Hard disagree on this, they certainly shouldn't be your only defence but I think for the vast majority of sites they are essential. Most site on the internet are either run by a tiny team with no dedicated security expert or no tech team at all (someone asked a friend/freelancer to put up a Wordpress site). They aren’t applying security patches and subscribing to the developer mailing lists. A WAF service (like CloudFlare) ensures that older, unpatched, infrastructure is protected. Yes, they should be patching their deployment, but try asking a small business to pay for their web guy to spend a few fours a month ensuring everything is secure. Not going to happen. From my perspective as someone with a good understanding of web security. I run a WAF service on my sites so that if there is a zero day on part of my stack We are protected immediately before we have time to patch the component, which I will do. That is invaluable to me and my business. Finally developers do make mistakes and accidentally introduce vulnerabilities. A WAF helps to ensure against that, although you should still be auditing your code.

latch 5y ago
> A WAF service (like CloudFlare) ensures that older, unpatched, infrastructure is protected It ensures that they're protected against a trivial and fairly outdated set of threats. You might say that's better than nothing, but questionable protection leading to a sense of security is more dangerous than having nothing and knowing it (also, false positives). > We are protected immediately Look at the recent log4j vulnerabilities. Hosted WAFs didn't "immediately" address the issue (though they were fairly quick). However, to the best of my knowledge they were unable to fully mitigate the threat. For example, if you look at CloudFlare's wording on rule 2c5413e155db4365befe0df160ba67d7: > In addition to the above rules we have also released a fourth rule that will protect against a much wider range of attacks at the cost of a higher false positive rate. For that reason we have made it available but not set it to BLOCK by default It's clear that, by default, their updated rules didn't fully mitigate the issue. Also, it IS NOT clear, whether the extra rule did fully mitigate the issue. Fundamentally, having a WAF in the face of log4j did nothing for you. You still have to patch everything, you still had to try and figure out if you'd been compromised, and you still had to update/alert your clients/customers.
- theptip 5y ago
  > It ensures that they're protected against a trivial and fairly outdated set of threats Isn’t a WAF getting access to pre-public intelligence and updating their rules accordingly? I was under the impression that major vendors like Cloudflare and Google were able to block zero-days before the public announcements.
- prdonahue 5y ago
  > It ensures that they're protected against a trivial and fairly outdated set of threats. You might say that's better than nothing, but questionable protection leading to a sense of security is more dangerous than having nothing and knowing it (also, false positives). Rules for remotely exploitable vulnerabilities like log4j are typically crafted within hours of a CVE being released, and deployed as quickly as possible to minimize false positives. I'm not sure I'd consider such threats "outdated". > However, to the best of my knowledge they were unable to fully mitigate the threat ... Fundamentally, having a WAF in the face of log4j did nothing for you. If you're only able to mitigate 9X% of a rapidly evolving zero-day and not 100%, should you not use a WAF at all? Security is about reducing risk, and raising the cost for attackers. Cloudflare tracked and responded to active exploitation attempts[1] in the wild with updated rules, while imploring customers to patch, e.g., from our second CVE (CVE-2021-45046) post[2] discussing additional rules we deployed: "This vulnerability is actively being exploited and anyone using Log4J should update to version 2.16.0 as soon as possible, even if you have previously updated to 2.15.0. The latest version can be found on the Log4J download page." > You still have to patch everything, you still had to try and figure out if you'd been compromised, and you still had to update/alert your clients/customers. Yes, of course. Nobody is arguing otherwise. Such is the nature of these massive vulnerabilities that pop up every few years. [1] - https://blog.cloudflare.com/exploitation-of-cve-2021-44228-before-public-disclosure-and-evolution-of-waf-evasion-patterns/ https://blog.cloudflare.com/exploitation-of-cve-2021-44228-b... [2] - https://blog.cloudflare.com/protection-against-cve-2021-45046-the-additional-log4j-rce-vulnerability/ https://blog.cloudflare.com/protection-against-cve-2021-4504...

latch 5y ago

> A WAF service (like CloudFlare) ensures that older, unpatched, infrastructure is protected It ensures that they're protected against a trivial and fairly outdated set of threats. You might say that's better than nothing, but questionable protection leading to a sense of security is more dangerous than having nothing and knowing it (also, false positives). > We are protected immediately Look at the recent log4j vulnerabilities. Hosted WAFs didn't "immediately" address the issue (though they were fairly quick). However, to the best of my knowledge they were unable to fully mitigate the threat. For example, if you look at CloudFlare's wording on rule 2c5413e155db4365befe0df160ba67d7: > In addition to the above rules we have also released a fourth rule that will protect against a much wider range of attacks at the cost of a higher false positive rate. For that reason we have made it available but not set it to BLOCK by default It's clear that, by default, their updated rules didn't fully mitigate the issue. Also, it IS NOT clear, whether the extra rule did fully mitigate the issue. Fundamentally, having a WAF in the face of log4j did nothing for you. You still have to patch everything, you still had to try and figure out if you'd been compromised, and you still had to update/alert your clients/customers.

theptip 5y ago
> It ensures that they're protected against a trivial and fairly outdated set of threats Isn’t a WAF getting access to pre-public intelligence and updating their rules accordingly? I was under the impression that major vendors like Cloudflare and Google were able to block zero-days before the public announcements.
prdonahue 5y ago
> It ensures that they're protected against a trivial and fairly outdated set of threats. You might say that's better than nothing, but questionable protection leading to a sense of security is more dangerous than having nothing and knowing it (also, false positives). Rules for remotely exploitable vulnerabilities like log4j are typically crafted within hours of a CVE being released, and deployed as quickly as possible to minimize false positives. I'm not sure I'd consider such threats "outdated". > However, to the best of my knowledge they were unable to fully mitigate the threat ... Fundamentally, having a WAF in the face of log4j did nothing for you. If you're only able to mitigate 9X% of a rapidly evolving zero-day and not 100%, should you not use a WAF at all? Security is about reducing risk, and raising the cost for attackers. Cloudflare tracked and responded to active exploitation attempts[1] in the wild with updated rules, while imploring customers to patch, e.g., from our second CVE (CVE-2021-45046) post[2] discussing additional rules we deployed: "This vulnerability is actively being exploited and anyone using Log4J should update to version 2.16.0 as soon as possible, even if you have previously updated to 2.15.0. The latest version can be found on the Log4J download page." > You still have to patch everything, you still had to try and figure out if you'd been compromised, and you still had to update/alert your clients/customers. Yes, of course. Nobody is arguing otherwise. Such is the nature of these massive vulnerabilities that pop up every few years. [1] - https://blog.cloudflare.com/exploitation-of-cve-2021-44228-before-public-disclosure-and-evolution-of-waf-evasion-patterns/ https://blog.cloudflare.com/exploitation-of-cve-2021-44228-b... [2] - https://blog.cloudflare.com/protection-against-cve-2021-45046-the-additional-log4j-rce-vulnerability/ https://blog.cloudflare.com/protection-against-cve-2021-4504...