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

[Ray Soucy <rps () maine edu>]

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