The frequency of DDoS attacks has seen a surge over the past few years, both globally, and even more so in the EMEA region, according to a report released by cyber security firm Radware. At the end of 2022, the frequency of DDoS attacks the company mitigated rose 3.5 times (from 8.4 per day at the end of 2021, to 29.3). In EMEA, organisations averaged 45 attacks per day, the report stated. That’s four times as much as just a year earlier (11.3 attacks per day). Security and protection against network attacks are becoming one of the greatest challenges for any organisation. In this article, we present Google Cloud Armor. You will find out what it is, what it protects against and how it can be integrated with other services. We will also present the best practices based for its implementation. Let’s begin.
What is Google Cloud Armor?
Google Cloud Armor is one of the services available within the Google Cloud platform that protects projects deployed there from attacks such as DDoS (distributed denial-of-service), XSS (cross-site scripting), and SQLi (SQL injection). Some of the security features provided by Google Cloud Armor work automatically, but not all of them.
Importantly, it is worthwhile to use Google Cloud Armor’s protection even when Google Cloud is not our sole cloud solution. The protection will also work in the case of a hybrid or multi-cloud model. In such architecture, the back-end for the load balancer must be of the Internet NEG (network endpoints groups) type.
The battlefield, or Layer 7
If you are familiar with the ISO/OSI reference model that standardizes network communication between different devices, you know that the seventh layer, the highest one, corresponds to the application level. It is at this layer that the “Adaptive Protection” feature operates. Its task is to block an attack before it reaches the load balancer’s backend. Each security rule is divided into a set of filtering rules based on the incoming request’s IP address, IP address range, region code, or request headers. When creating custom rules, parameters from layers L3-L7 are used.
Defining rules
Within Google Cloud Armor, it is possible to define rules with priorities. You can also use pre-configured WAF (web application firewall) rules that contain dozens of signatures compiled from industry standards available in open source. Each signature corresponds to a rule for detecting attacks within a rule set. WAF rules focus on limiting the top 10 threats related to vulnerabilities in OWASP web application security.
Using rules provides great convenience. They allow Google Cloud Armor to evaluate dozens of different traffic signatures, referring to user-defined rules instead of requiring manual definition for each signature.
How does it work?
Google Cloud Armor:
- Provides continuous protection against network or protocol-based DDoS attacks.
- Protects applications and services behind the load balancer.
- Is capable of detecting and mitigating network attacks by allowing only legitimate requests through the proxy servers.
- When using custom rules, parameters from layers L3-L7 can be used, and Adaptive Protection can be enabled for each of these rules, which detects and blocks Layer 7 DDoS attacks.
The diagram below illustrates the location of global external Load Balancer modules, Google network, and Google data centres.
Google Cloud Armor in practice
This is how you can control access to your applications and services.
Enabling access for users from specific IP addresses using allowlists
A typical situation is represented by the following diagram. In this case, only members of the organisation, who have IP addresses or IP blocks assigned by the organisation and listed in the allowlist, have access to services behind the load balancer. This allows control over access to both external and classic Application Load Balancers.
If your organisation uses an external traffic cleansing security provider, you can add their IP address to the allowlist. The diagram would look as follows:
Blocking addresses using denylists
The service also allows the reverse operation, which involves creating security rules that reject traffic from specific IP addresses or CIDR ranges. This practice is illustrated in the following diagram:
Applying custom rules to filter parameters between layers
Within Google Cloud Armor, you can use custom rule language to define one or more expressions in rule matching conditions. When the service receives a request, it evaluates it based on these expressions, allowing for blocking or allowing external traffic.
Using Google Cloud Armor to protect the origin server of Cloud CDN
To mitigate the risk of an attack on the Cloud CDN origin server through SQL injection (SQLi) or cross-site scripting (XSS), follow these steps:
- Create or identify a backend service with CDN enabled.
- Create Google Cloud Armor security policies.
- Create one or more rules in the security policy to help reject Layer 7 attacks.
- Configure one of the security policy targets as the backend service mentioned in the first step.
Protect against DDoS attacks and deploy Google Cloud Armor.
Assistance with Google Cloud Armor deployment
To efficiently utilize an essential tool like Google Cloud Armor, a cloud security policy, it is best to seek assistance from a certified Google Cloud Architect. Google Cloud’s premium partner companies, such as FOTC, has nearly a hundred of certified specialists. Learn how to navigate through the installation of Google Cloud Armor step-by-step, secure your services and online applications, and defend against the increasingly potent attacks we are witnessing today.
