Paid Advertising
web application security lab

Lighttpd and Slowloris

I had heard various different reports from people who use lighttpd during the initial investigation of slowloris that it was not vulnerable. But now I’m hearing differently. From Iraklis Alexios C. Mathiopoulos:

I just tested it on a fresh/default install of the latest lighttpd with a simple index.html page (no fastcgi this time). Consistent results, 4-5 seconds after I fire slowloris from host A to “attack” server B, server’s B is unresponsive. I’m checking from host C btw in order to minimize the risk of any dos appliances that might be in the way blocking requests. host A, server B, host C are all in different geographical locations.

As soon as I stop slowloris server B becomes responsive again. Interestingly enough top doesn’t show any change in cpu/mem usage during the attack.

Btw the targeted server is running Centos 5.4 64bit on an Intel i7 with 8GB ram.

Anyone have different results to share for lighttpd? About a year has come and gone and I haven’t heard any word from the Apache camp on a fix either. Anyone heard anything about a fix in Apache’s core web server?

6 Responses to “Lighttpd and Slowloris”

  1. StalkR Says:

    As for Apache it’s not fixed in the core but a module has been released: mod_antiloris

  2. ck01 Says:


    mod_qos for apache2 works good for mee. See:



  3. guly Says:

    that’s what i hate about IT. they don’t fix things, they just wrote an anti-something function and go to bed.
    the half-full-glass view is that this approach give us a lot of work for the future ;)

  4. Iraklis Says:

    +1 on mod_antiloris, works fine.

    Half-full is always cheaper in the short term.

  5. Damien Says:

    The official (integrated in the vanilla distrib since 2.2.15) module related to slowloris-like attacks is mod_reqtimeout (

    This module is enabled by default on Debian since 2.2.15-1 (

  6. flam Says:

    One of the first articles (if not the first) that came out on defending from the attack: