Survey of Denial of Service Countermeasures
(November 2000)
Ping-Herng Denny Lin, California State University Fullerton
Keywords: Denial-of-service, SYN flooding, firewalls, routers, cookies, protocols, intrusion detection.
A denial-of-service (DOS) attack is aimed at shutting down a computer or a network, by exhausting a computer's resource or by exhausting bandwidth limits of a network. SYN flooding is most often mentioned in connection with DOS attacks and distributed denial-of-service (DDoS) attacks.
SYN flooding attacks consist of a stream of connection request packets an attacker sends to overwhelm a victim host's connection request queue. The victim host replies to each connection request by sending a synchronize + acknowledge (SYN+ACK) packet to the requestor, and waits for an acknowledgement (ACK) packet. A malicious client exhausts the victim host's request queue by forcing it to wait in vain for ACK packets that will never arrive. Once the victim host's request queue has been exhausted, legitimate connection requests are denied access to the host [Rlk99].
Many network administrators and commercial vendors have suggested various firewall or router configurations to stop DOS attacks. New operating system architectures have been designed and proven to be effective against DOS attacks. Protocol designers have proposed DOS resistant protocols. Firewalls may be also be used to protect against DOS attacks. Finally, the recent explosive growth of intrusion detection products promises to counter DOS attacks and other malicious attacks.
There is no perfect solution for DOS attacks, and the problem appears to be a difficult one to solve. This paper examines the strengths and weaknesses of these countermeasures.
Ferguson, Senie, and the SANS institute have outlined specific steps to configure and use firewalls and routers as DOS countermeasures.
During an attack, the firewall responds to the SYN sent by the attacker; since the ACK never arrives, the firewall terminates the connection with an RST packet, and the host never receives the datagram. For legitimate connections, the firewall creates a new connection to the internal host on behalf of the client, and continues to act as a proxy for translating sequence numbers of packets flowing between the client and server [Skk97].
Strengths: Host is completely shielded from DOS attacks, and never receives spoofed SYN packets. Weaknesses: New delays are introduced for legitimate connections.
Strengths: No delays introduced for legitimate connections.
Weaknesses: Timeout period needs to be carefully selected so access is not denied to legitimate connections with long response times.
In RFC 2267, Ferguson and Senie described network ingress filtering that can prevent attackers from using forged source addresses to launch a DOS attack [Fse98].
Strengths: Effectively stops attackers within the originating network from forging source addresses that do not conform to ingress filtering rules.
Weaknesses: This technique does nothing to address flooding attacks that originate from valid IP addresses, and may negatively affect mobile IP services [Fse98].
Strengths: Useful when deployed close to the end user. Effectively deters attackers from victimizing others with one's network resource.
Weaknesses: Egress filtering becomes difficult for Internet Service Providers and almost impossible for major service providers. These service providers frequently need to forward legitimate traffic that is not part of its own address space [San00].
Senie urged administrators to block the receipt and forwarding of network-prefix-directed broadcast on routers through RFC 2644 [Sen99].
Strengths: Combined with egress filtering, this technique will prevent participation in a "smurf" or "fraggle" attack.
Weakness: Broadcast amplification is a useful diagnostic tool. Without a broadcast amplifier, the WINS server on the network will not receive the broadcast, causing some name resolution on Windows systems to fail [Cia00].
This bulletin gave an example of improvements achieved for a server with 25 listening ports, and an 8,192-entry queue, by merely upgrading its memory from 64MB to 128MB. At 600 bytes/entry, the system coped well under an all out SYN flood attack because the total memory consumed would be 120MB [Cia96].
Strengths: These brute force improvements require large amounts of protected kernel memory. They are relatively easy to implement, and successful attacks are less likely because attackers would need to flood connection requests at a rate exceeding reasonable bandwidth capabilities.
Weaknesses: Server response time may be slower due to the larger "connection pending" data structure it needs to search [Rlk99].
This admission control mechanism drops a pending request from a full connection request queue. The algorithm can pick a request at random, select the oldest request, or use a combination of both, to deal with a queue under attack [Cia96]. Ricciulli, Lincoln, and Kakkar revised an analytical model for the random drop algorithm, and used a high-fidelity simulation to compare random request dropping with three other cookie-based SYN flooding defense mechanisms.
Strengths: Ricciulli et al. reported that random dropping worked well in both low congestion and high congestion by keeping client performance losses below 10%, even under very high spoofed SYN rates [Rlk99].
Weaknesses: An attacker can occasionally deny a legitimate connection request.
Strengths: The Escort architecture supports end-to-end resource accounting, and multiple hardware-enforced protection domains so un-trusted modules can be isolated from each other. It can successfully detect and remove offending clients while delivering quality-of-service guarantees to other clients with very low overhead.
Weaknesses: The Escort architecture appears to work only on the Scout operating system, and has yet to be extended to popular operating systems such as Unix, Linux, and Windows.
Bernstein and Bona suggested a stateless cookie approach. When a client sends a SYN packet, the server calculates a one-way hash of the sender's sequence number, ports, the server's secret key, and a counter that changes every minute. The server sends the result of the one-way hash to the client, and the connection is not established. When the client replies with an ACK packet, the server recalculates the same hash function and throws away the packet if it fails to authenticate with the server. Otherwise, set up the Transmission Control Block, if it doesn't already exist [Ber96, Bon96].
Strengths: Memory is never exhausted by SYN flood DOS attacks, as CPU time is used to calculate hash values.
Weaknesses: In case of packet loss, the server is prevented from sending SYN+ACK packets, breaking TCP semantics [Rlk96].
Strengths: Optimizes the server's behavior under stressful conditions.
Weakness: May be vulnerable to re-play attacks. New protocols approaches require changes to existing protocols.
Strengths: Cryptographic puzzles can have varying levels of difficulty (different sizes), so that the difficulty can increase as an attack becomes more severe.
Weakness: Requires client-side software capable of solving the puzzle.
The paper contains a sample application of the theoretical framework to the Station-to-station protocol proposed by Diffie, van Oorschot, and Wiener; the author found several DOS vulnerabilities in the protocol. Because it is difficult to prove the correctness of a protocol, automated protocol analysis tools can help reveal vulnerabilities.
ID products available include RealSecure by Internet Security Systems, IntrusionAlert by Unified Access Communications, SecureNet Pro by Intrusion.com, NetProwler by Axent, and freeware such as Snort.
Strengths: Reybok and Engle's article on securityfocus.org suggests that ISS RealSecure is an excellent tool for detecting intrusions [Ren00]. ID systems are designed to detect violations to usage policies, virus activity, and pre-attack probes, and other malicious hacking activities. Thus, ID capabilities transcend DOS detection.
Weaknesses: In 1998, Ptacek and Newsham described ways to evade ID systems using insertion attacks, evasion attacks, and DOS attacks. The authors of the paper found serious weaknesses in four 1996 versions of popular products (RealSecure, NetRanger, SessionWall, and Network Flight Recorder). Insertion and evasion attacks disrupt reassembly of packets, causing ID systems to accept packets that hosts should reject. They also claimed that the "fail-open" nature of ID systems doesn't deny a hacker's access to the victim network when a monitor system becomes unresponsive due to a DOS attack. For ID systems that are capable of retaliatory attacks, the ID system may be tricked into retaliating a host that has not perpetrated any attacks [Pne98]. Many of these vulnerabilities have been addressed in recent versions of ID systems.
Many ID systems rely on rule-based algorithms and these rules need to be updated as new attacks are discovered. ID systems need to be maintained to keep these rules up to date.
In April 2000, Securityfocus.org reported that RealSecure uses a Microsoft Jet database to store data collected from detectors at the console. The size of this MDB file cannot exceed 1 Gigabyte, and must be frequently purged [Ren00].
Firewalls can be configured as a relay, or a semi-transparent gateway. The latter method promises to provide efficient connection times for legitimate requests; however, the timeout period needs to be carefully selected, so that slow legitimate connections are not denied. Firewalls and routers can be configured to filter packets. Filtering techniques require widespread adoption by system administrators. Egress filtering may be difficult to implement on ISPs and impossible to implement on major service providers. However, these methods effectively stop attackers from forging addresses and using a compromised network to launch DOS attacks. Disabling broadcast amplification prevents smurf and fraggle attacks, but the usefulness of this approach should be weighed against the need to use this feature as a diagnostic tool, and the need to support WINS servers.
Operating system improvements in Solaris and Linux promises to affect the majority of web servers. Simple brute force improvements are possible, at the cost of slowing server response times. Random drop admission control mechanisms may optimize the behavior of any operating system that adopts this algorithm, at the cost of occasionally dropping a legitimate connection request under a DOS attack. New security architectures promise to make operating systems resistant to DOS attacks. However, the benefits of such architectures need to be extended to existing operating systems.
Protocol improvements designed to resist DOS attacks have been proposed. Cookie-based approaches use one-way hash functions so that under a DOS attack, only cheaper CPU resources are used instead of expensive memory resources. Stateless protocols strengthen servers against DOS attacks, by storing state information in the client. Client-puzzle protocols deter DOS attacks by requiring suspicious clients to compute solutions to hard puzzles before the server completes the request. Theoretical framework is useful for analyzing and evaluating newly developed protocols. In all cases, the need to replace old protocols with newly developed ones is the biggest disadvantage in this approach.
In intrusion detection, stand-alone monitors deploy sensors and engines to detect network anomalies and warn administrators. The field of intrusion detection is relatively new, and its capabilities are not limited to DOS attacks. Important vulnerabilities have been reported, and improvements in intrusion detection are to be expected in coming years.
There are no simple solutions to DOS attacks. An effective response to the problem requires deployment of multi-faceted techniques, deliberate analysis, changes to many of the protocols and operating systems we use today, and deployment of an effective intrusion detection system.
[Anl00] T. Aura, P. Nikander, J. Leiwo, "DOS-resistant Authentication with Client Puzzles"
[Ber96] D. J. Bernstein, "Syn floods - a solution"
[Bon96] R. Bona, "TCP SYN attacks - a simple solution"
[Cia96] CIAC, "H-02: SUN's TCP SYN Flooding Solutions", Information Bulletin, October 1996.
[Cia00] CIAC, "K-032: DDoS Mediation Action List", Information Bulletin, April 2000.
[Cox96] A. Cox, "Linux TCP Changes for protection against the SYN attack", September 1996.
[Dna95] C. Dwork, M. Naor, "Pricing via Processing or Combating Junk Mail"
[Fse98] P. Ferguson, D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing" RFC 2267, January 1998.
[Hma99] S. Hirose and K. Matsuura, "Enhancing the Resistance of a Provably Secure Key Agreement Protocol to a Denial-of-Service Attack", Lecture Notes in Computer Science 1726, Springer-Verlag, Berlin, P.169-182, November 1999.
[Jbr99] A. Juel, J. Brainard, "Client Puzzles: A Cryptographic Countermeasure Against Connection Depletion Attacks", NDSS '99, Proceedings of the 1999 Network and Distributed System Security Symposium
[Mea99] C. Meadows, "A Formal Framework and Evaluation Method for Network Denial of Service"
[Pne98] T. Ptacek, T. Newsham, "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection"
[Ren00] "Deploying ISS Realsecure in a Large Scale Environment"
[Rlk99] L Ricciulli, P. Lincoln, P. Kakkar, "TCP SYN Flooding Defense", CNDS 1999.
[San00] "Egress Filtering v 0.2" GIAC Special Notice, SANS Institute Resources, February 2000.
[Sen99] D. Senie, "Changing the Default for Directed Broadcasts in Routers", RFC 2644, August 1999.
[SKk97] C. Schuba, I. Krsul, M. Kuhn, E. Spafford, A. Sundaram, D. Zamboni, "Analysis of a Denial of Service Attack on TCP", Proceedings of the 1997 IEEE Symposium on Security and Privacy.
[Spe99] O. Spatscheck, L. Peterson, "Defending Against Denial of Service Attacks in Scout"
You are visitor number