25 overlooked security configurations on your switches and routers by palante presented at blackhat,...

25 Overlooked security configurations on your switches

and routers

by PalantePresented at Blackhat, 2001

•

Introduction

• “Palante”– 3 years of server prizes in Defcon Capture the

Flag, kernel programmer

– Pentest with Fortune 500 consulting firm

– Experience includes large telecom environments

• This presentation covers router and switch misconfigurations for Cisco and Foundry– General syntax only, must be configured

according to specific site needs

Your network...

• While you were busy making your network bigger/faster/better, you also made it possible to control the network itself.

• The old days when you had to unplug something to cause problems are now officially gone.

• Routers and switches ARE your network, they should be resistant to attack.

The First 10 “Basics”

• I can’t fault you for not already fixing these– Mediocre sites will only have 1 or 2– Fascist sites will have about 4 to 6– Some items may be solved other ways

• But if you don’t understand the REASONS for all ten, you are way behind the curve– Time for a security “gut-check” – PS, 6 isn’t good enough.

#1 - Passwords

• Believe it or not, some people have to be told to put passwords on their equipment

• Vty/Console/Aux passwords

• Enable password– use enable secret (ie 5, not 7) !!!

#2 - SNMP Community Strings

• If you’re still using “public” and “private”

YOU SHOULD BE ASHAMED OF YOURSELF

• I see this way more often than you think

• Vulnerable “managed devices” mean your entire network is waiting to be controlled

• Spanning/Shadow port setup via snmp

• Even read access could give valuable info

#3 - SSH

• When you telnet into a device you expose your passwords and are subject to hijacking. (even through a switch! Spanning ports or ARP will do it!)

• Either go out-of-band (like serial line) or...• SSH into Foundry devices (Management II

blade or better)• SSH into Cisco requires IOS 12 with IPSEC

image ($,$$$ to $,$$$,$$$)

#4 - Source routing

• Source routing - think “spoof-o-matic”

• Source routing is a way to have packets bypass routing tables and take a different path - a path specified by the packet

no ip source-route (Foundry & Cisco)

#5 - Subnet broadcast

• Subnet broadcasts addresses are used in smurf attacks (Denial of service by ICMP flooding)

• If you don’t need broadcasts travelling across subnets, it might be a good idea to disable

no ip directed-broadcast (Foundry & Cisco)

#6 Services (Cisco)

• Turn off small servers (tcp AND udp) and finger

• At least chargen won’t respond to echo port (reassuring, but disable anyway)

no service tcp small-servers

no service udp small-servers

no service finger

#7 - Filter connections to router/switch itself

• Why allow just anyone to connect? Are you afraid that you’ll just be walking around and suddenly have such a brilliant idea that you need to telnet in immediately and change your config?????

• I hope none of these are internet-facing• Restrict connections to admin stations

access lists, reserve tty with access-class, transport input, etc

#8 - Config files

• Don’t leave your config files lying around for someone to read or even change

• This includes your TFTP servers– remember only enable password can be 5

#9 - Log review

• Collect SNMP traps (snmp trap target)

• That way you see the 100 failed snmp attempts (because you’re not using “public” or “private”) caused when someone is trying to get control of the device

#10 - Filter private address space

• RFC 1700 “127.0.0.0”• RFC 1918 “10.0.0.0, 172.16-19.0.0,

192.168.0.0”• Also your network’s address space should not

be sending packets from the outside• Only your address space should be sending

packets from the inside• If everyone would observe these there would

be no “Distributed DoS” Attacks

The Other 15...

• Some of these will put you even with the curve. Most will put you ahead.

• Being ahead of the curve means not being surprised when there turns out to be a tool that does what the vendor swore was completely theoretical.

• (The “nit-picky” stuff didn’t make it into the top 25)

#11 - Dynamic Routing Keys

• Keys authenticate dynamic route updates

• Use different keys with each neighbor

key-chain locked (Cisco)

. . key-string <key>

. . accept-lifetime

. . send-lifetime

#11 - Dynamic Routing Keys (cont)

ip <protocol> authentication-key <key> (Foundry)

also “distribute-list in …” may help

• Filter dynamic routes to private address space from #10

#12 - User Accounts

• Use login local or aaa & acs for multiple admins

• Several people have the device passwords - they all say they “didn’t do it”. True???

• “Root Cause Analysis” needs to know if anyone mucked with your config

#13 - ICMP redirects

• “ICMP redirects” are like source routing

deny icmp any any redirect (Cisco)

no ip icmp redirects (Foundry)

#14 - port security & static tables

• Cisco port security keeps other HW addresses from using a port

• It’s too easy to walk in, find the printer, unplug it, and plug a laptop in. DHCP usually is happy to provide the intruder an address if they’re not competent enough to pick one themselves (Although sniffers don’t need IP addresses)

• Port security prevents unauthorized HW addresses

#14 - port security & static tables (cont)

• It’s possible to change the hardware address, but this at least raises the bar. Also don’t forgot that a well-monitored switch will tell you in real-time that the printer was unplugged.

• Static table entries are a little different.– Switches learn which port devices are on– But until it learns, that traffic must be flooded– If the switch “unlearns” the port number, it will

flood the traffic (which may be SNMP)

#14 - port security & static tables (cont)

• Static table entries eliminate learning period

set cam static (Cisco)

static-mac-address (Foundry)

• These measures are probably too extreme except for critical servers and devices

• I do know of a company locking down 1000 systems by hardware address

#15 - Authenticate SNMP

• “Secure” SNMP has been vapor

• Best thing so far is keyed (authenticated) on Cisco (SNMP v2)

snmp-server party (instead of community)

#16 - SNMP access lists

• Remember I said earlier to restrict logins? This is the same thing for SNMP. Not as obvious but twice as important.

snmp-server access-list # (Cisco)

snmp-client/telnet-client/web-client (Foundry)

#17 - VPNs

• “VPN” is a virtual private network via an insecure path

• “Tunnel encapsulation” is not a VPN because it has no cryptography to prevent disclosure or packet injection

crypto isakmp policy & keys

crypto ipsec transform-set

crypto map

#17 - VPNs (cont)

• Similar cautions go for MPLS “vpn”. MPLS security depends on trusted paths.

• MPLS - think “virtual circuit”, not “vpn”

#18 - VLANs

• Don’t let VLANs share a common port

• I.e. don’t use HW address to determine VLAN membership

• Doing so makes system a de-facto gateway between VLANs

#19 - Routing ARP packets

• Do you need to route arp packets across networks?

no ip proxy-arp (Cisco/Foundry)

• otherwise use ip access lists on specific ports to prevent outgoing ARP hijacking and set ARP timeouts

• static arp entries also

arp <ip> <hw> arpa (Cisco)

arp <#> <ip> <hw> ethernet <port> (Foundry)

#20 - Layer 3 Packet Limits

• It’s possible to limit packet rates

ip icmp burst-normal & burst-max

(Foundry - net limits)

lockup (Foundry - timeout)

rate-limit (Cisco - limit ICMP and SYN rates)

#21 - Layer 2 Frame Limits

• unknown-unicast-limit (Foundry)

• broadcast limit, multicast limit (Foundry- limit/sec)

• set port broadcast <limit> (Cisco)

#22 - Reverse Network checks

• Goes beyond simple in/out/private address filters

• Verify reverse path (must be symmetric)

ip verify unicast reverse-path (Cisco)

#23 - LLC protocols

• LLC isn’t as harmless as you think

• Cisco Discovery Protocol (CDP) gives out information about your network, besides making it trivial to identify the most important devices on the network

no cdp enable (Cisco RSM)

set cdp disable (Cisco CatOS)

#23 - LLC protocols (cont)

• Spanning Tree Protocol (STP) - designed to prevent layer 2 loops

• It does this by turning off ports until there’s only one link to each device

• “Turning off ports”??? Still think it’s harmless??? And any idea what would happen if one of those ports turned back on? Trust me, it would be bad.

#23 - LLC protocols (cont)

set spantree root

set spantree disable # (Cisco CatOS)

span .. Priority <x>

no spanning-tree (Foundry)

• turn it off on ports to endusers, outsiders, people without access to multiple ports

#24 - Scheduler

• Cisco recommends scheduler limits to allow the device to respond when under attack (decreases the number of packets handled so the device is capable of responding to commands)

scheduler internal 500 or

scheduler allocate

#25 - Virtual/Hot Standby Router

• HSRP - Cisco’s protocol for multiple routers to cooperate, VRRP - Generic

• Routers agree which ones don’t route packets

• Don’t route packets??? Yikes!

• It’s possible to use plaintext auth string (no more secure than SNMP)

standby # authentication <string> (Cisco)

Random Cisco Links

• http://www.cisco.com/warp/public/707/21.html

• http://www.cisco.com/warp/public/707

• http://www.cisco/com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s5/sshv1.htm

Random Foundry Links

• http://www.foundrynet.com/techdocs/SRguide/FoundryManual_Security.html

• http://www.foundrynet.com/techdocs/SRguide/index.html

• http://www.foundrynet.com/techdocs/CLIref/CLI_Ref_global_Cfg_cmds.html

Conclusion

Just because everything is working doesn’t mean everything is ok. Don’t take your network security for granted.

palante@subterrain.net