Phil explains how to write a scalable SNMP Trap and Inform message receiver in Java using SNMP4J. He also explains what SNMP is and surrounding ideas such as TCP and UDP.
Slowloris HTTP DoS Attacks
Today, the other admin of Matthouse Hosting came to me with a serious concern. He was able to single handily bring down Matthouse and the entire infrastructure that I have spent countless hours on securing. After learning a little about this attack he used, I was able to successfully bring down other major sites that run on Linux based servers, which makes me wonder how old this attack really is and how well known it is. Naturally, it is a major security concern when a system administrator like myself finds out how easy it is to completely bring a network server to its knees, so I immediately dropped everything and began researching a solution to the problem. In the process, I decided it would be beneficial to blog about what I’ve learned.
A typical DoS attack works by sending TCP/IP packets to the web server in massive quantities. These packets of data clog the lines that run to the server and cause it to overload. Think of a typical DoS attack as a couple hundred of people knocking at your front door at once asking something from you. You will be naturally overwhelmed and give up entirely. Servers are not any different when subjected to these attacks. Although there are no real prevention tips for these kinds of attacks, there are special routers that can reroute these attacks to black holes causing the service to never go out entirely. Depending on the network capacity, any server on that network may exhibit slow connectivity. The datacenter that hosts Matthouse experiences huge DoS attacks about 5 to 6 times a year and during this time, some of our servers are entirely unreachable.
DoS attacks tend to be caused by lots of hackers going after a certain site / service that they don’t like. For example, often on Internet Relay Chat (IRC), hackers get mad at other hackers and they use their networks of compromised computers to send packets to the service, bringing it down. DoS is by far the hardest type of attack to prevent, and admins such as myself dread them. Matthouse has some redundancy, but I doubt it could handle a large scale attack without at least some period of downtime, then again, many smaller networks couldn’t handle a large scale attack, so Matthouse isn’t alone.
Moving on, The Slowloris attack (located at: http://ha.ckers.org/slowloris/) is classified as a special kind of Denial of Service (DoS) attack on a web server. This attack works by sending partial request packets to the web server to request data in return. It sends fully constructed internet packets so it doesn’t clog the network, but the packets it sends are not fully constructed, and the web server thinks that data is missing so it requests a resend of the packet. Normally the web browser will send a full request again and the server will complete the request. Notice that the server never drops the initial connection for a period of time.
The idea of slowloris is to send incomplete packets at specified intervals to take up all the available slots of a web server, thus effectively making the server wait for that single client. It is basically an attack that makes the server sit there and wait for a full request instead of freeing its resources to handle other people who may want a page from it. Usually web servers only have enough open slots to fill up 512 requests or about there. So if you can get a single computer to utilize all of these resource openings, you can block service to everyone else. The cool part is that the server logs will not note anything suspicious because the requests are legitimate, just incomplete. Once the attack is finished, the log file will show a bunch of 400 errors for bad requests. When this attack is stopped, the server will return to normal within seconds because servers don’t wait a long time before giving up on the connection.
So what exactly is affected? I’ve found that all of my Linux based servers which run the Apache web server are vulnerable to this attack. To my surprise, both of the Microsoft Windows Servers running Internet Information Services (IIS) were NOT susceptible to this attack, likely because they wait for a complete request before responding to it. I’ve also read that lighttpd isn’t affected in this type of attack.
Now for the fun part, the solution. Justin beat me to the punch line, but his solution is very effective at protecting all of the servers that we manage at Matthouse and Amphosted. Both of us run updated versions of CSF and LFD (http://configserver.com/). With CSF, there was a very simple configuration directive that can be added to the configuration file that effectively blocks this attack. You should add the following to your configuration file for CSF (on the appropriate line) “PORTFLOOD = “80;tcp;20;5″”. After testing the server for this vulnerability again, CSF effectively blocked the attacking server, thus fixing the vulnerability.
Hopefully you can protect your servers from what I have learned. I’ve found several major websites that are vulnerable to this attack!