> -----Original Message----- > From: Rudi Feijó > Sent: Wednesday, January 22, 2014 8:38 > > 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
Reading: http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html What are your Process Management settings? > request is small and fast. So the server gets clogged with > processes, Ive tried a lot of different fcgid's Very weird, the purpose of mod_fcgid should prevent the need for multiple processes. Do you have a memory leak? > 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. This is not an attempt to tell you to change technologies, but on our managed application (J2EE) servers (no external processes) have never seen such a problem. > > > -----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
