Hardening Services and Features
We all know how important it is to harden the services that are running on our servers and workstations. Often overlooked areas of services, however, are the ones running on our routers and switches. For the same reasons that you disable unnecessary services on your servers and workstations, you want to disable unnecessary services on your routers and switches. Any services that are required you want to harden through whatever built-in security mechanism is supported. The following services and features are going to be reviewed:
| Cisco Discovery Protocol (CDP) | TCP and UDP small servers |
| Finger | Network Time Protocol (NTP) |
| Bootp server | Dynamic Host Configuration Protocol (DHCP) |
| Configuration autoloading | Name resolution |
| Proxy ARP | Directed broadcasts |
| IP source routing | ICMP Redirects, Unreachables, and Mask replies |
| Syslog | Simple Network Management Protocol (SNMP) |
| Implement loopback address | Disable unused interfaces |
| Configure core dumps |
Cisco Discovery Protocol (CDP)
Cisco Discovery Protocol is a proprietary management protocol. Although it can be useful for troubleshooting personnel, it also creates additional network traffic and can provide an attacker with useful network information. Therefore, it should probably be disabled. You can disable CDP on your IOS-based devices in one of two ways: You can disable it completely on the switch, or you can disable it on certain interfaces (for example, an external interface on a perimeter router). The same command is used in either method to disable CDP; however, it is run at a different mode of execution. To disable CDP completely, run the following command at the global configuration mode:
rtr-1721(config)#no cdp run
To disable CDP on a specific interface, simply run the command at the interface configuration mode. For example, if you wanted to disable it on interface FastEthernet 0, you would run the following commands:
rtr-1721(config)#interface fastethernet 0 rtr-1721(config-if)#no cdp run
You can disable CDP for the entire device or for individual interfaces on your CatOS-based devices, too. Here is the command to disable CDP for the device:
Console> (enable) set cdp disable all
If you wanted to disable CDP for a specific interface (for example, interface 3/1), you would run the following command:
Console> (enable) set cdp disable 3/1
TCP and UDP Small Servers
TCP and UDP small servers run a series of servers that, in theory, provide some diagnostic and informational types information, but in practice these are largely worthless features ”and in some cases they can be exploited by attacks such as the fraggle attack, which uses a UDP echo.
You can disable TCP and UDP small servers on your IOS-based devices by running the following commands at the global configuration mode:
rtr-1721(config)#no service tcp-small-servers rtr-1721(config)#no service udp-small-servers
CatOS-based devices do not support TCP or UDP small servers.
finger
The finger server is used by the finger protocol to gain information about the currently logged-on users from a network location. Because you can log onto the device and view the currently logged-on users by running the command show users , there is no reason to run a server that allows unauthenticated users to gain access to that same information.
You should disable finger on your IOS-based devices by running the following commands at the global configuration mode:
rtr-1721(config)#no ip finger rtr-1721(config)#no service finger
CatOS-based devices do not support finger.
Network Time Protocol (NTP)
As mentioned in previous chapters, NTP is used to synchronize time throughout your environment. This is a critical component of logging because you need accurate timestamps for all events if you want to be able to accurately determine what happened with your device in the event of an exploit or security incident.
You can approach NTP in two ways. The first way is to simply disable it on all interfaces on your IOS-based devices. You can do this by running the following command on every interface on the device:
rtr-1721(config-if)#ntp disable
You can disable NTP on your CatOS-based devices by running the following command:
Console> (enable) set ntp client disable
A better solution than simply disabling NTP ”because it does serve a valid purpose in your environment ”is to configure NTP to operate in a secure fashion. You can configure NTP to operate in a secure fashion by running the following commands on your IOS-based device:
rtr-1721(config)#service timestamps log datetime localtime msec rtr-1721(config)#service timestamps deb datetime localtime msec rtr-1721(config)#clock timezone CST 6 rtr-1721(config)#clock summer-time CDT recurring rtr-1721(config)#access-list 20 remark ACL for Remote NTP Server rtr-1721(config)#access-list 20 permit 192.168.173.99 rtr-1721(config)#ntp access-group peer 20 rtr-1721(config)#ntp authenticate rtr-1721(config)#ntp authentication-key 1 md5 ntpkey rtr-1721(config)#ntp trusted-key 1 rtr-1721(config)#ntp server 192.168.173.99 key 1
This configures the system to debug and log timestamps using the local date and time format. Next , it configures the appropriate time zone values based on U.S. standards. The remaining lines establish an ACL that specifies who the permitted NTP servers are and configures NTP to use authentication to ensure that the NTP host is who it claims to be. Once you have run these commands, you should disable NTP on any external interfaces, as previously described.
Configuring NTP on your CatOS-based devices requires you to run the following commands:
Console> (enable) set ntp timezone CST 6 Console> (enable) set ntp summertime enable CDT Console> (enable) set ntp summertime recurring Console> (enable) set ntp key 1 trusted md5 ntpkey Console> (enable) set ntp server 10.20.20.20 key 1 Console> (enable) set ntp client enable Console> (enable) set ntp authentication enable
The first three commands enable the time zone “ related information based on U.S. standards. The last four commands define the NTP key that should be used, define the NTP server that should be used, and enable the NTP client and authentication.
bootp Server
bootp is used by hosts to load their operating system over the network, typically by diskless workstations. You can use a Cisco router as a bootp server to provide IOS software to other Cisco equipment. In theory, this can be used as part of a deployment strategy for configuring your routers; however, in practice, there are a multitude of better deployment strategies. Consequently, you should disable bootp server on your IOS-based devices by running the following command from the global configuration mode:
rtr-1721(config)#no ip bootp server
CatOS-based devices do not support bootp.
Dynamic Host Configuration Protocol (DHCP)
DHCP is used to provide IP addresses to clients that request them. Cisco routers can act as a DHCP server to provide IP addresses to clients that request them. In most environments, however, a local server can provide DHCP services, or the router can be configured to support the forwarding of DHCP broadcasts (DHCP relay agent) to a centralized DHCP server with the ip helper-address command.
By default, the router should not be running a DHCP server; however, you can ensure that is the case by running the following command:
rtr-1721(config)#no ip dhcp pool <poolname>
CatOS-based devices do not support DHCP.
 |
The ip helper-address command actually forwards a number of broadcasts types by default. If want your routers to only forward DHCP broadcasts, you should restrict the protocols that will be broadcast by using the ip forward-protocol udp bootpc and ip forward-protocol udp bootps commands.
| |
Configuration Autoloading
Many Cisco devices are capable of pulling their configuration from a network device through a process known as configuration autoloading. This is a completely insecure process however as the device will pull the configuration from any server that offers one. In fact, some buddies and I used to use this to mess with each other in the lab by causing the devices to pull invalid configurations (geek humor is great <g>).
You can disable this functionality on you IOS-based devices by running the following commands from the global configuration mode of execution:
rtr-1721(config)#no boot network rtr-1721(config)#no service config
CatOS-based devices do not support configuration autoloading.
Name Resolution
Name resolution is used by IOS-based devices to support the entering of hostnames instead of IP addresses. However, if you have every mistyped a command on a device, you know that you will have to wait 20 “30 seconds for the name resolution to fail because, by default, the device attempts to broadcast the name query, and I have never encountered a name server that responds to this type of request. There are two methods in which you can approach name resolution. The first method is to disable name resolution completely. You can do this on your IOS-based devices by running the following command at the global configuration mode of execution:
rtr-1721(config)#no ip domain-lookup
You can perform the same thing on your CatOS-based devices by entering the following command:
Console> (enable) set ip dns disable
If you want to use name resolution and have trusted DNS servers that you can use, you can enable DNS by running the following commands on an IOS-based device:
rtr-1721(config)#ip domain-lookup rtr-1721(config)#ip name-server 192.168.173.100 rtr-1721(config)#ip domain-name wjnconsulting.com
For your CatOS-based devices, you can run the following commands:
Console> (enable) set ip dns enable Console> (enable) set ip dns server 10.20.20.20 Console> (enable) set ip dns domain wjnconsulting.com
Proxy ARP
Proxy ARP is used to allow systems on two different subnets that would not normally be able to communicate with each other to do so. Proxy ARP is typically implemented for dial-in PPP users. For a host to use proxy ARP, it is configured with its own IP address for its default gateway. This causes the host to ARP for all remote hosts. By default, Cisco routers will respond to this broadcast and then route the remote packets to the destination on behalf of the client. Outside of the very specific scenario of implementing proxy ARP to support dial-in users, however, you should disable proxy ARP. You can do this on your IOS-based devices by running the following command at the interface configuration mode for all interfaces on your device:
rtr-1721(config-if)#no ip proxy-arp
Proxy ARP is not supported in the CatOS.
Directed Broadcasts
Directed broadcasts allow a remote host to initiate a broadcast on a different LAN segment. As a result, directed broadcasts are typically used for generating a denial of service (DoS) attack by inundating a segment with broadcast traffic. Although most IOS-based devices disable directed broadcasts by default, you can explicitly disable them by running the following command at the interface configuration mode for all the interfaces on your device:
rtr-1721(config-if)#no ip directed-broadcast
Directed broadcasts are not supported in the CatOS.
IP Source Routing
IP source routing is used to allow the source to define the route a packet should take in the network (hence, the name source routing) . Source routing is used most commonly for token ring networks, and because it can be used for a number of different attacks, you should disable it unless you explicitly require it. You can disable IP source routing by running the following command at the global configuration mode of execution:
rtr-1721(config)#no ip source-route
IP source routing is not supported in the CatOS.
ICMP Redirects, Unreachables, and Mask Replies
Although ICMP messages provide a wealth of troubleshooting information, they can also be used by a malicious user to map and diagnose a network. Three ICMP messages in particular are commonly used for this purpose: redirects, unreachables, and mask reply messages. You should disable all these protocols by running the following commands at the interface configuration mode for all the interfaces in your device:
rtr-1721(config-if)#no ip redirects rtr-1721(config-if)#no ip unreachable rtr-1721(config-if)#no ip mask-reply
Your CatOS-based devices support redirects and unreachables, and you disable them by running the following commands:
Console> (enable) set ip redirect disable Console> (enable) set ip unreachable disable
syslog
As mentioned in previous chapters, syslog is used to provide a central repository of logging data that can be used for auditing and troubleshooting. You can configure syslog to send all events of a certain level or lower to a syslog server. For example, if you set the logging level at informational, all events from emergency events to informational events are sent to the syslog server. Because debugging should not be routinely occurring on your devices, I recommend that you do not send debugging events to the syslog server by default and instead use informational as the default syslog logging severity level. You can configure syslog on your IOS-based devices by running the following commands at the global configuration mode:
rtr-1721(config)#logging trap informational rtr-1721(config)#logging 192.168.173.114
You can enable syslog logging on your CatOS-based devices by running the following commands:
Console> (enable) set logging server enable Console> (enable) set logging server 10.20.20.20 Console> (enable) set logging server severity 6
| |
Note that syslog is transmitted in clear text. Although this is not a good thing, you are better off to configuring logging in clear text than to not use syslog at all. You can provide encryption to syslog data by configuring IPsec on the device and using IPsec to encapsulate the syslog data. IPsec configuration is covered later in this chapter.
| |
Simple Network Management Protocol (SNMP)
SNMP can be used to manage your network devices, providing configuration mechanisms as well as the monitoring of performance and device configuration. Although a low-level discussion of SNMP is beyond the scope of this book, it is important to understand the pros and cons of SNMP and how to securely implement SNMP on your network infrastructure devices. It is important to understand that if you are not actively using SNMP, you should disable it by running set snmp disable on your CatOS-based devices and no snmp-server on your IOS-based devices.
SNMP has three versions: SNMP v1, SNMP v2c. and SNMP v3. Both SNMP v1 and SNMP v2c are largely insecure protocols. Although they support the use of community strings as a rudimentary authentication mechanism, the data transported (including the community string) is done so in clear text, so it requires very little effort to compromise. SNMP v3 was implemented with authentication and privacy in the form of usernames, passwords, and the use of 56-bit DES encryption. Unfortunately, many vendors still do not support SNMP v3 for their devices. As a result, we are going to look at how to implement SNMP v1 and SNMP v2c and then at how to implement SNMP v3 separately.
Securing SNMP v1 and SNMP v2c
The only truly secure way to implement SNMP v1 and SNMP v2c is to encapsulate the data in an IPsec tunnel to prevent eavesdropping. We will cover how to implement IPsec later in this chapter. You can, however, undertake a number of steps to mitigate the insecurity of SNMP v1 and SNMP v2c through the use of ACLs and community strings. First, you should treat your community strings in the same manner as you would passwords. Second, you should review what you are using SNMP for and only grant SNMP access that is required. For example, if you are not using SNMP to configure devices, implement SNMP in a read-only mode.
You can configure SNMP on your IOS-based devices by running the following commands at the global configuration mode:
rtr-1721(config)#access-list 15 remark ACL to Permit SNMP rtr-1721(config)#access-list 15 permit host 192.168.173.114 rtr-1721(config)#snmp-server community <enterrostring> ro 15 rtr-1721(config)#snmp-server community <enterrwstring> rw 15 rtr-1721(config)#snmp-server host 192.168.173.114 traps <entercommstring>
The first two lines define an ACL that is used to specify what hosts are permitted to use SNMP to connect to the device. The next two lines define read-only and read-write community strings and assign the previously defined ACL to permit access. You should use different community strings for different degrees of access. The final line configures the device to send SNMP traps to a management station on IP address 192.168.173.114 using the specified community string.
You can enable SNMP v1 or SNMP v2c by running the following commands on your CatOS-based device:
Console> (enable) set snmp enable Console> (enable) set snmp access-list 1 10.20.20.20 Console> (enable) set snmp community read-only <enterrostring> Console> (enable) set snmp community read-write <enterrwstring> Console> (enable) set snmp trap 10.20.20.20 <entercommstring> Console> (enable) set snmp trap enable all
Again, if you do not require read-write access, you should disable it.
Securing SNMP v3 on Your IOS-Based Devices
Configuring SNMP v3 is more secure than SNMP v1 and SNMP v2c; however, it is also a much more complex process to implement. The following steps are required to implement SNMP v3 on your IOS-based devices:
-
Configure the SNMP-server engineID.
-
Configure the SNMP-server views.
-
Configure the SNMP-server group names .
-
Configure the SNMP-server hosts.
-
Configure the SNMP-server users.
Configure the SNMP-Server EngineID The SNMP server engineID is used to identify the local and remote SNMP entities. By default, your IOS-based device has a local engineID based on the MAC address of the device. You can enter a different SNMP-server engineID by running the following command at the global configuration mode of execution:
rtr-1721(config)#snmp-server engineid local <idstring>
You can also configure the remote entity engineID using the following command (this is optional):
rtr-1721(config)#snmp-server engineid remote 192.168.173.114 <idstring>
Configure SNMP-Server Views SNMP-server views define what part of the SNMP MIB tree will be accessible. For example, if you wanted to make all of the Internet MIB as well as all the sub-branches available, you could run the following command to create a view named readview :
rtr-1721(config)#snmp-server view readview internet included
Configure the SNMP-Server Group Names The next step is to configure the SNMP-server group names. This maps SNMP users to SNMP views, allowing you to control who can view what SNMP information. For example, you could create a group named readonly that has the ability to read the view you previously created (readview) and uses authentication and privacy by running the following command:
rtr-1721(config)#snmp-server group readonly v3 priv read readview
Configure SNMP-Server Hosts SNMP-server hosts define the destination for SNMP traps. You can configure SNMP traps by running the following command line:
rtr-1721(config)#snmp-server host 192.168.173.114 traps version 3 priv privpass
Configure SNMP-Server Users The last step is to configure the SNMP-server users who are allowed to connect. You can do this by running the following command:
rtr-1721(config)#snmp-server user wnoonan readonly v3 auth md5 <enterpassword> priv des56 <passphrase>
In this case, I created a user named wnoonan and made that user a member of the group readonly that was previously configured. I have also specified the use of MD5 authentication and, to ensure privacy, the use of 56-bit DES encryption.
Securing SNMP v3 on Your CatOS-Based Devices
Implementing SNMP v3 on your CatOS-based devices is largely the same process as on your IOS-based devices, but instead you use the CatOS-specific command syntax. You can enable SNMP v3 by running the following commands:
Console> (enable) set snmp engineid <engineID> Console> (enable) set snmp view readview internet included Console> (enable) set snmp access readonly security-model v3 privacy read readview Console> (enable) set snmp user wnoonan authentication md5 <authpass> privacy <privpass> Console> (enable) set snmp group readonly user wnoonan security-model v3
Implementing Loopback Address
You should configure the loopback address of the router to provide a stable and secure method of managing the device because the loopback interface is fixed. In addition, you can use the loopback interface as the source interface for a number of services and routing protocols, allowing you to configure the security of other devices more tightly because you need only grant access from the loopback address as opposed to one of the interfaces. Configuring the services in this manner means that packets sourced from the router are sourced from the IP address of the loopback interface.
Creating the loopback interface is a relatively straightforward process. Simply assign it an IP address as you would any other interface. One important note is that the loopback address cannot be an IP address in use anywhere else on the router, nor can it be a part of the same network as any other interface. Consequently, if you want to be able to access the loopback address from any other network, you will need to configure the appropriate routing functionality.
Setting a loopback ensures that all the traffic the router creates will be sourced from the same IP, thus facilitating better management and control. You can run the following commands from the global configuration mode of execution to implement a loopback address:
local-rtr(config)#interface loopback 0 local-rtr(config-if)#ip address 192.168.250.1 255.255.255.255
You can then reference the loopback address throughout the router configuration. For example, you can assign the loopback address as the source for FTP, TFTP, syslog, SNMP, and NTP, just to name a few, by running the following commands at the global configuration mode:
local-rtr(config)#ip ftp source-interface loopback 0 local-rtr(config)#ip tftp source-interface loopback 0 local-rtr(config)#logging source-interface loopback 0 local-rtr(config)#snmp-server trap-source loopback 0 local-rtr(config)#ntp source loopback 0
For more information about commands that support the loopback as a source interface, see the Cisco IOS Command Reference for your version of IOS software.
Disabling Unused Interfaces
As a standard practice, you should disable any unused interfaces. This will prevent someone from being able to locate an open jack and plugging something into the network ”in particular technicians who are adding network devices for which they may not have followed the appropriate change control procedures. You can disable interfaces on your IOS-based devices by running the following command at the interface configuration mode of all the device interfaces that need to be disabled:
rtr-1721(config-if)#shutdown
Disabling ports is much simpler on your CatOS-based devices because you can disable multiple ports with a single command:
Console> (enable) set port disable 3/1 Console> (enable) set port disable 3/1-3/10 Console> (enable) set port disable 3/1,3/3,3/5
The first command disables a single port, port 3/1. The second command disables ports 3/1 through 3/10. The third command disables ports 3/1, 3/3, and 3/5.
Configuring Core Dumps
We all like to joke about the blue screen of death on Microsoft Windows systems, but the truth is that all systems have the ability to core dump (I had at least 30 core dumps while I wrote just this chapter because the routers I was using did not have enough RAM to run OSPF and attempt to obtain a PKI certificate). To help in diagnosing the cause of router crashes, you can configure the router to offload the core memory to an external server. The most secure method of performing this is through the use of the FTP protocol:
remote-rtr01(config)#ip ftp source-interface loopback 0 remote-rtr01(config)#ip ftp username routeruser remote-rtr01(config)#ip ftp password routerpass remote-rtr01(config)#exception protocol ftp remote-rtr01(config)#exception dump 192.168.173.100
In this case, I have configured the router to perform a core dump to the FTP server at 192.168.173.100.
EAN: N/A
Pages: 125