Managed Security Services

Battening Down SNMP—continued

Ask who's there
The OUSPG demonstrated that many SNMP implementations are vulnerable to malformed message and buffer overflow attacks. These kinds of exploits are often used to perpetrate denial-of-service attacks (DoS)—crashing or crippling the target so that it cannot perform its normal function. For example, an attacker might send your router an SNMP GET request containing an object identifier with invalid syntax—before your router even gets to worry about the command's authenticity, it spins off into never-never land trying to parse the message. Thus preoccupied, the router may stop forwarding legitimate packets or even reboot itself.

In more severe buffer overflow attacks, the target is actually thrown into command execution mode, letting an intruder "piggyback" nefarious commands on the invalid message. Once compromised in this fashion, the target unwittingly executes the attacker's commands—for example, reconfiguring a router, deleting files, or installing trojan software.

The OUSPG simply demonstrated this attack vector exists; hackers will now try to exploit it. As a February 12th ISS X-Force Alert warned, "Circulation of [the OUSPG SNMP test] tool may lead to the widespread use of new exploits to crash or compromise vulnerable systems."

CERT recommends using filters to mitigate this risk by deflecting messages away from their intended targets. First, filters can and should be applied on the device itself. Many devices have configuration hooks to narrow administrator access, permitting SNMP from or to specific IPs and subnets. For example, Cisco routers can be configured to accept SNMP from a single NMS by creating an access list like:

access-list 101 permit ip host [NMS IP address] any
access-list 101 deny udp any any eq snmp
access-list 101 deny udp any any eq snmptrap

and applying this access list to the ingress interface (the interface on which legitimate SNMP packets—and potential attack packets—will arrive):

interface ethernet 0 ip access-group 100 in

While device-level filtering can help, again it is not enough. UDP packets that carry SNMP are easily sent with a forged source IP address. An attacker who knows your management station's IP can "spoof" this address to penetrate your admin filters.

Post a guard outside
More comprehensive filters should also be applied at the network edge to block unauthorized access to your entire trusted network. As a rule, ingress filters are appropriate to deny all incoming traffic except that which you must explicitly permit. Particularly if remote administration runs over a secure tunnel, there is probably no good reason why you should ever let SNMP from the outside get past your firewall. Access lists containing deny rules like the one illustrated above can be applied at screening routers and perimeter firewalls.

The CERT advisory further warns that ingress filters must constructed to stop SNMP not just to specific subnets or interfaces, but also to broadcast and loopback addresses. If you forget to block SNMP to subnet or "all ones" broadcast addresses, an intruder can launch an attack without knowing any of your inside, trusted IP addresses.

Inside your network, you can take steps to physically and logically separate legitimate SNMP traffic from general network business. For example, drop your management station on a separate Ethernet to multi-homed devices, using ACLs to narrow SNMP access down to just this one port on each managed node. Alternatively, use 802.1Q VLAN tags [definition] to logically separate and filter admin traffic.

Although it may seem counter-intuitive, egress filtering is also helpful. Filtering outbound traffic leaving your network perimeter may not prevent SNMP attacks against your own systems. However, it can stop your systems from being used to launch attacks against others—and it can stop your systems from blindly announcing their presence to the outside world.

Upgrade your defenses
In many cases, the strongest security measure you can apply is the latest security patch or image update available from your vendor(s). Keeping up with security patches can be a daunting task, and it is easy to get complacent about this. Some rationalize delayed deployment by reasoning that security patches destabilize systems—and sometimes they do. However, that's generally not a good enough reason to stick with old, buggy software when serious vulnerabilities have been corrected in newer versions.

The CERT advisory includes a list of impacted vendors, accompanied by vendor responses and links to each vendor's own advisories and patches. Several vendors have already announced patches and made configuration recommendations to close the holes identified by OUSPG. A few examples include Cisco, Juniper, Microsoft, and RedHat. Many network products either incorporate or are commonly used with third-party SNMP software maintained by companies like SNMP Research. For example, RedHat is making patches for the popular UCD SNMP implementation available. If your vendor is not listed in this CERT advisory, check with the vendor directly.

Test yourself
To identify and demonstrate these SNMP vulnerabilities, the OUSPG used a stress-testing tool called PROTOS. This Java tool is freely available for download. Vendors are using PROTOS to assess their vulnerability, but these tools can be used by anyone for self-assessment. If believe that your network is not vulnerable to the attacks described in this CERT advisory, aim PROTOS at your own network to confirm—or dispel—your assumptions.

After you implement additional SNMP safeguards, test yourself again—either with PROTOS or using a simple scanner to aim UDP/161 and 162 traffic at your network and the nodes therein. If you use a commercial scanner, check for new SNMP-related updates—for example, the ISS Internet Scanner. Keep your guard up by repeating your vulnerability tests again periodically.

In addition, put your network on alert for unusual SNMP or compromised system behavior. Read the Intruder Detection Checklist published by the CERT Coordination Center. This describes how to look for common evidence of system compromise and what to do when you find it. It also provides contact information for reporting suspected intrusions. Several vendors responding to this CERT advisory have also published trouble-shooting tips. For example, to spot nefarious behavior on your Cisco routers, heed the advice offered in this Cisco advisory.

Put the risk in perspective
The CERT advisory is a shot across the bow—a warning to all of us who use SNMP throughout our networks. Take the steps outlined in this article, the CERT advisory, and referenced vendor sites. But don't panic. Several of these vulnerabilities have been known for some time, and have already been addressed in current release code. Attacks that exploit the newest vulnerabilities are bound to surface, so action is clearly required.

Remember that denial-of-service attacks are intended to impede your ability to conduct business—taking rash steps to reconfigure network can do just that. Consider every change you make carefully, weighing your risk against the impact of change on your network. For example, even CERT warns that ingress filters should be applied sparingly due to impact of granular filters on performance. Common sense dictates rapid response to these reported vulnerabilities—just implement change with the appropriate thought and due caution.

<Back to page 1

—End