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

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.