Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
On 1/14/15 5:56 AM, André Warnier wrote:
Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Jesse,
On 1/13/15 6:29 PM, Jesse Barnum wrote:
I need the ability to examine the POST data from a request,
examine it, and either respond to it or close the connection
without returning any result, not even a 200 OK status.
The reason for this is because I’m getting overwhelmed with
thousands of invalid requests per second, which are racking up
bandwidth fees. The requests can’t be traced to an IP address,
so I can’t just block them in a firewall or Apache - I need to
actually use logic in my Tomcat app to figure out which
requests to respond to.
Is there a way to force Tomcat to just drop the connection and
close the socket without sending a response?
You can't close the stream form your code, Tomcat will ignore it,
so a response flush, and return a 200 response anyway.
I'm curious, what's wrong with an empty 200 response? It's only
a couple of bytes, but I suppose if you are getting millions per
hous, you could still incur bandwidth costs...
You might be able to do this with a Valve, but then you might
have problems with your web application needing to provide the
logic to determine whether or not to accept the request.
When you say "can't be traced to an IP address" do you mean that
you are seeing invalid requests coming from all over the place,
or that the requests don't include a source IP address (which
seems fishy)?
A few options that might achieve your goal without using the
technique you describe:
1. Use client authentication; unauthorized clients can't even
handshake Downsides: SSL overhead
2. Use a VPN (which essentially uses client authentication)
Downsides: VPNs really, really suck
3. (As Mark E suggests) Use mod_security with httpd I know this
will seriously separate your business logic form your web
application, but perhaps there is a simple set of criteria that
might eliminate a significant portion of the requests, thus
solving the problem "well enough"
I have an additional suggestion, harking back to a time when I was
trying to convince the Apache httpd devs to implement something
like this in .. Apache httpd. By experience with trying to convince
people, I know that this is controversial, so hold on tightly and
follow the gist. You can always decide by yourself if this is
appropriate for your case.
The idea is this : when you get such a request, and you decide that
it is invalid, return a 404 "not found", but delay it by some
random number of seconds. (do a random sleep in your webapp, or in
a filter after the webapp).
This is essentially a reverse slowloris attack against the client. The
major problem is that it ties up resources on the server, which is the
whole problem you are trying to solve in the first place. In theory,
it's a good idea, but in practice, you are using system resources to
.. avoid using system resources. I'm not sure if the curve is linear
(your suggestion may be "cheaper" than simply doing nothing), but it's
certainly not a free lunch.
The short-term hope is that if attackers notic that your website is
such a "sink", they may just take it out of their list of targets,
so as not to slow down their whole nefarious scheme.
This is the club[0] effect: your server is marginally more of a pain
in the neck than someone else's, so they ignore you and attack others.
Yes, exactly.
And think about it : if this was a default (but optional) feature of Tomcat in general,
then after a sufficient while (e.g. the time for a significant portion of Tomcat sites to
upgrade to the newest release), the miscreants may notice that most Tomcat servers are
such pains in the a.., and start avoiding them altogether.
Seen from a Tomcat point of view, wouldn't that be nice ?
And (one can dream) imagine that most mainstream webservers were to adopt a similar scheme
over time, then the general method of blindly scanning a lot of IPs for weak webservers
would cease to be practical, and would be abandoned, to the general benefit of all the
Internet.
The default (but optional) feature in question would be : any 404 (not found) or 401
(forbidden) response is delayed by a random number of seconds (say between 1 and 100).
Enough to bother the miscreants and make their scanning uneconomical, but low enough so
that it is impossible for said miscreants to know whether this is intentional, or just a
slow server.
Although I am incapable of designing this myself, I believe that there must exist a way to
create a mechanism in Tomcat to apply this scheme at low resource cost to the server.
For example : as soon as it is known that the response to a request is 401 or 404,
actually sending out that response after the random delay could be forked out to some
separate pool of lightweight specialised threads, and the heavy thread handling the webapp
could be recycled immediately for more interesting things.
Of course this is taking us further and further away from the request of the original OP,
so I'll stop here and maybe start a new thread for this again.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
