Protocol Capabilities

There are a discrete number of protocols commonly used in network management. Most have major security issues around their use. This section outlines each of the main protocols and discusses its typical uses (and sometimes tools that use the protocol), the security considerations around the protocol's use, and deployment best practices, assuming the protocol is required. Specific options with the design of the network to best accommodate management (and insecure management protocols) are described later in this chapter.

Telnet/Secure Shell

I would wager that almost all readers of this book have used Telnet (and perhaps Secure Shell [SSH]) at some point in their computing experiences. As used in network management, Telnet and SSH allow a remote device to log in to a server and run commands. This server is traditionally a UNIX server, but in terms of network management, it can be a switch, router, firewall, NIDS, VPN gateway, web cache, load balancer, or almost anything else with an IP address.

Typical Use

In addition to interactive configuration changes made by an operator (such as accessing a remote router to change an access list), many automated network management tools use Telnet and SSH as a method of making automated configuration changes or enabling software upgrades. For example, a network management tool might run a script that accesses a large quantity of routers and adds access to a specific IP subnet in each router's access control list (ACL).

Security Considerations

As you might expect, the security considerations around Telnet and SSH are different.

Telnet uses TCP, which makes session hijacking difficult (because of sequence numbers) unless the attacker has access to the traffic flow of the Telnet session. If the attacker does access the traffic flow (or gets it through one of the methods described in Chapter 3, "Secure Networking Threats"), all the commands, usernames, and passwords that are sent between the client and the server can be read by the attacker. This is because Telnet does not encrypt any of the information sent on the wire.

SSH is superior to Telnet from a security perspective because cryptographic protections are provided for the session. SSH version 1 (v1) never made it through the standardization process, and SSHv2, as it is now known, is going through the final stages of review in the Internet Engineering Task Force (IETF). Implementations of SSHv1 and v2 can be currently found on a wide variety of IP-connected devices. Although SSHv2 is preferred over SSHv1 from a security standpoint, SSHv1 is still vastly superior to Telnet in the security it provides. The major mistake made in the typical use of SSH is not validating the RSA signature of a host prior to completing the connection. Man-in-the-middle (MITM) attacks like those implemented in the tool dsniff (Chapter 3 and Chapter 6, "General Design Considerations") can allow an attacker to pose as the SSH server. When you SSH to a server and see the following message, you are ideally supposed to validate that the signature for the host is indeed correct through some out-of-band means.

The authenticity of host 'ssh.somehost.com (192.0.2.50)' can't be established.
RSA key fingerprint is d9:7c:91:32:46:53:5a:2e:c7:26:43:6a:4c:20:8d:12.
Are you sure you want to continue connecting (yes/no)?

In reality, much like with the popular secure mail client Pretty Good Privacy (PGP), few go through this step. In a high-security environment this should be done, and for your management environment it isn't too difficult to distribute these fingerprints to all your management stations. By clicking "yes" without validating the fingerprint, you are taking a calculated risk that you or the server are not currently the victims of some type of MITM attack.

Deployment Best Practices

As a general rule, use SSH when possible and Telnet when necessary. SSH offers greater functionality and security. Some low-power devices don't have the capability to run SSH or, if they do, the CPU is unduly impacted. When using Telnet or SSH, it is useful to limit access to the Telnet/SSH daemon to the IP addresses that need it. The configuration for doing this is shown in Chapter 5. This should be considered desirable for SSH but required for Telnet with most security policies. The risks of allowing Telnet from anywhere on the network is very high.

When performing identity checks with Telnet or SSH, one-time passwords (OTPs) can be used to stop identity spoofing. However, this can cause problems with automated systems. A network management application that uses SSH or Telnet to do automated configuration changes to routers will be unable to generate the OTP to send; therefore, for those users you need a fixed password. If Telnet is used with this fixed password, it should be changed often.

HTTP/HTTPS

HTTP and HTTP Secure (HTTPS) are both used for many of the same functions that Telnet and SSH provide. Typically, they are used more for static configuration modifications and software updates. Some systems offer both an HTTP variant and either Telnet or SSH. Generally, the configuration is easiest to set up using one of the two tools (the other can be used as backup).

Typical Use

The typical use is the same as Telnet and SSH: provision devices, make configuration changes, check system status, and so on. HTTP also offers the capability to transfer files, which is not possible with Telnet or SSH unless SCP or SFTP are used (discussed later). HTTP is also commonly used as a monitoring viewer. An IDS system, for example, can send event data to a central server and display that data using HTTP or HTTPS.

Security Considerations

The security differences between HTTP and HTTPS broadly are the same as those between Telnet and SSH. HTTP, like Telnet, is cleartext and runs over TCP. HTTPS, like SSH, is cryptographically protected. HTTPS uses Secure Sockets Layer (SSL) or Transport Layer Security (TLS) for security and can also be vulnerable to the MITM attacks described earlier, though a careful inspection of the false certificate presented to the user during the attack can reveal its faults. This attack is further described in the "dsniff" section of Chapter 3.

Deployment Best Practices

HTTPS should be preferred to HTTP. In both cases, L3 filtering should limit who is able to establish connections to the HTTP server, but this should be considered essential for HTTP. If you are comfortable with your management options using SSH, there is no need to also run HTTP or HTTPS. Try to limit the management protocols on a given device to those that are necessary to manage the device properly.

Simple Network Management Protocol

Simple Network Management Protocol (SNMP) is designed exclusively to enable remote management of networked systems. SNMP has gone through a number of revisions in its history. SNMPv1, v2c, and v3 are the most common, with v3 not yet in wide use. This is unfortunate because only SNMPv3 has reasonable security. SNMP is UDP-based and runs on port 161 for most functions and 162 for SNMP traps.

Typical Use

Today's networks primarily use SNMP for monitoring. Occasionally you will find organi-zations that make configuration changes through SNMP, but the majority uses Telnet or some other interactive session. If you are simply monitoring information by using SNMP, you can set your SNMP server to read-only, as shown in Chapter 5. Making configuration changes through SNMP can be done only with read-write access from the SNMP manager. Traps can also be sent over SNMP. These messages are similar to the events you can view using Syslog, and there isn't a lot of call to do both. Because Syslog is more widely adopted in security devices, it is probably most appropriate.

Because of the history of poor security (see next section), most security devices do not make much use of SNMP. Over time, I would expect this to change as SNMPv3 gains broader adoption on network devices and management platforms. Cisco Systems, for example, supports v3 in its routers and switches, but most network management applications from Cisco do not yet support v3.

Security Considerations

Because SNMPv1 and v2c do not support any form of strong authentication or encryption, they are not considered secure. The only form of password is a community string that is sent in the clear. This is compounded with SNMP's use of UDP. Attackers can spoof packets fairly easily if the appropriate precautions aren't taken. Table 16-1 is taken straight from the Cisco 12.2 IOS documentation and shows the security options available for SNMP.

Table 16-1. SNMP Security Comparison by Version

Model	Level	Authentication	Encryption	What Happens
v1	noAuthNoPriv	Community string	No	Uses a community string match for authentication
v2c	noAuthNoPriv	Community string	No	Uses a community string match for authentication
v3	noAuthNoPriv	Username	No	Uses a username match for authentication
v3	authNoPriv	MD5 or SHA	No	Provides authentication based on the HMAC-MD5 or HMAC-SHA algorithms
v3	authPriv	MD5 or SHA	DES	Provides authentication based on the HMAC-MD5 or HMAC-SHA algorithms; provides DES 56-bit encryption in addition to authentication based on the CBC-DES (DES-56) standard
Table 16-1 Source: Table 18http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/ffun_c/fcfprt3/fcf014.htm

 

Deployment Best Practices

Some security purists prefer almost no management functions enabled on devices and certainly not SNMP. Although this eliminates some security issues with the management protocols, more security issues are introduced by the organization's inability to monitor and maintain the network. With that in mind, use SNMP where it adds significant value, giving preference to v3 but using v1 or v2c where no secure alternative exists. The following best practices will improve the security of your SNMP use regardless of version.

For all versions of SNMP, it is important to use an ACL on the SNMP process to limit the addresses able to send SNMP commands to the device. This is shown in Chapter 5 and should be considered essential for v2c or v1 SNMP. In addition, be sure to implement antispoof filtering as shown in Chapter 6 to prevent another device on your network from spoofing the traffic to the server. Because SNMP is UDP based, spoofing can be a big problem. Finally, if you do need to use v1 or v2c and community strings, treat the strings like root passwords by changing them often and making them difficult to guess.

Even when using SNMPv3, be aware that DES isn't considered acceptable encryption by many because it can be brute forced with the right hardware and time (see Chapter 10, "IPsec VPN Design Considerations"). That said, DES is vastly superior to the encryption options in SNMPv1 and v2c. (There are none.) The SNMPv3 standard was written to support additional encryption options, so I'm sure v3 will support some variant of AES in the future.

TFTP/FTP/SFTP/SCP

These four protocols all enable the transfer of files from one device to another. The first, Trivial File Transfer Protocol (TFTP), is UDP based (port 69), cleartext, and supports no authentication. The triple crown of insecurity!

NOTE

I always like to joke when I give talks that TFTP is only a 10-page RFC (RFC 1350) and as such has no room for security. In reality, it was never meant to be secure. There is a reason "trivial" is in the name.

File Transfer Protocol (FTP) rides over TCP, and its specific operation (active versus passive) is discussed in Chapter 8, "Common Application Design Considerations." Unlike TFTP, FTP supports user authentication, but all communications are still sent as cleartext. Secure Copy (SCP) and Secure FTP (SFTP) are both secure file transfer protocols that use SSH. Not all systems that support SSH also support SFTP and SCP, but many do. SCP is a quick copy much like Remote Copy (RCP). The following shows a basic use of scp to copy a file from one location to another.

[sejal:~/temp] sconvery% scp test.txt sconvery@172.19.93.147:test.txt
The authenticity of host '172.19.93.147 (172.19.93.147)' can't be established.
RSA key fingerprint is 67:6e:a2:fa:5f:28:17:08:f8:03:03:3c:85:31:b4:0d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.19.93.147' (RSA) to the list of known hosts.
sconvery@172.19.93.147's password:
test.txt 100% |*****************************| 0 00:00

SFTP is an interactive file transfer like traditional FTP.

Typical Use

These protocols are used to transfer files between hosts.

Security Considerations

The security considerations have mostly been covered already. Use SCP, SFTP, or HTTPS for file transfer whenever possible. If needed, use FTP or HTTP, but beware of situations in which your authentication information or file contents could be sniffed. Understanding the way FTP active mode works is useful because it underscores the value that stateful filtering provides.

TFTP should be used as a last resort, but it is very handy because it is simple. Of special note is the way in which TFTP handles UDP communications because it illustrates how decisions made at the protocol level can dramatically affect security. Here is what a simple TFTP transfer from my computer looks like:

[sejal:~/temp] sconvery% tftp 10.1.1.150
tftp> get test.txt
tftp>

The packets look like this:

[sejal:~] sconvery% sudo tcpdump host 10.1.1.150
tcpdump: listening on en0
17:36:42.228991 10.1.1.9.55352 > 10.1.1.150.tftp: 20 RRQ "test.txt"
17:36:42.229734 10.1.1.150.1091 > 10.1.1.9.55352: udp 4
17:36:42.229820 10.1.1.9.55352 > 10.1.1.150.1091: udp 4

Because this is UDP, no connection establishment is required. The first packet sends a read request (RRQ) from a random high port on my host to the TFTP port (69) on the server asking for test.txt. The TFTP server responds by picking its own UDP high port and sending the file to my host. My host then acknowledges receipt of the file, and the transfer is done. So, where is the security problem (besides the fact that there was no authentication or encryption)? It lies in the server's selection of its own high port that the sending client has no way of anticipating in advance. A stateless ACL on my host would need to permit all UDP high ports into my system from the TFTP server because the port the server uses is unknown. This is unlike a protocol like HTTP, for which the client knows to expect the responses to have the source port of 80. It is also unlike active mode FTP, which, although it changes ports, allows the client to specify the port the FTP server should use through the PORT command.

Deployment Best Practices

Always try to use a secure file transfer protocol. It is often not possible, though, because many network management systems still require cleartext protocols such as TFTP to function. Filtering the IP addresses that can access the file transfer process can lessen the security risk, but for the same reasons identified earlier for Telnet and HTTP, the risks cannot be eliminated.

As a result, you often must design your network management topology carefully to account for these protocols. Options for this are discussed later in this chapter.

Syslog

The Syslog protocol (RFC 3164) was originally developed for Berkeley Software Distribution (BSD) UNIX, but it has since been ported to many other network devices. A network device sends Syslog messages on UDP port 514 to a Syslog collector. These collector devices usually receive data from a large number of sources and then allow sorting and alerting based on the data sent. Every stock UNIX system can act as a Syslog collector or sender. The following are the last 10 messages generated by the firewall protecting my home network (IPs were changed):

cerberus:/home/sean# tail -f /var/log/cisco
Apr 26 12:05:16 10.1.1.1 %PIX-4-106023: Deny udp src outside:201.156.6.238/1031
dst inside:192.0.2.7/137 by access-group "101"
Apr 26 12:07:54 10.1.1.1 %PIX-4-106023: Deny udp src outside:203.7.130.134/1026
 dst inside:192.0.2.7/137 by access-group "101"
Apr 26 12:11:41 10.1.1.1 %PIX-4-106023: Deny tcp src outside:207.21.115.3/1964
 dst inside:192.0.2.7/1080 by access-group "101"
Apr 26 12:11:58 10.1.1.1 %PIX-4-106023: Deny tcp src outside:207.21.115.3/1965
dst inside:192.0.2.7/6588 by access-group "101"
Apr 26 12:16:04 10.1.1.1 %PIX-4-106023: Deny udp src outside:204.187.16.201/1513
 dst inside:192.0.2.7/1434 by access-group "101"
Apr 26 12:18:05 10.1.1.1 %PIX-4-106023: Deny udp src outside:60.59.164.104/1028
dst inside:192.0.2.7/137 by access-group "101"
Apr 26 12:18:29 10.1.1.1 %PIX-4-106023: Deny udp src outside:
202.175.111.170/61615 dst inside:192.0.2.7/137 by access-group "101"
Apr 26 12:22:40 10.1.1.1 %PIX-4-106023: Deny udp src outside:
203.213.206.123/1027 dst inside:192.0.2.7/137 by access-group "101"
Apr 26 12:25:15 10.1.1.1 %PIX-4-106023: Deny udp src outside:210.31.20.195/17410
dst inside:192.0.2.7/137 by access-group "101"
Apr 26 12:28:04 10.1.1.1 %PIX-4-106023: Deny udp src outside:80.132.90.105/1028
dst inside:192.0.2.7/137 by access-group "101"

As you can see, every few minutes someone tries to connect to my server using NetBIOS (UDP 137). Most are automated scans looking for unprotected systems with weak passwords on their file shares.

Typical Use

Syslog is used in a wide variety of ways in network management. From a security perspective, it is often the lowest common denominator of log information. Almost every security device should be able to send some kind of Syslog information to a collector. These collectors can then log the data for historical reasons or represent it in an alarm console for the operator to see and respond to. The key with Syslog (and other logging systems) is to choose sensible logging levels. This is discussed later in the chapter.

Security Considerations

Although Syslog is often used in a security role, the protocol isn't particularly secure. It uses UDP without authentication and has no mechanism to ensure the delivery of a message. Devices generating Syslog are "fire and forget": after a message is sent, they never know if the message was delivered or not. This makes the protocol very efficient from a processing standpoint but also somewhat sloppy in that messages can be lost. If an attacker knows a target system has Syslog running, the attacker could choose to congest the network between the Syslog generator and the collector. This way, messages will be lost on the way to the collector.

NOTE

There is a working group in the IETF that is evaluating improvements to Syslog to address, among other things, the lack of reliable message delivery. Vendors have occasionally implemented proprietary extensions to Syslog to address this issue. The Cisco PIX Firewall, for example, includes an option to run Syslog over TCP.

 

Deployment Best Practices

Syslog is a great catch-all management system for both security and other general networking events. Configuring Syslog on Cisco devices is covered in Chapter 5. The secure management deployment options discussed later should be strongly considered when using Syslog to increase the security of the message transit from generator to collector.

The performance impact of Syslog should also be considered. Some hardware-based forwarding engines (such as those found in higher-end routers and switches) are significantly slowed by logging. This is because logging the event requires the involvement of the CPU on the device to generate the message. I expect vendors to fix this issue over time, but examine the capabilities of your devices closely before you turn on logging of certain messages. As mentioned earlier in this section, be sure also to read the information on logging levels later in this chapter.

NetFlow

NetFlow is a software feature initially available on Cisco routers. Similar functionality is now available in other vendors' gear as well. The core function of NetFlow is to record information about each flow sent across a router. A flow is defined as the set of traffic matching the following characteristics:

• Source address
• Destination address
• Source port
• Destination port
• IP protocol type
• Type of service (TOS) bits
• Input interface

These flows are unidirectional. A flow is completed either when a timeout expires or, in the case of TCP, when a FIN/RST bit is set in the TCP header. Refer to the NetFlow documentation for more specifics regarding flow termination. The information recorded on each flow can be viewed on the router or sent to an external collector system for processing.

Typical Use

NetFlow data can be used for performance monitoring, billing, or, as we are primarily concerned with, security monitoring. By evaluating the flows that cross a router, you can determine how the network is behaving in aggregate. SNMP will tell you the utilization on your links but not the makeup of the traffic on those links. Sniffing will give you every packet sent on a link but is too data intensive to use all the time. NetFlow strikes a balance between the two by recording the flows as they occur, providing the packet sizes of the flows, the number of packets sent, and other useful information but not the packets themselves. To enable NetFlow on a Cisco router, simply type the following at the interface configuration level:

router(config-if)#ip route-cache flow

To view the flow information on a router, simply type show ip cache flow. The following is sample output:

router#show ip cache flow
IP packet size distribution (703 total packets):
 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
 .000 .852 .103 .012 .009 .000 .000 .009 .009 .000 .000 .000 .000 .000 .000

 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
 .000 .001 .000 .000 .000 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 278544 bytes
 2 active, 4094 inactive, 84 added
 1444 ager polls, 0 flow alloc failures
 Active flows timeout in 30 minutes
 Inactive flows timeout in 15 seconds
 last clearing of statistics never
Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)
-------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow
TCP-Telnet 9 0.0 59 44 0.0 17.4 10.8
UDP-DNS 7 0.0 2 62 0.0 0.0 15.6
UDP-NTP 53 0.0 1 76 0.0 0.0 15.3
UDP-other 13 0.0 2 183 0.0 0.0 15.5
Total: 82 0.0 7 53 0.0 1.9 14.9

SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
Fa0/1 1.0.0.100 Null 1.255.255.255 11 008A 008A 2
Fa0/0 16.0.0.100 Local 1.0.0.1 06 80AE 0017 69

In the preceding data, you can see the breakdown of packet sizes (most common is 64-byte packets), the most common traffic types, and (at the end) the currently active flows. This kind of data in the hands of a security professional could help identify the following conditions:

• DoS attacks Unusually high amounts of packets, flows, large packets, or some combination of the three
• Worms Unusually high amounts of traffic on a specific TCP or UDP port

This data can be used to identify other conditions on the network when the operator understands what is considered normal. For example, if you don't allow Telnet anywhere on your network but you suddenly see Telnet traffic through NetFlow, you know there is a security policy violation. By analyzing the NetFlow data, you will be able to tell roughly which are the affected systems as well.

To enable export of the NetFlow data, type the following command:

Router(config)# ip flow-export destination ip-address udp-port

There are a wide variety of NetFlow collector software packages. To get an idea of their capabilities, take a look at cflowd on CIADA's website: http://www.caida.org/tools/measurement/cflowd/.

Several commercial tools are available that process NetFlow data in a more security-oriented manner. Arbor Network's Peakflow product line is one example: http://arbornetworks.com.

For more information on configuring NetFlow, refer to the Cisco documentation at http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fswtch_c/swprt2/xcfnfc.htm.

Security Considerations

The security considerations for NetFlow are the same as those for Syslog. The data is sent using UDP and is not reliable. That said, the strength of NetFlow for security is the aggregate of all the data sent by a device. If a specific message is lost, it is not as critical as a lost Syslog message in most networks.

Deployment Best Practices

NetFlow has a few deployment considerations. First, be sure to understand the performance implications of the NetFlow process. This varies from platform to platform and is affected by the number of flows that commonly traverse the router. Some router versions offer the capability to summarize NetFlow data in very high-utilization environments. Second, like Syslog, try not to have the NetFlow data travel over a long distance. The lack of reliability in UDP gets worse and worse the farther you are from the destination. In terms of deployment locations, the principal location of interest for security folks is the Internet edge router(s). This will give you early warnings on worms, denial of service (DoS), and other nastiness originating from the Internet. You might also consider enabling NetFlow at key choke points in your internal network.

NetFlow can be used in a real-time fashion (as you might use it to determine the traffic type of a new worm) or in a historical fashion to establish trends on the network.

Others

A large quantity of proprietary management protocols are designed to do some combination of the functions described so far in this chapter. Earlier versions of Cisco NIDS appliances used a protocol called Post Office, which ran over UDP port 45000. These protocols can be as secure or insecure as any other, though the lack of widespread peer review often harms the security of proprietary protocols.

Also, a wide range of management standards is in development. The Operations and Management area of the IETF is a good place to start if you are interested in these efforts: http://www.ietf.org/html.charters/wg-dir.html#Operations%20and%20Management%20Area.

From a security industry perspective, the lack of common, effective, and implemented standards for all areas of security management is the single biggest impediment to the effective use of security technologies today. The problem is so big that there aren't even effective vendor-specific tools that do everything right.

Even if there were, a mixed-vendor security environment is a requirement because the security capabilities you implement in your hosts, network infrastructure, and security-specific appliances will never be delivered by the same company. Even if you bought everything Cisco sold for secure networking, you'd still need antivirus, e-mail filtering, and proxy servers from other vendors, just to name a few. This doesn't even consider all the host-specific events generated by all the end systems in your network. When you try to aggregate the information from all these sources in a common management system, standards become essential to make sure the data can be properly collected and analyzed.

Although there are promising developments in this area from a product standpoint, it will still be a number of years before the security industry can consider this problem solved. In the meantime, the best practices described at the end of this chapter will help significantly in making do with what you have.