I'm wondering how many operators don't have systems in place to quickly and efficiently filter problem host systems. I see a lot of talk of ACL usage, but not much about uRPF and black hole filtering. There are a few white papers that are worth a read: http://www.cisco.com/c/dam/en/us/products/collateral/security/ios-network-fo... http://www.cisco.com/web/about/security/intelligence/urpf.pdf If you have uRPF enabled on all your access routers then you can configure routing policy such that advertising a route for a specific host system will trigger uRPF to drop the traffic at the first hop, in hardware. This prevents you from having to maintain ACLs or even give out access to routers. Instead, you can use a small router or daemon that disables hosts by advertising them as a route (for example, we just use a pair of small ISR 1841 routers for this); this in turn can be tied into IPS or a web UI allowing your NOC to disable a problem host at the first hop and prevent its traffic from propagating throughout the network without having to know the overall architecture of the network or determine the best place to apply an ACL. I've seen a lot of talk on trying to filter specific protocols, or rate-limit, etc. but I really feel that isn't the appropriate action to take. I think disabling a system that is a problem and notifying its maintainer that they need to correct the issue is much more sustainable. There are also limitations on how much can be done through the use of ACLs. uRPF and black hole routing scale much better, especially in response to a denial of service attack. When the NTP problems first started popping up, we saw incoming NTP of several Gb, without the ability to quickly identify and filter this traffic a lot of our users would have been dead in the water because the firewalls they use just can't handle that much traffic; our routers, on the other hand, have no problem throwing those packets out. I only comment on this because one of the comments made to me was "Can't we just use a firewall to block it?". It took me over an hour to explain that the firewalls in use didn't have the capacity to handle this level of traffic -- and when I tried to discuss hardware vs. software filtering, I got a deer-in-the-headlights look. :-) On Thu, Feb 27, 2014 at 8:57 PM, Keegan Holley <no.spam@comcast.net> wrote:
It depends on how many customers you have and what sort of contract you have with them if any. A significant amount of attack traffic comes from residential networks where a "one-size-fits-all" policy is definitely best.
On Feb 26, 2014, at 4:01 PM, Jay Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "Brandon Galbraith" <brandon.galbraith@gmail.com>
On Wed, Feb 26, 2014 at 6:56 AM, Keegan Holley <no.spam@comcast.net> wrote:
More politely stated, it's not the responsibility of the operator to decide what belongs on the network and what doesn't. Users can run any services that's not illegal or even reuse ports for other applications.
Blocking chargen at the edge doesn't seem to be outside of the realm of possibilities.
All of these conversations are variants of "how easy is it to set up a default ACL for loops, and then manage exceptions to it?".
Assuming your gear permits it, I don't personally see all that much Bad Actorliness in setting a relatively tight bidirectional ACL for Random Edge Customers, and opening up -- either specific ports, or just "to a less-/un-filtered ACL" on specific request.
The question is -- as it is with BCP38 -- *can the edge gear handle it*?
And if not: why not? (Protip: because buyers of that gear aren't agitating for it)
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
-- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net