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

Fri Feb 28 14:02:03 UTC 2014

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