This section describes a number of protocols that are used by people and programs to manage and maintain networks: SNMP , RIP , and ICMP - and, where appropriate, the tools, such as ping and traceroute , that use them.
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.
SNMP is a UDP -based service. SNMP servers (in network devices) listen on both TCP and UDP port 161. SNMP trap servers (in management stations) listen on both TCP and UDP port 162. SNMP clients generally use ports above 1023 to talk to both regular and trap servers.
SNMP is not commonly used across the Internet, so proxies for it are not widely available. Although it is a straightforward single-connection protocol, it's often implemented in devices (like dedicated routers) for which source code and compilers are not readily available, making it almost impossible to use with a modified-client proxy system like SOCKS . It shouldn't be too difficult to make it work with modified-procedure proxy systems.
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.
RIP is a UDP -based service. RIP servers listen on port 520 for broadcasts from other servers and requests from clients. RIP servers generally send their broadcasts from port 520. RIP clients generally use ports above 1023.
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.
Many packet filtering systems let you filter ICMP packets in much the same way as TCP or UDP packets: by specifying the ICMP message type code instead of the TCP or UDP source or destination port number. If your packet filtering system has this capability, its documentation should include a list of the ICMP numeric codes or keywords that the packet filtering system understands.
To allow the ping program to operate outbound (i.e., ping 'ing remote hosts), you'll have to allow ICMP echo request packets outbound and ICMP echo response packets inbound. To allow inbound ping (i.e., a remote host ping 'ing a local host), you'll have to allow ICMP echo request packets inbound and ICMP echo response packets outbound.
Because ping is neither TCP nor UDP -based, it won't work with any widely available generic proxy server for modified-client proxying. Because ping transmits no user-supplied data to the destination host, modified-procedure proxying for ping is not possible. Modified-procedure proxying also relies on the ability of the proxy server to intercept the request before the machine it's running on generates a reply, which is difficult with ping . In a pure proxying environment, ping will have to be provided by letting users connect to the proxying host and run ping from there, as discussed in Chapter 7 .
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. 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.
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.
To allow traceroute outbound through your packet filters (i.e., someone running traceroute from the inside, to an external destination), you have to allow the constructed UDP packets outbound, and the relevant ICMP packets (particularly "time to live exceeded" and "service unavailable" back inbound.
To allow traceroute inbound, you have to allow the constructed UDP packets inbound, and the relevant ICMP messages back outbound. You may wish to limit this capability to the machines used by the network operations center of your network service provider, in order to keep a tight reign on the UDP packets allowed through your firewall. Doing so protects RPC -based services like NFS and NIS/YP ) and keeps attackers from using traceroute to discover which addresses at your site are actually assigned to hosts.
Some versions of traceroute can be told (via a command line or a compile-time option) which range of UDP ports to use for the destination. You may need to establish a convention for your site of what port(s) will be allowed through the packet filters for use by traceroute . You don't want to allow any more latitude in your packet filters for traceroute than absolutely necessary (particularly for incoming traceroute ). Because traceroute is UDP -based, an attacker could potentially take advantage of the UDP -based rules in your packet filtering that are there to allow traceroute in order to attack other UDP -based services like NFS and NIS/YP .
Like ping, traceroute could easily be supported by an ICMP -knowledgeable modified-client proxy server. Unfortunately, no such proxy server is widely available. Modified-procedure proxying is not possible with traceroute .
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.
As we've said earlier, ICMP packets do not have source or destination port numbers, but have a single ICMP message type field instead. Many packet filtering systems will let you filter ICMP packets based on that field in the same way they allow you to filter TCP or UDP packets based on the source and destination port number fields. Here are some common ICMP message types, and how you should handle them (whether you should allow them through your firewall, or block them).