You want to set up basic SNMP services on a router.
To enable read-only SNMP services, use the following configuration command:
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#snmp-server community ORARO ro
Router(config)#end
Router#
To enable read-write SNMP services, use the following command:
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#snmp-server community ORARW rw
Router(config)#end
Router#
|
Starting with IOS Version 12.0(3)T, Cisco introduced a new system for configuring SNMP services using the snmp-server group and snmp-server user configuration commands. Use the following commands to enable read-only SNMP services with this new method:
Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#snmp-server group COOKRO v1 Router(config)#snmp-server user TESTRO1 COOKRO v1 Router(config)#snmp-server group BOOKRO v2c Router(config)#snmp-server user TESTRO2 BOOKRO v2c Router(config)#end
SNMP services are disabled by default on all Cisco routers. The examples highlighted in the solutions section show only how to configure the router to allow inbound SNMP services so that it will respond to SNMP Get and Set requests. These configuration examples do not enable SNMP traps or informs, which we discuss in Recipe 17.13.
When inbound SNMP services are enabled, the router starts to listen for incoming SNMP requests on UDP port 161. It is important to note that these methods enable SNMPv1 and SNMPv2c only (SNMPv3 is covered in Recipe 17.22).
The first example shows the older method of enabling SNMP services. It uses the snmp community command to simultaneously enable both SNMPv1 and SNMPv2c:
Router(config)#snmp-server community ORARO ro
Cisco documentation often refers to this as bilingual SNMP support because it allows the router to speak both SNMP languages (or versions).
The show snmp group command gives details on exactly what SNMP versions are enabled, as well as the security models they use. Running this command after implementing the first two configuration examples gives the following output:
Router#show snmp group groupname: ORARO security model:v1 readview :v1default writeview: <no writeview specified> notifyview: <no notifyview specified> row status: active groupname: ORARO security model:v2c readview :v1default writeview: <no writeview specified> notifyview: <no notifyview specified> row status: active groupname: ORARW security model:v1 readview :v1default writeview: v1default notifyview: <no notifyview specified> row status: active groupname: ORARW security model:v2c readview :v1default writeview: v1default notifyview: <no notifyview specified> row status: active
This shows that the groups we have configured each created two entries: one for SNMPv1 support, and the other for SNMPv2c. This is possible because SNMPv1 and SNMPv2c use the same community string authorization model. Therefore, the router is capable of responding to either version of SNMP.
When using the snmp-server group command for enabling SNMP services, you can create an SNMP group entry that belongs to a single SNMP security model (SNMPv1 or SNMPv2c). Cisco added this command to support SNMPv3 services, which may eventually replace the legacy method.
Both methods for enabling SNMP services assign a community string that acts as a password of sorts to protect access. SNMP services run on a well-known UDP port, so the router needs this password to help prevent unauthorized access. The router will simply discard any SNMP requests that contain incorrect SNMP community strings. It is important to note that in both Version 1 and 2c, SNMP transmits these community strings through the network in clear-text, making it relatively insecure.
You can configure the router for either read-only or read-write SNMP service. Read-only access means that users can view the router's MIB tree. This is relatively benign, although information about the router's configuration could be useful to someone planning an attack on your network. Read-write access, on the other hand, permits users to change some of the values in the MIB tree. A user with read-write access could potentially wreak havoc by disabling IP routing, disabling interfaces, erasing router flash, downloading router configurations, uploading configuration commands, or making a variety of other dangerous changes.
Be extremely careful when providing SNMP write access. If SNMP write access is not absolutely required, we recommend disabling it. Far too many organizations automatically enable full SNMP write access without regard for the dangers of possible unauthorized changes.
If write access is required, you will first need to define SNMP views as described in Recipe 17.7. But a better solution is to simply use SNMPv3, which we discuss in Recipe 17.22. SNMPv3 offers advanced authentication and encryption services that ensure safe delivery over insecure networks. Unfortunately, SNMPv3 is still a relatively young standard, and many NMS systems don't yet support it.
So, in those cases where SNMP Version 1 or 2c write access is an absolute requirement, we recommend using the security features described in Recipe 17.5, Recipe 17.6, and Recipe 17.7. These describe how to implement SNMP ACLs, limit SNMP views, and restrict SNMP TFTP access to help to reduce the risk of attack.
Recipe 17.13; Recipe 17.5; Recipe 17.6; Recipe 17.7; Recipe 17.22
|
|
|
| Top |