Web application security is crucial for the protection of organizational and client data. In 2021, cyber attacks caused approximately 6 trillion USD in damage, which is expected to increase by 15% annually over the next 5 years. Thus, it is essential to use all possible tools to reduce the risk of these cyber attacks.
Google Cloud Armor is a web-application level “firewall” (WAF) capable of protecting companies from a wide variety of cyberattacks in a simple and efficient way. In order to use this tool, we will have to use Google Cloud Platform’s load balancers since that is where Cloud Armor can be enabled on the backend services.
Once the load balancer has been configured and a security policy has been activated for a backend service, it is time to adjust which WAF rules should be applied. There is a wide variety available depending on our needs. The following table shows a list of some of these preconfigured rules grouped by categories:
| Name of the rule | Name of the ModSecurity rule |
| sqli-stable | SQL injection |
| xss-stable | Cross-site scripting |
| lfi-stable | Local file inclusion |
| rfi-stable | Remote file inclusion |
| rce-stable | Remote code execution |
| scannerdetection-stable | Scanner detection |
Each of these rules contains dozens of signatures that are compiled from ModSecurity v3.0.2. Google Cloud Platform (GCP) provides a controlled way to debug these rules with real traffic. The best part is that users are not affected, since we can select them in “preview only” mode. This means that every time one of these rules is triggered, it will simply be logged and let the traffic through. Obviously, by activating preview mode, we will not be securing our platform in any way, Still, in this way, we are able to avoid false positives and gradually add each of these rules.
In addition to the preview-only mode, GCP uses verbose logging capabilities. What does this mean? For each request blocked by these rules, we will see detailed information in the log on which signature and what part of the request has caused the block. As previously mentioned, each of the rules listed in the previous table contains a number of signatures, so some of these signatures may cause false positives and should thus be disabled.
With this protection we can avoid the following attacks:
- SQL injection
- Cross-site scripting
- Local file inclusion
- Remote file inclusion
- Remote code execution
- Method enforcement (public preview)
- Scanner detection
- Protocol attack
- PHP injection attack
- Session fixation attack
Do you want to know more about how to better secure your websites and applications? The Making Science Cloud team can help. Get in touch at info@makingscience.com. We look forward to hearing from you!
Cookie configuration