#

| Chapter 8 Configuring Internet Services |

## 8.12 Network Management Services

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.

### 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.1.1 Packet filtering characteristics of SNMP

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.

Direc- | Source | Dest. | Pro- | Source | Dest. | ACK |
--- | --- | --- | --- | --- | --- | --- | ---
tion | Addr. | Addr. | tocol | Port | Port | Set | Notes
In | Ext | Int | UDP | >1023 | 161 | [43] | External management station (client) contacting internal SNMP network device (server)
Out | Int | Ext | UDP | 161 | >1023 | [43] | Internal SNMP network device (server) replying to external management station (client)
In | Ext | Int | TCP | >1023 | 161 | [44] | External management station (client) contacting internal SNMP network device (server)
Out | Int | Ext | TCP | 161 | >1023 | Yes | Internal SNMP network device (server) replying to external management station (client)
Out | Int | Ext | UDP | >1023 | 161 | [43] | Internal management station (client) contacting external SNMP network device (server)
In | Ext | Int | UDP | 161 | >1023 | [43] | External SNMP network device (server) responding to internal management station (client)
Out | Int | Ext | TCP | >1023 | 161 | [44] | Internal management station (client) contacting external SNMP network device (server)
In | Ext | Int | TCP | 161 | >1023 | Yes | External SNMP network device (server) responding to internal management station (client)
In | Ext | Int | UDP | >1023 | 162 | [43] | External network device (client) contacting internal SNMP management station (trap server)
Out | Int | Ext | UDP | 162 | >1023 | [43] | Internal SNMP management station (trap server) replying to external network device (client)
In | Ext | Int | TCP | >1023 | 162 | [44] | External network device (client) contacting internal SNMP management station (trap server)
Out | Int | Ext | TCP | 162 | >1023 | Yes | Internal SNMP management station (trap server) replying to external network device (client)
Out | Int | Ext | UDP | >1023 | 162 | [43] | Internal network device (client) contacting external SNMP management station (trap server)
In | Ext | Int | UDP | 162 | >1023 | [43] | External SNMP management station (trap server) responding to internal network device (client)
Out | Int | Ext | TCP | >1023 | 162 | [44] | Internal network device (client) contacting external SNMP management station (trap server)
In | Ext | Int | TCP | 162 | >1023 | Yes | External SNMP management station (trap server) responding to internal network device (client)

> [43] UDP packets do not have ACK bits.

> [44] ACK will not be set on the first packet of this type (establishing connection) but will be set on the rest.

#### 8.12.1.2 Proxying characteristics of SNMP

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.

### 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.2.1 Packet filtering characteristics of RIP

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.

Direc- | Source | Dest. | Pro- | Source | Dest. | ACK |
--- | --- | --- | --- | --- | --- | --- | ---
tion | Addr. | Addr. | tocol | Port | Port | Set | Notes
In | Ext | Int | UDP | >1023 | 520 | [45] | External client request to internal server
Out | Int | Ext | UDP | 520 | >1023 | [45] | Internal server response to external client
Out | Int | Ext | UDP | >1023 | 520 | [45] | Internal client request to external server
In | Int | Ext | UDP | 520 | >1023 | [45] | External server response to internal client
In | Ext | Broadcast | UDP | 520 | 520 | [45] | External server broadcasting to internal servers
Out | Int | Broadcast | UDP | 520 | 520 | [45] | Internal server broadcasting to external servers

> [45] UDP packets do not have ACK bits.

#### 8.12.2.2 Proxying characteristics of RIP

Because RIP allows a host to develop routing tables that are specific to where that host is in the network, it doesn't make any sense to proxy RIP to another host elsewhere in the network.

### 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.3.1 Packet filtering characteristics of ping

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.

Direc- | Source | Dest. | Pro- | Message |
--- | --- | --- | --- | --- | ---
tion | Addr. | Addr. | tocol | Type[46] | Notes
In | Ext | Int | ICMP | 8 | Incoming ping
Out | Int | Ext | ICMP | 0 | Response to incoming ping
Out | Int | Ext | ICMP | 8 | Outgoing ping
In | Ext | Int | ICMP | 0 | Response to outgoing ping

> [46] ICMP messages do not have source or destination port numbers; they have a single ICMP message type field instead. ICMP packets also do not have ACK bits.

#### 8.12.3.2 Proxying characteristics of ping

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.

### 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.4.1 Packet filtering characteristics of traceroute

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.

Direc- | Source | Dest. | Pro- | Source | Dest. | Message |
--- | --- | --- | --- | --- | --- | --- | ---
tion | Addr. | Addr. | tocol | Port[48] | Port[48] | Type[48] | Notes
Out | Int | Ext | UDP | [49] | [49] | [48] | Outgoing traceroute probe
In | Ext | Int | ICMP | [48] | [48] | 11 | Incoming "TTL exceeded"
In | Ext | Int | ICMP | [48] | [48] | 3 | Incoming "service unavailable"
In | Ext | Int | UDP | [49] | [49] | [48] | Incoming traceroute probe
Out | Int | Ext | ICMP | [48] | [48] | 11 | Outgoing "TTL exceeded"
Out | Int | Ext | ICMP | [48] | [48] | 3 | Outgoing "service unavailable"

> [48] UDP packets have source and destination ports; ICMP packets have only message type fields. Neither UDP nor ICMP packets have ACK bits.

> [49] traceroute probe packet UDP source/destination ports vary by implementation, invocation, and/or command-line arguments. They are generally >32768, but that's about the only generalization you can make about them. Specific implementations (particularly in routers and on non-UNIX platforms) may vary. Destination ports, in particular, are usually in the range 33434 through 33523. (Why this is the case is somewhat complicated, and you should read the comments in the UNIX traceroute source code if you're perversely curious.)

#### 8.12.4.2 Proxying characteristics of traceroute

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.

### 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.5.1 Packet filtering characteristics of ICMP

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).

Message |
--- | ---
Type[50] | Description
0 | Echo reply (reply to ping; see ping section above).
3 | Destination unreachable (see traceroute section above). May indicate host unreachable, network unreachable, port unreachable, or other.
4 | Source quench (somebody telling destination "slow down; you're talking too fast"); should probably be allowed.
5 | Redirect (somebody telling destination to change a route); is supposed to be ignored by your systems unless it comes from a directly connected router, but should probably be blocked anyway. In particular, make sure the routers that are part of your firewall ignore it.
8 | Echo request (generated by ping; see ping section above); should probably be allowed.
11 | Time exceeded (packet appears to be looping); should probably be allowed.
12 | Parameter problem (problem with a packet header); should probably be allowed.

> [50] ICMP messages do not have source or destination port numbers; they have a single ICMP message type field instead. ICMP packets also do not have ACK bits.

### 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.

8.11 syslog |  | 8.13 Network Time Protocol (NTP)