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 >>> >> >> > > > >-- >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
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
