Google Cloud Networking: DDoS Protection Through Network Security


This post will teach you how to protect your website against DDoS attacks using network security and Google Cloud networking.

Major investments are made in Google Cloud's capabilities, and the company is constantly coming up with new ideas to stop cyberattacks such as distributed denial-of-service attacks from taking down websites, applications, and services. It's essential to protecting its customers.

Networking and security on Google Cloud

In order to defend against attacks, including stopping one of the biggest distributed denial-of-service (DDoS) attacks to date, Google Cloud uses portions of its Cloud Armor, Cloud CDN, and Load Balancing services in its Project Shield offering. Project Shield makes use of Google Cloud networking and its Global Front End infrastructure. It incorporates them into a robust protection architecture that can help keep significant websites of public interest up and running in spite of persistent attacks.

Although Project Shield is designed for customers who are particularly vulnerable to DDoS attacks, such as news organizations, infrastructure supporting elections and voting, and human rights organizations, enterprise clients can also benefit from Google Cloud networking and network security. For your application, website, or API, Google Cloud can help you secure workloads anywhere on the web by utilizing the same protection infrastructure as Project Shield. This is the process.

Dispersed Denial-of-serviceassaults on services

DDoS is a serious danger that can take down your service without requiring special authorization or security lapses. These attacks could come from anywhere in the world and are hard to track down. They frequently use compromised computers and sometimes even lightbulbs as components of botnets. Although the assaults look like regular network traffic, they happen very quickly millions of bogus requests are delivered every second.

To safeguard your service, you must be able to discern between legitimate and malicious traffic; but, you still need to handle all requests, no matter where they originate from. Google encourages you to focus on adding value to your audience, not on trying to stop the escalation of requests. To do this, effective defenses need to be scalable to handle more traffic than you actually receive.

How to get started

Older defensive tactics have been proven to be inadequate over time. Firewalls find it hard to reject requests that seem to be coming from reliable sources. Traffic filtering requires significant infrastructure investment, which is expensive and consumes resources that may be used more wisely.

It just takes a few minutes to secure your website with Google Cloud's networking and network security services. Its solutions may neutralize threats and cache your data to speed up user delivery while reducing the load on your hosting servers, all with the help of its latest machine learning (ML)-based protections. Your content can be hosted anywhere, but it will be protected by Google Cloud's Cloud Armor, Material Delivery Network, Load Balancer, and potentially Adaptive Protection.

There are two methods that you can set these security measures up for your business. There are two things you can do: either run this Terraform script (with a few modifications) or utilize the Google Cloud console interface and follow the steps below.

The steps listed below can be utilized to protect your service using the Google Cloud console interface:
  1. Take up a Google Cloud project first.
    • You can use the same project again if Google Cloud is already hosting your material.
  2. It is necessary to activate APIs for:
    • Cloud Load Balancer
    • Cloud CDN
    • Cloud Armor
  3. To locate your material, make a network endpoint group, which is a basic proxy. There are various forms for you to complete.
    • Give it a name.
    • ‘New network endpoint’ gives you the option to point to either an IP address or a fully qualified domain name.
    • Here, use the IP address and port of your website (instead of 8.8.8.8). This stage instructs the load balancer on where to retrieve material in response to incoming requests.
    • Press the Create button.
  4. You can click Next four times to construct a new load balancer (global front end) with the following configurations, all of which are defaults:
    • Application load balancer
    • Public facing (external)
    • Best for global workloads
    • Global external Application Load Balancer
  5. Assign a name to the load balancer.
  6. Indicate the direction of the traffic.
    • Choose Create IP Address after naming the frontend (it’s no more expensive than Ephemeral and lets you direct traffic to it regularly).
    • For your Frontend Load Balancer arrangement, which will resemble slide (2), use that IP.
  7. Add the Backend service after that.
    • Then select “Create a Backend Service.”
    • Give it a name.
    • Select the Internet network endpoint group as the backend type. The information that the load balancer needs to establish a connection to a place on the internet is stored in this container.
    • Click ‘New Backend’ to get a list of network endpoint groups, of which the group we created above ought to appear. Select that.
    • We will require Enable Cloud CDN later, so make sure it is checked, as it should be.
    • The cache mode settings work well. Cache static content refers to the fact that Cloud CDN will obey cache-control headers and cache static content (such images and PDFs) in the absence of an explicit cache-control header.
    • You can return later to change Cloud Armor rules in that UI, leaving Security settings as they are.
    • If you need to protect your backends from particular sources (such known attackers, certain geographic areas, and large volume), you can add rules to the Cloud Armor edge security policy that will take effect before traffic reaches Cloud CDN. These rules can also be added in the Cloud Armor UI at a later time.
    • To complete the load balancer’s addition of the backend service, click Create.
  8. To configure your new load balancer, click the Create button at the bottom of the page.
  9. Utilizing the same static IP as your HTTP load balancer, repeat steps 4 through 7 for HTTPS.
    • You can upload your own certificates or choose Google-Managed certificates. If you utilize Google-Managed certificates, provide the certificate by creating a CNAME record according to the guidelines.
    • To make your defense configuration simpler, you can use the same security policy you made for your HTTP load balancer, or you can utilize a second security policy.
  10. You can now direct your traffic to your newly configured load balancer. Don’t forget to update your domain’s DNS settings to point to the newly established static IP.
  11. [Selective] A couple more clicks will grant you ML-based protections for your backend:
    • Enroll in the Paygo Cloud Armor Service Tier (or use Annual to save money on an annual basis).
    • Open the policies for Cloud Armor.
    • Navigate to your policy by clicking.
    • Select Edit.
    • Select Enable under Adaptive Protection.
    • Press Update.
    • Select “Add rule.”
    • To access evaluateAdaptiveProtectionAutoDeploy(), select Advanced Mode.
    • Enter 0 to use the rule at high priority, or any other low value.)
    • Press Add.
    • With the knowledge it has gained about attack patterns and typical traffic, Google Cloud can now adjust to these patterns.

Improving the layer of caching

Traffic may resolve at the Google edge with the cache that cloud CDN provides, cutting down on latency and giving your backend a rest. It helps defend against wide-ranging, shallow DDoS attacks and is quite simple to activate on your load balancers.

The cache-control headers that your backend sends will guide Google Cloud's cache, but it can also allow automatic caching of static resources like images even in the absence of headers. Using a short Time-To-Live (TTL) could be highly helpful in minimizing request floods while preserving freshness. You can prevent backend overload even if your TTL is set to "one second."

Get started now

You can test this right now by choosing a backend that needs to be more reliable and accessible, adding a load balancer and CDN to it, and then monitoring the level of satisfaction that results. Protection-as-a-service, so you can focus less on headaches and more on happiness.




Post a Comment

0 Comments