Inhaltsverzeichnis von Linux Network Administrator's Guide

Inhaltsvorschau

The idea of networking is probably as old as telecommunications itself. Consider people living in the Stone Age, when drums may have been used to transmit messages between individuals. Suppose caveman A wants to invite caveman B over for a game of hurling rocks at each other, but they live too far apart for B to hear A banging his drum. What are A's options? He could 1) walk over to B's place, 2) get a bigger drum, or 3) ask C, who lives halfway between them, to forward the message. The last option is called networking.

Of course, we have come a long way from the primitive pursuits and devices of our forebears. Nowadays, we have computers talk to each other over vast assemblages of wires, fiber optics, microwaves, and the like, to make an appointment for Saturday's soccer match. In the following description, we will deal with the means and ways by which this is accomplished, but leave out the wires, as well as the soccer part.

We define a network as a collection of hosts that are able to communicate with each other, often by relying on the services of a number of dedicated hosts that relay data between the participants. Hosts are often computers, but need not be; one can also think of X terminals or intelligent printers as hosts. A collection of hosts is also called a site.

Communication is impossible without some sort of language or code. In computer networks, these languages are collectively referred to as protocols. However, you shouldn't think of written protocols here, but rather of the highly formalized code of behavior observed when heads of state meet, for instance. In a very similar fashion, the protocols used in computer networks are nothing but very strict rules for the exchange of messages between two or more hosts.

Modern networking applications require a sophisticated approach to carry data from one machine to another. If you are managing a Linux machine that has many users, each of whom may wish to simultaneously connect to remote hosts on a network, you need a way of allowing them to share your network connection without interfering with each other. The approach that a large number of modern networking protocols use is called

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The idea of networking is probably as old as telecommunications itself. Consider people living in the Stone Age, when drums may have been used to transmit messages between individuals. Suppose caveman A wants to invite caveman B over for a game of hurling rocks at each other, but they live too far apart for B to hear A banging his drum. What are A's options? He could 1) walk over to B's place, 2) get a bigger drum, or 3) ask C, who lives halfway between them, to forward the message. The last option is called networking.

Of course, we have come a long way from the primitive pursuits and devices of our forebears. Nowadays, we have computers talk to each other over vast assemblages of wires, fiber optics, microwaves, and the like, to make an appointment for Saturday's soccer match. In the following description, we will deal with the means and ways by which this is accomplished, but leave out the wires, as well as the soccer part.

We define a network as a collection of hosts that are able to communicate with each other, often by relying on the services of a number of dedicated hosts that relay data between the participants. Hosts are often computers, but need not be; one can also think of X terminals or intelligent printers as hosts. A collection of hosts is also called a site.

Communication is impossible without some sort of language or code. In computer networks, these languages are collectively referred to as protocols. However, you shouldn't think of written protocols here, but rather of the highly formalized code of behavior observed when heads of state meet, for instance. In a very similar fashion, the protocols used in computer networks are nothing but very strict rules for the exchange of messages between two or more hosts.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Modern networking applications require a sophisticated approach to carry data from one machine to another. If you are managing a Linux machine that has many users, each of whom may wish to simultaneously connect to remote hosts on a network, you need a way of allowing them to share your network connection without interfering with each other. The approach that a large number of modern networking protocols use is called packet switching. A packet is a small chunk of data that is transferred from one machine to another across the network. The switching occurs as the datagram is carried across each link in the network. A packet-switched network shares a single network link among many users by alternately sending packets from one user to another across that link.

The solution that Unix systems, and subsequently many non-Unix systems, have adopted is known as TCP/IP. When learning about TCP/IP networks, you will hear the term datagram, which technically has a special meaning but is often used interchangeably with packet. In this section, we will have a look at underlying concepts of the TCP/IP protocols.

TCP/IP traces its origins to a research project funded by the United States Defense Advanced Research Projects Agency (DARPA) in 1969. The ARPANET was an experimental network that was converted into an operational one in 1975 after it had proven to be a success.

In 1983, the new protocol suite TCP/IP was adopted as a standard, and all hosts on the network were required to use it. When ARPANET finally grew into the Internet (with ARPANET itself passing out of existence in 1990), the use of TCP/IP had spread to networks beyond the Internet itself. Many companies have now built corporate TCP/IP networks, and the Internet has become a mainstream consumer technology. It is difficult to read a newspaper or magazine now without seeing references to the Internet; almost everyone can use it now.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

As it is the result of a concerted effort of programmers around the world, Linux wouldn't have been possible without the global network. So it's not surprising that in the early stages of development, several people started to work on providing it with network capabilities. A UUCP implementation was running on Linux almost from the very beginning, and work on TCP/IP-based networking started around autumn 1992, when Ross Biro and others created what has now become known as Net-1.

After Ross quit active development in May 1993, Fred van Kempen began to work on a new implementation, rewriting major parts of the code. This project was known as Net-2. The first public release, Net-2d, was made in the summer of 1993 (as part of the 0.99.10 kernel), and has since been maintained and expanded by several people, most notably Alan Cox. Alan's original work was known as Net-2Debugged. After heavy debugging and numerous improvements to the code, he changed its name to Net-3 after Linux 1.0 was released. The Net-3 code was further developed for Linux 1.2 and Linux 2.0. The 2.2 and later kernels use the Net-4 version network support, which remains the standard official offering today.

The Net-4 Linux Network code offers a wide variety of device drivers and advanced features. Standard Net-4 protocols include SLIP and PPP (for sending network traffic over serial lines), PLIP (for parallel lines), IPX (for Novell compatible networks), Appletalk (for Apple networks) and AX.25, NetRom, and Rose (for amateur radio networks). Other standard Net-4 features include IP firewalling (discussed in Chapter 7), IP accounting (Chapter 8), and IP Masquerade (Chapter 9). IP tunneling in a couple of different flavors and advanced policy routing are supported. A very large variety of Ethernet devices are supported, in addition to support for some FDDI, Token Ring, Frame Relay, and ISDN, and ATM cards.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Throughout this book, we will mainly deal with installation and configuration issues. Administration is, however, much more than that—after setting up a service, you have to keep it running, too. For most services, only a little attendance will be necessary, while some, such as mail, require that you perform routine tasks to keep your system up to date. We will discuss these tasks in later chapters.

The absolute minimum in maintenance is to check system and per-application logfiles regularly for error conditions and unusual events. Often, you will want to do this by writing a couple of administrative shell scripts and periodically running them from cron. The source distributions of some major applications contain such scripts. You only have to tailor them to suit your needs and preferences.

The output from any of your cron jobs should be mailed to an administrative account. By default, many applications will send error reports, usage statistics, or logfile summaries to the root account. This makes sense only if you log in as root frequently; a much better idea is to forward root's mail to your personal account by setting up a mail alias as described in Chapters Chapter 11 and Chapter 12.

However carefully you have configured your site, Murphy's Law guarantees that some problem will surface eventually. Therefore, maintaining a system also means being available for complaints. Usually, people expect that the system administrator can at least be reached via email as root, but there are also other addresses that are commonly used to reach the person responsible for a specific aspect of maintenence. For instance, complaints about a malfunctioning mail configuration will usually be addressed to postmaster, and problems with the news system may be reported to newsmaster or usenet. Mail to hostmaster should be redirected to the person in charge of the host's basic network services, and the DNS name service if you run a nameserver.

Another very important aspect of system administration in a network environment is protecting your system and users from intruders. Carelessly managed systems offer malicious people many targets. Attacks range from password guessing to Ethernet snooping, and the damage caused may range from faked mail messages to data loss or violation of your users' privacy. We will mention some particular problems when discussing the context in which they may occur and some common defenses against them.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In this chapter we turn to the configuration decisions that you'll need to make when connecting your Linux machine to a TCP/IP network, including dealing with IP addresses, hostnames, and routing issues. This chapter gives you the background you need in order to understand what your setup requires, while the next chapters cover the tools that you will use.

To learn more about TCP/IP and the reasons behind it, refer to the three-volume set Internetworking with TCP/IP (Prentice Hall) by Douglas R. Comer. For a more detailed guide to managing a TCP/IP network, see TCP/IP Network Administration (O'Reilly) by Craig Hunt.

To hide the diversity of equipment that may be used in a networking environment, TCP/IP defines an abstract interface through which the hardware is accessed. This interface offers a set of operations that is the same for all types of hardware and basically deals with sending and receiving packets.

For each peripheral networking device, a corresponding interface has to be present in the kernel. For example, Ethernet interfaces in Linux are called by such names as eth0 and eth1; PPP (discussed in Chapter 6) interfaces are named ppp0 and ppp1; and FDDI interfaces are given names such as fddi0 and fddi1. These interface names are used for configuration purposes when you want to specify a particular physical device in a configuration command, and they have no meaning beyond this use.

Before being used by TCP/IP networking, an interface must be assigned an IP address that serves as its identification when communicating with the rest of the world. This address is different from the interface name mentioned previously; if you compare an interface to a door, the address is like the nameplate pinned on it.

Other device parameters may be set, such as the maximum size of datagrams that can be processed by a particular piece of hardware, which is referred to as

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

To hide the diversity of equipment that may be used in a networking environment, TCP/IP defines an abstract interface through which the hardware is accessed. This interface offers a set of operations that is the same for all types of hardware and basically deals with sending and receiving packets.

For each peripheral networking device, a corresponding interface has to be present in the kernel. For example, Ethernet interfaces in Linux are called by such names as eth0 and eth1; PPP (discussed in Chapter 6) interfaces are named ppp0 and ppp1; and FDDI interfaces are given names such as fddi0 and fddi1. These interface names are used for configuration purposes when you want to specify a particular physical device in a configuration command, and they have no meaning beyond this use.

Before being used by TCP/IP networking, an interface must be assigned an IP address that serves as its identification when communicating with the rest of the world. This address is different from the interface name mentioned previously; if you compare an interface to a door, the address is like the nameplate pinned on it.

Other device parameters may be set, such as the maximum size of datagrams that can be processed by a particular piece of hardware, which is referred to as Maximum Transfer Unit (MTU). Other attributes will be introduced later. Fortunately, most attributes have sensible defaults.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

As mentioned in Chapter 1, the IP networking protocol understands addresses as 32-bit numbers. Each machine must be assigned a number unique to the networking environment. If you are running a local network that does not have TCP/IP traffic with other networks, you may assign these numbers according to your personal preferences. There are some IP address ranges that have been reserved for such private networks. These ranges are listed in Table 2-1. However, for sites on the Internet, numbers are assigned by a central authority, the Network Information Center (NIC).

IP addresses are split up into four 8-bit numbers called octets for readability. For example, quark.physics.groucho.edu has an IP address of 0x954C0C04, which is written as 149.76.12.4. This format is often referred to as dotted quad notation.

Another reason for this notation is that IP addresses are split into a network number, which is contained in the leading octets, and a host number, which is the remainder. When applying to the NIC for IP addresses, you are not assigned an address for each single host you plan to use. Instead, you are given a network number and allowed to assign all valid IP addresses within this range to hosts on your network according to your preferences.

The size of the host partly depends on the size of the network. To accommodate different needs, several classes of networks have been defined, with different places to split IP addresses. The class networks are described here:

Class A: Class A comprises networks 1.0.0.0 through 127.0.0.0. The network number is contained in the first octet. This class provides for a 24-bit host part, allowing roughly 1.6 million hosts per network.
Class B

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

IP has a companion protocol that we haven't talked about yet. This is the Internet Control Message Protocol (ICMP), used by the kernel networking code to communicate error messages to other hosts. For instance, assume that you are on erdos again and want to telnet to port 12345 on quark, but there's no process listening on that port. When the first TCP packet for this port arrives on quark, the networking layer will recognize this arrival and immediately return an ICMP message to erdos stating "Port Unreachable."

The ICMP protocol provides several different messages, many of which deal with error conditions. However, there is one very interesting message called the Redirect message. It is generated by the routing module when it detects that another host is using it as a gateway, even though a much shorter route exists. For example, after booting, the routing table of sophus may be incomplete. It might contain the routes to the math department's network, to the FDDI backbone, and the default route pointing at the Groucho Computing Center's gateway (gcc1). Thus, packets for quark would be sent to gcc1 rather than to niels, the gateway to the physics department. When receiving such a datagram, gcc1 will notice that this is a poor choice of route and will forward the packet to niels, meanwhile returning an ICMP Redirect message to sophus telling it of the superior route.

This seems to be a very clever way to avoid manually setting up any but the most basic routes. However, be warned that relying on dynamic routing schemes, be it RIP or ICMP Redirect messages, is not always a good idea. ICMP Redirect and RIP offer you little or no choice in verifying that some routing information is indeed authentic. This situation allows malicious good-for-nothings to disrupt your entire network traffic, or even worse. Consequently, the Linux networking code treats Network Redirect messages as if they were Host Redirects. This minimizes the damage of an attack by restricting it to just one host, rather than the whole network. On the flip side, it means that a little more traffic is generated in the event of a legitimate condition, as each host causes the generation of an ICMP Redirect message. It is generally considered bad practice to rely on ICMP redirects for anything these days.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The Internet is growing at an incredible rate. Much of this growth is attributed to Internet users who have cheap and easy access to DSL, cable, and other high-speed permanent network connections and who use protocols such as PPP to dial in to a network provider to retrieve their daily dose of email and news.

This chapter is intended to help all people who rely on modems to maintain their link to the outside world. We won't cover the mechanics of how to configure your modem, as you can find detailed documentation of this in many of the available modem HOWTO documents on the web. We will cover most of the Linux-specific aspects of managing devices that use serial ports. Topics include serial communications software, creating the serial device files, serial hardware, and configuring serial devices using the setseria _l and stty commands. Many other related topics are covered in the Serial HOWTO by David Lawyer.

There are a number of communications packages available for Linux. Many of these packages are terminal programs, which allow a user to dial in to another computer as if she were sitting in front of a simple terminal. The traditional terminal program for Unix-like environments is kermit. It is, however, ancient now, and would probably be considered difficult to use. There are more comfortable programs available that support features such as telephone-dialing dictionaries, script languages to automate dialing and logging in to remote computer systems, and a variety of file exchange protocols. One of these programs is minicom, which was modeled after some of the most popular DOS terminal programs. X11 users are accommodated, too. seyon is a fully featured X11-based communications program.

Terminal programs aren't the only type of serial communication programs available. Other programs let you connect to a host and download email in a single bundle, to read and reply to later at your leisure. This can save a lot of time and is especially useful if you are unfortunate enough to live in an area where your connectivity is time charged. All of the reading and replying time can be spent offline, and when you are ready, you can reconnect and upload your responses in a single bundle.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

There are a number of communications packages available for Linux. Many of these packages are terminal programs, which allow a user to dial in to another computer as if she were sitting in front of a simple terminal. The traditional terminal program for Unix-like environments is kermit. It is, however, ancient now, and would probably be considered difficult to use. There are more comfortable programs available that support features such as telephone-dialing dictionaries, script languages to automate dialing and logging in to remote computer systems, and a variety of file exchange protocols. One of these programs is minicom, which was modeled after some of the most popular DOS terminal programs. X11 users are accommodated, too. seyon is a fully featured X11-based communications program.

Terminal programs aren't the only type of serial communication programs available. Other programs let you connect to a host and download email in a single bundle, to read and reply to later at your leisure. This can save a lot of time and is especially useful if you are unfortunate enough to live in an area where your connectivity is time charged. All of the reading and replying time can be spent offline, and when you are ready, you can reconnect and upload your responses in a single bundle.

PPP is in-between, allowing both interactive and noninteractive use. Many people use PPP to dial in to their campus network or other Internet Service Provider to access the Internet. PPP (in the form of PPPoE) is also, however, commonly used over permanent or semipermanent connections like cable or DSL modems. We'll discuss PPPoE in Chapter 7.

The Unix kernel provides devices for accessing serial hardware, typically called tty devices (pronounced as it is spelled: T-T-Y).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Like all devices in a Unix system, serial ports are accessed through device special files, located in the /dev directory. There are two varieties of device files related to serial drivers, and there is one device file of each type for each port. The device will behave slightly differently, depending on which of its device files we open. We'll cover the differences because it will help you understand some of the configurations and advice that you might see relating to serial devices, but in practice you need to use only one of these. At some point in the future, one of them may even disappear completely.

The most important of the two classes of serial device has a major number of 4, and its device special files are named ttyS0, ttyS1, etc. The second variety has a major number of 5 and was designed for use when dialing out (calling out) through a port; its device special files are called cua0, cua1, etc. In the Unix world, counting generally starts at zero, while laypeople tend to start at one. This creates a small amount of confusion for people because COM1: is represented by /dev/ttyS0, COM2: by /dev/ttyS1, etc. Anyone familiar with IBM PC-style hardware knows that COM3: and greater were never really standardized anyway.

The cua, or "callout," devices were created to solve the problem of avoiding conflicts on serial devices for modems that have to support both incoming and outgoing connections. Unfortunately, they've created their own problems and are now likely to be discontinued. Let's briefly look at the problem.

Linux, like Unix, allows a device, or any other file, to be opened by more than one process simultaneously. Unfortunately, this is rarely useful with tty devices, as the two processes will almost certainly interfere with each other. Luckily, a mechanism was devised to allow a process to check if a tty device had already been opened by another device. The mechanism uses what are called lock

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Now let's spend some time looking at the two most useful serial device configuration utilities: setserial and stty.

The kernel will make its best effort to correctly determine how your serial hardware is configured, but the variations on serial device configuration makes this determination difficult to achieve 100 percent reliably in practice. A good example of where this is a problem is the internal modems we talked about earlier. The UART they use has a 16-byte FIFO buffer, but it looks like a 16450 UART to the kernel device driver: unless we specifically tell the driver that this port is a 16550 device, the kernel will not make use of the extended buffer. Yet another example is that of the dumb 4-port cards that allow sharing of a single IRQ among a number of serial devices. We may have to specifically tell the kernel which IRQ port it's supposed to use, and that IRQs may be shared.

setserial was created to configure the serial driver at runtime. The setserial command is most commonly executed at boot time from a script called rc.serial on some distributions, though yours may very. This script is charged with the responsibility of initializing the serial driver to accommodate any nonstandard or unusual serial hardware in the machine.

The general syntax for the setserial command is:

setserial device [parameters]

in which the device is one of the serial devices, such as ttyS0.

The setserial command has a large number of parameters. The most common of these are described in Table 3-1. For information on the remainder of the parameters, you should refer to the setserial manpage.

Table 3-1: setserial command-line parameters
Parameter

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

It was once very common that a Unix installation involved one server machine and many "dumb" character mode terminals or dial-up modems. Today that sort of installation is less common, which is good news for many people interested in operating this way, because the "dumb" terminals are now very cheap to acquire. Dial-up modem configurations are no less common, but these days they would probably be used to support a PPP login (discussed in Chapter 6) rather than a simple login. Nevertheless, each of these configurations can make use of a simple program called a getty program.

The term getty is probably a contraction of "get tty." A getty program opens a serial device, configures it appropriately, optionally configures a modem, and waits for a connection to be made. An active connection on a serial device is usually indicated by the Data Carrier Detect (DCD) pin on the serial device being raised. When a connection is detected, the getty program issues a login: prompt, and then invokes the login program to handle the actual system login. Each of the virtual terminals (e.g., /dev/tty1) in Linux has a getty running against it.

There are a number of different getty implementations, each designed to suit some configurations better than others. The getty that we'll describe here is called mgetty, which is quite popular because it has all sorts of features that make it especially modem-friendly, including support for automatic fax programs and voice modems. We'll concentrate on configuring mgetty to answer conventional data calls and leave the rest for you to explore at your convenience.

The mgetty daemon is available in just about all Linux distributions in prepackaged form. The mgetty daemon differs from most other getty implementations in that it has been designed specifically for modems with the AT command set.

It still supports direct terminal connections but is best suited for dialup applications. Rather than using the DCD line to detect an incoming call, it listens for the

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In this chapter, we walk you through all the necessary steps to set up TCP/IP networking on your machine. Starting with the assignment of IP addresses, we slowly work our way through the configuration of TCP/IP network interfaces and introduce a few tools that come in handy when hunting down network installation problems.

Most of the tasks covered in this chapter will generally have to be done only once. Afterward, you have to touch most configuration files only when adding a new system to your network or reconfiguring your system entirely. Some of the commands used to configure TCP/IP, however, have to be executed each time the system is booted. This is usually done by invoking them from the system /etc/rc scripts.

Commonly, the network-specific part of this procedure is contained in a script. The name of this script varies in different Linux distributions. In many older Linux distributions, it is known as rc.net or rc.inet. Sometimes you will also see two scripts named rc.inet1 and rc.inet2; the former initializes the kernel part of networking and the latter starts basic networking services and applications. In modern distributions, the rc files are structured in a more sophisticated arrangement; here you may find scripts in the /etc/init.d/ (or /etc/rc.d/init.d/) directory that create the network devices and other rc files that run the network application programs. This book's examples are based on the latter arrangement.

This chapter discusses parts of the script that configure your network interfaces. After finishing this chapter, you should have established a sequence of commands that properly configure TCP/IP networking on your computer. You should then replace any sample commands in the configuration scripts with your commands, make sure the script is executed from the basic rc script at startup time, and reboot your machine. The networking rc scripts that come along with your favorite Linux distribution should provide a solid example from which to work.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Linux 2.4 distributions rely on the /proc filesystem for communicating with the kernel, 2.6 uses the new sysfs. Both interfaces permit access to kernel runtime information through a filesystem-like mechanism. For purposes of this chapter, we'll focus more on the /proc filesystem, as it is currently more widely used. This filesystem, when mounted, can list files like any other filesystem, or display their contents. Typical items include the loadavg file, which contains the system load average, and meminfo, which shows current core memory and swap usage.

To this, the networking code adds the net directory. It contains a number of files that show things such as the kernel ARP tables, the state of TCP connections, and the routing tables. Most network administration tools get their information from these files.

The proc filesystem (or procfs, as it is also known) is usually mounted on /proc at system boot time. The best method is to add the following line to /etc/fstab:

# procfs mount point:

none  /proc  proc defaults

Then execute mount /proc from your /etc/rc script.

The procfs is now configured into most kernels by default.

Prepackaged Linux distributions contain the major networking applications and utilities along with a coherent set of sample files. The only case in which you might have to obtain and install new utilities is when you install a new kernel release. Because they occasionally involve changes in the kernel networking layer, you will need to update the basic configuration tools. This update at least involves recompiling, but sometimes you may also be required to obtain the latest set of binaries. These binaries are available at their official home site at ftp://ftp.inka.de/pub/comp/Linux/networking/NetTools/, packaged in an archive called net-tools-XXX.tar.gz, where XXX is the version number.

If you want to compile and install the standard TCP/IP network applications yourself, you can obtain the sources from most Linux FTP servers. All modern Linux distributions include a fairly comprehensive range of TCP/IP network applications, such as World Wide Web browsers, Telnet and FTP programs, and other network applications such as talk. If you do find something that you need to compile yourself, the chances are good that it will compile under Linux from source quite easily if you follow the instructions included in the source package.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

As we discussed in Chapter 2, TCP/IP networking may rely on different schemes to convert names into addresses. The simplest way is to use a host table stored in /etc/hosts. This is useful only for a small LAN that is run by a single administrator and no IP traffic with the outside world. The format of the hosts file has already been described in Chapter 4.

While a hosts file approach may be appropriate on a small network, most administrators will need to investigate a DNS server. There are multiple services that you can use to resolve IP addresses. The most commonly used is the Berkeley Internet Name Domain service (BIND) Version 8.x. BIND v9.x has been available for some time now and seeks to add a variety of new features, as well as contend with security issues in BIND v8.x. The jump from BIND 8 to BIND 9 isn't quite as significant as was the leap from BIND 4 to 8; many of the configuration files and options are the same. Configuring BIND can be a real chore, but once you've done it, you can easily make changes in the network topology. On Linux, as on many other Unix-ish systems, BIND service is provided through a program called named. At startup, it loads a set of master files into its internal cache and waits for queries from remote or local user processes. There are different ways to set up BIND, and not all require you to run a nameserver on every host.

We will also discuss a simpler and more secure option, djbdns, written by David J. Bernstein. This resolver was written from scratch with security in mind and simplifies server setup in a number of ways, primarily by eliminating the need for multiple confusing zone files.

This chapter can do little more than give a rough sketch of how DNS works and how to operate a nameserver. It should be sufficient for readers with a small LAN and an Internet connection. For the most current information, you may want to check the documentation contained in the BIND or djbdns source packages, which supply manual pages, release notes, and in the BIND package, the

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The term resolver refers not to a special application, but to the resolver library. This is a collection of functions that can be found in the standard C library and are invoked by a wide range of networking applications. The central routines are gethostbyname(2) and gethostbyaddr(2), which look up all IP addresses associated with a hostname, and vice versa. They may be configured to simply look up the information in hosts, or to query a number of DNS nameservers.

The resolver functions read configuration files when they are invoked. From these configuration files, they determine what databases to query, in which order, and other details relevant to how you've configured your environment. The older Linux standard library, libc, used /etc/host.conf as its master configuration file, but since Version 2 of the GNU standard library, glibc, uses /etc/nsswitch.conf.

The nsswitch.conf file allows the system administrator to configure a wide variety of different databases. We'll limit our discussion to options that relate to host and network IP address resolution. You can easily find more information about the other features by reading the GNU standard library documentation.

Options in nsswitch.conf must appear on separate lines. Fields may be separated by whitespace (spaces or tabs). A hash sign (#) introduces a comment that extends to the next newline. Each line describes a particular service; hostname resolution is one of these. The first field in each line is the name of the database, ending with a colon. The database name associated with host address resolution is hosts. A related database is networks, which is used for resolution of network names into network addresses. The remainder of each line stores options that determine the way lookups for that database are performed.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

DNS organizes hostnames in a domain hierarchy. A domain is a collection of sites that are related in some sense—because they form a proper network (e.g., all machines on a campus), because they all belong to a certain organization (e.g., the U.S. government), or because they're simply geographically close. For instance, universities are commonly grouped in the edu domain, with each university or college using a separate subdomain, below which their hosts are subsumed. Groucho Marx University the groucho.edu domain, while the LAN of the mathematics department is assigned maths.groucho.edu. Hosts on the departmental network would have this domain name tacked onto their hostname, so erdos would be known as erdos.maths.groucho.edu, which would be the FQDN (see Section 4.1.2 in Chapter 4).

Figure 5-1 shows a section of the namespace. The entry at the root of this tree, which is denoted by a single dot, is quite appropriately called the root domain and encompasses all other domains. To indicate that a hostname is a FQDN, rather than a name relative to some (implicit) local domain, it is sometimes written with a trailing dot. This dot signifies that the name's last component is the root domain. Depending on its location in the name hierarchy, a domain may be called top-level, second-level, or third-level. More levels of subdivision occur, but they are rare. Table 5-1 lists several top-level domains that you may see frequently.

Figure 5-1: A part of the domain namespace

Table 5-1: Common top-level domains
Domain	Description
edu

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Those who have been concerned with the number of security vulnerabilities found in the BIND server through the years, or who prefer an easier DNS solution, may wish to investigate an alternative, djbdns. This software, written from scratch by D.J. Bernstein, provides a much more robust, simplified and secure framework for DNS. djbdns is easy to install and configure, and is much less complex than BIND, essentially the same functionality. In this next section, we'll cover the basics of installing and configuring a DNS server using djbdns. It is important to note that a djbdns DNS server is designed to be just that, a DNS server, meaning that by default it won't be resolving queries for machines outside of your authority. For that, you will need to build a separate caching server on a separate machine or IP address. As recommended earlier, caches and DNS servers should be separated for security reasons. To read more about this topic, please refer to the djbdns web site at http://cr.yp.to/djbdns.html.

To run djbdns, you first need to install another DJB program called daemontools, which is basically a collection of tools used to manage various Unix daemons. To view full documentation and source code for daemontools, visit its webpage at http://cr.yp.to/daemontools.html. When you've successfully downloaded the software, extract it to a directory on your machine and compile the software. daemontools comes with a script that will automatically compile and install the software. It can be launched as follows:

vlager# mkdir software

vlager# cd software

vlager# tar xzpf daemontools-0.76.tar.gz

vlager# cd admin/daemontools-0.76

vlager# package/install

When the script finishes, you can remove the installation directories, and begin installing the next dependency, ucspi-tcp, which is DJB's very own TCP client-server handling program. It is also very easy to install:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Point-to-point protocol (PPP) is a protocol used to send datagrams across a serial connection. In this chapter, we briefly cover its basic building blocks. We will also cover PPP over Ethernet (PPPoE), which is now commonly used by telecom providers to establish DSL sessions. There is also a comprehensive O'Reilly book on the topic, Using & Managing PPP, by Andrew Sun.

At the very bottom of PPP is the High-Level Data Link Control (HDLC) protocol, which defines the boundaries around the individual PPP frames and provides a 16-bit checksum. A PPP frame is capable of holding packets from protocols other than IP, such as Novell's IPX or Appletalk. PPP achieves this by adding a protocol field to the basic HDLC frame that identifies the type of packet carried by the frame.

The Link Control Protocol (LCP) is used on top of HDLC to negotiate options pertaining to the data link. For instance, the Maximum Receive Unit (MRU) states the maximum datagram size that one side of the link agrees to receive.

An important step at the configuration stage of a PPP link is client authorization. Although it is not mandatory, it is really a must for dial-up lines in order to keep out intruders. Usually the called host (the server) asks the client to authorize itself by proving it knows some secret key. If the caller fails to produce the correct secret, the connection is terminated. With PPP, authorization works both ways; the caller may also ask the server to authenticate itself. These authentication procedures are totally independent of each other. There are two protocols for different types of authorization, which we will discuss further in this chapter: Password Authentication Protocol (PAP) and Challenge Handshake

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

On Linux, PPP functionality is split into two parts: a kernel component that handles the low-level protocols (HDLC, IPCP, IPXCP, etc.) and the user space pppd daemon that handles the various higher-level protocols, such as PAP and CHAP. The current release of the PPP software for Linux contains the PPP daemon pppd and a program named chat that automates the dialing of the remote system.

The PPP kernel driver was written by Michael Callahan and reworked by Paul Mackerras. pppd was derived from a free PPP implementation for Sun and 386BSD machines that was written by Drew Perkins and others, and is maintained by Paul Mackerras. It was ported to Linux by Al Longyear. chat was written by Karl Fox.

PPP is implemented by a special line discipline. To use a serial line as a PPP link, you first establish the connection over your modem as usual and subsequently convert the line to PPP mode. In this mode, all incoming data is passed to the PPP driver, which checks the incoming HDLC frames for validity (each HDLC frame carries a 16-bit checksum), and unwraps and dispatches them. Currently, PPP is able to transport both the IP protocol, optionally using Van Jacobson header compression, and the IPX protocol.

pppd aids the kernel driver, performing the initialization and authentication phase that is necessary before actual network traffic can be sent across the link. pppd's behavior may be fine-tuned using a number of options. As PPP is rather complex, it is impossible to explain all of them in a single chapter. This book therefore cannot cover all aspects of pppd, but only gives you an introduction. For more information, consult Using & Managing PPP or the pppd manpages, or READMEs in the pppd source distribution, which should help you sort out most questions this chapter fails to discuss. The PPP HOWTO

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

When you want to connect to the Internet through a PPP link, you have to set up basic networking capabilities, such as the loopback device and the resolver. Both have been covered in Chapter 4 and Chapter 5. You can simply configure the nameserver of your Internet Service Provider in the /etc/resolv.conf file, but this will mean that every DNS request is sent across your serial link. This situation is not optimal; the closer (network-wise) you are to your nameserver, the faster the name lookups will be. An alternative solution is to configure a caching-only nameserver at a host on your network. This means that the first time you make a DNS query for a particular host, your request will be sent across your serial link, but every subsequent request will be answered directly by your local nameserver, and will be much faster. This configuration is described in Chapter 5.

As an introductory example of how to establish a PPP connection with pppd, assume you are at vlager again. First, dial in to the PPP server c3po and log in to the ppp account. c3po will execute its PPP driver. After exiting the communications program you used for dialing, execute the following command, substituting the name of the serial device you used for the ttyS3 shown here:

# pppd 

            /dev/ttyS3 

            38400 

            crtscts 

            defaultroute

This command flips the serial line ttyS3 to the PPP line discipline and negotiates an IP link with c3po. The transfer speed used on the serial port will be 38,400 bps. The crtscts option turns on hardware handshake on the port, which is an absolute must at speeds above 9,600 bps.

The first thing pppd does after starting up is negotiate several link characteristics with the remote end using LCP. Usually, the default set of options pppd tries to negotiate will work, so we won't go into this here, except to say that part of this negotiation involves requesting or assigning the IP addresses at each end of the link.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Before pppd parses its command-line arguments, it scans several files for default options. These files may contain any valid command-line arguments spread out across an arbitrary number of lines. Hash signs introduce comments.

The first options file is /etc/ppp/options, which is always scanned when pppd starts up. Using it to set some global defaults is a good idea, because it allows you to keep your users from doing several things that may compromise security. For instance, to make pppd require some kind of authentication (either PAP or CHAP) from the peer, you add the auth option to this file. This option cannot be overridden by the user, so it becomes impossible to establish a PPP connection with any system that is not in your authentication databases. Note, however, that some options can be overridden; the connect string is a good example.

The other options file, which is read after /etc/ppp/options, is .ppprc in the user's home directory. It allows each user to specify her own set of default options.

A sample /etc/ppp/options file might look like this:

# Global options for pppd running on vlager.vbrew.com

lock                 # use UUCP-style device locking

auth                 # require authentication

usehostname          # use local hostname for CHAP

domain vbrew.com     # our domain name

The lock keyword makes pppd comply to the standard UUCP method of device locking. With this convention, each process that accesses a serial device, say /dev/ttyS3, creates a lock file with a name such as LCK..ttyS3 in a special lock-file directory to signal that the device is in use. This is necessary to prevent other programs, such as minicom or uucico, from opening the serial device while it is used by PPP.

The next three options relate to authentication and, therefore, to system security. The authentication options are best placed in the global configuration file because they are "privileged" and cannot be overridden by users'

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

One of the things that may have struck you as inconvenient in the previous example is that you had to establish the connection manually before you could fire up pppd. pppd relies on an external program or shell script to log in and connect to the remote system. The command to be executed can be given to pppd with the connect command-line option. pppd will redirect the command's standard input and output to the serial line.

The pppd software package is supplied with a very simple program called chat, which is capable of being used in this way to automate simple login sequences. We'll talk about this command in some detail.

If your login sequence is complex, you will need something more powerful than chat. One useful alternative you might consider is expect, written by Don Libes. It has a very powerful language based on Tcl and was designed exactly for this sort of application. Those of you whose login sequence requires, for example, challenge/response authentication involving calculator-like key generators will find expect powerful enough to handle the task. Since there are so many possible variations on this theme, we won't describe how to develop an appropriate expect script in this book. Suffice it to say, you'd call your expect script by specifying its name using the pppd connect option. It's also important to note that when the script is running, the standard input and output will be attached to the modem, not to the terminal that invoked pppd. If you require user interaction, you should manage it by opening a spare virtual terminal, or arrange some other means.

The chat command lets you specify a chat script. Basically, a chat script consists of an alternating sequence of strings that we expect to receive from the remote system, and the answers we are to send. We will call them expect and send strings, respectively. This is a typical excerpt from a chat script:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

IPCP is used to negotiate a number of IP parameters at link configuration time. Usually, each peer sends an IPCP configuration request packet, indicating which values it wants to change from the defaults and the new value. Upon receipt, the remote end inspects each option in turn and either acknowledges or rejects it.

pppd gives you a lot of control over which IPCP options it will try to negotiate. You can tune it through various command-line options that we will discuss in this section.

All IP interfaces require that IP addresses be assigned to them; a PPP device always has an IP address. The PPP suite of protocols provides a mechanism that allows the automatic assignment of IP addresses to PPP interfaces. It is possible for the PPP program at one end of a point-to-point link to assign an IP address for the remote end to use, or each may use its own.

Some PPP servers that handle a lot of client sites assign addresses dynamically; addresses are assigned to systems only when calling in and are reclaimed after they have logged off again. This allows the number of IP addresses required to be limited to the number of dial-up lines. While limitation is convenient for managers of the PPP dial-up server, it is often less convenient for users who are dialing in. We discussed the way that hostnames are mapped to IP addresses by use of a database in Chapter 5. In order for people to connect to your host, they must know your IP address or the hostname associated with it. If you are a user of a PPP service that assigns you an IP address dynamically, this knowledge is difficult without providing some means of allowing the DNS database to be updated after you are assigned an IP address. Such systems do exist, but we won't cover them in detail here; instead, we will look at the preferable approach, which involves you being able to use the same IP address each time you establish a network connection.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We already encountered LCP, which is used to negotiate link characteristics and test the link.

The two most important options negotiated by LCP are the Asynchronous Control Character Map and the Maximum Receive Unit. There are a number of other LCP configuration options, but they are far too specialized to discuss here.

The Asynchronous Control Character Map, colloquially called the async map, is used on asynchronous links, such as telephone lines, to identify control characters that must be escaped (replaced by a specific two-character sequence) to avoid them being interpreted by equipment used to establish the link. For instance, you may want to avoid the XON and XOFF characters used for software handshake because a misconfigured modem might choke upon receipt of an XOFF. Other candidates include Ctrl-l (the telnet escape character). PPP allows you to escape any of the characters with ASCII codes 0 through 31 by specifying them in the async map.

The async map is a 32-bit-wide bitmap expressed in hexadecimal. The least significant bit corresponds to the ASCII NULL character, and the most significant bit corresponds to ASCII 31 decimal. These 32 ASCII characters are the control characters. If a bit is set in the bitmap, it signals that the corresponding character must be escaped before it is transmitted across the link.

To tell your peer that it doesn't have to escape all control characters, but only a few of them, you can specify an async map to pppd using the asyncmap option. For example, if only ^S and ^Q (ASCII 17 and 19, commonly used for XON and XOFF) must be escaped, use the following option:

asyncmap 0x000A0000

The conversion is simple as long as you can convert binary to hex. Lay out 32 bits in front of you. The right-most bit corresponds to ASCII 00 (NULL), and the left-most bit corresponds to ASCII 32 decimal. Set the bits corresponding to the characters you want escaped to one, and all others to zero. To convert that into the hexadecimal number

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

A misconfigured PPP daemon can be a devastating security breach. It can be as bad as letting anyone plug their machine into your Ethernet (and that can be very bad). In this section, we discuss a few measures that should make your PPP configuration safe.

Root privilege is required to configure the network device and routing table. You will usually solve this by running pppd setuid root. However, pppd allows users to set various security-relevant options.

To protect against any attacks a user may launch by manipulating pppd options, you should set a couple of default values in the global /etc/ppp/options file, like those shown in the sample file in Section 6.3 Section 6.3, earlier in this chapter. Some of them, such as the authentication options, cannot be overridden by the user, and thus provide reasonable protection against manipulations. An important option to protect is the connect option. If you intend to allow non-root users to invoke pppd to connect to the Internet, you should always add the connect and noauth options to the global options file /etc/ppp/options. If you fail to do this, users will be able to execute arbitrary commands with root privileges by specifying the command as their connect command on the pppd line or in their personal options file.

Another good idea is to restrict which users may execute pppd by creating a group in /etc/group and adding only those users who you wish to have the ability to execute the PPP daemon. You should then change group ownership of the pppd daemon to that group and remove the world execute privileges. To do this, assuming you've called your group dialout, you could use something like:

# chown root /usr/sbin/pppd

# chgrp dialout /usr/sbin/pppd

# chmod 4750 /usr/sbin/pppd

Of course, you have to protect yourself from the systems you speak PPP with, too. To fend off hosts posing as someone else, you should always require some sort of authentication from your peer. Additionally, you should not allow foreign hosts to use any IP address they choose, but restrict them to at most a few. The following section will deal with these topics in detail.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

With PPP, each system may require its peer to authenticate itself using one of two authentication protocols: the Password Authentication Protocol (PAP) or the Challenge Handshake Authentication Protocol (CHAP). When a connection is established, each end can request the other to authenticate itself, regardless of whether it is the caller or the callee. In the description that follows, we will loosely talk of "client" and "server" when we want to distinguish between the system sending authentication requests and the system responding to them. A PPP daemon can ask its peer for authentication by sending yet another LCP configuration request identifying the desired authentication protocol.

PAP, which is offered by many Internet Service Providers, works basically the same way as the normal login procedure. The client authenticates itself by sending a username and a (optionally encrypted) password to the server, which the server compares to its secrets database. This technique is vulnerable to eavesdroppers, who may try to obtain the password by listening in on the serial line, and to repeated trial and error attacks.

CHAP does not have these deficiencies. With CHAP, the server sends a randomly generated "challenge" string to the client along with its hostname. The client uses the hostname to look up the appropriate secret, combines it with the challenge, and encrypts the string using a one-way hashing function. The result is returned to the server along with the client's hostname. The server now performs the same computation and acknowledges the client if it arrives at the same result.

CHAP also doesn't require the client to authenticate itself only at startup time, but sends challenges at regular intervals to make sure that the client hasn't been replaced by an intruder, for instance, by switching phone lines or because of a modem configuration error that causes the PPP daemon not to notice that the original phone call has dropped out and someone else has dialed in.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

By default, pppd logs any warnings and error messages to syslog's daemon facility. You have to add an entry to syslog.conf that redirects these messages to a file or even the console; otherwise, syslog simply discards them. The following entry sends all messages to /var/log/ppp-log:

daemon.*                /var/log/ppp-log

If your PPP setup doesn't work right away, you should look in this logfile. If the log messages don't help, you can also turn on extra debugging output using the debug option. This output makes pppd log the contents of all control packets sent or received to syslog. All messages then go to the daemon facility.

Finally, the most drastic way to check a problem is to enable kernel-level debugging by invoking pppd with the kdebug option. It is followed by a numeric argument that is the sum of the following values: 1 for general debug messages, 2 for printing the contents of all incoming HDLC frames, and 4 to make the driver print all outgoing HDLC frames. To capture kernel debugging messages, you must either run a syslogd daemon that reads the /proc/kmsg file, or the klogd daemon. Either of them directs kernel debugging to the syslog kernel facility.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

While configuring PPP to dial in to a network like the Internet is the most common application, some users have more advanced requirements. In this section we'll talk about a few of the more advanced configurations possible with PPP under Linux.

Running pppd as a server is just a matter of configuring a serial tty device to invoke pppd with appropriate options when an incoming data call has been received. One way to do this is to create a special account, say ppp, and give it a script or program as a login shell that invokes pppd with these options. Alternatively, if you intend to support PAP or CHAP authentication, you can use the mgetty program to support your modem and exploit its "/AutoPPP/" feature.

To build a server using the login method, you add a line similar to the following to your /etc/passwd file:

ppp:x:500:200:Public PPP Account:/tmp:/etc/ppp/ppplogin

If your system supports shadow passwords, you also need to add an entry to the /etc/shadow file:

ppp:!:10913:0:99999:7:::

Of course, the UID and GID you use depends on which user you wish to own the connection, and how you've created it. You also have to set the password for the mentioned account using the passwd command.

The ppplogin script might look like this:

#!/bin/sh

# ppplogin - script to fire up pppd on login

mesg n

stty -echo

exec pppd -detach silent modem crtscts

The mesg command disables other users from writing to the tty by using, for instance, the write command. The stty command turns off character echoing. This command is necessary; otherwise, everything the peer sends would be echoed back to it. The most important pppd option given is -detach because it prevents

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

PPPoE has become much more important recently, as it is the connection method of choice by a number of DSL providers. Fortunately for Linux users, a number of functional options are available, most of which are easily configurable. PPPoE is nothing new; it is simply the same PPP as used over dial-up, except it is used over Ethernet.

For the purposes of this section, we'll assume that your DSL modem and equipment are properly configured and ready for use. More information on how this is accomplished can be found in the excellent Linux DSL HOWTO, written by David Fannin and Hal Burgiss (http://www.tldp.org/HOWTO/DSL-HOWTO). Additionally, we'll assume that the Ethernet card in your PC is installed and operational.

In most DSL environments the DSL modem is configured to be a bridge, meaning that it won't have an IP address. As a result of this, your server will be configured with a WAN IP address. Before enabling the WAN interface, you should make certain that you've patched all of the listening services on your machine. Additionally, you should consider using an IPtables or other firewall. Security when connecting directly to the Internet should be of the utmost importance. It has been reported that unpatched versions of some Linux distributions survive only a few hours on the Internet before they're compromised. Make sure you've done as much as possible to ensure that this doesn't happen to you!

To get started with configuring PPPoE, you will need to obtain a PPPoE client. There are a number of clients available, including one from Roaring Penguin that has become very popular with many users and providers. It can be downloaded from http://www.roaringpenguin.com in both source format and as pre-compiled RPMs. When you've downloaded and compiled or installed the software, you are ready for configuration. The client software comes with a very easy to use configuration script called

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Security is increasingly important for companies and individuals alike. The Internet provides them with a powerful tool to distribute information about themselves and obtain information from others, but it also exposes them to dangers from which they were previously exempt. Computer crime, information theft, and malicious damage are all potential dangers.

This chapter covers the Linux features for setting up a firewall, known both by its command interface (iptables) and its kernel subsystem name (netfilter). This firewall implementation was new in the 2.4 kernel and works substantially the same way in 2.6.

A malicious person who gains access to a computer system may guess system passwords or exploit the bugs and idiosyncratic behavior of certain programs to obtain a working account on that host. Once they are able to log in to the host, they may have access to sensitive information. In a commercial setting, stealing, deleting, or modifying information such as marketing plans, new project details, or customer information databases can cause significant damage to the company.

The safest way to avoid such widespread damage is to prevent unauthorized people from gaining network access to the host. This is where firewalls come in.

Constructing secure firewalls is an art. It involves a good understanding of technology, but equally important, it requires an understanding of the philosophy behind firewall designs. We won't cover everything you need to know in this book; we strongly recommend you do some additional research before trusting any particular firewall design, including any we present here.

We will focus on the Linux-specific technical issues in this chapter. Later we will present a sample firewall configuration that should serve as a useful starting point in your own configuration, but as with all security-related matters, you'll want to make sure that you understand the information well enough to customize it to suit your needs and verify that the result is sufficient. Double-check the design, make sure that you understand it, and then modify it to suit your requirements. To be safe, be sure.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

As a network administrator, it is important that you understand the nature of potential attacks on computer security. We'll briefly describe the most important types of attacks so that you can better understand precisely what the Linux IP firewall will protect you against. You should do some additional reading to ensure that you are able to protect your network against other types of attacks. Here are some of the more important methods of attack and ways of protecting yourself against them:

Unauthorized access: This simply means that people who shouldn't be allowed to use your computer services are able to connect to and use them. For example, people outside your company might try to connect to your company accounting host or to your NFS server.

There are various ways to avoid this attack by carefully specifying who can gain access through these services. You can prevent network access to all except the intended users.

Exploitation of known weaknesses in programs: Some programs and network services were not originally designed with strong security in mind and are inherently vulnerable to attack. The BSD remote services (rlogin, rexec, etc.) are an example.

The best way to protect yourself against this type of attack is to disable any vulnerable services or find alternatives. A good place to start is to only install, run and expose services that you absolutely have to. Start with no network services and work your way up from there. Use the netstat command to determine the ports that your host is listening on, make sure the list is as small as possible, and know exactly what each of them is for. Don't run any network services on the firewall host, with the possible exception of Secure Shell (SSH)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

A firewall is a hardened and trusted host that acts as a choke point among a group of networks (usually a single private network and a single public network). All network traffic among the affected networks is routed through the firewall. The firewall host is configured with a set of rules that determine which network traffic will be allowed to pass and which will be blocked (dropped without response) or refused (rejected with a response). In some large organizations, you may even find a firewall located inside their corporate network to segregate sensitive areas of the organization from employees in other areas. Many cases of computer crime originate within an organization, rather than from outside.

Firewalls can be constructed in a variety of ways. The most sophisticated arrangement involves a number of separate hosts and is known as a perimeter network or demilitarized zone (DMZ) network. Two hosts act as "filters" (sometimes called chokes) to allow only certain types of network traffic to pass, and between these chokes reside network servers such as an email (SMTP) server or a World Wide Web (HTTP) proxy server. This configuration can be very safe and allows a great range of control over who can connect both from the inside to the outside and from the outside to the inside. This sort of configuration might be used by large organizations.

In many cases, though, people build firewalls that also provide other services (such as SMTP or HTTP). These are less secure because if someone exploits a weakness in one of the extra services running on the firewall, the entire network's security has been breached. The attacker could modify the firewall rules to allow more access and turn off accounting that might have otherwise alerted the network administrator that there was unusual network activity. Nevertheless, these types of firewalls are cheaper and easier to manage than the more sophisticated arrangement just described. Figure 7-1 illustrates the two most common firewall configurations.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

IP filtering is simply a mechanism that decides which types of IP packets will be processed normally and which will be dropped or rejected. By dropped we mean that the packet is deleted and completely ignored, as if it had never been received. By rejected we mean that the firewall sends an ICMP response to the sender indicating a reason why the packet was rejected. You can apply many different sorts of criteria to determine which packets you wish to filter. Some examples of these are:

Protocol type: TCP, UDP, ICMP, etc.
Port number (for TCP/UPD)
Packet type: SYN/ACK, data, ICMP Echo Request, etc.
Packet source address: where it came from
Packet destination address: where it is going to

It is important to understand at this point that IP filtering is a network layer facility. This means that it doesn't understand anything about the application using the network connections, only about the connections themselves. For example, you may deny users access to your internal network on the default Telnet port, but if you rely on IP filtering alone, you can't stop them from using the Telnet program with a port that you do allow to pass through your firewall. You can prevent this sort of problem by using proxy servers for each service that you allow across your firewall. The proxy servers understand the application that they were designed to proxy and can therefore prevent abuses, such as using the Telnet program to get past a firewall by using the World Wide Web port. If your firewall supports a World Wide Web proxy, outbound Telnet connections on the HTTP port will always be answered by the proxy and will allow only HTTP requests to pass. A large number of proxy-server programs exist. Some are free software and many others are commercial products. The

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

While developing the previous version of Linux IP firewalling (called ipchains), Paul "Rusty" Russell decided that IP firewalling should be less difficult. He set about the task of simplifying aspects of packet processing in the kernel firewalling code and produced a filtering framework that was both much cleaner and much more flexible. He called this new framework netfilter.

While ipchains was a vast improvement over its predecessor (ipfwadm) for the management of firewall rules, the way it processed packets was still complex, especially in conjunction with important features such as IP masquerade (discussed in Chapter 9) and other forms of address translation. Part of this complexity existed because IP masquerade and NAT were developed independently of the IP firewalling code and integrated later, rather than having been designed as a true part of the firewall code from the start. If a developer wanted to add yet more features in the packet-processing sequence, he would have had difficulty finding a place to insert the code and would have been forced to make changes in the kernel in order to do so.

netfilter addresses both the complexity and the rigidity of older solutions by implementing a generic framework in the kernel that streamlines the way packets are processed and provides a capability to extend filtering policy without having to modify the kernel. The Linux 2.4 Packet Filtering HOWTO (available online at http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO.html) offers a detailed list of the changes that have been made, so let's focus on the more practical aspects here.

To build a Linux IP firewall, it is necessary to have a kernel built with IP firewall (netfilter) support and the iptables user-space configuration utility. The netfilter code is the result of a large redesign of the packet handling flow in Linux. netfilter provides direct backward-compatible support for both of the two older Linux firewalling solutions (

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

iptables defines five "hook points" in the kernel's packet processing pathways: PREROUTING, INPUT, FORWARD, POSTROUTING, and OUTPUT. Built-in chains are attached to these hook points; you can add a sequence of rules for each of them. Each of these represents an opportunity to affect or monitor packet flow.

It is common to refer to "the PREROUTING chain of the nat table," which makes it seem like chains belong to tables. But chains and tables are only partially correlated, and neither really "belongs" to the other. Chains represent hook points in the packet flow, and tables represent the types of processing that can occur. Figure 7-2 shows all the legal combinations, and the order in which they are encountered by packets flowing through the system.

Figure 7-2 shows how packets traverse the system. The boxes represent the iptables chains, and inside each box is a list of the tables that have such a chain (in the order in which they are invoked). All of these Table and Chain combinations are involved in packet mangling.

Figure 7-2: All network packet flow hook points

In Figure 7-3, the gray boxes represent chains and tables not involved in NAT.

Figure 7-3: Network packet flow and hook points for NAT

Figure 7-4 shows how packets traverse the system for packet filtering.

Figure 7-4: Network packet flow and hook points for filtering

Table 7-3 shows the five "hook points" and describes the points in the packet flow where they allow you to specify processing.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The Linux kernel must be configured to support IP firewalling. There isn't much more to it than selecting the appropriate options when performing:

# make menuconfig

of your kernel. In 2.4 kernels you should select the following options:

Networking options  --->

     [*] Network packet filtering (replaces ipchains)

         IP: Netfilter Configuration  --->

              .

             <M> Userspace queueing via NETLINK (EXPERIMENTAL)

             <M> IP tables support (required for filtering/masq/NAT)

             <M>   limit match support

             <M>   MAC address match support

             <M>   netfilter MARK match support

             <M>   Multiple port match support



             <M>   TOS match support

             <M>   Connection state match support

             <M>   Unclean match support (EXPERIMENTAL)

             <M>   Owner match support (EXPERIMENTAL)

             <M>   Packet filtering

             <M>     REJECT target support

             <M>     MIRROR target support (EXPERIMENTAL)

              .

             <M>   Packet mangling

             <M>     TOS target support

             <M>     MARK target support

             <M>   LOG target support

             <M> ipchains (2.2-style) support

             <M> ipfwadm (2.0-style) support

Before you can use the iptables command, you must load the netfilter kernel module that provides support for it. The easiest way to do this is to use the modprobe command as follows:

# modprobe ip_tables

The remarkable flexibility of Linux netfilter is illustrated by its ability to emulate the ipfwadm and ipchains interfaces. Emulation makes the initial transition to the new generation of firewall software much easier (although you'd want to rewrite your rules as iptables eventually).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The iptables command is extensible through dynamically loaded libraries. It is included in the netfilter source package available at http://www.netfilter.org/. It will also be included in any Linux distribution based on the 2.4 series kernels.

The iptables command is used to configure IP filtering and NAT (along with other packet-processing applications, including accounting, logging, and mangling). To facilitate this, there are two tables of rules called filter and nat. The filter table is assumed if you do not specify the -t option to override it. Five built-in chains are also provided. The INPUT and FORWARD chains are available for the filter table, the PREROUTING and POSTROUTING chains are available for the nat table, and the OUTPUT chain is available for both tables. In this chapter we'll discuss only the filter table. We'll look at the nat table in Chapter 9.

The general syntax of most iptables commands is:

# iptables 

            command rule-specification 

            extensions

Now we'll take a look at some options in detail, after which we'll review some examples.

Most of the options for the iptables command can be grouped into subcommands and rule match criteria. Table 7-6 describes the other options.

Table 7-6: iptables miscellaneous options
Option	Description
`-c` packets bytes	When combined with the `-A`, `-I`, or `-R` subcommand, sets the packet counter to packets and the byte counter to

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Each iptables command can contain one subcommand, which performs an operation on a particular table (and, in some cases, chain). Table 7-7 lists the options that are used to specify the subcommand.

The manpage for the iptables command in the 1.2.7a release shows a -C option in the synopsis section, but there is no -C option to the iptables command.

Table 7-7: iptables subcommand options
Option	Description
`-A` chain rule	Appends rule to chain.
`--append`	Synonym for `-A`.
`-D` chain `[` index `\|` rule `]`	Deletes the rule at position index or matching rule from chain.
`--delete`	Synonym for `-D`.
`--delete-chain`	Synonym for `-X`.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

iptables has a small number of built-in matches and targets and a set of extensions that are loaded if they are referenced. The matches for IP are considered built-in, and the others are considered match extensions (even though the icmp, tcp and udp match extensions are automatically loaded when the corresponding protocols are referenced with the -p built-in IP match option).

Some options can have their senses inverted by using an optional exclamation point surrounded by spaces, immediately before the option. The options that allow this are annotated with [!]. Only the non-inverted sense is described in the sections that follow, since the inverted sense can be inferred from it.

These built-in matches are available without a preceding -m argument to iptables. Table 7-8 shows the layout of the fields in an Internet Protocol (IPv4) packet. These fields are the subjects of various match and target extensions (including the set of built-in matches described in this section). Table 7-8 describes the options to this match.

Table 7-8: Internet Protocol match options
Option	Description
`-d [!]` addr `[/` mask `]`	Destination address addr (or range, if mask is given).
`--destination`	Synonym for

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We've discussed the fundamentals of firewall configuration. Let's now look at an easily customizable firewall configuration. In this example, the network 172.16.1.0/24 is treated as if it were a publicly routable network, but it is actually a private, non-routable network. We are using such a non-routable network in this example because we have to use some network, and we don't want to put a real publicly routable network number here. The commands shown would work for a real class C publicly routable network.

#!/bin/bash

##########################################################################

# This sample configuration is for a single host firewall configuration

# with no services supported by the firewall host itself.

##########################################################################

#

# USER CONFIGURABLE SECTION (Lists are comma-separated)

#

#   OURNET    Internal network address space

#   OURBCAST  Internal network broadcast address

#   OURDEV    Internal network interface name

#

#   ANYADDR   External network address space

#   EXTDEV    External network interface name

#

#   TCPIN     List of TCP ports to allow in (empty = all)

#   TCPOUT    List of TCP ports to allow out (empty = all)

#

#   UDPIN     List of TCP ports to allow in (empty = all)

#   UDPOUT    List of TCP ports to allow out (empty = all)

#

#   LOGGING   Set to 1 to turn logging on, else leave empty

#

###########################################################################

   

OURNET="172.29.16.0/24"

OURBCAST="172.29.16.255"

OURDEV="eth0"

   

ANYADDR="0/0"

EXTDEV="eth1"

   

TCPIN="smtp,www"

TCPOUT="smtp,www,ftp,ftp-data,irc"

   

UDPIN="domain"

UDPOUT="domain"

   

LOGGING=

   

###########################################################################

#

# IMPLEMENTATION

#

###########################################################################

   

#

# Install the modules

#

   

modprobe ip_tables

modprobe ip_conntrack # Means we won't have to deal with fragments

   

#

# Drop all packets destined for this host received from outside.

#

   

iptables -A INPUT -i $EXTDEV -j DROP

   

#

# Remove all rules on the FORWARD chain of the filter table, and set th

# policy for that chain to DROP.

#

   

iptables -F FORWARD                                         # Delete rules

iptables -P FORWARD DROP                                    # Policy = DROP

iptables -A FORWARD -s $OURNET -i $EXTDEV -j DROP           # Anti-spoof

iptables -A FORWARD -p icmp -i $EXTDEV -d $OURBCAST -j DROP # Anti-Smurf

   

#

# TCP - ESTABLISHED CONNECTIONS

#

# We will accept all TCP packets belonging to an existing connection

# (i.e. having the ACK bit set) for the TCP ports we're allowing through.

# This should catch more than 95 % of all valid TCP packets.

#

   

iptables -A FORWARD -d $OURNET -p tcp --tcp-flags SYN,ACK ACK \

  -m multiport --dports $TCPIN -j ACCEPT

   

iptables -A FORWARD -s $OURNET -p tcp --tcp-flags SYN,ACK ACK \

  -m multiport --sports $TCPIN -j ACCEPT

   

#

# TCP - NEW INCOMING CONNECTIONS

#

# We will accept connection requests from the outside only on the

# allowed TCP ports.

#

   

iptables -A FORWARD -i $EXTDEV -d $OURNET -p tcp --syn \

  -m multiport --sports $TCPIN -j ACCEPT

   

#

# TCP - NEW OUTGOING CONNECTIONS

#

# We will accept all outgoing tcp connection requests on the allowed /

# TCP ports.

#

   

iptables -A FORWARD -i $OURDEV -d $ANYADDR -p tcp --syn \

  -m multiport --dports $TCPOUT -j ACCEPT

   

#

# UDP - INCOMING

#

# We will allow UDP packets in on the allowed ports and back.

#

   

iptables -A FORWARD -i $EXTDEV -d $OURNET -p udp \

  -m multiport --dports $UDPIN -j ACCEPT

   

iptables -A FORWARD  -i $EXTDEV -s $OURNET -p udp \

  -m multiport --sports $UDPIN -j ACCEPT

   

#

# UDP - OUTGOING

#

# We will allow UDP packets out to the allowed ports and back.

#

   

iptables -A FORWARD -i $OURDEV -d $ANYADDR -p udp \

  -m multiport --dports $UDPOUT -j ACCEPT

   

iptables -A FORWARD -i $OURDEV -s $ANYADDR -p udp \

  -m multiport --sports $UDPOUT -j ACCEPT

   

#

# DEFAULT and LOGGING

#

# All remaining packets fall through to the default

# rule and are dropped. They will be logged if you've

# configured the LOGGING variable above.

#

   

if [ "$LOGGING" ]

then

  iptables -A FORWARD -p tcp  -j LOG  # Log barred TCP

  iptables -A FORWARD -p udp  -j LOG  # Log barred UDP

  iptables -A FORWARD -p icmp -j LOG  # Log barred ICMP

fi

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

There is enough material on firewall configuration and design to fill a whole book, and indeed here are some good references that you might like to read to expand your knowledge on the subject:

Real World Linux Security, Second Edition: by Bob Toxen (Prentice Hall). A great book with broad coverage of many security topics, including firewalls.
Building Internet Firewalls, Second Edition: by E. Zwicky, S. Cooper, and D. Chapman (O'Reilly). A guide explaining how to design and install firewalls for Unix, Linux, and Windows NT, and how to configure Internet services to work with the firewalls.
Firewalls and Internet Security, Second Edition: by W. Cheswick, S. Bellovin, and A. Rubin (Addison Wesley). This book covers the philosophy of firewall design and implementation.
Practical Unix & Internet Security, Third Edition: by S. Garfinkel, G. Spafford, and A. Schwartz (O'Reilly). This book covers a wide variety of security topics for popular Unix variants (including Linux), such as forensics, intrusion detection, firewalls, and more.
Linux Security Cookbook: by D. Barrett, R. Silverman, and R. Byrnes (O'Reilly). This book provides over 150 ready-to-use scripts and configuration files for important security tasks such as time-of-day network access restrictions, web server firewalling, preventing IP spoofing, and much more.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In today's world of commercial Internet service, it is becoming increasingly important to know how much data you are transmitting and receiving on your network connections. If you are an Internet Service Provider and you charge your customers by volume, this will be essential to your business. If you are a customer of an Internet Service Provider that charges by data volume, you will find it useful to collect your own data to ensure the accuracy of your Internet charges.

There are other uses for network accounting that have nothing to do with dollars and bills. If you manage a server that offers a number of different types of network services, it might be useful to you to know exactly how much data is being generated by each one. This sort of information could assist you in making decisions, such as what hardware to buy or how many servers to run.

The Linux kernel provides a facility that allows you to collect all sorts of useful information about the network traffic it sees. This facility is called IP accounting.

The Linux IP accounting feature is very closely related to the Linux firewall software. The places you want to collect accounting data are the same places that you would be interested in performing firewall filtering: into and out of a network host and in the software that does the routing of packets. If you haven't read the section on firewalls, now is probably a good time to do so, as we will be using some of the concepts described in Chapter 7.

Because IP accounting is closely related to IP firewall, the same tool was designated to configure it, so the iptables command is used to configure IP accounting. The command syntax is very similar to that of the firewall rules, so we won't focus on it, but we will discuss what you can discover about the nature of your network traffic using this feature.

The general command syntax is:

# iptables -A 

            chain rule-specification

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The Linux IP accounting feature is very closely related to the Linux firewall software. The places you want to collect accounting data are the same places that you would be interested in performing firewall filtering: into and out of a network host and in the software that does the routing of packets. If you haven't read the section on firewalls, now is probably a good time to do so, as we will be using some of the concepts described in Chapter 7.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Because IP accounting is closely related to IP firewall, the same tool was designated to configure it, so the iptables command is used to configure IP accounting. The command syntax is very similar to that of the firewall rules, so we won't focus on it, but we will discuss what you can discover about the nature of your network traffic using this feature.

The general command syntax is:

# iptables -A 

            chain rule-specification

The iptables command allows you to specify direction in a manner consistent with the firewall rules.

The commands are much the same as firewall rules, except that the policy rules do not apply here. We can add, insert, delete, and list accounting rules. In the case of ipchains and iptables, all valid rules are accounting rules, and any command that doesn't specify the -j option performs accounting only.

The rule specification parameters for IP accounting are the same as those used for IP firewalls. These are what we use to define precisely what network traffic we wish to count and total.

Let's work with an example to illustrate how we'd use IP accounting.

Imagine we have a Linux-based router that serves two departments at the Virtual Brewery. The router has two Ethernet devices, eth0 and eth1, each of which services a department; and a PPP device, ppp0, that connects us via a high-speed serial link to the main campus of the Groucho Marx University.

Let's also imagine that for billing purposes that we want to know the total traffic generated by each of the departments across the serial link, and for management purposes we want to know the total traffic generated between the two departments.

Table 8-1 shows the interface addresses we will use in our example:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

It is all very well to be collecting this information, but how do we actually get to see it? To view the collected accounting data and the configured accounting rules, we use our firewall configuration commands, asking them to list our rules. The packet and byte counters for each of our rules are listed in the output.

The iptables command behaves very similarly to the ipchains command. Again, we must use the -v when listing tour rules to see the accounting counters. To list our accounting data, we would use:

# iptables 

               -L 

               -v

Just as for the ipchains command, you can use the -x argument to show the output in expanded format with unit figures.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The IP accounting counters will overflow if you leave them long enough. If they overflow, you will have difficulty determining the value they actually represent. To avoid this problem, you should read the accounting data periodically, record it, and then reset the counters back to zero to begin collecting accounting information for the next accounting interval.

The iptables command provides you with a simple means of doing this:

# iptables 

            -Z

You can even combine the list and zeroing actions together to ensure that no accounting data is lost in between:

# iptables 

            -L 

            -Z 

            -v

This command will first list the accounting data and then immediately zero the counters and begin counting again. If you are interested in collecting and using this information regularly, you would probably want to put this command into a script that recorded the output and stored it somewhere, and execute the script periodically using the cron command.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

One last command that might be useful allows you to flush all the IP accounting rules that you have configured. This is most useful when you want to radically alter your rule set without rebooting the host.

The iptables command supports the -F argument, which flushes all the rules of the type you specify:

# iptables 

            -F

This flushes all of your configured rules (not just your accounting rules), removing them all and saving you having to remove each of them individually.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

One last trick you might like to consider: if your Linux host is connected to an Ethernet, you can apply accounting rules to all of the data from the segment, not only that which it is transmitted by or destined for it. Your host will passively listen to all of the data on the segment and count it.

You should first turn IP forwarding off on your Linux host so that it doesn't try to route the packets it receives. You can do so by running this command:

# echo 0 >/proc/sys/net/ipv4/ip_forward

You should then enable promiscuous mode on your Ethernet interface using the ifconfig command. Enabling promiscuous mode for an Ethernet device causes it to deliver all packets to the operating system rather than only those with its Ethernet address as the destination. This is only relevant if the device is connected to a broadcast medium (such as unswitched Ethernet). For example, to enable promiscuous mode on interface eth1:

# ifconfig eth1 promisc

Now you can establish accounting rules that allow you to collect information about the packets flowing across your Ethernet without involving your Linux accounting host in the route at all.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

You don't have to have a good memory to remember a time when only large organizations could afford to have a number of computers networked together by a LAN. Today network technology has dropped so much in price that two things have happened. First, LANs are now commonplace, even in many household environments. Certainly many Linux users will have two or more computers connected by some Ethernet. Second, network resources, particularly IP addresses, are now a scarce resource, and while they used to be free, they are now being bought and sold.

Most people with a LAN will probably also want an Internet connection that every computer on the LAN can use. The IP routing rules are strict in how they deal with this situation. Traditional solutions to this problem would have involved requesting an IP network address, perhaps a class C address for small sites, assigning each host on the LAN an address from this network and using a router to connect the LAN to the Internet.

In a commercialized Internet environment, this is an expensive proposition. First, you'd be required to pay for the network addresses that are assigned to you. Second, you'd probably have to pay your Internet Service Provider for the privilege of having a suitable route to your network put in place so that the rest of the Internet knows how to reach you. This might still be practical for companies, but domestic installations don't usually justify the cost.

Fortunately, Linux provides an answer to this dilemma. This answer involves a component of a group of advanced networking features called Network Address Translation (NAT). NAT describes the process of modifying the network addresses (and sometimes port numbers) contained with packet headers while they are in transit. This might sound odd at first, but we'll show that it is ideal for solving the problem we've just described. IP masquerading is the name given to one type of network address translation that allows all of the hosts on a private network to use the Internet at the price of a single dynamic IP address. When the single address is statically assigned, the same functionality goes by the name SNAT (

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The IP masquerade facility comes with its own set of side effects, some of which are useful and some of which might become bothersome.

None of the hosts on the supported network behind the masquerade router are ever directly seen; consequently, you need only one valid and routable IP address to allow all hosts to make network connections out onto the Internet. This has a downside: none of those hosts are visible from the Internet and you can't directly connect to them from the Internet; the only host visible on a masqueraded network is the masquerade host itself. This is important when you consider services such as mail or FTP. It helps determine what services should be provided by the masquerade host and what services it should proxy or otherwise treat specially.

However, you can use DNAT (Destination NAT) on the router to route inbound connections to certain ports to internal servers. This works great for web and mail servers. You can run those services on hosts on the private network, and use DNAT to forward inbound connections to port 80 and port 25 to the appropriate internal servers. This way, the router host is only involved in routing, not in providing any externally visible services. You can use the same technique to route incoming connections to a high-numbered port (say, 4022) to the Secure Shell (SSH) port (usually 22) on an internal host so you can SSH directly into one of your internal hosts through the router.

Because none of the masqueraded hosts are visible, they are relatively protected from attacks from outside. You can have one host serve as your firewall and masquerading router. Your whole network will be only as safe as your masquerade host, so you should use firewall rules to protect it and you should not run any other externally visible services on it.

IP masquerade will have some impact on the performance of your networking. In typical configurations this will probably be barely measurable. If you have large numbers of active masquerade sessions, though, you may find that the processing required at the masquerade host begins to impact your network throughput. IP masquerade must do a good deal of work for each packet compared to the process of conventional routing. That low-end host you have been planning on using as a masquerade host supporting a personal link to the Internet might be fine, but don't expect too much if you decide you want to use it as a router in your corporate network at Ethernet speeds.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

To use the IP masquerade facility, your kernel must be compiled with network packet filtering support. You must select the following options when configuring the kernel:

Networking options --->



 [M] Network packet filtering (replaces ipchains)

The netfilter package includes modules that help perform masquerading functions. For example, to provide connection tracking of FTP sessions, you'd load and use the ip_conntrack_ftp and ip_nat_ftp.o modules. This connection tracking support is required for masquerading to work correctly with protocols that involve multiple connections for one logical session, since masquerading relies on connection tracking.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

If you've already read the firewall and accounting chapters, it probably comes as no surprise that the iptables command is used to configure the IP masquerade rules as well.

Masquerading is a special type of packet mangling (the technical term for modifying packets). You can masquerade only packets that are received on one interface that will be routed to another interface. To configure a masquerade rule, construct a rule very similar to a firewall forwarding rule, but with special options that tell the kernel to masquerade the packet. The iptables command uses -j MASQUERADE to indicate that packets matching the rule specification should be masqueraded (this is for a dynamic IP address; if you have a static IP address, use

-j

SNAT

instead).

Let's look at an example. A computing science student at Groucho Marx University has a number of computers at home on a small Ethernet-based LAN. She has chosen to use one of the reserved private Internet network addresses for her network. She shares her accommodation with other students, all of whom have an interest in using the Internet. Because the students' finances are very tight, they cannot afford to use a permanent Internet connection, so instead they use a single Internet connection. They would all like to be able to share the connection to chat on IRC, surf the Web, and retrieve files by FTP directly to each of their computers—IP masquerade is the answer.

The student first configures a Linux host to support the Internet link and to act as a router for the LAN. The IP address she is assigned when she dials up isn't important. She configures the Linux router with IP masquerade and uses one of the private network addresses for her LAN: 192.168.1.0. She ensures that each of the hosts on the LAN has a default route pointing at the Linux router.

The following iptables commands are all that are required to make masquerading work in her configuration:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Handling domain nameserver lookups from the hosts on the LAN with IP masquerading has always presented a problem. There are two ways of accommodating DNS in a masquerade environment. You can tell each of the hosts to use the same DNS that the Linux router host does, and let IP masquerade do its magic on their DNS requests. Alternatively, you can run a caching nameserver on the Linux host and have each of the hosts on the LAN use the Linux host as their DNS. Although a more aggressive action, this is probably the better option because it reduces the volume of DNS traffic traveling on the Internet link and will be marginally faster for most requests, since they'll be served from the cache. The downside to this configuration is that it is more complex. The Section 5.2.6 in Chapter 5 describes how to configure a caching nameserver.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The netfilter software is capable of many different types of NAT. IP masquerade is one simple application of it.

It is possible, for example, to build NAT rules that translate only certain addresses or ranges of addresses and leave all others untouched, or to translate addresses into pools of addresses rather than just a single address, as masquerade does. You can in fact use the iptables command to generate NAT rules that map just about anything, with combinations of matches using any of the standard attributes, such as source address, destination address, protocol type, port number, etc.

Translating the source address of a packet is referred to as Source NAT, or SNAT, in iptables. Translating the destination address of a packet is known as Destination NAT, or DNAT. SNAT and DNAT are targets that you may use with the iptables command to build more sophisticated rules.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

After successfully setting up IP and the resolver (DNS), you then must look at the services you want to provide over the network. This chapter covers the configuration of a few simple network applications, including the inetd and xinetd servers and the programs from the rlogin family. We'll also deal briefly with the Remote Procedure Call interface, upon which services like the Network File System (NFS) are based. The configuration of NFS, however, is more complex and is not described in this book.

Of course, we can't cover all network applications in this book. If you want to install one that's not discussed here, please refer to the manual pages of the server for details.

Programs that provide application services via the network are called network daemons. A daemon is a program that opens a port, most commonly a well-known service port, and waits for incoming connections on it. If one occurs, the daemon creates a child process that accepts the connection, while the parent continues to listen for further requests. This mechanism works well but has a few disadvantages; at least one instance of every possible service that you wish to provide must be active in memory at all times. In addition, the software routines that do the listening and port handling must be replicated in every network daemon.

To overcome these inefficiencies, most Unix installations run a special network daemon, what you might consider a "super server." This daemon creates sockets on behalf of a number of services and listens on all of them simultaneously. When an incoming connection is received on any of these sockets, the super server accepts the connection and spawns the server specified for this port, passing the socket across to the child to manage. The server then returns to listening.

The most common super server is called inetd, the Internet Daemon. It is started at system boot time and takes the list of services it is to manage from a startup file named

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Programs that provide application services via the network are called network daemons. A daemon is a program that opens a port, most commonly a well-known service port, and waits for incoming connections on it. If one occurs, the daemon creates a child process that accepts the connection, while the parent continues to listen for further requests. This mechanism works well but has a few disadvantages; at least one instance of every possible service that you wish to provide must be active in memory at all times. In addition, the software routines that do the listening and port handling must be replicated in every network daemon.

To overcome these inefficiencies, most Unix installations run a special network daemon, what you might consider a "super server." This daemon creates sockets on behalf of a number of services and listens on all of them simultaneously. When an incoming connection is received on any of these sockets, the super server accepts the connection and spawns the server specified for this port, passing the socket across to the child to manage. The server then returns to listening.

The most common super server is called inetd, the Internet Daemon. It is started at system boot time and takes the list of services it is to manage from a startup file named /etc/inetd.conf. In addition to those servers, there are a number of trivial services performed by inetd itself called internal services. They include chargen, which simply generates a string of characters, and daytime, which returns the system's idea of the time of day.

An entry in this file consists of a single line made up of the following fields:


            service 

            type 

            protocol 

            wait 

            user 

            server 

            cmdline

Each of the fields is described in the following list:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Since opening a computer to network access involves many security risks, applications are designed to guard against several types of attacks. Some security features, however, may be flawed (most drastically demonstrated by the RTM Internet worm, which exploited a hole in a number of programs, including old versions of the sendmail mail daemon), or do not distinguish between secure hosts from which requests for a particular service will be accepted and insecure hosts whose requests should be rejected. We've already briefly discussed the finger and tftp services. A network administrator would want to limit access to these services to "trusted hosts" only, which is impossible with the usual setup, for which inetd provides this service either to all clients or not at all.

A useful tool for managing host-specific access is tcpd, often called the daemon "wrapper." For TCP services you want to monitor or protect, it is invoked instead of the server program. tcpd checks whether the remote host is allowed to use that service, and only if this succeeds will it execute the real server program. tcpd also logs the request to the syslog daemon. Note that this does not work with UDP-based services.

For example, to wrap the finger daemon, you have to change the corresponding line in inetd.conf from this:

# unwrapped finger daemon

finger    stream tcp nowait bin    /usr/sbin/fingerd in.fingerd

to this:

# wrap finger daemon

finger  stream  tcp     nowait  root    /usr/sbin/tcpd   in.fingerd

Without adding any access control, this will appear to the client as the usual finger setup, except that any requests are logged to syslog's auth facility.

Two files called /etc/hosts.allow and /etc/hosts.deny implement access control. They contain entries that allow and deny access to certain services and hosts. When

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

An alternative to the standard inetd has emerged and is now widely accepted. It is considered a more secure and robust program, and provides protection against some DoS attacks used against inetd. The number of features offered by xinetd also makes it a more appealing alternative. Here is a brief list of features:

Provides full-featured access control and logging
Limits to the number of servers run at a single time
Offers granular service-binding -services, which can be bound to specific IP addresses

xinetd is now a standard part of most Linux distributions, but if you need to find the latest source code or information, check the main distribution web site http://www.xinetd.org. If you are compiling, and use IPv6, you should make certain that you use the --with-inet6 option.

The configuration of xinetd is somewhat different, but not more complex than inetd. Rather than forcing one master configuration file for all services, xinetd can be configured to use a master configuration file, /etc/xinetd.conf, and separate configuration files for each additional service configured. This, aside from simplifying configuration, allows for more granular configuration of each service, leading to xinetd's greater flexibility.

The first file you'll need to configure is /etc/xinetd.conf. A sample file looks like this:

# Sample configuration file for xinetd

   

defaults

{

        only_from      = localhost

        instances      = 60

        log_type       = SYSLOG authpriv info

        log_on_success = HOST PID

        log_on_failure = HOST

        cps            = 25 30

}

  

includedir /etc/xinetd.d

There are a number of options that can be configured, the options used above are:

only_from

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The port numbers on which certain "standard" services are offered are defined in the Assigned Numbers RFC. To enable server and client programs to convert service names to these numbers, at least part of the list is kept on each host; it is stored in a file called /etc/services. An entry is made up like this:


            service 

            port/protocol   [aliases]

Here, service specifies the service name, port defines the port the service is offered on, and protocol defines which transport protocol is used. Commonly, the latter field is either udp or tcp. It is possible for a service to be offered for more than one protocol, as well as offering different services on the same port as long as the protocols are different. The aliases field allows you to specify alternative names for the same service.

Usually, you don't have to change the services file that comes along with the network software on your Linux system. Nevertheless, we give a small excerpt from that file in Example 10-2.

Example 10-2. A sample /etc/services file

# /etc/services

    

tcpmux          1/tcp                           # TCP port service multiplexer

echo            7/tcp

echo            7/udp

discard         9/tcp           sink null

discard         9/udp           sink null

systat          11/tcp          users

daytime         13/tcp

daytime         13/udp

netstat         15/tcp

qotd            17/tcp          quote

msp             18/tcp                          # message send protocol

msp             18/udp                          # message send protocol

chargen         19/tcp          ttytst source

chargen         19/udp          ttytst source

ftp-data        20/tcp

ftp             21/tcp

fsp             21/udp          fspd

ssh             22/tcp                          # SSH Remote Login Protocol

ssh             22/udp                          # SSH Remote Login Protocol

telnet          23/tcp

# 24 - private

smtp            25/tcp          mail

# 26 - unassigned

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The general mechanism for client-server applications is provided by the Remote Procedure Call (RPC) package. RPC was developed by Sun Microsystems and is a collection of tools and library functions. An important application built on top of RPC is NFS.

An RPC server consists of a collection of procedures that a client can call by sending an RPC request to the server along with the procedure parameters. The server will invoke the indicated procedure on behalf of the client, handing back the return value, if there is any. In order to be machine-independent, all data exchanged between client and server is converted to the External Data Representation format (XDR) by the sender, and converted back to the machine-local representation by the receiver. RPC relies on standard UDP and TCP sockets to transport the XDR formatted data to the remote host. Sun has graciously placed RPC in the public domain; it is described in a series of RFCs.

Sometimes improvements to an RPC application introduce incompatible changes in the procedure call interface. Of course, simply changing the server would crash all applications that still expect the original behavior. Therefore, RPC programs have version numbers assigned to them, usually starting with 1, and with each new version of the RPC interface, this counter will be bumped up. Often, a server may offer several versions simultaneously; clients then indicate by the version number in their requests which implementation of the service they want to use.

The communication between RPC servers and clients is somewhat peculiar. An RPC server offers one or more collections of procedures; each set is called a program and is uniquely identified by a program number. A list that maps service names to program numbers is usually kept in

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

It's often very useful to execute a command on a remote host and have input or output from that command be read from, or written to, a network connection.

The traditional commands used for executing commands on remote hosts are rlogin, rsh, and rcp. We briefly discussed the security issues associated with it in Chapter 1 and suggested ssh as a replacement. The ssh package provides replacements called ssh and scp.

Each of these commands spawns a shell on the remote host and allows the user to execute commands. Of course, the client needs to have an account on the remote host where the command is to be executed. Thus, all these commands use an authentication process. The r commands use a simple username and password exchange between the hosts with no encryption, so anyone listening could easily intercept the passwords. The ssh command suite provides a higher level of security: it uses a technique called Public Key Cryptography, which provides authentication and encryption between the hosts to ensure that neither passwords nor session data are easily intercepted by other hosts.

It is possible to relax authentication checks for certain users even further. For instance, if you frequently have to log in to other machines on your LAN, you might want to be admitted without having to type your password every time. This was always possible with the r commands, but the ssh suite allows you to do this a little more easily. It's still not a great idea because it means that if an account on one machine is breached, access can be gained to all other accounts that user has configured for password-less login, but it is very convenient and people will use it.

Let's talk about removing the r commands and getting ssh to work instead.

Start by removing the

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Electronic mail transport has been one of the most prominent uses of networking since networks were devised. Email started as a simple service that copied a file from one machine to another and appended it to the recipient's mailbox file. The concept remains the same, although an ever-growing net, with its complex routing requirements and its ever increasing load of messages, has made a more elaborate scheme necessary.

Various standards of mail exchange have been devised. Sites on the Internet adhere to one laid out in RFC 822, augmented by some RFCs that describe a machine-independent way of transferring just about anything, including graphics, sound files, and special characters sets, by email. CCITT has defined another standard, X.400. It is still used in some large corporate and government environments, but is progressively being retired.

Quite a number of mail transport programs have been implemented for Unix systems. One of the best known is sendmail, which was developed by Eric Allman at the University of California at Berkeley. Eric Allman now offers sendmail through a commercial venture, but the program remains free software. sendmail is supplied as the standard mail transfer agent (or MTA) in some Linux distributions. We describe sendmail configuration in Chapter 12.

sendmail supports a set of configuration files that have to be customized for your system. Apart from the information that is required to make the mail subsystem run (such as the local hostname), there are many parameters that may be tuned. sendmail's main configuration file is very hard to understand at first. It looks as if your cat has taken a nap on your keyboard with the Shift key pressed. Luckily, modern configuration techniques take away a lot of the head scratching.

When users retrieve mail on their personal systems, they need another protocol to use to contact the mail server. In Chapter 15 we discuss a powerful and increasingly popular type of server called IMAP.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

A mail message generally consists of a message body, which is the text of the message, and special administrative data specifying recipients, transport medium, etc., similar to what you see when you look at a physical letter's envelope.

This administrative data falls into two categories. In the first category is any data that is specific to the transport medium, such as the address of sender and recipient. It is therefore called the envelope. It may be transformed by the transport software as the message is passed along.

The second variety is any data necessary for handling the mail message, which is not particular to any transport mechanism, such as the message's subject line, a list of all recipients, and the date the message was sent. In many networks, it has become standard to prepend this data to the mail message, forming the so-called mail header. It is offset from the mail body by an empty line. Most mail transport software in the Unix world use a header format outlined in RFC 822. Its original purpose was to specify a standard for use on the ARPANET, but since it was designed to be independent from any environment, it has been easily adapted to other networks, including many UUCP-based networks.

RFC 822 is only the lowest common denominator, however. More recent standards have been conceived to cope with growing needs such as data encryption, international character set support, and Multipurpose Internet Mail Extensions (MIME), described in RFC 1341 and other RFCs.

In all these standards, the header consists of several lines separated by an end-of-line sequence. A line is made up of a field name, beginning in column one, and the field itself, offset by a colon and whitespace. The format and semantics of each field vary depending on the field name. A header field can be continued across a newline if the next line begins with a whitespace character such as tab. Fields can appear in any order.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Generally, you will compose mail using a program such as mail or mailx, or more sophisticated ones such as mutt, tkrat, or pine. These programs are called mail user agents (MUAs). If you send a mail message, the interface program will in most cases hand it to another program for delivery. This is called the mail transport agent (MTA). On most systems the same MTA is used for both local and remote delivery and is usually invoked as /usr/sbin/sendmail, or on non-FSSTND compliant systems as /usr/lib/sendmail.

Local delivery of mail is, of course, more than just appending the incoming message to the recipient's mailbox. Usually, the local MTA understands aliasing (setting up local recipient addresses pointing to other addresses) and forwarding (redirecting a user's mail to some other destination). Also, messages that cannot be delivered must usually be bounced—that is, returned to the sender along with some error message.

For remote delivery, the transport software used depends on the nature of the link. Mail delivered over a network using TCP/IP commonly uses Simple Mail Transfer Protocol (SMTP), which is described in RFC 821. SMTP was designed to deliver mail directly to a recipient's machine, negotiating the message transfer with the remote side's SMTP daemon. Today it is common practice for organizations to establish special hosts that accept all mail for recipients in the organization and for that host to manage appropriate delivery to the intended recipient.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Email addresses are made up of at least two parts. One part is the name of a mail domain that will ultimately translate to either the recipient's host or some host that accepts mail on behalf of the recipient. The other part is some form of unique user identification that may be the login name of that user, the real name of that user in "Firstname.Lastname" format, or an arbitrary alias that will be translated into a user or list of users. Other mail addressing schemes, such as X.400, use a more general set of "attributes" that are used to look up the recipient's host in an X.500 directory server.

How email addresses are interpreted depends greatly on what type of network you use. We'll concentrate on how TCP/IP networks interpret email addresses.

Internet sites adhere to the RFC 822 standard, which requires the familiar notation of user@host.domain, for which host.domain is the host's fully qualified domain name. The character separating the two is properly called a "commercial at" sign, but it helps if you read it as "at." This notation does not specify a route to the destination host. Routing of the mail message is left to the mechanisms we'll describe shortly.

Before moving on, let's have a look at the way things used to be. In the original UUCP environment, the prevalent form was path!host!user, for which path described a sequence of hosts the message had to travel through before reaching the destination host. This construct is called the bang path notation because an exclamation mark is colloquially called a "bang."

Other networks had still different means of addressing. DECnet-based networks, for example, used two colons as an address separator, yielding an address of host::user

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The process of directing a message to the recipient's host is called routing. Apart from finding a path from the sending site to the destination, it involves error checking and may involve speed and cost optimization.

On the Internet, the main job of directing data to the recipient host (once it is known by its IP address) is done by the IP networking layer.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

On the Internet, the destination host's configuration determines whether any specific mail routing is performed. The default is to deliver the message to the destination by first determining what host the message should be sent to and then delivering it directly to that host. Most Internet sites want to direct all inbound mail to a highly available mail server that is capable of handling all this traffic and have it distribute the mail locally. To announce this service, the site publishes a so-called MX record for its local domain in its DNS database. MX stands for Mail Exchanger and basically states that the server host is willing to act as a mail forwarder for all mail addresses in the domain. MX records can also be used to handle traffic for hosts that are not connected to the Internet themselves. These hosts must have their mail passed through a gateway. This concept is discussed in greater detail in Chapter 6.

MX records are always assigned a preference. This is a positive integer. If several mail exchangers exist for one host, the mail transport agent will try to transfer the message to the exchanger with the lowest preference value, and only if this fails will it try a host with a higher value. If the local host is itself a mail exchanger for the destination address, it is allowed to forward messages only to MX hosts with a lower preference than its own; this is a safe way of avoiding mail loops. If there is no MX record for a domain, or no MX records left that are suitable, the mail transport agent is permitted to see if the domain has an IP address associated with it and attempt delivery directly to that host.

Suppose that an organization, say Foobar, Inc., wants all its mail handled by its machine mailhub. It will then have MX records like this in the DNS database:

green.foobar.com.        IN   MX      5    mailhub.foobar.com.

This announces mailhub.foobar.com

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

It's been said that you aren't a real Unix system administrator until you've edited a sendmail.cf file. It's also been said that you're crazy if you've attempted to do so twice.

Fortunately, you no longer need to directly edit the cryptic sendmail.cf file. The new versions of sendmail provide a configuration utility that creates the sendmail.cf file for you based on much simpler macro files. You do not need to understand the complex syntax of the sendmail.cf file. Instead, you use the macro language to identify the features you wish to include in your configuration and specify some of the parameters that determine how that feature operates. A traditional Unix utility, called m4, then takes your macro configuration data and mixes it with the data it reads from template files containing the actual sendmail.cf syntax to produce your sendmail.cf file.

sendmail is an incredibly powerful mail program that is difficult to master. Any program whose definitive reference (sendmail, by Bryan Costales with Eric Allman, published by O'Reilly) is 1,200 pages long scares most people off. And any program as complex as sendmail cannot be completely covered in a single chapter. This chapter introduces sendmail and describes how to install, configure, and test it, using a basic configuration for the Virtual Brewery as an example. If the information presented here helps make the task of configuring sendmail less daunting for you, we hope you'll gain the confidence to tackle more complex configurations on your own.

sendmail is included in prepackaged form in most Linux distributions. Despite this fact, there are some good reasons to install sendmail from source, especially if you are security conscious. sendmail changes frequently to fix security problems and to add new features. Closing security holes and using new features are good reasons to update the sendmail release on your system. Additionally, compiling sendmail from source gives you more control over the sendmail environment. Subscribe to the

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

sendmail is included in prepackaged form in most Linux distributions. Despite this fact, there are some good reasons to install sendmail from source, especially if you are security conscious. sendmail changes frequently to fix security problems and to add new features. Closing security holes and using new features are good reasons to update the sendmail release on your system. Additionally, compiling sendmail from source gives you more control over the sendmail environment. Subscribe to the sendmail-announce mailing list to receive notices of new sendmail releases, and monitor the http://www.sendmail.org/ site to stay informed about potential security threats and the latest sendmail developments.

Download the sendmail source code distribution and the source code distribution signature file from http://www.sendmail.org/current-release.html, from any of the mirror sites, or from ftp://ftp.sendmail.org/pub/sendmail/. Here is an example using ftp:

# ftp ftp.sendmail.org

Connected to ftp.sendmail.org (209.246.26.22).

220 services.sendmail.org FTP server (Version 6.00LS) ready.

Name (ftp.sendmail.org:craig): anonymous

331 Guest login ok, send your email address as password.

Password: win@vstout.com

230 Guest login ok, access restrictions apply.

Remote system type is UNIX.

Using binary mode to transfer files.

ftp> cd /pub/sendmail

250 CWD command successful.

ftp> get sendmail.8.12.11.tar.gz

local: sendmail.8.12.11.tar.gz remote: sendmail.8.12.11.tar.gz

227 Entering Passive Mode (209,246,26,22,244,234)

150 Opening BINARY mode data connection for 'sendmail.8.12.11.tar.gz' (1899112 bytes).

226 Transfer complete.

1899112 bytes received in 5.7 secs (3.3e+02 Kbytes/sec)

ftp> get sendmail.8.12.11.tar.gz.sig

local: sendmail.8.12.11.tar.gz.sig remote: sendmail.8.12.11.tar.gz.sig

227 Entering Passive Mode (209,246,26,22,244,237)

150 Opening BINARY mode data connection for 'sendmail.8.12.11.tar.gz.sig' (152 bytes).

226 Transfer complete.

152 bytes received in 0.000949 secs (1.6e+02 Kbytes/sec)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

sendmail reads a configuration file (typically called /etc/mail/sendmail.cf, or in older distributions, /etc/sendmail.cf, or even /usr/lib/sendmail.cf ) that is simple for sendmail to parse, but not simple for a system administrator to read or edit. Fortunately, most sendmail configuration does not involve reading or editing the sendmail.cf file. Most sendmail configuration is macro driven. The macro method generates configurations to cover most installations, but you always have the option of tuning the resultant sendmail.cf manually.

The m4 macro processor program processes a macro configuration file to generate the sendmail.cf file. For our convenience, we refer to the macro configuration file as the sendmail.mc file throughout this chapter. Do not name your configuration file sendmail.mc. Instead, give it a descriptive name. For example, you might name it after the host it was designed for—vstout.m4, in our case. Providing a unique name for the configuration file allows you to keep all configuration files in the same directory and is an administrative convenience.

The configuration process is basically a matter of creating a sendmail.mc file that includes the macros that describe your desired configuration, and then processing that sendmail.mc file with m4. The sendmail.mc file may include basic m4 commands such as define or divert, but the lines in the file that have the most dramatic effect on the output file are the sendmail macros. The sendmail developers define the macros used in the sendmail.mc file. The m4 macro processor expands the macros into chunks of sendmail.cf syntax. The macro expressions included in the sendmail.mc file begin with the macro name (written in capital letters), followed by parameters (enclosed in brackets) that are used in the macro expansion. The parameters may be passed literally into the sendmail.cf output or may be used to govern the way the macro processing occurs.

Unlike a sendmail.cf file, which may be more than 1,000 lines long, a basic

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

There is rarely any need to use sendmail.cf commands in your configuration because the sendmail macros created by the sendmail developer handle most possible configurations. Yet it is useful to know something about the sendmail.cf command for those rare occasions when you come across a configuration that requires something that the sendmail developers just didn't think of. Table 12-3 lists the sendmail.cf configuration commands.

Table 12-3: sendmail.cf configuration commands
Command	Syntax	Meaning
Version Level	`[V` level / vendor]	Specify version level.
Define Macro	`D` xvalue	Set macro x to value.
Define Class	`C` cword1[ word2] ...	Set class c to word1 word2 ....
Define Class	`F` cfile	Load class c from file.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Using the sendmail.mc and sendmail.cf information covered so far in this chapter you should be able to read or create a basic sendmail configuration. Let's get started by looking at a sample sendmail.mc file.

The sendmail distribution comes with a large number of sample macro configuration files located in the cf/cf directory. Many are generic configuration files for different operating systems, including the generic-linux.mc file for Linux. Example 12-2 shows the contents of this file.

Example 12-2. The generic-linux.mc file

divert(-1)

#

# Copyright (c) 1998, 1999 Sendmail, Inc. and its suppliers.

#       All rights reserved.

# Copyright (c) 1983 Eric P. Allman.  All rights reserved.

# Copyright (c) 1988, 1993

#       The Regents of the University of California.  All rights reserved.

#

# By using this file, you agree to the terms and conditions set

# forth in the LICENSE file which can be found at the top level of

# the sendmail distribution.

#

#

   

#

#  This is a generic configuration file for Linux.

#  It has support for local and SMTP mail only.  If you want to

#  customize it, copy it to a name appropriate for your environment

#  and do the modifications there.

#

   

divert(0)dnl

VERSIONID(`$Id: ch12.xml,v 1.2 2005/03/03 21:11:44 ellie Exp $') 

OSTYPE(`linux')dnl

DOMAIN(`generic')dnl

MAILER(`local')dnl

MAILER(`smtp')dnl

A few things are obvious about this configuration file without knowing anything about the file syntax. First, the name sendmail.mc is obviously not sacrosanct. generic-linux.mc works just as well and is clearly a more descriptive name. Second, the configuration file is very short. The bulk of the lines in Example 12-1 are comments; only the last five lines are really sendmail configuration commands. Third, the sendmail configuration commands are short with a relatively simple syntax.

The five active lines in the generic-linux.mc file are composed of four different macros. The VERSIONID

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The sample configuration created above uses several sendmail databases. (Here we use the term "database" loosely to include both real databases and flat files.) sendmail databases are an often overlooked component of sendmail configuration. Yet sendmail databases play an important role in sendmail configuration. It is in these databases, not in the m4 files or the sendmail.cf file, that day-to-day configuration changes are made. The sendmail databases used in our sample configuration are as follows:

aliases: The aliases database is included in the configuration by default. This database is an essential component in local mail delivery and in mail forwarding. Nothing needs to be added to the configuration to use the aliases database.
local-host-names: The local-host-names file is added to a configuration by the use_cw_file feature. This file is used to define which mail is accepted for local delivery.
relay-domains: The relay-domains file is included in the configuration by default. Therefore, no changes are needed in the sendmail configuration to use this file. The relay-domains file can authorize relaying, which, by default, is disabled.
genericstable: The genericstable feature adds support for this database. The genericstable is used to rewrite the email addresses an organization uses internally into the format it wishes to present to the outside world.
access

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Email is an essential service. It is also a service that can be exploited by intruders when it is misconfigured. It is very important that you thoroughly test your configuration. Fortunately, sendmail provides a relatively easy way of doing this.

sendmail supports an "address test" mode that allows a full range of tests. In the following examples we specify a destination mail address and a test to apply to that address. sendmail then processes that destination address displaying the output of each ruleset as it proceeds. To place sendmail into address test mode, invoke it with the -bt argument.

The default configuration file used for the address test mode is the /etc/mail/sendmail.cf file. To specify an alternate configuration file, use the -C argument. This is important because you will test a new configuration before moving it to /etc/mail/sendmail.cf. To test the sample Linux sendmail configuration created earlier in this chapter, use the following sendmail command:

# /usr/sbin/sendmail -bt -Cvstout.cf

ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)

Enter <ruleset> <address>

>

The > prompt shown above indicates that sendmail is ready to accept a test mode command. While in address test mode, sendmail accepts a variety of commands that examine the configuration, check settings, and observe how email addresses are process by sendmail. Table 12-4 lists the commands that are available in test mode.

Table 12-4: Sendmail test mode commands
Command	Usage
ruleset [,ruleset . . . ] address	Process the address through the comma-separated list of rulesets.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The sendmail daemon can be run in either of two ways. One way is to have to have it run from the inetd daemon; the alternative, and more commonly used method, is to run sendmail as a standalone daemon. It is also common for mailer programs to invoke sendmail as a user command to accept locally generated mail for delivery.

When running sendmail in standalone mode, place the sendmail command in a startup file so that it runs at boot time. The syntax used is commonly:

/usr/sbin/sendmail -bd -q10m

The -bd argument tells sendmail to run as a daemon. It will fork and run in the background. The -q10m argument tells sendmail to check its queue every ten minutes. You may choose to use a different time interval to check the queue.

To run sendmail from the inetd network daemon, you'd use an entry such as this:

smtp  stream  tcp nowait  nobody  /usr/sbin/sendmail -bs

The -bs argument here tells sendmail to use the SMTP protocol on stdin/stdout, which is required for use with inetd.

When sendmail is invoked this way, it processes any mail waiting in the queue to be transmitted. When running sendmail from inetd, you must also create a cron job that runs the runq command periodically to service the mail spool periodically. A suitable cron table entry would be similar to:

# Run the mail spool every fifteen minutes

0,15,30,45     *     *     *     *     /usr/bin/runq

In most installations sendmail processes the queue every 15 minutes as shown in our crontab example. This example uses the runq command. The runq command is usually a symlink to the sendmail binary and is a more convenient form of:

# sendmail 

            -q

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

There are a number of things you can do to make managing a sendmail site efficient. A number of management tools are provided in the sendmail package; let's look at the most important of these.

Mail is queued in the /var/spool/mqueue directory before being transmitted. This directory is called the mail spool. The sendmail program provides the mailq command as a means of displaying a formatted list of all spooled mail messages and their status. The /usr/bin/mailq command is a symbolic link to the sendmail executable and behaves identically to:

# sendmail 

               -bp

The output of the mailq command displays the message ID, its size, the time it was placed in the queue, who sent it, and a message indicating its current status. The following example shows a mail message stuck in the queue with a problem:

$ mailq

                Mail Queue (1 request)

--Q-ID-- --Size-- -----Q-Time----- ------------Sender/Recipient------------

RAA00275      124 Wed Dec  9 17:47 root

                 (host map: lookup (tao.linux.org.au): deferred)

                                   terry@tao.linux.org.au

This message is still in the mail queue because the destination host IP address could not be resolved.

To force sendmail to immediately process the queue, issue the /usr/bin/runq command. sendmail will process the mail queue in the background. The runq command produces no output, but a subsequent mailq command will tell you if the queue is clear.

If you use a temporary dial-up Internet connection with a fixed IP address and rely on an MX host to collect your mail while you are disconnected, you will find it useful to force the MX host to process its mail queue soon after you establish your connection.

A small perl program is included with the sendmail distribution that makes this simple for mail hosts that support it. The

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

sendmail is a complex topic—much too complex to be truly covered by a single chapter. This chapter should get you started and will help you configure a simple server. However, if you have a complex configuration or you want to explore advanced features, you will need more information. Here are some sources to start you on your quest for knowledge.

The sendmail distribution is delivered with some excellent README files. The README file in the top-level directory created when the distribution is installed is the place to start. It contains a list of other informational files, such as sendmail/README and cf/README, that provides essential information. (The cf/README file, which covers the sendmail configuration language, is also available on the Web at http://www.sendmail.org/m4/readme.html.)
The sendmail Installation and Operations Guide is an excellent source of information. It is also delivered with the sendmail source code distribution, and can be found in doc/op/op.me or doc/op/op.ps, depending on your preferred format.
The sendmail web site provides several excellent papers and online documents. The Compiling Sendmail documentation, available at http://www.sendmail.org/compiling.html, is an excellent example.
The sendmail site provides a list of available sendmail books at http://www.sendmail.org/books.html.
Formal sendmail training is available. Some training classes are listed at http://www.sendmail.org/classes.html.

Using these resources, you should be able to find out more about sendmail than you will ever need to know. Go exploring!

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

IPv4 space is becoming scarcer by the day. By 2005, some estimates place the number of worldwide Internet users at over one billion. Given the fact that many of those users will have a cellular phone, a home computer, and possibly a computer at work, the available IP address space becomes critically tight. China has recently requested IP addresses for each of their students, for a total of nearly 300 million addresses. Requests such as these, which cannot be filled, demonstrate this shortage. When IANA initially began allotting address space, the Internet was a small and little- known research network. There was very little demand for addresses and class A address space was freely allocated. However, as the size and importance of the Internet started to grow, the number of available addresses diminished, making obtaining a new IP difficult and much more expensive. NAT and CIDR are two separate responses to this scarcity. NAT is an individual solution allowing one site to funnel its users through a single IP address. CIDR allows for a more efficient division of network address block. Both solutions, however, have limitations.

With new electronic devices such as PDAs and cellular phones, which all need IP addresses of their own, the NAT address blocks suddenly do not seem quite as large.

Researchers, realizing the potential IP shortage, have redesigned the IPv4 protocol so that it supports 128-bits worth of address space. The selected 128-bit address space provides 340 trillion possible addresses, an exponential increase that we hope will provide adequate addressing into the near (and far) future. This is, in fact, enough addresses to provide every person on Earth with one billion addresses.

Not only does IPv6 solve some of the address space logistics, it also addresses some configuration and security issues. In this section, we'll take a look at the current solutions available with Linux and IPv6.

At the beginning, IANA gave requestors an entire class A network space thereby granting requestors 16.7 million addresses—many more than necessary. Realizing their error, they began to assign class B networks—again, providing far too many addresses for the average requestor. As the Internet grew, it quickly became clear that allocating class A and class B networks to every requestor did not make sense. Even their later action of assigning class C banks of addresses still squandered address space, as most companies didn't require 254 IP addresses. Since IANA could not revoke currently allocated address space, it became necessary to deal with the remaining space in a way that made sense. One of these ways was through the use of

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

At the beginning, IANA gave requestors an entire class A network space thereby granting requestors 16.7 million addresses—many more than necessary. Realizing their error, they began to assign class B networks—again, providing far too many addresses for the average requestor. As the Internet grew, it quickly became clear that allocating class A and class B networks to every requestor did not make sense. Even their later action of assigning class C banks of addresses still squandered address space, as most companies didn't require 254 IP addresses. Since IANA could not revoke currently allocated address space, it became necessary to deal with the remaining space in a way that made sense. One of these ways was through the use of Classless Inter-Domain Routing (CIDR).

CIDR allows network blocks to be allocated outside of the well-defined class A/B/C ranges. In an effort to get more mileage from existing class C network blocks, CIDR allows administrators to divide their address space into smaller units, which can then be allocated as individual networks. This made it easier to give IPs to more people because space could be allocated by need, rather than by predefined size-of-space. For example, a provider with a class C subnet could choose to divide this network into 32 individual networks, and would use the network addresses and subnet masks to delineate the boundaries. A sample CIDR notation looks like this:

10.10.0.64/29

In this example, the /29 denotes the subnet mask, which means that the first 29 bits of the address are the subnet. It could also be noted as 255.255.255.248, which gives this network a total of six usable addresses.

While CIDR does deal with the problem in a quick and easy way, it doesn't actually create more IP addresses, and it does have some additional disadvantages. First, its efficiency is compromised since each allocated network requires a broadcast IP and a network address IP. So if a provider breaks a class C block into 32 separate networks, a total of 64 individual IPs are wasted on network and broadcast IPs. Second, complicated CIDR networks are more prone to configuration errors. A router with an improper subnet mask can cause an outage for small networks it serves.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In order to combat the shrinking IP space problem, the concept of IPv6 was born. Future-minded designers chose to have 128 bits of address space, providing for a total of 340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4 1,038) addresses or, in more visual terms, 655,570,793,348,866,943,898,599 (6.5 1,023) addresses for every square meter of the earth's surface. This provides a sizable extension over the current 32-bits of address space under IPv4.

The first noticeable difference between IPv4 and IPv6 is how the addresses are written. A typical IPv6 address looks like:

fe80:0010:0000:0000:0000:0000:0000:0001

There are eight sets of four hex values in every IP address. These addresses can be long and cumbersome, which is why a shortening method was developed. A single string of zeroes can be replaced with the double colon. For example, the previous example could be written in shortened form as.

fe80:0010::1

However, this can be done only one time in an address in order to avoid ambiguity about what has been removed. Let us consider the following example IP which has separate strings of zeroes:

2001:0000:0000:a080:0000:0000:0000:0001

Since only one string of zeroes can be replaced, the IP can not be shortened to:

2001::a080::1

Generally, the longest string is shortened. In this example, with the longest set replaced, the shortened IP is:

2001:0000:0000:a080::1

Within IPv6, there are several different types of addresses that define the various functions available within the specification:

Link-local address: This address is automatically configured when the IPv6 stack is initialized using the MAC address from your network card. This kind of address is generally considered a client-only type of address, and would not be capable of running a server or listening for inbound connections. Link-local addresses always begin with

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

One of the most widely used software packages under Linux currently is the Apache web server. Starting in 1995 as small group of developers, the Apache Software foundation incorporated in 1999 to develop and support the Apache HTTP server. With a base of more than 25 million operational Internet web servers, Apache's HTTP server is known for its flexibility and performance benefits. In this section, we will explore the basics of building and configuring an Apache HTTP server and examine some options that will assist in the security and performance of its operation. In this chapter, we'll be looking at Apache v1.3, which is currently the most widely deployed and supported version.

Apache is in itself just a simple web server. It was designed with the goal of serving web pages. Some commercial web servers have tried to pack many different features into a web server product, but such combination products tend to be open to substantial numbers of security vulnerabilities. The simplicity and modular design of the Apache HTTPD server brings a more secure product, and its track record especially when compared to other web servers shows it to be a stable and robust product.

This is not to say that Apache servers are incapable of providing dynamic content to users. There are many Apache modules that can be integrated to provide an almost infinite number of new features. Add-on products, such as PHP and mod_perl, can be used to create powerful web applications and generate dynamic web content. This chapter, however, will concentrate on the configuration of Apache itself. Here, we will discuss how to build and configure an Apache HTTPD web server and look at the different options that can be used to build a stable and secure web server.

If your Linux distribution does not currently have Apache, the easiest way to get it is from one of the many Apache mirror sites. A list can be found at the main Apache Software Foundation site, http://www.apache.org

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Apache is in itself just a simple web server. It was designed with the goal of serving web pages. Some commercial web servers have tried to pack many different features into a web server product, but such combination products tend to be open to substantial numbers of security vulnerabilities. The simplicity and modular design of the Apache HTTPD server brings a more secure product, and its track record especially when compared to other web servers shows it to be a stable and robust product.

This is not to say that Apache servers are incapable of providing dynamic content to users. There are many Apache modules that can be integrated to provide an almost infinite number of new features. Add-on products, such as PHP and mod_perl, can be used to create powerful web applications and generate dynamic web content. This chapter, however, will concentrate on the configuration of Apache itself. Here, we will discuss how to build and configure an Apache HTTPD web server and look at the different options that can be used to build a stable and secure web server.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

If your Linux distribution does not currently have Apache, the easiest way to get it is from one of the many Apache mirror sites. A list can be found at the main Apache Software Foundation site, http://www.apache.org. At present, there are two branches of the Apache HTTPD version tree, 1.3 and 2.0. The new version tree, v2.0 offers new features and is being actively developed, but is more likely to be susceptible to bugs and vulnerabilities. In this chapter, we will be using the most recent version of the 1.3 branch because of its proven reliability and stability. Many of the configuration options, however, are similar in both versions.

You have the option of obtaining Apache in either source format or package format. If you are installing from package, you will not have the same amount of initial configuration flexibility as you would building from source. Packages generally come with the most common options pre-built into the binaries. If you are looking for specific features or options or if you want to build a very minimal version of the server, you should consider building from source.

Building Apache from source is similar to building other Linux source packages and follows the "configure-make-make install" path. Apache has many options that need to be set at source configuration time. Among these is the ability to select the modules which you would like to build or have disabled. Modules are a great way to add or remove functionality to your web server and cover a wide range of functions—from performance to authentication and security. Table 14-1 shows a sample list taken from the Apache documentation of a number of the available modules.

Table 14-1: Apache modules
Type	Enabled or disabled by default

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

When the Apache software has been installed in the directory you have selected, you are ready to begin configuration of the server. Earlier versions of the Apache server used multiple configuration files. However, now only the httpd.conf file is required. It is still quite handy to have multiple configuration files (for example, to make version upgrades easier). The include option will allow you to read additional configuration files from the main httpd.conf file.

Apache comes with a default configuration file that has the most common options set. If you are in a hurry to have your server running, this default configuration should cover the requirements to launch Apache. While functional, this configuration is not acceptable to many administrators. To begin fine-tuning the configuration, the first option most administrators choose is selecting the IP address and port information of the server.

Listen and BindAddress are the first two options that you may want to change.

# Listen: Allows you to bind Apache to specific IP addresses and/or

# ports, instead of the default. See also the <VirtualHost>

# directive.

#

#Listen 3000

Listen 172.16.0.4:80

This configuration change enables the Apache server to listen only on the specified interface and port. You can also use the BindAddress option to specify the IP address to which the server will bind. With this option, you are only specifying the IP address, not the port as above.

# BindAddress: You can support virtual hosts with this option. This directive

# is used to tell the server which IP address to listen to. It can either

# contain "*", an IP address, or a fully qualified Internet domain name.

# See also the <VirtualHost> and Listen directives.

#

BindAddress 172.16.0.4

When building Apache, you may have specified the installation directory. If so, the installation has automatically set the paths for your server root documents and all of your logfiles. If you need to change this, the following options will be useful:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

One of the more powerful features of Apache is the ability to run multiple web servers on one machine. This functionality is accomplished using the VirtualHost functionality found within the httpd.conf file. There are two types of virtual hosts that can be configured—named virtual hosts and IP virtual hosts. With named virtual hosts, you can host multiple TLDs on a single IP, while with IP virtual hosting, you can host only one virtual host per IP address. In this section, we will give examples of each, and list some common configuration options.

For those who have only one site to host or have multiple IPs for all sites they wish to run, IP-based virtual hosting is the best configuration choice. Consider the following example where the Virtual Brewery decides to host a web site for its Virtual Vineyard. The following is the minimum amount of configuration that would need to be added to the httpd.conf file in order to create the new web site.

Listen www.virtualvineyard.com>:80

.

.

<VirtualHost www.virtualvineyard.com>

ServerAdmin webmaster@vbrew.com

DocumentRoot /home/www/virtualvineyard.com

ServerName www.virtualvineyard.com

ErrorLog /var/www/logs/vvineyard.error_log

TransferLog /var/www/logs/vvineyard.access_log

</VirtualHost>

You would also want to make sure that www.virtualvinyard.com was added to your /etc/hosts file. This is done because Apache will need to look up an IP address for this domain when it starts. You can rely entirely on your DNS, but should your DNS server be unavailable for some reason when the web server restarts, your web server will fail. Alternately, you can hardcode the IP address of your server at the beginning of the configuration in the <VirtualHost> tag. Doing so may seem more efficient, however, should you wish to change your web server IP address, it will require changing your Apache configuration file.

In addition to the configuration options listed in the example, any of the options discussed earlier in the chapter can be added to the VirtualHost groups. This provides you with maximum flexibility for each of your separate web servers.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

After having configured and tested your Apache web server configuration, the next thing you may wish to do is configure an SSL page. From protecting web-based email clients, to providing secure e-commerce transactions, there are many reasons why one would use SSL. Within the Apache realm there are two options for providing SSL, Apache-SSL and mod_ssl. In this section, we'll focus on the older and more commonly used mod_ssl.

As with any SSL-based application, certificates are required. These provide the basis on which the trust relationship between client and server is established. This being said, if you are hosting a site for a business, you will likely want to get a certificate signed by a third party, such as Verisign or Thawte. Since these certificates are somewhat costly, if you aren't hosting a business, you also have the option of generating your own certificate. The disadvantage of this method is that when clients access your site, an error will be generated telling them that your certificate is not trusted since it hasn't been signed by a third party. This means that they will be required to click through the error message and decide whether or not they want to trust your certificate. In this chapter we will provide configuration examples for administrators generating their own certificates. Alternately, the cacert.org organization offers free certificates for individuals.

In order to enable an SSL session, you will first need to create a certificate. To do this, you will need to make sure you have OpenSSL installed. It can be found at http://www.openssl.org, in both source and binary package format. This package comes installed with many Linux distributions, so you may not have to install it. Once you have installed or verified the installation of OpenSSL, you can proceed to create the required SSL certificate.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

As complex as Apache configurations can be, it's not unlikely that there will be problems. This section will address some common errors and resolutions to those problems.

Fortunately for administrators, Apache comes with a configuration checker, which will test changes made to the configuration before bringing down an operational server. If it finds any errors, it will provide you with some diagnostic information. Consider the following example:

vlager # ../bin/apachectl configtest

Syntax error on line 985 of /var/www/conf/httpd.conf:

Invalid command 'SSLEgine', perhaps mis-spelled or defined by a module not included 

in the server configuration

The configuration testing tool has found an error on line 985, and it appears that the SSLEngine directive was spelled incorrectly. This configuration checker will catch any syntactical errors, which certainly helps. Administrators should always run this before stopping and restarting their servers.

The configtest option won't solve all of your problems, however. Transposed digits in an IP, a misspelled domain name, or commented out requirements will all pass the test, but cause problems for the operational server.

This is a very general error, and a variety of circumstances can cause it. This is Apache's way of telling you that it can't find or read the page. If you are getting an error of this nature, first check all of your paths. Remember with Apache, you are operating within a virtual directory environment. If you have links to files outside of this structure, it is likely that the server will not be able to server them. Additionally, you should verify the permissions of the files and make sure that the user who owns the web server process can read them. Files owned by root, or any other user, set to mode 700 (read/write/execute user) may cause the server to fail, since it will be unable to read them.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Internet Message Access Protocol (IMAP) was developed from a need for mobile email access. Many workers read mail from a variety of locations (the office, home, hotel rooms, and so on) and want such flexible features as the ability to download headers first and then selectively download mail messages. The main mail delivery protocols before IMAP, for the Internet, was POP, which offers more rudimentary mail delivery-only functionality

With IMAP, traveling users can access their email from anywhere and download it or leave it on the server as desired. POP, on the other hand, does not work well when users access email from many different machines; users end up with their email distributed across many different email clients. IMAP provides users with the ability to remotely manage multiple email boxes, and store or search as well as archive old messages.

IMAP, fully documented in RFC 3501, was designed to provide a robust, mobile mail delivery and access mechanism. For more detail on the protocol and how it functions on the network layer, or for additional information on the numerous specification options, please consult the RFC documentation.

POP and IMAP tend to be grouped together or compared, which is a bit unfair since they are dissimilar in many ways. POP was created as a simple mail delivery vehicle, which it does very well. Users connect to the server and obtain their messages, which are then, ideally, deleted from the server. IMAP takes an entirely different approach. It acts as the keeper of the messages and provides a framework in which the users can efficiently manipulate the stored messages. While administrators and users can configure POP to store the messages on the server, it can quickly become inefficient since a POP client will download all old messages each time the mail is queried. This can get messy quickly, if the user is receiving any quantity of email. For users who do not need any kind of portability, or receive little email, POP is probably an acceptable choice, but those seeking greater functionality will want to use IMAP.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

IMAP, fully documented in RFC 3501, was designed to provide a robust, mobile mail delivery and access mechanism. For more detail on the protocol and how it functions on the network layer, or for additional information on the numerous specification options, please consult the RFC documentation.

POP and IMAP tend to be grouped together or compared, which is a bit unfair since they are dissimilar in many ways. POP was created as a simple mail delivery vehicle, which it does very well. Users connect to the server and obtain their messages, which are then, ideally, deleted from the server. IMAP takes an entirely different approach. It acts as the keeper of the messages and provides a framework in which the users can efficiently manipulate the stored messages. While administrators and users can configure POP to store the messages on the server, it can quickly become inefficient since a POP client will download all old messages each time the mail is queried. This can get messy quickly, if the user is receiving any quantity of email. For users who do not need any kind of portability, or receive little email, POP is probably an acceptable choice, but those seeking greater functionality will want to use IMAP.

Once you've decided that IMAP is for you, there are two primary options. The two main flavors are Cyrus IMAP and the University of Washington IMAP server. Both follow the RFC specification for IMAP and have their advantages and disadvantages. They also use different mailbox formats and therefore cannot be mixed. One key difference between the two is found in Cyrus IMAP. It does not use /etc/passwd for its mail account database, so the administrator does not have to specially add mail users to the system password file. This is more secure option for system administrators, because creating accounts on systems can be construed as a security risk. However, the ease of configuration and installation of UW IMAP often makes it more appealing. In this chapter, we'll primarily focus on the two most common IMAP servers: UW IMAP, because of its popularity and ease of installation, and Cyrus IMAP, because of its additional security features.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Another option IMAP administrators have is the product from CMU called Cyrus. It is similar to UW IMAP as far as general functionality goes—from the user standpoint, there will be little difference. The majority of the differences come on the administrative side. This is also where its benefits can be seen.

The Cyrus software can be obtained in a number of places, but the most reliable choice, with the latest source releases, will be the central CMU Cyrus distribution site, http://asg.web.cmu.edu/cyrus/download/. Here, both current and previous releases can be downloaded. The availability of previous releases could be an advantage for sites with polices against using the most recent versions of software.

To begin the installation of the Cyrus server, download and decompress the latest version. You will need to download both the IMAP and SASL packages.

SASL is the authentication mechanism used by Cyrus IMAP, and will need to be configured and installed first. It is easily built using the standard "configure-make" order.

vlager# cd cyrus-sasl-2.1.15

vlager# ./configure

loading cache ./config.cache

checking host system type... i686-pc-linux-gnu

.

creating saslauthd.h

Configuration Complete. Type 'make' to build.

vlager# make

make  all-recursive

make[1]: Entering directory `/tmp/cyrus-sasl-2.1.15'

Assuming the compile is completed without failure and you've successfully executed the make install, you can now proceed to configuring and installing the Cyrus IMAP server itself.

After decompressing the Cyrus IMAP source, prepare the configuration using the following command:

vlager# ./configure --with-auth=unix

This will prepare Cyrus IMAP to use the Unix passwd/shadow files for user authentication. It is also possible to enable Kerberos for authentication at this point.

Next, you will need to create all of the dependency files, and then build and install the package:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The presence of Microsoft Windows machines in the network environment is often unavoidable for the Linux network administrator, and often interoperability is critical. Fortunately, a group of developers has been hard at work for the last 10 years, and has created one of the most advanced Windows-to-UNIX interoperability packages—Samba. It has, in fact, become so successful and practical that system administrators can completely replace Windows servers with Samba servers, keeping all functionality, while adding additional stability.

Samba, still actively developed in order to maintain feature compatibility with the ever-changing Microsoft software, provides a framework to allow Linux machines to access Windows network resources, such as shared drives and printers. Samba not only lets Linux machines access these services, but also allows Linux to offer these same services to Windows machines. With Samba, it's possible to completely replace a Windows-based file server, a Windows print server, and even, with advanced options, replace the Primary Domain Controller (PDC). Recent versions of Samba even allow Active Directory compatibility. The open-source flexibility of Samba means that development will be able to continue, and new features will be introduced when the Windows architecture changes. More information on Samba can be found in Using Samba, Second Edition (O'Reilly), by Jay Ts, Robert Eckstein, and David Collier-Brown.

The underlying technology used in Samba is based on Server Message Blocks (SMB), which was originally developed in the early 80s by Dr. Barry Feigenbaum while he was working at IBM. Initially, IBM was actively involved with the development, but Microsoft soon took charge and heavily continued the development work. In later years, Microsoft renamed the SMB protocol to

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Samba, still actively developed in order to maintain feature compatibility with the ever-changing Microsoft software, provides a framework to allow Linux machines to access Windows network resources, such as shared drives and printers. Samba not only lets Linux machines access these services, but also allows Linux to offer these same services to Windows machines. With Samba, it's possible to completely replace a Windows-based file server, a Windows print server, and even, with advanced options, replace the Primary Domain Controller (PDC). Recent versions of Samba even allow Active Directory compatibility. The open-source flexibility of Samba means that development will be able to continue, and new features will be introduced when the Windows architecture changes. More information on Samba can be found in Using Samba, Second Edition (O'Reilly), by Jay Ts, Robert Eckstein, and David Collier-Brown.

The underlying technology used in Samba is based on Server Message Blocks (SMB), which was originally developed in the early 80s by Dr. Barry Feigenbaum while he was working at IBM. Initially, IBM was actively involved with the development, but Microsoft soon took charge and heavily continued the development work. In later years, Microsoft renamed the SMB protocol to Common Internet File System (CIFS), by which it is now known. One sees the terms used interchangeably.

There is little accurate and official documentation about how CIFS functions. Unlike most other network protocols, there is no official RFC documentation, though Microsoft did submit specifications to the IETF in the 1990s that expired due to numerous inaccuracies and inconsistencies. Newer documentation attempts by Microsoft have not been as helpful to the Samba development group, due to the licensing restrictions place upon it as well as a general lack of new information.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

OpenLDAP is a freely available, open source LDAP solution designed to compile on a number of different platforms. Under Linux, it is currently the most widely used and best supported free LDAP product available. It offers the performance and expected functionality of many commercial solutions, but offers additional flexibility because the source is available and customizable. In this section, we will discuss possible uses for an OpenLDAP server as well as describe installation and configuration.

Before proceeding, a brief explanation of LDAP is required. Lightweight Directory Access Protocol (LDAP) is a directory service that can be used to store almost anything. In this way, it is very similar to a database. However, it is designed to store only small amounts of data, and is optimized for quick searching of records. A perfect example of an application for which LDAP is suited is a PKI environment. This type of environment stores only minimal amount of information and is designed to be accessed quickly.

The easiest way to explain the structure of LDAP is to imagine it as a tree. Each LDAP directory starts with a root entry. From this entry others branch out, and from each of these branches are more branches, each with the ability to store a bit of information. A sample LDAP tree is shown in Figure 17-1.

Figure 17-1: Sample LDAP tree.

Another critical difference between LDAP and regular databases is that LDAP is designed for interoperability. LDAP uses predefined schemas, or sets of data that map out specific trees. The X.500 structure is outlined by RFC 2253 and contains the following entries:

String X.500 AttributeType
------------------------------
CN commonName

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Before proceeding, a brief explanation of LDAP is required. Lightweight Directory Access Protocol (LDAP) is a directory service that can be used to store almost anything. In this way, it is very similar to a database. However, it is designed to store only small amounts of data, and is optimized for quick searching of records. A perfect example of an application for which LDAP is suited is a PKI environment. This type of environment stores only minimal amount of information and is designed to be accessed quickly.

The easiest way to explain the structure of LDAP is to imagine it as a tree. Each LDAP directory starts with a root entry. From this entry others branch out, and from each of these branches are more branches, each with the ability to store a bit of information. A sample LDAP tree is shown in Figure 17-1.

Figure 17-1: Sample LDAP tree.

Another critical difference between LDAP and regular databases is that LDAP is designed for interoperability. LDAP uses predefined schemas, or sets of data that map out specific trees. The X.500 structure is outlined by RFC 2253 and contains the following entries:

String X.500 AttributeType
------------------------------
CN commonName
L localityName
ST stateOrProvinceName
O organizationName
OU organizationalUnitName
C countryName
STREET streetAddress
DC domainComponent
UID userid

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The current home of OpenLDAP is http://www.openldap.org. All current stable and beta versions can be acquired from this site along with an "Issue Tracking" engine, should you encounter any bugs that you wish to report.

While the temptation of downloading and using beta versions is always there, because of the promise of increased functionality, unless you are installing the software on a test server, it is best to use only known stable versions.

Having downloaded and extracted the source archive, it is generally a good idea to briefly review any README files that may be contained within the archive. The five minutes spent reading these files can save five times the initial time investment should there be any problems during install.

Like many software packages, OpenLDAP is not without its dependencies. With OpenLDAP, you will need to have the latest version of OpenSSL installed and configured. If you do not yet have this package, it can be found at http://www.openssl.org, along with installation instructions.

SASL from Cyrus is also required for OpenLDAP. As defined by its name, Simple Authentication and Security Layer (SASL) provides an easy-to-use security framework. Many Linux distributions have this package installed by default; however, should you need to install this yourself, it can be found at http://asg.web.cmu.edu/sasl/sasl-library.html or by using a package search engine such as RPMfind.

OpenLDAP supports Kerberos as an option rather than a requirement. If you are currently using Kerberos in your environment, you will want to make sure that you have it installed on your OpenLDAP server machine. If you're not currently using Kerberos, it may not be of great value to enable it especially for OpenLDAP. There is a great deal of Kerberos information available on which you can base your decision as to whether or not to enable it.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Wireless networking is a promising and increasingly popular technology, offering a wide range of benefits compared to traditional wired technology. These advantages range from increased convenience to users and decreased deployment cost to ease of network installation. A new wireless deployment can save substantial amounts of money since there is no need for additional cables, jacks, or network switches. Adding new users to a network can be as easy as plugging in a wireless card and powering up a machine. Wireless networking has also been used to deliver network access to areas where there is little or no traditional network infrastructure.

Perhaps the biggest impact of wireless networking can be seen within its widespread acceptance among consumers. The most obvious example of this popularity can be seen with new laptop systems, where nearly every unit is shipped with integrated 802.11b or g. The practical benefits have consequently insured good sales, allowing manufacturers to lower the equipment costs. At the time of this writing, the price of client wireless cards is comparable to that of traditional Ethernet adapter cards.

These benefits, however, do not come without some disadvantages, the most severe of these being the security issues.

Wireless LANs are based on spread spectrum technology, initially developed for military communications by the U.S. Army during World War II. Military technicians considered spread spectrum desirable because it was more resistant to jamming. Other advances at this time allowed an increase in the radio data rate. After 1945, commercial enterprises began to expand on this technology, realizing its potential benefits to consumers.

Spread spectrum technology evolved into the beginnings of the modern wireless LAN in 1971 with a University of Hawaii project called AlohNet. This project allowed seven computers around the various islands to communicate bidirectionally with a central hub on Oahu.

The university research on AlohNet paved the way for the first generation of modern wireless networking gear, which operated at the 901-928 MHz frequency range. Primarily used by the military, this phase of wireless development saw only limited consumer use, due to crowding within this frequency and the relatively low speed.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Wireless LANs are based on spread spectrum technology, initially developed for military communications by the U.S. Army during World War II. Military technicians considered spread spectrum desirable because it was more resistant to jamming. Other advances at this time allowed an increase in the radio data rate. After 1945, commercial enterprises began to expand on this technology, realizing its potential benefits to consumers.

Spread spectrum technology evolved into the beginnings of the modern wireless LAN in 1971 with a University of Hawaii project called AlohNet. This project allowed seven computers around the various islands to communicate bidirectionally with a central hub on Oahu.

The university research on AlohNet paved the way for the first generation of modern wireless networking gear, which operated at the 901-928 MHz frequency range. Primarily used by the military, this phase of wireless development saw only limited consumer use, due to crowding within this frequency and the relatively low speed.

From this point, the 2.4 GHz frequency was defined for unlicensed use, so wireless technology began to emerge in this range and the 802.11 specification was established. This specification evolved into the widely accepted 802.11b standard, and continues to evolve into faster, more secure implementations of the technology.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The standards based around wireless networking for PCs are established by the Institute of Electrical and Electronics Engineers (IEEE). LAN/MAN technology has been broadly assigned number 802, which is then broken down into working groups. Some of the most active wireless working groups include 802.15, designed for wireless personal area networks (Bluetooth), 802.16 which defines support for broadband wireless systems, and finally, 802.11, assigned to wireless LAN technology. Within the 802.11 definition, there are more specific definitions that are assigned letters. Here is a list of the most important 802.11 wireless LAN definitions:

802.11a: This definition provides wireless access on the 5 GHz band. It offers speeds of up to 54 MBps, but has not caught on, perhaps due to relatively higher priced equipment and short range.
802.11b: This is still the standard to which most people refer when talking about wireless networking. It establishes 11 MBps speeds on the 2.4 GHz band, and can have a range extending more than 500 meters.
802.11g: This standard has been established to provide higher data rates within the 2.4 GHz band and provides added security with the introduction of WiFi Protected Access, or WPA. 802.11g devices are now being deployed in place of 802.11b devices and have nearly reached mainstream acceptance.
802.11i: While still in the development phase, this standard seeks to resolve many of the security issues that have plagued 802.11b and provide a more robust system of authentication and encryption. At the time of this writing, the specification has not been finalized.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

When the IEEE created the 802.11b standard, they realized that the open nature of wireless networking required some kind of data integrity and protection mechanism and thus created Wired Equivalent Privacy (WEP). Promised by the standard to provide encryption at the 128-bit level, users were supposed to be able to enjoy the same levels of privacy found on a traditional wired network.

Hopes for this kind of security, however, were quickly dashed. In a paper called "Weaknesses in the Key Scheduling Algorithm of RC4" by Scott Fluhrer, Itsik Mantin, and Adi Shamir, the weaknesses in the key generation and implementation of WEP were described in great detail. Although this development was a theoretical attack when the paper was written, a student at Rice University, Adam Stubblefield, brought it into reality and created the first WEP attack. Although he has never made his tools public, there are now many similar tools for Linux that will allow attackers to break WEP, making it an untrustworthy security tool.

Still, it should be acknowledged that staging a WEP attack requires a considerable amount of time. The success of the attack relies upon the amount of encrypted data the attacker has captured. Tools such as AirSnort require approximately 5 to 10 million encrypted packets. A busy wireless LAN, which is constantly seeing the maximum amount of traffic, can still take as long as 10 hours to crack. Since most networks do not run at capacity for this long, it can be expected that the attack would take considerably longer, stretching out to a few days for smaller networks.

However, for true protection from malicious behavior and eavesdropping, a VPN technology should be used, and wireless networks should never be directly connected to internal, trusted networks.

Different manufacturers use a slightly different architecture to provide 802.11b functionality. There are two major chipset manufacturers, Hermes and Prism, and within each, hardware manufacturers have made modifications to increase security or speed. For example, the USRobotics equipment, based on the Prism chipset, now offers 802.11b at 22 MBps, but it will not operate at these speeds without the DLink 802.11b 22 MBps hardware. However, they are interoperable at the 11 MBps speed.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Throughout this book we've used the following example that is a little less complex than Groucho Marx University and may be closer to the tasks you will actually encounter.

The Virtual Brewery is a small company that brews, as the name suggests, virtual beer. To manage their business more efficiently, the virtual brewers want to network their computers, which all happen to be PCs running the brightest and shiniest production Linux kernel. Figure A-1 shows the network configuration.

On the same floor, just across the hall, there's the Virtual Winery, which works closely with the brewery. The vintners run an Ethernet of their own. Quite naturally, the two companies want to link their networks once they are operational. As a first step, they want to set up a gateway host that forwards datagrams between the two subnets. Later, they also want to have a UUCP link to the outside world, through which they exchange mail and news. In the long run, they also want to set up PPP connections to connect to offsite locations and to the Internet.

The Virtual Brewery and the Virtual Winery each have a class C subnet of the Brewery's class B network, and gateway to each other via the host vlager, which also supports the UUCP connection. Figure A-2 shows the configuration.

Figure A-1:The Virtual Brewery and Virtual Winery subnets

Figure A-2:The Virtual Brewery Network

Section A.1: Connecting the Virtual Subsidiary Network

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The Virtual Brewery grows and opens a branch in another city. The subsidiary runs an Ethernet of its own using the IP network number 172.16.3.0, which is subnet 3 of the Brewery's class B network. The host vlager acts as the gateway for the Brewery network and will support the PPP link; its peer at the new branch is called vbourbon and has an IP address of 172.16.3.1. This network is illustrated in Figure A-2.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsverzeichnis

Themen

Buchreihen

Special Interest

International Sites