Home > Cisco, Networking, Security > Slowloris and Nkiller2 vs. the Cisco CSS load balancer

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)
YouTube Preview Image

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
YouTube Preview Image

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)
YouTube Preview Image

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
YouTube Preview Image

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.

  1. Dennis
    June 22nd, 2009 at 23:19 | #1

    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!

  2. Trey Guinn
    June 23rd, 2009 at 10:15 | #2

    Nicely done, guys!

  3. June 23rd, 2009 at 13:55 | #3
  4. Ennioac
    June 24th, 2009 at 17:56 | #4

    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

  5. Ryan
    June 26th, 2009 at 19:10 | #5

    @Ennioac
    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

  6. June 27th, 2009 at 14:28 | #6

    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.

  7. Ryan
    June 29th, 2009 at 18:23 | #7

    @Motoma
    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.

  8. Reeza
    July 2nd, 2009 at 09:54 | #8

    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)?

  1. June 25th, 2009 at 02:35 | #1
  2. June 28th, 2009 at 05:52 | #2
  3. August 25th, 2009 at 11:42 | #3
  4. August 28th, 2009 at 16:29 | #4
  5. November 26th, 2009 at 16:58 | #5
  6. April 5th, 2010 at 05:01 | #6