What is a Denial of Service (DoS)? A DoS is a malicious attempt to prevent the normal operation of a computer system. There are many reasons an attacker may utilize a DoS: they may be used to stop business transactions, get revenge on a rival forum user, or even promote spam. This tutorial is bit technical, so make sure you’ve read the TCP/IP Tutorial before you begin.
You may frequently see the terms ‘DDoS’ (Distributed Denial of Service) and ‘DoS’ used interchangeably, but there are some subtle differences. Most DoS attacks exploit a particular vulnerability by sending carefully crafted network packets to the target machine, while a distributed attack (DDoS) comes from multiple locations at once and is generally a bandwidth flooding attack rather than an attack of some specific vulnerability. In addition to coming from multiple locations, these distributed attacks may or may not exploit vulnerabilities.
It’s important to note that the IP address a packet originates from may be forged, so simply dropping packets that have originated from an offending address may not always thwart the attack. In fact, this may be used to deny service to a legitimate customer: the attacker could spoof the legitimate IP in order to have it blocked. Imagine your network being flooded with source IPs of the root DNS servers, resulting in those IPs being blocked! The key to DDOS prevention is how you separate the “good” from the “bad.” Then, null-route the bad traffic (i.e. route it to a black-hole space) before it hits the interior of your network and overloads your routers or servers. A null-route is not the same thing as just blocking a port or denying an IP. Always block DoS traffic with a null route. Otherwise, you will reply to the attack with RST packets! This is something to avoid because, aside from flooding your upstream router, it could be an attempt to DDoS someone else using your replies. You must be able to accomplish this without adversely affecting any legitimate traffic to the system and failure to do so only helps the attacker.
“it is better that ten guilty persons escape, than that one innocent suffer” — William Blackstone
There are a number of companies that offer DDOS prevention services, either as a stand-alone unit to purchase and install in front of a firewall, or as a service that you route your traffic to via a BGP announcement. We won’t attempt to determine the best option for you, but instead give you the history and insights you need to make your own informed decisions.
Let’s look at some of the most historically famous attacks, how they worked, and how we can combat them. We’ll use historical examples (many of which are no longer effective) since the intent is to detail how the attacks operate as opposed to training you to take down networks using them! It should, however, give you a good idea of what you’re up against.
Historical & Famous
Ping of Death
The Ping of Death uses an ICMP PING to carry its payload since a PING doesn’t need to know anything about the target machine except its IP address. The attack itself exploits the fact that an IP packet can only have a maximum size of 65535 bytes. The OS thus uses this value as a buffer size. The Ping of Death sends its payload as a packet fragment. IP fragmentation splits a packet that is larger than the MTU (Maximum Transmission Unit) into smaller packets. Each fragment’s payload then contains an offset into the overall payload data buffer. The ping of death uses the maximum offset value, leaving only 8 bytes for the rest of the data. It sends much more than that, however, resulting in a packet larger than the maximum of 65535 bytes. This causes the OS to overflow its buffers and typically results in a crash. Mitigation: This no longer affects modern operating systems since they now check to ensure that the incoming packet length + the fragment offset does not exceed 65535. DoS prevention units typically perform this check in addition to IP fragment reassembly before the information arrives at the server or firewall.
Named after a song by the group Massive Attack, Teardrop is a DoS attack that is very similar to the Ping of Death. It works by setting packets’ fragment offset fields such that the packets will overlap when reassembled. This can overwrite packet headers cause all sorts of issues. Teardrop generally uses UDP, so it still works if ICMP is blocked at your router! Mitigation: In this case, the fragmentation issue was fixed in all major operating systems, but it came back again in later versions of Windows and required another patch. It is a good example of how these issues can keep returning. Defense systems offering packet reassembly provide good protection. Think ahead to the near future when we have the Internet of Things (IoT) and all your light-bulbs have their own IP address. How advanced is the IP stack in the cheap light-bulb?
This simple attack was able to take down some of the largest E-Commerce sites around back in the mid 1990s and it’s relatively simple. It’s a form of PING. When you send a PING, the target machine sends back a reply. More specifically, it responds to the address defined by the header of the packet. With that in mind, consider what happens when you ping a network’s broadcast address? Indeed, all of the machines on the network will respond! If the network contains 200 different machines, then a single packet just generated 200 response packets. An attacker can craft the PING packets such that the their target is in the “from” field. The destination address can then be set to the broadcast IP of any insecure network that does not block broadcast packets at the router. The attacker can then flood the broadcast address with these packets, performing what is generally referred to as an amplification attack. Mitigation: Configure your routers and firewalls properly. Generally, there is no reason to allow broadcast traffic into your network from the Internet. This protects your neighbor more than yourself, but it is an important precaution to take. PING floods are easy to detect with network monitoring software, and it’s generally safe to automatically add a firewall rule to temporarily block ICMP Echo Response messages from a flooding IP address since it generally doesn’t affect legitimate users. You should also whois the owner of the offending IP and instruct them to block broadcast messages!
Metaphorically speaking, fraggles are pretty similar to smurfs, except they aren’t all blue and they worship the trash heap. A Fraggle attack is much like the Smurf attack, but it uses the UDP services echo (port 7) or chargen (port 19). Most systems no longer run these services, but early Unix systems had them and early Linux systems followed suite to emulate Unix. These services send replies that can be hundreds of times larger than the original packet, causing an amplification attack that can get through firewalls and routers that have disabled ICMP, which is typically a poor solution already. Mitigation: Turn off unused services and block broadcast addresses at your router. Block both incoming and outgoing traffic to these services at your firewall such that you won’t be the victim or used as an amplifier. When you see attack traffic, inform the owner of the IP about the exploit so they can stop the attack on your end and stop flooding your firewall.
Local Area Network Denial (LAND) must be sent to an open port on the server. It sends a SYN packet where the source and destination address and port are the same. This will cause older systems to become confused and they’ll end up sending themselves packets in a loop! While Linux systems were never vulnerable to this attack, many routers and switches were susceptible since smart network devices have IP addresses and run addressable services. If an attacker crashes a network’s router, the server behind will also crash! Mitigation: Most new systems are no longer vulnerable and SYN proxies. Router/firewall configurations that block packets with the same source and destination will also help protect against the attack. Be sure to disallow remote access to your routers and switches. If you need remote control of these devices, however, use a VPN.
This small but aggressive animal ferociously attacks your network. The shrew attack is designed to get around bandwidth detection and anomaly detectors. It’s called a low-rate denial of service. It sends a very short but intense burst of traffic designed to cause a very minor packet loss at a congested router. It then stops so its average bandwidth remains well below the radar. TCP re-transmission time-out (RTO) is one second, so shrew sends the next burst precisely one second later when the previously lost packets will be resent! This means that the number of lost packets will slowly increase over time since each legitimate connection that losses a packet ends up contributing to the packet burst that causes additional losses. Mitigation: While fair queuing and similar methods can mitigate simple shrew attacks, a distributed shrew attack using multiple very-low-rate attacks can only be dealt with by network defense appliances. A number of solutions exist, such as Shrew Attack Prevention (SAP). SAP generally keeps records of active flows and prioritizes the traffic with an active connection that’s dropping packets. The prioritized packets get preferential treatment and are not consistently dropped. All other traffic, such as the attack, is delayed and buffered (traffic shaping).
DNS Reflection Attack
In this attack, DNS requests are made with wildcards and multiple extensions to make the size of the response as large as possible. The request is done using a forged source address of the target machine. This is basically another amplification attack, usually amplifying as much as 50 to 100 times! Mitigation: Rate limiting at the routers or DDoS prevention devices are the most common methods. You can also block known open recursive DNS resolvers that might be used for such attacks. Personally, I recommend that people avoid dual-use DNS servers and not rely on outside DNS services (such as Google’s 220.127.116.11). Your domain should be hosted on a DNS server that only resolves its own domain and resides outside the firewall (like djbdns or ldapdns). Then the caching DNS that uses recursive queries (such as djb’s dnscache) should only accept queries for machines on the local network. The firewall should only allow UDP port 53 traffic to/from the local DNS cache.
SYN Flood Attacks
There are many SYN-flood attacks, the most popular being Synk4, which should still function today since many systems are unprotected. Rather than trying to crash or exploit a vulnerability or deprive it of bandwidth, a SYN flood attempts to starve a system of connection resources. First, the attacker must find an open port. If it’s a web server, ports 80 and 443 are a given. Now we send SYN packets at the machine to the open port. The source address will be forged, so the SYN/ACK replies will never get back to the attacker and we can’t complete the TCP 3-way handshake. This is fine since the attacker doesn’t need to actually complete the connection. Each incoming SYN packet will force the server to create an entry in its connection table waiting for the ACK. The connections take a significant amount of time to expire and we can send enough SYN packets to saturate the connection table from even a modest connection.
There isn’t enough information in the SYN packet itself to filter out the attack. The SYN packets could be an attack with a random source address, or it could be a valid user of your system. Let’s look at a couple ways we commonly deal with these attacks.
- SYN Cookies – This method was created by Daniel J Bernstein. Every Linux machine has this built-in, but it’s not normally enabled. When SYN cookies are turned on, an overloaded server will send a SYN/ACK packet without creating an entry in the connection table. The SYN/ACK will contain a cryptographically hashed initial sequence number that contains relevant information from the received SYN packet. If this is a real connection, the remote system’s ACK tells us this is a valid connection and the information in the original SYN is recovered since the remote system sends us back our initial sequence number (after incrementing it by one). Forged packets cause us to send a useless SYN/ACK, but otherwise are harmless. Newer versions of the SYN Cookie method can encode support for the most common TCP extensions by performing a similar trick with the TCP timestamp field.
- SYN Proxy – This is a bit harder to home-brew, but a number of commercial DDoS defense products contains some form of SYN proxy, as does the open-source pfSense product. Like any other proxy server, the SYN proxy gets the data first. In this case, the initial SYN of the 3-way handshake is not passed on to the target server. Instead, the SYN-proxy sends the SYN/ACK to the attacker and keeps its own records of the connection. Once the 3-way handshake has verified that the connection is complete, it will open its own connection to the real server (usually using the IP of the remote system) and begins to proxy the data. SYN proxies can also do IP defragmentation and other services while performing the SYN proxy.
Application Layer Attacks
Application layer attacks simply send malformed data in attempt to crash the service. There are more application layer attacks than you can imagine, so we’ll look at a couple of the more famous examples. In these cases, the mitigation is to keep up with your system patching and advisories.
R-U-Dead-Yet is an HTTP POST attack. It opens a connection to your web server, sends an HTTP POST request and sets the Content-length header to an insanely large value. Apache will accept up to 2GB in its default configuration. The attack is simple. After the header, it sends the data incredibly slow. It’s just fast enough to not cause a TCP timeout. Meanwhile, the attacker opens up another connection. The process uses very little bandwidth, but can exhaust a server of valid connections in a hurry. Mitigation: Use a combination of URL-specific HTTP methods (don’t allow POST to URLs where it doesn’t make sense), absolute connection timeouts, and sane per-URL content-length limits.
This classic from the Hall of Fame was used to reboot Windows machines in a fraction of a second. It sends a malformed packet to the machine’s NetBIOS port (139) causing an internal buffer overflow in the machine that causes it to crash. Mitigation: While modern machines are immune, you need to ask yourself why you would allow connections to port 139 from outside your network. In most cases, only traffic on the local sub-net is valid for this service.
Attacker Methodology 101
The distributed denial of service (DDoS) attack can be any of the above from multiple sources, or just a bunch of simple HTTP requests in a loop designed to make legitimate network requests. In a DDoS attack, your attack is coming from multiple simultaneous locations. The main goal is to flood the server’s network bandwidth such that there is simply no more bandwidth available for regular traffic. The main advantage to using legitimate requests over a DoS packet is that it’s nearly impossible to distinguish from legitimate users of the service.
The most common methods of creating a DDOS attack is through a network of compromised machines. Typically, a virus or worm infects multiple machines and causes them to deliver a specific payload to the target machine at a given time. This W32.Mimail.E virus was specifically designed to attack spamhaus.org by making multiple legitimate requests on Oct. 31, 2003. The intent was to shut down spamhaus.org, a site that produces a reverse DNS block list (RBL) for use with SpamAssasin and other tools to identify senders of spam email. According to sources at spamhaus.org and the FBI, a large portion of email spam comes from Russian Mafia, who hired Chinese programmers to create the virus. Some of the largest DDoS attacks in history have targeted spamhaus.org. This incident was a pure bandwidth attack from millions of machines whose owners had no idea that the computers on their desk were making constant attacks against a website. Luckily, the browser ID string used by the virus was unique and not copied from a commonly used browser, allowing the attack to be identified and dropped by the Squid proxy being used to defend the site. This allowed the site itself, operating under a secret IP address, to stay operational.
Another common method of distributing attacks is via Botnet. This causes compromised machines to join a network group and await further instruction rather than attack a fixed destination. A common and easy way to control a botnet is via Internet Relay Chat (IRC). Before Facebook Messenger, Google Hangouts, and even before AIM, we had IRC. It is still used in the Linux and Open Source communities for collaboration and help on various projects and distributions. On IRC, you easily create a new channel and password protect it. The compromised machines join that specific IRC channel. The attacker send message in this channel to command the bots to coordinate attacks and even update their code dynamically.
For example, consider a simple botnet of 500 machines. Each of them can produce a DoS attack such as a DNS amplification attack which increases the effective bandwidth another 50 times or more. This simple configuration effectively expands your bandwidth by more than 25,000 times!
If a malicious user is intentionally targeting your network or one of your servers, the attacker will need to gather as much information as possible. They may be trying to obtain administrative access to the system through a root exploit, or may be simply trying to take down your website and render it useless.
The most common way of obtaining such information is through a network probe using a tool such as nmap. This tool can tell you what machines are operational on a network, what OS is running on it, usually the OS version number, what services are available, and the version of those services! This is a huge amount of information that can let an attacker know exactly how to target your system. This is often the first step an attacker uses when targeting your network, so watch for scans and be alert! You should configure your network monitoring software to watch for port scans and send alerts.
Luckily, you can fight back. Simple port scans are detectable, although very slow scans are much harder to detect and the stealthiest scans return less information. The attacker also needs to get this information returned, so the scan will be from a real IP address! Not forged! You can also use tools like p0f which use the same TCP fingerprinting method on incoming connections! Since the browser ID string is so easy to forge, you should not trust the OS version it reports.
Just when you thought it couldn’t get any worse, it gets worse. How about a Permanent Denial of Service (PDoS) attack? In this type of attack, the attacker gains enough access to damage hardware and render it useless. If you’ve heard of someone doing a firmware update to a device such as a phone or router and inadvertently “bricking” the device, imagine how easy it would be for a remote attacker to so the same. Never allow access to firmware updates from a remote IP. This should include VPN traffic as well. Firmware updates need to be limited to IPs that are on-premises in case something goes wrong. However, if an attacker gains root access to the machine, they can do just about anything.
This actually isn’t new. Back to the first days of computing, the TRS-80 had memory locations that determined the adjustments for screen size; height and width. This determined how far the electron gun in the CRT would move. Someone wrote a virus that set these values to zero which caused the video circuitry to burn out. A few years later, a virus was written for the early PCs that told the machine’s floppy drive to seek to an insanely high sector number, which would slam it really hard at the limit of travel. The virus then made it seek back to 0, then slammed it at the limit again in an infinite loop. It wouldn’t take long to actually break the read/write head on the drive. Most new hard drives are firmware controlled and anyone with root access can use a tool like the Linux hdparm to “update” the firmware and render the drive useless.
A PDoS is a denial of service, but in almost every case it requires root privileges to execute. Always be up to date on your OS patching and maintain strict security. Remote access to a machine should be through SSH only, which should be set to use key authentication only, not passwords. Furthermore, you should never allow direct login by the root user. There should be no root password; use sudo!
The system administrator is the front-line commander with respect to DDoS attack protection. You need to know your network and stay up to date on reports from CERTs (Computer Emergency Response Team) such as ocert.org, cert.org, and us-cert.gov. Linux admins should never break the integrity of the distribution’s package manager or maintenance will become a horrible nightmare. For this reason, you should choose a distribution that actively releases timely security patches and advisories. Your favorite desktop distribution may have a fancy GUI, but without an active security team to push security updates downstream, your networks and servers may be compromised.
Familiarize yourself with the DoS methods above and ask the protection vendors detailed questions about how the units they sell operate and what types of attacks they can mitigate. If you are hosted on Amazon, they offer the AWS Shield product for DDoS prevention. Other options, including some open-source ones (like pfSense, although its capabilities are limited), exist and can also be run on AWS. Also be ready to actively monitor your network for anomalous activity (Nagios is a good choice) and be able to route suspect traffic to a network analyzer such as Wireshark or to a black-hole address space (RFC 6666 specifically defines a black-hole IPv6 address block for this purpose).
TCP/IP is being expanded all the time with different extensions and improvements. Any of these could have implementation flaws. SSL encryption has been changed and modified countless times to address flaws and insecurities, many of which are quite recent. We now have IPv6 in its infancy and the Internet of Things offering new IP stacks that must be optimized for tiny resources – all new code and with new insecurities. The race is far from over. Never assume that old exploits won’t resurface or that new flaws won’t be found in the time it took to read this.