Web application security is crucial for protecting organisational and client data. In 2021, cyber attacks caused approximately 5 trillion GBP in damage, which is expected to increase by 15% annually over the next five 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 simply and efficiently. 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 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 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 can avoid false positives and gradually add 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 several signatures, so some of these 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 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!
Cookies configuration