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:jpye...@pdinc.us] > Sent: terça-feira, 21 de janeiro de 2014 16:39 > To: users@httpd.apache.org > Subject: RE: [users@httpd] Security challenge, rejecting specific requests > without blocking IP > > > -----Original Message----- > > From: Rudi Feijó [mailto:rudi.fe...@multidadosti.com.br] > > Sent: Tuesday, January 21, 2014 13:25 > > To: users@httpd.apache.org > > Subject: [users@httpd] 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 its 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-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org --- 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-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
