Chapter 7. Network Security

At a Glance

Few computers are standalone workstations; most are connected to other computers via modems, networks, or wireless communications. This chapter discusses security issues for administrators configuring computers to participate in networks. First, it examines how the computer connects to the network, with special attention to modems, routers, and wireless access. Then it focuses on network security issues for networks using TCP/IP, the predominant networking protocol on both local area networks and the Internet.

Modems

In this age of the Internet, there are still many reasons to be concerned about with the security of modems and dialup services. Because dialup services are easy to set up and cheap to maintain, there are many that are still in operation — some of which have been in operation for a decade or more. Likewise, even with the wide availability of local area networks and high-speed connections, there are many reasons that you might wish to set up your own modem-based network connections. If people in your organization want to use the computer from their homes after hours or on weekends, a modem will allow them to do so. Administrators can do some remote maintenance and administration when they are “on call.” If some people in your organization travel infrequently, or if they travel to rural areas, they might want to use a modem to access the computer when they’re out of town, particularly if nationwide Internet service is not available or secure.

Despite these benefits, modems come with many risks. Because people routinely use modems to transmit their usernames and passwords, you should ensure that your modems and terminal servers are properly installed, behaving properly, and doing exactly what you think they are doing—and nothing else. Furthermore, because dialup services can be set up with a simple analog phone line or even a cell phone, they can be enabled by an individual without the knowledge or the authorization of an organization’s management.

Modems are a remote access technology born of the 1960s, first deployed in the 1970s, and popularized in the 1980s and 1990s. Nevertheless, modems are still very much a part of the computing landscape today. Attackers know that they can break into many otherwise defended networks by finding modems that have not been properly secured. For this reason, security professionals must be familiar with modem security issues.

Modems and Security

Modems raise a number of security concerns because they create links between your computer and the outside world. Modems can be used by individuals inside your organization to remove confidential information. Modems can be used by people outside your organization to gain unauthorized access to your computer. If your modems can be reprogrammed or otherwise subverted, they can be used to trick your users into revealing their passwords. And, finally, an attacker can eavesdrop on a modem communication.

Despite the rise of the Internet, modems remain a popular tool for breaking into large corporate networks. The reason is simple: while corporations closely monitor their network connections, modems are largely unguarded and unaudited. To maximize security, modems should be provided by the organization and administered in a secure fashion.

The first step is to protect the modems themselves. Be sure they are located in a physically secure location, so that no unauthorized individual can access them. The purpose of this protection is to prevent the modems from being altered or rewired. Some modems can have altered microcode or passwords loaded into them by someone with appropriate access, and you want to prevent such occurrences. You might make a note of the configuration switches (if any) on the modem, and periodically check them to be certain they remain unchanged.

Many modems sold these days allow remote configuration and testing. This capability makes changes simpler for personnel who manage several remote locations. It also makes abusing your modems simpler for an attacker. Therefore, be certain that such features, if present in your modems, are disabled.

The next most important aspect of protecting your modems is to protect their telephone numbers. Treat the telephone numbers for your modems the same way you treat your passwords: don’t publicize them to anyone other than those who have a need to know. Making the telephone numbers for your modems widely known increases the chances that somebody might try to use them to break into your system. If your telephone system permits, change your modem numbers yearly, and request numbers that don’t share the same prefix as your voice phones.

Unfortunately, you cannot keep the telephone numbers of your modems absolutely secret. After all, people do need to call them. And even if you were extremely careful with the numbers, an attacker could always discover the modem numbers by dialing every telephone number in your exchange. For this reason, simple secrecy isn’t a solution; your modems need more stringent protection.

Banners

A banner is a message that is displayed by a modem (or the computer to which the modem is connected) when it is called. Some banners are displayed by the answering system before the caller types anything; other banners are displayed only after a person successfully authenticates.

Banners improve the usability of a system by letting the callers know that they have reached the correct system. They can also include any necessary legal disclosures or notices. Unfortunately, banners can also be used by attackers: an attacker who scans a telephone exchange or a city can use banners to determine which organization’s modems they have found. Avoid including the name of your organization, phone numbers or other contact information, or any information about your computer’s operating system in the banner. You should also avoid any word that expresses “welcome”, as this may be interpreted as an invitation to unauthorized users.

Here are some recommendations for what to put into your banner:

• State that unauthorized use of the system is prohibited and may be prosecuted. (Do not say that unauthorized use will be prosecuted. If some unauthorized users are prosecuted when others are not, the users who are prosecuted may be able to claim selective enforcement of this policy.)

• State that all users of the system may be monitored.

• Tell the user that he is agreeing to be monitored as a condition of using the computer system.

• In some cases, it is acceptable to display no welcome banner at all.

Security Schemes

With today’s telephone systems, if you connect your computer’s modem to an outside telephone line, then anybody in the world can call it.

Although usernames and passwords provide a degree of security, they are not fool-proof. Users often pick bad passwords, and even good passwords can occasionally be guessed or discovered by other means. For this reason, a variety of special kinds of modems and modem use schemes have been developed that further protect computers from unauthorized access.

Password modems

These modems require the caller to enter a password before the modem connects the caller to the computer. As with regular system passwords, the security provided by these modems can be defeated by repeated password guessing or by having an authorized person release his password to somebody who is not authorized. Usually, these modems can only store one to ten passwords. The password stored in the modem should not be the same as the password of any user.

Callback setups

A callback scheme is one in which an outsider calls your machine, connects to the modem, and provides some form of identification. The system then severs the connection and calls the outsider back at a predetermined phone number. Call-back enhances security because the system will dial only preauthorized numbers, so an attacker cannot get the system to initiate a connection to his or her modem. Most callback modems can only store a few numbers to call back.

To operate properly, callback systems must completely disconnect the incoming call before placing the outgoing call. This can be surprisingly difficult on many phone lines, so it’s better to use a different set of modems for the outgoing calls than are used to receive the incoming calls.

It is possible to subvert a callback system that uses two modems. If the attacker has subverted a phone company switch, he can install call-forwarding on the phone number that the callback modem is programmed to dial, and forward those calls back to his modem. Callback schemes can enhance your system’s overall security, but you should not depend on them as your primary means of protection

Encrypting modems

These modems, which must be used in pairs, encrypt all information transmitted and received over the telephone lines. Encrypting modems offer an extremely high degree of security not only against individuals attempting to gain unauthorized access, but also against wiretapping. Some encrypting modems contain preassigned cryptographic “keys” that work only in pairs. Other modems contain keys that can be changed on a routine basis, to further enhance security. Many of the benefits afforded by encrypting modems can be had for less money by using cryptographic protocols over standard modems, such as SSH over a PPP connection.

Caller-ID

In many areas, you can purchase an additional telephone service called Caller-ID (CNID). As its name implies, Caller-ID identifies the phone number of each incoming telephone call. The phone number is usually displayed on a small box next to the telephone when the phone starts ringing. Many modems support Caller-ID directly. When these modems are properly programmed, they will provide Caller-ID information to the host computer when the information is received over the telephone lines.

There are many ways that you can integrate Caller-ID with your remote access services:

• Some remote access systems can be programmed to accept the Caller-ID information directly and log the information for each incoming call along with the time and the username that was provided. The vast majority of remote access systems that support telephone lines delivered over ISDN Basic Rate, ISDN PRI, and T1 Flex-Path circuits include support for logging Caller-ID information in RADIUS accounting log files.238

238 RADIUS, the Remote Authentication Dial In User Service, is a protocol designed to allow terminal servers to authenticate dial-up users against a remote database. It is described in RFC 2138.

• Caller-ID can be very useful for tracking down perpetrators after a break-in. Unlike a username and password, which can be stolen and used by an unauthorized individual, Caller-ID information almost always points back to the actual source of an attack.

• If your remote access system does not handle Caller-ID, you can set up a second modem in parallel with the first on the same line. Program your computer to answer the first modem on the third or fourth ring. Use a third-party Caller-ID logging program to capture the Caller-ID information from the second modem. You will then need to manually combine the two logs.

• ISDN and some other telephone systems offer yet another service called Restricted Calling Groups, which allows you to specify a list of phone numbers that are allowed to call your telephone number. All other callers are blocked.

Advanced telephone services such as these are only as secure as the underlying telephone network infrastructure: many corporate telephone systems allow the corporation to determine what Caller-ID information is displayed on the telephone instrument of the person being called — even for calls that terminate on other parts of the public switched telephone network. Attackers who have control of a corporate telephone system could program it to display whatever phone number they desire, potentially bypassing any security system that depends solely on Caller-ID or Restricted Calling Groups.

Physical intervention schemes

When modems are connected to hardware to allow off-site technicians to remotely maintain or troubleshoot it, you certainly want to prevent unauthorized users from connecting to these modems and reconfiguring your equipment. One simple and effective approach is to leave the modems unplugged from the phone line, and require off-site technicians to call your operator before performing maintenance (or, better yet, the reverse, to make social engineering attacks less feasible.) The operator connects the phone line for the technician’s work (and notes this in a log book), and disconnects it thereafter.

One-Way Phone Lines

Many sites set up their modems and telephone lines so that they can both initiate and receive calls. This may seem like an economical way to make the most use of your modems and phone lines. However, this approach introduces significant security risks. Outgoing modems can be used to make free phone calls at your expense. When both inbound and outbound calls are allowed on the same modems, attackers can subvert callback systems or tie up your outbound lines by using them for inbound connections.

Your system will be more secure if you use separate modems for inbound and outbound traffic. In most environments the cost of the extra phone lines is minimal compared to the additional security and functionality provided by line separation.

You may further wish to routinely monitor the configuration of your telephone lines to check for the following conditions:

• Check to make sure that telephone lines that are not used to call long-distance telephone numbers cannot, in fact, place long-distance telephone calls. Don’t subscribe to long-distance service.

• Check to make sure that telephone lines used only for inbound calls cannot place outbound calls.

• Check to make sure that telephone lines used only for outgoing calls cannot receive calls. Call forwarding is a typical way to insure this.

Protection of Modems and Lines

Although physical protection is often overlooked, protecting the physical access to your telephone line is as important as securing the computer to which the telephone line and its modem are connected.

Be sure to follow these guidelines:

Protect physical access to your telephone line

Be sure that your telephone line is physically secure. Lock all junction boxes. Place the telephone line itself in an electrical conduit, pulled through walls or at least located in locked areas. An intruder who gains physical access to your telephone line can attach his or her own modem to the line and intercept your telephone calls before they reach your computer. By spoofing your users, the intruder may learn their login names and passwords. Instead of intercepting your telephone calls, an intruder might simply monitor them, making a transcript of all of the information sent in either direction. In this way, the intruder might learn passwords not only to your system, but also to all of the systems to which your users connect.

Make sure incoming telephone lines do not allow call forwarding

If your telephone can be programmed for call forwarding, an intruder can effectively transfer all incoming telephone calls to a number of his choosing. If there is a computer at the new number that has been programmed to act like your system, your users might be fooled into typing their usernames and passwords.

Have your telephone company disable third-party billing

Without third-party billing, people can’t bill their calls to your modem line.

Consider using a leased line

If all your modem usage is to a single outside location, consider getting a leased line. A leased line is a dedicated circuit between two points provided by the phone company. It acts like a dedicated cable and cannot be used to place or receive calls. As such, it allows you to keep your connection with the remote site, but it does not allow someone to dial up your modem and attempt a break-in. Leased lines are more expensive than regular lines in most places, but the security may outweigh the cost. Leased lines offer another advantage: you can usually transfer data much faster over leased lines than over standard telephone lines.

Testing Modems

After a modem is connected, you should thoroughly test its ability to make and receive telephone calls. First, make sure that the modem behaves properly under normal operating circumstances. Next, make sure that when something unexpected happens, the computer behaves in a reasonable and responsible way. For example, if a telephone connection is lost, your computer should kill the associated processes and log the user out, rather than letting the next person who dials in access the previous command interpreter. Most of this testing will ensure that your modem’s control signals are being properly sent to the computer (so that your computer knows when a call is in progress), as well as ensuring that your computer behaves properly with this information.

Originate testing

If you have configured your modem to place telephone calls, you need to verify that it always does the right thing when calls are placed as well as when they are disconnected. To test your modem, you must call another computer that you know behaves properly. (Do not place a call to the same computer that you are trying to call out from; if there are problems, you may not be able to tell where the problem lies.)

Test as follows:

1. Try calling the remote computer with a terminal emulation program. Each time the computer answers, you should get a login prompt. You should be able to log in and use the remote computer as if you were connected directly.

2. Hang up on the remote computer by pulling the telephone line out of the originating modem. Your terminal program should realize that the connection has been lost.

3. Call the remote computer again and this time hang up by turning off your modem. Again, your program should realize that something is wrong.

4. Call the remote computer again. This time, leave the telephone connection intact and exit your program. Your modem should automatically hang up on the remote computer.

5. Call the remote computer one last time. This time, do a software disconnect by killing the terminal process on your local computer (either from another terminal or with the Task Manager on Windows systems.) Once again, your modem should automatically hang up on the remote computer.

Other things to check for dialing out include:

• Make sure there is no way to enter your modem’s programming mode by sending an escape sequence. An escape sequence is a sequence of characters that lets you reassert control over the modem and reprogram it. Most modems that use the “AT” command set (originally developed by the Hayes modem company), for example, can be forced into programming mode by allowing a three-second pause; sending three plus signs (+), the default escape character, in quick succession; and waiting another three seconds. If your modem prints “OK,” then your modem’s escape sequence is still active. Many Unix modem control programs disable the modem’s escape sequence, but some do not. On some modems, for example, sending the sequence “+++\rATH0;ATDT611” causes the modem to hang up the phone and dial “611,” the universal number for telephone repair. (While some modems require a 3-second pause between the “+++” and the “\r”, other modems do not, because the 3-second pause was patented by Hayes, and many modem vendors chose not to license the patent.)

If your modem’s escape sequence is not disabled, consult your modem documentation or contact your modem vendor to determine how to disable the sequence. This step may require you to add some additional initialization sequence to the modem software or to set some configuration switches.

• Verify that your modems lock out concurrent access properly. Be sure that there is no way for one user to access a modem that is currently in use by another user.

If the terminal program does not exit when the telephone is disconnected, or if it is possible to return the modem to programming mode by sending an escape sequence, a user may be able to make telephone calls that are not logged. A user might even be able to reprogram the modem, causing it to call a specific phone number automatically, no matter what phone number it was instructed to call. At the other end, a Trojan horse might be waiting for your users.

If the modem does not hang up the phone when the program exits, it can result in abnormally high telephone bills. Perhaps more importantly, your user might remain logged into the remote machine. The next person who uses the program might gain access to that first user’s account on the remote computer.

Answer testing

To test your computer’s answering ability, you need another computer or terminal with a second modem to call your computer.

Test as follows:

1. Call your computer. It should answer the phone on the first few rings and offer a login banner. If your modem is set to cycle among various baud rates, you may need to press the BREAK or linefeed key on your terminal a few

times to synchronize the answering modem’s baud rate with the one that you are using. You should not press BREAK if you are using a modem that automatically selects baud rate.

2. Log in as usual. Then log out. Your computer should hang up the phone.

3. Call your computer and log in a second time. This time, hang up the telephone by pulling the telephone line out of the originating modem. This action simulates having the phone connection accidentally broken. Call your computer back on the same telephone number. You should get a new banner. You should not be reconnected to your old shell or session; that shell should have had its process destroyed when the connection was broken. The system must automatically log you out when the telephone connection is broken. Otherwise, if the telephone is accidentally hung up and somebody else calls your computer, that person will be able to type commands as if he were a legitimate user, without ever having to log in or enter a password.

4. If you have several modems connected to a hunt group (a pool of modems where the first non-busy one answers, and all calls are made to a single number), make sure that the group hunts properly. Many don’t—which results in callers getting busy signals even when there are modems available. Some stop hunting if they connect to a failed modem, rendering the rest of the group inaccessible.

Protecting Against Eavesdropping

Modems are susceptible to eavesdropping and wiretapping. Older modems, including data modems that are slower than 9600 baud and most fax modems, can be readily wiretapped using off-the-shelf hardware. Higher-speed modems can be eavesdropped upon using moderately sophisticated equipment that, while less readily available, can still be had for, at most, thousands of dollars.

Kinds of eavesdropping

There are basically six different places where a telephone conversation over a modem can be tapped. At your premises, an attacker can place a second modem or tape recorder in parallel with your existing instruments. Outside your window, it’s possible to determine the information being sent over modems by analyzing the flashing of their transmit data and receive data lights. Between your premises and the telephone company central office, wires can be spliced. At the telephone company switch, a programmer can install an undetectable tap on a computer switch, or splice the line on a manual switch. If the call is routed over a satellite or microwave link, the radio transmission can be decoded. Finally, at the call’s destination, a wiretap can be installed.

Eavesdropping countermeasures

There are several measures that you can take against electronic eavesdropping, with varying degrees of effectiveness:

Visually inspect your telephone line

Look for spliced wires, taps, or boxes that you cannot understand. Most eavesdropping by people who are not professionals is easy to detect.

Have your telephone line electronically “swept”

Using a device called a signal reflectometer, a trained technician can electronically detect any splices or junctions on your telephone line. Junctions may or may not be evidence of taps; in some areas, many telephone pairs have multiple arms that take them into several different neighborhoods. If you do choose to sweep your line, you should do so on a regular basis. Detecting a change in a telephone line that has been watched over time is easier than looking at a line one time only and determining if the line has a tap on it.

Sweeping may not detect certain kinds of taps, such as digital taps conducted by the telephone company for law enforcement agencies or other organizations, nor will it detect inductive taps.

Use cryptography

The best way to protect your communications from eavesdropping is to assume that your communications equipment is already compromised and to encrypt all the information as a preventative measure. If you use a dialup connection to the Internet, you can use cryptographic protocols such as SSL and SSH to form a crypto-graphic barrier that extends from your computer system to the remote server. VPN systems such as point-to-point tunneling protocol (PPTP) and IPsec can also be used to encrypt all communications between your computer and a remote server.

A few years ago, cryptographic telephones or modems cost more than $1,000 and were only available to certain purchasers. Today, there are devices costing less than $300 that fit between a computer and a modem and create a cryptographically secure line. Most of these systems are based on private key cryptography and require that the system operator distribute a different key to each user. In practice, such restrictions pose no problem for most organizations. But there are also a growing number of public key systems that offer simple-to-use security that’s still of the highest caliber. There are also many affordable modems that include built-in encryption and that require no special unit to work.

Preventing Unauthorized Modems with Telephone Scanning and Telephone Firewalls

Many organizations have policies that forbid the installation and operation of modems without specific permission from the site security manager. Each authorized modem is then audited on a regular basis to assure that it is correctly configured and that it complies with the site’s policies regarding banners, usernames, passwords, and so forth.

Because it is so easy to install a modem, many organizations have modems of which they are unaware. There are two ways to deal with the threat of these so-called rogue modems: telephone scanning and telephone firewalls.

Telephone scanning

You can use a program called a telephone scanner to locate unknown and unauthorized modems. A telephone scanner systematically calls every telephone number in a pre-defined range and notes the banners of the systems that answer. Some telephone scanners can be programmed to attempt to break into the computer systems that they find by using a predetermined list of usernames and passwords. There are both free and commercial telephone scanners available with a wide range of options. Additionally, some computer consulting firms will perform telephone scanning as part of a security audit.

Telephone firewalls

In some situations, the risk of penetration by modem is so high that simply scanning for unauthorized modems is not sufficient. In these situations, you may wish to use a telephone firewall to mediate telephone calls between your organization and the outside world.

Similar to an Internet firewall, a telephone firewall is a device that is placed between your telephone system and an outside communications circuit. Typically, a telephone firewall is equipped with multiple ports for digital T1 telephone lines: instead of plugging a PBX into a T1 from a telephone company, the PBX is plugged into the telephone firewall, and the firewall is plugged into the exterior T1s.

A telephone firewall analyzes the content of every telephone conversation. If it detects modem tones originating or terminating at an extension that is not authorized to operate a modem, the call is terminated and the event is logged. Telephone firewalls can also be used to control fax machines, incoming phone calls, and even unauthorized use of long-distance calls and the use of 800 numbers and 900 services.

Limitations of scanning and firewalls

It is important to realize that neither telephone scanning nor telephone firewalls can do more than detect or control modems that use telephone lines that you know about. Suppose that your organization has a specific telephone exchange: in all likelihood, you will confine your telephone scanning and telephone firewall to that exchange. If some worker orders a separate telephone line from the phone company and pays for that line with his own funds, that phone number will not be within your organization’s telephone exchange and will, therefore, not be detected by telephone scanning. Nor will it be subject to a telephone firewall. A cell phone connected to a modem is also not going to be within your defined exchange.

In many cases, the only way to find rogue telephone lines is through a detailed physical inspection of wiring closets and other points where external telephone lines can enter an organization. In an environment that is rich with authorized wireless devices, it can be even harder to find unauthorized wireless devices.

Networks

Although telephone modems are still widely used to connect computers, millions of computers are connected to one another through higher-speed networks. From a practical viewpoint, computer users today usually divide the world of networking into two halves:

Local area networks

LANs are high-speed networks used to connect computers at a single location. Although the original Ethernet network was a broadcast network that sent high-frequency transmissions over a coaxial cable, today the term Ethernet is widely taken to refer to a twisted-pair network assembled with hubs or switches that can transmit information at speeds of 10, 100, or 1,000 Mbps. Wireless networks that operate over a relatively short range— within an office or home—also constitute “local area networks.” The protocols involved in either case are defined in standards developed by the Institute of Electrical and Electronics Engineers (IEEE).

Two computers can also be directly connected to each other with a serial line. IP packets are then sent using PPP (Point-to-Point Protocol), SLIP (Serial Line Internet Protocol), or CSLIP (Compressed SLIP). If each computer is, in turn, connected to a local area network, the serial line can bridge together the two LANs.

Wide area networks

WANs are typically slower-speed networks that organizations use to connect their LANs. WANs are often built from leased telephone lines and long-distance data circuits (which may transit satellite links, microwave connections, and fiber optic cables) capable of moving data at speeds between 56 Kbps and gigabits per second. A WAN might bridge a company's offices on either side of a town or on either side of a continent. Some WANs are shared by several organizations.

A special kind of WAN link that's become increasingly popular is the Virtual Private Network (VPN). The VPN is a virtual network because the packets travel over the Internet (or some other public network); it's a private network because the data in the packets is encrypted to prevent anyone on the public network from reading it or tampering with it. A VPN can connect multiple locations much more cheaply than leasing lines between them.

One of the first computer networks was the ARPANET, developed in the early 1970s by universities and corporations working under contract to the U.S. Department of Defense's Advanced Research Projects Agency (ARPA or DARPA). The ARPANET linked computers around the world and served as a backbone for many other regional and campuswide networks that sprang up in the 1980s.

Today, the descendant of the ARPANET is known as the Internet. The Internet is an IP-based network that encompasses hundreds of millions of computers and more than a billion users throughout the world. Some of these computer systems are constantly connected, while others are connected only intermittently. Any one of those users can try to send you electronic mail, exchange files with your FTP file server, or break into your system—if your system is configured to allow them the access necessary to do so.

Gateways and Routers

Despite the complexity of the Internet and IP addressing, computers can easily send each other messages across the global network. To send a packet, most computers simply set the packet's destination address and then send the packet to a computer on their local network called a gateway. If the gateway makes a determination of where to send the packet next, the gateway is a router. The router takes care of sending the packet to its final destination by forwarding the packet to a directly connected gateway that is (supposed to be) one step closer to the destination host.

Many organizations configure their internal networks as a large tree. At the root of the tree is the organization's connection to the Internet. When a gateway receives a packet, it decides whether to send it to one of its own subnetworks or direct it towards the root. Out on the Internet, major IP providers have far more complicated networks with sophisticated routing algorithms and specialized routing protocols. Many of these providers have redundant networks so that if one link malfunctions, other links can take over.

Small office and home users can easily purchase 4-port and 8-port Ethernet routers that are designed to connect to a broadband DSL or cable modem connection and route packets between the home computers and the broadband modem (and from thence to the Internet). An important feature of these devices (and one that is also supported by high-end routers) is Network Address Translation (NAT). NAT is a general system for translating IP addresses in data packets received by the router to other addresses before (or after) the packet’s destination is chosen by the router and the packet is sent out to that destination. It is most commonly used to allow several internal computers with private (nonroutable) IP addresses to share a single external (public) IP address, or to translate public IP addresses for groups of computers into corresponding private IP addresses on an internal network. Because the internal IP addresses cannot be reached directly from the public Internet (because no other routers will be able to correctly route them), NAT schemes provide some protection against outsiders initiating connections to internal machines, while still making it possible for the internal machines to initiate and maintain connections to the Internet.

A second feature of high-end routers is the ability to establish a Virtual Private Network (VPN) between two LANs in separate locations (e.g., two branch offices). Pairs of routers create VPNs between them using protocols like IPsec, and then route traffic between the LANs through the VPN rather than over the unprotected Internet.

Routers often represent the border of an organization’s network security perimeter, as well as a point of vulnerability. If a router is subverted, attackers can redirect packets intended for the organization elsewhere, or gain inappropriate access to internal hosts or network layout information. Each router vendor offers different programming features, which can make securing routers a challenge. A recommended practice is to insure that routers can only be programmed by those with physical access (to a terminal connected by a serial cable, for example), and not through the network. Router configuration menus should always be password-protected, and if routers are to be SNMP-managed, read access to the router should be password-protected and write access disabled.

Borders routers should be equipped with egress filters so that they will not send packets out of a network unless the packet has a valid source IP address located within the network. They should also be configured with ingress filters to insure that packets claiming to be from within the network will not be accepted on the router’s external interface and routed into the network.

External Firewalls

A firewall is a device that is designed to prevent traffic from flowing between two networks, with the exception of traffic passing through designated “holes” in the firewall.

Firewalls are typically divided into two types: packet filters and application gateways. Packet-filtering firewalls intercept and analyze network data packets and determine if they should be allowed to pass through the firewall or not. Traditional packet-filtering firewalls are relatively simple-minded. They can allow, deny, or otherwise mangle packets using the information contained in the packet’s headers, such as source and destination addresses and ports, and packet flags like SYN.

Packet filters that perform stateful inspection keep track of the state of each connection passing through the firewall and may examine the contents of each packet in greater detail in order to determine whether they “belong” to a particular connection. For example, a stateful firewall can identify an FTP data transfer connection, determine that it is associated with an existing FTP control connection, and allow it, while disallowing a new inbound connection on the same port.

An application gateway operates at the application level of the network, rather than the packet level, and is typically built of several proxies for application services to be provided. Rather than connect to the organization’s web server itself, outsiders might connect to the firewall’s web server proxy operating on port 80. The proxy software insures that the connection is appropriate, may validate the data stream, and then passes it on to the actual internal web server; the proxy is similarly responsible for relaying the outbound data from the web server back to the client.

Some policies that an external firewall might be used to implement include:

• Disallow all incoming traffic by default, but permit a few exceptions, such as allowing anyone to make an HTTP connection to port 80, and a list of predefined hosts to make an SSH connection to port 22. This “deny everything that isn’t permitted” approach is a recommended security practice.

• Allow outgoing HTTP connections to anywhere on the Internet, but only allow incoming connections to a few select hosts.

• Log firewall violations for later analysis.

Several (very good) books on firewalls are available that discuss their design and deployment in depth, including how to organize multiple firewalls to partition the network into a subnetwork of hosts that outsiders can access (often called the “demilitarized zone”) and a subnetwork of hosts that are protected from outsiders. Especially recommended are Cheswick, Bellovin, and Rubin’s 2003 book Firewalls and Internet Security: Repelling the Wily Hacker, Second Edition, and Zwicky, Cooper, and Chapman’s 2000 book Building Internet Firewalls, Second Edition.

Host-Based Firewalls

Many systems, including most Unix systems and recent Microsoft systems, contain a built-in packet filter. Some, like Linux 2.4’s netfilter component, provide stateful inspection of packets as well. The firewall is controlled with rules that are loaded into the kernel at runtime. Rules can block or allow packets to flow based on packet type, host, protocol, and even packet-level flags. Guidelines for configuration of host-based packet filters are largely the same as those for external firewalls.

The rules that you add to the kernel with a packet-level firewall are in addition to any access control rules that you might implement within network applications, with the tcpwrapper system (discussed below),or with any external firewall that may be protecting the network that the host is on. The kernel-level firewall can give you an additional layer of protection and is an important part of a defense-in-depth strategy.

The primary disadvantage of packet-level firewalls is that they consume some CPU power; this can be a special concern on systems that are heavily loaded and in cases where the rule sets are very long — the added CPU requirements may be more than your system can handle! For most situations, however, packet-level firewalls do not place an excessive burden on the system. For example, an Intel-based 486 running at 33Mhz with a free Unix kernel can easily handle the traffic of a fully-loaded T1 or DSL line.

Most host-based firewalls allow you to configure rules that will apply to incoming packets destined for the host, outgoing packets leaving the host, or packets being forwarded by a host that is serving as a gateway. Filtering incoming packets is an important way to restrict access to network services. Filtering outgoing packets can limit accidental exposure of important system resources and configuration information, and can reduce the damage that can be done if the machine should be compromised by a Trojan. It can also help enforce policies on acceptable network use, but sufficiently knowledgeable users can often tunnel connections through outbound filters. One of the more interesting developments in host-based firewalls is on-demand filtering. If you’re not running several services because of known vulnerabilities, you might instead run a monitor that listens on the unused ports – or even on every unused port below 1024. If a remote host tries to connect to your host for NNTP when you’re not a news server, or to use the TFTP service, the monitor takes action: logging the attempt, adding the remote host’s IP address to a tcpwrapper deny rule, or adding a host-based firewall rule to block the remote host from any connections. If you’re concerned about accidentally blocking an innocent host, the monitor might be configured to require multiple probes before firewalling the remote host. Several free and commercial scan-detection monitors are available for different platforms.

Wireless Networking

An increasingly prevalent networking strategy, particularly in locations where adding network infrastructure would be costly or infeasible, is wireless networking. Wireless networks generally follow the IEEE 802.11 standards, which include 802.11b, 802.11a, and 802.11g239. In a typical wireless network, devices called wireless access points are installed to receive and transmit data within a given area (e.g. one floor of a building). Access points may be bridged to one another, but eventually must connect to the organization’s (wired) router if packets are to be routed outside of the organization.

There are several important security considerations in setting up a wireless network. Data on the network should be private – it should be infeasible for an attacker to eavesdrop. Moreover, it should be infeasible for an attacker to join the wireless network and take advantage of its resources (such as Internet connectivity).

Unfortunately, wireless networking does not have a good security record. In particular, most 802.11b networks offer little protection. Although a protocol for link-level encryption called WEP (wired equivalent protocol) is widely used, WEP has been demonstrated to be fundamentally flawed, and attackers with relatively simple hardware (a laptop and a wireless card) can capture enough data packets to divulge the encryption key and render all of the data visible. The most popular access control approaches, such as MAC filtering (only allowing wireless clients with known hardware addresses to connect), are also relatively weak, as MACs are easy to determine and can be changed. Although it’s a good idea to enable all of these security features, as well as changing default SSIDs and turning off SSID broadcast, they do not add up to a secure wireless network.

On older 802.11b networks, confidentiality can generally be achieved only by requiring clients to use additional end-to-end encryption (such as SSH or VPN systems) for their connections. Access control can be managed through use of a captive portal. In this system, a firewall (ideally, operating on each access point), blocks all

239 Other wireless devices, like cell phones and PDAs, may use GSM cellular networks instead. Many of the problems that plague 802.11 networks are also prevalent in GSM networks; for more information, see “Mobile Risk Management: E-Finance in the Wireless Environment (2002), by Tom Kellermann for The World Bank: www.worldbank1.org/finance

unauthenticated traffic except traffic directed to the portal application, which is responsible for (securely) authenticating the user, and directing the firewall to allow packets from the authenticated machine to be routed for a limited time. For example, the portal application might run on an SSL-protected web and RADIUS server connected by Ethernet to the access point.

A more secure approach is outlined in the IEEE 802.1x standard. Wireless devices that support this standard use the Extensible Authentication Protocol (EAP) to exchange authentication data. Wireless clients start out in an unauthenticated mode in which they can only send the initial EAP packet. The access point responds with an EAP request for the client’s identity, which the client transmits. This conversation occurs over a secure channel, most commonly implemented via a variation of TLS. The access point authenticates the identity and changes the client’s mode to authenticated. It transmits an initial WEP key to be used to encrypt the wireless data, and can change keys during the connection; by changing keys frequently, attacks against WEP that rely on capturing many packets with the same key are prevented.

A new specification, Wi-Fi Protected Access™ (WPA), offers an improved encryption system in place of WEP, and the ability to perform authentication either through 802.1x or by use of a shared key. The latter mode is primarily intended for home or small office users who cannot set up their own RADIUS servers for 802.1x authentication. Like wired networks, wireless networks can also benefit from appropriate configuration of packet filters on access points, appropriate location of access points in the network topology (ideally, outside the internal firewall), and similar approaches to hardening network security. Running a network intrusion detection system on the wireless network is also a good practice.

Finally, note that wireless networks are susceptible to jamming. For example, a leaky microwave oven can effectively disrupt a wireless network based on the Wi-Fi (802.11) technology, as both microwave ovens and Wi-Fi systems use the same band of the 2.4Ghz spectrum. Although jamming may not lead to information disclosure, it can effectively make a wireless network unusable.

Two useful books for building secure wireless networks are 802.11 Security and RADIUS, both published by O’Reilly and Associates.

TCP/IP Networking

The Internet Protocol (IP) is the glue that holds together modern computer networks. IP specifies the way that messages are sent from computer to computer; it essentially defines a common “language” that is spoken by every computer stationed on the Internet.

IPv4, the fourth version of the Internet Protocol, has been used on the Internet since 1982. IPv4 is universally used today, and will likely see continued use for many years to come. IPv5 was an experimental protocol that was never widely used. IPv6 is the newest version of the Internet Protocol. IPv6 provides for a dramatically expanded address space, built-in encryption, and plug-and-play Internet connectivity. As of 2003, IPv6 is largely being used on an experimental basis, although use of this new Internet Protocol is slowly increasing.

On the Internet, data is sent in blocks of characters called datagrams, or more colloquially, packets. Each packet has a small block of bytes called the header, which identifies the sender and intended destination on each computer. The header is followed by another, usually larger, block of characters of data called the packet's contents. After the packets reach their destination, they are often reassembled into a continuous stream of data; this fragmentation and reassembly process is usually invisible to the user. As there are often many different routes from one system to

another, each packet may take a slightly different path from source to destination. Because the Internet switches packets, instead of circuits, it is called a packet-switching network.

The IP packets can themselves be encapsulated within packets used by other network protocols. Today, many IP networks built from “leased lines” actually send IP packets encapsulated within Frame Relay or ATM (Asynchronous Transfer Mode) networks.

IP addressing

Every interface that a computer has on an IPv4 network is assigned a unique 32-bit address. These addresses are often expressed as a set of four 8-bit numbers called octets. A sample address is 18.70.0.224. A computer can have multiple network interfaces, each with a different address, and potentially with each on a different LAN or serial line.

Theoretically, the 32-bit IP address allows a maximum of 232 = 4,294,967,296 computers to be attached to the Internet at a given time. In practice, the total number of computers that can be connected is much more than 232 because it is possible for many computers to share a single IP address through the use of technologies such as proxies and Network Address Translation. These multiple systems behind the single IP address can be configured with a variety of policies to govern connectivity between machines, allowing no access, restricted access, or unlimited access in either or both directions.

IP networks

The Internet is a network of networks. Although many people think of these networks as being major networks, such as those belonging to companies like AT&T, WorldCom, and Sprint, most of the networks that make up the Internet are actually local area networks, such as the network in an office building or the network in a small research laboratory. Each of these small networks is given its own network number.

There are two methods of looking at network numbers. The “classical” network numbers were distinguished by a unique prefix of bits in the address of each host in the network. This approach partitioned the address space into a well-defined set of differently sized networks. There are five primary kinds of IP addresses in the “classical” address scheme; the first few bits of the address (the most significant bits) define the class of network to which the address belongs. The remaining bits are divided into a network part and a host part:

Class A addresses

Hosts on Class A networks have addresses in the form N.a.b.c, in which N is the network number and a.b.c is the host number; the most significant bit of N must be 0. There are not many Class A networks, as they are quite wasteful; unless your network has 16,777,216 separate hosts, you don't need a Class A network. Nevertheless, many early pioneers of the Internet, such as MIT and Bolt Beranek and Newman (BBN), were assigned Class A networks. Of course, these organizations don't really put all of their computers on the same physical network. Instead, most of them divide their internal networks as (effectively) Class B or Class C networks. This approach is known as subnetting.

Class B addresses

Hosts on Class B networks have addresses in the form N.M.a.b, in which N.M is the network number and a.b is the host number; the most significant two bits of N must be 10. Class B networks are commonly found at large universities and major commercial organizations.

Class C addresses

Hosts on Class C networks have addresses in the form N.M.O.a, in which N.M.O is the network number, and a is the host number; the most significant three bits of N must be 110. These networks can only accommodate a maximum of 254 hosts. (Flaws and incompatibilities between various IP implementations make it unwise to assign IP addresses ending in either 0 or 255.) Most organizations have one or more Class C networks.

Class D addresses

A Class D address is of the form N.M.O.a, in which the most significant four bits of N are 1110. These addresses are not actually of networks, but of multicast groups, which are sets of hosts that listen on a common address to receive broadcasts.

Class E addresses

A Class E address is of the form N.M.O.P, in which the most significant four bits of N are 1111. These addresses are currently reserved for experimental use.

Several of these network classes had large “holes” – sets of host addresses that were never used. With the explosion of sites on the Internet, a somewhat different interpretation of network addresses has been proposed, which allows more granularity in the assignment of network addresses and less waste. This approach is the Classless InterDomain Routing (CIDR) scheme.

As the name implies, there are no “classes” of addresses as in the classical scheme. Instead, networks are defined as being the most significant k bits of each address, with the remaining 32-k bits being used for the host part of the address. Thus, a service provider could be given a range of addresses whereby the first 14 bits of the address are fixed at a particular value (the network address), and the remaining 18 bits represent the portion of the address available to allocate to hosts. This method allows the service provider to allocate up to 218 distinct addresses to customers.

CIDR networks are often abbreviated as the lowest IP address in the range, followed by a slash and the size, in bits, of the network portion. For example, the network 128.200.0.0/14 represents all of the IP addresses from 128.200.0.0 to 128.203.255.255. Another way that this network is often abbreviated is with the lowest IP address in the range, followed by a slash and the netmask, which is the dotted octet in which the k most significant bits are 1s and all others are 0s. In our example, this abbreviation would be 128.200.0.0/255.252.0.0.

The CIDR scheme is compatible with the classical address format, with Class A addresses using an 8-bit network field (e.g., 10.0.0.0/8), Class B networks using a 16-bit network address (e.g., 192.168.0.0/16), and so on.

Packets and Protocols

Today there are four main kinds of IP packets that are sent on the Internet that will be seen by typical hosts (additional types of packets may be used by routers on major backbones or in VPNs). Each is associated with a particular protocol:

ICMP

Internet Control Message Protocol. This protocol is used for low-level operation of the IP protocol. There are several subtypes—for example, for the exchange of routing and traffic information.

TCP

Transmission Control Protocol. This protocol is used to create a two-way stream connection between two computers. It is a “connected” protocol and includes time-outs and retransmission to ensure reliable delivery of information.

UDP

User Datagram Protocol. This protocol is used to send packets from host to host. The protocol is “connectionless” and makes a best-effort attempt at delivery. Although the protocol is technically unreliable because it does not guarantee that information sent will be delivered, in practice most UDP packets reach their destination under normal operating circumstances.

IGMP

Internet Group Management Protocol. This protocol is used to control multicasting, which is the process of purposely directing a packet to more than one host. Multicasting is the basis of the Internet's multimedia backbone, the MBONE. (Currently, IGMP is not used inside the MBONE, but is used on the edge.)

ICMP

The Internet Control Message Protocol is used to send messages between gateways and hosts regarding the lowlevel operation of the Internet. For example, the ping command uses ICMP Echo packets to test for network connectivity; the response to an Echo packet is usually either an ICMP Echo Reply or an ICMP Destination Unreachable message type.

In addition to the information in the IP header (packet source and destination addresses), each ICMP packet contains an ICMP header that includes an 8-bit packet type value. Some of the ICMP packet types are no longer used on the Internet, although many of them remain supported in most TCP/IP implementations. This has been an occasional source of security problems. In particular, packet types 3 (destination unreachable), 4 (source quench), and 5 (redirect) present security risks, because an attacker who can craft ICMP packets of these types can redirect network traffic or perform a denial of service. Although the other packet types present less of an immediate risk, different versions of different operating systems often have subtly different responses to these ICMP packets, and attackers can use the pattern of responses to help “fingerprint” the operating system on your system to exploit known bugs. If you use a firewall, you should be sure that many ICMP packet types are blocked or monitored. You can generally safely block incoming ICMP packets of types 5, 13 (timestamp request), 14 (timestamp reply), 17 (address-mask request), and 18 (address-mask reply), and outgoing ICMP packets of types 5, 11 (time exceeded), 12 (parameter problem), 13, 14, 17, and 18.

TCP

TCP provides a reliable, ordered, two-way transmission stream between two programs that are running on the same or different computers. “Reliable” means that every byte transmitted is guaranteed to reach its destination (or you are notified that the transmission failed), and that each byte arrives in the order in which it was sent. Of course, if the connection is physically broken, bytes that have not been transmitted will not reach their destination unless an alternate route can be found. In such an event, the computer's TCP implementation should send an error message to the process that is trying to send or receive characters, rather than give the impression that the link is still operational.

Each TCP connection is attached at each end to a port. Ports are identified by 16-bit numbers. For most TCP protocols the server uses the port number assigned to the service it is providing, and the client's port number is randomly chosen by the client on a per-connection basis. Some well-known port numbers are port 80 for HTTP servers and port 25 for SMTP servers.

On the wire, TCP packets are IP packets that include an additional TCP header. This header contains, among other things:

• TCP port number of the packet's source.

• TCP port number of the packet's destination.

• Sequence information, so that the receiver can correctly assemble the information in this TCP packet to its correct point in the TCP stream.

• Flow control information, which tells the receiver how many more bytes the originator of the packet can receive. This is called the TCP window.

• TCP checksum.

At any instant, every IPv4TCP connection on the Internet can be identified by a set of two 32-bit numbers and two 16-bit numbers:

• Host address of the connection's originator (from the IP header)

• Port number of the connection's originator (from the TCP header)

• Host address of the connection's target (from the IP header)

• Port number of the connection's target (from the TCP header)

The TCP protocol uses two special bits in the packet header, SYN and ACK, to negotiate the creation of new connections. To open a TCP connection, the requesting host sends a packet that has the SYN bit set but does not have the ACK bit set. The receiving host acknowledges the request by sending back a packet that has both the SYN and the ACK bits set. Finally, the originating host sends a third packet, again with the ACK bit set, but this time with the SYN bit unset. This process is called the TCP “three-way handshake.” By looking for packets that have theSYN bit set and the ACK bit unset, one can distinguish packets requesting new connections from those that are sent in response to connections that have already been created. This distinction is useful when constructing packet filtering-firewalls.

TCP is used for most Internet services that require the sustained synchronous transmission of a stream of data in one or two directions. For example, TCP is used for the hypertext transfer protocol (HTTP), remote terminal service, file transfer, and electronic mail. TCP is also used for sending commands to displays using the X Window system. Table 5A identifies some common TCP services. Significant security problems of exploitable weaknesses have been found in the majority of them, as indicated in the notes.

Security concerns:

a) Service can be remotely exploited to create a denial-of-service attack.

b) Protocol requires that a password be transmitted in cleartext across the Internet without the use of any encryption (under IPv4).

c) Improper configuration of SMTP servers, CGI scripts, and proxies is a leading contributor to the relaying of unwanted junk e-mail on the Internet.

d) Service is commonly configured for authentication using IP addresses. This is subject to spoofing and other kinds of attacks.

UDP

The User Datagram Protocol provides a simple, unreliable system for sending packets of data between two or more programs running on the same or different computers. “Uunreliable” means that the operating system does not guarantee that every packet sent will be delivered, or that packets will be delivered in order. UDP does make a best effort to deliver the packets, however. On a LAN or uncrowded Internet path, UDP often approaches 100% reliability. UDP's advantage is that it has less overhead than TCP—less overhead lets UDP-based services transmit information

Table 5A. Some common TCP services and ports

(virtual terminal and file transfer)

Remote Procedure Call (RPC)

Protocol (NNTP) (Usenet)

remote Unix host

513

login

Logs in to a remote Unix

b, d

Disable

host ( rlogin )

514

shell

Retrieves a shell on a

b, d

Disable

remote Unix host ( rsh )

6000-6010

X

X Window system

b, d

Restrict access, tunnel through SSH

with as much as 10 times the throughput. UDP is used primarily for Sun's NetworkInformation System (NIS) and Network Filesystem (NFS), for resolving hostnames, and for transmitting routing information. It is also used for services that aren't affected negatively if they miss an occasional packet because they will get another periodic update later, or because the information isn't really that important.

As with TCP, UDP packets are also sent from a port on the sending host to another port on the receiving host. Each UDP packet also contains user data. If a program is listening to the particular port and is ready for the packet, it will be received. If no program is listening, the packet will be ignored, and the receiving host will return an ICMP error message. If a program is listening but is not prepared to receive the packet, it may simply be queued and eventually received, or simply lost.

In contrast to TCP packets, UDP packets can be broadcast, which causes them to be sent to the same port on every host that resides on the same local area network. Broadcast packets are used frequently for services such as time of day.

Ports are identified by 16-bit numbers. Table 5B lists some common UDP ports.

Table 5B. Some common UDP services and ports

another datagram

Protocol (DHCP)

69

tftp

Trivial File Transfer

c

Disable

Protocol (TFTP)

111

sunrpc

Sun Microsystems' Remote

c

Restrict access

Procedure Call (RPC) portmapper

137-139, 445 Smb

Microsoft networking and

Restrict access

file sharing

Protocol (SNMP)

Security concerns:

a) Service can be remotely exploited to create a denial-of-service attack.

b) Protocol requires that a password be transmitted in cleartext across the Internet without the use of any encryption.

c) Service is commonly configured for authentication using IP addresses. This is subject to spoofing and other kinds of attacks.

Clients and Servers

The Internet Protocol is based on the client/server model. Programs called clients initiate connections over the network to other programs called servers, which wait for the connections to be made. One example of a client/server pair is the Network Time System. The client program is the program that asks the network server for the time. The server program is the program that listens for these requests and transmits the correct time. In Unix parlance, server programs that run in the background and wait for user requests are often known as daemons. In the Microsoft world, they are called services.

You can connect to an arbitrary TCP/IP port of a computer using the telnet program. (The telnet program was originally used for logging into remote systems. However, as this requires sending an unencrypted password over the network, such use of the telnet program is now strongly discouraged.) For instance, you might connect to port 25 (the SMTP port) to fake some mail without going through the normal mailer:

% telnet control.mil 25 Trying 45.1.12.2 ... Connected to hq.control.mil. Escape character is '^]'.

220 hq.control.mil ESMTP Sendmail 8.11.6/8.11.6; Sun, 18 Aug 2002 21:21:03 –0500 HELO kaos.org

250 hq.control.mil Hello kaos.org, pleased to meet you MAIL FROM:<agent86@control.mil> 250 <agent86>... Sender ok

RCPT TO:<agent99@control.mil> 550 <agent99>... Recipient ok DATA

354 Enter mail, end with “.” on a line by itself To: agent99

From: Max <agent86> Subject: tonight

99, I know I was supposed to take you out to dinner tonight, but I have been captured by KAOS agents, and they won't let me out until they finish torturing me. I hope you understand. Love, Max

.

250 UAA01441 Message accepted for delivery QUIT

221 hq.control.mil closing connection Connection closed by foreign host. %

Hostnames and DNS

A hostname is the name of a computer on the Internet. Hostnames make life simpler for users: they are easier to remember than IP addresses. You can change a computer's IP address but keep its hostname the same. A single hostname can have more than one IP address, and a single IP address can be associated with more than one hostname. Both of these facts have profound implications for people who are attempting to write secure network programs.

Hostnames must begin with a letter or number and may contain letters, numbers, and a few symbols, such as the hyphen (-)240. Case is ignored. A sample hostname is tock.cerias.purdue.edu. For more information on hostnames, see RFC 1122 and RFC 1123.

Each hostname has two parts: the computer's machine name and its domain. The computer's machine name is the name to the left of the first period; the domain name is everything to the right of the first period. In our example above, the machine name is tock, and the domain is cerias.purdue.edu. The domain name may represent further hierarchical domains if there is a period in the name. For instance, cerias.purdue.edu represents the CERIAS center domain, which is part of the Purdue University domain, which is, in turn, part of the Educational Institutions toplevel domain.

In the early days of the Internet, a single file (/etc/hosts) contained the address and name of each computer on the Internet. But as the file grew to contain thousands of lines, and as changes to the list of names started being made on a daily basis, a file soon became impossible to maintain. Instead, the Internet developed a distributed network-based naming service called the Domain Name Service (DNS).

DNS implements a large-scale distributed database for translating hostnames into IP addresses and vice-versa, and performing related name functions. The software performs this function by using the network to resolve each part of the hostname distinctly. For example, if a computer is trying to resolve the name girigiri.gbrmpa.gov.au, it would first get the address of a root domain server (usually stored in a file) and ask that machine for the address of an autop-level domain server. The computer would then ask the au domain server for the address of a gov.au domain server, and then would ask that machine for the address of a gbrmpa.gov.au domain server. Finally, the computer would then ask the gbrmpa.gov.au domain server for the address of the computer called girigiri.gbrmpa.gov.au. A variety of caching techniques are employed to minimize overall network traffic.

DNS hostname lookups are typically performed over UDP, but DNS also uses TCP for some operations.

IP Security

The Internet and the IP protocols are vulnerable to many different kinds of attacks, including password guessing, social engineering, bugs in software, network sniffing, packet spoofing and data tampering, connection hijacking, and denial of service attacks. Many of these attacks were anticipated years before they arose in the wild. Yet the IP protocols and the Internet itself are not well-protected against them.

IP was not designed to provide security and is not resilient to purposeful attack. Several techniques can add security to IP networks. These include application access controls, using encryption, advanced authentication systems, SSH, and decoy systems (honeypots). Each is discussed in detail below. In addition, the use of firewalls (discussed earlier), hardening server hosts (discussed in chapter 5-5), and physical isolation of vulnerable systems can be employed to enhance security.

240 Technically, hostnames should not contain the underscore (_) character, but most systems that map hostnames to IP addresses grudgingly accept the underscore, and Microsoft's Active Directory service effectively requires it, in violation of at least one RFC.

Application Access Controls

Many network applications can be configured with access control lists that determine which hosts are permitted to connect to the application (or, in a less secure but common configuration, which hosts are prohibited from connecting).

On Unix systems, a standard access control mechanism for applications has developed around Wietse Venema’s tcpwrappers system, which consists of a library for access control checking (libwrap), a wrapper program for adding access checks to network servers that don’t use the library (tcpd), and a pair of access control configuration files (/etc/hosts.allow and /etc/hosts.deny). On modern systems, /etc/hosts.deny should contain a catchall deny rule (“ALL:ALL”), while /etc/hosts.allow should contain rules that permit access to specific services by specific hosts.

In addition to permitting or denying connections, the tcpwrappers system can perform double reverse name lookups, do extra logging, perform ident lookups on connections (see below), send banners to connecting clients, and even run auxiliary commands or substitute a fake environment to study the behavior of the connecting client. Accordingly, tcpwrappers can make up for deficiencies in other network server programs. For details on configuring tcpwrappers, see PUIS, 315-323.

On other operating systems, each application typically manages its own access control lists (or relies on the system’s host-based packet filter).

Using Encryption to Protect IP Networks from Eavesdropping

IP is designed to get packets from one computer to another computer; the protocol makes no promise as to whether other computers on the same network will be able to intercept and read those packets in real time. Such interception is called eavesdropping or packet sniffing.

On Ethernet and unswitched twisted-pair networks, the potential for eavesdropping is high because packets can be intercepted by any host on the network. Using an Ethernet switch can dramatically reduce the potential for eavesdropping. A switch is a special-purpose device that transmits packets only to the computers for which they are destined. However, it is still possible to monitor a switched network by programming the switch to create a mirror or monitor port, or to attack a switch to attempt to confuse its internal table associating computers and addresses. Although token ring networks are not inherently broadcast, in practice all packets that are transmitted on the ring pass through, on average, one-half of the interfaces that are on the network, so equivalent concerns apply. As discussed earlier in this chapter, telephone lines and wireless networks can also be sniffed; in a similar fashion, IP transmissions over cable TV or power lines can be intercepted.

In short, with most network technologies it is impossible to prevent or even detect eavesdropping. The only thing you can do is assume that your network traffic is in fact being eavesdropped and use encryption so that the recorded network traffic will not be useful to an attacker241.

There are several places where encryption can be used to improve the security of IP networking protocols:

Link-level encryption

With link-level encryption, packets are automatically encrypted when they are transmitted over an unsecure data link and decrypted when they are received. Eavesdropping is defeated because an eavesdropper does not know how to decrypt packets that are intercepted. Link-level encryption is available on many radio-networking products, but is harder to find for other broadcast network technologies such as Ethernet or FDDI. Special link encryptors are available for modems and leased-line links.

241 Even with encryption, however, the source and destination addresses and ports of packets can be determined by an attacker and used for traffic analysis.

End-to-end encryption

With end-to-end encryption, the host transmitting the packet encrypts the packet's data; the packet's contents are automatically decrypted when they are received at the other end. Some organizations that have more than one physical location use encrypting routers for connecting to the Internet. These routers automatically encrypt packets that are sent from one corporate location to the other to prevent eavesdropping by attackers on the Internet (these are known as VPNs); however, the routers do not encrypt packets that are sent from the organization to third-party sites on the network.

Today, this kind of packet-level encryption is typically implemented using the IPsec protocol (described in RFC 2401). IPsec can be used to transparently encrypt all communications between two hosts, between a host and a network, or between two networks. Using IPsec is a powerful way to automatically add encryption to systems that otherwise do not provide it.

Application-level encryption

Instead of relying on hardware to encrypt data, encryption can be done at the application level. For example, the Kerberos version of the telnet command can automatically encrypt the contents of the telnet data stream in both directions. The Secure Shell protocol (ssh) automatically provides for encryption of the data stream.

Application-level encryption can also be provided by tunneling or wrapping an existing application-level protocol using a second protocol. For example, the Secure Shell protocol provides for TCP/IP ports and connections to be “forwarded” from one host to another over a cryptographically-protected tunnel. Individual application servers and clients can also be wrapped using the SSL and TLS protocols.

Simply using encryption is not enough: the encryption must be properly implemented for it to provide protection. As discussed above, WEP, the original encryption standard for 802.11b wireless LANs does not provide any true confidentiality at all: the encryption implementation is flawed, and it is trivial to determine the encryption keys used by WEP systems.

Advanced Authentication Systems

Most IP services do not provide a strong system for positive authentication. As a result, an attacker can transmit information and claim that it comes from another source. The lack of positive authentication presents problems, especially for services such as DNS, electronic mail, and Netnews (Usenet). In all of these services, the recipient of a message, be it a machine or a person, is likely to take positive action based on the content of a message, whether or not the message sender is properly authenticated.

Authentication systems have been developed for each of these services. DNS supports the cryptographic signing of zone data and authentication between nameservers using a shared secret key, mail servers can authenticate valid senders against a database using the SMTP AUTH extension, and Usenet messages can be cryptographically signed with PGP. However, adoption of these systems has not been widespread to date.

IPsec, discussed above, also provides for strong authentication between peers. IP traffic received over such a VPN is more likely to be from the source that it claims to be, but for most Internet services, VPNs will not be used.

ident

Many of the authentication problems arise because the TCP/IP protocol is a system for creating communication channels between computers, and not between users. When a server receives a TCP/IP connection from a client, it

knows the IP address of the client. However, the server has no way to readily ascertain the name of the person who initiated the TCP/IP connection.

When the TCP/IP protocol suite was developed, there was no need for a general-purpose approach for learning the names of people initiating TCP/IP connections. Protocols that required usernames (e.g., SMTP and FTP) provided them. As the Internet has grown, network managers have discovered a very important reason for knowing the name of a person initiating a TCP/IP connection: accountability. If a remote system administrator discovers that her computer was attacked at 5:00 p.m. by a user at a computer named fas.harvard.edu , it is important to be able to trace that attack back to the specific user and account that was responsible for the attack so that either the user can be punished or the compromised account can be terminated.

The identification protocol gives you a way of addressing this problem with a simple callback scheme. When a server wants to know the “real name” of a person initiating a TCP/IP connection, it simply opens a connection to the client machine's ident daemon (identd) and sends a description of the TCP/IP connection in progress; the remote machine sends a human-readable representation of the user who is initiating the connection.

Traditionally, the information sent back to the requesting system was the user's username. More recent implementations of the ident daemon provide for an encrypted token to be sent back; the token can later be decrypted by the remote site with the cooperation of the site running the ident daemon. This prevents identd lookups from being used to get username information on a remote host without its cooperation.

The identification protocol depends on the honesty of the computer that is originating the TCP/IP connection. If your system is under attack from a multiuser system that has not been otherwise compromised, identd may be valuable. On the other hand, if your system is under attack from a single-user computer that is not running identd or is running an identd that has been gimmicked to give untrue or misleading information, the response may be worthless. Because major IRC networks require clients to run an ident daemon, there are many free Windows-based ident daemons that return false responses.

In general, the responses of identd queries are more useful to the administrators of the site that sends the response than they are to the site that receives it. Thus, logging ident queries may not help you, but can be a courtesy to others—it lets the remote site know which account was involved in the attack. That's especially useful if the attacker went on to erase log files or otherwise damage the originating site.

Not surprisingly, identd has been most useful in tracking down attackers originating at universities and other organizations with large multiuser Unix systems. Sites that have nonprivileged interactive Unix users should run ident to help track down accounts that have been compromised during an incident.

SSH (Secure Shell)

Originally developed by Tatu Ylonen, SSH (the Secure Shell) is a cryptographically-enabled protocol for remote login, file copying, and TCP connection tunneling (also known as port forwarding by SSH users.) Although originally implemented solely by Tatu Ylonen’s ssh command-line Unix utility, today the SSH protocol is implemented by dozens of programs on many platforms. The two most popular implementations are Ylonen’s original SSH, and OpenSSH, developed by the Open-BSD Project. Commercial clients and servers are also available.

SSH has become a crucial piece of network security infrastructure because it can replace several protocols and programs that transmit plaintext passwords (including telnet, rlogin, rsh, rcp, rdist, and ftp). In addition, the TCP connection tunneling facility makes it possible to use SSH as the basis for a virtual private network. SSH has particular support for tunneling the X-Windows protocol.

There are two versions of the SSH protocol. Although both protocols allow the symmetric cipher to be negotiated, SSH Version 1 relies on the RSA public key encryption algorithm for authentication and initial key exchange. SSH Version 2 has extended the protocol by allowing both the RSA and the DSA public key encryption algorithms and has corrected several flaws in the SSH1 protocol. Version 2 is therefore recommended.

Host authentication with SSH

Every host that runs an SSH server is supposed to have its own unique RSA public and private key pair, called the SSH HostKey. Version 2 servers have a second key pair called the HostDSAKey that uses the DSA encryption algorithm. Most SSH startup scripts will automatically create this key the first time that the server is run if the key does not already exist.

When an SSH client connects to the server, the server provides its public key. This key serves two purposes. First, the client uses this key to encrypt information that is sent back to the server during the authentication phase. Second, the public key is used by the server to establish its identity. Each time a client connects to the server, the server provides the same public key to the client; the client is thus able to determine, each time it connects to the server, that it is communicating with the same server as it was on previous occasions.

The host key protects against two kinds of attacks. First, it assures that you are connecting to the correct host. If the host you intend to connect to has changed its IP address or has a new DNS name (or if somebody has attacked your DNS system and it is handing out the wrong IP addresses), the SSH client will note that the new host has a different HostKey from the older address and you will, presumably, not provide your password. Second, the HostKey assures that you will have an encrypted connection directly to the remote server, and that no intermediate machine is engaging in a man-in-the-middle attack. For a successful man-in-the-middle attack to take place, an attacker would need to provide his own public key—a public key to which he presumably had the matching private key. (An attacker mounting a man-in-the-middle attack would not provide the HostKey of the server under attack because if he did, he would be unable to decrypt the resulting communications.)

Unfortunately, HostKeys seem to change on a fairly regular basis — sometimes whenever a new operating system is installed, or when a new SSH installation inadvertently creates a new host key, rather than preserving the old one. Therefore, if the HostKey of a server that you communicate with changes, you shouldn’t assume that the server has been compromised or that a man-in-the-middle attack is taking place. But you might want to look into why the key was changed.

Client authentication with SSH

When a client connects to the SSH server, the client provides the username of the account that it wishes to use. It then provides a suitable authentication credential to prove that it is entitled to the account. If the server is satisfied by the client’s credentials, it starts up a copy of the user’s shell, and logs the user in.

SSH offers a variety of secure methods for authenticating clients to the server’s operating system:242

• Clients can provide a valid password for the account on the remote server. This password is not transmitted in plain text.

• Clients can prove their identities using public key cryptography, if the client presents a public key that is in the user’s authorized keys file and the client can decrypt information that is encrypted with that public key.

• Clients can authenticate using Kerberos, one-time passwords, or other challenge/response systems available on the server.

241 SSH also offers some less secure methods that are based on the client’s IP address and should generally be avoided.

TCP connection tunneling

SSH can tunnel a TCP connection between a second client and server. First, the ssh client is used to make a connection to the ssh server on the remote machine, and to request a tunnel to given other port on the remote machine. If the ssh client successfully authenticates and connects, it listens on a new port on the local machine; the ssh server initiates a connection to the second server on the remote machine. The second client is directed to connect to the new port on the local host, and data received on this new port is transmitted by ssh to the remote sshd server, which passes it on to the second remote server.

Some protocols cannot be protected with a simple TCP tunnel. FTP, for example, requires multiple tunnels (some of which are difficult to predict), and so most SSH distributions provide a substitute ftp client (often called sftp) that works as users expect an FTP program to, but uses an SSH connection. The X-Windows protocol presents some similar difficulties, but specific support for tunneling X-Windows connections is available in most SSH applications. Instead of running a remote X client on a local X server, SSH creates a tunnel and a virtual X display that the remote client can safely use to communicate with the local server via SSH.

Decoy Systems

A final approach to subverting attackers is to set up decoy systems for the attackers to attack. Decoy systems are closely monitored; often these systems are built with known vulnerabilities to increase their likelihood of attack. Decoy systems, sometimes called honeypots or honeynets have two primary advantages:

1. Because they are closely monitored, decoy systems can be used to learn about attackers. Decoy systems can reveal attacker locations, techniques, motivations, skill levels, objectives, and many other pieces of information.

2. If a decoy system is sufficiently rich and compelling, exploring that system might consume so much of the attacker's time that the attacker will not have the time to attack systems that you actually care about. For example, Brad Spencer has championed the use of honeypot open relays to monitor and distract e-mail spammers (for some details, see http://fightrelayspam.homestead.com/files/antispam06132002.htm).

Decoy systems are not without their risks. The first risk is that the attacker will find something of value in the system. You must make absolutely certain that there is nothing on the decoy system that an attacker could use to harm you. Specifically, the decoy system should contain no information about your organization. One way to accomplish this goal is to use only new computers for your decoy system, rather than computers repurposed from other projects. Furthermore, if your organization has a firewall, the decoy system should be outside the firewall.

A second risk of decoy systems is that they can become platforms for attacking other computers on the Internet— possibly making you liable for third-party civil damages or even for charges of criminal conspiracy!

For both of these reasons, you should think carefully—and possibly consult with an attorney—before setting up a decoy or honeypot system.