> -----Original Message-----
> From: Jason Pyeron [mailto:jpyeron@xxxxxxxx]
> Sent: quarta-feira, 22 de janeiro de 2014 21:16
> To: users@xxxxxxxxxxxxxxxx
> Subject: RE: Security challenge, rejecting specific requests
> without blocking IP
>
> > -----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?
These are the current settings
FcgidInitialEnv PHP_FCGI_MAX_REQUESTS 10000
FcgidBusyScanInterval 30
FcgidBusyTimeout 7200
FcgidConnectTimeout 3
FcgidIdleScanInterval 30
FcgidIdleTimeout 150
FcgidProcessLifeTime 1200
FcgidIOTimeout 200
FcgidMaxProcesses 1000
FcgidMaxProcessesPerClass 100
FcgidMaxRequestsPerProcess 0
FcgidMinProcessesPerClass 3
FcgidOutputBufferSize 0
FcgidSpawnScoreUpLimit 300
>
> > 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.
I actually appreciate the info, we usually reserve some development time to
research other technologies.
>
> >
> > > -----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
|