Networking

How we tackled the SNMP problem in three steps

Plugging security holes caused by a recently described series of flaws in the SNMP protocol takes some careful consideration. A network administrator at TechRepublic describes how she is tackling this project in three phases.


TechRepublic is a fairly young company, only about three years old, but even new companies with their new networks are susceptible to a protocol flaw that dates back to the early days of the Internet. The flaw is in the ubiquitous Simple Network Management Protocol (SNMP), and it posed quite a challenge recently.

Computers and networking devices use SNMP to share information, and it's a primary part of many tools that administrators use to monitor and log activity on their networks. CERT recently published an advisory describing the flaws that the Finnish Oulu University's Secure Programming Group discovered when it examined SNMP as part of an ongoing testing project. The testing group discovered problems with the way SNMP decodes and processes messages and in the way it handles manager-to-agent request messages.

Additional reading
In "SNMP flaw can lead to DoS attacks and network instability," TechRepublic columnist John McCormick looked at the vulnerabilities, and in "Don’t allow SNMP to compromise network security," he discussed the relationship of SNMP to general network security.

Most network administrators have been aware of SNMP's security vulnerabilities for years and haven't felt the need to do anything about it, according to TechRepublic system administrator Lori Hyde.

"People just haven't put much emphasis on SNMP because they use it on the inside of their protected networks, and they just haven't been hacked using it," she said.

That changed after the CERT advisory because the university also released links to tools that test for the flaws. Inevitably, people will use the tools to exploit the SNMP flaws, so IT departments must now confront the problem.

Hyde has developed and is implementing a three-phase strategy to deal with the threat. In this week's From the Trenches, we will look at these phases with her:
  • Blocking outside SNMP traffic
  • Implementing patches from OEMs
  • Changing default "community names"

Blocking traffic
Protecting the outer shell of the network is of immediate necessity, Hyde said. This means going beyond your firewall, which probably is blocking ports 161 and 162 already. Those are the two major SNMP ports, but depending on the operating system and network equipment on the network, there may be other ports to check. For example, some Cisco equipment uses port 1993 for certain SNMP traffic.

Even if all these ports are blocked on your firewall, you may have routers or other edge devices that are vulnerable. All outside access to SNMP traffic needs to be blocked, Hyde said, and then it should allow only queries from known and trusted hosts. This is done through an access list or firewall rule.

Not only does the outer shell of the central or main office network need to be hardened, but the outer shell at remote sites needs to be protected.

Network management gets dicey at this point. One solution is to use a VPN tunnel to a trusted machine at the remote site and use that machine as a relay point for managing network devices at the remote site. This provides the needed security for the SNMP traffic from the remote site to the home site.

Update, update, update
Once the immediacy of the first phase was addressed, Hyde began seeking updates from the original equipment manufacturers for all of TechRepublic's network devices.

Having an up-to-date inventory of equipment that lists where each item is physically located is a key ingredient for successfully fulfilling this goal. Of course, the bigger the organization and its network, the bigger the problem of updating the equipment will be.

Various vendors are handling the SNMP vulnerability through software updates, configuration advisories, and/or advice on workarounds. A good example is Cisco Systems. Many Cisco products run on the company's proprietary Internetworking Operating System (IOS). Cisco offers a security advisory specifically for devices that run the IOS and one for equipment it builds that does not use the IOS.

Dealing with community names
With the network's outer shell hardened and the network devices being upgraded, Hyde is now examining the community names network devices use to accept requests.

As McCormick explained in his column on SNMP and network security, most network devices use communities named "private" and "public" by default. While this makes setting up the equipment for remote management quick and easy, these names do not challenge a hacker during an attack.

Hyde said she is creating community names for TechRepublic's equipment that will not be easily guessed, closing another security hole.

Again, the size of an organization will determine the scale of the task.

"Changing these community names when you're a big organization is a complex problem," she said. Not only do you have to change the community names in the individual network devices, but you have to change them in the computers that manage those devices.

Looking at the future
Large organizations should consider testing their ability to update their SNMP from the widely used SNMPv1, or even SNMP-Sec with the added security protocol, to SNMPv2p.

Changing the community names on both manager and agent machines and devices is such a huge undertaking that this would be the time to implement the newer protocol, Hyde said.

However, network administrators should test v2p to see how it will affect current network operations, enterprise applications, and system services before implementing it, she added.

Hyde wants to see how different pieces of equipment support the new protocol, and she is curious about migration issues. Meanwhile, she is logging attempts to breach the security of her border routers and hoping no one cares about tapping the mother lode of information that's available via SNMP.

Have you ever been attacked using SNMP?
Have you seen an attack on your network based on SNMP information? Do you log attempts to use ports 161 and 162 on your border devices? Share your experiences in the discussion below.

 

Editor's Picks