Controlling SNMP Access to the Router

Problem

You need to improve upon the security offered by the SNMPv2 community password.

Solution

There are two straightforward solutions. One is to identify which NMS systems are allowed to use the SNMP community:

	[edit snmp]
	aviva@router1# set community public clients 10.0.0.1/32

The second is to limit the router interfaces that can communicate with the NMS system:

	[edit 
snmp]
	aviva@router1# set interface [fe-0/0/0]

Discussion

SNMPv2 is inherently insecure because the community string, which acts as the password between the manager and agent, is sent as clear text across the network. You can improve the security a bit by limiting SNMP manager access to the router and to the MIB on the router. Perhaps the simplest way to improve security is to define which NMS systems can or cannot use a particular community string. The first command in this recipe allows only a single system, 10.0.10.1/32, to access the router using the community string public. While this example and the examples throughout this chapter use a community named public, this name is very well known, so for security reasons, it is recommended that you use a different name, preferably one that's difficult to guess (for example, mYsnmPcommunitYversioNonE).

You can also disallow access for specific NMS systems. One plausible use of this is to allow access by all the NMS systems on a subnet and then deny access to just a few:

	[edit snmp]
	aviva@router1# set community public clients 10.0.0.0/8
	aviva@router1# set community public clients 10.0.0.1/32 restrict

This configuration allows all NMS systems on the 10.0.0.0/8 subnet to access the router, with the exception of 10.0.0.1/32.

Another way to restrict access is to define which router interfaces can receive requests from NMS systems. The second command in this recipe does this by specifying a physical interface, or you can name individual logical interfaces to be more specific:

	[edit snmp]
	aviva@router1# set interface [fe-0/0/0.0 fe-0/0/0.1]