When I was looking at the website before I didn't really see any mention of uRPF, just the use of ACLs, maybe I missed it, but it's not encouraging if I can't spot it quickly. I just tried a search and the only thing that popped up was a how-to for a Cisco 7600 VXR.
http://www.bcp38.info/index.php/HOWTO:CISCO:7200VXR On Fri, Feb 28, 2014 at 9:04 AM, Jay Ashworth <j...@baylink.com> wrote: > You mean, like Bcp38(.info)? > > > On February 28, 2014 9:02:03 AM EST, Ray Soucy <r...@maine.edu> wrote: >> >> 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-foundation-protection-nfp/prod_white_paper0900aecd80313fac.pdf >> >> 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.s...@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 <j...@baylink.com> wrote: >>> >>>> ----- Original Message ----- >>>>> >>>>> From: "Brandon Galbraith" <brandon.galbra...@gmail.com> >>>> >>>> >>>>> On Wed, Feb 26, 2014 at 6:56 AM, Keegan Holley <no.s...@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 >>>> j...@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 >>> >>> >> >> >> > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- 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
