- Management Plane Security Elements
- Network Device Security
- Conclusions
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Network Device Security
Network devices are typically powerful computers in their own right, particularly for high-end devices such as edge MPLS routers, Internet core routers, and so forth. Along with a wide range of network interface support (ATM, IP/MPLS, frame relay, Ethernet, etc.), such devices also feature a variety of security schemes:
RADIUS
Kerberos
SecurID
TACACS
Access control lists (ACLs)
SNMPv3
The first four of these schemes typically employ an external security server that's used to authenticate the user. Once authenticity has been established, the user is allowed to open a session with the device via Telnet, SSH, secure HTTP, etc.
For ACLs and SNMPv3, a different approach is used. With ACLs, the IP addresses of authorized users are entered into a list on the network devices. Then, when a user tries to login to one of the devices, its IP address must be in the ACL; otherwise, the connection attempt is rejected. SNMPv3 provides a user-based security management (USM) system in which different users (principals) are configured to use a specific set of authentication and privacy protocols.
Let's see how these various schemes work in practice.
Logging In via RADIUS
RADIUS user authentication requires a username and password. A secret key is shared between the network device and a RADIUS server. The network device uses the key to encrypt the user password, which it then relays (in an access request packet) to the RADIUS server. If the RADIUS server sends an appropriate access grant to the network device, the user-to-network device connection is allowed to proceed.
Logging In and Communicating via Kerberos
In this case, a user requests access to a network device via a Kerberos server. If the user is known to the server, a ticket is issued linking the user to the network device. The ticket identifies the user and includes a session key. The user time stamps the ticket and sends it back to the server. The session key is then used to authenticate the user with the network device. Because time stamping plays a part, it's important that the times on the network devices and the Kerberos server not differ by more than five minutes.
Once authentication has occurred, the user can complete an encrypted session.
Logging In via SecurID
SecurID login requires the use of a PIN concatenated with the number generated by a physical security device such as an RSA SecurID card, a keychain fob, and the like. At login, the user is requested to enter an account name followed by the concatenated PIN and generated code number. The server verifies this data and the session is appropriately allowed or denied. Many organizations use SecurID schemes for providing access to corporate VPNs; for example, for remote/traveling workers.
The remote worker uses her portable PC to dial a local number that gives access to a service provider. Once connected to the service provider, the security mechanism is employed to authenticate the user. If the user passes the security check, she gains access to the required corporate resource (the office LAN, for example). SecurID schemes can also be used for gaining access to managed network devices.
Logging In via TACACS
With TACACS enabled, the network device prompts the user for a name and password; it then verifies the password with a TACACS server. As with RADIUS and Kerberos, TACACS allows a network operator to outsource security to a centralized server.
Access Control Lists
ACLs can be used on network nodes to perform filtering of incoming IP packets. This is done to determine whether the source IP address in the packet header matches an entry in the ACL. If the addresses match, the packet is accepted. Additional rules can also be configured.
Masks can be used to make the allowed IP address range wider; for instance, a mask of 255.255.0.0 and a filter address of 10.10.*.* will allow through all IP packets with source addresses between 10.10.1.1 and 10.10.255.255.
SNMPv3 USM
SNMPv3 is a secure version of SNMP that was preceded by SNMPv1 and SNMPv2c. Both versions 1 and 2c employ a simple password-based authentication scheme—the password is called a community string and is included as clear text in the SNMPv1/2c protocol messages that appear on the wire. SNMPv3 is a major departure in that it provides a modular structure that separates the main protocol areas:
Message dispatch—sending/receiving SNMP messages
Message processing—encoding/decoding SNMP messages
Security—implementing the configured security model
Access control—implementing views
Applications—agents, managers, proxy forwarding, etc.
The modular structure provides flexibility in that future extensions (such as a new security algorithm) can be added as required. [3] It's not necessary for a new version of SNMP to be created.
The security options are encoded in SNMPv3 protocol messages and the allowed combinations are as follows:
No authentication or privacy. Messages are neither authenticated nor encrypted.
Authentication and no privacy. Messages are authenticated but not encrypted.
Authentication and privacy. Messages are authenticated and encrypted.
In addition, SNMPv3 provides for checking the timeliness of messages to protect against replay attacks. For both authentication and privacy, the parties employ shared secret keys. These keys must be created outside SNMP but thereafter can be changed using SNMPv3.
The SNMPv3 administrative model employs parties. For example, an NMS could be a party. This means that the NMS must be recorded in the security MIB on SNMPv3 nodes with which it will communicate.
SNMPv3 View-Based Access Control
The SNMPv3 USM provides for message-level protection. The view-based access control mechanism (VACM) allows for security at the level of individual MIB objects. This is a more fine-grained security scheme than those described previously.
Let's say the network manager in Figure 1 tries to delete a managed object such as an LSP between nodes X and Z. The NMS presents a GUI-based topology with which the network manager interacts. Lower-level NMS software then translates the GUI actions into a series of SNMP (set and get) messages that are sent into the network via the MP. If the NMS user is not permitted to delete the LSP, this can be implemented using the VACM. Because it's quite likely that only specific NMS client users would be permitted to make service-affecting changes such as deletions, only selected clients would need to be disallowed from completing the LSP deletion.
The SNMP objects that represent the LSP must be contained in the view used by the NMS. If the view for the NMS doesn't contain the required MIB objects, the sets will fail. Therefore, two views are needed: one that allows deletion and one that doesn't.
The NMS Must Be Secure
If the NMS is operating as a go-between for the network manager (that is, all device access is made by the NMS, not by the network manager), it must be secure. At the very least, the NMS must authenticate a user and provide an associated security profile with which access is made to the network. As we saw in part 1 of this series, security is only as strong as its weakest link, so the NMS must provide strong security.