blocking unwanted traffic from hitting gateway
I've got about 1000 people hammering a Linux gateway with http requests, but only about 150 of them are authenticated users for the ISP. Once someone authenticates, then I want their traffic to pass through okay. But if they're not an authenticated user, I would like to ideally block those http requests (e.g. Google updater, AV scanners, etc) from ever tying up my web server. Is there some sort of box I could put in front (e.g. OpenBSD pf in transparency mode) or maybe some sort of filter on the webserver? This solution would need to be tied into the authentication services so authenticated users hit the gateway. -- Also on LinkedIn? Feel free to connect if you too are an open networker: scubacuda@gmail.com
On May 18, 2011, at 7:42 PM, Rogelio wrote:
This solution would need to be tied into the authentication services so authenticated users hit the gateway.
So the attackers can just hammer the authentication subsystem and take it down, instead? ;> By going the 'authentication' route in the sense you mean it, you'll make it even more trivially easy to DDoS the Web servers than is possible without such a system. <http://www.mail-archive.com/nanog@nanog.org/msg17914.html> ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> The basis of optimism is sheer terror. -- Oscar Wilde
On Wed, May 18, 2011 at 09:42:03AM -0300, Rogelio wrote:
I've got about 1000 people hammering a Linux gateway with http requests, but only about 150 of them are authenticated users for the ISP.
Are you the ISP, or someone else? Why is the gateway caring that the requests are HTTP? Is it also an HTTP server (and if so, does it matter that it's a gateway?)
Once someone authenticates, then I want their traffic to pass through okay. But if they're not an authenticated user, I would like to ideally block those http requests (e.g. Google updater, AV scanners, etc) from ever tying up my web server.
What authentication mechanism are acceptable? HTTP at the request level, captive portal, custom app, etc etc etc.
Is there some sort of box I could put in front (e.g. OpenBSD pf in transparency mode) or maybe some sort of filter on the webserver?
What risk or problem are you actually trying to mitigate against? Sure, you can put all sorts of things in front of it or on it, but are you just going to be moving the problem (whatever it may be) to another box, adding complexity for no good reason?
This solution would need to be tied into the authentication services so authenticated users hit the gateway.
You might want to mention what "authentication services" you're using if you want any useful recommendation about tying into it. - Matt -- The hypothalamus is one of the most important parts of the brain, involved in many kinds of motivation, among other functions. The hypothalamus controls the "Four F's": 1. fighting; 2. fleeing; 3. feeding; and 4. mating. -- Psychology professor in neuropsychology intro course
On May 18, 2011, at 5:42 AM, Rogelio wrote:
I've got about 1000 people hammering a Linux gateway with http requests, but only about 150 of them are authenticated users for the ISP.
Once someone authenticates, then I want their traffic to pass through okay. But if they're not an authenticated user, I would like to ideally block those http requests (e.g. Google updater, AV scanners, etc) from ever tying up my web server.
Is there some sort of box I could put in front (e.g. OpenBSD pf in transparency mode) or maybe some sort of filter on the webserver? This solution would need to be tied into the authentication services so authenticated users hit the gateway.
-- Also on LinkedIn? Feel free to connect if you too are an open networker: scubacuda@gmail.com
I use apache mod_rewrite in front of some stuff, there are a couple of examples where I look for a cookie and make sure it's set to some value before they can do something interesting. If the cookie doesn't exist, or if it's not set to the desired value, it goes somewhere else that's easily cacheable. Here's an example, the cookie name is "loggedin" and the value is "true". If that doesn't match up it proxies over to login.jsp. RewriteCond %{HTTP_COOKIE} !loggedin=true RewriteRule ^/(.*) http://%{HTTP:Host}/login.jsp [P,L] Good luck. -wil
For what it's worth, here are some things I did to cut down on broadcast traffic until I figure out the other pieces --Putting router in between subscribers and gateway (handles thousands of ARP requests every minute much better than Linux) --DCHP relay on one of the northbound interface of the new router (which points towards subscriber gateway) --DHCP unicast settings on the CPE devices Seems to have helped a lot, which leads me to believe it is much more related to broadcast than I previously thought.
participants (4)
-
Dobbins, Roland -
Matthew Palmer -
Rogelio -
Wil Schultz