Last week I wrote an article that demonstrated the grievous security oversight in the Telnet protocol. Telnet, being a clear text protocol, exposes the entire contents of any session to anyone who can gain access to the traffic. Telnet is not the only management protocol that lacks built in encryption capabilities. Other protocols, including but not limited to SNMP (versions 1 and 2), http, syslog and ftp, have similar shortcomings. This article addresses, at a high level, some of the techniques that can be used when an insecure protocol is the only option.
In some cases, there is no secure alternative to otherwise insecure management protocols. In that case, it is very important to understand what is at risk and what some of the mitigation techniques are. When protocols lack their own ability for encryption, the primary objective of a security conscious administrator should be to keep the packets out of the hands of any untrusted party. This article identifies some of the features that may be available in a Cisco network to help with this objective.
The first thing that I recommend is controlling the access to any management protocol. This is especially true with unsecured management protocols. Just because the security conscious administrator knows where it may be acceptable to connect to an insecure protocol from, doesn’t mean that all members of the team share the security concerns. In that case, a more security conscious admin may only connect from a trusted LAN, but a junior engineer may connect to it from an untrusted network and expose sensitive information. In a Cisco network, access to insecure management interfaces can be controlled through transit acl’s (access-lists) or by using and access-class specifically on the management interface (vty or http).
The next technique is to overcome the limitation with encryption. This is often done with some sort of IPSec tunnel to create a VPN between the two devices using an insecure protocol. This is a relatively secure method when it can be employed end to end. In some cases, there may be some limitation in the equipment that may not allow for end to end encryption. At a minimum, this type of encryption should be used across any untrusted network segments.
Earlier I mentioned that it is important to keep the unencrypted packets from being exposed to untrusted parties. We have covered two techniques for this already. The first was to not allow the session to be created thus sensitive packets don’t really exist. The second method used encryption in order to make them unintelligible if an untrusted party did gain access.
Those techniques cover many of the concerns. However, the cases still exist when packets carrying insecure protocols are often transmitted in clear text through a portion of a trusted network. Statistically speaking, many attacks on technology resources come from inside threats. Additionally, many external threats use “phone home” techniques and look a lot like a traditional internal threat. In order to keep unauthorized internal hosts from accessing these sensitive packets, there are various techniques that can be employed.
The first and most basic thing is to avoid the use of hubs in your network. Switches, instead of hubs, are just typical in modern networks. It is actually quite difficult to purchase a new hub today. Switches intelligently build knowledge of the physical addresses on a network and only forward traffic to the appropriate ports.
There are cases, known as flooding, in which a switch can forward frames out all ports similar to a hub. One example of when switches flood is when they haven’t yet learned a destination. Switches, like all compute devices, have a finite amount of resources. As a result, a malicious party on a switched network can flood a switch with invalid addresses and make the switch behave like a hub. This works by overwhelming the switch’s memory that is responsible for address to port mapping. By doing this, the malicious party can get the switch to forward all packets everywhere. At that point, the attacker can easily gain access to these packets.
To mitigate this threat, many Cisco switches have a feature called “port security”. This feature allows an administrator to configure the switch to only allow a certain number of MAC addresses to be presented on a single switchport. Once this number is exceeded, the switch can disable the port. This effectively disables the attackers access to the packets as well as the network.
There are other man-in-the-middle (MiTM) techniques that can be attempted to gain access to unsecured management packets. Examples of this include ARP Poisoning, DHCP spoofing. By spoofing DHCP responses an internal attacker could become the “router” for the subnet or network. In that case, all packets may be routed though an unintended host. To prevent this, Cisco switches have a feature called DHCP Snooping. This configuration allows an administrator to restrict DHCP responses to only be sourced by the appropriate trunk ports and ports connected to a DHCP server. The switch can also look at the DHCP responses and build a mac to IP address database used validate arp traffic. This feature is called dynamic arp inspection.
In addition to these features, we need to remember general security techniques. For example not securing routing protocols and appropriately using passive interfaces, could allow an attacker another way to perform a man-in-the-middle attack on our traffic. Additionally, not using complex passwords and per user authentication can lead to unintended consequences.
In summary, there are some insecure management protocols that we often have to learn to deal with. Some of the tools that are available in a Cisco network to mitigate the risks are as follows:
- Access-lists (transit packet control)
- Access-class (vty and http source restrictions)
- DHCP Snooping
- Dynamic Arp Inspection
- General Security Techniques
This is not an exhaustive or all inclusive list of risks and mitigation techniques. If you must utilize a clear text protocol, the most important thing is to think about the possible threats and determine what is acceptable mitigation for each use case.