Forum Discussion
Nikoolayy1
MVP
MVPHas anyone used F5 rules for AWS WAF?
Hello to All,
Has anyone worked with this product and can provide an overview of it and if it is worth it? From what I read and see it is limited and F5 have not added ip intelligence feed to it like Imperva has done but I could be wrong.
After tests here is my review of the AWS WAF with native or F5 AWS WAF managed rules:
The AWS WAF as a whole is not made well to deal with false positives and it can't replace F5 for critical sites. In the AWS WAF GUI overview logs for AWS waf you just see the request without any highlights about what part causes the issue and the only workaround is you to set the action to 'count'' for the subrule group t hat makes a security hole or create a custom allow rule with higher priority but as you don't know from the logs exactly what part of the request causes the false positive and you can't directly view the F5 AWS WAF rules or the Native AWS WAF rules you are making the custom allow rule hoping you are not making a security hole. Also the limit of 1500 rules as of now makes it really hard to use with the F5 AWS rule groups as you can add just one of them.For example you can't attach the F5 rules for bot protection and the ones for for OPSWAT top ten under the same AWS object, as a bad workaround you can attach the F5 Bot protection rules under Cloudfront and the F5 OPSWAT rules under AWS Aplication LB or API gateway.
The AWS WAF default managed rules with burp suite professional web scanner and they are good enough for basic OPSWAT top 10 protection, so for not important sites that you are not going to anyway buy F5 to protect ok then it is an option as it is similar to the on premise modsecurity module for NGINX/apache that you can use with free or payed rules like comodo or OWASP ModSecurity Core Rule Set. Who knows maybe it is even based on this on the background as the AWS Network Firewall for IPS uses Suricata so I am really thinking that modsecurity could be the AWS WAF implementation :)
The AWS Bot protection managed rules can be hacked by just using User-Agent header value like the one for Chrome etc, so they just check the header values etc., so this is not protection at all in our current day and age.
- Nikoolayy1
After tests here is my review of the AWS WAF with native or F5 AWS WAF managed rules:
The AWS WAF as a whole is not made well to deal with false positives and it can't replace F5 for critical sites. In the AWS WAF GUI overview logs for AWS waf you just see the request without any highlights about what part causes the issue and the only workaround is you to set the action to 'count'' for the subrule group t hat makes a security hole or create a custom allow rule with higher priority but as you don't know from the logs exactly what part of the request causes the false positive and you can't directly view the F5 AWS WAF rules or the Native AWS WAF rules you are making the custom allow rule hoping you are not making a security hole. Also the limit of 1500 rules as of now makes it really hard to use with the F5 AWS rule groups as you can add just one of them.For example you can't attach the F5 rules for bot protection and the ones for for OPSWAT top ten under the same AWS object, as a bad workaround you can attach the F5 Bot protection rules under Cloudfront and the F5 OPSWAT rules under AWS Aplication LB or API gateway.
The AWS WAF default managed rules with burp suite professional web scanner and they are good enough for basic OPSWAT top 10 protection, so for not important sites that you are not going to anyway buy F5 to protect ok then it is an option as it is similar to the on premise modsecurity module for NGINX/apache that you can use with free or payed rules like comodo or OWASP ModSecurity Core Rule Set. Who knows maybe it is even based on this on the background as the AWS Network Firewall for IPS uses Suricata so I am really thinking that modsecurity could be the AWS WAF implementation :)
The AWS Bot protection managed rules can be hacked by just using User-Agent header value like the one for Chrome etc, so they just check the header values etc., so this is not protection at all in our current day and age.
- Daniel_Wolf
Guessing, but those look like static rule sets.
- Web exploits OWASP Rules < could be similar to the OWASP Core Rule Set (CRS)
- Common Vulnerabilities & Exposures (CVE) Rules < Static Attack Signatures
- Bot Protection Rules < static bot signatures, no client-side JS injection or fingerprinting
- Nikoolayy1
If it is like the CRS or the Comodo rules that can be used with modsecurity (a free very basic waf solution for apache, nginx or windows IIS) then it seems only good for basic sites that don't need a lot of security and just OPSWAT 10 basic protections are needed. I will play and test it and then I will share my experience. Still from what I read the AWS WAF can be connected to external feed lists but as it seems the ip intelligence is not available I will see if I can use the misp or minemeld to feed it for better security.
- Nikoolayy1
After any review for critical web sites I think it is much better to use F5 silverline as it is based in AWS and it can be integrated with AWS cloudfront as the routing between the AWS cloudfront and the F5 silverline and the siverline and the real origin servers happens internally in the AWS high speeed network.
- Nikoolayy1
I also see some people complaint that the support model of the rules is not clear but probably it is F5 that need to support this.
