A router is at the core of your network infrastructure, hence it should be obvious that if someone can take over control of your router then they can effectively take over control of your network. This is not a good thing! Securing a router involves a large number of issues, all of which need to be considered. The following is not an exhaustive list, merely a starting point:
enable secret
command. This encrypts the password using a non-reversable
cryptographic algorithm.service password-encryption. This will encode
all other passwords (eg. OSPF and BGP passwords) using an XOR
function. This is not secure, however it will prevent casual
observers from noting the passwords if they happen to see the
configuration file.no ip directed-broadcast command. This
prevents a number of security attacks that make use of directed
broadcasts for traffic amplification. Note that this is disabled
by default for IOS release 12.0 onwards.no ip source-route
command. This prevents hosts from specifying the route that a
packet must take through the network.scheduler interval or
scheduler allocate command to ensure that the router does
not spend excessive time servicing network interrupts and not handling
other business.no service tcp-small-servers and
no service udp-small-servers commands. This is also disabled
by default for IOS release 12.0 onwards.no service finger and
no ip bootp server would achieve this.In many situations it is not practical, nor convenient to manage routers via a serial console. Remote management is almost an essential part of router administration, however it is also one that requires close attention from a security perspective.
This should be obvious - we do not want our passwords, commands and router configurations travelling over the wire in the clear. Instead you should use Secure Shell (SSH) which provides authentication and encryption.
SSH needs to be enabled and RSA keys need to be generated:
ip ssh hostname R1 ip domain-name latrobe.edu.au crypto key generate rsa
Issuing a show ip ssh command should now verify that SSH
is enabled. You should now reconfigure your virtual terminals (VTYs) to
allow SSH only:
line vty 0 4 login password mekmitasdigoat transport input ssh
The last line disables all other forms of input for remote access.
Even if you have disabled telnet and are only using SSH, it is still a good idea to restrict access to your administration network:
access-list 5 permit 192.168.50.0 0.0.0.255 access-list 5 deny any log ! line vty 0 4 access-class 5 in exec-timeout 10 0
Only a limited number of VTY ports are available on a router - the above
configuration will prevent potential denial of service attacks whereby an
attacker can make multiple connections to the router thus blocking legimate
access. Additionally, setting an exec-timeout will result in
sessions being automatically disconnected if they are idle for the specified
period of time.
One of the more interesting challenges in router management is dealing with the management of the router's configuration. Ideally you do not want to be constantly configuring routers via the IOS command line - it makes life a lot easier if you can create a configuration file and download it to the router. Likewise backing up the router's configuration and tracking changes in configuration are issues that need to be considered.
Cisco IOS allows configuration files to be loaded from and saved to network locations using the TFTP, RCP and SCP protocols. Out of these three we are really only interested in SCP due to the fact that the other two are highly insecure.
To load a configuration file onto a router we could use the following:
copy scp://user@host:configs/router1.conf running-config
To save a configuration file from a router we could use the following:
copy running-config scp://user@host:configs/router1.conf
Note that we could load or save the startup configuration simply by using
startup-config in place of running-config in the
above commands. Be careful though - the router will not parse the
configuration until it is rebooted, which may result in an unuseable
router if there is an error in the file.
When making changes to router configurations it is highly recommended that changes are tracked via some form of versioning system. This way if a configuration gets broken and something stops working, an older version of the configuration can be retreived and the router can be reconfigured so that it can resume normal operation. The alternative is that things remain broken until you can track down and resolve the problem that you introduced!
Tools that would allow for version tracking include the Revision Control System (RCS), Concurrent Versioning System (CVS) and Subversion. One approach would be to make changes to the configuration, check it into your versioning system, then copy the configuration file to the router from the versioning system. This also has the added benefit of introducing backups with no additional effort!
Logging should be enabled on your routers, both from a security and management point of view - without logging there is no record of who has logged in or what changes have been made. Additionally it can be beneficial to log traffic that has been blocked via ACLs. Furthermore all logs should be sent to a central log server to ensure that logs are kept in the one place. This also prevents logs from being erased in the case of a router being compromised.
Logging can be controlled via the IOS logging command:
service timestamp log datetime localtime ! logging console alerts ! logging trap 192.168.1.1 logging trap notifications logging facility local7
The above will enable timestamps (using localtime) for all logs, reduce console logging to only alerts and emergency messages and enabling logging to a syslog server having the IP address of 192.168.1.1.
In many cases attempting to debug network problems means comparing information from logs generated on numerous routers. If the clocks are not synchronised on all routers then debugging can become very difficult since the timestamps do not match up.
This problem can be avoided by the use of the Network Time Protocol or NTP. NTP allows for automatic synchronisation of time amongst devices. It is highly recommended that you run your own NTP server within your network - this server in turn can be synchronised from a stratum 2 source, or a locally connected time keeping device such as a GPS receiver (or atomic time clock if you're really keen :)
To enable NTP synchronisation on IOS:
ntp server 192.168.1.1
The Simple Network Management Protocol (or Scary Network Management Protocol?) allows for data collection that will facilitate administration and monitoring. All Cisco routers support SNMPv1, with SNMPv3 being supported from IOS release 12.0 onwards.
SNMP can be enabled by issuing an snmp-server command, with
options depending on your required configuration. For example, to enable
a read-only community with community string of 'mysecret' only accessible
from the 192.168.1.0/24 network:
access-list 10 permit 192.168.1.0 0.0.0.255 snmp-server community mysecret ro 10
A package such as MRTG can be used to monitor the router via SNMP and provide useful statistics in a graphical form. SNMP traps can be used to have the router notify an SNMP manager about system events or changes. For example, to have BGP changes "trapped" to 192.168.1.1:
snmp-server enable traps bgp snmp-server host 192.168.1.1 access
In many network configurations the failure of a single router can result in an outage for at least part of a network. Most hosts will be configured with the IP address of a single default gateway and if this router becomes unreachable traffic will simply disappear into a blackhole.
Router redundancy can be implemented in order to remove the single point of failure. Two routers need to be configured using a redundancy protocol such as the Virtual Router Redundancy Protocol (VRRP), Cisco's Hot Standby Routing Protocol (HSRP) or OpenBSD's Common Address Redundancy Protocol (CARP).
All of these protocols allow for two devices to be configured with the same IP address, in such a way that if one device fails the other automatically assumes the identity of the first and starts routing its traffic.
HSRP can be configured as follows:
Router 1interface Ethernet 0/0 ip address 192.168.0.1 255.255.255.0 standby 1 priority 120 preempt standby 1 authentication mekmitasdigoat standby 1 ip 192.168.0.254Router 2interface Ethernet 0/0 ip address 192.168.0.2 255.255.255.0 standby 1 authentication mekmitasdigoat standby 1 ip
Router 2 will learn about the standby IP address via HSRP hello messages. The priority and preempt allows the router with the highest priority to take over the active role, if it is currently being handled by another device. This would mean that Router 1 would always be the active device unless it stops responding to network traffic.
In corporate environments changes to router configuration needs to be handled in an appropriate manner. There are a number of issues that need to be considered, including:
A number of these issues are addressed via the use of a versioning system for router configurations. However, depending on the size and type of the business, a separate policy may be needed to detail the procedures that are to be followed for configuration changes. Finally, a log of all changes should be kept so that problems can be traced back to a configuration change (and the person responsible!)
RFC3768 - Virtual Router Redundancy Protocol.
Concurrent Versioning System (CVS)