Momento 1 Diagnóstico de la competencia Resolución de Problemas

• Kerberos

Each of these methods is discussed in the following sections.

Distributed passwd

The first method used for achieving distributed logon was simply to copy the same passwd file around the organization. While this didn’t actually provide seamless logon, it did allow for the same account name and password to be used on every machine. Achieving this distribution is technically easy but labor intensive.

Administrators have hacked various methods to simplify passwd distribution, including cron scripts using ftp, using rdist to automatically move the file, and so forth. These administrative hacks frequently opened up security holes of their own.

NIS and NIS+

Network Information Service, originally called yellow pages (or yp) was developed by Sun Microsystems to simplify logon distribution and allow for the seamless mounting of NFS volumes. The concept is simple: A single master NIS server maintains a database of account names and passwords (and other information). NIS slave servers periodically refresh their own local password map based on the contents of a master NIS server. Client machines use modified login processes (as well as other services) to attach to the NIS server to retrieve logon credentials. The group of machines configured to trust the master NIS server is called a NIS domain.

yellow pages (yp)

The original name for NIS.

NIS also does for groups what it does for user accounts: groups (called netgroups in NIS) on the master are the basis for valid GIDs on all machines in the NIS domain.

NIS for Windows Administrators

The NIS architecture is the same as the original Windows NT domain model, where a Primary Domain Controller maintains an official database of user accounts. The accounts are

replicated to backup domain controllers that provide logon services, and clients are attached to the domain to trust the domain controllers for secure logon credentials.

The following terms are congruent in the two environments: Domain = Domain

Backup Domain Controller = NIS Slave Domain Member Server = NIS Client Domain Member Workstation = NIS Client

A newer version of NIS called NIS+ was developed by Sun to shore up some of the early problems with NIS security. NIS+ is significantly more secure than NIS because it encrypts and authenticates communications between clients and servers, but it suffers from stability problems, a lack of wide support across different versions of Unix, and overly complex server-side administration. NIS+ stores logon information in database files rather than in plain text files. A number of sites that have attempted to use NIS+ have abandoned the effort in favor of simply shoring up the security of NIS.

NIS itself has numerous security flaws that are well documented—data is not encrypted between the clients and server, password maps can be retrieved and decrypted using popular password crackers, and so forth. As with nearly all pre-Internet protocols, NIS is LAN-grade security that simply isn’t strong enough to keep the hacking hordes at bay.

Warning NIS is not compatible with shadow passwords. There have been some attempts to make NIS compatible with shadow passwords, but those modifications do not work correctly as of this writing.

To set up a NIS master server, you need to install the NIS server. In some distributions, the NIS server is called ypserv, in others it is called nis-server. In either case, the NIS master server’s configuration is set by the var/yp/securenets file.

Most distributions of Unix install the NIS server by default; In Red Hat Linux (the most popular distribution of Unix), all that is necessary to run the NIS server is to correctly set the NIS configuration and rename the ypserv link in /etc/rc.d/rc3.d to begin with an "S" rather than a "K" (this change should be made in /etc/rc.d/rc5.d if you boot to directly to X- Windows rather than the text console).

Configuring clients is simple: Make sure the machine’s host name and domain are set in /etc/sysconfig/network (i.e., it’s not localhost.localdomain) and configure ypbind to run as part of the startup process by appending usr/sbin/ypbind as the last line in /etc/rc.d/rc.local. For complete information on setting up NIS servers, slaves, and clients, check out the NIS HOWTO for your distribution. The Red Hat NIS HOWTO can be found at:

www.redhat.com/mirrors/LDP/HOWTO/NIS-HOWTO/index.html.

Note For more information about establishing and managing a NIS infrastructure, read Managing NIS and NFS (2nd ed.) by Hal Stern et al. (2001, O’Reilly).

Kerberos

Kerberos is an authentication protocol that uses secret key cryptography to provide seamless logon amongst computers in a security domain (called a realm in Kerberos). Kerberos was

developed by MIT, and is basically open source under a BSD style license. MIT will provide it to anyone who wants it.

security domain

A collection of machines that all trust the same database of user credentials. realm

A Kerberos security domain defined by a group of hosts that all trust the same Key Distribution Center.

Tip Official documentation for Kerberos can be found at: web.mit.edu/ kerberos/www/ Kerberos is becoming the standard distributed logon mechanism in both Windows and Unix environments that require higher security, and it is clearly the future of distributed logon in both environments. The two platforms are somewhat compatible; with effort, Windows and Unix can be configured to logon interchangeably using Kerberos.

Kerberos in Unix is analogous to Kerberos in Windows: you have Key Distribution Centers (called domain controllers in Windows parlance) and you have clients. Kerberos v.5 specifies a Master KDC and numerous slave KDCs to which changes are propagated on a regular basis. You can optionally use DCE (Distributed Computing Environment) as your KDC

database, so that you can keep a single database of users at your site. (Windows uses Active Directory, a modified Exchange engine, to maintain the database of users and makes it available via LDAP. )

Key Distribution Center (KDC) In Kerberos, an authentication server.

Distributed Computing Environment (DCE)

An early initiative by the Open Software Foundation to provide distributed login mechanism for Unix and Windows. DCE is supported in many commercial Unix distributions and by Windows.

Note A discussion of the Kerberos security mechanisms can be found in Chapter 10, because Kerberos is a “here now” security solution for Windows. This section concentrates on the current Unix security issues associated with Kerberos.

The road to Kerberos on Unix is a long one. Because Windows is controlled by a single vendor, Microsoft was able to “Kerberize” their server services and their clients in a single release. Unix doesn’t have a central point of control, and as of this writing, there’s no pre- built “Pure Kerberos” distribution available. Installing Kerberos currently in Unix is like making a patchwork quilt of services and being rigorous about which services must be chosen. Kerberos also lacks a “Kerberos wrapper” that can be used to shore up security on any client service (although Cornell University is working on a project called “Sidecar” that will do exactly this).

Note Configuring Kerberos is complex and well beyond the scope of this book, but a pretty good step-by-step procedure can be found at

http://www.ornl.gov/~jar/HowToKerb.html. Using Kerberos

Kerberos works by either replacing the standard login mechanism on a host with a kerberized logon or by running the kinit program after logging in (if Kerberos is not being used to provide local security). When you log on (or kinit), your credentials are sent to the KDC, which uses them (and the current time) to encrypt a Ticket Granting Ticket (TGT) that is transmitted back to your machine. Your host then decrypts the ticket using your stored credentials. TGTs have an expiration (8 hours, by default; 10 hours in Windows) period and are encrypted using the current time each time they’re used. Think of a TGT as your "all day pass" at an amusement park: Once you’ve paid for it, it’s valid all day.

Ticket Granting Ticket (TGT)

An encrypted value stored by a client after a successful logon that is used to quickly prove identity in a Kerberos environment.

Whenever you attempt to subsequently access a Kerberos service, your TGT is again encrypted and transmitted to the KDC, which responds with an encrypted service specific ticket that can be provided to a kerberized service to gain access to it. Tickets usually have a very short expiration time and must be used within five minutes of their grant. This is

analogous to using your “All Day Pass” to get free “Ride Tickets” for a specific attraction at the fair from the central ticket booth (the KDC’s Ticket Granting Service). You can then take the ride tickets to the specific attraction to be admitted.

ticket

In Kerberos, an encrypted value appended with the time to prove identity to a network service.

kerberized

A service or services that has been modified for compatibility with Kerberos.

Note Kerberos is extremely sensitive to time synchronization amongst hosts in the domain. You must make sure that all of your hosts are correctly synchronized to the same Network Time Protocol (NTP) server for Kerberos to work correctly.

Kerberos Security

Theoretically, Kerberos security is very strong. By authenticating with a KDC, you get a ticket that can be used to prove your identity to any service in your organization. Keys are automatically managed by your system, so login to various services is seamless. It sounds wonderful, and in Windows, it really works. But Kerberos just isn’t completely integrated into any Unix distribution, and without complete integration, it loses much of its appeal and

The major problem with Kerberos is its “all or nothing” nature—you can’t just add Kerberos to the mix and secure a few protocols, because users will use the same account names and passwords with the as-yet-unsecured services, thus compromising them. You have to convert your entire network services infrastructure to use services that are compatible with Kerberos for authentication, or the whole thing isn’t really secure. Every service you provide that you want to provide seamless logon for has to be replaced with a “kerberized” version that knows how to trust the Kerberos authentication mechanism.

Warning Don’t use the same user accounts and passwords on your Kerberos systems as you use on non-kerberized services. Non-kerberized services can’t protect the

passwords, so they will be revealed to sniffers if users are in the habit of using the same passwords on all systems. Best: Kerberize all of your services, or none of them.

This is why deploying Kerberos is so complex. It is possible to use PAMed applications that are configured to check Kerberos for applications that haven’t been kerberized, but this is problematic because the user’s credentials may have to run from the client to the service host in whatever form the service uses before PAM can use Kerberos to validate the password. PAMed

An application that has been modified to allow for Pluggable Authentication Modules. Warning Don’t use PAM to “kerberize” every service on your machine, because many

services transmit passwords in the clear. Depending upon its configuration, PAM may not check the password until it’s received on the server, meaning that it has traveled through the network in whatever form the PAMed protocol uses. PAM then receives the password and checks it against a Kerberos KDC. For protocols that transmit passwords in the clear, like Telnet and FTP, using PAM to check Kerberos passwords would reveal the passwords to a sniffer.

Despite the promise of Kerberos to eliminate the vast majority of simple attacks against Unix, it is not going to achieve widespread use until a Unix vendor releases a pure Kerberos

distribution that any system administrator can deploy. This is a few years away from actually happening, so unless your organization has significant network administration resources available to properly deploy Kerberos, it’s likely to drain more resources away from more immediate security solutions than it is to provide better security in the short term.