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

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

6. Targets Per Policy ( Which are the backends that need to be protected by this policy)

7. Rules Per Policy ( No Limit per policy, 200 rules per project) ( A collection of Allow and Deny rules )

8. Statements Per Rule ( 5 statements limit ) ( What are the conditions that are evaluated for allow / deny ) Heuristics

9. Allow rules should take lower priority

10. Allow rules should be as specific as possible

11. Deny rules should be as broad as possible

12. 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

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') 

Deny ( 403) — OWASP

evaluatePreconfiguredExpr('xss-stable') &&evaluatePreconfiguredExpr('protocolattack-stable') && evaluatePreconfiguredExpr('sqli-stable') && evaluatePreconfiguredExpr('lfi-stable') && evaluatePreconfiguredExpr('rfi-stable')

Deny (403) — OWASP

evaluatePreconfiguredExpr('sessionfixation-stable') && evaluatePreconfiguredExpr('protocolattack-stable') && evaluatePreconfiguredExpr('scannerdetection-stable')

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

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.

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

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

6. Targets Per Policy ( Which are the backends that need to be protected by this policy)

7. Rules Per Policy ( No Limit per policy, 200 rules per project) ( A collection of Allow and Deny rules )

8. Statements Per Rule ( 5 statements limit ) ( What are the conditions that are evaluated for allow / deny ) Heuristics

9. Allow rules should take lower priority

10. Allow rules should be as specific as possible

11. Deny rules should be as broad as possible

12. 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

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') 

Deny ( 403) — OWASP

evaluatePreconfiguredExpr('xss-stable') &&evaluatePreconfiguredExpr('protocolattack-stable') && evaluatePreconfiguredExpr('sqli-stable') && evaluatePreconfiguredExpr('lfi-stable') && evaluatePreconfiguredExpr('rfi-stable')

Deny (403) — OWASP

evaluatePreconfiguredExpr('sessionfixation-stable') && evaluatePreconfiguredExpr('protocolattack-stable') && evaluatePreconfiguredExpr('scannerdetection-stable')

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

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.