Network Management Security

Happy New Year! I recently read a great article on network management security by Joel Snyder, and thought it would make a nice first topic for 2010. His article offers up several very good tips that you should consider implementing if you haven't done so already. Check it out:
 
It doesn't happen very often, but when Cisco sends out a security advisory about one of their routing or security products, there's a big splash. Almost all of these advisories can be summarized like this: "If someone out on the Internet sends some bad packets to your Cisco device, and if your device is listening to them, then something bad will happen." 

The phrase in that alert you need to pay attention to? "If your device is listening to them." 

It shouldn't be. 

Do you have SNMP enabled on edge devices? Fine… so long as you also have an access list saying that those SNMP packets can only come from your management station. Is the management interface, whether HTTP, HTTPS, SSH or (heaven forbid) Telnet running? 

Fine … so long as no one outside our network can ever get there. 

We call this the "control plane" or "management plane." Think of it as a different network that runs in parallel to your data network, and is used to control, monitor and manage the data network. In huge networks, there is a true network control plane that is completely separate from the data that the device sees. But in many smaller networks, control plane, management plane, and data plane run on the same wire.

You can, and should, secure your network control plane in many ways, but they mostly come down to two techniques: access control lists and self-protection.

ACCESS CONTROL LISTS MANAGE TRAFFIC TO EDGE DEVICES 
Access control list protections usually occur when you put a block of some sort in non-firewall devices at the edge and core of your network. A good example is SNMP. Let's say you have an SNMP management station at 10.20.30.161. That represents the one valid flow to and from that management station to network and security devices. Now, any other SNMP traffic floating around on your network, or coming in from the edge, should be blocked. If you have intermediate routers in your network, and certainly if you have firewalls, you should use them to block SNMP traffic -- and any other management traffic -- to your security and network devices, except from authorized sources.


You can get as strict as you want. For example, you can simply block all SNMP anywhere in your network except to and from the official management station. Here's an example using Cisco Systems Inc. access list syntax (once you define these access lists, don't forget to apply them to the appropriate interfaces):

permit udp 10.20.30.161 any eq snmp
permit udp any 10.20.30.161 eq snmptrap
deny udp any any eq snmp log
deny udp any any eq snmptrap log

Or you could put a block in to just protect the network and security devices. Usually, stricter is better, but if you don't know who else might be using SNMP, then you can focus on the devices that run your network.

At the edge, a much stricter approach is appropriate. In this case, you should be blocking all traffic directed at your firewalls, load balancers, and routers on their management addresses. Remember: No one on the Internet needs to send packets to your firewall, or to your external router. They legitimately send packets through those devices all the time, but the packets are never destined (at the IP layer, anyway) directly to the device. They're always for some IP address behind the device. The only time you may want to consider letting traffic come directly to the management IP of your external security and network devices is for PING traffic -- it's a very useful debugging tool and worth letting traffic come in.


Here's an example, using Cisco syntax, of blocking access to a device 128.182.35.42: 

deny IP any host 128.182.35.42

If you wanted to block all SNMP incoming, you could do something like this:

remark *** Deny all other SNMP incoming
deny udp any any eq snmp
deny udp any any eq snmptrap

If you're in a NAT environment and you're using the external IP address of your firewall or router both for management and NAT, here is some advice: Don't do that. You're asking for security trouble, because now you have the same IP address being used for two things. IP addresses may be in short supply, but they're not in that short supply. Here's an example in case you can't separate out NAT from other traffic, assuming you know which ports your router or firewall are listening to (not a very good assumption, as the Cisco advisories show):

remark *** Block obvious access to mgmt plane; allow others
deny tcp any host 128.182.35.42 eq 22
deny tcp any host 128.182.35.42 eq www
deny tcp any host 128.182.35.42 eq 443
permit ip any host 128.182.35.42

CONFIGURE SECURITY DEVICES TO PARTICULAR TRAFFIC
Another protective technique should be self protection. With self protection, you configure the network or security device so that it doesn't listen to traffic it shouldn't hear. On devices such as routers, you'll want to create a local access list that only allows management traffic from authorized management networks. If you can, also disable management protocols and interfaces you aren't using. On devices such as firewalls, there is often a series of check boxes that let you turn on or off management on certain interfaces. It doesn't need to be enabled on the outside, ever. That's what VPNs are for, if you really need external management.

Sometimes you want to disable protocols entirely. Most people, for example, do not manage Cisco routers using HTTP. Here's a configuration example that's double overkill: disabling the HTTP server, and then also putting an access list on it, just in case.

no ip http server
ip http access-class 21
ip http authentication local
no ip http secure-server
access-list 21 deny any

And even if you do have management enabled, you should also add lists of authorized management addresses. It shouldn't be possible for someone who happens to be inside your network to connect to the management IP of your firewalls, routers, or other security devices, unless they're on the official management network.

For example, again using Cisco syntax, here is what the SNMP part of the router configuration might look like in a self-protective mode of operation:

snmp-server community public RO 6
snmp-server community vewysekwitpassword RW 6
snmp-server location Opus One/Tucson, Arizona
access-list 6 permit 203.209.92.105
access-list 6 permit 192.245.12.0 0.0.0.255
access-list 6 deny any log

In summary…
1. Your public facing devices should not have non-essential ports open. 
2. SNMP is safe when using an access list to limit who your routers will send/receive SNMP traffic to/from. 
3. Use a Management or Control plane to isolate the monitoring and management tasks from the other traffic. This allows you to open ports/protocols often necessary to enable the best functionality.

Do you have any network management security tips that you frequently use or follow?