Linux Network Administrator Guide, Second Edition

If you have enabled call sequence checks, you should check your log files regularly for error messages that hint at possible attacks. If your system rejects the call sequence number the calling system offers, uucico will put a message into the log file saying something like, 'Out of sequence call rejected.' If your system is rejected by its feed because the sequence numbers are out of sync, it will put a message in the log file saying, 'Handshake failed (RBADSEQ).'

To enable call sequence checks, add the following command to the system entry:

# enable call sequence checks
sequence true

In addition, you have to create the file containing the sequence number itself. Taylor UUCP keeps the sequence number in a file called .Sequence in the remote site's spool directory. It must be owned by uucp and must be mode 600 (i.e., readable and writeable only by uucp). It is best to initialize this file with an arbitrary, previously agreed-upon start value. A simple way to create this file is:

# cd /var/spool/uucp/pablo
# echo 94316 ›.Sequence
# chmod 600.Sequence
# chown uucp.uucp.Sequence

Of course, the remote site has to enable call sequence checks as well and start by using exactly the same sequence number as you.

Anonymous UUCP

If you want to provide anonymous UUCP access to your system, you first have to set up a special account for it as previously described. A common practice is to give the anonymous account a login name and a password of uucp.

In addition, you have to set a few of the security options for unknown systems. For instance, you may want to prohibit them from executing any commands on your system. However, you cannot set these parameters in a sys file entry because the system command requires the system's name, which you don't have. Taylor UUCP solves this dilemma through the unknown command. unknown can be used in the config file to specify any command that can usually appear in a system entry:

unknown remote-receive ~/incoming unknown remote-send ~/pub unknown max-remote-debug none unknown command-path /usr/lib/uucp/anon-bin unknown commands rmail

This will restrict unknown systems to downloading files from below the pub directory and uploading files to the incoming directory below /var/spool/uucppublic. The next line will make uucico ignore any requests from the remote system to turn on debugging locally. The last two lines permit unknown systems to execute rmail; but the command path specified makes uucico look for the rmail command in a private directory named anon-bin only. This restriction allows you to provide some special rmail that, for instance, forwards all mail to the superuser for examination. This allows anonymous users to reach the maintainer of the system, but at the same time prevents them from injecting any mail to other sites.

To enable anonymous UUCP, you must specify at least one unknown statement in config. Otherwise uucico will reject all unknown systems.

UUCP Low-Level Protocols

To negotiate session control and file transfers with the remote end, uucico uses a set of standardized messages. This is often referred to as the high-level protocol. During the initialization phase and the hangup phase these are simply sent across as strings. However, during the real transfer phase, an additional low-level protocol that is mostly transparent to the higher levels is employed. This protocol offers some added benefits, such as allowing error checks on data sent over unreliable links.

Protocol Overview

UUCP is used over different types of connections, such as serial lines, TCP, or sometimes even X.25; it is advantageous to transport UUCP within protocols designed specifically for the underlying network protocol. In addition, several implementations of UUCP have introduced different protocols that do roughly the same thing.

Protocols can be divided into two categories: streaming and packet protocols. Protocols of the streaming variety transfer a file as a whole, possibly computing a checksum over it. This is nearly free of overhead, but requires a reliable connection because any error will cause the whole file to be retransmitted. These protocols are commonly used over TCP connections but are not suitable for use over telephone lines. Although modern modems do quite a good job at error correction, they are not perfect, nor is there any error detection between your computer and the modem.

On the other hand, packet-oriented protocols split up the file into several chunks of equal size. Each packet is sent and received separately, a checksum is computed, and an acknowledgment is returned to the sender. To make this more efficient, sliding-window protocols have been invented, which allow for a limited number (a window) of outstanding acknowledgments at any time. This greatly reduces the amount of time uucico has to wait during a transmission. Still, the relatively large overhead compared to a streaming protocol makes packet protocols inefficient for TCP use, but ideal for telephone lines.

The width of the data path also makes a difference. Sometimes sending 8-bit characters over a serial connection is impossible; for instance, the connection could go through a stupid terminal server that strips off the eighth bit. When you transmit 8-bit characters over a 7-bit connection, they have to be quoted on transmission. In the worst-case scenerio, quoting doubles the amount of data to be transmitted, although compression done by the hardware may compensate. Lines that can transmit arbitrary 8-bit characters are usually called 8-bit clean. This is the case for all TCP connections, as well as for most modem connections.

Taylor UUCP 1.06 supports a wide variety of UUCP protocols. The most common of these are:

g

This is the most common protocol and should be understood by virtually all uucico s. It does thorough error checking and is therefore well suited for noisy telephone links. g requires an 8-bit clean connection. It is a packet-oriented protocol that uses a sliding-window technique.

i

This is a bidirectional packet protocol, which can send and receive files at the same time. It requires a full-duplex connection and an 8-bit clean data path. It is currently understood by Taylor UUCP only.

t

This protocol is intended for use over a TCP connection or other truly error-free networks. It uses packets of 1,024 bytes and requires an 8-bit clean connection.

e

This should basically do the same as t. The main difference is that e is a streaming protocol and is thus suited only to reliable network connections.

f

This is intended for use with reliable X.25 connections. It is a streaming protocol and expects a 7-bit data path. 8-bit characters are quoted, which can make it very inefficient.