Getting Started on Cloud Armor, Protect and Score Protection Levels
If your application is hosted on Google Cloud serving internet traffic, consider enabling Cloud Armor. Which provides an extremely simple and easy to use way of protecting your applications against a variety of attack signatures.
While WAF rules and tuning them is beyond the scope of this post in itself If you do not know what rules you need to start with
A good Starting Point
1. Filter Traffic from unwanted Geographies
2. Filter Traffic to unwanted paths in your API
3. Filter Traffic with unauthorized methods
4. OWASP Top 10
5. SSL Policy to disallow TLS < target version
Cloud Armor Basics
For a detailed understanding of Limits , check this page
1. Targets Per Policy
( Which are the backends that need to be protected by this policy)2. Rules Per Policy ( No Limit per policy, 200 rules per project)
( A collection of Allow and Deny rules )3. Statements Per Rule ( 5 statements limit )
( What are the conditions that are evaluated for allow / deny )
Heuristics
1. Allow rules should take lower priority
2. Allow rules should be as specific as possible
3. Deny rules should be as broad as possible
4. Start with UAT , and enable it in Preview
Rule Translation
How would all this translate as Rules in Cloud Armor. This is by no means the most comprehensive but is a good starting point. For the universal set of all rules check this page
# Rule 1
Deny ( 403)
Allow traffic from a specific region Only , also disallow sensitive paths or specific headers
origin.region_code != '<ONLY REGION YOU WANT TRAFFIC FROM>' || request.path.contains('/<YOUR PATH>') ||
request.headers.contains('<DISALLOWED HEADERS')
#Rule 2
Deny ( 403) — OWASP
evaluatePreconfiguredExpr('xss-stable') &&evaluatePreconfiguredExpr('protocolattack-stable') && evaluatePreconfiguredExpr('sqli-stable') && evaluatePreconfiguredExpr('lfi-stable') && evaluatePreconfiguredExpr('rfi-stable')
# Rule 3 ( Extension of Rule 2 due to 5 Statement limit per rule)
Deny (403) — OWASP
evaluatePreconfiguredExpr('sessionfixation-stable') && evaluatePreconfiguredExpr('protocolattack-stable') && evaluatePreconfiguredExpr('scannerdetection-stable')
Inside Cloud Armor Rule Config
How do I test the effectiveness of these rules
Some of the popular and easy WAF testing frameworks
1. https://github.com/wallarm/gotestwaf Wallarm
2. https://github.com/signalsciences/waf-testing-framework SignalSci
3. https://github.com/fastly/ftw Fastly
4. https://github.com/f5devcentral/f5-waf-tester F5
I decided to choose the one by Wallarm
docker pull wallarm/gotestwaf
docker run -v ${PWD}/reports:/app/reports --network="host" wallarm/gotestwaf --url=<Your WAF Endpoint>
Generates a report in this format. The Hosted backend is a Hello World Application
serving on Flask so Application Secutity
Next Steps :
The report generates a folder /reports/xxx.pdf , which on examination reveals that there are a bunch of false positives which got flagged and blocked while it shouldn’t have been . Which is a good place to begin
Tuning the False Positives
Correlate Cloud Armor Logs to WAF Report
Select “Logs” >> “Policy Logs”
Correlate WAF Logs to Test Execution Times
Tune the ModSec paranoia Levels
Each preconfigured rule has a sensitivity level that corresponds to a ModSecurity paranoia level. A lower sensitivity level indicates a higher confidence signature, which is less likely to generate a false positive. A higher sensitivity level increases security, but also increases the risk of generating a false positive.
Repeat tests.