Denial of Service Attacks
Recently there was a Dark Reading article on a new type of TCP DOS attack, of course the authors have learned their PR lessons and it's all hush-hush until the next big conference or product launch. Of course that leaves us all guessing as to what the attack could be. So I thought I would cover some basics about Denial of Service Attacks for people interested.
Normal TCP Connection
Client Server
SYN ->
<- SYN-ACK
ACK ->
DATA ->
<- ACK
FIN ->
<- FIN-ACK
SYN Flood
SYN Floods are one of the most basic Denial of Service attacks. The basic way they work is the attacker sends a large number of TCP requests to the victim (a server or network device). This ties up all his connection entries and he can no longer process incoming requests. To jump down to a even more basic level -
To make a connection to a server a number of things have to happen, one of them is generally a TCP connection. The connection involves a three way hand shake. The first is called the SYN, which the client sends, then the server says SYN-ACK - meaning I read you loud and clear. The next stage (third step in the three way handshake), is the client saying okay - we have a connection or ACK. Now we are in established state. So if my devices supports 5,000 connections then and you sent 5,000 SYNs I can't receive any more connections. So I have denied service. Make sense?
SYN Flood
Client Server
SYN ->
<- SYN-ACK
SYN ->
<- SYN-ACK
repeat
This technique has had a solution since 1996 (I know, I have the first patent on it). There are so many ways to solve this problem. One is to make a list of connecting and established connections. When the connecting list is full you throw away the oldest of those in the connecting state or favor something existing in the established list. Hence, clients that you have already spoken to are more trusted then those talking to you the first time. Again, dozens of solutions to the SYN Flood problem.
Connection Attack
A connection attack is basically the same thing as Denial of Service, except in this case I complete the three way hand shake. Now, I've gone onto your established list and eaten up your entries. You can also do this (but it's painful) by focusing on a single IP address and eating up every possible port number (16 bit value), but that requires a lot of connections (~65k) and generally speaking big sites use load balancers and dozens of IP addresses, so it's not useful.
Connection Attack
Client Server
SYN ->
<- SYN-ACK
ACK ->
Other forms of Denial of Service
You can play with TCP stacks to create other types of Denial of Service issues. Sending resets can interrupt connections or playing with the Window Size. I could make the victim think that I'm on a really slow link and it will leave the connection open forever. This works great on network devices in particular because they tend to shortcut the TCP fields to save on memory and speeding up their data searching (hashing, lists, trees, etc).
I did a recent test the other day on making the victim think I am on a slow link. I found devices with specific field size for the TCP header were susceptible to having this type of attack more often. For example, a Windows 2003 Server took 10 packets per connection, while a popular network firewall took 4 packets per connection. This type of attack is intensive in the number of packets (not large one's mind you, but still enough) and it fools even the best load balancers and firewalls. It definitely can bypass SYN-Cookies without a problem.
A good example on TCP Window Size is:
"In theory the TCP window size should be set to the product of the available bandwidth of the network and the round trip time of data going over the network. For example if a network had a bandwidth of 100 Mbits/s and the round trip time was 5 msec, the TCP window should be 100x10^6 times 5x10^-3 or 500x10^3 bits (65 kilobytes)" - so If I want to go slower?
This type of attack is really interesting because an article in Dark Reading recently talks about some folks that think they found the next DOS attack, no details have surfaced so who knows, but my guess it's this type of attack.
Application Denial of Service
Another Denial of Service is to run a CPU intensive program/script/query on the device you are after. For example, if I run a select query that is highly complex on a database I may be denying service to users that want to query as well. Run enough of these and you can starve people out. You could also send malformed data to the program, if the program crashes or runs really slow you deny service. A recent favorite we saw was VoIP related, some compression algorithms are more CPU intensive then others. By selecting a horribly slow one and creating a dozen calls, all voice calls start to suffer in quality - or worse can't happen at all. So you can see Denial of Service isn't just TCP related and there are dozens of ways to make it happen.
Network Device Denial of Service
Network equipment also suffers from Denial of Service problems. How many ARP entries can a device handle? How big is the connection table? Does it have a control path for routing protocols? If I send routing protocol packets, like RIP updates does it slow down packet processing? What if I send a flood of them? If I create a worse case packet for an IDS that leverages Regular Expressions, does it miss traffic? If so, I can sneak my attack by unnoticed.
So it seems that Denial of Service that will end the Internet is the new craze. To be honest, Denial of Service attacks aren't rocket science, to find one you just need to look, it really is that easy. It all comes back to testing; if you test the worst case scenarios in your product, you will come up with simple solutions to protect from these and minimize the possibility of a Denial of Service attack.
