You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jesse Barnum <js...@360works.com> on 2015/01/14 00:29:01 UTC
Is there a way to abruptly force a connection closed without returning anything?
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?
--Jesse Barnum, President, 360Works
Re: Is there a way to abruptly force a connection closed without
returning anything?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a way to abruptly force a connection closed without
returning anything?
Posted by André Warnier <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a way to abruptly force a connection closed without
returning anything?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a way to abruptly force a connection closed without
returning anything?
Posted by André Warnier <aw...@ice-sa.com>.
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).
The rationale of this is as follows : most such requests - if not all - come from
automated nefarious agents, which try to break into your server (and others) by finding
some weakness.
They work on the base of a list of IP's (or hostnames) and use potentially many infected
hosts to issue such requests. When one of these agents does find a "hit" (a URL which
actually looks weak), it phones it back to Mamma, which can then mount a more serious
attack. The strategy works, because each missed request (to a well-protected server)
usually only takes a few milliseconds to send and get a response, so these agents can do
thousands of them in a reasonable timeframe.
But..
If it was so that each target took a long but unpredictable time to respond (only for
those bad requests), by a legitimate but slow response, then these agents would have a
major problem, because given the same attacking resources, they could only achieve a small
fraction of the probes that they intend to do.
And, this should not bother legitimate accesses by legitimate applications very much,
because these legitimate applications send overwhelmingly "good" requests (so they get a
normal answer time).
The only serious drawback (at least in my view), is that you have to provision on your
server a sufficient amount of response threads, to do this "sleeping" for bad requests,
while continuing to serve legitimate ones.
But it might be possible to design a clever scheme by which such sleeping webapp instances
would consume a minimal amount of resources while doing so.
(Mabe such as internally dispatching the bad requests to some special webapp which handles
this at low cost).
The long-term hope of course would be that if a sufficient number of webservers on the
Internet came to adopt similar practices, this type of robot scanning may become so
impractical for their originators, that it would be abandoned.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a way to abruptly force a connection closed without returning anything?
Posted by Jesse Barnum <js...@360works.com>.
> On Jan 16, 2015, at 10:38 AM, Christopher Schultz <ch...@christopherschultz.net> wrote:
>
>> This is for a license check phone-home server. Old versions of our
>> products had bugs that could cause them to endlessly make
>> phone-home requests as fast as possible. We need to examine the
>> POST data, check the product code parameter to see which product it
>> is, as well as a version parameter to see which version of the
>> product it is. We then consult a lookup table (hard-coded into
>> Java) to see whether to reject the request or respond to it.
>>
>> I would assume that is beyond the scope of configurable filters in
>> Apache, maybe I’m wrong?
>
> Apache httpd 2.4 has Lua built right into it. Perhaps you could
> knock-up a "filter" using that?
>
> Does your product not set a User-Agent header with a version number
> when phoning-home? Perhaps you should start doing that, then you could
> filter based upon HTTP headers instead of part of the message body.
>
> Another thing you might be able to do would be to have Apache httpd
> pull-out the data from the request body and pop it into a header,
> which Tomcat could check without processing the body. Something is
> still examining the body, but it will make your Java code simpler.
Thank you for the suggestion Christopher, that definitely makes sense.
Fortunately, I was able to come up with a different solution last night - the product (even old ones) have a frequency setting that I forgot about that can be used to limit how often they make requests. I originally designed it as a single server-wide setting for all clients to adjust overall server bandwidth, but by detecting the old buggy clients and sending them an Integer.MAX_VALUE for that frequency, I am able to effectively disable them. This has solved my problem.
--Jesse Barnum, President, 360Works
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a way to abruptly force a connection closed without
returning anything?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jesse,
On 1/16/15 9:02 AM, Jesse Barnum wrote:
>
>> On Jan 16, 2015, at 4:37 AM, André Warnier <aw...@ice-sa.com>
>> wrote:
>>
>> If you do have an Apache httpd front-end anyway, it still seems a
>> bit of a shame to have to use any Tomcat bandwidth and resources
>> in order to catch this kind of thing, and not be able to do it at
>> the Apache httpd level, before you even decide to proxy the
>> request to Tomcat. Apache httpd also has a lot of add-ons to
>> catch and deny things like obstreperous clients etc.. Are you
>> sure that there is nothing which you could "export" from Tomcat
>> to Apache httpd, to allow httpd to catch these unwanted requests
>> earlier ? (not necessarily all of them; but whatever you catch
>> there, saves resources in Tomcat).
>>
>> Some info, if it can be useful : unlike a servlet or filter in
>> Tomcat, Apache-based code does not necessarily "consume" the
>> whole request in order to examine for example some POST
>> parameters. So it can do that, and still proxy (or not) the
>> whole request to Tomcat if appropriate. It is probably a fair
>> bet, that many of these unwanted requests follow some kind of
>> general pattern that could be relatively easily filtered out
>> early, isn't it ?
>
> This is for a license check phone-home server. Old versions of our
> products had bugs that could cause them to endlessly make
> phone-home requests as fast as possible. We need to examine the
> POST data, check the product code parameter to see which product it
> is, as well as a version parameter to see which version of the
> product it is. We then consult a lookup table (hard-coded into
> Java) to see whether to reject the request or respond to it.
>
> I would assume that is beyond the scope of configurable filters in
> Apache, maybe I’m wrong?
Apache httpd 2.4 has Lua built right into it. Perhaps you could
knock-up a "filter" using that?
Does your product not set a User-Agent header with a version number
when phoning-home? Perhaps you should start doing that, then you could
filter based upon HTTP headers instead of part of the message body.
Another thing you might be able to do would be to have Apache httpd
pull-out the data from the request body and pop it into a header,
which Tomcat could check without processing the body. Something is
still examining the body, but it will make your Java code simpler.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUuTBgAAoJEBzwKT+lPKRYkhsP/Ay0rWa+C94kqz6fl2xtWyho
ffaxRI/CDHwMz9u5lW/eatM2yRGP+cQg3vZn4Sn1ip8yuMiB4HVOB/AfYslv7Z2V
eZy55CnTT0ywE1bOZGobT6Wu4uYInp8tBdPU2cZqKkWkwsgwpifwr3lPRD0B3EqB
f+xFWHVndumfwG5/zyFaJcycPuCcHgTF5m1hNaaQknhQzOPZd/sJxmjcyiEVaIDB
njJqcr97hF6SXoHRqmTktfHb2mPE71Sn7QYETRhzwGT+tXlZLQQCJW1PDWhf5k1Y
6w5AeKw7Geptu/VZ3B2D6dM3g8eM5Rtal+1JwktnlZoM/UdVwFIBLHEERIqFI7Qm
JGDY1HktqBY9T8gaF1iItkSCpo4uZxc8xzv5h9vp1dKYfOFCrEyws1Pyt/X7ZBiI
wJ/nqO767ElxN66v+p+4DUfLmcD2lqCWElbVAkUxDaMTYO1wiB7i9bTgoqkabUmg
vAAQSVCSCvokVwT4yZdn9Avg4nUAOU74USxJ9YM0hkDFE2Yh6NjJ9//2gbaeNDhh
Jwk9RRX/dok6glPBmGiBsmORjske7JxB3P9cr9wH/d2FacR2w4fxVYd0Rf1sAJVj
PvuXYGwMORVVcJ/VS+3KjqvSDJ45138q36Nc5Or4vMFK/Q//FoeU+jQUBQ3m3yAE
XPVp1F/LxWm/Twgs1YpG
=bqDu
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a way to abruptly force a connection closed without returning anything?
Posted by Jesse Barnum <js...@360works.com>.
> On Jan 16, 2015, at 4:37 AM, André Warnier <aw...@ice-sa.com> wrote:
>
> If you do have an Apache httpd front-end anyway, it still seems a bit of a shame to have to use any Tomcat bandwidth and resources in order to catch this kind of thing, and not be able to do it at the Apache httpd level, before you even decide to proxy the request to Tomcat. Apache httpd also has a lot of add-ons to catch and deny things like obstreperous clients etc..
> Are you sure that there is nothing which you could "export" from Tomcat to Apache httpd, to allow httpd to catch these unwanted requests earlier ? (not necessarily all of them; but whatever you catch there, saves resources in Tomcat).
>
> Some info, if it can be useful : unlike a servlet or filter in Tomcat, Apache-based code does not necessarily "consume" the whole request in order to examine for example some POST parameters. So it can do that, and still proxy (or not) the whole request to Tomcat if appropriate.
> It is probably a fair bet, that many of these unwanted requests follow some kind of general pattern that could be relatively easily filtered out early, isn't it ?
This is for a license check phone-home server. Old versions of our products had bugs that could cause them to endlessly make phone-home requests as fast as possible. We need to examine the POST data, check the product code parameter to see which product it is, as well as a version parameter to see which version of the product it is. We then consult a lookup table (hard-coded into Java) to see whether to reject the request or respond to it.
I would assume that is beyond the scope of configurable filters in Apache, maybe I’m wrong?
--Jesse Barnum, President, 360Works
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a way to abruptly force a connection closed without
returning anything?
Posted by André Warnier <aw...@ice-sa.com>.
Jesse Barnum wrote:
>> On Jan 14, 2015, at 12:29 AM, Konstantin Kolinko <kn...@gmail.com> wrote:
>>
>> 2015-01-14 6:28 GMT+03:00 Christopher Schultz > 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...
>> response.setHeader("Connection", "close") will cause Tomcat to close
>> the connection (i.e. do not use keep-alive that is default for
>> HTTP/1.1 requests).
>>
>> Response body may be empty but by default the response includes HTTP
>> status code and reason phrase and some headers.
>> Is that too much?
>>
>>> 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.
>> It can be implemented in two tiers:
>>
>> a) an application sets an attribute on request or uses some specific
>> status code on the response.
>>
>> b) a valve detects presence of the attribute or status code and closes
>> the connection.
>>
>> You have not mentioned your version of Tomcat.
>>
>> For a pointer, note the following enum value in the source code
>> (available in the current 7.0.x, 8.0.x):
>>
>> org.apache.coyote.ErrorState.CLOSE_NOW
>>
>> org.apache.coyote.ErrorState.isIoAllowed()
>>
>> Best regards,
>> Konstantin Kolinko
>
> Thank you very much for all the help. After reading all of these responses, I concluded that it was not that bad to just return an empty response, especially by using mod_header to se the server and date headers to empty value.
>
> I forgot to mention - I’m running Tomcat 7.052 with an Apache 2.2 front-end. I have a feeling that even if I did implement the Valve trick, Apache would still return some response to the user (likely an error 500 or 503 that the AJP connector had failed to respond), so returning a very small response from Tomcat is actually probably less outbound bandwidth.
>
If you do have an Apache httpd front-end anyway, it still seems a bit of a shame to have
to use any Tomcat bandwidth and resources in order to catch this kind of thing, and not be
able to do it at the Apache httpd level, before you even decide to proxy the request to
Tomcat. Apache httpd also has a lot of add-ons to catch and deny things like obstreperous
clients etc..
Are you sure that there is nothing which you could "export" from Tomcat to Apache httpd,
to allow httpd to catch these unwanted requests earlier ? (not necessarily all of them;
but whatever you catch there, saves resources in Tomcat).
Some info, if it can be useful : unlike a servlet or filter in Tomcat, Apache-based code
does not necessarily "consume" the whole request in order to examine for example some POST
parameters. So it can do that, and still proxy (or not) the whole request to Tomcat if
appropriate.
It is probably a fair bet, that many of these unwanted requests follow some kind of
general pattern that could be relatively easily filtered out early, isn't it ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a way to abruptly force a connection closed without
returning anything?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jesse,
On 1/15/15 5:06 PM, Jesse Barnum wrote:
>> On Jan 14, 2015, at 12:29 AM, Konstantin Kolinko
>> <kn...@gmail.com> wrote:
>>
>> 2015-01-14 6:28 GMT+03:00 Christopher Schultz > 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...
>>
>> response.setHeader("Connection", "close") will cause Tomcat to
>> close the connection (i.e. do not use keep-alive that is default
>> for HTTP/1.1 requests).
>>
>> Response body may be empty but by default the response includes
>> HTTP status code and reason phrase and some headers. Is that too
>> much?
>>
>>> 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.
>>
>> It can be implemented in two tiers:
>>
>> a) an application sets an attribute on request or uses some
>> specific status code on the response.
>>
>> b) a valve detects presence of the attribute or status code and
>> closes the connection.
>>
>> You have not mentioned your version of Tomcat.
>>
>> For a pointer, note the following enum value in the source code
>> (available in the current 7.0.x, 8.0.x):
>>
>> org.apache.coyote.ErrorState.CLOSE_NOW
>>
>> org.apache.coyote.ErrorState.isIoAllowed()
>>
>> Best regards, Konstantin Kolinko
>
> Thank you very much for all the help. After reading all of these
> responses, I concluded that it was not that bad to just return an
> empty response, especially by using mod_header to se the server and
> date headers to empty value.
>
> I forgot to mention - I’m running Tomcat 7.052 with an Apache 2.2
> front-end. I have a feeling that even if I did implement the Valve
> trick, Apache would still return some response to the user (likely
> an error 500 or 503 that the AJP connector had failed to respond),
> so returning a very small response from Tomcat is actually probably
> less outbound bandwidth.
You might want to look into mod_evasive.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUuIPAAAoJEBzwKT+lPKRYsiQP/RWcv8w5nmJucMDmPRtNkF3s
qx7y7puZH5ZZJLaKf9PUAD8boT8UHJZ21R/IUGV243k/mSVbZkBTVYgBjBNKl4nZ
3gXJvHCpWRvJzlvZ+NP7fjtPG6+uyhQBmAGDTxOVSdL9UvXCYWFPjLWFgE6M64pF
0KUcH299fXbBe+t0kX1mW108N0epTOo4XJXTVdO9mqBqozPpgmEH911uF0Dl9+ve
H7syjcjKHKATBeIfdEyPGMHt7firDcQVS7NsiYKJV4hq7frZcS6eSByMcWPjXsDI
a0cEyXYO53y4fO3GdaiI3Yr2N8pMQcqHPZNy6iNgBe1TYeuC9QH9ndwdrIrRZezD
FYS8QqSRw/DAHW5PBjPK4wsMAz7XJ3qN/DoqOSe4rUo4CxiRKNdxYD9cOMPPBgWL
T/lH5KvRmRNGNiP2SO/JePfvvGggwxYhyHEINiI/W4hhGB2Vdt3xqtBIp4T4xE67
f0VvX+B2bu3GQEsBFa1jIYSskGtylt32x6oyLvJLDpEQY59eZhHYuy/IsH2P+ch5
x+Jx29VHX0dfQS+EALoSxc6bT98wgUJxMNa7fyWMb+cnnY6kF8cmqOgcb5x1JCly
rP/Wc7JbjACiJNxPsR+OaD+fVdwrKGO4e3m7IRyFD5u5nk5zV4WbL155L2t+WGaI
4stKItkZ2uL9p9tYxKcS
=OEGV
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a way to abruptly force a connection closed without returning anything?
Posted by Jesse Barnum <js...@360works.com>.
> On Jan 14, 2015, at 12:29 AM, Konstantin Kolinko <kn...@gmail.com> wrote:
>
> 2015-01-14 6:28 GMT+03:00 Christopher Schultz > 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...
>
> response.setHeader("Connection", "close") will cause Tomcat to close
> the connection (i.e. do not use keep-alive that is default for
> HTTP/1.1 requests).
>
> Response body may be empty but by default the response includes HTTP
> status code and reason phrase and some headers.
> Is that too much?
>
>> 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.
>
> It can be implemented in two tiers:
>
> a) an application sets an attribute on request or uses some specific
> status code on the response.
>
> b) a valve detects presence of the attribute or status code and closes
> the connection.
>
> You have not mentioned your version of Tomcat.
>
> For a pointer, note the following enum value in the source code
> (available in the current 7.0.x, 8.0.x):
>
> org.apache.coyote.ErrorState.CLOSE_NOW
>
> org.apache.coyote.ErrorState.isIoAllowed()
>
> Best regards,
> Konstantin Kolinko
Thank you very much for all the help. After reading all of these responses, I concluded that it was not that bad to just return an empty response, especially by using mod_header to se the server and date headers to empty value.
I forgot to mention - I’m running Tomcat 7.052 with an Apache 2.2 front-end. I have a feeling that even if I did implement the Valve trick, Apache would still return some response to the user (likely an error 500 or 503 that the AJP connector had failed to respond), so returning a very small response from Tomcat is actually probably less outbound bandwidth.
--Jesse Barnum, President, 360Works
http://www.360works.com
Product updates and news on http://facebook.com/360Works
(770) 234-9293
== Don't lose your data! http://360works.com/safetynet/ for FileMaker Server ==
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a way to abruptly force a connection closed without
returning anything?
Posted by Konstantin Kolinko <kn...@gmail.com>.
2015-01-14 6:28 GMT+03:00 Christopher Schultz > 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...
response.setHeader("Connection", "close") will cause Tomcat to close
the connection (i.e. do not use keep-alive that is default for
HTTP/1.1 requests).
Response body may be empty but by default the response includes HTTP
status code and reason phrase and some headers.
Is that too much?
> 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.
It can be implemented in two tiers:
a) an application sets an attribute on request or uses some specific
status code on the response.
b) a valve detects presence of the attribute or status code and closes
the connection.
You have not mentioned your version of Tomcat.
For a pointer, note the following enum value in the source code
(available in the current 7.0.x, 8.0.x):
org.apache.coyote.ErrorState.CLOSE_NOW
org.apache.coyote.ErrorState.isIoAllowed()
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a way to abruptly force a connection closed without
returning anything?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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"
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUteJIAAoJEBzwKT+lPKRY13MP+gM+q3VtnKYHRwksGTnf2ZO7
mCiBZYudoYUqaWwzumIsi3bOp7dMjnFlkjw9/nG68x5O8vIIPxOY13n30gA2YXaN
4B4+Wfaf6nFTYgq84IfcNs6qJ1GOR2dfasVkeGbhfqslcgkkl/05VOBz2f5tK3mI
Kc3j1FygiXc2R8fG5KLZREgnRmVxNUwxsRDL9pZTj/okQyg2fLlljmCwDFHvuLLx
19W1x3CeeeAJD8/Akp8WCsjAsgdnYvg7r9ynC9DFBFKfjztZR+/QXK3mXxAYLziS
KadzbE/k3Am1VLA5dAD5VSFTOmCMPkt2i0INIrKvnf3Hj6QpU1B+qTr++dYTZUBb
F1n1GIXGYV1YJZFMIcZu7f4gTyJiKDCQQ6im+PJVfpG5zhVrlKv2teAttfT7qEET
pILu71NYVN5ysT11pYM8xoBj9zv1v/V9sOyvWpmLi6oPrJSnlqMKMfoXqlNRwq9q
DVGL0GkDR83MIChe+yen+/3QDnBaXnQTUGlG2U3tDns7yChAVbhu0TjT/uzxNRvc
15DUUrnvve8R8c/49tXumgPnb/fGrL/jooCk2SiKNHF2HsoxoNY5VWYybIzXw+Aw
0SpgVV/By4RMOEWGevhIagczMeakUm1y3v6dX9hVjMm+lN4Fr5C4TteKRtComrn0
KuaAooL3NTb+/yL/s49S
=zen8
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a way to abruptly force a connection closed without
returning anything?
Posted by Mark Eggers <it...@yahoo.com.INVALID>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 1/13/2015 4:03 PM, Jesse Barnum wrote:
>> On Jan 13, 2015, at 6:46 PM, Mark Eggers
>> <it...@yahoo.com.INVALID> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> On 1/13/2015 3: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?
>>>
>>> --Jesse Barnum, President, 360Works
>>>
>>
>> Possibly with mod_security?
>>
>> https://www.modsecurity.org/
>>
>> You can add this to Apache HTTPD if you're fronting Tomcat with
>> it, or you can check out the Java implementation here:
>>
>> http://blog.spiderlabs.com/2013/09/modsecurity-for-java-beta-testers-needed.html
>>
>>
>>
I have used mod_security, and while it's somewhat a beast, it does a
>> great job at protecting web applications.
>>
>> I have not used the Java version.
>>
>> . . . just my two cents /mde/
>
> Thanks for the suggestion, but that won’t do what I need. I need to
> examine the request and use business logic in my web app to
> determine whether or not to respond to the request.
>
> --Jesse Barnum, President, 360Works http://www.360works.com Product
> updates and news on http://facebook.com/360Works (770) 234-9293 ==
> Don't lose your data! http://360works.com/safetynet/ for FileMaker
> Server ==
Yep, writing business logic as a set of custom rules might be a bit of
work. I've had to write custom rules in the past, and they can get
complicated quickly.
On the plus side, with mod_security the Apache HTTPD server does the
work, logs the requests, and you can possibly start to see patterns
where you could short-circuit the tests.
It's also in one place, so you wouldn't have to duplicate the effort
(unless each application has a different set of failure rules).
. . . just my two cents
/mde/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBAgAGBQJUtbXRAAoJEEFGbsYNeTwt/80H/19/x+lWs1SxpkzqQv00aY35
tpTB9gxbJF3RGTvDiJpMbhh7bcue+P6upEPTNkxBLN5duuffztb+3yP6ZTa/dRa6
ACdk2ENNhp7y/aBtB2nDoCrQF2XAB+bj//E08p7Ap4H6ZjsCz60N+jZQ2cWwv48W
KGQp3iXyZBN1Fe382YzaEdRpobQ+1evG0DGTIpeV0JCxAGk686pFMm2Tiv4YQcXl
cIXjPfyhhfD7lMsxlLTNtfbrFgoLOAuw76G1V+FAOCH5VhMslA7z0QxfbumEqvR2
S37klL8QjEhYH2VeQZJDLsa5V2rELR+2Cpr2B3Wa+vH+REC4odUPkYcxMTyUJEQ=
=OZ6s
-----END PGP SIGNATURE-----
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a way to abruptly force a connection closed without returning anything?
Posted by Jesse Barnum <js...@360works.com>.
> On Jan 13, 2015, at 6:46 PM, Mark Eggers <it...@yahoo.com.INVALID> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 1/13/2015 3: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?
>>
>> --Jesse Barnum, President, 360Works
>>
>
> Possibly with mod_security?
>
> https://www.modsecurity.org/
>
> You can add this to Apache HTTPD if you're fronting Tomcat with it, or
> you can check out the Java implementation here:
>
> http://blog.spiderlabs.com/2013/09/modsecurity-for-java-beta-testers-needed.html
>
> I have used mod_security, and while it's somewhat a beast, it does a
> great job at protecting web applications.
>
> I have not used the Java version.
>
> . . . just my two cents
> /mde/
Thanks for the suggestion, but that won’t do what I need. I need to examine the request and use business logic in my web app to determine whether or not to respond to the request.
--Jesse Barnum, President, 360Works
http://www.360works.com
Product updates and news on http://facebook.com/360Works
(770) 234-9293
== Don't lose your data! http://360works.com/safetynet/ for FileMaker Server ==
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Is there a way to abruptly force a connection closed without
returning anything?
Posted by Mark Eggers <it...@yahoo.com.INVALID>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 1/13/2015 3: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?
>
> --Jesse Barnum, President, 360Works
>
Possibly with mod_security?
https://www.modsecurity.org/
You can add this to Apache HTTPD if you're fronting Tomcat with it, or
you can check out the Java implementation here:
http://blog.spiderlabs.com/2013/09/modsecurity-for-java-beta-testers-needed.html
I have used mod_security, and while it's somewhat a beast, it does a
great job at protecting web applications.
I have not used the Java version.
. . . just my two cents
/mde/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBAgAGBQJUta46AAoJEEFGbsYNeTwtDI4H/iImbmftf+KIxBsPo1Gx0+ZD
mFPdlgDegHDQRRlDxGFShoyAQcKX9O/xIfy04P6SrOLdxQJ5sBVv5uEN7qYp24Ar
WLz0Iwy/zGWpA0Y7Gq1AXRK64oGvrmJJ8KMLwXu9eBUCQiK8eIJvNZdKRJi/7Ki/
FLxchfA8E9DGA3B59uebuSYgmVobj1hCK5/+z2DMNNSZh0nTWb29dbzW/BCC8/e5
y123ZapWPS1ze2bjkgC6FZmZD9eH2JN1QTC0966R4G9K3LmKpCS3SyxZisxfRPUh
AZVhvJ9tV5jzaMytveOj2MSltUlqJA/PitQIbFP3plP3hyB3lSFwacyZiePOeQ8=
=bQTB
-----END PGP SIGNATURE-----
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org