How ASPHostPortal Deals with DDOS Attacks?

You have to be aware of your surroundings in order to avert an attack. A distributed denial-of-service (DDoS) attack is when an attempt is made to obstruct a targeted server, service, or network’s normal operation by flooding it with unsolicited traffic.

A denial-of-service (DDoS) attack aims to prevent access to a server by flooding the target with malicious traffic that exceeds its capacity. We put traffic filtering solutions into place to guard against these kinds of attacks and ensure maximum uptime.

To stay ahead of the curve, we’re always updating our systems and enhancing our services. We’ll go through our defenses against DDoS attacks, as well as the configuration of our Wanguard traffic filter and infrastructure in general, today.

How Does an Assault Appear?

This is an actual instance of a DDoS attack. Imagine 400 Mbps of UDP traffic going to a VPS that has 100 Mbps of available bandwidth.

Simple Underattack website load time results:
Before the attack: 0.08 seconds
During an attack: 22.35 seconds (1st attempt), 33.16 seconds (2nd attempt)

Due to the fact that DDoS attacks typically involve entire or numerous botnets targeting you, they are frequently difficult to mitigate. Since a botnet is made up of numerous compromised systems, attempting to combat it on your own will typically backfire.

ASPHostPortal Response to DDoS Attacks

To counter incoming attacks on our infrastructure, we have two DDoS mitigation solutions: traffic filtering and remotely triggered black holes (RTBH).

Before unwanted traffic even reaches our infrastructure, it can be swiftly eliminated with RTBH filtering. Although as a service provider this approach successfully safeguards our infrastructure, it also keeps all traffic from reaching us, which is not what our clients want. Their VPSs and webpages eventually go completely offline. The attackers succeed in their objectives as a result.

For our services, traffic filtering is the next-generation DDoS defense. Rather than erasing all traffic, it simply halts the malicious traffic. We can detect malicious traffic by looking at the packets that are passing through our infrastructure. We look for particular patterns in the following traffic elements:

• packet payload
• source port
• source IP
• destination port
• country
• and more

Our clients don’t need to worry because this filtering is done on our infrastructure before the traffic reaches our services.

Traffic Filtering

Setup

For our setup, out-of-line filtering has been put into place. In-line filtering would be impractical and expensive because strong DDoS attacks are rare; instead, we have the RTBH technique to defend against them.

In our setup, traffic is diverted via spine switches that are connected to filter instances. We examine and reroute traffic as necessary using sFlows, which are sent from spine instances to the filter instance. Malicious traffic is dropped at the filter instance, while clean traffic is routed to leaf switches. It’s crucial to remember that the filtering and traffic diversion systems are completely automated.

We use ExaBGP to advertise a destination host’s IP address to the spines in the event that any host experiences a traffic spike above our predetermined thresholds. We look at the incoming packets when the traffic reaches a filter instance in order to determine the attack pattern. After finished, the firewall is updated with new rules that stop malicious traffic from getting to its intended target.

Hardware

The CPU and NIC are the primary components on which the filter server is dependent. Following some investigation and testing, we chose the following:

CPU: Intel(R) Xeon(R) Gold 5218 @ 2.3 GHz
NIC: Intel XL710 (40G)

The CPU usage during a DDoS attack with 8 Gbps of traffic and ~1.5 Mpps looks like this:

Automation

Handling several filter instances across all data centers would be difficult. Because of this, every aspect of the solution—from attack detection to threshold settings—is entirely automated. Right now, Ansible and Chef are what we use for infrastructure as code (IaC). All it takes is a few lines of code to update thresholds or other settings for all instances at once.

Configuration

Since our instance needs to be able to route packets between interfaces, IPv4 and IPv6 forwarding is turned on. We must disable reverse path filtering or set it to “loose mode,” as we have done, since we don’t have any routes via interfaces used for traffic diversion. This will prevent packets arriving via those interfaces from being dropped.

The maximum number of packets that can be sent in a single NAPI poll cycle (net.core.netdev_budget) has been raised to 1000. We have our ring buffers set to maximum because in this scenario, throughput is more important to us than latency.

After implementing this solution for six months, we’ve seen that the minor adjustments are sufficient to fend off any attacks on the expected scales. We chose not to fine-tune the system further because the default settings are adequate and pose no issues.

Acts are the next in line. The detection or completion of an attack initiates an action. We use it to notify our monitoring team about the attack (via a Slack message from the instance), redirect traffic (route announcement via ExaBGP), and more.

Additionally, thresholds are handled as code, offering a multitude of choices for attack detection. For instance, we initiate the filtering process if we notice 100K UDP packets per second directed at a single target. Additionally, it could be HTTP/HTTPS requests, TCP traffic, and more.

Additionally, prefixes that need to be protected are automatically added by Chef data bags.

Results

How would one respond to a DDoS attack on Grafana? Below, we’ll examine a recent attack that used 8 Gbps and 1 Mpps of traffic.

This is the traffic that the filter instance is receiving:

This is the traffic that is being sent to the final device:

As seen, there is a brief spike in traffic moving from the filtering instance to the end device. It is the void left by the process of identifying attack patterns. Though it usually lasts only a few seconds—between one and ten seconds—it’s still something to be mindful of. As the graph illustrates, you’re safe once the attack pattern is found!

How quickly are attacks detected? This component relies on sFlows and is known to be slower than port mirroring. However, it is less expensive, more flexible, and simple to set up. It takes 20 to 50 seconds after an attack begins to redirect traffic to the filter instance.

The entire procedure appears as follows from the target instance:

After a brief spike, everything resumes as usual. You might not even notice it, depending on the service you are using.

Let’s look into this case a little bit more because at ASPHostPortal, we like to know what is going on with our infrastructure:

Source of Attack. India and Taiwan were the two countries contributing the most to the increase in IPv4 traffic that we observed. This information might be erroneous because there’s a good chance those IP addresses were spoof. Because of spoofing, we will not publish the list of source addresses and ASNs that we possess here.

Attack protocol. Since there were no odd spikes on the TCP graph, the attack was primarily focused on UDP.

Attack type.It caused a lot of traffic to flow to arbitrary UDP ports.

Summary

Although RTBH is an effective DDoS defense, it eventually causes outages. We only drop malicious traffic after integrating the traffic filtering solution into our infrastructure, as opposed to all traffic. We’ve observed a 90–95% drop in RTBH usage, which has improved service and customer uptime.

ASPHostPortal has you covered if you’re looking for a dependable ASP.NET hosting solution. Our hosting offers market-leading performance, a 100% uptime guarantee, DDOS-protection and first-rate technical support.

We also provide a variety of hosting packages at reasonable prices, including shared, managed, VPS, cloud, and more. To see how simple it can be to host a website online, sign up right away.