RE: Security challenge, rejecting specific requests without blocking IP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----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






[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux