ACLs / Filter Lists - Best Practices

Fri Nov 30 06:39:24 UTC 2001

John,

We recently ran through this exercise with Cisco.  Our Cisco engineer came
with a huge powerpoint slideshow that covers a lot of general topics.  Ask
Cisco if you can get that from them, it seemed to have more detailed info
than the whitepaper on the website.  (Powerpoint with more detail than a
whitepaper... go figure.)

Some lessons learned...

- <rant>RFC 1918 filtering is no silver bullet.  Yes, it should be done, but
all a malicious person needs in order to be able to launch an effective DDoS
attack is to source from unassigned address space or address space that is
known to be unused.</rant>

- Myself and a couple of other engineers set up a DDoS testbed recently on a
completely private network.  We took a 7500 series router, loaded our test
configs and a full BGP table.  Then we threw our baseline traffic at it from
Smartbits.  I installed linux on 4 old PCs and used Tribe Flood Net 2k to
launch an ICMP flood DDoS attack against the router.  Without any
countermeasures, it killed the router -- brought it to it's knees --
couldn't get the console to respond.  Started trying various things Cisco
recommends like rate-limiting ICMP to see the effect.  We were seeing an
anomaly in that the DDoS attack wasn't showing up as filter hits on the VIPs
against the fast ethernet interfaces with rate-limiting turned on.  The
curious thing was that a ping from another router generated a filter hit,
but not the traffic from TFN2K.  Not sure what happened since then... I went
off working on some other things and never got back to it.  My thought was
to get ye olde sniffer out and see if I could find anything like a malformed
ICMP packet coming from TFN2K.  I know it writes to a raw socket.

- One of the things Cisco recommends is rate-limiting ICMP as a percentage
of bandwidth.  Our problem was that we often have multiple circuits with the
same b/w and we use equal-cost-multipath.  So, for example, if you
rate-limit 2% of a DS-3, you're really letting in an aggregate of 2% times #
of links.  What I'd like to see is an adaptive rate-limiting algorithm that
samples ICMP traffic over a statistically significant period of time and
then rate-limits based upon exceeding the average sampled threshold.  Could
possibly be done in conjunction with NetFlow or accounting.  This, of
course, does nothing for TCP and UDP floods, but it would help with managing
ICMP.

- My pet peeve with IOS is that some default commands are "hidden" in the
IOS config  -- they command is there by default, but it doesn't show up in
the config.  It's nearly impossible to find out which configuration commands
are on by default in which versions of IOS. (Hmmm... which version of IOS
was it that made "no ip-directed broadcasts" on by default?) It's just too
complicated... it could use some simplification.  I absolutely hate the fact
that I can't tell by looking at the router config.  I'm tired of trying to
figure it out from CCO, so I feel safer entering all the commands anyway
just to make sure.  I don't want to take any chances.

Hope this helps,
Tim

> -----Original Message-----
> From: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu]On Behalf Of
> John McBrayne
> Sent: Tuesday, November 27, 2001 6:37 PM
> To: nanog at merit.edu
> Subject: ACLs / Filter Lists - Best Practices
>
>
>
> Is anyone aware of any current "best practices" related to the
> recommended set of filtering rules (Cisco ACL lists or Juniper filter
> sets) for reasons of Security, statistics collection, DoS attack
> analysis/prevention, etc.?  I'm curious to see if there are any such
> recommendations for Tier 1/Tier 2 backbone routers, peering points,
> etc., as opposed to CPE terminations or Enterprise/LAN equipment
> recommendations.
>
> Actual config file examples would be great, if they exist.
>
> Thanks;
> ..john