Hello! So the other night I tried to learn some more about the Slow-Loris style of DOS attack. I couldn’t tell you much about EXACTLY how the original slow-loris.pl worked, but here’s what I found to be effective against an Apache2. I figured I’d go through the process of what I did to share some of the knowledge I gained through it. Plus, I thought it would be a nice and simpler first post.
So first of all, for those who aren’t a little bit familiar with the Slow-Loris type of DOS attack, the main point is that it is low-bandwidth, and only takes one computer running multiple threads. Alot of DOS/DDOS attacks revolve around sending an unmanageable amount of information to the server. This works, but also at the expense of the attacking resources. What is great about this kind of attack, and the Slow-Loris concept is that it does not use a ridiculous amount of bandwidth. Instead, it takes up all of the web servers possible connections. So let’s take a look at the server-status page of our Apache2 server while its running normally.
As we can see, the server is currently only handling one request. One important thing to know is that HTTP is considered a “connectionless” protocol. What this means is that a client will establish a TCP connection to an HTTP server, send its request, then the server will send its reply and close the connection. This makes sense, especially considering that a website may serve many people at once, and many concurrent socket connections can bog down a less capable box. Now suppose our goal is to halt this server from serving anyone. We might first think to send a bunch of UDP packets at random ports and try to take up as much resources from the server as possible, but the Slow-Loris type attack targets the server’s web-server software itself instead. Our goal, for the attack, is to take up all the allowed connections for the webserver, and keep those sockets connected for as long as possible. So let’s open up a connection with this server and see how long it takes before it closes our connection because we sent it no request. This can be done quickly and simple with netcat. Just open up a connection, send part of a request, and see how long it takes before the server disconnects us. We get the following html response.
408 Request Time-outRequest Time-out
Server timeout waiting for the HTTP request from the client.
Apache/2.2.22 (Debian) Server at 127.0.1.1 Port 80
For this particular Apache, it took about 20 seconds before the server sent us a “you took too long” html response. So, we know we can open a socket and connect, then waste about 20 seconds of the servers time before we get disconnected. So far so good, but we can do a little more to be more effective. We can send, as a header in the HTTP request, a “Keep-Alive” request. Keep in mind that it is up the server whether or not it wants to listen and follow our wish, but this is basically asking the server not to close our connection for a little while. I’m not exactly sure why this is implemented in HTTP protocol, but I believe it is for the better performance of some clients. You may want to read more on that if you’re interested. Also, if you want to learn more about HTTP in general, I suggest you check out the RFC documents, they proved useful to me. So let’s send a request with a keep alive header in there and see how it responds. Let’s fire up python and check it out. Here is the first part of the response we get.
HTTP/1.1 200 OK
Date: Tue, 24 May 2016 06:00:09 GMT
Server: Apache/2.2.22 (Debian)
Last-Modified: Fri, 15 Apr 2016 21:00:37 GMT
ETag: “1ff92-329-5308c4d87d9fc”
Accept-Ranges: bytes
Content-Length: 809
Vary: Accept-Encoding
Keep-Alive: timeout=5, max=100 <------------Important!
Connection: Keep-Alive <---------- Important!
Content-Type: text/html
We now know that this web server does indeed listen to Keep-Alive requests, and it will give us 5 more seconds until it closes our connection. Let’s implement that into our attack too. Here is a pastebin link to the python script I tossed together for this. Keep in mind, it is by no means refined, and I have made no improvements from the time it was written around 5-am 
Basically, it takes advantage of the keep-alive and how long it takes before the server closes client sockets to keep attacking sockets connected for a while. Also, for fun, it will send various user agents to the server. At least for this particular Apache, it took it over almost immediately. I hope you enjoyed reading this, and hopefully the script might give you a bit more knowledge about HTTP. Thanks! Of course, as you all already know, don’t go using it against some vulnerable public web server. (Note: I tried this also on an XMPP server running on Windows, and it disrupted it, but was not as effective since XAMPP doesn’t listen to keep-alive header requests)
PasteBin link : http://pastebin.com/ABdrzZtW
