-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Igal,
On 5/14/19 15:38, Igal @ Lucee.org wrote:
> Chris,
>
> On 5/14/2019 12:15 PM, Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>> All,
>>
>> bump
>>
>> It's hard to see anything with all the commit messages :)
>>
>> On 5/9/19 12:52, Christopher Schultz wrote:
>>> All,
>>>
>>> What are the options we might have to "punish" an HTTP client
>>> that we don't like for some reason?
>>>
>>> Specifically, I'd like to be able to write a servlet that
>>> ties-up the response to the client for a while for some bad
>>> behavior. For example, maybe lots of authentication attempts or
>>> some other criteria. Maybe even just a single bad
>>> authentication attempt.
>
> How do you identify the bad actor on subsequent requests? By its
> IP address?
I'm not sure I'd bother. Making a client wait 10 seconds for each bad
password attempt might be good enough. Sure, they can use NIO and
launch a million threads on their end but I can use mod_qos on my end.
>>> I'm thinking of something along these lines:
>>>
>>> public void doGet(...) {
>>>
>>> ...
>>>
>>> if(shouldPunishClient(...)) {
>>> request.setAttribute("delay-client", Boolean.TRUE); return; }
>>>
>>> ... }
>>>
>>> Or maybe even specify a time-out.
>>>
>>> Then, Tomcat observes that the servlet or filter wants to put
>>> the response into the penalty box and, instead of flushing the
>>> response and (possibly) closing the connection, it just
>>> sits-around for a while, keeping the connection open.
>
> Wouldn't that punish Tomcat by keeping the connection open? Open
> the door for DDoS attacks?
No, this is the point. Tie-up the connection, but not the thread.
> I would think that a better way to do it is to flush and close the
> request immediately, and then block the IP address for X seconds.
That can be done through other means (e.g. fail2ban).
>>> The poller usually waits for data to become available on either
>>> end of the connection and pushes the bytes. How complicated
>>> would it be to put connections into a queue where they wait
>>> some amount of time before being flushed/closed/returned to the
>>> connection pool? In this case, the only stimulus for taking
>>> action is the passage of time, not arrival of data on a
>>> stream.
>>>
>>> Any thoughts about how this could be done?
>
> You mean as part of the NIO implementation?
Yes, something like that. Instead of closing and returning the
connection to the pool, put it in another "timeout" pool for a bit and
then close/return it after some timeout.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzbK18ACgkQHPApP6U8
pFgJphAAruPfn0xW8GCyObHNTVJzU4LxBar52QNY8Q4Espp+qZRyT/OpuMsLEpDW
xlyq2Au4Uh625jX/EzCshm/Tbe9JSNOWx668sae7LkDkX708ZA1mgGbyo6J669L3
avOz4j6Bt7Yn4OC9mRm2vu6BYCOhlpe6WHYkZEsC7n73kAf9CqhqMlOa01qM1BZr
PDNp/tLz6MJfSBROJHvB4Bj/0Ga00aoqxHv8x0oHDqmUKDyJs370u3MVtvxtUpqx
V3Md+f12CBxtkj1HkfcNOW3/S1gYJLG3syd2NITdWs1y+E8WUvXyDkynwt+pfbDw
KGJzhyLbbQlbFmAawns9J/dgBLX8nFwvR3vqoFA1qVmeblSmdn1CHAl/sNmpZnz6
m+wgDkEbJ9L55MsyNS0qhnHNqcVLypPpHcEtqtri56ZMR6d0Vib9pntctkI0vYQc
QiLGJUi2BhNnuP2n2AmtV9ANfoFGbGun/3/vO3Kj+C+LnW5n3X+MeNSrdGEVSem7
qBeAGAfS0z9WcpMnCafMjeC6ZqaOqBvp1PhJ+2pK6n8WtxCnpqnk181q2lDYmpnZ
EGOsU08LigVMs4YlSs7ELxtyu+CLeRV8XEL+VvQ+0eG1TGFckJC6EgznggbALIro
wDmKy7I0cvGBKynKBaJuOFlPTbOq4jDK/N/O7kIPfRwuV2EflV0=
=pRck
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
