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.
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 gated.cornell.edu.
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:
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 info@clbooks.com, where they should be able to help you. O'Reilly maintains an online catalog at gopher.ora.com. 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: conference@usenix.org You will also be able to find some of the papers from past conferences on ftp.sage.usenix.org, an archive maintained by Mark Verber from Xerox Parc.
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 heimdal.sysadmin.com by thor.sysadmin.com (8.6.9.1/8.6.5) with ESMTP id SAA05594 for <bjorn@thor.sysadmin.com>; Thu, 8 Dec 1994 18:07:15 -0800 2: Received: from localhost (ftp@localhost) by heimdal.sysadmin.com (8.6.9/8.6.5) id RAA09949 for <bjorn@sysadmin.com>; Thu, 8 Dec 1994 17:57:22 -0800 3: Received: from relay2.uu.net(192.48.96.7) by heimdal.sysadmin.com 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 ics.uci.edu (ics.uci.edu [128.195.1.1]) by hofmann.CS.Berkeley.EDU (8.6.9/8.6.6.Beta11) with SMTP id NAA23544 for <bind@ucbarpa.berkeley.edu>; Thu, 8 Dec 1994 13:39:13 -0800 7: Received: from USENET by q2.ics.uci.edu id aa29767; 8 Dec 94 13:39 PST 8: Received: from news.service.uci.edu by q2.ics.uci.edu id aa29752; 8 Dec 94 13:38 PST 9: Received: by news.service.uci.edu id AA22388 (5.65c/IDA-1.4.4 for fa-bind@ics.uci.edu); 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 sendmail.cf 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 bjorn@sysadmin.com; or by phone at (408) 241-3111.
|
I have recently started to administer a small network
of UNIX systems, and I am trying to understand routing.
Can you help?
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.