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@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of John McBrayne Sent: Tuesday, November 27, 2001 6:37 PM To: nanog@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