The recent attacks that were launched against Yahoo, Amazon, and eBay have catapulted denial of service attacks to prominence. But what exactly do DoS attacks do? And can they affect Linux? Read Vincent Danen's Daily Drill Down to find out.
Recently, malicious hackers struck down a number of well-known and popular Web sites, including Yahoo, Amazon, and eBay. Since then, speculation has been running rampant, and many papers have been written on the subject of denial of service (DoS) attacks. In this Daily Drill Down, I’ll discuss denial of service attacks, and I’ll tell you how you can prevent DoS attacks from harming your Linux server.
What is a DoS attack?
In its most basic form, a denial of service attack is an action that’s initiated by a person or any other system that incapacitates your server's hardware and/or software. It renders your server unreachable and causes the server to deny service to users. DoS attacks originate from attackers who want to knock your server(s) off of the Internet. DoS attacks are always malicious and illegal, except for those instances when security teams test consenting systems.
DoS attacks are a persistent problem for several reasons. First, they are one of the easiest attacks to perform, and they achieve immediate results. They are the most common attacks that an administrator with a system that’s always connected to the Internet can expect. DoS attacks also exploit errors, limitations, or inconsistencies in TCP/IP stacks and programs until the author fixes and releases a corrected version of the offending program. While the author is scrambling to fix the program, however, the vulnerabilities exist, and someone is going to exploit those weaknesses eventually.
You would think that Linux users, who have the source code for most of their used applications at their fingertips, would be less affected by DoS attacks. Such is not the case. Certainly, Linux users might find themselves patching software after a new DoS attack surfaces, reconfiguring hardware, or filtering TCP or UDP ports. Unless these Linux users are programmers, however, they must rely on someone else to provide the patches or updated programs that will fix their applications. Thus, Linux systems are just as vulnerable as any other operating system that hosts Internet servers.
Now, you can understand why a DoS attack can wreak such havoc on any server. For some systems, the effects will be trivial; the attacked service can be stopped and restarted easily. For others, however, there may be far-reaching implications. Since the Internet is home to thousands of commercial organizations that produce revenue, a well-timed (or ill-timed, depending on your perspective) DoS attack can greatly reduce profit. To thousands of e-commerce vendors, this possibility poses a serious problem. Of course, with the variety of mission-critical servers and applications that are available on the Internet, DoS attacks can reduce more than revenue. They can hamper your ability to work and gather information. Simply put, denial of service attacks are irritating and time-consuming for everyone involved.
Types of DoS attacks
There are several different types of DoS attacks, including attacks against network hardware, base Linux networking, and Linux applications. Let’s take a look at some of these types of attacks.
Attacks against network hardware are pretty generic. One common attack occurs when attackers send connection requests from forged or non-existent IP addresses. Since these IP addresses aren’t reachable, the receiving system can’t resolve them. The session may hang, which can affect a single service or port or possibly the entire server. Another attack occurs when an attacker exploits overflows in login routines (usually called buffer overflows); this attack causes the server to crash or reboot. Finally, attackers can flood the server with improperly formed or strange packets. The server will lock up because it can’t process them correctly.
Attacks against base Linux networking capabilities are more prevalent, especially when a known exploit exists. There have been a number of cases in the past in which problems in networking code have been exploited and subsequently fixed. Since I can’t list all of them, I'll discuss some of the consequences that have resulted from these exploits.
The most common exploits occur because of improperly written source code. One exploit is the IP fragmentation cache attack, which can kill IP connectivity. It usually happens when a 0-length IP fragment is received and confuses Linux. Linux won’t release the fragment; instead, it keeps the fragment in the cache. The IP cache is limited to 4,096 simultaneous entries. When the cache is full of these IP fragments, Linux can no longer process incoming packets. Linux begins to deny services. There are a number of other exploits that are based on IP fragmentation. Some exploits are based on IP packet size or on oversized IP packet fragmentation.
Another type of exploit is the ICMP flood attack. It’s not limited to Linux; it can affect all other operating systems. Here, the attacker sends a storm of ICMP packets to the server from a forged IP address (which is usually the target's own IP address). Then, the ICMP request is broadcasted to multiple hosts on the server's network, which, in turn, will flood the server with replies. This type of attack can become particularly devastating if the server's network has a number of other hosts. The number of replies would increase dramatically. Eventually, the high volume of responses would shut down the target server.
A very popular DoS attack is known as the Ping of Death. Some previous versions of Linux were susceptible to oversized ping packet attacks that would crash the system. Typically, the ping utility sends out 32-byte packets, which can be handled easily. Most servers can handle packet sizes from 0 to 65,500. Some will reject packets that are larger than 65,500 bytes, but some won’t. If not, they provide the attacker with a successful Ping of Death attack. This particular attack isn’t dangerous to recent Linux versions, but they still become problematic. If this flood of ping packets doesn’t shut your server down, it will certainly slow the server down. Imagine a high-speed source that delivers packet upon packet to a slower-speed server. The high-speed source has plenty of bandwidth to work with, but the slower server doesn’t. Thus, the server will have reduced bandwidth and won’t be able to establish any other connections.
Finally, there are the Linux network application attacks. These exploits are based on faulty end-user applications, such as Netscape or FTP clients. Usually, these exploits don’t pose much of a problem, and the author of the affected package can fix the problem quickly.
What can you do?
So, how do you defend against denial of service attacks? Unfortunately, there’s no generic or foolproof way to protect yourself from a DoS attack. There are some very good guidelines that will reduce the possibility of being susceptible to such an attack, but they’re not guaranteed working methods. The first thing that you can do is disable broadcast addressing by issuing:
ifconfig eth0 -broadcast
Second, you can filter incoming ICMP, ping, and UDP packet traffic with the firewall code in the Linux kernel. This code is called ipchains in the most recent version. Ipchains provides you with several ways of building a firewall to keep unwanted or suspect packets out of your system and of preventing your system from ever initiating an accidental attack (like a Ping of Death) on another system. For example, accepting error ICMP packets is a good idea, but they might be all that you want to accept. To make that distinction, you would type something like the following:
ipchains -N icmpacc
ipchains -A icmpacc -p icmp --icmp-type destination-unreachable –j
ipchains -A icmp-acc -p icmp --icmp-type source-quench -j ACCEPT
ipchains -A icmp-acc -p icmp --icmp-type time-exceeded -j ACCEPT
ipchains -A icmp-acc -p icmp --icmp-type parameter-problem –j
Creating and using ipchains
First, you’ll want to create a new ipchains chain, which we’ll call icmpacc. The next four commands (as shown above) add rules to our new chain. These rules tell ipchains to accept the specified ICMP error packets (which are useful in programs like ping). If any ICMP packets come through that don’t match any of these rules, control will be passed back to the calling chain (usually the input chain). If you want to deny all incoming ping and ping replies, you could type:
ipchains -A input -i eth0 -p ICMP --icmp-type ping -j DENY
ipchains -A input -i eth0 -p ICMP --icmp-type pong -j DENY
If you have a router that supports TCP interception, use it. The TCP interception feature allows the router to intercept and validate TCP connections. Connections that fail to resolve after a reasonable time frame are dropped—as are connection requests from unreachable hosts. In either case, the server will be reached only by valid and fully available connections. Finally, use the filtering code in ipchains to drop suspicious source addresses; it will provide you with a defense against spoofed IP addresses. Your server should never accept packets from the Internet that claim to originate from inside your own network, and you might want to prevent incoming connections from reserved addresses like 172.16.0.x and 192.168.x.x, as shown below:
ipchains -N no-local
ipchains -A no-local -i eth0 -s 192.168.1.0/24 -l -j DENY
This code creates a new ipchains rule called no-local. To this rule, add a command that logs and denies packets on the eth0 interface from the source address of 192.168.1.0/24 or 192.168.1.0/255.255.255.0 (which is a range of IP addresses from 192.168.1.0 to 192.168.1.255). Of course, I’m assuming that your local network uses the 192.168.1.x reserved IP address range.
For more information on ipchains and protecting your system, take a look at the manual pages (man pages) for ipchains by typing man ipchains. These pages will give you a good idea of the commands that you can use in order to build a good firewall on your Linux server and to protect yourself from attack.
There are many sites on the Internet that deal with preventing DoS attacks on Linux servers and building proper firewalls that will secure your system from a DoS attack. The sites listed below will provide you with several good starting points for securing your Internet server and protecting yourself from any kind of attack (whether DoS or otherwise).
- Denial of Service Attacks on any Internet Server Through SYN Flooding: Tom Kermode offers an overview of SYN flooding and makes some suggestions for preventing the problem.
- Strategies to Protect Against Distributed Denial of Service (DDoS) Attacks: Cisco provides a good overview of DoS and DDoS attacks and suggests ways of preventing them.
- Preventing Smurf Attacks: NORDUnet provides an overview of Smurf attacks and how to prevent them. (Smurf attacks are another form of DoS attacks.)
- Linux IPCHAINS-HOWTO: Paul Russell wrote a standard HOW-TO document that explains how to make the most use of the ipchains code in the Linux 2.2.x kernels.
- Firewall and Proxy Server HOWTO: Mark Grennan wrote another standard HOW-TO document that details firewall and proxy configuration and installation. It contains a lot of good information that will help you set up a proper firewall and prevent your system from being hit by various DoS attacks.
- BugTraq: This mailing list about Linux security is one of the most important mailing lists to which a systems administrator can subscribe. BugTraq will alert you to any security holes in your Linux system, and it will give you the information that you need in order to repair the problem.
- CERT Coordination Center: This site is an excellent source of information on security. CERT studies Internet security vulnerabilities and provides incident response services to sites that have been attacked. To improve site security, CERT also publishes a variety of security alerts, security research, and developments in information.
Since new DoS attacks surface on a regular basis (usually one or two every few months), the best way to protect yourself is to keep up-to-date on security advisories and patches for your programs. You may want to learn about new program versions; however, doing so can become a double-edged sword. New versions may fix past exploits, but they introduce new ones. Paying attention to security announcements from the vendor of your Linux distribution is more effective.
If you find out about a new attack and then you upgrade to a new version or patch level for a particular service, pay close attention to security mailing lists and newsgroups for at least three weeks after the attack is announced and fixed. That way, you’ll give the various communities of hackers and crackers enough time to study the new attack's code and modify it further; sometimes, they create new modified attacks on the same application.
The best advice for preventing DoS attacks is to stay alert. Know your system and know what you’re running. Keep your eye on the available security sources and know what does and doesn’t affect you. Minimize your services to only those services you need. You can't be attacked on a service that you don’t run. Administrators who don't pay much attention to their systems and environments will eventually fall prey to some kind of DoS attack. Administrators who understand their systems, however, are much less likely to be affected by these malicious attacks.
Vincent Danen, a native Canadian in Edmonton, Alberta, has been computing since the age of 10, and he’s been using Linux for nearly two years. Prior to that, he used OS/2 exclusively for approximately four years. Vincent is a firm believer in the philosophy behind the Linux "revolution,” and heattempts to contribute to the Linux causein as many ways as possible—from his FreezerBurn Web site to building and submitting custom RPMs for the Linux Mandrake project. Vincent also has obtained his Linux Administrator certification from Brainbench .He hopes to tackle the RHCE once it can be taken in Canada.The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.