Protecting Linux Against DoS/DDoS Attacks

Monday, June 27, 2011

Jamie Adams

4085079c6fe0be2fd371ddbac0c3e7db

When I first heard ridiculous-sounding terms like smurf attack, fraggle attack, Tribal Flood Network (TFN), Trinoo, TFN2K, and stacheldraht, I didn't take them too seriously for a couple of reasons — I worked mainly on non-Internet facing systems, and I was never a victim.

I thought it was primarily a network or application administrator's problem. I am not too proud to admit that I was completely wrong. The truth is that I only had a grasp of the impact of such attacks but I didn't know anything about the methods and the things that can and should be done at the operating system level.

I have been neck-deep in completing documentation for our product's Common Criteria for Information Technology Security Evaluation (ISO/IEC 15408) submission so I hadn't had much time to think about topics for a blog post. Besides, how can I compete with all of these eye-catching,dramatic headlines about LulzSec, Anonymous, and Ryan Cleary?

A co-worker asked me how our Security Blanket operating system lock down tool could help against denial-of-service (DoS) attacks. So began my research and I quickly had the epiphany that I barely knew anything about DoS attacks.

Of course this topic is far too broad and complex to cover in one blog post but I am going to highlight some of my findings. First of all, I strongly recommend visiting the SANS Institute InfoSec Reading Room and reading “A Summary of DoS/DDoS Prevention, Monitoring and Mitigation Techniques in a Service Provider Environment.” Secondly, read the W3C's “The World Wide Web Security FAQ - Securing against Denial of Service attacks.”

In “HACKING the art of exploitation”1, Erikson describes two general forms of DoS attacks: those that crash services and those that flood services. Wikipedia goes on to describe five basic types of attacks:

  1. Consumption of computational resources, such as bandwidth, disk space, or processor time.
  2. Disruption of configuration information, such as routing information.
  3. Disruption of state information, such as unsolicited resetting of TCP sessions.
  4. Disruption of physical network components.
  5. Obstructing the communication media between the intended users and the victim so that they can no longer communicate adequately.

The W3C defines DoS as “an attack designed to render a computer or network incapable of providing normal services. The most common DoS attacks will target the computer's network bandwidth or connectivity. Bandwidth attacks flood the network with such a high volume of traffic, that all available network resources are consumed and legitimate user requests can not get through. Connectivity attacks flood a computer with such a high volume of connection requests, that all available operating system resources are consumed, and the computer can no longer process legitimate user requests.

The W3C differentiates a DoS attack from a Distributed Denial of Service (DDoS) attack. The DDoS “attack uses many computers to launch a coordinated DoS attack against one or more targets. Using client/server technology, the perpetrator is able to multiply the effectiveness of the Denial of Service significantly by harnessing the resources of multiple unwitting accomplice computers which serve as attack platforms.

In the case of smurf and fraggle attacks, one method of prevention is to configure the router to block broadcast packets that did not originate from that network. On Linux systems, you can configure the kernel to disregard ICMP ECHO and TIMESTAMP requests that were sent to broadcast or multicast addresses by setting the kernel parameter net.ipv4.icmp_echo_ignore_broadcasts to one.

When it comes to “SYN flood” DoS form of attacks, you can configure Linux to send out requests (syncookies) to remote hosts if they are flooding your system’s backlog queue with SYN packets; to enable this set the kernel parameter net.ipv4.tcp_syncookies to one.

These requests check whether or not the inbound SYN packets are legitimate. In cases where these inbound SYN packets are not legitimate, your system might be experiencing a “SYN flood” DoS attack. Enabling this option on a system under normal load is useful. If your system is under high load it will make new connections but without advanced features such as explicit congestion notification (ECN) or selective acknowledgment (SACK).

All of the normal hardening procedures for the operating system will of course help. Namely, it will help reduce the likelihood your system will become compromised and become the platform for which attacks will be launched. Additionally, it is critical to know what software is present on your system. One technique to monitor this is to baseline (or fingerprint) your system to include the use of cryptographic hashes where possible. Then periodically, perform another baseline and compare it to the previous one.

The use of host-based firewalls (e.g., iptables) is strongly encouraged as well as disabling of unnecessary server services. System minimization has been a topic in many of my posts before and I believe it is one of the easiest but most effective techniques because it reduces your “attack surface.” The W3C FAQ also says, “assume a service should be turned off, unless it is absolutely required.” And I would take it one step further by removing the software packages associated with those unused services.

Safeguarding and monitoring operating systems against DoS and DDoS are areas which I continue to learn about and develop techniques. Please, share your knowledge and techniques so we all might learn.


[1] Erikson, Jon (2008). HACKING the art of exploitation (2nd edition ed.). San Francisco: No Starch Press. p. 251. ISBN 1-59327-144-1.

 

Cross-posted from the Security Blanket Technical Blog

Possibly Related Articles:
24157
Operating Systems
Information Security
Denial of Service DoS Operating Systems Linux Attacks DDoS Syn flood
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.