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