Managing ACL exceptions (was Re: Filter NTP traffic by packet size?)

Fri Feb 28 14:04:18 UTC 2014

You mean, like Bcp38(.info)?

On February 28, 2014 9:02:03 AM EST, Ray Soucy <rps at 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.spam at 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 at baylink.com> wrote:
>>
>>> ----- Original Message -----
>>>> From: "Brandon Galbraith" <brandon.galbraith at gmail.com>
>>>
>>>> On Wed, Feb 26, 2014 at 6:56 AM, Keegan Holley
><no.spam at 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 at 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.