A variety of services are used to manage and maintain networks; these are services that most users don't use directly — indeed, that many of them have never even heard of — but they are very important tools for network managers. They are described in detail in Chapter 22.
Simple Network Management Protocol (SNMP) is a protocol designed to make it easy to centrally manage network devices. Originally, SNMP focused on devices that were purely network-oriented (routers, bridges, concentrators, and hubs, for instance). These days, SNMP agents may be found on almost anything that connects to a network, whether or not it's part of the network infrastructure. Many hosts have SNMP agents; large software packages, like databases, often have specialized SNMP agents; and even telephone switches and power systems have network interfaces with SNMP agents.
SNMP management stations can request information from agents via SNMP. SNMP management stations can also control certain functions of the device. Devices can also report urgent information (for example, that a line has gone down, or that a significant number of errors are occurring on a given line) to management stations via SNMP. Devices vary greatly in the sorts of information they give out via SNMP, and in the parameters that can be changed via SNMP. The network devices that originally spoke SNMP used it for mildly sensitive data, like the number of bytes that had gone through a specific port, or the routing table of a given device. Some of them allowed management stations to do potentially catastrophic things (turning off a network interface, for instance), but most of them didn't (if only because many of them simply failed to implement the "set" command, which is required for a management station to actually change anything).
Modern SNMP agents often contain extremely sensitive data; the default SNMP agent for Windows NT includes the complete list of valid usernames on the machine and a list of currently running services, for instance. Many SNMP agents allow for machine reboots and other critical changes. Unfortunately, they are hardly secured at all. SNMP security currently relies on a cleartext password, known as a community string, with a well-known and widely used default. Some SNMP agents implement additional levels of security (for instance, controls over the IP addresses they will accept queries from), but these are still insufficient for extremely sensitive data. Allowing SNMP from the Internet is extremely dangerous.
With the introduction of SNMP v3, which provides better authentication and can encrypt data, it is becoming possible to run SNMP more securely. However, SNMP v3 is not yet widespread.
Routing protocols like RIP and OSPF are used to distribute information about where packets should be directed. Transactions on the Internet involve hosts distributed across the world, which are added, moved, and deleted, all without a single central authority to control them. The Domain Name System provides part of the information necessary to make this work (the mapping between human-readable names and machine-usable numbers), and another critical part is provided by routing services, which distribute information about which numbers are where and how to get to them.
If you interfere with a host's routing, you interfere with its ability to talk to the rest of the world. You can cut it off altogether or merely steal traffic that was intended to go someplace else. Unfortunately, most routing protocols now in use were designed when the Internet was a less dangerous place, and they don't provide any significant degree of protection.
The good news is that routing information rarely needs to go to any significant number of hosts; in general, you will have at most a few routers that talk to the Internet, and those will be the only hosts that need to talk routing protocols to the Internet. In general, you will not need to pass routing protocols through firewalls, unless you are using internal firewalls inside a site.
The two most common network management tools are ping and traceroute (also known as tracert). Both are named after the Unix programs that were the first implementations, but both are now available in some form on almost all Internet-capable platforms. They do not have their own protocols but make use of the same underlying protocol, the Internet Control Message Protocol (ICMP). Unlike most of the programs we've discussed, they are not clients of distinguishable servers. ICMP is implemented at a low level as a required part of the TCP/IP protocols all Internet hosts use.
ping simply tests reachability; it tells you whether or not you can get a packet to and from a given host, and often additional information like how long it took the packet to make the round trip. traceroute tells you not only whether you can reach a given host (and whether it can answer), but also the route your packets take to get to that host; this is very useful in analyzing and debugging network trouble somewhere between you and some destination.
Because there aren't servers for ping and traceroute, you can't simply decide not to turn the servers on. However, you can use packet filtering to prevent them from reaching your machines. There are few risks for outbound ping or traceroute, and those risks can be avoided by using them without hostname resolution. Inbound ping and traceroute, however, pose significant risks. ping, in particular, is a frequent basis for denial of service attacks. ping and traceroute can both be used to determine which hosts at your site exist, as a preliminary step to attacking them. For this reason, many sites either prevent or limit the relevant packets inbound.
Network Time Protocol (NTP), an Internet service that sets the clocks on your system with great precision, has clients on most operating systems (including Unix, Windows NT, and MacOS). Synchronizing time among different machines is important in many ways. From a security point of view, examining the precise times noted on the log files of different machines may help in analyzing patterns of break-ins. Having synchronized clocks is also a requirement for preventing attackers from recording an interaction and then repeating it (a playback attack); if timestamps are encoded in the interaction, they will be incorrect the second time the transaction is replayed. Kerberos authentication, for example, which we discuss in Chapter 21, depends on time synchronization. From a practical point of view, synchronized clocks are also required to successfully use NFS.
You do not have to use NTP across the Internet; it will synchronize clocks to each other within your site, if that's all you want. The reason that people use NTP from the Internet is that a number of hosts with extremely accurate clocks — radio clocks that receive the time signal from master atomic clocks or from the atomic clocks in the Global Positioning System (GPS) satellites — provide NTP service to make certain that your clocks are not only synchronous with each other but also correct. Without an external time service, you might find that all your computers have exactly the same wrong time. Accepting an external service makes you vulnerable to spoofing, but because NTP won't move the clocks very far very fast, a spoofed external clock is unlikely to make you vulnerable to a playback attack, although it could succeed in annoying you by running all your clocks slow or fast. Radio or GPS clocks suitable for use as NTP time sources are not terribly expensive, however, and if you are using NTP to synchronize clocks for an authentication protocol like Kerberos, you should buy your own and provide all time service internally, instead of using an external reference.