10.3 Modems and Unix
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.
|