Cover V04, I01
Figure 1
Sidebar 1


Questions and Answers

Bjorn Satdeva

Firewalls are a hot topic these days. Several companies have announced firewall products over the last few months, and in recent days we have even seen an announcement from Big Blue. Unfortunately, not all commercial offerings are of the high quality we could want. The good news is that the Internet Engineering Task Force has convened a working group to create a standard (RFC), to be based on the SOCKS protocol originally designed and implemented by Dave Koblas. The IBM firewall, along with several other upcoming products, is based on SOCKS, and the new NetScape client program from Mosaic, Inc., uses it. It is still much to early to tell for sure, but it looks like the marketplace is converging towards SOCKS as the firewall strategy of choice.

As I promised in an earlier column, I am including an overview of the 1994 SANS System Administrator Salary Survey, conducted by Alan Paller, the moving force behind the SANS conferences. More than 650 surveys, including many from Sys Admin readers, were returned, making this the most comprehensive survey of its kind to date. The results of the survey are too large to print here in their totality, but I've reported some of the most essential findings in the sidebar, "Selected Information from the SANS Salary Survey," where you will also find information on how to request a more complete report.

And speaking of conferences, the winter USENIX conference takes place January 16th to 20th. I have written a lot about USENIX in past columns, so will keep it short this time. However, this conference is a very good place to go both for its useful tutorials and as a place to meet your peers. Contact information for USENIX is below.

 Q I have recently started to administer a small network of UNIX systems, and I am trying to understand routing. Can you help?

 A Complete coverage of routing and routing protocols would require a book, so I will limit this answer to the basics. The kernel needs routing information to determine where a given packet must be sent in order for it to arrive at its destination. If you only have one network where all hosts are directly connected, this is easy, as the necessary routing information will automatically be entered into the kernel's routing tables by the ifconfig utility (which is used to bring up the ethernet controller). However, if you have more than one network, it is no longer as simple, and you will need to explicitly add information to the kernel routing table.

In real life, you would normally use a program such as gated to maintain the kernel tables more or less automatically. However, before you can start to understand how such programs work, you will need to understand the most basic form of routing, usually referred to as static routing. With static routing, each route is added into the kernel route table by the route utility and this information will never change of its own accord.

Each route added to the table tells the kernel where it should send a packet for a given network. Therefore, each route command will consist of two pieces of information, a network address and the IP address (on the local network) where the packet for that network should be sent. A somewhat simplistic example is shown in Figure 1, where hosts are represented by upper-case letters and networks by lower-case letters (you name your networks using the /etc/networks file). In the example in Figure 1, if the host "A" needs to send a packet to some host on the network "c", it cannot reach that host directly, but it can talk to the host "C", which in turn can talk to all hosts on the "c" network. You can add a route on "A" which tells the kernel that any packet destined for the "c" network should be sent to host "C," which will know how to forward the package. In this case, the complete routing on "A" can be configured by adding the following route statements to a startup file to be executed during boot:

route add -net b B
route add -net c C
route add -net d D
route add -net e E

If this were a real case, you would use the raw IP addresses for both hosts and networks rather than the names, since at bootup your name service would probably not be available.

One more point: if you are connected to the Internet, you do not want to keep the routes to all possible networks in the world in your kernel's routing table; it would take way too much memory and would be a nightmare to maintain. The kernel therefore needs a default route, that is, the route to be used when no other route in the kernel table matches your need. The default route on any system should always point in the direction of the Internet gateway. You can also use the default route on hosts connected to only one network (this is most likely the case for all your workstations, but may not be the case for your servers), to point to the one host on the network that is connected to the rest of your local network.

Using static routes is complicated and can take a great deal of work to maintain when the network changes. If your site has more than just a few networks, you will need to use tools that maintain the routing tables dynamically. Several different programs can do this, but in my opinion the best is gated, which is available by anonymous ftp from

 Q I have been volunteered to become a system administrator and need to climb the learning curve fast. Along with getting Sys Admin, I have been told to "get in touch with LISA and go to the Usenix (sp?) conference." Can you point me in the right direction and make any other suggestions?

 A Subscribing to Sys Admin and attending the relevant conferences will certainly give you what looks like a much-needed boost. Attending the tutorials at either the LISA System Administration conference, the USENIX main conferences, or the SANS (System Administration, Networking and Security) conference will give you much information to work with. I like to recommend these tutorials because they are presented by people who work with the material they teach on a daily basis. In addition to this, there are now many good (and even more not-so-good) books available on various topics related to system administration. A very good overall book is Evi Nemeth's UNIX System Administration Handbook, from Prentice Hall; it is now several years old, but is still one of the best of its kind on the market, and an updated version will be out soon.

There are specialized books available from many sources, but the overall best selection can be found from O'Reilly and Associates, where Tim O'Reilly has for many years been working towards a very comprehensive coverage of UNIX. Depending on your specific area of responsibility, some of the O'Reilly books you might want to check out are:

  • TCP/IP Network Administration, by Craig Hunt

  • Managing NFS and NIS, by Hal Stern

  • DNS and BIND, by Cricket Liu and Paul Albitz

  • Practical UNIX Security, by Simson Garfinkel and Gene Spafford

  • sendmail, by Bryan Costales, with Eric Allman and Neil Rickert

  • Managing UUCP and Usenet, by Tim O'Reilly and Grace Todino

    Other good books are available, but the above represent a very good basic library and should keep you busy for a while. If you cannot get the books from a local bookstore, you can send e-mail to Computer Literacy at, where they should be able to help you. O'Reilly maintains an online catalog at

    Finally, you will probably find the proceedings of the past LISA and SANS conferences useful (LISA IV and SANS III, to the present). They are all available from the USENIX conference office:

    USENIX Conference Office 22672 Lambert Street, Suite 613 El Toro, CA 92630 USA (714) 588-8649; FAX: (714) 588-9706 E-mail:

    You will also be able to find some of the papers from past conferences on, an archive maintained by Mark Verber from Xerox Parc.

     Q I'm taking a course which looks into the different aspects of the Internet and I need some information on expanding email delivery to incorporate a confirmed delivery time. I was wondering if you had any thoughts on this matter. Any help would be appreciated.

     A It would have been good if you had included a bit more context, such as whether the delivery time in question is for the local mail reader, or whether you expect to get a return receipt back with the delivery time at the destination. However, as each such issue can cast light on how the e-mail delivery system works, I will address several of them.

    First, the recipient of the mail can see not only the time of delivery in the mail headers, but also the time of delivery for each host the mail has passed through. Each such host adds a "Received" line, which tells the time of delivery on that host. The following example is taken from a real message, with a line number prepended to the description:

    1: Received: from by ( with ESMTP id SAA05594
    for <>; Thu, 8 Dec 1994 18:07:15 -0800
    2: Received: from localhost (ftp@localhost)
    by (8.6.9/8.6.5) id RAA09949
    for <>; Thu, 8 Dec 1994 17:57:22 -0800
    3: Received: from
    by via smap (V1.3mjr)
    id sma009945; Thu Dec  8 17:56:55 1994
    4: Received: by relay2.UU.NET
    id QQxtle22937; Thu, 8 Dec 1994 16:39:21 -0500
    5: Received: from hofmann.CS.Berkeley.EDU by relay2.UU.NET with SMTP
    id QQxtle22917; Thu, 8 Dec 1994 16:39:15 -0500
    6: Received: from ( [])
    by hofmann.CS.Berkeley.EDU (8.6.9/8.6.6.Beta11) with SMTP
    id NAA23544 for <>;
    Thu, 8 Dec 1994 13:39:13 -0800
    7: Received: from USENET by id aa29767; 8 Dec 94 13:39 PST
    8: Received: from by id aa29752;
    8 Dec 94 13:38 PST
    9: Received: by id AA22388
    (5.65c/IDA-1.4.4 for; Thu, 8 Dec 1994 13:38:42 -0800

    Line one is from the final delivery, which took place on Thursday, December 8th, 1994. Each received line lists which host received the email, and from whom, and often which protocol and version of the software was used. There is not a fixed format for the "Received" header, and each header can span several lines, so long as subsequent lines start with a tab. The main purpose of the "Received" headers is to enable a postmaster to track down problems, such as large delays in the delivery; for most everyday users of email, they are of little interest.

    If you are sending email to a remote host and you want a return receipt with the delivery time, the problem gets a good deal more problematic. There is no way that you can guarantee that you will get the delivery date back, but sendmail does support a "Return-Receipt-To" header, which will cause the remote host to bounce the message back to the sender with a subject line which says "Subject: Returned mail: Return Receipt" to the address specified in the "Return-Receipt-To" header. This may do what you want, as long as the remote site has not turned this feature off. However, if you are hacking your to always include the "Return-Receipt-To" you might find that unexpected side effects may completely break your mail systems, especially if you are running a mailing list or are using exploding aliases. These can cause mail loops which will bring your system to a grinding halt from many, many sendmail processes.

    Let me finish with a word of warning. The e-mail system is more complex than it might appear at a glance, and tinkering with rewrite rules or header intrepretaion may cause unexpected side effects, some of which may not show up for quite some time. If you are writing your own specialized delivery agent, you not only need to look for correct behavior according to the various RFCs, you also need make sure that it does not contain subtle bugs which can be exploited by the cracker community. Even if you know what you're doing, the latter is always a possibility, as we have seen only too many times over the years.

    About the Author

    Bjorn Satdeva is the president of /sys/admin, inc., a consulting firm which specializes in large installation system administration. Bjorn is also co-founder and former president of Bay-LISA, a San Francisco Bay Area user's group for system administrators of large sites. Bjorn can be contacted at /sys/admin, inc., 2787 Moorpark Ave., San Jose, CA 95128; electronically at; or by phone at (408) 241-3111.