# Getting Started on Cloud Armor, Protect and Score Protection Levels **Published by:** [Vamsi Ramakrishnan](https://paragraph.com/@mrvemzi/) **Published on:** 2022-07-22 **URL:** https://paragraph.com/@mrvemzi/getting-started-on-cloud-armor-protect-and-score-protection-levels ## Content 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 withA good Starting PointFilter Traffic from unwanted GeographiesFilter Traffic to unwanted paths in your APIFilter Traffic with unauthorized methodsOWASP Top 10SSL Policy to disallow TLS < target version Cloud Armor Basics For a detailed understanding of Limits , check this pageTargets Per Policy ( Which are the backends that need to be protected by this policy)Rules Per Policy ( No Limit per policy, 200 rules per project) ( A collection of Allow and Deny rules )Statements Per Rule ( 5 statements limit ) ( What are the conditions that are evaluated for allow / deny ) HeuristicsAllow rules should take lower priorityAllow rules should be as specific as possibleDeny rules should be as broad as possibleStart 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 pageRule 1Deny ( 403) Allow traffic from a specific region Only , also disallow sensitive paths or specific headersorigin.region_code != '<ONLY REGION YOU WANT TRAFFIC FROM>' || request.path.contains('/<YOUR PATH>') || request.headers.contains('<DISALLOWED HEADERS') Rule 2Deny ( 403) — OWASPevaluatePreconfiguredExpr('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) — OWASPevaluatePreconfiguredExpr('sessionfixation-stable') && evaluatePreconfiguredExpr('protocolattack-stable') && evaluatePreconfiguredExpr('scannerdetection-stable') Inside Cloud Armor Rule ConfigHow do I test the effectiveness of these rules Some of the popular and easy WAF testing frameworkshttps://github.com/wallarm/gotestwaf Wallarmhttps://github.com/signalsciences/waf-testing-framework SignalScihttps://github.com/fastly/ftw Fastlyhttps://github.com/f5devcentral/f5-waf-tester F5 I decided to choose the one by Wallarmdocker 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. ## Publication Information - [Vamsi Ramakrishnan](https://paragraph.com/@mrvemzi/): Publication homepage - [All Posts](https://paragraph.com/@mrvemzi/): More posts from this publication - [RSS Feed](https://api.paragraph.com/blogs/rss/@mrvemzi): Subscribe to updates - [Twitter](https://twitter.com/mrvemzi): Follow on Twitter