If you are at all familiar with <acronym title="Simple Network Management Protocol">SNMP</acronym>, you've probably heard of "community strings". Community strings are similar to passwords. They define and grant access to a device's <acronym title="Management Information Base">MIB</acronym>. If you've used SNMP in conjuction with a Cisco network device, you've probably seen something similar to this in your own configuration.

snmp-server community SLAPREAD RO

This line allows complete read-only access to any SNMP agent accessing the device with the community string "SLAPREAD". If your network is closed and you have no concerns with local users using sniffers, then this method of security is perfectly fine.

Or, you could kick it up a notch.

There are three different versions of SNMP. We'll only be discussing versions 1 and 2 here. Version 2 extends and improves upon version 1, but isn't much different from a user's perspective. When it comes to security, they are configured in the same way.

There are two parts to basic v1/v2 security: the community string and the access-list. We've previously discussed defining management IPs with an access-list, so we'll reuse that concept here. All we need to do is take our existing SNMP configuration and add the access-list.

snmp-server community SLAPREAD RO 9

We've now required that agents know the community string and come from the right source IP before we'll grant them read-only access.

Is this really secure? No, of course not. Your data is still transmitted in the clear. But, it's a simple step to help reduce the risk of serious data loss to unknown sources, especially those outside your network.