A DoS and a DDoS…What’s the difference?
A “Denial of Service,” or “DoS” attack, is a category of advanced cyberattack in which a single malicious user denies legitimate users access to a service by blocking or exhausting the resources of a victim system. The DoS is commonly carried out through some form of flooding mechanism, which generates a large volume of network traffic around the area of the target system, resulting in undesirable network congestion and bandwidth utilization. This flooding causes the system to perform too much processing and responding, an aspect called “amplification.”
But, flooding the system isn’t the only way a DoS can be performed. Simply unplugging the system denies legitimate users access to the system’s services, which is, by definition, a type of DoS. Likewise, exploiting vulnerabilities in the system that, in some way, takes the system offline also denies the services it provides. Though this latter approach requires no flooding mechanism, it is still considered a DoS.
Then, of course, there is the “Distributed Denial of Service, or “DDoS” attack, which with the help of Anonymous, has gained more considerable attention in modern times from both non-technical and technical enthusiasts. But, let’s not get ahead of ourselves. A DDoS is not the same as a DoS. I’ll discuss the DDoS attack near the end of this post. Until then, let’s focus our discussion on the DoS attack and the many ways attacker’s execute this attack.
Denial of Service (DoS) Attacks
A DoS is characterized as an attack from one source, most of the time, with the purpose of preventing legitimate users from using the victim system’s services or resources. Let’s discuss a few of the most common ways to implement a DoS attack.
If the attacker has physical access to the system, he or she can create a DoS by physically taking the system offline. This would entail unplugging the system or damaging it in a way that it no longer functions as intended.
In an alternative approach, the attacker gains logical access to the system, allowing the attacker to misconfigure the target system. In a logical access scenario, let’s take a wireless gateway router, for instance, which sits on the edge of the network. This wireless gateway router is responsible for providing Internet access to the computers on its LAN connection. Hypothetically speaking, we’ll also say that the router’s administrator left the router’s username and password in its default settings. If the attacker logs into the router via a Web interface connection using the default credentials, then the attacker leaves the administrator no chance.
There is a well-known saying that if the attacker can gain physical access to your device, there is little you can do to secure it from him. Such is the case in this wireless gateway router scenario. Once logged into the router, the attacker can reset the login credentials to the router, effectively blocking the router’s administrator access into the router. From there, the attacker can deny legitimate devices access to the router via MAC address filtering, block access to Web sites, or even reduce the router’s built-in firewall settings to nothing. This is a DoS attack.
Gaining logical access into a system doesn’t have to be accomplished through default credentials either. On rare occasions, system administrators themselves can turn rogue and take systems offline. This can happen if the administrator holds a grudge with the company or soon after he or she has been terminated. For that reason, it’s important to complete a formal off-boarding process for any terminated employees. One of the important steps of this process is to disable the account(s) of the terminated employees. This would prevent them from gaining any remote or local unauthorized access to a system.
And, of course, we should never forget that many of our systems could be vulnerable to some other form of exploitation. The default configurations of our servers, for example, come with hundreds or thousands of services or open ports. If we do not disable these unnecessary services, then we increase the attack vector by which an attacker can gain access to a system. Some services are vulnerable to Remote Code Execution (RCE) and buffer overflow attacks, the likes of which could take the server offline.
The Smurf Attack
The “Smurf” attack is a type of DoS attack that abuses ICMP. An ICMP echo request (or ping) is usually unicast. However, in a Smurf attack, the attacker sends the ping out as a broadcast to the network. Every system connected on that network receives this broadcast and should respond back with an echo reply. But, the special thing about the Smurf attack is that the attacker spoofs his source address as the IP address of the target system. The victim, in turn, gets flooded with ICMP echo replies instead. Since the ICMP echo replies are sent to the victim instead, the Smurf attack is considered a type of “Reflected” DoS attack.
The Smurf attack isn’t usually successful these days because many routers don’t forward broadcasts, and it’s been this way since around 1999. And, if you are worried about this on your network, you can configure your hosts not to respond to ICMP requests or broadcasts.
The Fraggle Attack
The “Fraggle” attack is similar to the Smurf attack in which the source address is spoofed, but instead of using ICMP, the Fraggle attack sends UDP echoes to a router’s broadcast address. The end result is the same as the Smurf attack and, just like with the Smurf attack, the Fraggle attack can be prevented since most routers do not forward broadcast traffic by default.
The LAND Attack
The “Local Area Network Denial” attack, or “LAND” attack, occurs when the attacker floods a system with SYN packets. The source and destination addresses of these SYN packets are spoofed with the target system’s IP address. The target system receives this flood of SYN packets, making it appear as if the target system sent the packets to itself. While the system takes its time to reply to itself, the system becomes unavailable.
The LAND attack was first discovered in 1997 and many legacy systems remain vulnerable, such as Windows 95, NT, and XP SP2; however, modern systems have seen patches for remediation. Preventing the LAND attack takes good perimeter security, using firewalls and IDS/IPS to detect and drop this malicious traffic. Router ACLs can also be configured to restrict traffic coming into and out of the network to discard any traffic with identical source and destination addresses, or perhaps packets coming from an unknown network.
The Tear Drop Attack
In the “Tear Drop Attack,” the attacker exploits the reassembly of IP packets. Recall that if the data being transferred over the network is larger than the Maximum Transmission Unit (MTU), the packets are fragmented. The “Fragment Offset” field in the IP header is manipulated when a Teardrop program creates a series of IP fragments with overlapping offset fields. This field’s intended purpose it to solves the problem of sequencing fragments by indicating to the destination device where each particular fragment should be placed in the overall message. That way, the destination device can reassemble the fragments in the correct order.
But, when the fragment offset fields overlap,this creates and over-sized payload, and the target system is unable to reassemble the fragments on the other side. This causes the system to crash. Windows 7 and Vista are susceptible to the Tear Drop attack.
The Ping of Death
The “Ping of Death” was mentioned in one of my earlier posts. It is an older-style DoS attack that also exploits ICMP. What it does is it sends out a an over-sized ping packet to a target system (anything over 65,535 bytes). Older systems simply didn’t know what to do with this over-sized packet and crashed.
By the late 1990s, operating system vendors had already made patches to address Ping of Death vulnerabilities, making modern systems insusceptible to the attack.
The Permanent DoS Attack
The “Permanent DoS” attack, shortened to “PDoS,” is any DoS attack that damages the system beyond repair. One common way to execute a PDoS is through a method called “Phlashing.” With Phlashing, the attacker must somehow damage the firmware of the device, either by exploiting a vulnerability, uploading a corrupted BIOS to the system, and so on. The attack is successful if the attacker can “flash” the image of the target system’s firmware.
Importantly, physical destruction of the device, such as the case with a physical DoS mentioned earlier, can be considered a type of PDoS since it destroys the system beyond repair.
DNS Amplification Attack
The “DNS Amplification attack” exploits the Domain Name System (DNS) and it’s commonly used in DDoS attacks. The DNS Amplification attack is a type of reflected DoS attack, discussed a moment ago. In this attack, the attacker uses DNS servers to flood a target system with UDP traffic (DNS uses UDP port 53 for name queries).
The attacker makes hundreds of thousands of DNS queries to several DNS resolvers with a spoofed source IP address of the target system. These DNS resolvers respond back to to these fake queries with thousands of responses to the target system. This attack can also be “amplified” if the DNS requests are increased to a larger size. This results in the DNS resovlers responding with an even larger response size.
Distributed Denial of Service (DDoS) Attacks
The “Distributed Denial of Service (DDoS) attack differs from a regular DoS attack in that it’s a large-scale, coordinated attack originating from MANY attacking computers. Most DDoS attacks are launched from a bot herder who uses his botnet (hundreds or thousands of compromised “zombie” computers) to attack a target system. Compared to a DoS attack that uses just one attacker, the DDoS attack gives the attacker the ability to wage a larger and more disruptive attack.
DDoS attackers are difficult to identift because, number one, the attack originates from compromised computers, and number two, the source IP addresses are usually spoofed. You can use any of the DoS attack methods above in a DDoS attack; however, the most common way attackers launch a DDoS attack is the “TCP SYN Flood attack.” If you’re unfamiliar with the TCP Three-Way handshake, then I suggest reading up on it here before you continue.
In the TCP SYN Flood attack, the attacking computers send the first SYN packet to the target system. Following the rules of TCP, the target system acknowledges the connection with the SYN/ACK. However, the attacking computers never respond with the last ACK packet, which leaves the connection “half-open.” The connection is kept open, in a “SYN_RECV” state. This is normal since the ACK packet may have been lost due to network problems. However, in the TCP SYN Flood attack, the attacker sends thousands of these half-open connections to the target system. As soon as the system’s buffer or queue becomes full, it stops accepting connections, even from legitimate users. As a result the attacker denies the system’s services.
Basic Detection and Prevention of DoS and DDoS Attacks
Many of the DoS attack methods discussed earlier have been patched on modern systems; therefore, they are not vulnerable to some of the attacks mentioned. If your network hosts legacy equipment that is vulnerable to any of these DoS attacks, then it would be wise to isolate these systems on the network, especially if they are serving a critical function.
To detect the launch of a DoS attack on your network, you can use a protocol analyzer or NetFlow tool to reveal suspicious traffic indicative of a DoS. Wireshark, for example, is one feasible solution in the detection of DoS attacks. As depicted below, Wireshark has detected a UDP flood against against a server at 192.168.1.2.
Because protocol analyzers like Wireshark display detailed information about the structure of each captured packet, we can deduce a lot of useful information about the attack, including origin, packet size, time, and visual graphs.
Of course, excluding NetFlow and protocol analyzers, we can also use an Intrusion Detection System (IDS) to detect these types of attacks. A network-based IDS or a host-based IDS would be two valuable options for consideration. I won’t go into detail how these systems work; however, they are definitely feasible options. Most IDS implementations are in the form of software and, just like firewalls, they use “rules.” The difference is that these rules are much more powerful than firewall rules. “Snort,” for example, is a great IDS (and IPS) that can detect DoS and DDoS attacks.
As for prevention, it’s possible to prevent a DoS attack using an Intrusion Prevention System (IPS). Unfortunately, preventing DDoS attacks is a different problem seeing as they are so large and dispersed. An IPS may be able to drop a flood of packets originating from one source; however, when the source of the flood is coming from thousands of spoofed IP addresses in less than a second, the DDoS attack can’t be stopped. This makes DDoS attacks particularly frustrating. But, there are solutions available that can divert malicious DDoS traffic.
If you have a lot of critical servers or even one critical server, it’s important to practice “redundancy.” Having extra servers in a passive cluster will help mitigate any DDoS attack against one of your servers. The extra servers can pick up where the downed server left off. Additionally, installing a load balancer could definitely help mitigate smaller DDoS attacks by “balancing” and evenly distributing the load of incoming traffic to each server in the cluster.
Kumarasamy, S., & Asokan, R. (2012). Distributed Denial of Service (DDoS) Attacks Detection Mechanism. Cornell University Library. Retrieved from https://arxiv.org/ftp/arxiv/papers/1201/1201.2007.pdf
Pachghare, S. V. (2011). SYN Flooding Using Scapy and Prevention Using iptables. EFY Enterprises Pvt. Ltd. Retrieved from http://opensourceforu.com/2011/10/syn-flooding-using-scapy-and-prevention-using-iptables/
SANS Institute. (2011). Denial of Service attacks and mitigation
techniques: Real time implementation with detailed
analysis. Retrieved from https://www.sans.org/reading-room/whitepapers/detection/denial-service-attacks-mitigation-techniques-real-time-implementation-detailed-analysi-33764