 | Chapter 14 Telephone Security |  |
| Chapter 14 Telephone Security | |
UNIX can use modems both for placing calls (dialing out) and for receiving them (letting other people dial in).
If you are calling out, you can call computers running any operating system. Outgoing calls are usually made with the 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.
Another popular program for dialing out is kermit, from Columbia University. Besides performing terminal emulation, kermit also allows reliable file transfer between different kinds of computers. Versions of kermit are available for practically every kind of computer in existence.
You can also set up your computer's modem to let people with their own modems call into your computer. There are many reasons why you might wish to do this:
If you have many people within your organization who want to use your computer, but they need to use it only infrequently, the most cost-effective approach might be to have each employee call your computer, rather than wiring terminal lines to every person's office.
If some people in your organization travel a lot, they might want to use a modem to access the computer when they're out of town.
If people in your organization want to use the computer from their homes after hours or on weekends, a modem will allow them to do so.
You can have administrators do some remote maintenance and administration when they are "on call."
UNIX also uses modems with the UUCP (UNIX-to-UNIX Copy) network system, which allows different computers to exchange electronic mail; we discuss UUCP in detail in Chapter 15, UUCP. You can also use modems with SLIP (Serial Line Internet Protocol) or PPP (Point-to-Point Protocol) to integrate remote computers transparently with local area networks. To set up a UUCP, SLIP, or PPP link between two computers, one computer must be able to place telephone calls and the other must be able to receive them.
Despite these benefits, modems come with many risks. Because people routinely use modems to transmit their usernames and passwords, you should ensure that your modems are properly installed, behaving properly, and doing exactly what you think they are doing - and nothing else.
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.
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, /etc/remote, and /usr/lib/uucp/L-devices if you wish to use UUCP. On System V systems, you may have to modify the files /etc/inittab and /usr/lib/uucp/Devices. You may also have to create a special device file in the /dev directory, or change the permissions on an existing file. The formats of these files are discussed in Chapter 15, UUCP.
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 man pages associated with the software as they often include a section entitled "Files" that names associated files.
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 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 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 %
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 the user out, 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.
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 as well as 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. When the computer answers, 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 and 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 C, UNIX Processes, for details about how to use these commands.) Once again, your modem should automatically hang up on the remote computer.
The above 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 a 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 together.
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 for referring to each 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.
Your software vendor might not have figured out how to make a tty driver that works properly. Many older versions of DEC's Ultrix had problems with their tty drivers, for example.
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 UNIX modem control programs will disable the modem's escape sequence, but some do not.[5]
[5] Most modems that use the Hayes "AT" command set, 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.
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 set some configuration switches.
Verify that your modems lock 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 or by the UUCP system. Likewise, make sure that UUCP does not use a telephone line that is being used interactively.
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 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.
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 MNP 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.
NOTE: 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.
Programs such as cu and tip usually must run SUID 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 that creates a file in the /tmp directory. Then, look at the file to see who owns it. For example:
% tip 5557000 connected login: ~! [sh] % touch /tmp/myfile % ls -l /tmp/myfile -rw-r--r-- 1 jason 0 Jul 12 12:19 /tmp/myfile %
The file should be owned by the user who runs the cu or tip program, and not by 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 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 and 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!
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 his or 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 to all of the systems to which your users connect.
Make sure your telephone line does 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.
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.
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.
|  | |
| 14.4 Modems and Security |  | 14.6 Additional Security for Modems |