The implementation details will vary depending on the attack target and the request type, but the basic concept of a denial of service is to overwhelm a target with a seemingly legitimate series of requests so that real requests are ignored and not processed. If the attack is launched from multiple points on the network, it is referred to as a distributed denial of service attack (a.k.a. DDoS).
I remember when I first started hearing about denial of service issues more than 10 years ago. I even played with a few tools to generate them on my own--in my own network, of course. Back then, defenses for this sort of thing simply didn't exist. Aiming a tool at a helpless server protected by an even more helpless firewall was a great way to wreak havoc.
In general, there are two ways to create a Denial of Service condition:
- Cause the relevant service to crash. This is actually pretty difficult to do in a simple fashion given the resiliency of most public-facing services, though for lesser-used services, it can happen.
- Resource exhaustion, where some resource needed to provide the service (bandwidth, buffers, etc) is depleted in a way that causes the service to not respond to legitimate requests.
Over the years, every part of the service stack has gotten more resilient against the most basic form of these attacks. For example, a simple SYN flood won't take down most web servers these days as web servers are smart enough not to allocate resources to a connection until the three-way handshake completes. That said, if you can get a few million of your closest friends to run Low Orbit Ion Cannon at a server, or visit a particular webpage, you can still take down a target.
To give you a real-world example of this, I'll talk briefly about a recent denial of service someone brought to Check Point's attention via a Pastebin posting. The attack, ironically, was not all that different from the first SYN floods I played with more than a decade ago.
According to the report on Pastebin, the security researcher was able to essentially cause a Check Point Security Gateway to stop processing packets by sending ~120k packets per second. That's easy to generate inside a VMware environment, or even on an isolated network segment. Over an Internet link? Depends on the size of the pipe.
Regardless of how realistic that particular incoming packet rate may be in a given environment, what happens when the gateway sees that much traffic? In many cases, it simply runs out of memory, causing traffic to be dropped. It also runs out of processor capacity to forward said traffic.
Since the only way to truly stop a denial of service attack is to disconnect from the Internet, your best hope is that the various components are optimally configured to operate in potential denial of service conditions. Check Point's official response to this issue mentions four specific configuration changes that can be made to their security gateways:
- Implementing the IPS protection "SYN Attack" feature in SYN cookie mode, which will reduce the memory footprint caused by these bogus connection attempts.
- A hotfix for SPLAT/GAiA systems that, along other things, optimizes how the SYN+ACK packets that come back from the server are processed (IPSO does not require this).
- Where applicable, use multiqueue to increase the number of processors that can handle traffic on a given interface.
- Increasing the receive buffers on the interface.