Cristian Morales

Cristian Morales

SysAdmin & DevOps Engineer

Protect your websites and applications with Google Cloud Armor WAF

12 September 2022
2 minutes

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 We look forward to hearing from you!