Remote System Security: A SecureNet and SLIP Solution
Rob MacKinnon and Mark Dapoz Introduction As computing becomes more portable, the need for people to connect back to a "home base" becomes more important. The system administrator must balance the convenience of remote access for the users against the dangers of compromised system integrity. Security must be at the forefront so, it becomes necessary to do more than just authorize remote use of the system: the remote user must be authenticated every time the system is accessed. This will guarantee that whoever is at the other end of the telephone is truly who they claim to be. At the Bergen Environmental Centre, we implemented two different security schemes to get the flexible remote access we needed. This article explains how we implemented a secured login scheme for the Centre. It describes how we modified the getty program and telnet daemon to include SecureNet authentication, how we administer the system and some of the system's benefits and shortcomings. It also describes how we implemented a dialback capability into SLIP so that system administrators could access and maintain the system from home. Dialback and Challenge/Response Protection Schemes There are essentially two wasy to authenticate a user at the opposite end of a demand connection. One is to have the system call back to a fixed telephone number when contacted. The principle is that since the location of the telephone is geographically fixed, physical protections in place at that location should ensure the integrity of the call. The second scheme is to implement a challenge/response system that authenticates the user at the other end of the connection by requiring the user to input a correct response to a calculated challenge string. The principle here is that since the challenge is based on a random, non-deterministic algorithm (like DES), the response will be impossible to predict without aid. That aid (an encryption key device) would be under the control of the system administrator and must be given to a particular person. The security hangs on the probability that the person who was issued the key at the other end of the connection is the person who is answering the challenge. A robust security scheme must begin by protecting all the entrances into the system. For our site, our connection to the Internet is protected with a gateway router which turns back most attempted "outside" UDP/TCP connections on most ports to all the machines within the centre. To meet the objectives for accessibility, the specific entrances to the systems that we had to "open up" were -- dial-in connections from anywhere in the world via the telephone network -- telnet connections via the Internet. There were other objectives to be met in choosing the scheme. The modems that were providing dial-up connections were the same modems that would provide SLIP connectivity. We needed a system that was flexible to configure, was adaptable to the different types of connections that would be attempted, and could provide user authentication without the exchange of clear text passwords that would compromise access integrity. One problem that was clear from the onset was that the security system could not interfere with the connection if the attempt was from a SLIP machine. There would be no means to respond to a challenge string during the initial SLIP connection attempt. The answer to our needs was to modify the daemon programs that provided the connection services to add the needed security measures. Our chosen setup gives us the flexibility to allow hassle-free SLIP connections into the special SLIP server and yet provide robust login security through the same server. In combination with the gateway router security, we have secured telnet access from the Internet. The modified telnet daemon will only allow connections after the authentication stage has been successfully passed, which limits the system's susceptibility to cracking. Connections from the Internet To allow the telnet connections via the network from the Internet , we opened up the telnet port (port 23) on the gateway router to a specific machine on our local area network. At this point, there were two possible methods we could have chosen to implement the challenge/response login. They were: --setup a firewall machine with restricted access into which the remote connection would be established. The login shell for the user would prompt with the challenge/response senerio. A successful response would present the user with a menu giving access to a restricted set of machines on the LAN. --modify telnet daemon on the special machine in the centre to give the initial login challenge. A successful response to the challenge would present the user with a single try password prompt which, if successfully entered, would give the user a normal shell. The first method had one particularly bad drawback. If the password file was not maintained properly, the user could be given a normal shell instead of the restricted shell. This meant that security was dependent on an administrative setup. We chose the second method because it proved to be more flexible for accessing machines in the centre and it placed the responsibility for implementing the security in an executable module rather than an administrative setup (as in the firewall case). The drawback to this method was that it required access to the source code for the login program we wished to modify. Without this source code, the only option would have been a firewall machine. The linchpin to our challenge/response scenario is the SecureNet encryption key (SNK) from Digital Pathways Inc. This hardware key implements a simple mutual authentication scheme using DES as the encryption method (see sidebar). We used the C code provided by Digital Pathways for deciphering the DES key. Modified telnet Program The telnetd, rshd, and rlogind programs are used to manage connections through a network. The telnetd daemon is launched by inet daemon when inetd detects a TCP connection attempt on port 23; it executes the login program to prompt for a userid/password combination. We modified the telnetd program to call our login wrapper program, snklogin, instead. The rshd and rlogind programs were not modified. This allowed local users to bypass the SNK challenge/response procedure for internal machines. In our security setup, the lack of SNK security on these programs did not present a problem. The gateway router turns back connecton attempts coming from outside our local area network on the ports for rlogin, rsh, and rexec. The wrapper program, snklogin (Listing 1 and Listing 2), accepts the user's SNK userid, which is stored in /etc/keyfile (an example is in (Listing 3). The 24-bit shared key number associated with this SNK userid is also stored in this file. After selecting the shared key based on the supplied SNK userid, snklogin prompts the user with the challenge string computed from the shared key and waits for the response. If the response that snklogin calculates doesn't match what the user enters at the prompt, snklogin exits. Otherwise, snklogin executes standard login. The login program was modified to add a new flag, the "-m" flag, which sets the maximum number of password attempts to one. This extra level of security deters a cracker who might have managed to get past the challenge/response scheme from cracking into any UNIX login. The modification to login prevents login from re-prompting for a userid after a failed password; the session is severed if the UNIX password is wrong. A typical login is shown below:
[robmack @ toppe]:.../secure/snk(274)> telnet newsroom Trying 129.177.21.11... Connected to newsroom.bsc.no. Escape character is '^]'. 4.3BSD Reno UNIX (newsroom.bsc.no) (ttyp4) Connection from toppe.bsc.no (129.177.21.131) SNK login: robmack Challenge is: 10554919 Enter Response: bf9c6d89 Password: 4.3BSD Reno UNIX #42: Fri Oct 8 11:31:58 MET 1993 erase ^H, kill ^U, intr ^C [robmack @ newsroom]:/home/robmack(1)>
Login via the Modem The dial-up connections are protected in a similar manner to the network connections. The getty program manages logins through a serial line or modem. It listens for the modem carrier signal and launches a login program when a connection is attempted. For the modem logins, we modified the getty program (a code fragment is in (Listing 4) to launch our login wrapper program instead of the standard login program. If the challenge is correctly answered, the user is presented with a normal login prompt. If the challenge is incorrectly answered, getty exits immediately and the connection is severed. The getty modifications were not as straightforward as the telnetd modifications. The challenge/response technique is excellent for cases where a human operator is at the other end of the connection and can respond to the challenge. With SLIP connections, the automated software cannot conveniently respond the to challenge string. So, in keeping with our security objectives, it was necessary in this case to implement dialback as the alternative security method. This dialback scheme also has the benefit that the office ends up footing the telephone bill for the connection -- an advantage especially in Europe where telephone calls are expensive. A special bit of coding was necessary to allow dialback SLIP. SLIPping in When a SLIP userid logs into the system, the SNK challenge/response scenario is bypassed. To accomplish this, SLIP userids are placed in a unique SNK class of users. Assigning user classes of users is a feature of the shadow password scheme used in versions of 4.3BSD Reno or later. The fifth field of the shadow password file is an arbitrary ASCII string which represents the class name. When the SLIP userid is setup, the class field is given the special string that triggers this code in getty. The difference between the security of this administrative setup and that of the firewall machine setup described earlier is that if, for example, an administrator forgets to set the class field, SLIP doesn't work. In other words, the system security is not compromised by a mistake. The user is only denied a service. Our dialback SLIP is relatively simple. The dialback code, sldial, was based on UUCP code. We used the UUCP dialing routines to handle most of the connection and modem details and wrote simple high-level code that looks to a file for mapping the SLIP userid to SLIP parameters like dialback number, maximum transmission unit (mtu) size, ip number, and so on. When the remote user initiates the call, he/she will sign into the system using a specially allocated SLIP userid. The login shell for the SLIP userid is a simple wrapper, slcallback (Listing 5), which drops the current connection, resets the modem, and executes a dialing program, sldial (Listing 6). sldial then looks up the telephone number to callback, dials the modem and waits for a carrier. When the connection is established, sldial executes the sliplogin program, which looks up the session parameters from the /etc/slip.hosts file and establishes the SLIP session. A typical SLIP login is shown below:
[robmack @ toppe]:.../secure/snk(268)> cu slip1 Connected 9600 4.3BSD Reno UNIX (slipsrv.bsc.no) (9600) login: Srbm Connection from unknown location (/dev/tty00) Password: 4.3BSD Reno UNIX #42: Fri Oct 8 11:31:58 MET 1993 You seem to be Srbm (502) Calling back j@k)Jp`D"D"D"D"D"D" Disconnected [robmack @ toppe]:.../secure/snk(269)> Mar 16 18:32:13 toppe.bsc.no -sliplogin[13876]: attaching slip unit 0 for Stoppe
Administering the SLIP Users Setting up a SLIP user requires several administrative steps. Once the setup is completed though, the user will be able to connect to the SLIP server and have the server call him/her back at a predetermined number. The user can then use all the services available on the Internet and the local area network. The first step is to, we create the userid under which the user will login to the SLIP server and assign a password to the new userid. The actual name of the userid is not important, although by convention all SLIP login ID's start with a capital S followed by the user's initials (e.g., Smd). The userid must have /usr/sbin/slcallback as the login shell and must also have the class "remote" in order to be able to login without needing SecureNet authentication. The uid and group numbers are not important except that the uid must be unique across all SLIP logins. A sample /etc/passwd entry for a SLIP user would look as follows:
Srbm::500:9999:remote:0:0:Slip Callback (Rob MacKinnon):/tmp:/usr/sbin/slcallback
The next step is to setup the uucp Systems file so that sliplogin can find the appropriate telephone numbers and chat scripts. We edit the file /etc/uucp/Systems.slip and add lines similar to the following, replacing the userid, phone number and chat script as appropriate. For a PC-based user calling the system, since a PC can't allow logins into itself, we merely leave the chat script off and hope that the PC on the other end is really who we think it is. If there's a UNIX machine on the other end, then we attempt to log into the machine with the special SLIP ID, which they must create. A sample entry follows:
# Slip line entries for callback: # Rob MacKinnon (home, unix) Srbm Any D_slip1 9600 55544618 in:-\r\d-in: Stoppe word: foobar Srbm Any D_slip2 9600 55544618 in:-\r\d-in: Stoppe word: foobar
There are as many entries in Systems.slip for a given userid as there are modem lines available. This allows sldial to try each line in turn in case some of the lines are in use. An ip address is assigned for the SLIP connection. By convention, it is assigned a name of the form slipNNN (where NNN is replaced by the user's initials). Once the name and ip address has been chosen, the domain nameserver database is updated with the information. The file /etc/slip.hosts provides sliplogin with the ability to map a SLIP userid to a given SLIP ip address, subnet mask, header compression scheme, and mtu size for the SLIP connection. An example entry would be as follows:
# login local-addr remote-addr mask mtu opt1 opt2 # (normal, # compress, # noicmp) Srbm 129.177.21.15 129.177.21.131 0xffffff00 1500 normal
Conclusion The setup we describe has been in operation for about a year. Most users feel that the inconvenience of having to obtain the SNK before traveling and having to answer the challenge at login time is far outweighed by the convenience of being able to access the systems from pretty well anywhere in the world. We as administrators appreciate the advantages of dialback SLIP and the ability to access the systems at work from home.
About the Authors
Robert MacKinnon graduated from Ryerson Polytechnical Institute, Toronto, Ontario, as an Electronic Technologist. Before coming to Bergen four years ago, he worked 12 years for IBM Canada as a VM/SP sysadmin and more recently as a UNIX sysadmin. He was responsible for the design and construction of the network at BSC and, along with Mark, performs systems admin activities there. Mark Dapoz graduated from the University of Waterloo with a B.Math in Computer Science. For the past two years he has been employed by Bergen Environmental Centre as a UNIX systems administrator.
|