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