To save you time searching through thousands of documents and sometimes disjointed practices, here are some of our recommendations for securing Cisco routers. These practices can also be applied to other routers in general, though we provide no specifics for others.
Security is always a concern to those who manage and configure routers. Every router company has well documented suggested procedures and configurations for their routing platforms. Our generic policy involves a couple of basic principles:
- “perfect security is unusable”
- “secure all the possible windows and doors”
- “manage the windows and doors you must have carefully”
- and have a security policy for your network – but more on that later
Interfaces
Interfaces are doors and windows to your network and to your networking devices. Any time an interface is not being used for traffic or control, shut the interface off. There are also some great commands listed below to turn off certain functions that are on by default.
- Interface Function Command to disable
- Unused interfaces shutdown
- No Smurf attacks no ip directed-broadcast
- Mask replies no ip mask-reply
- Ad-hoc routing no ip proxy-arp
Unnecessary Services and Servers
Always shut down unnecessary services and servers on the router as they also act as virtual doors and windows to your network/devices. For instance if the router has an HTTP server, and your company does not use HTTP to access/control routers, then shut the HTTP server off. You can use the ‘show proc’ command to show current processes on the router.
This is a great starting point. We have listed the common ones we turn off below:
- Server Name Command to disable
- HTTP no ip http server
- BOOTP no ip bootp server
- Finger no service finger
- Small services (echo, discard, chargen, etc.)
- no service tcp-small-servers
- no service udp-small-servers
SNMP no snmp-server
If your network requires SNMP, then you should always configure an SNMP access control list (ACL) (Note: there are some best practices on Access Lists in General, below). Also use good quality SNMP community strings. The example commands below show how to remove the default community strings and set a better read-only community string, with an ACL:
Router(config)# no snmp community public ro
Router(config)# no snmp community private rw
Router(config)# no access-list 20
Router(config)# access-list 20 permit 10.10.10.1
Router(config)# snmp community 1tacot2go! ro 20
Services Name Command to disable
- CDP no cdp run
- Remote config. no service config
- Source routing no ip source-route
Lines
Another set of entrance/exit points are the “Lines”, specifically Console, VTY and AUX. Generically, if any of these are not used, shut them down. For the ones that must exist, make sure the sessions time out in a respectable amount of time, and that login’s and passwords are used (more on passwords in a moment). You will see below that we have shown some best practices for AUX and VTY lines.
Line Suggested Config:
Console Line line con 0
exec-timeout 5 0
login
Auxiliary Line:
line aux 0
no exec
exec-timeout 0 10
transport input none
VTY lines:
line vty 0 4
exec-timeout 5 0
login
transport input telnet ssh
Passwords
We always recommend using good quality passwords. They should contain upper and lower case, numbers, and at least one extended character. Always configure the “Enable Secret” password, which is protected with an MD5-based algorithm. We also highly recommend that you extend the configurations for CON, AUX and VTY Lines above with passwords. To provide basic protection for the user and line passwords using the “enable secret” service password encryption command: enable secret 0 Our56net$
Line Suggested Config:
Console Line
line con 0
password 1taco2go!
Auxiliary Line
line aux 0
password 1burrito2go!
VTY lines:
line vty 0 4
password 1burrito2go!
Basic protection service password-encryption
One last “Line” Related suggestion. We usually recommend that you use SSH instead of Telnet. Most decent configuration programs easily support SSH (our favorite is SecureCRT). But if you must use Telnet, then use an access list to control Telnet access.
Router(config)# no access-list 90
Router(config)# access-list 90 permit 14.2.10.1
Router(config)# access-list 90 permit 14.2.9.1
Router(config)# line vty 0 4
Router(config-line)# access-class 90 in
Logging
Almost all routers have the ability to keep logs of events. This is an often overlooked and powerful tool We suggest you turn on the router’s logging capability, and use it to log errors and blocked packets to an internal (secure and trusted) syslog host. Also, keep the routers and network devices properly configured for time. By having reliable logging and time stamped events, you have just increased your ability to trace network attacks with accuracy and repeatability. Sometimes tracking an attacker is more important than blocking them so that the community as a whole can learn from the attackers behaviors (a good read on the subject is a book we love: The Cuckoos Egg). Here are some example configs for logging and setting up the time clock in your devices:
Suggested Logging Configuration
Router(config)# logging on
Router(config)# logging 10.10.10.5
Router(config)# logging buffered
Router(config)# logging console critical
Router(config)# logging trap informational
Router(config)# logging facility local1
Suggested Time Clock Configuration (use two NTP sources)
Router(config)# service timestamps log datetime localtime show-timezone msec
Router(config)# clock timezone GMT 0
Router(config)# ntp server 10.1.1.1
Router(config)# ntp server 10.1.1.254
Use Access Control Lists
One of the most powerful features of Router IOS is that of access control lists (ACLs). The challenge is that they can be cumbersome and expensive to maintain. The use of ACLs is prescribed at a minimum level below, and we imagine a good network manager will expand and contract our recommendations suited to his/her specific need. Before we get to the “security” ACLS, a general recommendation: always clear out any previous versions of a given access list as a best practice. The process for this is to always enter the command “no access-list ###” as your first configuration command. For example:
Router(config)# no access-list 20
Router(config)# access-list 20 permit host 10.10.10.1
Router(config)# access-list 20 deny any log
The following are a list of what we think are great “base level” ACL protection.
A. Log access list port messages properly to the log and ensure that logs contain correct port number information, by using the port range arguments shown below at the end of an access list.
access-list 100 deny udp any range 1 65535
any range 1 65535 log
access-list 100 deny tcp any range 1 65535
any range 1 65535 log
access-list 100 deny ip any any log
The last line is suggested to ensure that rejected packets of protocols other than TCP and UDP are properly logged.
B. Another best practice (if you can support it in your network) is to constrain / enforce traffic address restrictions, particularly on the border points of the network and also log this when something fails. For instance, allow only internal addresses to enter the router from the internal interfaces, and allow only traffic destined for internal addresses to enter the router from the outside (external interfaces). At the same time, it is good practice to block illegal addresses at the outgoing interfaces. Besides preventing an attacker from using the router to attack other sites, it helps identify poorly configured internal hosts or networks also see RFC 2827?. Below are some examples:
Router(config)# no access-list 100
Router(config)# access-list 100 permit ip 10.10.10.0 0.0.0.255 any
Router(config)# access-list 100 deny ip any any log
Router(config)# no access-list 101
Router(config)# access-list 101 permit ip any 10.20.10.0 0.0.0.255
Router(config)# access-list 101 deny ip any any log
Router(config)# interface ethernet 0/1
Router(config-if)# ip access-group 100 in
Router(config-if)# exit
Router(config)# interface ethernet 0/2
Router(config-if)# ip access-group 100 out
Router(config-if)# ip access-group 101 in
C. Packets that are sourced from an untrusted network or that have obvious incorrect source networks (i.e. private addresses on the public network – also see RFC 1918)should be immediately filtered. Example networks are 0.0.0.0/8, 127.0.0.0/8, 10.0.0.0/8, 169.254.0.0/16, 172.16.0.0/20, 192.168.0.0/16. A word of caution here. Filtering through traffic can be processor impacting on some routing platforms. By blocking incoming packets that claim to have a source address of any internal (trusted) networks impedes TCP sequence number guessing and other attacks. If the network doesn’t need IP multicast, then block multicast packets. Also block broadcast packets. (Note that this may block DHCP and BOOTP services, but these services should not be used on external interfaces and certainly shouldn’t cross border routers.) Know that a number of remote probes and attacks use ICMP echo, redirect, and mask request messages, block them. (A superior but more difficult approach is to permit only necessary ICMP packet types.) Also, as we have stated above, you want to log these events. So lets look at some implementations of ACLs to cover the above issues:
Router(config)# no access-list 100
Router(config)# ! block our internal addresses
Router(config)# access-list 100 deny ip 15.1.0.0 0.0.255.255 any log
Router(config)# access-list 100 deny ip 15.2.0.0 0.0.255.255 any log
Router(config)# ! block special/reserved addresses
Router(config)# access-list 100 deny ip 127.0.0.0 0.255.255.255 any log
Router(config)# access-list 100 deny ip 0.0.0.0 0.255.255.255 any log
Router(config)# access-list 100 deny ip 10.0.0.0 0.255.255.255 any log
Router(config)# access-list 100 deny ip 169.254.0.0 0.0.255.255 any log
Router(config)# access-list 100 deny ip 172.16.0.0 0.15.255.255 any log
Router(config)# access-list 100 deny ip 192.168.0.0 0.0.255.255 any log
Router(config)# ! block multicast (if not used)
Router(config)# access-list 100 deny ip 224.0.0.0 15.255.255.255 any
Router(config)# ! block some ICMP message types
Router(config)# access-list 100 deny icmp any any redirect log
Router(config)# access-list 100 deny icmp any any echo log
Router(config)# access-list 100 deny icmp any any mask-request log
Router(config)# access-list 100 permit ip any 15.2.0.0 0.0.255.255
Router(config)# access-list 100 permit ip any 15.1.0.0 0.0.255.255
Router(config)# interface ethernet 0/0
Router(config-if)# description External interface
Router(config-if)# ip access-group 100 in
D. Using Access Lists to block incoming packets that claim to have the same destination and source address (i.e. a Land attack on the router itself) is highly recommended. You should incorporate this protection into the access list used to restrict incoming traffic into each interface, using a rule like the one shown below.
access-list 100 deny ip host 192.168.10.1
host 192.168.10.1 log
interface Ethernet 0/1
ip address 192.168.10.1 255.255.0.0
ip access-group 100 in
Security Policy
And finally but not any less importantly, any network manager should have a well communicated security policy within their network operations group (clearly protected by non-disclosure and confidentiality, of course). Security policies vary in detail from network to network. There are, nonetheless, some key components that should be covered in every policy. Here is a short list we recommend as a starting point:
- Consider adopting SSH, if your router supports it, for all remote access and configuration work
- Protect your router configuration file(s) by backing them up routinely on a secure server, and protect em from unauthorized disclosure
- Have a password policy and enforce it
- Always maintain the systems to the latest (IOS) releases
- Have logging process/procedure
- Ensure you have a “best practices” section
- Routine maintenance and update commitment
- Always test your network at regular (2 times a year) intervals (preferably by outsiders) to ensure security is properly maintained.