-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 André,
On 1/14/15 3:05 PM, André Warnier wrote: > 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. No, the resource cost is *very high* in terms of file descriptors. It's not uncommon to see a maximum number of file descriptors set to something like 1024. That means that, if your server isn't responding fast enough for an attacker, they can DOS you by opening 1024 connections to your server asking for "/foo.php?let-me-in"... all of which will sit there not doing anything. Now your server isn't worth operating any longer. IMO it's cheaper to return 400 or 500 or 403 or whatever and get on with your life. Or, if the server supports it, simply hang up the phone and not bother returning anything at all. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUts54AAoJEBzwKT+lPKRYD7EP/08wHHn6+WbkVlVYlPP8gBqg hsxI4EL6CrCf0yNLO8E1b0xt2BDHy7/FsUQ7tju3OhhT5ru4ach5y8OCeTm0BkFY AzgM78Zkke0hLHgPaTnK5TcMEpmwLNFou+tBmceuvU4qPzm9KsnBHqJwa5hS1Lgf G+4IiGc8wv16oAdmKa3Oamrpo6zCn8DsR9Io7jQNRxwlaOb29Ax5K2PlswyYa6GP VfEFKldaQMn1E9wM+my7Ii4pEk5RsjuzcwlqNjDkse/L1K6W8JspLwPHUGD0Dz18 ugYBb6cAwornO7jAY4nubdXmIbTEiRC0FGV0BSZpgowy+f8+5DM/MT057Ke7TOJ5 c8nqw3/8pURX0RKsKGYijqHY2vCJFT6Ja8ZC5/Y+QXFMJ7cDCVtQ8K8vJgFhtX4A 2tnPuJ1IDwQCfrFvFXY+rqiRf1homE/W9TWd9sZETSPNc6auVPYhlPP1KRYYEezm lv0Kamhfs0qqrl1Htn64AJwHKye4tdxyYwzNSF/FP3Uc1I/WNt1b2S25k+rJrZa9 YV4gudQJ8t1HgjOjCbGr8omTqsxsEE39/SnnQORvRsaKZRtGxmwvJGz+dgNii3rz +i/BR/WkrMmWxYoOvcxeH3umn/iivNRwo+hoG8VoxjR0Hp84fN0Ua0iInp6SJsdD g9VfeWEQ5S3AOp1lf4eT =jFon -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
