UNIX: The Complete Reference (2007)

Part IV: Network Administration

Chapter 17: Network Administration

Although a computer running the UNIX System is quite useful by itself, it is only when it is connected with other systems that the full capabilities of the system are realized. Earlier chapters have described how to use the many communications and networking capabilities of UNIX. These network capabilities include programs for electronic mail such as sendmail as well as TCP/IP utilities for remote login, remote execution, terminal emulation, and file transfer. They also include NFS (Network File System) and the associated management structure, NIS (Network Information Services).

In this chapter, you will learn how to administer your system so that it can connect with other systems to take advantage of these networking capabilities. You will learn how to manage and maintain these connections and how to customize many network applications. Also, you will learn about facilities for providing security for networking, as well as potential security problems. The secure shell, which is a replacement for the Berkeley Remote Commands, is discussed in Chapter 9.

You will also learn about, and how to administer, the TCP/IP system, the sendmail mail application, DNS (Domain Name Service), and NFS (Network File System). We will discuss some network performance concepts and what tools exist to enhance performance or correct performance problems. Finally, we will briefly discuss web-based network issues, including routing, firewalls (and firewall security), and proxy servers.

Network Administration Concepts

You must understand many aspects of network administration to ensure that your network runs well, and that you can provide needed network services to your users. One aspect of network administration is the installation, operation, and management of TCP/IP networking. Before you can manage a network, you must install and set up the Internet utilities that provide TCP/IP networking services. You must also obtain an Internet address to identify your machine to other machines on your network. You need to find out how to configure your system to allow remote users to transfer files from your system using anonymous FTP. You also need to learn some tools for troubleshooting TCP/IP networking problems.

Administering the mail system is another important aspect of networking administration. You must learn how to administer the sendmail mail environment to customize the way your system sends and receives mail (use of e-mail systems is described in Chapter 8). You should also know how to use the Simple Mail Transfer Protocol (SMTP), part of the Internet Protocol Suite, to send mail. You need to learn how to control to whom mail may be sent (Chapter 10 discusses sending and receiving mail over the Internet).

Installing, setting up, configuring, and maintaining distributed file systems is also an important part of UNIX network administration. You need to understand administering the distributed file systems supported by UNIX. You need to learn how to install and set up the Network File System (NFS) to manage common resources used by your entire network, as well as the Distributed File System (DFS) to manage select portions of it.

UUCP system administration is also a network administration topic. It is covered in depth on the companion web site, http://www.osborne.com/unixtcr/webcomp.htm.

TCP/IP Administration

TCP/IP is one of the most common networks used for connecting UNIX System computers. TCP/IP networking utilities are part of UNIX. Many networking facilities such as the Mail System and NFS can use a TCP/IP network to communicate with other machines. (Such a network is required to run the Berkeley remote commands and the DARPA commands discussed in Chapter 9.)

This chapter will discuss what is needed to get your TCP/IP network up and running. You will need to

1. Obtain an Internet address.

2. Install the Internet utilities on your system.

3. Configure the network for TCP/IP.

4. Configure the TCP/IP startup scripts.

5. Identify other machines to your system.

6. Configure the STREAMS listener database.

7. Start running TCP/IP.

Once you have TCP/IP running, you need to administer, operate, and maintain your network. Some areas you may be concerned with will also be addressed, including

§ Security administration

§ Troubleshooting

§ Some advanced features available with TCP/IP

Internet Addresses

You need to establish the Internet address you will be using on your machine before you begin the installation of the Internet utilities. If you are joining an existing network, this address is usually assigned to you. If you are starting your own network, you need to obtain a network number and assign Internet addresses to all your hosts.

Internet addresses permit routing between computers to be done efficiently, much as telephone numbers are used to efficiently route calls. Area codes define a large number of telephone exchanges in a given area; exchanges define a group of numbers, which in turn define the phone on your desk. If you call within your own exchange, the call need only go as far as the telephone company office in your neighborhood that connects you to the number you are calling. If you call within your area code, the call need only go to the switching office at that level. Only if you call out of your area code is switching done between switching offices. This reduces the level of traffic, since most connections tend to stay within a small area. It also helps to quickly route calls.

The Format of Internet Addresses

The Internet has long been run on Version 4 of the Internet Protocol, or IPv4, for short. In IPv4, Internet addresses are 32 bits, separated into four 8-bit fields (each field is called an octet), separated by periods. Each field can have a value in the range of 0–255. The Internet address is made of a network address followed by a host address. (Version 6 of the Internet Protocol, IPv6, may eventually replace IPv4. In IPv6, Internet addresses have a different form that supports many more addresses.)

Obtaining IP Addresses

The Internet Corporation for Assigned Names and Numbers (ICANN) manages and coordinates the Domain Name System (discussed in depth later in this chapter). This system ensures that every Internet address used anywhere in the world is unique. Furthermore, it ensures that every user on the Internet is able to locate all valid addresses and every domain name is mapped to the correct IP address. If you want to register a new domain name for your company or organization and obtain a block of IP addresses, you need to register this domain name with one of many different domain name registrars, each accredited by ICANN. (You can find a list of accredited registrars at http://www.internic.net/regist.html.) Of course, your new domain name cannot be the same as one already taken by another organization. The domain name registrar you contact will be able to tell you if you have selected an available domain name and will be able to help you find a unique domain name if you have trouble finding one not already taken.

Once you have selected your new domain name, the registrar you select will ask you to submit contact and technical information and will give you a registration contract specifying the terms under which your registration is accepted and maintained. The registrar submits the appropriate information about your domain name and the Internet address or addresses associated with that name to the appropriate Network Information Center (NIC). The NIC maintains a database keeping track of which domain name corresponds to which IP address in the domain name service. This information can then become available to other computers throughout the world through the Domain Name Service (DNS). You will also be required to enter a registration contract with the registrar, which sets forth the terms under which your registration is accepted and will be maintained.

If you only need an IP address for your particular computer, or you have a small organization and do not want to register a domain name yourself, your Internet service provider (ISP) can obtain an IP address for you and assign you a domain name that is a subdomain of its own domain.

Network Addresses

In IPv4, the network of each Internet domain is assigned a class, or level of service. Depending on the size of the domain, that is, the number of Internet addresses it supports, a network may be of class A, B, or C. The network addresses of Class A networks consist of one field, with the remaining three fields used for host addresses. Consequently Class A networks can have as many as 16,777,216 (256×256×256) hosts. The first field of a Class A network is, by definition, in the range 1–126. Any network addresses that start with 127 are loopback addresses. A loopback address is used to test your computer’s connectivity capability and tell you if your network is set up correctly The official site for loopback testing is at 127.0.0.1.

The network addresses of Class B networks consist of two fields, with the remaining two fields used for host addresses. Consequently, Class B networks can have no more than 65,536 (256×256) hosts. The first field of a Class B network is, by definition, in the range 128–191.

The network addresses of Class C networks consist of three fields, with one field used for host addresses. Consequently, Class C networks can have no more than 256 hosts. As you can see, Class A addresses allow many hosts on a small number of networks, Class B addresses allow more networks and fewer hosts, and Class C addresses allow very few hosts and many networks. The first field of a Class C network is, by definition, in the range 192–254.

Although all Internet addresses currently follow this structure, work is proceeding in the IETF (Internet Engineering Task Force) standards group to move to a new hierarchy scheme called IPv6 (Internet Protocol Version 6). You can find more about this protocol at http://www.ipv6.com/. Many vendors are involved in deploying this architecture to their networks and hardware devices, but they are doing so slowly to maintain compatibility with existing systems. An international test bed backbone for IPv6 (called 6bone) is dedicated to aiding the deployment of IPv6 worldwide. It is on the web at http://www.6bone.net/.

Host Addresses

After you have received a network address, you can assign Internet addresses to the hosts on your network. Because most public networks are Class C networks, it is assumed that your network is in this class. For a Class C network, you use the last field to assign each machine on your network a host address. For instance, if your network has been assigned the address 192.11.105 by an authorized agent such as NSI or one of the newer authorizing agents, you use these first three fields and assign the fourth field to your machines. You may use the first valid number, 1, in the fourth field for the first machine to be added to your network, which gives this machine the Internet address 192.11.105.1. As you add machines to your network, you change only the last number. Your other machines will have addresses 192.11.105.2, 192.11.105.3, 192.11.105.4, and so on.

Each of the network classes (A, B, and C) uses the concept of a netmask to define which part of the IP address is the network address and which part is the actual host ID. For example, a Class B network has a default mask of 255.255.0.0. The fields containing the O’s are what define your host, and the others (the first two fields) mask the network ID portion. For example, 135.18.64.100 has a network address portion of 135.18 and a host ID portion of 64.100. The Class A default is 255.0.0.0, and the Class C default mask is 255.255.255.0. You may not have access to all of the addresses within the portion that is normally reserved for the host ID, though. With the ever-increasing demand for Internet addresses for host machines, the pool of numbers is decreasing. Some ISPs use a portion of what would normally be the host ID area for the network. For instance, in a Class C network, the ISP may use a netmask that is not on an 8-bit boundary, such as 192.11.105.192, which has a 26-bit netmask. This leaves only 62 possible IP addresses for hosts on this particular network. Table 17–1 shows how the classes and netmasks relate, and shows some sample host IP addresses for each class.

Installing and Setting Up TCP/IP

You most likely already have TCP/IP installed on your system if you are running a UNIX variant, but if not, you can install the TCP/IP system on your computer, for instance, using pkgadd. You will need to know the Internet address for your machine and the network that your machine will be part of. The installation procedure prompts you for both of these as it does a basic setup of some of the configuration files.

There may be other dependencies for this package to be installed, so check the documentation that comes with the Internet utilities to be sure that you have everything else that you need. The use of pkgadd is described in Chapter 13.

Network Provider Setup

TCP/IP requires a network provider to communicate with other machines. This network provider can be a high-speed LAN such as Ethernet, or it can be a WAN that communicates via dial-up lines to remote machines and networks. Whichever network provider you use will need to be configured using netcfg (the root program for configuring and managing network interfaces) or ifconfig (configures a network interface).

Your hardware provider may have also supplied a network interface card for your particular configuration. In either situation, consult the documentation that came with your network interface hardware or TCP/IP package for more information on setting up the network provider.

Configuring the Network Interface Card

You use the ifconfig utility to set up your NIC (network interface card), sometimes called an Ethernet card. For example, if you want to configure a 3COM 3C509 card (device e130) on an HP-UX system to be at address 135.16.88.37 on a default net mask and a default broadcast mask f or that network, you would enter

#ifconfig e130 135.16.88.37

For a Linux system, the first Ethernet device is defined as eih0, regardless of the NIC used. The equivalent command would be

#ifconfig eth0 135.16.88.37

Solaris uses le0 as the first Ethernet device for 10 Mb Ethernet NICs, so its equivalent command would be

#ifconfig le0 135.16.88.37

(Note that Solaris uses eri0 for newer 10/100 Mb Ethernet devices and hme0 for the older Ultra 10/100 Mb Ethernet devices.) This would also set the netmask address to its default (255.255.0.0) and the broadcast address to its default (here, 135.16.255.255, since the address is on the 135.16 network). Note that in Solaris, to configure the NIC without having to reboot, where you have previously installed the hardware, you need to initialize, or plumb, the network card using the command

#ifconfig le0 plumb

If you already have an entry in your /etc/hosts file that maps the hostname to the IP address (see the next section), you can use it instead of the IP address. For example, if the previous machine with IP address 135.16.88.97 had the hostname bumble, you would type

#ifconfig devname bumble

where devname is the associated device name for your Ethernet card, as seen in the previous examples (such as e130, eth0, or le0).

The hosts File

To get TCP/IP working on other machines, you must first define the machines that you would like to talk to in the file /etc/hosts. This file contains an entry on a separate line for each machine you want to communicate with. Before you add any hosts, there will already be some entries in this file that are used to do loopback testing. You should add the new machines to the bottom of the file. This is the format of the file:

· Internet-address host-name host-alias

Here, the first field, Internet-address, contains the number assigned to the machine on the Internet; the second field, host-name, contains the name of the machine; and the third field, host-alias, contains another name, or alias, that the host is known by (such as its initials or a nickname). For example, if you wanted to talk to the machine moon, with alias luna, and Internet address 192.11.105.100, the line in this file for moon would look like this:

192.11.105.100 moon luna

The most important entry in the hosts file is the entry for your own machine. This entry lets you know which network you belong to and helps you to understand who is in your network. Note that if a machine you need to talk to is not on the same network as your machine, TCP/IP still allows you to talk to it using a gateway (discussed in a later section of this chapter).

Listener Administration

Now that you have TCP/IP configured, you may want to use it as a transport provider for your networking service. If your variant of UNIX supports TLI, you can do this by setting up your TLI listener, which is used to provide access to the STREAMS services from remote machines. Note that Linux does not support TLI. To set up the TLI listener, you must first determine the hexadecimal notation for your Internet address. To create a listener database for TCP/IP, first initialize the listener by typing this:

# nlsadmin −i tcp

This creates the database needed by the listener. Next, tell the listener the hexadecimal form of your Internet address so that it can listen for requests to that address. Do this by running a command of the form

# nlsadmin −1 \xhexadecimal_address tcp

For example, if the hexadecimal number of your listener address is 00020401c00b6920, you prefix this number with \x and append 16 zeros to the number. You type this:

# nlsadmin −1 '\x00020401c00b69200000000000000000' tcp

Every service you want to run over TCP/IP needs to be added to the listener’s database. For instance, if you want to run uucp over TCP/IP, make sure that there is an entry in the database for this service.

You can modify the listener database in two ways, either by using nlsadmin or by using sacadm or pmadm (these are discussed in more detail in Chapter 14). You can enter service codes for additional services that you want to run over TCP/IP by consulting the administrative guide for each service.

Starting TCP/IP

You must have TCP/IP running on your machine for users to be able to access the network. To start TCP/IP after you load it onto your system, you might need to reboot the machine. This is important on some machines because some of the changes you might have made take effect only if you reboot. To reboot most UNIX variants, you can use the shutdown command with the following options:

# /etc/shutdown −y −g0 −16

Most newer UNIX variants, including Linux and Solaris, normally do not need to be rebooted, because TCP/IP is enabled in the kernel and should start up with your system. If, for any reason, things seem to be working improperly, you may choose to reboot. Most versions of Linux support the shutdown command, and the –r option tells the system to reboot after shutdown is complete. For example,

# shutdown −r now

does an immediate (now) shutdown and then reboots. Linux users may also use the reboot command to perform the same task.

These procedures automatically reboot the machine, bringing it back up to the default run level for which you have your machine configured. To see whether TCP/IP processes are running, type this:

$ ps −ef | grep inetd

This tells you whether the network daemon inetd (the master Internet daemon) is running. The configuration information for this daemon is contained in the file /etc/indetd.conf, which contains daemons for all of the services in your Internet environment, such as the ftp daemon (ftpd), the telnet daemon (telnetd), the talk daemon (talkd), and the finger daemon (fingerd). The inetd daemon should be started by the /etc/init.d/inetinet script for machines running Solaris, HP-UX, or other UNIX variants built on UNIX System V, or by the /etc/rc.d/init.d/inet script on Linux. If you do not see it, you should stop the network by using the command

# /etc/init.d/inetinit stop

and then restart the network by typing this:

# /etc/init.d/inetinit start

If this fails, check your configuration files to make sure that you have not forgotten to do one of the steps previously covered in configuring the machine for TCP/IP. Every time you reboot your machine, TCP/IP will start up if it is configured properly

TCP/IP Security

Allowing remote users to transfer files, log in, and execute programs may make your system vulnerable. TCP/IP provides some very good security capabilities, but nevertheless there have been some notorious security problems in the Internet.

Some aspects of TCP/IP security were covered in Chapter 9, in particular, how to use the files hosts.equiv and .rhosts to control access by remote users. These capabilities provide some protection from access by unauthorized users, but it is difficult to use them to control access adequately, while still allowing authorized users to access the system. You can provide a more secure environment by using the secure shell(ssh), which is also described in Chapter 9. This feature provides encryption of information when you are logged in to a remote machine.

TCP/IP Security Problems

One of the most famous examples of a TCP/IP security problem was the Internet worm of November 1988. The Internet worm took advantage of a bug in some versions of the sendmail program (sendmailadministration is discussed later in this chapter) used by many Internet hosts to allow mail to be sent to a user on a remote host.

The worm interrupted the normal execution of hundreds of machines running variants of UNIX, including the BSD System. Fortunately, the bug had already been fixed in the UNIX System V sendmail program, so that machines running UNIX System V were not affected. This worm and other security attacks have shown that it is necessary to protect certain areas by monitoring daemons and processes that could cause a breach in security Two of these are

§ fingerd (the finger service daemon)

§ rwhod (the remote who service daemon)

Both of these daemons supply information to remote users about users on your machine. If you are trying to maintain a secure environment, you may not want to let remote users know who is logging in to your machine. This data could provide information that could be used to guess passwords, for example. The best way to control the use of the daemons is simply not to run them on your system. For example, you can disable the finger daemon, by modifying the line

finger stream tc nowait nobody /usr/sbin/in.fingerd in.fingerd

in the file /etc/inetd.conf to look like

# finger stream tc nowait nobody /usr/sbin/in.fingerd in.fingerd

The pound sign (#) comments the line out.

In general, remember that as long as you are part of a network, you are more susceptible to security breaches than if your machine is isolated. It is possible for someone to set up a machine to masquerade as a machine that you consider trusted. Gateways can pass information about your machine to others whom you do not know, and routers may allow connections to your machine over paths that you may not trust. It is good practice to limit your connectivity into the Internet to only one machine, to disable all services that you know you do not need, and to gateway all of your traffic to the Internet via your own gateway You can then limit the traffic into the Internet or stop it completely by disconnecting the gateway into the Internet.

Utilities for Added Security

There are utilities that are available over the Internet to help you monitor your network traffic and identify intrusions. There are others, such as Tripwire at http://www.tripwiresecunty.com/, which prevents file replacement by intruders, and COPS (Computer Oracle and Password System), which can be downloaded from http://www.ciac.org/ciac/ToolsUnixSysMon.html, which checks file permissions security You can also use a package such as SARA (Security Auditor’s Research Assistant) or SAINT (Security Administrator’s Integrated Network Tool). SARA and SAINT examine TCP/IP ports on other systems on the network to discover common vulnerabilities. (Both SARA and SAINT incorporate an earlier package called SATAN [Security Administrator’s Tool for Analyzing Networks], which was also known as SANTA.) Many other tools have been developed to monitor your network’s security For an up-to-date list of network monitoring tools, go to the CERT web site, http://www.cert.org/. You can find a UNIX security checklist at http://www.cert.org/tech_tips/usc20_fullhtml. (CERT [Computer Emergency Response Team] is a network security body run by Carnegie Mellon University)

You might also want to use a program called tcp_wrappers, created by Wietse Venema, a well-known security expert. Venema has created a number of other security-related routines; the index page for all of his tools is at ftp://ftp.porcupine.org/pub/security/. The tcp_wrappers utility can be used to detect and log information that may indicate network intrusions (including spoofing). It logs the client host name of any incoming attempts to use ftp, telnet, or finger, or else to perform remote executions.

Another useful tool that you can use to identify security vulnerabilities is Nessus, which is a comprehensive vulnerability scanning program. Nessus consists of a daemon, nessusd, which performs the scanning, and a client, nessus, which presents results to the user. You can use Nessus to carry out a port scan using its internal port scanner to determine which ports are open on a target host machine. Once Nessus finds the open ports, it then tries to run different exploits that can take advantage of possible vulnerabilities, on the open ports. To learn about Nessus and to download it free of charge, go to http://www.nessus.org/.

AdministeringAnonymous FTP

As we mentioned in Chapter 9, the most important use of FTP is to transfer software over the Internet. Chapter 9 described how you can obtain files via anonymous FTP. Here, you will see how you can offer files on your machine via anonymous FTP to remote users.

When you enable anonymous FTP, you give remote users access to files that you choose, without giving these users logins. Many UNIX systems include a script for setting up anonymous FTP. If your system does not provide such a script, you can set up anonymous FTP by following these steps. Note that the directories used to store the information may differ slightly among variants from this example, but the process is the same. To set up anonymous FTP,

1. Add the user ftp to your /etc/passwd and /etc/shadow files.

2. Create the subdirectories bin, etc, and pub in /var/home/ftp.

3. Copy /usr/bin/ls to the subdirectory /var/home/ftp/bin.

4. Copy the files /etc/passwd, /etc/shadow, and /etc/group to /var/home/ftp/etc.

5. Edit the copies of /etc/passwd and /etc/shadow so that they contain only the following users: root, daemon, uucp, and ftp.

6. Edit the copy of /etc/group to contain the group other, which is the group assigned to the user ftp.

7. Change permissions on the directories and files in the directories under /var/home/ ftp, using the permissions given in Table 17–2.

8. Check that there is an entry in /etc/inetd.conf for in.ftpd.

9. Put files that you want to share in /var/home/ftp/pub.

After you complete all these tasks, remote users will have access to files in the directory /var/home/ftp/pub. Remote users may also write to this directory We offer a word of caution here, however. Making a directory on your machine a repository that others can write to may result in content that drains resources or is inappropriate for the machine (such as MP3 audio files).

Troubleshooting TCP/IP Problems

Some standard tools are built into TCP/IP that allow the administrator to diagnose problems. These include ping, netstat, and ifconfig.

ping

If you are having a problem contacting a machine on the network, you can use ping to test whether the machine is active. ping responds by telling you that the machine is alive or that it is inactive. For example, if you want to check the machine ralph, type this:

$ ping ralph

If ralph is up on the network, you see this:

ralph is alive

But if ralph is not active, you see this:

no answer from ralph

Although a machine may be active, it can still lose packets. You can use the −s option to ping to check for this. For example, when you type

$ ping −s ralph

ping continuously sends packets to the machine ralph. It stops sending packets when you hit the BREAK key or when a timeout occurs. After it has stopped sending packets, ping displays output that provides packet-loss statistics.

You can use other options to ping to check whether the data you send is the data that the remote machine gets. This is helpful if you think that data is getting corrupted over the network. One example of this is using the ping command with the –s option, which performs a ping every second, until you end the ping request (usually with a CTRL-C). The results of a successful four-second ping like this for machine dodger, at IP address 135.18.99.6, would be

# ping dodger

64 bytes from dodger (135.18.99.6): icmp_seq=1. time=38. ms

64 bytes from dodger (135.18.99.6): icmp_seq=2. time=25. ms

64 bytes from dodger (135.18.99.6): icmp_seq=3. time=45. ms

64 bytes from dodger (135.18.99.6): icmp_seq=4. time=36. Ms

----dodger PING statistics---

4 packets transmitted, 4 packets received, 0% packet loss

round-trip (ms) min/avg/max 25/36/45

You can also specify that you want to send data packets of a different size than standard. Here the default is used (64 bytes), but you may want to diagnose how bigger blocks are handled, particularly if you think your network is slow. For instance, you would type

# ping −s dodger 4096

to request that 4,096 bytes be sent back each time from dodger to see if they all come back. Check your system’s manual page for ping to learn more about its options. If you are a user of Windows9x/NT, the options are very similar to those you would use when running an add-on vendor package such as WSPing32, which is a commercial version of ping for Windows machines with more functionality than just the built-in Windows utility

netstat

When you experience a problem with your network, you need to check the status of your network connection. You can do this using the netstat command. You can look at network traffic, routing table information, protocol statistics, and communication controller status. If you have a problem getting a network connection, check whether all connections are being used, or whether there are old connections that have not been disconnected properly

For instance, to get a listing of statistics for each protocol, type this:

$ netstat −s

ip:

385364 total packets received

0 bad header checksums

0 with size smaller than minimum

0 with data size < data length

0 with header length < data size

0 with data length < header length

0 fragments received

0 fragments dropped (dup or out of space)

0 fragments dropped after timeout

0 packets forwarded

0 packets not forwardable

0 redirects sent

icmp:

9 calls to icmp_error

0 errors not generated 'cuz old message was icmp

Output histogram:

destination unreachable: 9

0 messages with bad code fields

0 messages < minimum length

0 bad checksums

0 messages with bad length

Input histogram:

destination unreachable: 8

0 message responses generated

tcp:

connections initiated: 2291

connections accepted: 11

connections established: 2253

connections dropped: 18

embryonic connections dropped: 49

conn. closed (includes drops): 2422

segs where we tried to get rtt: 97735

times we succeeded: 95394

delayed acks sent: 81670

conn. dropped in rxmt timeout: 0

retransmit timeouts: 239

persist timeouts: 50

keepalive timeouts: 54

keepalive probes sent: 9

connections dropped in keepalive: 45

total packets sent: 200105

data packets sent: 93236

data bytes sent: 13865103

data packets retransmitted: 88

data bytes retransmitted: 10768

ack-only packets sent: 102060

window probes sent: 55

packets sent with URG only: 0

window update-only packets sent: 13

control (SYN|FIN|RST) packets sent: 4653

total packets received: 156617

packets received in sequence: 90859

bytes received in sequence: 13755249

packets received with cksum errs: 0

packets received with bad offset: 0

packets received too short: 0

duplicate-only packets received: 16019

duplicate-only bytes received: 17129

packets with some duplicate data: 0

dup. bytes in part-dup. packets: 0

out-of-order packets received: 2165

out-of-order bytes received: 5

packets with data after window: 1

bytes rcvd after window: 0

packets rcvd after "close": 0

rcvd window probe packets: 0

rcvd duplicate acks: 15381

rcvd acks for unsent data: 0

rcvd ack packets: 95476

bytes acked by rcvd acks: 13865931

rcvd window update packets: 0

udp:

0 incomplete headers

0 bad data length fields

0 bad checksums

The preceding example is a report on the connection statistics. If you find many errors in the statistics for any of the protocols, you may have a problem with your network. It is also possible that a machine is sending bad packets into the network. The data gives you a general picture of the state of TCP/IP networking on your machine.

If you want to check out the communication controller, type this:

$ netstat −I

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Collis

1o0 2048 loopback localhost 28 0 28 0 0

The output contains statistics on packets transmitted and received on the network.

If, for example, the number of collisions (abbreviated to “Collis” in the output) is high, you may have a hardware problem. On the other hand, if as you run netstat –i several times you see that the number of input packets (abbreviated to “Ipkts” in the output) is increasing, while the number of output packets (abbreviated to “Opkts” in the output) remains steady, the problem may be that a remote machine is trying to talk to your machine, but your machine does not know how to respond. This may be caused by an incorrect address for the remote machine in the hosts file or by an incorrect address in the /etc/ethers file.

Checking the Configuration of the Network Interface

You can use the ifconfig command to check the configuration of the network interface. For example, to obtain information on the Ethernet interface installed in slot 4, type this:

# /usr/sbin/ifconfig emd4

emd4: flags=3<UP,BROADCAST>

inet 192.11.105.100 netmask ffffff00 broadcast 192.11.105.255

This tells you that the interface is up, that it is a broadcast network, and that the Internet address for this machine is 192.11.105.

Netcat, the “TCP/IP Swiss Army Knife”

Experienced system and network administrators often identify netcat, the “TCP/IP Swiss Army Knife,” as one of the more useful tools for debugging network problems and for identifying network security vulnerabilities. Basically, netcat is a general-purpose utility that can read and write data across a network, using either the TCP or UDP. It can be thought of as the network analog of the cat command on your local system. Recall that cat command can be used to write to a file or to read from a file on a UNIX system. Netcat can do the same things, but over a network, and can be used, using its various options and as part of scripts, to carry out an amazing variety of tasks over a network. If netcat is not already available on your system, you can download the GNU version of netcat from http://netcat.sourceforge.net/. This version runs without changes on Linux, Solaris, FreeBSD, NetBSD, and Mac OS X, and with minor changes on other UNIX variants. Some distributions of netcat include a set of sample scripts for carrying out basic tasks, including probing remote hosts, copying files over the network, and so on.

When you run netcat (by running either the netcat command or the nc command, depending on the version you have), you can connect to a remote host on a specified port and send your input to the service that answers on that port. For example, if you connect to port 25 on a remote host using netcat, you can determine whether the SMTP daemon is running on this port, as expected. If it is, you can use netcat to interactively test whether SMTP is running properly on this remote host. Similarly, you can interactively test other TCP/IP services, including FTP (port 21), POP3 (port 110), IMAP (port 143), HTTP (port 80), and so on.

In Chapter 9 we discussed the telnet command, which can be used for remote login over a TCP network. Note that telnet does not provide the same functionality as netcat. The netcat command has been designed to be much more useful that the telnet command. Netcat can be set up to listen for incoming connections, while telnet cannot; telnet only supports TCP and not UDP, and netcat can easily be used in a script, while telnet cannot be.

Examples of netcat Use

We will illustrate the use of netcat with two examples. (Here we use the GNU netcat command; other versions of netcat are run using the nc command for netcat. You should check to see which of these two commands is supported on your system. Generally, these two commands take the same options.) First, note that you can use netcat to send a file over a network. To send a file, you need to run netcat on both the host that is sending the file, say host1, and the host that is receiving the file, say host2. For example, on host2 you could run the command

# netcat −1 −p 3000 −v > test

to tell netcat to listen (using the –l option) on port 3000 (using the –p option). On host1, you then run

# cat test | netcat host2 3000 −q 5

to send the file test to netcat, which then sends this file to host2 on port 3000. The –q option tells netcat to quit five seconds after the end of the file (EOF). The –v (verbose) option is used to provide brief diagnostic messages, including when the connection was made and the sending and receiving hosts; the option –vv can be used to provide complete diagnostic messages, including the amount of data transmitted.

Next, we will show how you can use netcat to scan a range of ports on a remote host. For example, you can use

# netcat −v −w 3 −z 192.20.5.55 20–30

to scan all ports between 20 and 30, inclusive, on the remote host with IP address 192.20.5.55. Here the –w option with the argument 3 tells netcat to wait three seconds before reporting that a particular port did not respond, and the –z option tells netcat not to send any data to each of the ports being scanned. (Another important tools for port scanning is the powerful nmap [network mapper] program. See http://www.insecure.org/nmap/ for more information on nmap.)

System administrators and network administrators have found many ways to effectively use netcat for a wide variety of tasks. Unfortunately, malicious hackers have also figured out ways to take advantage of netcat for attacking remote hosts. Because of this, use of netcat is often limited by various security policies and systems.

For more information on netcat, go to http://www.vulnwatch.org/netcat/readme.html. To learn more about netcat and how it can be used by hackers, go to http://www.onlamp.eom/pub/a/onlamp/2003/05/29/netcat.html. There is also a version of netcat that encrypts data sent over connections, called CryptCat; you can learn about CryptCat at http://farm9.org/Cryptcat/.

Advanced Features

Other capabilities can be enabled once your system supports TCP. We will briefly discuss some of these capabilities here. Their configuration can be quite complicated. For more information, consult the “How to Find Out More” section at the end of this chapter.

Name Server

You can designate a single machine as a name server for your TCP/IP network. When you use a name server, a machine wishing to communicate with another host queries this name server for the address of the remote host. So, the machine itself does not need to know the Internet addresses of every machine it can communicate with. This simplifies administration because you only have to maintain an /etc/hosts file on one machine. All machines in your domain can talk to each other and the rest of the Internet using this name server. Using a name server also provides better security because Internet addresses are only available on the name server, limiting access to addresses to only the people who have access to the name server.

Just because some users in your domain can’t reach your name server doesn’t mean they can’t use the IP address directly to contact a host. Also, it doesn’t prevent them from using other name servers to get the same info. (For example, you can set up your /etc/resolv. conf to point to 138.23.180.127 even though your local name server is 207.217.126.81.)

Router

A router allows your machine to talk to another machine via an intermediate machine. Routers are used when your machine is not on the same network as the one you would like to talk to. You can set up your machine so that it uses a third machine that has access to both your network and the network of the machine you need to talk to. For instance, your machine may have Ethernet hardware, while another machine you need to communicate with can be reached only via PPP. If you have a machine that can run TCP/IP using both Ethernet and PPP, you can set this machine up as a router, which you could use to get to the remote host reachable only via PPP. You would configure your machine to use the router when it attempts to reach this remote system. The users on your machine would not need to know about any of this; to them it seems as if your machine and the remote machine are on the same network.

You need to understand a few more things about routers than we can cover here, but we can discuss some basic concepts. Routers are set up using the same network addressing scheme as for the network card we previously described. The router is assigned a specific IP address. Usually it is the first address on your network. For example, the first router on the 135.18.99 network would be 135.18.99.1. If you have additional routers, you would usually assign them the next available number (135.18.99.2 and so on). Since a router is a device on your network, you can ping it just as you would a UNIX machine. For example, if you want to know the status of the router at address 135.18.99.1, you can type

# ping 135.18.99.1

If you have assigned a name to the router, say snoozy, you can ping the router with the command sequence

# ping snoozy

You will receive responses similar to those shown in the previous section on ping in this chapter.

Networks and Ethers

As you expand the scope of your connectivity, you may want to communicate with networks other than your own local one. You can configure your machine to talk to multiple networks using the /etc/inet/networksfile. Here is an example of a line you would add to this file:

mynet 192.11.105 my

The first field is the name of the network, the second is its Internet address, and the third is the optional alias name for this new network.

The file /etc/ethers is used to associate host names with Ethernet addresses. There is also a service called RARP that allows you to use Ethernet addresses instead of Internet addresses, similar to the way DNS (Domain Name Service) maps a machine node name to an IP address. RARP converts a network address into an Internet address. For example, if you know that a machine on your network has an Ethernet address of 800010031234, RARP determines the Internet address of this machine. If you are using the RARP daemon, you need to configure the ethers file so that RARP can map an Ethernet address to an IP address.

There are other files that generally do not require attention, such as /etc/services and /etc/ protocols. If you want to know more about these files, consult the network administration guide for your variant.

PPP ADMINISTRATION

PPP(Point-to-Point Protocol) is a connection-oriented protocol that allow users to connect to UNIX systems over a remote connection using a device such as a modem or a dedicated serial link. To use these protocols, you must have TCP/IP running on both the client machine and the UNIX host to which it wants to connect.

PPP Protocol Administration

PPP (Point-to-Point Protocol) is a serial connection that can be used to support reliable connections. PPP allows you to communicate over a variety of protocols, including TCP/IP. PPP provides excellent error handling and correction facilities. It also allows for intelligent connections between your machine and the UNIX host. PPP can determine the local and remote TCP/IP addresses from a connection. The program that sets up the configuration for the PPP connection is called pppd (PPP daemon).

PPP does not perform a dialing function itself. Instead, it uses a connection-oriented program such as chat (see Chapter 10 for information on the Internet Relay Chat). You can specify some of the commonly used options to pppd in the chat script file and provide others on the command line. For example, the command

pppd connect 'chat −f mychat.chat' /dev/cua0 33600

will start PPP on port 1 (cua0) at 33600 baud, using the chat script myscript.chat for other settings as well as actually making the connection. You can set up routine PPP options in a file called /etc/ppp/options. When you start PPP, it will look in this file first for options and only override them if the command line supplies a different value for an option.

PPP also provides a secure method for transmitting information, CHAP (Challenge Handshake Application Protocol). If you need to use authentication to ensure security between two connected systems, you can set up a security file called /etc/ppp/chap-secrets. This file contains the client’s and server’s hostnames, a key, and the range of allowed IP addresses that they can communicate from. When PPP is started with the –auth option, CHAP is used to authenticate the connection and monitor it continuously

DNS (Domain Name Service) Administration

The concept of DNS has been around since the 1980s. It was implemented to make the life of the network and system administrators easier by establishing a uniform architecture for identifying names for machines instead of TCP/IP addresses. In addition, DNS made it possible to centralize the places you look to find out the name for a particular machine into machines called DNS servers. In the following sections, we will discuss how the DNS service evolved, and how it is structured to be administered easily

A Brief History of DNS

As Internet use grew in the early 1980s, the number of networked machines required to house all of the information grew at an even higher pace. One of the biggest problems was in handling the names of all of these machines. In the beginning of the Internet, every computer had a file called hosts.txt that contained the hostname-to-IP address mapping for all the hosts on the ARPANET. UNIX modified the name to /etc/hosts. Since there were so few computers, the file was small and could be maintained easily The maintenance of the hosts.txt file was the responsibility of SRI-NIC, located at the Stanford Research Institute in Menlo Park, California. When administrators wanted to change this file, they e-mailed the request to SRI-NIC, which would incorporate requests once or twice a week. This meant that administrators also had to periodically compare their hosts.txt file against the SRI-NIC hosts.txt file, and if the files were different, the administrator had to ftp a new copy of the file.

As the Internet started to grow, the idea of centrally administering hostnames, as well as deploying the hosts.txt file, became a major issue. Every time a new host was added, a change had to be made to the central version, and every other host on ARPANET had to get the new version of this file. In addition to this problem, several other issues with a single file were encountered.

To maintain an updated hosts.txt file required administrators to constantly download new copies of the file, causing unnecessary traffic on the network and an unbearable load on the SRI machines. A single file could not handle duplicate names, which meant that machine names would eventually run out. Every computer on ARPANET needed to have the latest version of hosts.txt, but there was no automatic way of distributing updated versions. If two computers had different versions, the entire network would get confused.

In the early 1980s, the SRI-NIC called for the design of a distributed database to replace the hosts.txt file. The new system was known as the Domain Name System (DNS for short). ARPANET switched to DNS in September 1984, and it has been the standard method for publishing and retrieving host name information on the Internet ever since. DNS is a distributed database based on a hierarchical structure. Under DNS, every computer that connects to the Internet connects from an Internet domain. Each Internet domain has a name server that maintains a database of the hosts in its domain and handles requests for hostnames.

The Structure of DNS

DNS has a root domain, ‘.’, at the top of its tree, much as UNIX has the root directory, ‘/’. All domains and hosts are located underneath the root domain. The root-level domain currently has 13 name servers maintained by the NIC that can answer queries. Their names are a.root-servers.net., b.rootservers.net., c.rootservers.net., and so on.

In this section we will first look at the structure of DNS, starting with the concept of top-level domains and then continuing into subdomains. We will also look at three different types of name servers that are used to handle domain information.

Top-Level Domains

Under the root domain, several “top level” domains are classified into two types, generic and country codes. Generic top-level domains include

· .biz (Business)

· .com (Commercial)

· .edu (Educational)

· .gov (U.S. Government)

· .info (Information)

· .int (International, e.g., NATO)

· .mil (U.S. Military)

· .museum (Reserved for museums)

· .name (Reserved for individuals)

· .net (Network organizations and Internet service providers)

· .org (Nonprofit organizations)

· .travel (Reserved for the travel industry)

Country codes are used to identify top-level domains of machines located within a particular country For example, .uk is the country code for the United Kingdom, .au is the country code for Australia, .ca is the country code for Canada, and .mx is the country code for Mexico. (Note that the country code for the United States, .us, is not used very much.) A complete list of country codes, covering every part of the world, can be found at http://www. iana.org/cctld/.

Subdomains

In addition to the top-level domains, DNS also has subdomains such as att.com, nasa.gov, and berkeley.edu. Subdomains in DNS are equivalent to subdirectories in the file system. If a particular directory contains too many files, we usually create a subdirectory and move many of the related files into this new directory This helps to keep directories and files organized. The same principle applies to DNS: When a domain has too many hosts, a subdomain can be created for some of the hosts in the domain. Subdomains can be created at any time without consulting any higher authority within the tree.

Any subdomain is free to create other subdomains. The relationship between a domain and its subdomain is similar to a parent and child relationship found in the UNIX directory tree. The parent domain must know which machine handles the subdomain database information so that it will be able to tell other name servers who holds the information for the subdomain. When a parent creates a subdomain, this is known as delegation. The parent domain delegates authority for the child subdomain to the subdomain’s name server.

Fully Qualified Domain Names

Each domain has a fully qualified domain name (FQDN), which is similar to a pathname in the file system, within the DNS. To identify the FQDN for a particular domain, we start by first getting the name of the current domain, adding the name of the parent domain, and then adding the name of the grandparent’s domain, and so on until we reach the root of the tree. This method is the reverse of the method used to construct directory names in the UNIX file system. An example of a fully qualified domain name is

csua.berkeley.edu

This particular domain name corresponds to the Computer Science Undergraduate’s Association at the University of California at Berkeley From this name we can tell that csua is a subdomain of the berkeley domain, which is itself a subdomain of the edu “top-level” domain. In this representation, the strings between the dot character, ‘.’, are called labels. The last ‘.’ is used to represent the root domain.

Resolvers

Special programs that store information about the domain name tree are called DNS resolvers or name servers. These programs usually have the complete information about some part of the domain name tree. The main types of name servers are master, slave, caching, and forwarding. You may see these servers referred to as full service resolvers, because they are capable of receiving queries from clients and other name servers. A full service resolver always maintains a cache of items that it has already looked up. It is also able to perform recursive queries to other name servers, if it does not have a cached answer for a query that it received.

Master DNS Servers

Each DNS domain has a master, or primary, server that contains the authoritative zone database file. This file contains all of the hostnames and their corresponding IP addresses for the domain, along with several other pieces of information about the zone. A master name server answers queries with authoritative answers for the zone in which it is located. To service client requests, a master name server normally queries other name servers to obtain the required information. It also maintains a memory cache to remember information returned by other name servers. The master name server’s database is also used to delegate responsibility for subdomains to other name servers.

To change the information for a domain, the zone database file on the master name server must be changed. The zone database contains a serial number that must be incremented each time the database is altered, as this ensures that secondary name servers will recognize the changes.

Slave DNS Servers

Each domain should have at least one slave, or secondary, server for redundancy purposes. The slave server will obtain a copy of the zone database, usually from the master name server. The slave will serve authoritative information for the zone just as the master server does. Slave name servers will normally query other name servers to obtain information from other name servers to answer client requests. Like master name servers, slave name servers have a memory cache that remembers information returned by other name servers.

Caching DNS Servers

Caching, or hint, name servers do not serve authoritative information for any zones. Clients query such a name server, and it forwards the query to other name servers until an answer for the query is found. Once an answer is found, the caching name server remembers the answer for a period of time. If the same client makes the same query again (or if other clients do), this name server gives the answer stored in cache, instead of forwarding the query to another name server. Caching name servers are generally used to reduce DNS traffic over slow or expensive network connections.

Forwarding DNS Servers

Forwarding, or proxy, client, or remote, servers have only one purpose, to forward all DNS requests to other DNS servers, caching the results. Although forwarding DNS servers may seem rather pointless, they can help reduce traffic and external access needs. In particular, they are used when access to an external network is slow or costly

DNS Resource Records

DNS resource records are entries stored in the DNS database. The DNS database is a set of ASCII text files that contain information about the machines in a domain. This information is stored in a specific format that we will examine in this section. Information is added to a domain by adding resource records to the database located on a primary name server. When a query is made to a name server, the server will return one or more resource records containing either the exact answer to the query or information pointing to another name server in the name space to look for the answer. The resource records on a primary name server are stored in a zone database. The zone database is usually made up of at least three files:

§ db.network (for example, db.10.8.11)

§ db.domain (for example, db.bosland)

§ db.127.0.0

The first file contains the mapping of IP addresses to hostnames for a given network. The second file contains the reverse mapping of hostnames to IP addresses. The third file contains a mapping for the local host.

DNS bind allows you to name these files differently from the examples. The name of the zone databases for bind4 mapping is in /etc/named.boot, and that for bind9 mapping is in /etc/named.conf.

The Structure of DNS Database Files

Each database file has three main sections, the Start of Authority section (SOA), the name server section (NS), and the database section. Each of these sections has one or more DNS resource records. The syntax of a DNS resource record can be in one of the following forms:

[TTL] [class] type data

[class] [TTL] type data

The first two fields, TTL and class, are optional fields that correspond to the “Time-To-Live” and the class of the record. The “Time-To-Live” is a decimal number that indicates to the name server how often this particular record needs to be updated. Usual values range from a few minutes to a few days. If this field is blank, it is, by default, assumed to be three hours.

The class field indicates which class of data the record belongs to. The only class that is used is the IN class, corresponding to Internet data. The type field is a required field and describes the type of data in the record:

§ SOA Record The Start of Authority resource record is located at the top of each file in the zone database. The SOA includes many pieces of information that are primarily used by the secondary name server.

§ NS Record The name server section is the second section in each of the files in the zone database. It contains a name server resource record, NS, for each of the primary and secondary name servers for the zone that the database serves.

§ A Record An A record is an address record used for providing translations for hostnames to IP addresses.

§ PTR Record The pointer, or PTR, records are typically seen in the db.network or the db.127.0.0 files. They are used for reverse address resolution, which is used by the name server to turn an IP address into a hostname.

§ CNAME Record The Canonical Name (CNAME for short) record makes it possible to alias hostnames. This is useful for giving common names to large servers. For example, it is useful to have the server that handles both web traffic and FTP traffic for a domain respond to the names www and ftp.

§ MX Record The list of host names that will accept mail for this domain, and their priority The priority indicates the urgency of mail delivery for a given host. A smaller number indicates quicker response.

The Database portion of the zone file contains all of the resource records that contain the data for the hosts in the zone. Three main types of records are encountered in this section. In the db.network file we will encounter PTR records. In the db.domain file we will encounter A and CNAME records.

Using NSLOOKUP to Find a Machine on the Network

You may want to connect to another machine on the TCP/IP network to send or receive information but not be sure what the machine’s address is, or even that the machine name (hostname) that you want to reach exists. The nslookup utility enables you to find out this information. You provide the hostname of the desired machine as part of the command line. For example,

# nslookup dodger.com

Name Server: damian.master.com

Address: 198.5.22.7

Name: dodger.com

Address: 199.14.36.112

provides the name server (damian.master.com) that dodger.com exists on as well as the IP address for both the name server and dodger.com. If the hostname for the machine does not exist, you will get a message back indicating so. For example, if you were to type in the name dogder.com by mistake, you would get a message like this:

# nslookup dogder.com

Name Server: damian.master.com

Address: 198.5.22.7

*** damian.master.com can't find dogder.com: Non-existent domain

One important point to note is that nslookup uses an authoritative approach to do its translations. It uses either your local name server or whatever is specified in /etc/resolυ.conf to do queries. As long as the machine is in your domain, you can guarantee that the machine exists without going outside the domain (called an authoritative answer). If you need to go outside your domain to get the information from another domain server, the answer is nonauthoritative (you are taking the other domain server’s word that the domain name exists). In the successful example shown previously, damian.master.com needs to be authoritative to dodger.com; otherwise, you will be informed that it is a nonauthoritative lookup.

Using host and dig

Besides nslookup, two other commands, host and dig, are often used to obtain DNS information about a particular hostname or IP address. These two commands are supported by Solaris, AIX, HP-UX, Linux, FreeBSD, NetBSD, and OpenBSD, as well as other UNIX variants. Some UNIX variants support one, but not both, of them.

The host Command

The host command can be used to find the IP address corresponding to a particular hostname, or vice versa. For example,

# host dodger.com

dodger.com is 198.5.22.7

gives us the IP address corresponding to the host dodger.com. We can find the hostname corresponding to the IP address 198.5.22.7 as follows:

# host 198.5.22.7

dodger is 198.5.22.7

The dig Command

The dig (short for domain information groper) is a powerful command that can be used to extract information from DNS servers. You can use this command for DNS lookups on particular DNS servers. Network administrators used the dig command to troubleshoot DNS problem because of its flexibility and ease of use, as well as the clear way output is presented. The following is an example of a dig query that will query each of the DNS servers listed in /etc/resolυ.conf:

# dig dodger.com

To query a particular DNS server, you use a command like

# dig @ns.dodger.com dodger.com any

This command directly queries the DNS server ns.dodger.com for any information about the hostname dodger.com. See the man page for the dig command to learn about the output provided by this command, as well as options that can be used to troubleshoot DNS problems.

sendmail Mail Administration

The sendmail daemon is a service that runs in the background on your UNIX machine to provide electronic mail services to users on a TCP/IP network. sendmail is what is known as a mail transfer agent (MTA). Although other MTAs are supported by UNIX (e.g., qmail), sendmail is by far the most commonly used one. The sendmail environment is the most complex service available on UNIX. In addition to simply sending messages from one user to another, sendmail determines how to best route the messages across networks to reach a particular destination. Finally, it provides forwarding services so that mail items can be redirected to destinations other than those they were originally sent to. Since sendmail is so complex, we will only address the basics that will allow you to get started as a network administrator for this service. If you want to learn more details, see the “How to Find Out More” section at the end of this chapter.

It is important to understand the distinction between a mail delivery function and a mail reading function. The sendmail daemon only provides the capability to encapsulate (package) a mail message so that it can be sent over a UNIX network. To read a message, a user must have an MUA (mail user agent), or mail reader, installed on the machine receiving the mail. Examples of MUAs are pine, Elm, and mailx. User interaction with sendmail is discussed in Chapter 8.

The sendmail program may already be on your machine. If it is not, you can get it for free. The best source is the official sendmail site at http://www.sendmail.org/. You can read more about sendmail in the Usenet newsgroup comp.mail.sendmail.

Once you have sendmail on your machine, you must configure it for your particular environment to use it effectively. This is done through entries in the sendmail.cf file (sendmail configuration file). This configuration file sets up the options to be used in sending mail and defines the locations of files it uses to do so. It also defines the message transfer agents (or mailers) that sendmail uses to route messages over the network. Lastly, it defines rules for senders and recipients of mail and mailers that are used on your system.

Monitoring sendmail Performance

To provide timely mail service to users on your system, not only must you configure sendmail properly, but you must also tune it and periodically and monitor its performance. The program includes a number of options that help you do this. Here are some of the more important ones that can be used when you start up the sendmail daemon:

Networked Mail Directories

A configuration you may find useful in a closely coupled environment is to use NFS (see Chapter 15) to share the directory /var/mail between multiple machines. In this way, mail gets stored on only one file system. In the event that your particular machine is down, you can most likely use another machine on your network that has access to the mail directory /var/mail on the server.

First, decide which machine will be the primary machine that will normally have the mail file system mounted, such as company1. Second, move all mail currently found on the secondary machines to the primary machine. Next, remove the directory /var/mail/:saved from all of the secondary machines. (This directory is normally used as a staging area when mail is rewriting mail files.) Then, tell mail where it should forward the mail message if it finds that the /var/mail directory is not mounted properly Do this by adding the following variable to the mail configuration file:

FAILSAFE=company1

Finally, mount the mail directory from the primary machine using NFS. Take caution to NFS-mount the mail spool directory as a hard mount (do not use the soft option). A soft mount may cause corruption of mail. For example, if the spooler is mounted with the soft option, and you are attempting to write to your local mailbox, and sendmail is attempting to deliver mail at the same time, your mail files may become corrupted.

Setting Up SMTP

SMTP (Simple Mail Transfer Protocol) is a protocol specified for hosts connected to the Internet that is used to transmit electronic mail. SMTP is used to transfer mail messages from your machine to another machine across a link created using the TCP/IP network protocol. The sendmail daemon sets up an SMTP service for both the mail client (the user who sends mail) and the mail server (the sendmail process that sends messages over the network). SMTP is the most popular mail protocol daemon for sending mail. To read your mail, you need an additional daemon. One example is the POP3 (Post Office Protocol level 3) protocol daemon. This daemon allows you to receive mail from the network in a format that can be read by a mail reader on your system. One specialized POP3 daemon is called qpopper, used to support mailers such as Eudora (see Chapter 8). You can obtain this daemon from Eudora at http://www.eudora.com/. Eudora is now a product of Qualcomm, Inc. If you use elm as your mail reader (see Chapter 8), you do not need to set up a mail reading daemon such as POP3, since elm reads directly from the mail spool directory

Mail Domains

The most commonly used method of addressing remote users on other computers is by specifying the list of machines that the mail message must pass through to reach the user. This is often referred to as a route-based mail system, because you have to specify the route used to get to the user, as well as the user’s address.

Another method of addressing people is to use what is known as domain addressing. This is the primary way in which web browser-based e-mail is sent; for example, sending mail to dhost@att.com (see Chapter 8, “Electronic Mail”). In a domain-based mail system, your machine becomes a member of a domain. Every country has a high-level domain named after the country; high-level domains are also set aside for educational and commercial entities. An example of a domain address is usermachine.company.com, or equivalently, machine.company. com!user. Anyone properly registered can send mail to your machine if they know how to get directly to your machine or know the address of another, smarter host (commonly referred to as the gateway machine) that does have further information on how to get to your machine; this may require the use of other machines on the way This cannot be done unless your machine is registered with the smarter host and you have administered the gateway machine on your system as the smarter host. If you have SMTP configured, your system may be able to directly access other systems in other domains.

Once you have registered your machine within a domain, you must set the domain on your system. This can be done in several ways:

§ If your domain name is the same as the Secure RPC domain name, then both can be set by using the /usr/bin/domainname program, using a line of the form

domainname .company.com

§ If you have a name server, either on your system or accessible via TCP/IP, the domain name can be set in the name server files, /etc/inet/named.boot or /etc/resolυ.conf, using a line of the form

domain company.com

§ The domain name can also be overridden within the mail configuration file using a line of the form

DOMAIN=.company.com

NIS+ (Network Information Service Plus) Administration

NIS+ is a networking service that centrally manages information about network users and the machines they use and access, applications that are run, file systems that are used, and services that are needed to do all of these things. This type of setup is very useful if you have a network with users who share a large portion of their files and applications. It also makes the job of the network administrator easier, since NIS+ is the official repository of networking information. NIS+ provides a robust network security and authorization environment for file sharing services such as NFS, discussed a little later in this chapter.

NIS, the predecessor of NIS+, has been around for a while. Commonly called the Yellow Pages, or YP for short, NIS was introduced by Sun Microsystems in the 1980s as a method for managing NFS environments by controlling and sharing such things as password and group information among hosts in a network. NIS+, which is part of Sun Microsystem’s suite of services called the Open Network Computing Plus (ONC+) platform, has been built onto the NIS platform.

NIS+ provides a screening mechanism that authenticates users when a request is made for a resource that is shared on the network. For instance, if you want to use a file on another machine in the network, NIS+ determines whether or not you are allowed to use the resource before allowing NFS (see the following section) to mount it. If you want to perform a command on another networked machine using RPC (Remote Procedure Calls), NIS+ validates that you have access to the command as well as the information on the networked machine. If you are validated, you can perform commands such as rsh on the remote machine. (See later on in this chapter for a discussion of RPC.)

NIS does not do authentication; it merely returns database entries. In the case of a password database, it is up to the application to determine whether the requesting user has the privileges to access it.

NIS+ is implemented on the UNIX system by a daemon called rpc.nisd. This daemon starts the NIS+ service in one of two ways. The first is to run NIS+ with all of its service features. If you start the daemon with the –YB option, NIS+ is started in NIS compatibility mode. This allows machines that are on the network to use resources as though they are being managed by the older NIS services.

NFS (Network File System) Administration

NFS allows you to share files across networks. This capability eliminates the need to duplicate commonly used files on each machine in your network. NFS is used by all of the major UNIX variants. It can be used to share files between two, or among multiple, operating system types. For instance, NFS allows you to share files between a Solaris system and a Linux system. NFS is discussed in more detail in Chapter 15.

Before you can use NFS, you need to make sure that a network provider is configured, that the Remote Procedure Call (RPC) package has been installed, and that the RPC database has been configured for your machine. Configuring a network provider has already been discussed. What follows is a discussion of the RPC package and its databases.

Checking RPC

NFS relies on RPC, which allows machines to access services on a remote machine via a network RPC handles remote requests and then hands them over to the operating system on the local machine. The local system has daemons running that attempt to process the remote request. These daemons issue the system calls needed to do the operations.

Because NFS relies on RPC, you need to check that RPC is running before starting NFS. You can check to see if it is running by typing this:

# ps −ef | grep rpc

If you see “rpc.bind” in the output of this command, then RPC is running. Otherwise, use the script /etc/init.d/rpc to start RPC. This startup script, also known as the portmapper in some variants, is in portmap/rpc.portmap/rpc.portmapper.

You should also check to make sure that the data files for RPC are set up in files with names of the form /etc/net/*/hosts and /etc/net/*/services. You replace the * with the name of your transport. You may see many transports in /etc/net, because you will have one per transport protocol, such as the transport protocols associated with TCP/IP, ticlts, ticots, and ticotsord.

Setting Up NFS

To set up NFS on clients and servers, the daemons used by NFS need to be started. For example, on Solaris machines, the daemons used by NFS clients and NFS servers are started by running the boot scripts /etc/init.d/nfs.client and /etc/init.d/nfs.server, respectively. Because this happens automatically at run level 3, you generally will not have to manually run these scripts. However, you start the NFS server daemons using the command

# /etc/init.d/nfs.server start

You can start the NFS client daemons using the command

# /etc/init.d/nfs.client start

On Linux, you can start both the NFS client and server daemons using the command

# /etc/init.d/nfs start

Note that NFS requires little in the way of configuration, as there is no notion of domains or name servers. With NFS, more of the configuration takes place as you actually make use of its facilities such as sharing and mounting resources.

Sharing NFS relies on the administrator who is sharing the resource to keep security in mind. So when you share a resource, you also must determine how secure you want that resource to be.

NFS resources do not have a name used to identify them, other than the actual path to the resource that is being shared. Machines on the network refer to the resource as machinename:resource when they attempt an operation on an NFS resource.

Mounting Mounting resources with NFS requires that resources are identified with the notation machine-name:resource. NFS resources can also be mounted via the automounter, discussed in the following section, which mounts the resource only when a user actually attempts to access it.

The Automounter

NFS includes a feature called the automounter that allows resources to be mounted on an as-needed basis, without requiring the administrator to configure anything specifically for these resources.

When a user requires a resource, it is automatically mounted for the user by the automounter. After the task using this resource has been completed, it will eventually be unmounted.

All resources are mounted under /tmp_mnt, and symbolic links are set up to place the resource on the requested mount point. The automounter uses three type of maps: master maps, direct maps, and indirect maps. A brief description of these three maps follows for the Solaris system. For more information on the particular automounter available for your system, see the documentation for your system. Note that there are two widely used automounters for Linux systems, autofs and amd (the Berkeley Automounter). For more information on autofs, go to http://www.faqs.org/docs/Linux-mini/Automount.html, and for more information on amd, go to http://www.am-utils.org/. For more information on NFS administration and automounters on AIX and HP-UX systems, go to http://www.freelab.net/uni x/hp- u x/chap1 2_nfs. html.

The Master Map The master map is used by the automounter to find a remote resource and determine what needs to be done to make it available. The master map invokes direct or indirect maps that contain detailed information. Direct maps include all information needed by automount to mount a resource. Indirect maps, on the other hand, can be used to specify alternate servers for resources. They can also be used to specify resources to be mounted as a hierarchy under a mount point.

A line in the master map has the form

mountpoint map [mount-options]

An example of a line in the master map is

/usr/add-on /etc/libmap −rw

This line tells the automounter to look at the map /etc/libmap and to mount what is listed in this map on the mount point /usr/add-on on the local system. It also tells the automounter to mount these resources with read/write permission.

Direct Map A direct map can be invoked through the master map or when you invoke the automount command.

An entry in a direct map has the form

key [mount-options] location

where “key” is the full pathname to the mount point, “mount-options” are the options to be used when mounting (such as –ro for read-only), and “location” is the location of the resource specified in the form server.path-name. The following line is an example of an entry in a direct map:

/usr/memos −ro jersey:/usr/reports

This entry is used to tell the automounter to mount the remote resources in /usr/reports on the server jersey with read-only permission on the local mount point /usr/memos. When a user on the local system attempts to access a file in /usr/reports, the automounter reads the direct map, mounts the resource from jersey onto /tmp_mnt/usr/memos, and creates a symbolic link between /tmp_mnt/usr/memos and /usr/memos.

A direct map may have many lines specifying many resources, like this:

/usr/src \

/cmd-rw,softcmdsrc:/usr/src/cmd \

/uts-ro, softutssrc:/usr/src/uts \

/lib-ro,securelibsrc:/usr/lib/src

In the preceding example, the first line specifies the top level of the next three mount points. Here, /usr/src/cmd, /usr/src/uts, and /usr/src/lib all reside under /usr/src. A backslash (\) denotes that the following line is a continuation of this line. The last line does not end with a \, which means that this is the end of the line. Each entry specifies the server that provides the resource; that is, the server cmdsrc is providing the resource to be mounted on /usr/src/cmd. You can see that it is possible to have different servers for all of the mount points, with different options.

You can also specify multiple locations for a single mount point, so that more than one server provides a resource. You do this by including multiple locations in the location field. For example, the following line,

/usr/src −rw,soft cmdsrc:/usr/src utssrc:/usr/src libsrc:/usr/src

can be used in a direct map. To mount /usr/src, the automounter first queries the servers on the local network. The automounter mounts the resource from the first server that responds, if possible.

Indirect Maps Unlike a direct map, an indirect map can only be accessed through the master map. Entries in an indirect map look like entries in a direct map, in that they have the form

key [mount-options] location

Here, the key is the name of the directory (and not its full pathname) used for the mount point, mount-options is a list of options to mount (separated by commas), and location is the server.path-name to the resource.

NFS Security

As mentioned earlier, you can use the share command to provide some security for resources shared using NFS. (For more serious security needs, you can use the Secure NFS facility if it is available for your UNIX variant, which is described later in this chapter.)

When you share a resource, you can set the permissions you want to grant for access to this resource. You specify these permissions using the –o option to share. For instance, –o rw will allow read/write access.

You may also choose to map user IDs across the network. For example, say you want to give root on a remote machine root permissions on your local machine. (By default, remote root has no permissions on the local machine.) To map IDs, use a command such as this:

# share −o root=remotemachine

When deciding the accesses to assign to a resource, first decide who needs to be able to use this resource.

Secure NFS

Secure NFS provides a method to authenticate users across the network and allows only those users who have been authorized to make use of the resources. Secure NFS is built around the Secure RPC facility (Note that Secure NFS is not available for all UNIX variants. For some variants, a different secure version of NFS is available.) Secure RPC will be discussed first.

Secure RPC

Secure RPC is used for authentication of users via credentials and verifiers. An example of a credential is a driver’s license that has information confirming that you are licensed to drive. An example of a verifier is the picture on the license that shows what you look like. You display your credential to show you are licensed to drive, and the police officer verifies this when you show your license. In Secure RPC, a client sends both credentials and a verifier to the server, and the server sends back a verifier to the client. The client does not need to receive credentials from the server because it already knows who the server is.

Secure RPC uses the Data Encryption Standard (DES) and public-key cryptography to authenticate both users and machines. Each user has a public key, stored in encrypted form in a public database, and a private key, stored in encrypted form in a private directory The user runs the keylogin program, which prompts the user for an RPC password and uses this password to decrypt the secret key keylogin passes the decrypted secret key to the keyserver, an RPC service that stores the decrypted secret key until the user begins a transaction with a secure server. The keyserver is used to create a credential and a verifier used to set up a secure session between a client and a server. The server authenticates the client, and the client, the server, using this procedure.

You can find details about how Secure RPC works in your network administrator’s guide for your variant.

Administering Secure NFS

To administer Secure NFS, you must make sure that public keys and secret keys have been established for users. This can be done either by the administrator via the newkey command or by the user via the chkey command.

Public keys are kept in the file /etc/publickey, whereas secret keys for users, other than root, are kept in the file /etc/keystore. The secret key for root is kept in the file /etc/.rootkey/.

After this, each user must run /usr/sbin/keylogin. (As the administrator, you may want to put this command in users’ /etc/profile, to ensure that all users run it.) You then need to make sure that /usr/sbin/keyserve (the keyserve daemon) is running.

Once Secure NFS is running, you can use the share command with the –o secure option to require authentication of a client requesting a resource. For example, the command

# share −F nfs −o secure /user/games

shares the directory /usr/games so that clients must be authenticated via Secure NFS to mount it.

As with many security features, be aware that Secure NFS does not offer foolproof user security. Methods are available for breaking this security, so that unauthorized users are authenticated. However, this requires sophisticated techniques that can only be carried out by experts. Consequently, you should only use Secure NFS to provide a limited degree of user authentication capabilities.

Troubleshooting NFS Problems

As mentioned in the preceding section, NFS relies on the RPC mechanism. NFS will fail if any of the RPC daemons have stopped or were not started. You can start RPC by typing this:

# /etc/init.d/rpc start

If you wish to restart RPC, first stop RPC by executing this script, replacing the start option with stop. Then run this command again to start RPC. If you see any error messages when you start RPC, there is most probably a configuration problem in one or more of the files in /etc/net.

If NFS had been running but now no longer works, run ps –ef to check that /usr/lib/nfs/ mountd and /usr/lib/nfs/nfsd are running. If mountd is not running, you will not be able to mount remote resources; if nfsd is not running, remotes will not be able to mount your resources. You should also see at least four /usr/lib/nfs/nfsd processes running in the output. One other daemon should be running on the client machine, /usr/lib/nfs/biod, which is a client-side daemon that enables clients to use NFS.

Other problems may be related to the network itself, so be sure that the transport mechanism NFS is using is running. Consult your network administrator’s guide for information about other possible failures.

Firewalls, Proxy Servers, and Web Security

If you are a network administrator who is responsible for the web environment on your UNIX machine, you will need to know how to make your environment secure as well as efficient. There are a couple of ways to do this. You can put software called firewall software between you and the rest of the network on your UNIX machine to provide security. To improve performance, you can send information to and receive information from the outside world via software running on your UNIX machine called a proxy server. You can even combine these two functions into the same physical machine and call it a proxy/firewallmachine. We will discuss each of these briefly here.

Firewalls for UNIX

There are many different commercial firewall products for different UNIX variants, but many UNIX variants include a built-in packet firewall that can be configured to handle network packets differently, depending on their source and other characteristics. These firewalls are controlled using rules loaded into the UNIX kernel. How packets are handled is specified using a set of rules. These rules can either block or allow packets to flow, depending on the source of the packet, the packet type, the protocol, and other data. For instance, these rules can be used to block all incoming traffic or block all incoming traffic but allow anyone to set up an HTTP connection to a particular port or to allow all hosts to set up an SSH connection to a particular port. (Generally, it is good administrative practice to disallow all traffic that is not explicitly permitted for specific uses.) These rules can also specify what is allowed for outgoing traffic.

Different UNIX variants support one or more packet firewalls. The most important of these are the iptables firewall, which is part of Linux, the ipfirewall (also called ipfw) (Free BSD and Mac OS X), and ipfilter(also called ipf), which comes with Solaris, NetBSD, and OpenBSD, and which runs on other many other UNIX variants, including HP-UX and Linux. We will illustrate how packet firewalls work with a brief introduction to iptables.

Commercial firewall can be much more sophisticated than these built-in packet firewalls. They can provide much more flexibility on how packets are handled, and they can integrate other functions, including the function of a proxy server, which we will discuss later in this chapter.

The iptables Firewall in Linux

All newer Linux distributions include a firewall called iptables. This firewall is built on top of netfilter, a set of hooks in the kernel of Linux that are used to intercept and manipulate packets sent over a network. Network address translation (NAT), which allows the source and/or the destination of packets to be rewritten, primarily so that multiple hosts can access the Internet using a single IP address, is also built on top of netfilter. Although iptables technically refers to the tool controlling packet filtering and NAT, it often refers to the entire infrastructure including netfilter, NAT, and connection tracking, as well as the iptables firewall itself.

A network administrator can use iptables to define rules specifying how network packets are handled. A rule specifies which packets it applies to and what is to be done with these packets. These rules are grouped into ordered list of rules, called chains. These chains are grouped into tables; each table is associated with a particular type of packet processing. Every network packet arriving at or leaving a host traverses at least one chain; each rule on that chain attempts to match the packet, and when the rule matches the packet, the target of that rule specifies what is done with that packet. If a packet reaches the end of a chain without matching any rule on the chain, the packet is handled using the default target of the rule of the chain.

We will not go into the details of the use of iptables and its various command options, but we will illustrate its use with an example. Suppose that you have iptables running on your desktop computer connected to the Internet with a dedicated connection. To have your computer ignore all packets trying to set up a connect with it, you include the line

iptables −p tcp −A INPUT -syn −j DROP

Here, the --syn option is used to match those TCP packets that are used to initiate TCP connections. Blocking such packets on the INPUT chain will prevent incoming TCP connections, while outgoing TCP connections will be unaffected. (Another useful option is-source, which can be used to block or allow inbound TCP connections from specified hosts or networks.) The –j option is used to specify the target that specifies what to do with packets that match the rule specification. Here, the DROP option specifies that all packets matching the rule specification are dropped. For more details on how to use iptables, consult its manual page.

Keeping Your Network Safe

Many more issues than we can discuss here are involved in managing a firewall effectively. This topic is beyond the scope of a book of this nature. If you are a firewall administrator, there are many good books on this topic that you will want to read before undertaking the task. We mention some good ones, such as the books by Cheswick and Bellovin and by Rubin, as well as a few others, listed in the section “How to Find Out More” of this chapter. What we will discuss here is why it is important to recognize that firewalls need to be administered to prevent against firewall attacks, or attempts by unauthorized users to get into your network.

As a network administrator, you probably already understand the importance of keeping files and programs from being accessed by unauthorized people. You probably use combinations of NIS and NFS to ensure security for these things. In the Internet environment, the same types of issues are present. Because the connection method of the Internet is TCP/IP, all of your services that use TCP/IP must be monitored to ensure that no one is trying to get into your systems over the network. The most common way to prevent this is to implement a firewall between your network and the outside world. This firewall can check all incoming traffic to see if there are attempts to take information from, or to deliver information to, the machines on your network by outsiders. The most common type of attacks on firewalls are called intrusion attacks, where an outsider tries to make your system believe he or she is a legitimate user on your system. The risk here is that-once the person is validated as a legitimate user-the intruder has all of the privileges of a legitimate user, such as erasing or moving files or programs. A second type of attack is the service denial attack. An intruder can get into your system and disable certain files or programs so that you cannot use them. An example of this is a virus or a worm, both of which can cause irreparable harm to your system if left undetected. A third type of attack, which may not cause physical harm to your system, is called an information theft attack. Since this type of attack does not require you to do anything immediately to repair damaged files or programs, it can go unnoticed for a while. However, it is potentially more damaging, especially if the information that is being stolen is proprietary to you or, perhaps, to your company

So how can you protect against these types of attacks? One way is to protect each host machine that connects to the outside world separately You install security software so that any unauthorized attempts to access a machine generate alarms and reports to the network administrator. While this is good for small environments with a few hosts, it becomes difficult when the network grows to dozens-or scores-of network hosts. For large systems, a better way is to install network-based security The difference in this method is that you spend time looking at network issues that affect security rather than machine issues. For instance, two hosts in your system may deny service to anyone but users on a certain network. As long as the address trying to access them is on this network, the user is let in, using the host-based model. But what happens if an intruder spoofs (fools) the network into thinking that it is getting a request from a legitimate internal network address? With the network-based model, only one machine-the one that connects your network to the outside world-has to worry about monitoring the network for these illegal intrusions. This is the machine on which you put all of your firewall protection.

Intrusion Detection

You can also increase the security of your hosts using an intrusion detection system. An intrusion detection system attempts to determine when someone is trying to break into your system, or when someone has already successfully broken in. Among the intrusion detection systems available for variants of UNIX are PortSentry the Linux Intrusion Detection System (LIDS), and SNORT. PortSentry watches possible scans of network ports on your system that might indicate that your system is under attack. When PortSentry sees suspicious activity, it can takes various actions, depending on the contents of a configuration file. You can download PortSentry free of charge from http://sourceforge.net/projects/sentrytools/.

The Linux Intrusion and Detection System (LIDS) adds a module to the Linux kernel, together with a set of administration tools that implements Mandatory Access Controls. These controls can be used to block access to all users, including root, except that access to resources can be allowed by configuring LIDS. LIDS can detect port scanning within its kernel. It can hide files completely and make files read-only to everyone, using root, it can hide processes to everyone or block which other processes are able to send signals to particular processes. LIDS also supports access control lists, discussed in Chapter 12. LIDS provides time-based restrictions on when tasks can be performed or a file can be accessed. You can download LIDS and obtain more information about LIDS from http://www.lids.org/.

SNORT is an open-source network intrusion detection, and prevention, system. You can obtain SNORT free of charge from Sourcefire, which offers commercial versions with integrated hardware and support services. SNORT can perform real-time traffic analysis and packet logging on IP networks and can perform protocol analysis; carry out content searching and matching; and detect a variety of attacks and probes, including buffer overflows, stealth port scanning, and CGI attacks, as well as many other types of attacks. It can also be used to prevent intrusions, not just detect them. To download, and learn more about, SNORT, go to http://www.snort.org/.

Proxy Servers

As the number of users on your network grows, the amount of requests for information on the Internet grows. Although most of these requests are legitimate and pose no security threats, there are some that may To prevent unauthorized requests from being made to services outside your firewall, there is an additional service that can be used besides firewall software, called a proxy service. The function of a proxy service is to let a machine that connects your network to the outside world, called a proxy server, act on your behalf (proxy) to send requests.

When you request to access a specific network address or URL (see Chapter 10), your request goes to the proxy server. Depending on rules that are set up by the software running on the proxy server, you may either be allowed to connect to the end site or be denied. Examples of when you would be denied are when specific URLs are deemed inappropriate for access by business employees, or when the site that you want to access is known to be a malicious site that may introduce a virus into your network if you access it.

Squid

If you do not already have a proxy server installed on your network, you may want to install one. One option is to use Squid, a high performance proxy caching server for web clients. Squid is available for use free of charge for AIX, HP-UX, Solaris, Linux, Mac OS X, FreeBSD, OpenBSD, and NetSD, and other UNIX variants. You can download Squid from http://www.squid-cache.org/. You can also find directions and help for compiling, installing, and running Squid at this site. You can also consult Squid: The Definitive Guide by Duane Wessels, published by O’Reilly and Associates, to learn more about Squid.

We will not go into details about Squid or other proxy servers here. Instead, we will offer an overview of network administration issues involving proxy servers.

Administering Proxy Servers

Administering a proxy server basically centers on being aware of the potential for a breach of security or a misuse of the network. There are tools, called proxy monitors, that allow a network administrator to look at what sites are being accessed, how often, and by whom. By analyzing this information, a network administrator can determine whether or not to limit or completely eliminate the capability for users to access a particular site or network address via a proxy server. In addition to the security and misuse potentials, another potential issue can be addressed by monitoring your proxy server: performance. Since the proxy server acts as a “traffic cop” between the users and the outside world, its performance is directly related to the number of people that are trying to access it simultaneously A strong part of proxy server management is to track the load that is being placed on it at various times. From this analysis, the network administrator may implement one or two strategies to avoid congestion. The first method may be to implement additional proxy servers. When one becomes heavily used, users are switched over to another one to make their requests. This process will work until you are using the full capacity of the last available proxy server. Then, the network administrator may have to employ the second method, which is to restrict users or services on each proxy server. This second method can be done as effectively as the first, but you need to really understand the needs of your users before you attempt to implement this second solution instead of the first one.

Summary

One of the highlights of UNIX is its strong set of networking capabilities. This chapter has covered some aspects of administration of networking. Administration of TCP/IP networking, sendmail administration, and NFS has been discussed, as has NIS. We have talked about web-based network issues such as DNS, firewalls, proxy servers, and web security Because network administration can be quite complicated, complete coverage of this topic cannot be provided here. However, you should be able to use what you’ve learned here to get started in administering your network of UNIX system computers. Although you will find running networks challenging, you will discover that UNIX provides many tools to help you with this task.

How to Find Out More

A number of useful books are available on various aspects of network administration. For example, you will find the following books particularly helpful:

· Barnett, D.A., R.E. Silverman, and R.G. Byrnes. Linux Security Cookbook. Sebastopol, CA: O’Reilly, 2003.

· Burk, Robin, et al. UNIX Unleashed. 3rd ed. Indianapolis, IN: Howard W. Sams, 1998.

· Cervone, H. Frank. Solaris Performance Administration. New York: McGraw-Hill, 1998.

· Eisner, Mike, Ricardo Labiaga, and Hal Stern. Managing NFS and NIS. 2nd ed. Sebastopol, CA: O’Reilly. 2001.

· Hunt, Craig. TCP/IP Network Administration. 3rd ed. Sebastopol, CA: O’Reilly, 2002.

· Mansfield, Niall. Practical TCP/IP: Designing, Using, and Troubleshooting TCP/IP Networks on Linux and Windows. Reading, MA: Addison-Wesley, 2003.

· Wells, Nicholas. Guide to Linux Networking and Security. Boston, MA: Thompson, 2003.

Here are some references for network security administration:

· Zwicky, Elizabeth, Simon Cooper, and D. Brent Chapman. Building Internet Firewalls. 2nd ed. Sebastopol, CA: O’Reilly, 2000.

· Cheswick, William R., Steven Bellovin, and Aviel Rubin. Firewalls and Internet Security: Repelling the Wiley Hacker. 2nd ed. Boston, MA: Addison-Wesley, 2003.

· Freiss, Martin. Protecting Networks with SATAN. Sebastopol, CA: O’Reilly, 1998.

· Garfinkel, Simson, Gene Spafford, and Alan Schwartz. Practical UNIX and Internet Security. 3rd ed. Sebastopol, CA: O’Reilly, 2003.

· Smith, Peter G., Linux Network Security. Hingham, MA: Charles River Media, 2005.

· Wells, Nicholas, Guide to Linux Networking and Security. Boston, MA: Course Technology, 2002.

If you want to understand sendmail better, you can try

· Costales, Bryan, and Eric Allman. Sendmail 3rd ed. Sebastopol, CA: O’Reilly, 2002.

If you want to understand the IPv6 protocol, you might try

· Feit, Sidnie. TCP/IP: Architecture, Protocols, and Implementation with IPv6 and IP Security. New York: McGraw-Hill, 1998.

· Loshin, Peter. IPv6 Clearly Explained. San Francisco, CA: Morgan-Kaufmann Publishers, 1999.

If you want to use newsgroups to find out more about some of the topics covered in this chapter, you can try comp.security.firewalls and comp.security.misc for firewall information, comp.protocols.dns.std for DNS standards work, comp.protocols.nfs for NFS information, and comp.protocols.ppp for PPP information. For understanding network abuse and how it is being handled across the industry try the newsgroup news.admin.net-abuse. For more generic network administration topics, try comp.unix.