Cover V05, I04


Questions & Answers

Bjorn Satdeva

The next major system administration related conference, the 5th UNIX System Administration, Networking & Security Conference (SANS) will take place in Washington, DC, May 12th to 18th. In my opinion, this conference and the LISA conference are the major system administration events of the year. The SANS conference has actually become four different programs combined into a single event, as it covers system administration, network administration, security, and new this year, WWW development and management.

Also, this year, the tutorials at SANS have been expanded to 22 tutorials spread out over 5 days. I think SANS and LISA offer some of the best tutorials around because, unlike with more commercial offerings, the teachers are people who offer experience they have gathered from working in these areas every day. This gives a different perspective of the topics covered, compared to that of a professional teacher who may never have worked in the system administration trenches. The teachers include luminaries such as Matt Bishop, Michele Crabb, Dan Geer, Rob Kolstad, Evi Nemeth, Marcus Ranum, and Gene Spafford

Besides the tutorials, there is a 3-day conference with invited and refereed papers, that often provide solutions that the attendees can apply immediately when they get back to work.

For more information, contact the SANS conference office at: Phone: 719-599-4303 FAX: 719-599-4395 Email WWW:

Tool of the Month

One of the biggest problems for many system administrators is keeping track of outstanding tasks. Working as a system administrator almost always means working in an environment in which interruption is the rule. It can be difficult not only to ensure that all reported problems get addressed, but also that users are kept up to date of progress on their specific problems.

This month's tool, req, can help you do just that. req is an email-based request tracking system, developed at Northeastern University. This Software implements a system where people with problems or questions can send requests via email to the system administration group responsible for dealing with those issues. Those requests can then be tracked and managed in various ways. You can get req from:

If you want to check out its predecessor, request, it can be found at:

For completeness, there is a third tool, gnats, from the GNU project. It was originally developed as a defect tracking system, and according to the GNU folks, it can be also used as a system administration task tracking tool. I have tried it, and have found it quite cumbersome to use, mostly because it is difficult to get a good overview of outstanding tasks. However, it too is available from the system administration source archive at:

An X11 front end to gnats can be found at:

Now to this month's questions:

 Q We currently archive all printer requests on our UNIX system in order to have the ability to regenerate reports when they fail. The problem is that we get too many requests for reprints, and many users only want a partial reprint. I considered setting up a structure that stores users' print requests in their home directories and then gives them a utility to reprint it, but rather than reinventing the wheel, I'm wondering if there's a package that does this. The other issue to consider is that we print jobs automatically on weekends. These jobs have a high reprint rate because they are printed unsupervised. We could put in a script to change to a specific user thereby storing the print job in his/her directory, but maybe there is an even better approach.

This must be an issue for many people, or perhaps they just live with the interruptions. Any help would be very much appreciated.

 A Based on the information information you have provided, it looks as if you are attempting to provide a technical solution to what essentially is a people problem. In my experience, this never works. If I were working with you as a consultant on this problem, the first thing I would ask is why people are requesting so many reprints. Your question indicates that the reprints present a severe load on your system, and if the need for the reprints can be reduced, then you have a better (and simpler) solution than any reprint management system you can invent would be able to provide.

In a more generic sense, it is always important that the system administrator maintain a distance to the problems that require a solution. I know it is often very, very hard to remember that the task is to drain the sump, when you are wading up to your knees in alligators, but unless you are to take the more distant view, it is not likely you will be able to solve the problem in a sustainable manner. As a consultant, I often see clients so bogged down in the specifics of the problem they are attempting to solve that they are unable get the bigger picture. Often I end up helping the client define the high level concept of what they are attempting to do.

Now, after that lecture, I'll get off my high horse and try to help with the direct question. I do not know of any publicly available package may be able to do what you want. You may have to look at a commercial package. There are commercial packages that implement printer management, à la mainframe, that may be able to provide you with the necessary solution.

 Q We are currently in the process of researching possible firewall solutions for our Internet connection. We are confused by the fact that some vendors claim that a secure firewall must be proxy based, while others claim that it makes no difference. What is your take on this?

 A This is a highly charged emotional and religious issue. Before I give you my answer, let me first explain the two different approaches to implementing a firewall and give some background information that will make it easier to understand the issues.

A packet filter implements a strategy whereby each packet arriving at the firewall is examined, and the router or host that is running the packet filter will decide, on a packet by packet basis, whether the packet should be routed toward its destination or should be dropped. Legacy packet filters have some severe shortcomings, because it is necessary to poke big holes in the filter in order to allow very desirable services, such as ftp, through the packet filter. Modern packet filters, such as Sun Microsytems' SunScreen and CheckPoints Firewall-1 use what are commonly called dynamic packet filters, in which the filter rules are rewritten on the fly.

A proxy on the other hand makes this decision in the context of the connections. There are two different strategies used to implement a proxy, circuit level proxies and application level proxies. The circuit level proxy is in some respect similar to a packet filter, as it will determine up front whether the connection should be allowed or denied. Because this decision is made at the beginning of the connection, the circuit level proxy will often be able to provide a better feedback in its logging than a packet filter. (An example of a circuit level proxy is the publicly available packet SOCKS (written by Dave Koblas), which is utilized in some commercial firewalls, such as IBM's NetSP, and in a redesigned version in NEC PrivateNet's SocksPlus implementation.

The application level proxy differs from circuit level proxy because it is a dedicated proxy for a single protocol, such as SMTP or telnet. Thus, it understands the underlying protocol and can make determinations about which commands and actions should be allowed. This allows the application level proxy to be made very secure, but at the cost of implementing a new set of software for each new application protocol. Also, it can sometimes be difficult to implement such proxies in a transparent manner (but then you do not always want such proxies to be completely transparent, for example, a telnet proxy is likely to include some kind of authentication).

In terms of which technology is more secure, I agree with the people who told you that proxy servers are more secure. However, when you look at the bigger picture, you will need to take into account the overall level of security in the existing network. If you evaluate the security of the firewall itself, and ignore the rest of the network, you might end up with installing an iron door in a cardboard house. In a number of instances in which I have evaluated the security of a firewall, I have found that it is almost a moot point due to lack of security in other areas. Selection, installation, and configuration of a firewall must be part of an overall strategy defining and implementing an appropriate level of security for the organization. In other words, although a firewall based on packet filter technology may be less secure than a proxy-based one, it might still be the most appropriate overall choice for an organization.

Also, a firewall can only enforce access control rules for a connection that parses through that firewall. It will do no good at all if the intruders can get in through other means, for example through modem connections. Therefore, when evaluating firewalls (whether they are commercial or freeware implementations), you must do that evaluation from an overall perimeter security point of view. This entails all outgoing network connections, including connections to any computer or network that is not part of the local administrative domain, all modem connections, and also nontechnical areas related to what is often called social engineering. In my opinion, it is not possible to build a firewall that cannot be breached. Even a firewall that is very strong from a technical perspective can be breached by bribing one or more of the people working for the victim organization.

 Q We will soon connect to the Internet. However, we are internally heavily dependent on NIS, and although I would prefer to use the Domain Name Server everywhere, this is currently not politically an option. It is, of course, possible to use the DNS tunnel in NIS, but I am not too happy maintaining two different name resolution schemes. Do you have any solution to this problem?

 A Cheat! If the hostname database used by NIS is empty, then it will always use the DNS to resolve hostnames. In this way, you will be able to fulfill the political requirement of using NIS, while in fact you only need to maintain one hostname resolution scheme the Domain Name Server. Anybody who wants to use only the DNS will be able to do so, without having to maintain the information for internal hosts in two different formats.

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.