Hardening Your Network Management Protocols

Hardening Your Network Management  Protocols

You will use a number of network management protocols on your network, including Cisco NetFlow, RMON, SNMP, syslog, TFTP, and Cisco Discovery Protocol (CDP). All these protocols share some common flaws, including the lack of any kind of data encryption or integrity mechanisms. In a number of the chapters in this book, we took a look at what can be done to secure or turn off these protocols for each device type, including firewalls, routers, and switches. With the sole exception of SNMP, there isn t much you can do with the protocols themselves to secure them. It s the old catch-22 of how to secure an insecure protocol. Well, the good news is that we can do something, at least for those protocols that utilize TCP/IP (which includes Cisco NetFlow, RMON, SNMP, syslog, and TFTP), and that is to encapsulate the traffic in IPSec. Although this technically does nothing for the protocols themselves , it at least ensures that the data is transmitted via a secure mechanism, effectively providing the kind of security you need for your network management traffic. We are going to look at how to configure IPsec on a Microsoft Windows 2000 server to allow it to communicate with your network devices. The device-specific IPsec configurations are covered in their respective chapters (see Chapter 3 for firewalls and Chapter 6 for routers and switches).

Configuring IPsec on Microsoft Windows 2000

IPsec is configured on Microsoft Windows 2000 systems through the use of the local security policy. The following steps detail how to configure the Microsoft Windows 2000 system to send all traffic to and from the given network device via IPsec.

The first step is to create the IPsec policy:

1. Open the Local Security Policy administrative tool.

2. Right-click IP Security Policies on Local Computer and select Create IP Security Policy. This will start the IP Security Policy Wizard. At the Introduction screen, click Next .

3. At the IP Security Policy Name screen, enter the appropriate name and description. When you are finished, click Next.

4. At the Requests for Secure Communication screen, uncheck Activate the Default Response Rule and click Next.

5. At the Finish screen, leave the Edit Properties box checked and click Finish.

The next step is to configure the filter list from the Microsoft Windows 2000 host to the device that will be managed:

1. At the NMS Security Policy Properties screen, clear the Use Add Wizard check box and click Add.

   

2. At the IP Filter List tab, click Add.

3. At the IP Filter List screen, enter the appropriate filter list name and description, as shown next. Clear the Use Add Wizard check box and click Add.

   

4. At the Filter Properties screen on the Addressing tab in the Source Address section, select A Specific IP Address and enter the IP address of the server. In the Destination Address section, select A Specific IP Address and enter the IP address of the device you want to communicate with. Finally, clear the Mirrored check box. The following is an example of what the screen should look like:

   

5. Click the Protocol tab and verify that Any is selected.

6. Click the Description tab and enter an appropriate description. You can copy the description from step 3. When you are finished, click OK and then click OK again.

The next step is to configure the filter list from the device that will be managed to the Microsoft Windows 2000 host. This process is an almost duplicate of the preceding process, switching the source and destination addresses:

1. Click Add at the IP Filter List tab.

2. At the IP Filter List screen, enter the appropriate filter list name and description, as shown next. Clear the Use Add Wizard check box and click Add.

   

3. At the Filter Properties screen on the Addressing tab in the Source Address section, select A Specific IP Address and enter the IP address of the device you want to communicate with. In the Destination Address section, select A Specific IP Address and enter the IP address of the server. Finally, clear the Mirrored check box. The following provides an example of what the screen should look like:

   

4. Click the Protocol tab and verify that Any is selected.

5. Click the Description tab and enter an appropriate description. You can copy the description from step 2. When you are finished, click OK and then click OK again.

The next step is to configure a rule for the tunnel from the Microsoft Windows 2000 server to the device that will be managed:

1. You should still be at the New Rule Properties screen with the two new IP filter lists you created displayed on the IP Filter List tab. Select the first filter list that you created (that is, Microsoft-to-Cisco) and click the Tunnel Setting tab.

2. Select the option The Tunnel Endpoint Is Specified By This IP Address and then enter the IP address of the remote device, as shown here:

   

3. Click the Connection Type tab and select All Network Connections.

4. Click the Filter Action tab, clear the Use Add Wizard check box, and click Add.

5. Click the Negotiate Security option and click to clear the setting Accept Unsecured Communication, But Always Respond Using IPSec. Click Add.

6. At the New Security Method screen, select Custom and then click Settings.

7. At the Custom Security Method Settings screen, enter the appropriate Data Integrity and Encryption settings. I recommend using SHA-1 and 3DES for the highest level of security. If the remote device will be configured with session key settings, enter them here, as shown next. When you are finished, click OK and then click OK again.

   

8. At the New Filter Action Properties screen, click the General tab and enter the appropriate name and description, as shown next. When you are finished, click OK.

   

9. At the Filter Action tab, select the filter action you created.

10. Select the Authentication Methods tab and click Add to add a new authentication method.

11. At the New Authentication Method Properties screen, select the appropriate authentication method and click OK. In this case, I clicked Add, selected pre-shared keys, and entered a pre-shared key for ease of implementation. However, you should use certificates in your environment if possible because certificates are more secure and will scale better. Remove any other authentication methods and click Close.

    Note  

    See http://support.microsoft.com/default.aspx?scid=kb;en-us;253498 and http://www.microsoft.com/windows2000/techinfo/planning/security/ipsecsteps.asp for information about how to add a certificate for use in IPsec on Microsoft Windows XP, 2000, and 2003 systems.

The last step is to configure a new rule for the traffic that flows from the device that will be managed to the Microsoft Windows 2000 host. Because you have already configured most of the filter lists and other settings you will be using, the process is much shorter:

1. At the Security Policy Properties screen, click Add to create a new rule.

2. At the IP Filter List tab, select the filter list for the traffic from the device that will be managed to the Microsoft Windows 2000 host.

3. At the Tunnel Setting tab, select the option The Tunnel Endpoint Is Specified By This IP Address and then enter the IP address of the server.

4. At the Filter Action tab, select the filter action you created.

5. At the Authentication Methods screen, add the same authentication method you previously configured and remove any other authentication methods.

6. When you are finished, click OK. Your security policy should look something like the screen shown next. Click Close to finish creating the new security policy.

   

The final task is to assign the IPSec security policy that you created by right-clicking the security policy and selecting Assign, as shown here:

At this point, you can configure the remote host to use IPsec. It is important to make sure the various components of IPsec match exactly on both clients . Table 10-1 shows how I have configured the settings on both the Cisco PIX firewall and the Microsoft Windows XP host in this chapter.

Table 10-1: Matching IPsec Settings

	Cisco PIX	Microsoft Windows
Peer Settings	192.168.173.114 (Microsoft server)	192.168.173.97 (Cisco PIX)
Transform Set/Filter Action	ESP, 3DES, SHA	ESP, 3DES, SHA
IPsec Authentication Method	Pre-shared Key	Pre-shared Key
IPsec Encryption Method	3DES	3DES
IPsec Integrity Method	SHA1	SHA1
Key Lifetime	28,800 seconds	28,800 seconds
Diffie-Hellman Group	Group 2	Group 2
IKE Encryption Method	3DES	3DES
IKE Integrity Method	SHA1	SHA1

For example, if the remote host was a Cisco PIX firewall, I could run the following commands (based on how I configured the Microsoft Windows 2000 server earlier):

 access-list secure-nms permit ip interface inside host 192.168.173.114 sysopt connection permit-ipsec crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac crypto map secure-nms 30 ipsec-isakmp crypto map secure-nms 30 match address secure-nms crypto map secure-nms 30 set peer 192.168.173.114 crypto map secure-nms 30 set transform-set ESP-3DES-SHA crypto map secure-nms interface inside isakmp enable inside isakmp key presharedkey address 192.168.173.114 netmask 255.255.255.255 isakmp policy 10 authentication pre-share isakmp policy 10 encryption 3des isakmp policy 10 hash sha isakmp policy 10 group 2 isakmp policy 10 lifetime 28800 

As Figure 10-1 shows, all the traffic between hosts 192.168.173.114 and 192.168.173.97 is being encapsulated in ESP IPsec packets (in this case, that traffic is syslog and Telnet traffic). This allows the server and the remote host to communicate with each other only using IPsec, thereby encapsulating all the insecure TFTP, syslog, SNMP, RMON, and any other traffic in the secure IPsec tunnel.

Figure 10-1: Ethereal Capture of IPSec Traffic