-----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. - -chris [0] http://en.wikipedia.org/wiki/The_Club_%28automotive%29 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUtrpnAAoJEBzwKT+lPKRYqW0P/0cSN1nyLwzVJZ2yBGoVmH3H MPsDjxnB/WFIvLtuDq2jGzerpzC4d//6kCxY6D2IxyPTXVLYABsvVA4A1WU4fnIB 5RJPFSf3U5MytpUbeXUGKv2J7nOF5kIGPIydpz7XTex+t+y8RGyPrfl6s2wLadIV LtPCI1Wje8By2UcIlLu4JMQXE6jLiXirW5/UgvwOiNq/92QCUSBilmn591yjjYtL WCLSOCcVsRtHnckjrLSXPLXEMAT2qVMFwdYgwT0AgyuuzRCZ6HAcuPzou6BXmJXx Uqhc34NzVYZ2lHSCLx8ZvYrJLlRPSAl0XQ70wwnX1DpmJfXOwdSqCXJTXv2/lpT7 CGPyN+n7EYIivP2zV04Iksp5vLu/8xTqzgkew5QOgCbviKZs9krDm+HbbCKA/dHp su9Bo/2Bo1OFgNEzyBsSWTuiKTAHt2yIunQw61YdWa5RpkMtXZ3kzrni9zaeNnas dxrxtlbCk44i5i09v6F/+lvgTRfu5zbp3qBtvlTirkWQhBhjiD5+XUMFPC6695Ih QMba6yc4JlKRy3JYpulNr8eXFPb8hT9FxNxf/367++FQso12VM5uPBOcizt9vToJ b6v+GEFAIhM3g8vsVfxSZxhMAslkBP0d8mKpMtnNSsaL2lkxWDLp9jDB6ZhoejMm VgYrKKu+mbvyN0VOkypt =s7hV -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
