Managing ACL exceptions (was Re: Filter NTP traffic by packet size?)
Ray Soucy
rps at maine.edu
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
More information about the NANOG
mailing list