Should an ADC be your first line of defense against Denial of Service (DoS) attacks?

Good question. And, based on all the Marketing spiel out there, you'd be forgiven for asking. As with most things, there are two schools of thought on this: ‘yes, it should’ and ‘no, it shouldn't’. Let's look at the arguments both for and against…

A quick side note on DoS and DDoS attacks

What is a DoS attack?

A Denial of Service (DoS) attack is designed to take down a website, server, or application, potentially crippling critical services. These attacks typically take the form of a very large number of superfluous requests made over a very short period of time. The overwhelming nature of these requests can result in services ceasing to be available to legitimate users, or bringing services to a crawl by severely slowing response times — hence disrupting availability.

What is a DDoS attack?

A distributed denial of service attack (DDoS, pronounced ‘dee-dos’) is a specific kind of DoS attack where the attack is launched from many different sources, making it very difficult to defend against.

Imagine that a plain DoS attack is like walking into a coffee shop and ordering 700 consecutive coffees. That would tie-up the baristas and deny genuine customers the chance to order coffee, or at least they'd have to wait in line a very long time. In the real world, this kind of ‘attack’ is easy to mitigate: the nuisance customer might be cut off after ordering 10 cups to allow everyone else to order (rate limiting their coffee ordering — we'll come back to that later…).

In contrast, a DDoS attack is like organising to walk into a coffee shop with 700 other people and having everyone order one coffee each. It's now almost impossible to tell the difference between real customers and the nuisance customers, but the result is the same; the shop is overwhelmed and genuine customers are denied the chance to order.

In reality, DDoS attacks are very hard to defend against in a meaningful way, mostly because it's difficult to tell apart the many, many smaller attackers from real users. There are specialised DDoS attack defense services available, plus Content Delivery Networks (CDNs) and cloud providers offer help and services in this area (with their global view of traffic and access to enormous amounts of bandwidth, they have the resources required to mount a realistic defense). These solutions involve routing all of your traffic through their data centers so they can squash any would-be DDoS attacks before they reach you and your services.

Now, for the rest of this post, we'll focus on regular DoS attacks — something that us mere mortals can actually defend against!

Where do DoS attacks occur?

DoS attacks can occur at different parts of the networking stack — often at the infrastructure level (layers 3 and 4) or at the application level (layers 6 and 7). This is an important distinction to make because the nature of a DoS attack will likely dictate the remedy needed.

Infrastructure DoS attacks

DoS attacks at Layers 3 and 4 are the most common, and include ICMP-based attacks at Layer 3, and at Layer 4 include SYN flood attacks on the TCP side, as well as UDP floods. These large volume attacks are designed to overload the capacity of a network or application. They are, however, relatively easy to detect due to their clear signature.

Application DoS attacks

Attacks at Layers 6 and 7 are less common, but tend to be more sophisticated. Their objective is to compromise a specific element of an application, making it unavailable for legitimate users. This might include an HTTP request flood to a web application's login page, or an XML-RPC flood in WordPress (aka a 'pingback' attack).

How can you protect against DoS attacks?

Your protection and mitigation strategy will ultimately depend on your use case and overarching security objectives. However, mitigation methods typically include the following:

Reducing the attack surface area

In other words, minimizing the possible points of attack. This can be done by using a CDN in front of your network, a load balancer to restrict HTTP traffic, or using a network firewall or access control lists (ACLs) to determine the traffic that is allowed to reach your applications.

Planning for high volume requests

If server capacity and network capacity are great enough, then they'll be able to absorb typical DoS attacks. Simply build for scale and ride out any storms. This is where load balancers shine, and it's exactly the same as planning ahead to be able to handle a surge in real customer traffic, such as a holiday sale or a special event. A load balancer provides the ability to scale horizontally and spread a workload across many back end servers.

Direct server return-based load balancing methods are particularly effective in this scenario: all reply traffic flows directly from the back end servers straight back to the client, eliminating the load balancer as a potential bottleneck on the return journey. Additional server capacity can be added with extremely little overhead, resulting in enormous scalability.

Autoscaling mechanisms are also useful, providing the ability to automatically spin up extra servers as virtual machines (VMs) or cloud instances to handle additional demand when it appears.

Again, CDNs are also a good option, here: if you can shift a lot of your content to being delivered by a CDN then you can dramatically reduce the pressure on your (origin) servers, leaving you with more capacticy to weather DoS attacks.

Distinguishing between 'good' and 'bad' clients

This can be achieved using rate limiting, where the rate at which HTTP requests and/or TCP connections being made per unique client IP address is tracked. Abusive clients making an unreasonable number of requests can easily be identified and blocked.

Rate limiting is best handled at a perimeter firewall (the earlier that packets from an abusive client can be dropped the better, and being able to block bad IP addresses at the perimeter is very helpful). It's also possible to implement rate limiting logic on a load balancer, which opens up the possibility of using more granular rate limiting rules. For example, when working with HTTP traffic, different parts of a web application can be rate limited to different degrees: an API or a login page might feature much stricter controls, while static content, like images, could be paired with much less aggressive rate limits.

Using a web application firewall (WAF)

This can be used to inspect the content of traffic before it reaches web applications. The rule logic of the OWASP Core Rule Set can be used to power such inspection, helping to block traffic that it determines to be anomalous and potentially malicious.

Ideally, in the context of weathering DoS attacks, a WAF will sit behind and/or be linked in with some form of rate limiting, to avoid the WAF layer itself from becoming overwhelmed and DoS'd. WAF inspection can take place on a load balancer, on an application-aware network firewall, or even on back-end servers themselves in the form of a distributed WAF solution. WAFs can play a useful role in detecting and preventing application-layer attacks, such as SQL injection (SQLi) and cross-site scripting (XXS) attacks in particular.

Yes, a load balancer should be a first line of defense against DoS attacks

In the past, some have argued that a load balancer should be used as a first line of defense against DDoS attacks.

This article by HAProxy makes some excellent points and suggests ways to mitigate DoS attacks using a load balancer, by…

• Employing TCP SYN flood attack mitigation at the kernel level*
• Using an HTTP request timeout to block Slowloris attacks*
• Limiting the number of TCP connections per user
• Limiting the HTTP connection rate

(*enabled by default on Loadbalancer.org appliances)

…all of which are valid ways to improve protection, and can all be configured on our load balancers.

BUT (and it is a pretty big BUT), using a load balancer to protect against DoS attacks is not the same thing as deciding to use it as your first line of defense.

A load balancer is only one piece of the puzzle. If you're shopping for a DoS protection solution then you don't want to only buy a load balancer! Start by purchasing a firewall from a reputable security vendor, configure that as appropriate to protect your environment, and maybe then add a layer of load balancing as a next step.

No, a load balancer should NOT be a first line of defense against DoS attacks

Our view is that while an ADC can play a role in defending against DoS attacks, a load balancer should not be used as the first line of defense, for these two, very good reasons:

1.The FIRST line of defense is your network firewall

The first line of defence is a network firewall, not a load balancer or a web application firewall. Network firewalls work with packets, protocols, and connections, and typically operate at (up to and including) Layer 4 of the networking stack, whereas web application firewalls (WAFs) inspect HTTP messages and operate at Layer 7, the application layer.

Network firewalls are specifically engineered to act as a first line of defense, and they can be very good at it. They feature highly efficient packet filters — a mechanism for handling network packets and deciding when and how to drop, reject, forward, process, or transform them. Network firewalls are built to handle millions of packets per second. They also perform connection tracking, where a stream of individual packets are grouped into the logical conversation they belong to. This allows for stateful inspection — if an unexpected packet arrives that doesn't belong to a pre-existing or new connection then it may be discarded as garbage. Network firewalls can handle tens of millions of connections at the same time: this is their bread and butter, and they're very good at it!

2.The SECOND line of defense can be an ADC

A load balancer should always sit behind a dedicated network firewall. Why? Because you don't want to rely on a single box to play the role of firewall and load balancer and WAF (and potentially web server, too!). That might be fine for a personal website that sees 5 clicks per day, but for any real service with real customers such a setup simply doesn't cut the mustard. Those roles should be separated out to dedicated machines, either hardware or virtual.

It's also important to remember the principle of defense in depth. A multi-layered system of defense, made up of multiple, independent parts provides a strong and resilient defense. This is because if one or more layers of defense should fail, then there are still other defensive layers in place to stop attacks and raise the alarm. Putting all of the defensive measures on one device is like having a single-layered balloon that's ready to pop, in contrast to a resilient, multi-layered onion with many different layers of defense.

It's worth noting that an ADC itself will often feature two types of firewall:

• OS-based / in-kernel packet filtering (e.g. the firewall you might configure using nftables, iptables, etc.)
• Web application firewall (WAF, often an optional extra)

The OS (operating system)-based firewall can filter and block packets, connections, and ports, allowing you to control access to services that you don't want the public internet or the wider network to see (preventing things like SSH attacks). System administrators can configure firewall rules to filter incoming and outgoing network packets however they wish.

A WAF, on the other hand, looks at the content of traffic, rather than the individual IP packets that make up that traffic. In other words, a WAF is a web filter that decides whether a given request is 'good' or 'bad'.

When DOES it make sense to use a load balancer to defend against DoS attacks?

Any modern web application or API ought to feature some form of request rate limiting as a security measure in the application itself. This helps to stop automated denial of service (DoS) attacks, brute force attacks, and credential stuffing. However, where rate limiting controls are inadequate, too coarse, or completely missing in a web app, this security logic can be added in at the ADC layer. Under these circumstances, a load balancer can look at certain types of requests and see if someone’s trying to make the same web request again and again and again, blocking such flood attacks.

How does rate limiting actually work?

Rate limiting can stop DoS attacks from a given traffic source by setting a threshold for the number of requests that a single client can reasonably make over a given period of time. This sort of logic should first be applied at the EDGE (e.g. using Cloudflare or another CDN and their built-in protection), then maybe at your firewall as well, and THEN, finally, on the load balancer that's protecting your application.

A word of caution, though…

DoS protection is easy to tune incorrectly and because the fundamental role of a load balancer is to provide an uninterrupted end user experience for critical applications, doing anything that can BLOCK access to legitimate user requests can ultimately undermine this. Like many things in life, rate limiting is a powerful tool but it can bite you if you use it incorrectly. Rate limiting can be used in combination with a WAF, or in isolation (which is especially useful when working with non-HTTP traffic, taking the WAF option out of play).

How to configure the rate limiting feature on your Loadbalancer.org application to mitigate DoS attacks

Rate limiting configurations can be added to virtual services on our load balancers. It's possible to apply rate limiting based on the number of open TCP connections, the rate of HTTP requests, and many other metrics. When required, it's possible to combine multiple different counters and metrics to provide fine-grained, complex, custom rate limiting and blocking logic, although a simple rate limiting solution is often the best answer: easy to understand, easy to implement, and extremely effective.

Here are some resources you might find helpful:

• Simple Denial of Service (DoS) attack mitigation using HAProxy
• How to rate limit with HAProxy Stick Tables and the WAF to prevent DoS attacks
• Handling large requests with a WAF while avoiding DoS attacks
• A deployment guide showing a real world use case

If there's anything you're unsure of, please do reach out to our technical team before you get started!

Conclusion

Security at the application level is complex and specific. Sadly, there is no single product that has a magic button that can protect against DoS attacks (and you should definitely question the integrity of anyone who claims that their single product is a comprehensive standalone solution...).

An ADC can be used to support overarching security objectives, but it is not a standalone security device, and should not be used as a first line of defense. Instead, its primary function is to optimize and manage application traffic and improve performance by balancing loads, offloading TLS/SSL processing, and caching content.

Yes, ADCs provide features that can help support the overall security ecosystem and make your applications more secure, and yes, Loadbalancer takes measures to ensure that our products are as secure as possible. But a layered approach is needed to prevent DoS attacks: a network firewall, DMZ, WAF, host firewall, data validation, and more. Your load balancer should not be first in line.