16

I'm using Apache Tomcat 7 to run my webapp on Linux. I scanned it by Acunetix and it's telling me that my webapp is vulnerable to "Slow HTTP Denial of Service Attack". How can I protect it?

Acunetix is reffering me to here, but it's about securing Apache, not Tomcat.

boly38
  • 103
  • 2
Amin Sh
  • 263
  • 1
  • 2
  • 7

5 Answers5

13

A CVE has been assigned specifically for this issue as it applies to Apache Tomcat: CVE-2012-5568. More appropriate references there than the one you were given.

The Tomcat developers do not consider this to be a vulnerability, and have no plans to fix.

Potential solutions:

  • Use firewall rules to prevent too many connections from a single host. This will mitigate run-of-the-mill Denial of Service attacks but not distributed ones (DDoS).

    Here is an example of an iptables command which can be used to limit the number of concurrent connections that can be established to port 80 from a single client host:

    # iptables -A INPUT -p tcp --syn --dport 80
    -m connlimit --connlimit-above 50 -j REJECT

    https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2007-6750

    This would, however, have side-effects if many users were legitimately connecting from a single IP (e.g. mega-proxy), so the number of connections would need to be tuned reasonably - dependant on the traffic expected.

  • Unfortunately, the best option is to place the Tomcat service downstream from a web server that can better handle HTTP connections, such as Apache. Then use an Apache solution such as mod_reqtimeout or mod_antiloris.

itscooper
  • 2,230
  • 13
  • 15
8

There is an Apache module which applies some heuristics to (try to) detect the "slowloris" attack and to counter it. It is called mod_antiloris (this is a module for Apache, not a module from the Apache Software Foundation). See this answer for details.

Remember that, like for all Denial-of-Service attacks, there is no solution, only mitigations.

Community
  • 1
Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • 2
    Tom, instead of mod_antiloris I have found mod_security perform a lot better for slow dos mitigation. Another advantage is that mod_antiloris specifically work against slow dos while mod_security as an extensive signature and anomaly detection database. Instructions are given at http://blog.spiderlabs.com/2012/01/modsecurity-advanced-topic-of-the-week-mitigation-of-slow-read-denial-of-service-attack.html – void_in Sep 18 '13 at 16:36
  • 3
    @Tom Leek , void_in : Thanks, but I mentioned that I have this problem with Tomcat, not Apache. How can i mitigate Slowloris attacks against Tomcat? I don't even have Apache(httpd) on my linux server! – Amin Sh Sep 23 '13 at 11:35
  • 1
    @AminSh you could run Apache (or nginx) as a reverse proxy (so Tomcat runs on localhost:1234, nginx on port 80/444, and then relays connections). The configuration is easy and only a few lines. As a bonus, if there are static resources being served, you'll get better performance from nginx caching, too. One thing to be aware of: Tomcat apps won't see the original client IP, since connections will come from localhost. You'd have to add a header containing the real IP if your app needs that. – MichaelGG Mar 07 '14 at 07:36
4

Note that Tomcat is part of the Apache Foundation, so technically it's called Apache Tomcat. However, the traditional Apache webserver (officially called "The Apache HTTP Server Project") is frequently referred to simply as Apache. Below, "Apache" refers to the Apache HTTP Server, and not Tomcat.

Tomcat typically doesn't run as a webserver, it runs as an application server. If Tomcat is directly exposed to the Internet (without being teamed up with Apache), then your solution should be one of the following:

  • Set up a reverse-proxy server in front of Tomcat, such as Nginx, Lighttpd, or even Apache.

  • Set up Apache and Tomcat together as traditionally configured.

If you use Apache in your solution, then you'll also need to use a slowloris mitigation stragegy. There's mod_antiloris, which will do that for you as described in the article you linked. And there's also mod_reqtimeout, which depsite being part of Apache Core is often not included by default in Apache installations.

mod_antiloris works by limiting the number of simultaneous connections a given IP can create.
mod_reqtimeout works by limiting the amount of time a single request can stay idle.

Both have their place, and a good defense will probably employ both.

Also, the mpm_event Apache worker configuration works the same way as other servers, such as Nginx, Cherokee, and lighttpd, and is not susceptible to the Slowloris attack. This is available on most modern installations, but is marked "expermental". In paritcular, it may not be compatible some older modules that rely on the thread-per-connection concept. An often-cited example is mod_php, though that may not apply to newer versions.

tylerl
  • 82,225
  • 25
  • 148
  • 226
2

do you have apache (the webserver) infront of your tomcat? if so -> upgrade. apache isnt vulnerable to slowloris since 2.2.16 IIRC, and 2.2.16 ships with debian squeeze, that is oldstable.

if you dont have a reverse-proxy infront of your tomcat: use one, preferable varnish or nginx.

for reasons to use a reverse-proxy see this answer @ serverfault

Community
  • 1
that guy from over there
  • 3,476
  • 17
  • 26
1

Here is a solution. This will not affect people using a proxy. Apache tomcat team does not consider this a vulnerability in tomcat or plan to release a patch. This code will stop other ddos attack methods as well. ps I did not write this.

BLACKLIST=cat /usr/local/AS/etc/blacklist.txt

for i in $BLACKLIST; do iptables -A INPUT -p tcp -m tcp --dport http -s $i -j DROP done

-# IPs which will never be refused - partner hosts

WHITELIST=****INSERT YOUR PERMANENT WHITELIST IPS HERE ******

for i in $WHITELIST; do iptables -A INPUT -p tcp -m tcp --dport http -s $i -j ACCEPT done

-# don't lower too much - browsers open multiple connections

OVERLIM_NEW=500
-# overall limit for new connections per second
INDILIM_NEW=30
-# limit for individual IP, new connections per second - prevents floods
INDILIM_CURRENT=200
-# limit for individual IP, total connections - prevents overusage
CURRENT_EVAL_INTERVAL=300
-# interval length for IP usage evaluation

iptables -N LIMIT_INDIVIDUAL_NEW
iptables -N LIMIT_INDIVIDUAL_CURRENT
iptables -N LIMIT_OVERALL_NEW

iptables -A INPUT -p tcp --dport 80 -m state --state ESTABLISHED -j LIMIT_INDIVIDUAL_CURRENT
iptables -A INPUT -p tcp --dport 80 --syn -m state --state NEW -j LIMIT_INDIVIDUAL_NEW

iptables -A LIMIT_INDIVIDUAL_CURRENT -m recent --set
iptables -A LIMIT_INDIVIDUAL_CURRENT -p tcp --tcp-flags FIN FIN -m recent --remove
iptables -A LIMIT_INDIVIDUAL_CURRENT -m recent --update --seconds $CURRENT_EVAL_INTERVAL --hitcount $INDILIM_CURRENT -j DROP
iptables -A LIMIT_INDIVIDUAL_CURRENT -j ACCEPT

iptables -A LIMIT_INDIVIDUAL_NEW -m recent --set
iptables -A LIMIT_INDIVIDUAL_NEW -m recent --update --seconds 1 --hitcount $INDILIM_NEW -j DROP
iptables -A LIMIT_INDIVIDUAL_NEW -j LIMIT_OVERALL_NEW
iptables -A LIMIT_OVERALL_NEW -m limit --limit $OVERLIM_NEW/second -j ACCEPT
iptables -A LIMIT_OVERALL_NEW -j DROP

Tim Jonas
  • 807
  • 1
  • 7
  • 19