Implementing a Secure rlogin Environment

8/6/2019 Implementing a Secure rlogin Environment

1/9

Implementing a Secure rlogin Environment:A Case Study of Using a Secure Network Layer Protocol

Gene H. Kim Hilarie Orman Sean OMalley

Department of Computer ScienceUniversity of Arizona

Tucson, AZ 85721

Abstract

This paper describes our experiences building asecure rlogin environment. With minimal changes to therlogin server and the use of a secure network layer pro-tocol, we remove the vulnerability of hostname-basedauthentication and IP source address spoong. We in-vestigate how applications such as rlogin interact withthis new layer, and propose extensions to the rloginserver that can utilize these services. We believe rloginpresents a situation where the application layer seemsthe most appropriate location for enforcingsecurity pol-icy, instead of in a lower layer.

Our layered approach to rlogin security achievesfunctionality similar to the Kerberos klogin client andthe encrypted telnet packages, without their complexityor loss of generality. Implementing the application layerrlogin server extensionsrequiredfewer than ninetylinesof code. Even if our rlogin application layer extensionsare omitted, rlogin connections still benet from securenetwork layer services.

1 Introduction

The rlogin program provides a security featureand at the same time introduces vulnerabilities with re-spect to user authentication on UNIX systems. Thesecurity feature uses the notion of trusted hosts to avoidsending passwords over a network, where they are vul-nerable to exposure. However, aws in the mechanism

can be exploited to allow malicious users to gain en-try to machines. These security vulnerabilities in theTCP/IP protocols and the Berkeley r-command pro-grams have been discussed at length in the literature[3, 20, 27]. Nonetheless, programs such as as rloginremain in widespread use. The consequences of noteliminating these security vulnerabilities can be seen inthe recent CERT advisory [6] pertaining to widespreadabuses of Unix systems via IP host spoong and TCPconnection forging.

In this paper, we address an attack whereby amalicious host masquerades as a trusted host to bypassthe rlogin password securitymechanism and gain accessto the system. The attacker can either forge DNS name

and address resolution replies [3] or forge the sourceaddress in the IP packet header. The latter attack is nota weakness due to hostname based authentication, but isa more general problem of remote host authentication.

In response to these attack scenarios, we describeour experiences building a secure rlogin environmentusing a prototype secure network layer protocol. Thislayer provides services for remote host authentication,message integrity, and optionally,message privacy (i.e.,packet encryption). Using these services, we have builtand demonstrated an rlogin server that is protected fromattacks and protects passwords from exposure under

more circumstances.Our approach to rlogin security is completely

modular. By using the x-kernel [1] as our design frame-work, thenetwork security layer can provide authentica-tion and privacy services without changing applicationlayer programs. Other solutions, such as Kerberos[15]and the encrypted telnet programs discussed in [23, 26],require modifying existing server and client programs.Our modications to rlogin allow it to establish a moreexible security policy than it did previously.

We attribute the simplicity of our implementa-tion and the concise interface between the application

and secure network layer to our software methodology.We believe that modular protocols can assist in pro-viding network security enhancements, and that small,well-dened module interfaces are sufcient even at theapplication level.

In the following sections, we describe the securityvulnerabilities in widely used UNIX network protocolsand programs that can be exploitedby malicioususers togain unauthorized access. Next, we describe our design


2/9

of the rlogin server and its extensions, and we presentour experiments with an rlogin client that establishesa TCP connection with forged IP and Ethernet sourceaddresses to spoof remote rlogin servers.

We then describe other solutions that have beenproposed to solve the problem of securing remote loginsessions. We conclude our paper by comparing ourdesign choices with these other works, addressing theissues of placement of policy manager and the interfacebetween the application and the network layer.

2 Problem denition

Many risks to system security stem from designaws in network protocols, servers, and programs orig-inally written a decade ago. In the following sections,we describe vulnerabilities that are related to the use of rlogin .

2.1 Password Vulnerability

When an rlogin server establishes a connectionwith a non-trusted host, it prompts the user for a pass-word. As the user types the password, it is transmittedover the network. In the past two years, this vulnerabil-ity has extensively exploited [5] to capture passwordsen masse .

2.2 Host Naming Vulnerabilities

In the rlogin server, trusted hosts are referencedby their names. Resolving these hostnames into IP ad-

dresses (and vice versa) is accomplished by the DomainNaming System [19], which refers to both the hierar-chical, distributed database and the query-response pro-tocol for accessing it. At the current time, there is noassurance that the information in a DNS response isvalid. Consequently, any security mechanisms depend-ing upon mapping names to addresses are ill-founded.This is documented in the literature[3, 27], andhasbeenexploited in system attacks[11].

2.3 TCP/IP Vulnerabilities

TCP is used as transport service for rlogin . TCP

and IP vulnerabilities to source address spoong andconnection forging are discussed in [3, 20]. Until re-cently, these vulnerabilities may have seemed too ob-scure to warrant concern. However, in January 1995,a CERT computer security advisory [6] described theavailability of tools that automate the process of IP hostspoong andTCPconnection forging malicious usersnow can use these techniques without detailed knowl-edge of their operation. How thistool can be used to gainprivileged access on UNIX machines running rlogind is

described in the next section.

2.4 Rlogin: Password Protection and Vulnerabili-ties

The 4.2BSD operating system [16] introduced asuiteof programs (sometimes called the r-commands)that allowed the convenient access of remote resourceson network-accessible machines. These programs,which include rcp , rsh , and rlogin , establish remotesessions with an associated user identier that is usedfor access control decisions; typically the identier isthe same on both machines.

The conventional login program, executed whenlogging onto a machine on its console or via telnet , re-quires users to type their passwords. If transmitted overa network, the password is subject to exposure as de-scribed previously. To prevent this, the rlogin programallows host authentication to substitute for a password.If a user is already authenticated as a user on a trustedhost, then this authentication can be adopted withoutpassword verication on the target host. This transitivetrust relationship is a discretionary policydetermined bythe site administrator in the /etc/hosts.equiv le and byindividual users via their .rhosts les.

Although the avoidance of password exposureprevents eavesdroppers from learning passwords, themethod of authenticating the originatinghost is so weak that it has become a major vulnerability. There aretwo aspects to the vulnerability. First and most basic,no mechanism (cryptographic or otherwise) validateswhether a network packet originated from the host in-dicated in the packet as the source. Second, trustedhosts are referenced by their host names, and the mech-anism for translating a name to an Internet address is notsecure. As a result, any host on the Internet can sendpackets masquerading as another host, whether trustedor not.

3 Design and implementation

The workdescribed hereaddresses the vulnerabil-ities described above. Strong cryptography is used fortrusted host authentication, and an alternative form of password protection is provided to encrypt all packetsin a key that is negotiated by the two hosts.

There are three parts to the design: the modularprotocol framework, the secure network layer imple-mented within that framework, and the rlogin server,which applies the discretionary policy based on infor-mation provided to it by the secure network layer.


3/9

rloginclient

proxyrlogin

rloginserver

tcp

/bin/login

rcmd librarytcp

ip

vnet

eth

rlogin server rlogin clientprotocol stack protocol stack

ip

vnet

eth

cryptopol

crypto

keymgr ipspesp

cryptopol

crypto

ipspesp keymgr

(optional layers)

Figure 1: Protocol stacks for rlogin server and client

3.1 Modular protocols

Our design and implementation framework usedthe object-oriented x-kernel networking architecture[21]. The x-kernel facilitates the development of layerednetwork protocols protocols are small and modular,

with xed, well-dened operations between the layers.The advantages of such an approach are more fully dis-cussed in [22].

We implemented a substantial subset of the rloginserver and client functionality in top layer protocols inthe x-kernel networking architecture. Implementing therlogin server and client as x-kernel protocols allowed usto determine to what extent these particular applicationlayer programs interact with the secure network layer.

Beneath the rlogin protocols is the standardTCP/IP protocol stack, with the optional inclusion of our prototypesecure network layer protocol. A diagram

of the major protocol modules is shown in Figure 1.Note that each box in the diagram represents an individ-ual software module presenting x-kernel interface func-tions for opening and closing connections, sending andreceiving messages, and answering queries about con-nections attributes (e.g. maximum packet size, type of security, etc.). Note also the pathway that bypasses thenetwork security layer; this allows backwards compati-bilityfor interoperating withhoststhat do notimplementthe network security layer.

3.2 Secure network layer

Our initial version of network layer security pro-vides cryptographic security enhancements for the dataportion of IP version 4 packets. The security of the en-hancements depends on a pairwise shared key between

hosts; the keys can either be manually pre-distributedordynamically negotiated.

The algorithms accepted between two hosts aredetermined by the site conguration module. For in-stance, a site may require that MD5 [25] authenticationbe used for all packets to and from a particular remotehost. Only those packets that are acceptable accordingto the site policy and pass the required cryptographicchecks are allowed to proceed up the protocol stack (i.e., to higher level protocols and applications).

Algorithmsfor all combinations of sender authen-tication, message integrity, and message privacy are

available. In practice, sender authentication and mes-sage integrityare provide by using a keyed hash functionsuch as MD5. Although the option of message privacyalone is provided by using DES in CBC mode [9], thiscombination is not generally recommended [4]; privacyplus authentication and integrity (e.g. DES-CBC overunkeyed MD5) is a better option because it protectspackets against having information appended to themwithout detection. Nonetheless, for the purpose of pro-tecting passwords, the DES-CBC option is viable, and


4/9

/bin/login

rlogin client

{local user,remote user,termtype}

rcmd library

remote IP address{locuser, remusertermtype}

.rhosts files

hosts.equiv file

rlogin server

{session securityattributes,remote IP address}

BYPASS PASSWORDPROMPT FOR PASSWORD

Figure 2: Flow graph for rlogin server authentication

rlogin makes use of it.

It should be noted that when a message integrityservice and sender authentication service are providedby the secure network layer, via keyed MD5 for ex-ample, then all packets on that TCP connection areprotected, not just the initial packets for user authen-tication. This implicitly protects against the attacks onTCP connections via IP address spoong.

The x-kernel structureallows applications to querylower protocols for attributes of a connection. For oursecure network layer, there are two relevant attributes:sender authentication and data privacy. The rlogin pro-tocol makes use of these attributes in applying its dis-cretionary access policy.

Currently, host-hostkey management is done withDife-Hellman key exchange [10] and validated usingRSA signatures [24]. For this prototype implementa-tion, RSA public keys are manually distributed.

Most aspects of thenetwork layer security policies

are determined by information in conguration les; atruntime, the conguration information is madeavailableby management modules using the uniform protocolinterface of the x-kernel .

3.3 Rlogin server

To take full advantageof thesecurity services pro-vided by thenetwork layer, wemodied the rlogin serverin three ways: it queries the network layer for the secu-

rity attributes of the connection, it uses this informationto implement a richer authentication and password pro-tection scheme, and only Internet addresses (not names)are allowed for authentication decisions.

3.3.1 Unmodied rlogin server operation

In the Berkeley implementation of the rlogin

server, functionality is divided between the rlogind dae-mon, login , and the rcmd library residing in libc . Howthe functions are distributed is summarized in Figure3. The rlogind daemon waits on a well-known portfor incoming connections. Once a TCP connection isestablished, the daemon forks and executes login , pass-ing the remote hostname as an argument. As part of the connection establishment handshake, login will re-ceive from the remote rlogin client the tuple f local user,remote user, termtype g .

To determine whether the remote host is a trustedhost, login passes the tuple and the remote hostnameto the ruserok() function residing in the libc library. Inother words, if the hostname is a trusted host listed inthe system hosts.equiv le, or if the f hostname, localuser g pair is in the users .rhosts le, the user is loggedin without any password authentication. Otherwise, lo-gin prompts for a password. (A ow graph of rloginauthentication information is shown in Figure 2.)

As a measure to protect against bogus DNS re-sponses, the rlogin server attempts to validate the re-solved address by checking the inverse mapping. First,


5/9

Component Functions

rlogind connection establishmentlogin calls rcmd() to decide whether to prompt for passwordrcmd library call examines .rhosts les to discover trust domains

Figure 3: Breakdown of Berkeley rlogin server components

quercus.CS.Arizona.edu gkim # quercus IP address192.12.69.73 root AUTH|PRIVACY

Figure 4: A new rhosts le

theservergets theremotehostaddressfromthe IP packetheader. Using this address, a host name is resolved bycalling gethostbyaddr() . The inverse address mapping

is then resolved using gethostbyname() . If the two ad-dresses do not match, or if the resolved host name doesnot match any trusted host name in the .rhosts le, theconnection is terminated.

Our implementation of the rlogin server is a func-tional subset of Berkeley implementation a UNIXrlogin client can connect withour x-kernel versionof therlogin server. Most featureomissionspertain to terminalI/O services typically provided through the STREAMSinterface. Our implementation does, however, mimicthe mechanisms for connection establishment and re-fusal, password bypass policy, and the I/O stream tothe local user shell. Server extensions were added toaddress security vulnerabilities.

3.3.2 Removing hostname references

Authenticating a remote host by its hostname in-troduces the risk of DNS spoong. To obviate this risk,we modied the interface to login , replacing the remotehostname argument with the remote host address. Therewere few changes necessary to implement this, but theyrequired changing the ruserok() library call to allow theparsing of IP addresses in the .rhosts and host.equivles. Note that this change alone does not eliminate thevulnerability of IP source address spoong.

3.3.3 Rhosts policy extensions

A new eldin the .rhosts le species the securityattributesthat mustbe present in an incoming connectionto bypass thepassword mechanism. At present, these at-tributes are AUTHand PRIVACY, specifying remote hostauthentication and connection encryption services re-spectively. An example of a new rhosts le is shownin Figure 4. The security services being provided by

the secure network layer for the connection are passedby the rlogin server as a additional arguments to login .For example, login may be invoked with /bin/login -rremotehost -auth -priv, which denotes a remote rloginsession from remotehost with an authenticated and en-crypted connection. If the specied security services donot meet the requirements specied in the rhosts le,the connection is terminated. These extensions allowusers to create separate discretionary access policies fortrusted, unauthenticated, and/or untrusted hosts.

Implementing the changes to the application levelrlogin server requiredfewer than ninetylinesof code. Inthe Berkeley implementation, these changes would havemodied source les pertaining to the rlogind daemon, /bin/login , and the rcmd service in the libc library.

3.4 Allowed policies

To determine the security attributes of an incom-ing connection, the rlogin server usescontrol operationsto query forthe presence of sender authentication and/orprivacy. The network security layer supplies replies to

these queries; the security of the authentication dependson the key distribution mechanism for setting up pair-wise keys that hosts can use for identifying each other.The privacy attribute is independent of the authentica-tion.

Our rlogin server can be congured to reject allincoming connections that cannot be authenticated (i.e.,not using the secure network layer protocol), and alsoreject connections based on the security requirementsper-user/per-host listed in the user rhosts les. Betweenthese two mechanisms, our rlogin server can be con-gured with the same granularity as Kerberos klogin or

encrypted telnet programs.In Figure 5, we enumerate the rlogin server ac-

tions as a function of authenticated and unauthenticatedclients, and the security ags specied in the usersrhosts le.

3.5 Demonstration

To demonstrate the effectiveness of an rloginserver running on top of a secure network layer, we


6/9


7/9

4.2 Secure network layer solutions

Network layer security is a generic approach thatcan provide security enhancements for many applica-tions, and validation of this claim was a factor in ourchoice of rlogin as a guinea pig protocol for our proto-

type network layer security protocol.In 1992, the Internet Protocol Security Working

Group was formed to develop mechanisms to protectclient protocols of IP at the network layer [12]. Pro-posed network layer services include message privacy,message integrity, source machine and network authen-tication, access control, reection protection, securitylabels, padding, and methods of avoiding trafc analy-sis.

[17] presents a survey of protocols that have beensubmitted to date. Although no proposal has been cho-sen for adoption at this time, prototypes have been built

and demonstrated. Among them are swIPe[14] andIPST[7], as well as our secure network layer protocoldescribed in this paper.

The secure network layer service needed to elimi-nate rlogin vulnerabilities to IP spoong is host authen-tication, and optionally, message privacy (i.e., packetencryption). In our work, message privacy is used as away of protecting transmitted passwords.

4.3 The Kerberos approach

Kerberos [15] takes a different approach to au-thentication, using a trusted third-party to provide alluser and host authentication services authenticationtickets are granted on a per-user, per-host basis for agiven service. Hosts and users are authenticated bytheir knowledge of a host-specic or user-specic se-cret, respectively.

The primary disadvantage of Kerberos is that allclients requiring authentication services must be mod-ied to use Kerberos services. For example, the Ker-beros package includes replacements for some of ther-commands, but it requires the installation of a central-ized ticket server. Because of this, and the associatedproblems of scaling this approach to the entire Internet,

Kerberos may not be a generally feasible solution.

4.4 Encrypted telnet packages

Telnet modications that incorporate encryptionand authentication services are described in [23, 26].This approach incorporates all aspects of network secu-rity at the application layer. Instead of delegating thesefunctions to a package such as Kerberos, or delegatingthem to a network layer protocol, these packages re-

implement them on a per-application basis. As a result,considerable functional redundancy may exist.

4.5 Secure DNS

The IETF has also formed a working group to ad-dress the security vulnerabilities in the Domain NameService hostname resolution protocol [19]. At the timeof this writing, [13] has been submitted to the DNS Se-curity Working Group. However, to reduce the set of dependencies, we do not utilize any of these services.Use of secure DNS is not incompatible with our ap-proach to network layer security; indeed, we plan touse DNS extensions for accessing the public keys thatare necessary for assuring authentication in our key ex-change protocol.

4.6 The GSS Application Layer Interface

For purposes of comparing application interfaces,we briey describe the Generic Security Service Ap-plication Program Interface described in [18]. It is in-tended to support in a generic manner cryptographicallyoriented security services, such as authentication, in-tegrity, non-repudiation, and privacy. Programs usingGSS-API benet from source-level portability of appli-cations, and independence from the underlying securitymechanisms.

The scope of GSS-API is quite large, providingthirteen major control operations, which return one of twenty-four dened return values. The operations man-age credentials and securitycontexts, operate on generic

data objects, and provide ancillary support.

5 Discussion and analysis

Our changes to the rlogin application layer serverremoved hostname based authentication and added fa-cilities to describe minimal security requirements on aper-host basis. It was not strictly necessary to changethe application layer programs; the reasons for doing sodeserve explanation.

Network layers such asswIPe do not requireappli-cation layer changes. Instead, they encapsulate policywithin the network security layer, refusing connectionsbased on the remote host address. A similar mechanismcould be provided by a security manager protocol re-siding between the network and application layer, onlyallowing connections meeting certain parameters.

However, we assert that all remote login connec-tions are not equal, even if they originate from the sameremote host. Consider the case when one rlogin ses-sion prompts for a password and another automaticallyaccepts the user without prompting for a password. In


8/9

the rst case, encryption must be provided to protectthe transmission of the password. In the second case,authentication services must be provided, but there maybe no clear need for encryption. Clearly, the policy de-cision cannot be made at the network security layer forlack of information.

In our case, implementing policy at the applica-tion layer does not require much communication withthe underlyingprotocol layers. The extent of interactionbetween the rlogin server and the underlying protocolsis very small: the two control operations for determin-ing source address authentication and packet privacy.The rst operation queries whether an underlying layeris providing remote host authentication services. Theoperation is propagated down the protocol stack until aprotocol services the control request. If the operation ispropagated down the entireprotocolstack without beingserviced, a failure message is automatically generated.)The second operation determines if encryption is beingapplied to the packets on the connection.

When compared to large number of interface callsdened in the GSS-API, our application interface seemsSpartan. However, we believe it is no less versatile. TheIETF specication for IP security requires user-orientedkeying, whereby hosts would guarantee that differentusers have different keys for their connections; our pro-totype is being extended to handle this, and two newinterface operations will be provided to applications forgetting and setting the key identiers for their connec-tions.

As described, our rlogin implementation allowsspecications of policies based on remote hosts and re-mote users with the same granularity as Kerberos. Thispolicy does not require the strong user authenticationand centralized key servers that underlie Kerberos.

We attribute the simplicity of our rlogin serverimplementation and the concise interface between theapplication and secure network layer to our softwaremethodology. It demonstrates that a small, xed inter-face is sufcient even at the application level, and thatmodular protocols assist in providing network securityenhancements.

6 Conclusions

In this paper, we have described our approachto solving rlogin security vulnerabilities via a securenetwork layer, avoiding extensive modications to ap-plication level programs. We describe a set of rloginserver extensions (e.g., addinga third eld to user rhostsles) that allow system administrators to specify policyat a ne-grain level, equivalent to the per-user/per-host

model of Kerberos, while retaining simplicity. This isan example of a useful policy that cannot be enforced atthe network security layer.

7 Acknowledgements

We thank Andrey Yeatts for providing his Machdevice driver and hardware expertise. Without his time,we would still be trying to get our demonstration work-ing. We also thank Rich Schroeppel for reviewing thispaper.

References

[1] Mark B. Abbott and Larry L. Peterson. Alanguage-based approach to protocol implemen-tation. IEEE/ACM Transactions on Networking ,1(1):419, February 1993.

[2] Frederick M. Avolio and Marcus J. Ranum. A net-

work perimeter with secure external access. Tech-nical report, Trusted Information Systems, Jan1994.

[3] Steve Bellovin. Security problems in the TCP/IPprotocol suite. Computer Communications Re-view , Vol. 19(No. 2), April 1989.

[4] Steve Bellovin. Hostpair weaknesses, ipsec dis-cussion. Technical report, ATT Bell Laboratories,1995.

[5] CERT Coordination Center. CA-94:01: Ongoing Network Monitoring Attacks , 1994.

[6] CERT Coordination Center. CA-95:01: IP Spoof-ing Attacks and Highjacked Terminal Connections ,1995.

[7] Pau-Chen Cheng. Design and implementation of modular key management protocol and ip securetunnel on aix. In Proceedings of the Fifth UsenixUnix Security Symposium , 1995.

[8] Bill Cheswick and Steve Bellovin. Firewalls and Internet Security: Repelling the Wily Hacker .Addison-Wesley, 1994.

[9] Data encryption standard. National Bureau of

Standards FIPS, 1977.[10] W. Dife and M. Hellman. New directions in cryp-

tography. IEEE Transactions on Information , IT-22, Nov 1976.

[11] Mark W. Eichin and Jon A. Rochlis. With micro-scope and tweezers: An analysis of the internetvirus of november 1988. In Proceedings of the1989 IEEE Symposium in Research on Securityand Privacy , 1989.


9/9

[12] Internet Engineering Task Force. Internet protocolsecurity protocol working group charter. Internet Activities Board , 1992.

[13] Donald E. Eastlake III. Domain name sys-tem protocol security extensions. Technical Re-

port IETF Working Draft draft-ietf-dnssec-secext-03.txt, DNS Security Working Group, Jan 1995.

[14] John Ioannidis and Matt Blaze. The architectureand implementation of network-layer security under unix. In Proceedings of the Fourth UsenixUnix Security Symposium , pages 2939, October1993.

[15] J. Kohl and Clifford Neuman. The kerberos net-work authentication service (V5). Request forComments (Proposed Standard) RFC 1510, Inter-net Engineering Task Force, September 1993.

[16] Samuel J. Lefer, Marshall Kirk McKusick,Michael J. Karels, and John S. Quarterman. The Design and Implementation of the 4.3BSD UNIX Operating System . Addison-Wesley, 1989.

[17] Mark H. Linehan. Comparison of network-levelsecurity protocols. Technical report, IBM T. J.Watson Research Center, June 1994.

[18] J. Linn. RFC 1508: Generic security service ap-plication program interface, version 2. Internet Activities Board , November 1994.

[19] P. Mockapetris. RFC 1034: Domain names concepts and facilities. Technical report, InternetActivities Board, November 1987.

[20] Robert T. Morris. A weakness in the 4.2bsd unixtcp/ip software. Technical report, ATT Bell Labo-ratories, 1985.

[21] Sean W. OMalley and Larry L. Peterson. A dy-namic network architecture. ACM TransactionsonComputer Systems , 10(2):110143, May 1992.

[22] H. Orman, S. OMalley, R. Schroeppel, and

D. Schwartz. Paving the road to network security,or the value of small cobblestones. In Proceedingsof the 1994 Internet Society Symposium on Net-work and Distributed System Security , February1994.

[23] Marcus J. Ranum. Thinking about rewalls. InProceedings of Second International Conferenceon Systems and NetworkSecurity and Management (SANS-II) , Apr 1994.

[24] R. Rivest, A. Shamir, and L. Adleman. A methodfor obtaining digital signatures and public keycryptosystems. Communicationsof the ACM , Vol.21(No. 2), 1978.

[25] R. L. Rivest. RFC 1321: The md5 message-digestalgorithm. Technical report, Internet ActivitiesBoard, April 1992.

[26] David R. Safford, Douglas Lee Schales, andDavid K. Hess. The TAMU security package: Anongoing response to internet intruders in an aca-demic environment. pages 91118, Berkeley, CA,1993. USENIX Association.

[27] Christoph L. Schuba and Eugene H. Spafford.Countering abuse of name-based authentication.Technical Report CSDTR94029,COAST Lab-oratory, Purdue University, apr 1994.

Implementing a Secure rlogin Environment

Documents

Transcript of Implementing a Secure rlogin Environment