10.3 Modems and Unix | Practical Unix & Internet Security, 3rd Edition

Unix can use modems both for placing calls (dialing out) and for receiving them (letting other people dial in).

Broadly speaking, there are four ways to initiate a modem call on a Unix system; several of these are considered archaic and obsolete, but are still widely available:

Calls can made with the user -level tip or cu commands

If you call a computer that's running the Unix operating system, you may be able to use a simple file-transfer system built into tip and cu . Unfortunately, such a system performs no error checking or correction and works only for transferring text files.

Calls can be initiated with a terminal emulator

Terminal-emulation programs are designed to dial up remote systems and behave like a terminal; they also often support reliable file transfers with protocols designed for serial communication. kermit is a once popular terminal-emulation and file-transfer program developed by Columbia University. Versions of kermit are available for an astonishing variety of computer systems. Several other free software terminal emulators, such as minicom , are also commonly used.

Calls can be initiated with UUCP

UUCP (Unix-to-Unix Copy System) is a primitive system for transferring files and performing remote job execution. Although once popular, UUCP has been largely replaced by SLIP and PPP (see the next item).

There are many security issues that arise when using UUCP. Although we detailed those issues in the first and second editions of this book, we've removed the UUCP section from this edition. Today, UUCP is such an arcane system that most security professionals no longer know how to properly audit a UUCP installation. For this reason, UUCP should no longer be used in environments that require security.

Calls can be initiated using Unix SLIP or PPP clients

SLIP is the Serial Line Internet Protocol to a remote SLIP server; PPP is the Point-to-Point Protocol to a remote PPP server. Such a phone call creates a point-to-point Internet connection between the two systems. Any Internet service can then be run over this connection, including telnet , ssh , ftp , http , and so on.

You can also set up your computer's modem to let people with their own modems call into your computer. Unix systems can handle inbound modem calls in two ways:

The caller can be prompted to provide a username and a password. If this information is correctly provided, the Unix system can present the caller with an interactive shell.
The Unix system can be configured so that a PPP packet forces the system to enter the PPP subsystem. Authentication is then performed with a PPP protocol such as PAP (Password Authentication Protocol) or CHAP (Challenge Handshake Authentication Protocol). Once authentication is completed, a PPP network connection is established. Some Unix systems also support SLIP connections, but SLIP has traditionally had less support for cryptographic authentication protocols than PPP.

10.3.1 Connecting a Modem to Your Computer

Because every computer and every modem is a little different, follow your manufacturer's directions when connecting a modem to your computer. Usually, there is a simple, ready-made cable that can be used to connect the two. If you are lucky, that cable may even come in the same box as your modem.

If you're running Unix on PC hardware, your modem may instead be on a card that is installed inside the computer's case, in a slot on the motherboard (if it's a PC laptop, the modem may already be wired directly into the motherboard).

After the modem is physically connected, you will need to set up a number of configuration files on your computer so that your system knows where the modem is connected and what kind of commands it responds to.

On Berkeley-derived systems, you may have to modify the files /etc/ttys and /etc/remote to use the cu and tip commands. On System V systems, you may have to modify the file /etc/inittab .

Depending on the software you are using, you should also check the permissions on any configuration files used with your modem software. These may include files of commands, phone numbers , PPP or SLIP initialization values, and so on. As the number and location of these files vary considerably from system to system, we can only suggest that you read the documentation carefully for the names of any auxiliary files that may be involved. Pay special attention to any manpages associated with the software, as they often include a section entitled "Files" that names associated files.

10.3.2 Setting Up the Unix Device

Each version of Unix has one or more special devices in the /dev directory that are dedicated to modem control. Some of the names that we have seen are:

 /dev/cua* /dev/ttyda /dev/ttys[0-9] /dev/tty1A /dev/modem /dev/ttydfa

Some versions of Unix use the same devices for inbound and outbound calls; others use different names for each purpose, even though the names represent the same physical device. Check your documentation to see what the filenames are for your system.

Permissions for the Unix devices associated with inbound modems should be set to mode 600 and owned by either root or uucp . If the modem device is made readable by group or world, it might be possible for users to intercept incoming phone calls and eavesdrop on ongoing conversations, or create Trojan horse programs that invite unsuspecting callers to type their usernames and passwords.

Permissions for the Unix devices associated with the outgoing modems should also be set so that the modems cannot be accessed by ordinary users. Usually, these permissions are achieved by setting the devices to mode 600, and are owned by either root or uucp . To make an outgoing call, users must then use a specially designated communications program such as tip or cu . These systems must be installed SUID or SGID so that they can access the external device.

You can check the ownership and modes of these devices with the ls command:

 %  ls -lgd /dev/cu*  crw----- 1 uucp     wheel    11,192 Oct 20 10:38 /dev/cua crw----- 1 uucp     wheel    11,193 Dec 21 1989  /dev/cub %

10.3.3 Checking Your Modem

After your modem is connected, you should thoroughly test its ability to make and receive telephone calls. First, make sure that the modem behaves properly under normal operating circumstances. Next, make sure that when something unexpected happens, the computer behaves in a reasonable and responsible way. For example, if a telephone connection is lost, your computer should kill the associated processes and log out the user, rather than letting the next person who dials in type commands at the previous shell. Most of this testing will ensure that your modem's control signals are being properly sent to the computer (so that your computer knows when a call is in progress), as well as ensuring that your computer behaves properly with this information.

10.3.3.1 Originate testing

If you have configured your modem to place telephone calls, you need to verify that it always does the right thing when calls are placed and when they are disconnected.

To test your modem, you must call another computer that you know behaves properly. (Do not place a call to the same computer that you are trying to call out from; if there are problems, you may not be able to tell where the problem lies.)

Test as follows :

Try calling the remote computer with the tip or cu command or a terminal-emulation program. Each time the computer answers, you should get a login : prompt. You should be able to log in and use the remote computer as if you were connected directly.
Hang up on the remote computer by pulling the telephone line out of the originating modem. Your tip or cu program should realize that the connection has been lost and return you to the Unix prompt.
Call the remote computer again. This time, hang up by turning off your modem. Again, your tip or cu program should realize that something is wrong and return you to the Unix prompt.
Call the remote computer again. This time, leave the telephone connection intact and exit your tip or cu program by typing the following sequence:
```
 carriage return, tilde (~), period (.), carriage return 
```
Your modem should automatically hang up on the remote computer.
Call the remote computer one last time. This time, do a software disconnect by killing the tip or cu process on your local computer from another terminal. (You may need to be the superuser to use the kill command to kill the other process. See Appendix B for details about how to use these commands.) Once again, your modem should automatically hang up on the remote computer.

The preceding sequence of steps checks out the modem control signals between your computer and your modem. If things do not work properly, then one of the following may be the problem:

The cable connecting your modem and computer may be shorting together several pins, may have a broken wire, or may be connecting the wrong pins on each connector.
Your computer's serial interface may not properly implement flow control or modem control signals. On some systems, for instance, the first serial port implements all control lines, but other serial ports do not.
Your modem may not be properly configured. Many modems have switches or internal registers that can make the modem ignore some or all of the modem control signals.
You may be using the wrong Unix device. Many versions of Unix have several different devices in the /dev directory that refer to a single physical serial port. Usually, one of these devices uses the modem control signals, while others do not. Check your documentation and make sure you're using the proper device.
Lightning or another power event may have caused a telephone line power surge that damaged the modem.

Other things to check for dialing out include:

Make sure there is no way to enter your modem's programming mode by sending an escape sequence. An escape sequence is a sequence of characters that lets you reassert control over the modem and reprogram it. Most modems that use the AT command set (originally developed by the Hayes modem company), for example, can be forced into programming mode by allowing a three-second pause; sending three plus signs (+), the default escape character, in quick succession; and waiting another three seconds. If your modem prints "OK," then your modem's escape sequence is still active. Many Unix modem control programs disable the modem's escape sequence, but some do not.

On some modems, for example, sending the sequence "+++\rATH0;ATDT611" causes the modem to hang up the phone and dial "611," the universal number for telephone repair. (While some modems require a 3-second pause between the "+++" and the "\r", other modems do not, because the 3-second pause was patented by Hayes, and many modem vendors chose not to license the patent.)

If your modem's escape sequence is not disabled, consult your modem documentation or contact your modem vendor to determine how to disable the sequence. This step may require you to add some additional initialization sequence to the modem software or to set some configuration switches.
Verify that your modems lock out concurrent access properly. Be sure that there is no way for one user to make tip or cu use a modem that is currently in use by another user.
Finally, verify that every modem connected to your computer works as indicated above. Both cu and tip allow you to specify which modem to use with the -l option. Try them all.

If the cu or tip program does not exit when the telephone is disconnected, or if it is possible to return the modem to programming mode by sending an escape sequence, a user may be able to make telephone calls that are not logged. A user might even be able to reprogram the modem, causing it to call a specific phone number automatically, no matter what phone number it was instructed to call. At the other end, a Trojan horse might be waiting for your users.

If the modem does not hang up the phone when tip or cu exits, it can result in abnormally high telephone bills. Perhaps more importantly, if a modem does not hang up the telephone when the tip or cu program exits, then your user might remain logged into the remote machine. The next person who uses the tip or cu program would then have full access to that first user's account on the remote computer.

10.3.3.2 Answer testing

To test your computer's answering ability, you need another computer or terminal with a second modem to call your computer.

Test as follows:

Call your computer. It should answer the phone on the first few rings and print a login : banner. If your modem is set to cycle among various baud rates, you may need to press the BREAK or linefeed key on your terminal a few times to synchronize the answering modem's baud rate with the one that you are using. You should not press BREAK if you are using a modem that automatically selects baud rate.
Log in as usual. Type tty to determine for sure which serial line you are using. Then log out. Your computer should hang up the phone. (Some versions of System V Unix will instead print a second login : banner. Pressing Ctrl-D at this banner may hang up the telephone.)
Call your computer and log in a second time. This time, hang up the telephone by pulling the telephone line out of the originating modem. This action simulates having the phone connection accidentally broken. Call your computer back on the same telephone number. You should get a new login : banner. You should not be reconnected to your old shell; that shell should have had its process destroyed when the connection was broken. Type tty again to make sure that you got the same modem. Use the ps command to ensure that your old process was killed . Unix must automatically log you out when the telephone connection is broken. Otherwise , if the telephone is accidentally hung up and somebody else calls your computer, that person will be able to type commands as if he was a legitimate user, without ever having to log in or enter a password.
Verify that every modem connected to your computer behaves in this manner. Call the modem with a terminal, log in, then unplug the telephone line going into the originating modem to hang up the phone. Immediately redial the Unix computer's modem and verify that you get a new login : prompt.

Even though Unix should automatically log you out when you hang up the telephone, do not depend on this feature. Always log out of a remote system before disconnecting from it.
If you have several modems connected to a hunt group (a pool of modems where the first non-busy one answers, and all calls are made to a single number), make sure that the group hunts properly. Many don't ”which results in callers getting busy signals even when there are modems available. Some stop hunting if they connect to a failed modem, rendering the rest of the group inaccessible.

10.3.3.3 Privilege testing

Programs such as cu and tip usually must run SUID or SGID so that they can manipulate the devices associated with the modems. However, these programs are specially designed so that if the user attempts a shell escape, the command runs with the user's UID and not the program's. (Likewise, if the user tries to redirect data to or from a file, cu and tip are careful not to give the user access to a file to which the user would normally not otherwise have access.) You should check your versions of cu and tip to make sure that users are not granted any special privileges when they run these programs.

One way to check to make sure your program is properly configured is to use cu or tip to connect to a remote machine and then use a shell escape to determine your identity. For example:

 %  tip 5557000  connected login:  ~! [sh]         %  id  uid=500(jason) gid=515(jason) %

Your identity should be that of the user who runs the cu or tip program (along with associated groups), and not root or uucp .

Some communications programs, such as kermit , must be installed SUID uucp , and not root . For example, if you try to run kermit if it is SUID root , you will get the following message:

 unix%  kermit  Fatal: C-Kermit setuid to root! unix%

The reason for this behavior is that SUID root programs can be dangerous things, and the authors of kermit wisely decided that the program was too complex to be entrusted with such a privilege. Instead, kermit should be installed SUID uucp , and with the outbound modems similarly configured. In this manner, kermit has access to the modems and nothing else.

If you have a third-party communications program that you cannot install SUID uucp , you may wish to use SGID instead. Simply create a uucp group, set the group of the modem Unix devices to be uucp , give the group both read and write access to the modems, and make the third-party program SGID uucp . And if these measures don't work, complain to your software vendor!

10.3.4 Protection of Modems and Lines

Although physical protection is often overlooked, protecting the physical access to your telephone line is as important as securing the computer to which the telephone line and its modem are connected.

Be sure to follow these guidelines:

Protect physical access to your telephone line: Be sure that your telephone line is physically secure. Lock all junction boxes. Place the telephone line itself in an electrical conduit, pulled through walls or at least located in locked areas. An intruder who gains physical access to your telephone line can attach her own modem to the line and intercept your telephone calls before they reach your computer. By spoofing your users, the intruder may learn their login names and passwords. Instead of intercepting your telephone calls, an intruder might simply monitor them, making a transcript of all of the information sent in either direction. In this way, the intruder might learn passwords not only to your system, but also to all of the systems to which your users connect.
Make sure incoming telephone lines do not allow call-forwarding: If your telephone can be programmed for call-forwarding, an intruder can effectively transfer all incoming telephone calls to a number of his choosing. If there is a computer at the new number that has been programmed to act like your system, your users might be fooled into typing their usernames and passwords.
Don't get long-distance service: If you don't intend to use the telephone for long-distance calls, do not order long-distance service for the telephone lines.
Have your telephone company disable third-party billing: Without third-party billing, people can't bill their calls to your modem line.
Consider using a leased line: If all your modem usage is to a single outside location, consider getting a leased line. A leased line is a dedicated circuit between two points provided by the phone company. It acts like a dedicated cable and cannot be used to place or receive calls. As such, it allows you to keep your connection with the remote site, but it does not allow someone to dial up your modem and attempt a break-in. Leased lines are more expensive than regular lines in most places, but the security may outweigh the cost. Leased lines offer another advantage: you can usually transfer data much faster over leased lines than over standard telephone lines.