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

Fri Feb 28 15:35:19 UTC 2014

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 <jra at baylink.com> wrote:
> 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
>>>
>>>
>>
>>
>>
>
> --
> 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