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
On Tue, Nov 27, 2001 at 03:37:18PM -0800, John McBrayne stated:
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
enter the RFC1918/egress filtering rants ... mmmm on a constructive note, I don't have config files to list, but a good start would be: * RFC1918 space filtered * egress filtering (space not on your network should not appear to be originating from within your network) * smurf prevention with no-directed-broadcast or the equivalent There were a couple of very helpful presentations at this year's ToorCon <http://www.toorcon.org> wrt locking down routers, with emphasis on Cisco hardware. Take a look at http://toorcon.org/lineup/ciscosecurity/ (HTML; PS also available) - that was the presentation on using Cisco IOS for Network Security. There seems to be no presentation notes available for 'The Top 25 Overlooked Configurations on Routers and Switches' on the site; I have some (rather poor and haphazard) notes I took myself that are available at http://darkuncle.net/top25_router_configurations.txt HTH -- Scott Francis darkuncle@ [home:] d a r k u n c l e . n e t UNIX | IP networks | security | sysadmin | caffeine | BOFH | general geekery GPG public key 0xCB33CCA7 illum oportet crescere me autem minui
Date: Tue, 27 Nov 2001 15:37:18 -0800 From: John McBrayne <mcbrayne@caspiannetworks.com>
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.
_Rob's Articles Collection_ makes a great start: http://www.cymru.com/~robt/Docs/Articles/ Have fun. HTH, Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
On Tue, 27 Nov 2001, John McBrayne wrote: jm> jm> Is anyone aware of any current "best practices" related to the jm> recommended set of filtering rules (Cisco ACL lists or Juniper filter jm> sets) for reasons of Security, statistics collection, DoS attack jm> analysis/prevention, etc.? I'm curious to see if there are any such John, the three areas you mention above really should be treated differently, is there something you are particularly interested in among these? On a 'generic' note there is are some recommendations offered by Cisco at thier website, I can't (of course) endorse them over anyone else, Barry Greene (who posts at times here and should respond to this note with the proper links from Cisco) is one of the better voices at Cisco for the Security (atleast) topic. Additionally, there were some 'recommended' or 'best practices' covered at the last NANOG: http://www.nanog.org/mtg-0110/greene.html That should atleast get you started on 'Security' and 'DoS' stuff... as to statistics could you clarify this some? jm> recommendations for Tier 1/Tier 2 backbone routers, peering points, jm> etc., as opposed to CPE terminations or Enterprise/LAN equipment jm> recommendations. jm> Hmm, I'm not going to recommend anything, since your network is likely MUCH different from any one I'm working on... BUT perhaps wecan discuss some likely scenarios?? (perhaps the other list members might have some statistics gathering ideas/examples??) jm> Actual config file examples would be great, if they exist.
Chris is talking about the ISP Workshop Archives which includes the ISP Essentials whitepaper/presentations, security presentations, multihoming presentations, and other materials we use to help new generations of ISP Engineers get up to speed. It is all "Cisco" stuff, so keep that in mind. No fancy web pages - just browse the directories: http://www.cisco.com/public/cons/ The security materials are at: http://www.cisco.com/public/cons/isp/security/ ISP Essentials is at: http://www.cisco.com/public/cons/isp/documents/
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Christopher L. Morrow Sent: Tuesday, November 27, 2001 9:13 PM To: John McBrayne Cc: nanog@merit.edu Subject: Re: ACLs / Filter Lists - Best Practices
On Tue, 27 Nov 2001, John McBrayne wrote:
jm> jm> Is anyone aware of any current "best practices" related to the jm> recommended set of filtering rules (Cisco ACL lists or Juniper filter jm> sets) for reasons of Security, statistics collection, DoS attack jm> analysis/prevention, etc.? I'm curious to see if there are any such
John, the three areas you mention above really should be treated differently, is there something you are particularly interested in among these?
On a 'generic' note there is are some recommendations offered by Cisco at thier website, I can't (of course) endorse them over anyone else, Barry Greene (who posts at times here and should respond to this note with the proper links from Cisco) is one of the better voices at Cisco for the Security (atleast) topic.
Additionally, there were some 'recommended' or 'best practices' covered at the last NANOG: http://www.nanog.org/mtg-0110/greene.html
That should atleast get you started on 'Security' and 'DoS' stuff... as to statistics could you clarify this some?
jm> recommendations for Tier 1/Tier 2 backbone routers, peering points, jm> etc., as opposed to CPE terminations or Enterprise/LAN equipment jm> recommendations. jm>
Hmm, I'm not going to recommend anything, since your network is likely MUCH different from any one I'm working on... BUT perhaps wecan discuss some likely scenarios?? (perhaps the other list members might have some statistics gathering ideas/examples??)
jm> Actual config file examples would be great, if they exist.
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.?
You might find the NSA Router Security Configuration Guide of some use. You can download a pdf of it at: http://nsa2.www.conxion.com/cisco/download.htm Best regards, Geoff Zinderdine CCNP MCP CCA MTS Communications
John McBrayne wrote:
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.
Protecting your IP network infrastructure (talk @BlackHat Briefings) (how to secure Cisco routers and (multi-layer) switches running IOS, CatOS, CatIOS and the networks they interconnect) : http://www.securite.org/presentations/secip/ Any feedback, comments, fixes, ideas are welcome :-) Nico. -- Nicolas FISCHBACH (nico@securite.org) <http://www.securite.org/nico/> Senior IP&Security Engineer - Professional Services - COLT Telecom AG Securite.Org Team <http://www.securite.org/>
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
On Fri, Nov 30, 2001 at 01:39:24AM -0500, Tim Irwin wrote:
- <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>
And that's why we all need to employ things like CEF reverse path verification at our customer edge. -- Andreas Plesner Jacobsen | There's a lot to be said for not saying a lot.
On Fri, Nov 30, 2001, Andreas Plesner Jacobsen wrote:
On Fri, Nov 30, 2001 at 01:39:24AM -0500, Tim Irwin wrote:
- <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>
And that's why we all need to employ things like CEF reverse path verification at our customer edge.
Strangely enough, DoS attacks these days may not be caught by reverse-path filtering. Think hundreds of exploited modem, DSL and cable machines (be it windows, linux, solaris, whatever..) Think each machine sitting on an irc network, whether it be a public one (Efnet, Undernet, Dalnet, etc) or a private one. Think each machine sending a valid stream of say, 5 packets a second (each a few hundred bytes) to some host that someone in the relevant IRC channel commands. Oops. DoS. Traceable (which is nice), but not easily stopped since the traffic, for all intents and purposes, is valid. RFC1918 filtering won't stop this. reverse-path filtering won't do this. subscriber-edge spoof filtering won't even catch this. And before someone jumps up and says "theoretical!", I'm sure a few NANOGers who double as occasional IRC server admins can possibly attest to strangely named channels with hundreds of idling clients sitting in them.. :-) Personally I think that subscriber-edge filtering should be the primary thing (come on guys, how many clients use satellite download schemes which require IP spoofing for outbound packets via a modem?), since most times an _end customer_ (and I'd kick-start the end-customer defintion as one who doesn't speak BGP) needs to spoof source IPs for a service, their service provider should be using an IP-IP encaps protocol. And, if reverse-path filtering starts becoming widespread, these people requiring source IP spoofing may also find themselves lost. 2c, Adrian -- Adrian Chadd "Auntie Em, Hate you. Hate Kansas. <adrian@creative.net.au> Taking the dog." -- Dorothy
Hi again, all. Ah, this is a topic near and dear to my heart. :) ] And before someone jumps up and says "theoretical!", I'm sure a few ] NANOGers who double as occasional IRC server admins can possibly ] attest to strangely named channels with hundreds of idling ] clients sitting in them.. :-) I track between one and ten botnets per day, on IRC networks both public and private. They vary in size from five bots to greater than 10K bots. The average is on the low end, probably less than 100 bots. The large botnets (> 2000 bots) are rare, but they do exist. Ponder the power of 10K bots hitting your border routers with any sort of flood. <BOOM> This stuff is quite real, and quite powerful. Thanks, Rob. -- Rob Thomas http://www.cymru.com/~robt ASSERT(coffee != empty);
Hi, all. Just a couple of comments in response to: ] - <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> I filter all RFC 1918 and unused/bogon space at my borders (in both prefix-lists and ACLs). This cuts down on a large percentage of the garbage. Of course I filter outbound as well, to protect the Internet from my data centers. :) You can see the filtering I use in the Secure IOS Template and Secure BGP Templates here: http://www.cymru.com/~robt/Docs/Articles/secure-ios-template.html http://www.cymru.com/~robt/Docs/Articles/secure-bgp-template.html With one routinely attacked site, 68% of the incoming traffic uses bogon source addresses (e.g. 127.1.1.1, 169.254.3.3, 0.1.2.3, etc.) So this filtering really does help. However, having said that, please keep in mind that most of the bots I disassemble and botnets I monitor don't bother to spoof at all. Many don't include the capability to generate spoofed or malformed packets. Why? Because the number of bots used in the attack is already overwhelming. It is almost impossible to block them all with conventional filtering, so there is no need to spoof. Further, tracking them is quite difficult as well. Try explaining to a home user that his or her machine has been used in a DDoS attack. The response I received by one home PC owner was: "Cool!" :P FYI, the miscreants continue to hack vulnerable Cisco routers. I watched as one crew gathered 800 ciscos (underground parlance) a few days ago. Please ensure that you have access control and good passwords on your routers. Advise your customers to do the same. Hmm, when will I ever be able to keep my posts to "just a couple of comments?" :) Thanks, Rob. -- Rob Thomas http://www.cymru.com/~robt ASSERT(coffee != empty);
participants (11)
-
Adrian Chadd -
Andreas Plesner Jacobsen -
Barry Raveendran Greene -
Christopher L. Morrow -
E.B. Dreger -
Geoff Zinderdine -
John McBrayne -
Nicolas FISCHBACH -
Rob Thomas -
Scott Francis -
Tim Irwin