Home Outline Lectures Labs/Tutorials Resources

Lecture #25 - Router Management

Router Security

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:

  • Set enable passwords on routers using the enable secret command. This encrypts the password using a non-reversable cryptographic algorithm.
  • Enable 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.
  • Disable routing of IP datagrams to directed broadcast addresses using the 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.
  • Disable IP source routing with the no ip source-route command. This prevents hosts from specifying the route that a packet must take through the network.
  • Use the scheduler interval or scheduler allocate command to ensure that the router does not spend excessive time servicing network interrupts and not handling other business.
  • Disable unnecessary services (eg. echo, daytime, chargen) using the no service tcp-small-servers and no service udp-small-servers commands. This is also disabled by default for IOS release 12.0 onwards.
  • Disable services such as finger and bootp, if they are not needed. Running no service finger and no ip bootp server would achieve this.
  • Lock down remote (vty) access using access control lists - more on this shortly.

Remote Management

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.

Do not use telnet!

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.

Restricting 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.

Configuration Management

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.

Copying Configuration Files

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.

Tracking Changes

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

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.

NTP

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

SNMP

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

Router Redundancy

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 1 
interface 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.254
Router 2 
interface 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.

Change Management

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:

Change Requests
Who is requesting the change, why is the change being requested and does the person requesting the change have the appropriate authority? Furthermore what impact is the change going to have on the network?
Change Approval
Depending on the change, approval may be required from senior staff and/or management.
Outages
If the change will result in an network outage then even more care is required and it should be scheduled so that it does not disrupt business. This may require that the changes be implemented out of hours.
Backout Plan
If a change is implemented, what is your backout plan should things go wrong?

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!)

References

RFCs

RFC3768 - Virtual Router Redundancy Protocol.

Other

Revision Control System (RCS)

Concurrent Versioning System (CVS)

Subversion.

The Network Time Protocol.

Cisco SNMPv3

Multi Router Traffic Grapher (MRTG)

Common Address Redundancy Protocol (CARP)