Jason, thanks for the reply.
The blocking mechanism works pretty much exactly like you described.
The page is served very fast too. The problem is fastcgi's (mod_fcgid) will
eventually spawn tons of process even if the request is small and fast. So
the server gets clogged with processes,
Ive tried a lot of different fcgid's configurations, went all low and high
extreme configs and this behavior still occurs - hence why Id like to try
and kill the request before it is handled.
> -----Original Message-----
> From: Jason Pyeron [mailto:jpyeron@xxxxxxxx]
> Sent: terça-feira, 21 de janeiro de 2014 16:39
> To: users@xxxxxxxxxxxxxxxx
> Subject: RE: Security challenge, rejecting specific requests
> without blocking IP
>
> > -----Original Message-----
> > From: Rudi Feijó [mailto:rudi.feijo@xxxxxxxxxxxxxxxxxxx]
> > Sent: Tuesday, January 21, 2014 13:25
> > To: users@xxxxxxxxxxxxxxxx
> > Subject: Security challenge, rejecting specific requests
> > without blocking IP
> >
> > Hello
> >
> > I have been trying to solve a big problem for the last 2 weeks with
> > one of our servers (apache 2.2 , windows, php).
> >
> > The client using our system is a contact center firm.
> > They have about 120 operators, all connect to our websever with the
> > same IP, their outgoing IP.
> >
> > We have been suffering DoS attacks from some of these operators.
> > These are simple, browser attacks , namely 5 or 10 operators will just
> > hold
> > F5 key and bombard the server with requests when they shouldnt.
> >
> > There is very little we can do to improve performance of these
> > specific url's the attackers are using. This is a software, not a
> > public portal, so a lot of screens have a good amount of processing
> > and real time querying in them.
> >
> > We did manage to produce a php protection which will recognize the
> > multiple requests and blacklist the user.
> > We use the user ID in the system to control who should be blacklisted,
> > so this is all dependent on our own authentication.
> > It works like this :
> > - user logs in our software, we write his ID in a cookie
> > - a control file is created using that ID as the unique key
> > - from there we control if he's hitting the same url repeatedly, if
> > the cookie exists
> > - after x requests on the same url, the script will die, and a message
> > will be displayed.
> > - the control cookie is erased when the users logoff or after a 24
> > hours lifetime
> >
> > This works to some extent, but it?s a little "too late" since
>
> First lines of php script:
>
> # only logged in users should request this page If ! Cookie present then
die; If !
> Session present then die; If nonce seen then die;
>
> > the request have already been sent and processed by the webserver.
> > Even after trimming down the request to a bare minimum, its still a
> > php request that will be enqueued and normally processed by the
> > handler.
> > So, the attackers now have to "hold F5" for a much longer time, but
> > they are still keen to doing it anyhow.
> >
>
> This is a side point, but it comes from experience.
>
> All web applications must out perform the ability of a client directly
connected
> holding down the F5 key. It is simple load testing during development.
>
> Your web app should be able to serve the following at the speed of the
wire:
>
> {
> if (session==null || session.user==null) return new
> Redirect("LoginPage");
> if (getNonce()==null || exists(session.nonces{getNonce()})) return
new
> HTTPError(500)
> return new HTTPDoc(200,"Hello there:"+new Date());
> }
>
> If it cannot, then your server is under powered, if so fix the code to
guard
> against multiple load violations.
>
> >
> > Ideally, we need something EXACTLY like mod_evasive, but for
> > rejecting single requests instead of blocking the IP.
> > Exemplifying : if a user calls the same url, 5 times, in a 3
> > second spawn, we will reject every next request for 30
> > seconds, but only the requests by that user.
> >
> >
> > Also, we can only work with apache on windows so far, but
> > linux only solutions are also of interest if there are any.
> >
> > Any help, suggestion or idea how to brain storm this issue is
> > greatly appreciated.
>
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> - -
> - Jason Pyeron PD Inc. http://www.pdinc.us -
> - Principal Consultant 10 West 24th Street #100 -
> - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
> - -
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> This message is copyright PD Inc, subject to license 20080407P00.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
---
Este email está limpo de vírus e malwares porque a proteção do avast! Antivírus está ativa.
http://www.avast.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|