Some advanced security measures can be put into place to further protect your system from “marauders.” The SENDFILES, REQUEST, VALIDATE, and CALLBACK options are, after proper login and password controls, the next step in UUCP security measures. VALIDATE validates the hostname of the calling system, and terminates the call if the caller does not have one of the listed hostnames. The following line shows how this option is used:

LOGNAME=choreo    VALIDATE=choreo:gateway

If a system logs in to the machine using the logname of choreo, but it isn’t the machine choreo or a gateway, the call will be terminated. To further inform you of who is calling, the CALLBACK feature can be used. With this option, the calling system is told during the negotiation that your system must call them back. Your system terminates the call, and then uses the information in the Systems file to call the remote machine. In this case, no work will take place until your system calls back the remote machine. The CALLBACK feature can also be used to determine who will pay for the phone call.

The SENDFILES option determines whether your system will send locally queued work after the remote has finished with its requests. Suppose, for example, that a machine called wabbit and another called thumper are communicating. A user on thumper initiates a request to send a file to wabbit. A user on wabbit starts a UUCP job to send a file to thumper. The Permissions entry for thumper on the machine wabbit has SENDFILES=call. The system thumper calls wabbit, logs in, and sends the file to wabbit. The call is terminated at this point, even though wabbit has a job to send to thumper. The call is terminated because the SENDFILES=call option indicates that jobs will NOT be sent to the remote machine if it calls; only if the local machine calls the remote machine.

In addition to SENDFILES, you can set the value REQUEST=no so that remote systems cannot request files from you. With both SENDFILES and REQUEST set this way, your system is pretty much in control of what is going on, regardless of the CALLBACK and VALIDATE values. The reason: all work destined for outside of your system must originate with your system.

---

Note:  Two things to watch for when using SENDFILES and CALLBACK: if both systems are set CALLBACK=yes, or one system is set CALLBACK=yes and the other is SENDFILES=call, no work will be performed in either case.

---

Allowing Anonymous UUCP Access

As in any situation where unauthenticated or anonymous access to a system is granted, there are certain risks that have to be accepted, and certain steps to take in protecting your assets. This is also true for UUCP. You might need to set up anonymous UUCP access at some point, or disable it. Being able to deal with either case results from a through knowledge of the security problems for such a setup, and how they can be minimized with a proper Permissions entry. During anonymous UUCP setup, you need to include two steps. The first step is to define a generic entry in Permissions:

#
# For ANONYMOUS LOGINS
#
LOGNAME=nuucp

Make sure a user login account exists on your system called nuucp, and executes the uucico program as its login shell. If this account doesn’t exist, make one. By defining only the LOGNAME option, any system that calls and uses the login name “nuucp” is granted only the DEFAULT permissions:

READ=/usr/spool/uucppublic
WRITE=/usr/spool/uucppublic
REQUEST=no
SENDFILES=call
COMMANDS=rmail

With this configuration, the amount of information users can get is limited. You probably will be setting up anonymous UUCP so that employees or outside users can download information. If this is the case, you may want to change REQUEST= to YES.

The second step concerns checking for or creating a file in the /usr/lib/uucp /directory called “remote.unknown.” The normal mode of operation in BNU requires that machines must exist in each other’s Systems files for the conversation to be successful. If a machine name does not exist, the program searches for remote.unknown. If it is found and is executable, the call is connected, the contents of the file are executed, and the call is then terminated. A sample remote.unknown file is listed here:

#!/bin/sh
#ident    “@(#)uucp:remote.unknown    2.3”
FOREIGN=/usr/spool/uucp/.Admin/Foreign
echo “`date`: call from system $1” >> $FOREIGN

For each unknown system that is it is missing from the Systems file, the remote.unknown script is executed. To prevent this from occurring, remove the execute bits using the chmod command. This allows calls from all unknown systems.