8.12.1 Simple Network Management Protocol (SNMP)

SNMP is a standardized remote monitoring and management mechanism for network devices like hubs, routers, and bridges, as well as servers and workstations. The theory is that any SNMP-capable management station should be able to monitor and control any SNMP-capable network device.

Normally, SNMP management stations act as clients, contacting SNMP servers in the various network devices to request information or to issue commands. Sometimes, network devices act as SNMP clients to contact special SNMP servers (known as trap servers) on management stations to report critical information that can't wait until the next time the management station polls the device. SNMP trap servers are separate from regular SNMP servers so that a given machine can run both - that is, both an SNMP server (and thus be manageable via SNMP) and an SNMP trap server (and thus be a management station and receive traps from other devices).

In general, you don't want someone from the outside to be able to manage your network via SNMP. Therefore, you shouldn't allow SNMP to cross your firewall, and you should carefully configure (or disable) SNMP on your systems that are outside your firewall so that attackers can't use it to change that configuration.

SNMP does support some rudimentary security; when information is requested, the requester needs to specify a "community" that it's in. Different communities can be shown different information, and a reusable password can be required for certain communities. At its best, this is quite primitive security; anybody who's doing packet sniffing can easily discover a community name and password.

Not all SNMP devices support even this much. Fortunately, the most insecure SNMP features (for example, allowing SNMP clients to set parameters) are also the most complex to implement, and therefore the least often implemented. SNMP servers that don't implement passwords probably implement only straightforward queries. That may still give away information that you'd prefer not be made public, e.g., the addresses you're communicating with and presumably trust, or the precise amount of extra traffic you'd have to generate to bring down a gateway.

8.12.2 Routing Information Protocol (RIP)

RIP is the oldest routing protocol on the Internet. In fact, it predates IP; it was taken almost verbatim from the older Xerox Network Services (XNS) system. It is also still the most commonly used routing protocol on local area IP networks. Routers (including general-purpose machines with multiple interfaces, that can act as routers) use RIP to periodically broadcast which networks they know how to reach, and how far away those networks are. By listening to these broadcasts, a router or host can determine what networks are reachable and choose the best (shortest) path to each. RIP servers generally just broadcast this information every 30 seconds or so for anyone interested to hear, but a RIP client can request a special update from a RIP server, which will cause the server to reply directly to the client with the information requested.

8.12.3 ping

The ping program checks network connectivity. The ping application generates an ICMP "echo request" packet. The destination system responds with an ICMP "echo response" packet. ICMP is typically implemented in the kernel, so it's the kernel that generates the "echo response" packet; there is no separate server for ICMP on most systems. (On some machines, the echo response is actually generated in the network interface itself, not in the operating system, and the machine need not even be fully running to respond to ping.) ping is not the only program that uses ICMP echo; others include spray and almost any dedicated network management tool.

ping is a useful network trouble-shooting tool, and it is reasonably safe. You'll probably want to allow ping outbound from at least the machines your network operations staff uses and inbound from at least the network operations center machines of your network service provider.

Because of where it is implemented, it is almost impossible to disable replies to ping on individual hosts; packet filtering is the only way to control it.

There are two dangers in allowing ICMP echo:

• It can be used for a denial of service attack: that is, to flood your network. Although any protocol you accept can be used in this way, ICMP echo is particularly tempting, because there are commonly available programs designed for network testing (including some versions of ping) that let you flood networks with simple command line options.

• Anybody who can send ICMP echo requests to and receive ICMP echo responses from your network can discover how many machines you have, and what network addresses they're at; this increases the efficiency of any further attacks. That's why you want to limit requests to machines that have a legitimate reason to be probing your network.

8.12.4 traceroute

traceroute is an application that shows you the route that packets take to a particular IP destination. Because no system typically knows the full path to the destination (merely the next step towards the destination), this is a neat trick.[47] traceroute works by carefully constructing special UDP packets. The destination address of the packets is the remote host; the destination port is an unused (or so we hope, as we'll discuss below) UDP port on the remote host. The really special thing about the packets, though, is that the "time to live" (TTL) fields are set very low (starting at 1), so that the packets will be rejected by intermediate routers as if they were looping in the network. By looking at where the rejections (ICMP "time to live exceeded" messages) come from, traceroute can determine who the intermediate routers are.

[47] traceroute is, fundamentally, a "cool hack."

TTL is an IP header that normally isn't of interest from a firewall point of view. The name is somewhat misleading; it might be more intuitively called "hops to live." When a packet is first created, its TTL field is set to some value (typically 16, 30, or 255). Every router that handles the packet along its journey decrements the TTL field by 1. If the TTL field ever reaches 0, the packet is assumed to be in some sort of a loop; it is encapsulated within an ICMP "time to live exceeded" message, and is returned to the source address.

Thus, the first router that handles the first of traceroute's specially constructed packets (which has a TTL of 1) will decrement the TTL field, see that it's 0, and return an ICMP "time to live exceeded" message, telling traceroute the IP address of the first router (the source of the ICMP message).

traceroute then constructs another UDP packet, this time with a TTL of 2, and sends it out. This packet gets to the second router before TTL gets decremented to 0, and traceroute knows that the router that returns the ICMP "time to live exceeded" for that packet is the second router along the path to the destination. traceroute then constructs a UDP packet with a TTL of 3, then 4, and so on, to determine the path to the destination.

traceroute knows it's finished when it gets back an ICMP "service unavailable" message, rather than an ICMP "time to live exceeded" message from some intermediate router.

Most versions of traceroute will also note and display relevant ICMP "host unreachable", "network unreachable", and other ICMP messages received.

If traceroute can't reach the destination host (or can't get anything back from it), it eventually times out.

8.12.5 Other ICMP Packets

There are a number of ICMP message types that are used for network management that don't have programs associated with them. These are automatically generated and interpreted by various programs and network devices.

What to do with ICMP messages depends on the message, and the direction it's going in. We've already talked about "echo request", "echo reply", "destination unreachable", "service unavailable" (actually a special type of "destination unreachable"), and "time to live exceeded" messages. The other ICMP message types you probably want to allow, both inbound and outbound, are "source quench" (used by a receiver to tell a sender to "slow down," because it's sending data too fast) and "parameter problem" (which is sort of a catch-all code to return when there is a problem with packet headers that can't be reported any other way).

Many other ICMP message types have the potential to change local information on your hosts (for example, "redirect" causes changes to a host's routing tables), so you probably don't want to allow such messages inbound through your packet filters.

In general, you only want to allow ICMP outbound when it has the chance of doing you some good. Both "source quench" and "parameter problem" are used to get the sending host to be nicer to you, and are worth allowing outbound. Any of the ICMP types that indicates that the connection can't be made ("destination unavailable", "network unavailable", "service unavailable", "destination adminstratively unavailable", or "network administratively unavailable", for example) will help an attacker probe your network without giving you much benefit, and you may want to block these outbound.

8.12.6 Summary of Network Management Recommendations

• Do not allow SNMP across your firewall from the Internet. (This may require special SNMP configurations on your packet filtering routers, which are probably themselves SNMP-capable devices.)

• Do not allow routing protocols (RIP or otherwise) across your firewall to or from the Internet. Routing on the firewall is generally very simple and accomplished best with static routes. Simply configure the firewall to direct packets bound for internal source addresses to an internal router and to direct all other packets to your Internet connection.

• Allow ICMP echo requests outbound, but limit incoming ICMP echo requests to those coming from machines with a legitimate need to probe your network (such as your network service provider's network operations center). Allow ICMP echo responses either way.

• Allow traceroute outbound, but limit incoming traceroute requests to those coming from machines with a legitimate need to probe your network, and limit the port range used.

• Allow only safe ICMP message types, as described above.