2.2. SNMP Communities
SNMPv1 and SNMPv2 use the notion of
communities to establish trust between managers and agents. An agent
is configured with three community names: read-only, read-write, and
trap. The community names are essentially passwords; there's no
real difference between a community string and the password you use
to access your account on the computer. The three community strings
control different kinds of activities. As its name implies, the
read-only community string lets you read data values, but
doesn't let you modify the data. For example, it allows you to
read the number of packets that have been transferred through the
ports on your router, but doesn't let you reset the counters.
The read-write community is allowed to read and modify data values;
with the read-write community string, you can read the counters,
reset their values, and even reset the interfaces or do other things
that change the router's configuration. Finally, the trap
community string allows you to receive traps (asynchronous
notifications) from the agent.
Most vendors ship their
equipment with default community strings, typically
public for the read-only community and
private for the read-write community. It's
important to change these defaults before your device goes live on
the network. (You may get tired of hearing this because we say it
many times, but it's absolutely essential.) When setting up an
SNMP agent, you will want to configure its trap destination, which is
the address to which it will send any traps it generates. In
addition, since SNMP community strings are sent in clear text, you
can configure an agent to send an SNMP authentication-failure trap
when someone attempts to query your device with an incorrect
community string. Among other things, authentication-failure traps
can be very useful in determining when an intruder might be trying to
gain access to your network.
Because community
strings are essentially passwords, you should use the same rules for
selecting them as you use for Unix or NT user passwords: no
dictionary words, spouse names, etc. An alphanumeric string with
mixed upper- and lowercase letters is generally a good idea. As
mentioned earlier, the problem with SNMP's authentication is
that community strings are sent in plain text, which makes it easy
for people to intercept them and use them against you. SNMPv3
addresses this by allowing, among other things, secure authentication
and communication between SNMP devices.
There
are ways to reduce your risk of attack. IP firewalls or filters
minimize the chance that someone can harm any managed device on your
network by attacking it through SNMP. You can configure your firewall
to allow UDP traffic from only a list of known hosts. For example,
you can allow UDP traffic on port 161 (SNMP requests) into your
network only if it comes from one of your network-management
stations. The same goes for traps; you can configure your router so
it allows UDP traffic on port 162 to your NMS only if it originates
from one of the hosts you are monitoring. Firewalls aren't 100%
effective, but simple precautions such as these do a lot to reduce
your risk.
WARNING:
It is important to realize that if
someone has read-write access to any of your SNMP devices, he can
gain control of those devices by using SNMP (for example, he can set
router interfaces, switch ports down, or even modify your routing
tables). One way to protect your community strings is to use a
Virtual Private Network (VPN) to make sure
your network traffic is encrypted. Another way is to change your
community strings often. Changing community strings isn't
difficult for a small network, but for a network that spans city
blocks or more and has dozens (or hundreds or thousands) of managed
hosts, changing community strings can be a problem. An easy solution
is to write a simple Perl script that uses SNMP to change the
community strings on your devices.
| | |
2. A Closer Look at SNMP | | 2.3. The Structure of Management Information |
Copyright © 2002 O'Reilly & Associates. All rights reserved.