Previous Table of Contents Next

Network Design in the Real World: SNMP Security

When working for a fairly small company, I had a small router connected to an Internet Service Provider—a router that also functioned as a limited firewall. The ISP recommended that they monitor our router for us, since we had no 24-hour staffing and no remote monitoring services at the time. I recommended that we allow only pings for monitoring, but I was outvoted and soon enabled SNMP using the ISP’s default passwords.

Needless to say, the access list rules were disabled within three months, and we were unfiltered to the Internet. We caught the problem as part of a weekly, manually initiated audit process—the syslog feature on the router was unreliable. (Note that this was not a Cisco router, although the same problems could exist on a Cisco-based platform.) The router was compromised because it was protected from SNMP attacks only by a simple, unencrypted password (clear-text) and an IP address restriction. Further, while the ISP never admitted that it had been hacked, there is little doubt that someone (either inside or outside the ISP) compromised the machine (or spoofed the IP address) that was given access and used it to attack us.

The immediate response to this attack was to disable the SNMP mechanism and re-enable the filters. A full audit of all systems did not detect any further compromises.

Designers should take a few lessons away from this story. First, don’t trust an ISP or any outside source to be secure. This is very hard to implement in practice—I worked on one network where the ISP was the maintainer of the firewall, and the IS staff was completely blocked from any involvement. This is a very poor practice, though many companies lack the internal staff resources necessary to properly maintain a firewall. In my opinion, when this function gets outsourced, the mindset shifts to one of blame distribution rather than security, which is never good.

The second lesson is to always push for another solution. I didn’t do this once management had made their decision, though I knew that SNMP was not secure (since version 2 uses clear-text passwords), and neither was a single-firewall router design. Unfortunately, I was unsuccessful in getting the budget for an internal firewall or the proper resources to manage and monitor the router.

The Cisco PIX

Cisco provides a stateful-inspection firewall with its Packet Internetwork Exchange (PIX) product line. Stateful-inspection firewalls do not examine each packet through the application layer—rather, they analyze the beginning of the data flow and then maintain information about that flow’s state. State is comprised of IP addresses, sequence numbers, and ports used. The benefit of the stateful-inspection firewall is that it is typically much faster than application-level firewalls; however, any additional features, including caching and virus checking, have to be provided by external devices.

The PIX’s features provide many benefits for the network designer. It is important to note that it is possible to install the PIX with only two IP addresses—one on the internal interface and one on the external. In addition, the administrator can interconnect PIX boxes for fail-over (which provides redundancy) and the integrated Network Address Translation (NAT) function (see Figure 11.3). NAT permits addresses to be changed and remapped at the translation device—a handy feature that allows the use of RFC 1918 (InterNIC-registered) addresses on the internal network while retaining Internet connectivity, although this requires a larger pool of IP addresses. Figure 11.3 illustrates the conversion process undertaken by a packet traversing the translation device.

FIGURE 11.3  Network Address Translation

The PIX also supports PAT, or Port Address Translation (see Figure 11.4). This feature is interesting in that a single IP address on the firewall can service all of the external connections, yielding a significant savings in total IP address allocations. PAT works by assigning each session a unique port number that maps to the IP address on the internal interface. Note that Figure 11.4 differs from 11.3 in that only the TCP port number is changed—the same IP address is used on the external interface. This duplication conserves addresses on the public network.

FIGURE 11.4  Port Address Translation

It is important to consider the types of traffic that will traverse a device providing PAT and NAT services. FTP, HTTP, and Telnet all operate well in this configuration; however, NetBIOS-based services, including Windows naming services, will not function properly. It is likely that this problem will be addressed as corporations migrate to Active Directory and Windows 2000.

As noted previously, the PIX also provides for failure of the firewall in redundant configurations. This is accomplished with an interconnect cable and is somewhat limited in that both PIX boxes must be in close proximity. Thus, this solution addresses hardware and most software failures, yet it provides no protection from site and facilities failures.


While bandwidth is becoming cheaper and more widely available, there are still many benefits to caching. When data is cached, the data elements are copied and provided from sources closer to the requestor. The cache is the collection of data elements that are provided.

Consider a Web page with three large graphics. It takes 10 seconds to download those graphics across the Internet with a T1. If a company cached Web traffic, the first employee would take 10 seconds to load the page, but each subsequent employee would receive it in a fraction of that time—perhaps a single second. The cache serves the data from a local resource, rather than requiring another transfer from a remote location. This results in more efficient use of the T1, the Internet, and the Web server, while providing the user a better response time.

Internet Service Providers have begun to place caches in their networks to further accelerate the distribution of data. This method again improves performance and yields a cheaper solution. Consider caches as you would commuting options. Adding lanes for more cars is significantly less efficient than using a train, bus, or ferry. While there are times when bigger pipes are required, it is best to evaluate the actual need. There are also instances where it’s best to take another tack—personally, I look at adding extra lanes for cars like I do combating obesity by getting larger pants. The same is true in networking—more bandwidth will not decrease the performance bottleneck caused by large, uncompressed graphics.

From a security perspective, caching can be problematic, although this problem is diminishing as the technology advances. The original issue was that pages viewed were stored on the caching server and could be viewed without authentication. As more sites employ Secure Hypertext Transfer Protocol (HTTPS) and non-caching flags, this problem should subside. Administrators can reduce this risk by securing the caching server as they would any other corporate resource.

Previous Table of Contents Next