Questions and Answers

Bjorn Satdeva

Well, yet again an attack from the cracker community has made the news. Toward the end of January, the New York Times ran an article that was picked up by many other newspapers. The story told of a "new" kind of attack which left firewalls virtually defenseless. However, this "news" is really "same old, same old," since this kind of attack has been known for a long time. Robert T. Morris wrote a paper about it back in 1985, and Steve Bellovin wrote about it in 1989 (this paper is available from many places, including the COAST security archives via anonymous ftp from coast.cs.purdue.edu, as /pub/doc/authentication/Steven_Bellovin_TCP_IP.ps.Z). In other words, this kind of attack has been possible for over ten years, but a very recent increase in the number of attacks is the reason for the CERT (CA-95:01, January 23, 1995: "IP Spoofing Attacks and Hijacked Terminal Connections") and CIAC advisories (CIAC Advisory F-08: "IP Address Spoofing and Hijacked Session").

As mentioned above, the newspaper article reported that many firewalls are defenseless against these attacks. In reality, any well-designed firewall will not be vulnerable; unfortunately, however, many sites are connected to the Internet through either homegrown, inadequate firewalls or, in many cases, no firewall at all. Such sites are vulnerable to many kinds of attacks, but might not know that their security has been breached.

The primary attack uses IP sequence number spoofing, in combination with fake source addresses in the packets. Unfortunately, the CERT advisory was very vague and somewhat misleading, in that it made many people think that the problem was related to source routing (another can of worms waiting on the sidelines). It would have been very useful if the CERT advisory had given a clear description of the problem; on the other hand, in a country where suing each other is the favorite pastime, it is difficult to fault them for being careful.

In any case, a firewall which completely blocks any packet for the shell port (514) appears to be safe from this specific kind of attack. A firewall which can block all packets to or from the internal networks will be better. The best firewall design for withstanding this kind of attack is probably one based on a combination of routers and a bastion host with application proxies, such as SOCKS or fwtk. [Editor's note: See Chris Hare's "Network Construction: Using a Firewall" on page 8 of this issue for an extended overview of firewalls.]

Enough about security for now (even though we really never get enough). The next system administration conference is coming up in April, this time the System Administration, Networking and Security conference (SANS). The conference takes place in Washington, DC, April 24-29. Since I have been receiving more e-mail about conferences and the related tutorials than about anything else I address in this column, I have included a short description of the SANS tutorials in the sidebar. For more information about the SANS conference, call 719-599-4303.

Our file server has six disk drives all connected to one SCSI controller. Now our hardware support person has told me that I should not attach that many drives to a single controller. Is he right?

Depending on the usage pattern of your machine, he might be. In my experience, about four active disk drives on a SCSI bus appear to occupy the bus full time. More active drives than that, and the bus starts to be a bottleneck. The keyword here is "active." If, for example, you use one or more drives to keep old sources around for reference and those drives are rarely accessed, then they will not have much effect on the performance of the SCSI bus. Based on the information above, it sounds like a second controller may give you a better overall performance. However, you will also need to look at the other components of the system, as you will need that information to evaluate if the bottleneck is truly where you think it is. For example, if your CPU is also maxed out, or if it does not have enough memory (both can be checked with vmstat), then adding the second controller will have little or no effect.

I work at a small site, where we get our electronic mail over UUCP. I recently read about a utility which allows sites such as ours to send and receive mail, using SMTP across a UUCP link. What kind of software is needed to accomplish this, and where can I get it?

What you are referring to is known as Batched SMTP or BSMTP. Using this strategy, e-mail is queued up via the standard SMTP command language, but instead of connecting to the remote host over TCP, commands and data are stored into a text file, which is then queued up for transmission with UUCP. The trick is that the remote site must be able to receive and understand the e-mail in this format. If you are using smail3 (which in my opinion is the best mailer for a UUCP site), you are halfway there, since it already supports BSMTP. However, if the remote site does not run smail or does not support the BSMTP program (which can receive batched SMTP mail), you are out of luck. I recommend that you implement BSMTP, as it provides a much better mail transfer protocol than native UUCP. UUCP will still provide the underlying transport mechanism, but it will no longer be involved in the e-mail address resolution. Gone will be the bang-addresses and the munged e-mail headers.

I have been told that ftp is difficult to handle in a firewall. Why is that the case?

The person who told you this was probably thinking of how ftp uses both a control connection and a data connection, and how this can create problems for router-based firewalls. To understand this requires looking at how ftp transfers files.

The control connection is established first, in the usual manner. The server listens to the well-known port for ftp (21). When the client wants to connect to the server, it will connect to this port. This connection will stay up for the duration of the ftp session, independent of whatever commands are executed.

Each time a file is to be transferred between the two machines, a data connection will be opened, and the file will be transferred through this connection. The problem is that the client chooses a random port to use for the data transfer. It then listens to the chosen port, and also sends that port number to the server, via the control connection. The server then connects to that port for the duration of the transfer.

The problem, with respect to firewalls, is that you do not know which port will be used. Proxy-based firewalls do not have this problem, because the proxy software understands the underlying protocol. However, a firewall which depends heavily on filtering routers may have such problems, even though the filtering capabilities of the routers are being increased all the time.

You have previously described how to set up a split name server, using one name server on the firewall and one name server on the inside. We use NIS internally, and I would like to avoid having an inside name server. Is there a way to do this?

If your internal hosts need to be able to resolve the names and addresses of hosts on the Internet, you will have to bite the bullet, and either convert to using the name server, or set up a DNS tunnel for NIS (which is now much easier than it was a few years ago). However, if your firewall is of a type (as, for example, the TIS FIrewall tool kit) where the inside hosts connect to the firewall machine, which in turn connects to the Internet, you have a reasonable way out.

You'll need to acquire a version of the resolver which will also use /etc/hosts for host name lookup (this version is know as resolv+), and use it when you compile and link the software on the firewall bastion host, which talks to the machines on the inside. The resolver will then use the values in /etc/hosts to identify the machines. The disadvantage, of course, is that you need to keep the /etc/hosts file on the bastion host up-to-date. In my opinion, you are better off converting to DNS internally. This way you only need to maintain the data on your internal primary name server. You can, of course, use the DNS-to-NIS tunnel, but this is a one-way street, so if you do use that solution, you will need to maintain both the name server and the NIS map.

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.