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
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
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
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?
recommendations for Tier 1/Tier 2 backbone routers, peering points,
etc., as opposed to CPE terminations or Enterprise/LAN equipment
recommendations.
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??)
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
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:
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.
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
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
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
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!" 
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.
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.