3

The last two days our Tomcat 5.5 Linux-based webserver has been broken down within minutes by starting thousands of downloads and stopping them. Some request paths in the access log end with a "?jfkdsjkfsdk"-like part. Is there a known vulnerability of Tomcat systems for such attacks?

Update: We are currently running pure Tomcat, no Apache.

Mike L.
  • 131
  • 1
  • 4
  • Can you capture the full headers of a request? That should help to determine the nature of the attack. – Shane Madden Sep 30 '11 at 15:12
  • We have just now updated logging, so I can't provide any details on request headers, but just the following: attack was performed from only one IP address and worked by requesting always the same binary file in regular intervals, sometimes multiple requests per seconds, sometimes a pause of a couple seconds. Tomcat has logged sent byte count between 18 and 32K and HTTP status code 206. – Mike L. Sep 30 '11 at 18:28

4 Answers4

3

Connecting thousands of times is a known "vulnerability" of any server with a maxconnections setting (or which uses a lot of resources per connection). As a DDOS, most likely they're not "stopping" the download, they're just cutting the connection without so much as a RST packet so the connection hangs around until it times out or using something like trickle to only acknowledge a few bytes at a time to keep the connection from timing out.

Anything you do to mitigate this will depend on your entire setup. Assuming you are currently using apache+mod_jk+tomcat, then in addition to Bart's fail2ban, I would look into mod_security to detect the possibly malicious requests and refuse them. Another idea is if you really are using tomcat to send static data, moving the static data to be served directly from apache (or a lightweight server like lighttpd or nginix) using a static.example.com domain. Or, if you need to have your code decide which file to send, consider using mod_xsendfile in apache to serve static files "pointed to" by your app, which would let tomcat finish the request and move on while apache handled the file (rather than keeping both apache and tomcat busy sending the file).

DerfK
  • 19,313
  • 2
  • 35
  • 51
3

Based on the 206 responses, your Tomcat server is being attacked with an overlapping range attack, as described against Apache in CVE-2011-3192.

When this was a hot topic last month, it seemed to me that Tomcat's default servlet looked vulnerable - see here.

The best ways to stop this would be to stop letting these static files be served by the default servlet, or to strip the Range: header off of incoming requests.

Community
  • 1
Shane Madden
  • 112,982
  • 12
  • 174
  • 248
  • You said, this issue is reported against Apache, but we are not using Apache, but only Tomcat. Would your suggestion mean to disallow downloads using a download manager which usually downloads multiple segments of a file at one time? – Mike L. Oct 01 '11 at 06:51
2

Are you proxying to Tomcat from Apache? If not you can be pretty easily vulnerable to attacks like Slowloris. It's a somewhat bad idea to publicly expose Tomcat.

Even if you are proxying through Apache, you need to be careful that you protect against Slowloris-esque attacks using mod_antiloris, or better yet use nginx for your frontend proxy, a server shown to be invulnerable to the Slowloris attack.

Shane Madden has a better answer, take his advice first.

Xorlev
  • 1,845
  • 14
  • 12
  • What do you think is easier to set up - Apache or nginx? – Mike L. Sep 30 '11 at 18:27
  • nginx, it's incredibly simple. – Xorlev Sep 30 '11 at 19:44
  • When using nginx as pure proxy to tomcat (i.e. all requests, even to our download files will be forwarded to tomcat), can nginx still protect us from slowloris-like attacks, Apache CVE-2011-3192-like attacks, ...? – Mike L. Oct 03 '11 at 08:23
  • We have installed `nginx` now but get now a strange ABE warning from within Firefox/Noscript: `Request { GET http://localhost/.... <<< http://our-domain.com/...., http://our-domain.com/foo/bar - 6} filtered by ABE: Deny`. What could this mean? – Mike L. Oct 05 '11 at 06:57
1

I don't know of one, but doesn't mean there isn't one. Use something like fail2ban to search logs for these requests and ban the IP's automatically.

You can also work on implementing resource/quota limits to limit download requests, proxy/caching to mitigate the load, and alerts to notify you of when this is happening. Along with throttling our outgoing requests, because even if you weren't being DDoS'ed you don't want legit requests to overwhelm your available bandwidth.

Most vulnerabilities would be to "own" your server; crashing/ddos'ing it is counterproductive in that regard. The only reason to kill the server, really, is if someone has an axe to grind against your company.

Bart Silverstrim
  • 31,092
  • 9
  • 65
  • 87