It's A Secret!

[SlightlyLoony]

I spoke this morning with a company that is deploying Discovery, and one of the topics of our conversation was this: how do we deal with a situation where the networking folks tightly restrict access to SNMP on their network gear? This issue comes up quite often, because restrictions like this are commonly employed.

Usually the first questions from the service desk are these: Why in the world do the networking people have these crazy restrictions? And how do I get Discovery to work — get rid of the restrictions, or find a way to work within them?

There are actually some good reasons for these sorts of restrictions. The three that I've heard most often:

1. Vulnerability of SNMP. Unfortunately, the SNMP versions most widely used (1 and 2) are inherently insecure. Even the community strings (the SNMP equivalent of a password) are passed over the network in the clear. Because many devices can be reconfigured or even shut down via SNMP, the people in charge of this equipment are often very leery about allowing just anyone to access it.
2. Exposing sensitive information. Even aside from the security issue above, SNMP can be used to read information out of devices that many people consider sensitive. Nothing like passwords or credit card numbers (at least so far as I know!), but lots of details about how your enterprise's network is put together, almost like a blueprint of your network. The bad guys are better off without this knowledge!
3. Means of attack. It's possible to attack certain devices (especially routers) via SNMP. Imposing restrctions on SNMP access is one of the simplest — and surest — means to defend against such an attack.

The key to understanding how to deal with SNMP access restrictions is to understand how they're implemented. By far the most common means is to create Access Control Lists (ACLs) directly on the devices. These ACLs are just a list of rules configured in the device. Basically, there are just two kinds of rules: a "permit" rule and a "deny". An ACL for SNMP access to (say) a router might look something like this:

permit 10.0.23.44
permit 10.65.23.0/24
deny all

The router will look at the IP address of every incoming request, and run it through those rules in sequence. If the request is coming from 10.0.23.44, it will be granted. If it's coming from 10.65.23.99, it will be granted (because that address is within the 10.65.23.0/24 network). Any request from an IP address that doesn't match the first two rules will be rejected. Aside from some tedious details, that's all there is to ACLs!

Understanding this, you can see that in general there are two ways to make Discovery work with such restrictions:

1. Put a MID server at an included IP address. This is by far the most desirable approach. If your enterprise's SNMP ACLs include a network, this could be as simple as finding or installing a server with an IP address in that network. If the ACLs include only individual IPs, then you'll need to find a server with one of those IPs that has enough capacity to handle a MID server. The networking folks often already have a server dedicated to network monitoring; it may be possible for you to install the MID server on that box.
2. Add a new rule to the ACL. Unless your networking team has an automated configuration deployment system, this means someone will have to manually add a new rule to the ACL in every networking device — something most networking teams will not want to do. For this reason, this is the less desirable approach.

One last thought about MID servers placed specially to handle ACLs... If you need such a MID server, it may well be that you'd like that MID server to do nothing else but handle these special cases. That is, you'd like to have another MID server (on some unprivileged box) handle everything it can, and then hand the cases where privilege is needed to the special MID server. This is the kind of thing that Discovery Behaviors do, and I'll describe them in another post...