Slowloris and Nkiller2 vs. the Cisco CSS load balancer

Today I spent most of my time analyzing the Slowloris and Nkiller2 denial of service (DoS) tools together with my colleague Gert Kremer.

Slowloris (name after the slow moving primates is a httpd DoS tool written by RSnake of ha.ckers. It works by tying up the httpd worker processes by slowly sending more and more headers of an httpd request.

Nkiller2 is a TCP/IP DoS attack tool which was published in issue 66 of Phrack magazine. It works by tying up httpd worker processes by requesting a file then stalling, mimicking the behavior of a client with full TCP/IP receive buffers.

Cisco CSS is a load balancer produced by Cisco.

In nearly all of the infrastructures built by my employer Schuberg Philis, the web servers are located behind a load balancer. In most cases a Cisco CSS. Because some of our customers were worried, I set out together with my colleague Gert Kremer to see if having a CSS load balancer in front of the web server provides any protection.

Slowloris
First we just had to try and find out what Slowloris did with an unprotected Apache server. The first video shows what happens when you run slowloris against a webserver. The window on the top left shows the number of apache processes, the top right window shows the scoreboard. This shows what the http processes are actually doing. The bottom window shows the slowloris output.

Slowloris vs Apache (No load balancer)

When slowloris is using 100 sockets, you can see 100 httpd workers in state “R”, meaning it is reading requests. The same is the case when running with 200 and 250 sockets. When running with 300 sockets the apache worker processes pool is exhausted and the web server can no longer service requests.

Slowloris vs Apache behind a Cisco CSS load balancer

Slowloris is running against the webserver with 3000 sockets (should be more then enough). As you can see on the top two windows the load balancer does not forward any of the incomplete requests to the webserver. We have stress tested the loadbancer up to 10,000 sockets and it had no effect on the loadbancer.

NKiller Nkiller vs Apache (No load balancer)
In the video we see for windows. Top left and right show the number of apache processes and the apache dashboard. The middle window displays the NKiller output and the bottom window TCPdump. When NKiller starts we see the it exhausts the httpd workers processes by putting them in a state where they are hanging while writing their reply back to the client.

Nkiller vs Apache behind a CSS load balancer
When NKiller was used against a server protected by a Cisco CSS load balancer the packets received from the load balancer do not match the expections of the Nkiller tool and the tool crashed producing a segmentation fault.

14 Comments

Dennis
Good stuff Frank + Gert.

Good to hear that the Cisco CSS mitigates this DDOS risk introduced by these tools. I'll update the corresponding ITSEC ticket for our customer resp inform them about your findings.

Again, excellent work gents!
Trey Guinn
Nicely done, guys!
mnomic
Ennioac
Hi Frank and Gert, I understand that the Cisco CSS is immune (wonderful work I might add!) but did the CSS need to be tweeked at all or was is a basic config?

Again, awesome work! :) Thanks and take care.
Ennio
Pozor na závažnú zraniteľnosť Apache-u!
[...] Cisco CSS (potvrdené komunitou) [...]
Ryan
<a href="#comment-10" rel="nofollow">@Ennioac </a>
Cisco CSS must have a front side delayed binding configuration applied the the HTTP content rule, this can be accomplished by putting a url in the content rule, for example:
content site_80_load_balanced
vip address 10.88.55.2
protocol tcp
port 80
url "/*"
add service server1
add service server2
active

If you have a SSL passing through your CSS to an Apache based server (and there are more than you think, for example IBM has a few!) you can configure back-end ssl on the CSS, refer to http://www.cisco.com/en/US/products/hw/contnetw/ps792/products_configuration_example09186a0080220dab.shtml
Motoma
Interesting findings.

RSnake mentioned in his article that HTTPReady was originally considered to be a tool for mitigating the SlowLoris attack because it holds connections until full requests come through. The way SlowLoris gets around this is by issuing POST requests instead of GET. To do this, you only need to enable the -httpready flag in SlowLoris.

It would be interesting to see how the Load Balancer handles POST requests. POSTs are different, because they can contain large amounts of data; were the Load Balancer to buffer these, one could overwhelm the it by sending a large number of big POSTs.
Slowloris HTTP DoS - .:: tt ::.
[...] Cisco CSS (verified by user community) [...]
Ryan
<a href="#comment-25" rel="nofollow">@Motoma </a>
I used the -httpready switch with slowloris against a CSS configuration with Delayed Binding, and the HTTP Request still does not make it back to the Apache HTTP Server, I looked at the HTTP Request Header and the HTTP Method is the only thing that changed with the -httpready switch.
Reeza
Hey all, would I be right in concluding that this would be effective whether slowloris or similar attack tool were used by one attack source or many (i.e. Distributed DoS using a botnet)?
Financeportal.eu &raquo; Blog Archive &raquo; Pozor na závažnú zraniteľnosť Apache-u!
[...] Cisco CSS (potvrdené komunitou) [...]
Barrapunto | slowloris: Ataque de denegación de servicio para Apache 1.x &laquo; El camello, el Leon y el niño. O la evolución del perro al lobo
[...] Cisco CSS (verified by user community) [...]
My Personal Diary &raquo; Blog Archive &raquo; Slowloris HTTP DoS Attcak
[...] Cisco CSS (verified by user community) [...]
nixmicrosoft &raquo; Blog Archive &raquo; Slowloris HTTP DoS
[...] Cisco CSS (verified by user community) [...]

Not Published

0/1000 characters
Go Top