Problem 2: Non-IP Dialup (getty)
Problem 2: Non-IP Dialup ( getty )
So you've got your Linux box up and running. Maybe you're on a 24 “7 connection like DSL or a cable modem. You've got your firewall configured and a whole network behind it, with a happy spouse and maybe happy children. Every inch the bucolic postmillennial family. Nice, isn't?
You are away at a sales convention (you're in sales ”don't take it personally , this is an imaginary scenario) and you're secure-shelled into your home network, in a talk session with your spouse when suddenly everything starts moving in slow motion. It's like you're typing through molasses.
X is so sluggish that it takes several minutes to open an X- term . Your spouse has stopped responding. You manage to launch a primitive sniffer, perhaps tcpdump, and you see that your whole network is pumping out traffic to some IP address. You do a whois and find that your network is spewing traffic at www.irs.ustreas.gov .
The IRS? You had better get off your dead backside before the men in dark suits , sunglasses, and little earpieces show up to tell you how much more fun they can have in your home than you can! Trouble is, at this point, your network is so congested that you can't type anything. You are dead in the water. Or are you?
I'm going to show you how you can maintain another communications channel of last resort. You can actually connect to your Linux box like an old-style BBS system. If you were into computers in the 1970s and 1980s, you remember a time before the Internet came to such lows as SLIP, CSLIP, and PPP. You remember using terminal programs (perhaps PROCOMM, perhaps Smarterm, perhaps something you wrote yourself {ahem!}) to issue ATDT commands to your Hayes-compatible modem and connecting to modems on other computers directly, one to one.
In our scenario, you pop your PCMCIA Ethernet card out of your laptop and slam in your PCMCIA modem. You fire up a terminal program (such as Minicom), dial your home analog modem number, and are greeted with:
sol login: You log in, become root, disable the network, and start looking for what went wrong. You are saved!
Well, maybe. Your system is probably hopelessly compromised. Once someone has gotten in and done something naughty with your system, it is almost certainly impossible to secure it again, simply because there is an almost infinite number of holes and back doors that may now be open. It's easy to open additional locked doors once you get through the first one. You'll have to leave the network down until you can get home and reinstall from scratch. (And don't bother restoring from backups . You have no way of knowing how long ago your system was compromised. You can restore, but you might be restoring their access as well.) This isn't a book about computer incident response, so I won't spend much more time on this. I will say, however, that you should make every effort to apply all security patches that have come out since you last built your system from scratch. You should also report the incident to your ISP. Finally, you should try to find how the little miscreant got in so you can nail them next time.
Enough of that. We are going to tell you how you can set your system up so you have this back way in. After all, where would you have been had you been unable to stop the flood from your network?
The Whys
The whys should now be obvious. Having a second communications path is always a good idea. Maybe your problem won't be a denial-of-service attack launched from your network by a bored teenager. Maybe it will simply be a bad network card that starts broadcasting junk. That would disable your network too. Dozens of things can go wrong. A common one for me since I shut down my home network with a highly restrictive firewall is forgetting to start the secure shell daemon before I leave in the morning so I can log in to my system (I must get around to adding that to runlevel 2).
In any case, having a second way in can be enormously helpful when things go wrong. If you are always at your system, you have the console. I don't know about you, but I occasionally leave the room, and once in a blue moon I even leave my house. That's when I get all twitchy unless I have a dialup backup.
The Hows
Logging in to a Linux box starts with a program called a getty. This stands for GET tTY. TTY stands for teletype, which was the brand name of the first serial communications devices. This name just sticks around like the terms Xerox and Kleenex. Nobody uses teletypes any more, but their names and terms stick around. I find it a charming bit of nostalgia in an industry that has no memory.
You use a getty any time you log in to one of your text-mode consoles. You do know about the text-mode consoles, don't you? (If you have a distribution that always boots to a graphical user interface (GUI) and you haven't been a Linuxer for some time, maybe you don't.)
Linux supports multiple virtual consoles. Every distribution I have seen uses this feature and runs at least five of them. You use the CTRL-ALT-Fn keys to switch between them. Press CTRL-ALT-F1 and you will find yourself at a text-mode login prompt. Press CTRL-ALT-F2 and you'll find yourself at another one. Most distributions I have seen put the GUI at CTRL-ALT-F7. You can press that to go back to the GUI.
The job of a getty is simple. Detect a connection on a port, match communication parameters, display the /etc/issue file, prompt for a username, and then wait. When a username is entered, the getty program actually runs a separate program called login, which prompts for the password and runs whatever shell is specified for the user in /etc/passwd.
For the desktop virtual consoles, this job is so simple (there are no status lines or modems or serial interfaces) that there is a special version of getty called mingetty that most distributions use for these consoles.
The mingetty program can't be used for dialup terminal login support. It doesn't know anything about serial port status lines or modem control commands and result codes. It doesn't know about baud rates, parity, start bits, stop bits, or terminal types. Maybe you don't either. That's okay ”you don't really need to know.
It turns out that there is more than one kind of smart getty out there. We'll take a look at the most common ones and help you figure out how to configure them. But first, we have to talk about how to run a getty. It's not like any other process in Linux.
The /etc/inittab File
Remember when we told you that this wasn't a book about Linux system administration? That, like so much in this book, was a half truth. What, in fact, ethics specialists call a "lie." In order to explain certain topics, we have to acquaint you with some of the less savory aspects of Linux system administration. One of these is the so-called System V initialization model. The heart of this is a little file called /etc/inittab, for INITialization TABle. (By the way, did you know that an acronym made up of syllables instead of initials is called a portmanteau word? Don't tell me this book didn't teach you anything!)
If you hadn't heard about inittab before this, then you probably haven't heard of runlevels either. The System V initialization model assumes the system can be in one of a number of states, or runlevels, ranging from state 0 (shut off) to state S (single user), through levels 1 “5, which will be states with different mixes of baseline services, running, all the way to state 6, which is reboot (not really a state, is it?). What services are running in each state will vary quite a bit from distribution to distribution. Also, how the system moves from state to state will vary quite a bit.
What we will show you here is the "out-of-the-box" /etc/inittab from a SuSE Linux 6.4 system. This was chosen through an exhaustive process of systems analysis to determine which distribution had the best pedagogical potential. Also it was chosen because that was the system I was using when I typed this part of this chapter. It could have been from a RedHat system or a Debian system. There would be differences in the specifics, but the general form and function is the same.
So let's dissect an inittab, shall we?
# # /etc/inittab # # Copyright (c) 1996 SuSE GmbH Nuernberg, Germany. All rights reserved. # # Author: Florian La Roche <florian@suse.de>, 1996 # # This is the main configuration file of /sbin/init, which # is executed by the kernel on startup. It describes what # scripts are used for the different runlevels. # # All scripts for runlevel changes are in /sbin/init.d/ and the main # file for changes is /etc/rc.config. # # default runlevel id:3:initdefault: # check system on start-up # first script to be executed if not booting in emergency (-b) mode si:I:bootwait:/sbin/init.d/boot # /sbin/init.d/rc takes care of runlevel handling # # runlevel 0 is halt # runlevel S is single-user # runlevel 1 is multiuser without network # runlevel 2 is multiuser with network # runlevel 3 is multiuser with network and xdm # runlevel 6 is reboot l0:0:wait:/sbin/init.d/rc 0 l1:1:wait:/sbin/init.d/rc 1 l2:2:wait:/sbin/init.d/rc 2 l3:3:wait:/sbin/init.d/rc 3 #l4:4:wait:/sbin/init.d/rc 4 #l5:5:wait:/sbin/init.d/rc 5 l6:6:wait:/sbin/init.d/rc 6 # what to do in single-user mode ls:S:wait:/sbin/init.d/rc S ~~:S:respawn:/sbin/sulogin # what to do when CTRL-ALT-DEL is pressed ca::ctrlaltdel:/sbin/shutdown -r -t 4 now # special keyboard request (Alt-UpArrow) # look into the kbd-0.90 docs for this kb::kbrequest:/bin/echo "Keyboard Request -- edit /etc/inittab to let this work." # what to do when power fails/returns pf::powerwait:/sbin/init.d/powerfail start pn::powerfailnow:/sbin/init.d/powerfail now #pn::powerfail:/sbin/init.d/powerfail now po::powerokwait:/sbin/init.d/powerfail stop # for ARGO UPS sh:12345:powerfail:/sbin/shutdown -h now THE POWER IS FAILING # getty programs for the normal runlevels # <id>:<runlevels>:<action>:<process> # The 'id' field MUST be the same as the last # characters of the device (after "tty"). 1:123:respawn:/sbin/mingetty --noclear tty1 2:123:respawn:/sbin/mingetty tty2 3:123:respawn:/sbin/mingetty tty3 4:123:respawn:/sbin/mingetty tty4 5:123:respawn:/sbin/mingetty tty5 6:123:respawn:/sbin/mingetty tty6 # # # Note: Do not use tty7 in runlevel 3; this virtual line # is occupied by the programm xdm. # # This is for the package xdmsc; after installing and # configuration, you should remove the comment character # from the following line: #7:2:respawn:+/sbin/init.d/rx tty7 # modem getty. # mo:23:respawn:/usr/sbin/mgetty -s 57600 modem # fax getty (hylafax) # mo:23:respawn:/usr/lib/fax/faxgetty /dev/modem # vbox (voice box) getty # I6:23:respawn:/usr/sbin/vboxgetty -d /dev/ttyI6 # I7:23:respawn:/usr/sbin/vboxgetty -d /dev/ttyI7 # end of /etc/inittab As usual in *nix configuration and script files, lines beginning with a pound sign (#) are comments and are ignored. Active lines in the file are of the form:
id:runlevels:action:process where the following holds.
| id | An identifier name of up to four characters. This is just a name. It doesn't have a great deal of significance (although there are some conventions for login accounting, so don't change names of entries that already exist). | |
| runlevels | Lists one or more runlevels at which this entry's process is to be run. | |
| action | One of the following | |
|
| Action | Description |
|
| respawn | If the process dies, run it again. |
|
| wait | The process will be run when the specified runlevel(s) is (are) started, and init will wait for the process to terminate before continuing. |
|
| once | The process will be started once when the specified runlevel(s) is (are) started. init will not wait for the process to terminate before continuing. |
|
| boot | The process will be executed once during boot. The runlevels field is ignored. |
|
| bootwait | The process will be executed once during boot. The runlevels field is ignored. The init process will wait for this process to terminate before continuing. |
|
| off | Disabled entry. Same as commenting the line out. |
|
| initdefault | Specifies the default runlevel. The process field is ignored. |
|
| sysinit | The process will be executed once during boot. It will be run before any boot or bootwait entries. |
|
| There are other options for power failure and on-demand processing, but these do not concern us here. Consult inittab(5) for full details. | |
| process | The process to execute. | |
The first noncomment line is:
id:3:initdefault This line specifies the default runlevel. This is the runlevel the machine will be in when booted . Note that here this is runlevel 3.
Setting Up a getty
As we said earlier, the program that recognizes and services a connecting ( non-network ) user is called getty. There are actually a great many getty programs out there. The truth is, you probably will not want to use one that works just like the classic getty program. We will describe two getty variants that are particularly well suited to modem use. These are agetty and mgetty.
agetty
The agetty command has a number of features that suit it to modem use, including:
· It autosenses parity and character size; it can handle uppercase only (in the traditional *nix way: \EVERYTHING UPPERCASE, WITH \C\A\P\I\T\A\L\S PRECEDED BY BACKSLASHES).
· It can adjust baud rate based on Hayes CONNECT messages from a modem.
· It has configurable flow control (needed for today's high-speed modems).
The agetty command is fairly useful, but in my humble opinion mgetty is better. For completeness, however, here are the switches that agetty understands (as usual, we document only those you are likely to use ”dig deeper if you want to know more):
| Switch | Description |
| -h | Enable hardware flow control (RTS/CTS protocol). |
| -i | Do not display the contents of /etc/issue file. |
| -f issue-file-name | Use issue-file-name instead of the default /etc/issue file. |
| -I initialization-string | Set a modem initialization string to be sent before sending anything else. Often set to ATZ (the Hayes modem reset command). Nonprintable characters may be put in the string by inserting a backslash (\) followed by the octal ASCII value of the character as a three-digit number. For example, to send an ESC (ASCII decimal 27), you would put \033. |
| -l login-program | Specify an alternate login program. Defaults to /bin/login if not specified. |
| -m | Attempt to extract the connection speed from Hayes standard "CONNECT xxx" result messages. The agetty program assumes the modem emits status messages at the baud rate specified as the first rate on the command line. |
| -n | Do not prompt for a login name. This can be used in conjunction with -l to run an alternate system, such as a BBS. Note that when agetty does not prompt for a login, it can't automatically set parity, word size, and other terminal options. |
| -t timeout | If a user name is not entered within timeout seconds, terminate the program. |
| -L | Local line. This makes agetty ignore the status of the carrier detect signal on the serial port. This might make sense if you have a terminal attached directly to a serial port, as opposed to using a modem. |
| -w | Wait for a carriage return or linefeed character before sending the /etc/issue file and user login prompt. This is a very good idea, especially when using the -I option. |
mgetty
The mgetty program is my personal preference when enabling non-network remote access. Why? Because it supports a couple of extra and useful features. Here are the advantages I see to mgetty:
· It supports modem initialization between calls.
· It manually answers incoming calls, so you never set your modem on "Autoanswer." This means your modem will not answer the phone if the system is not ready.
· It obeys UUCP (Unix-to-Unix Communications Program) locking protocols, so you can use the same modem for dial-in and dial-out applications simultaneously .
· It understands fax/modems, so if an incoming call is from a fax machine, it will save the incoming fax as a file and will then again be ready for either a fax or a data call.
· It has extensive logging capabilities.
If you go back to the earlier section on /etc/inittab, you will notice a commented-out line that would set up mgetty. Apparently, SuSE shares my preference for mgetty. The only problem is their default parameters are little behind the times. For one thing, a speed of 57,600 baud might well be a bit low for today's fastest modems.
Let's go over the most important command line options for mgetty, and then let's choose a few to modify our sample /etc/inittab.
| Switch | Description |
| -k space | Reseve space kilobytes on the drive when receiving a fax. It is a very good idea to set this to a fairly large value. Otherwise you may become a victim of a denial-of-service attack through a fax machine! |
| -x logging level | Set the " verbosity " of mgetty logging. The logging level may be from 0 to 9, with 0 being no logging and 9 being, well, a lot. |
| -s speed | Sets the data rate between mgetty and the modem or terminal to an initial value of speed bits per second. |
| -r | Skips modem initialization for direct-connected terminals. |
| -p login-prompt | Allows you to create your own login prompt. There are a number of special macros you can use to put information in the prompt. For example, "\D" will output the date, "\T" the time, and "@" the system name. There are many others. Consult the man and info pages for details. |
| -n number of rings | Allows you to specify which ring mgetty should answer on. The default is 1 (meaning the first ring). |
| -D | Tells mgetty to accept data calls only. You should set this option if your modem is not a fax/modem. Even if it is a fax/modem, this will cause fax calls to be rejected. |
| -F | Tells mgetty to accept only fax calls. No data calls will be accepted. |
| -C class | Tells mgetty what "class" of modem is being used. Values allowed for class are: · auto · cls2 · c2.0 · data (This is the same as using the -D option) The default class is auto, which mgetty will attempt to query the modem for its capabilities. The cls2 and c2.0 select between the "class 2 fax" and "class 2.0 fax" protocols (don't ask me whose bright idea it was to have "2" and "2.0" be different instead of, say, "2" and "2.1"). I would recommend sticking with auto unless you have problems. |
| -I fax id | Use the string fax id as the fax station ID. In the United States it is unlawful to send a fax without certain identifying information. This information must include at least the business or person's name and the fax's telephone number. Although mgetty doesn't normally send faxes (except for fax polling ”read the info and man pages!), it is still a good idea to put this minimal information in the program, just to be "Reno-proof." |
| -a | This enables autobauding. In other words, mgetty will attempt to parse the "CONNECT xxxxx" messages from the modem and adjust its baud rate to match. Most modems today do not require this. They communicate with the host at a fixed rate and buffer internally to handle different connection speeds. Use this option only if your modem insists on actually changing its host rate to match the connection rate. (No 14.4k or faster modems should do this). |
| -m modem chat | Set the modem initialization dialog. The string consists of alternating "expect/send" messages. Use two double quotes for an empty expect string. Example: -m '"" ATZ OK ATH0' |
Remember, this is not complete mgetty documentation. Still, based on this, let's take a look at how we would set up our /etc/inittab line:
# modem getty. mo:23:respawn:/usr/sbin/mgetty -k 204800 -s 115200 -m '"" ATZ OK' -I "(763) 555-3456 M. Schwarz" modem Our options make sure that:
· At least 200MB of disk space is left free (-k).
· Baud rates up to the maximum ability of modern serial ports will be accepted (-s).
· The modem will be reset between calls (-m).
· Any faxes will be met with correct identification (-I).
Be aware that mgetty has several options we have not covered. It can reject calls based on caller ID (for modems that support it). It is designed to work with the sendfax program. It can be made to reject calls without disabling the program, and so forth. Be sure to read up on these features.
EAN: 2147483647
Pages: 257