Marge: “Well, Homer, I have to admit, you created something people really love. You truly are an artist.” Homer: “No, I’m just a nut who couldn’t build a barbecue.” | ||
| --The Simpsons | ||
Deploying Mac OS X in a small office setting is dramatically different from configuring tens or hundreds of workstations in a lab environment. In a small office, the threats are generally from the network, not from a malicious user sitting at the console. There are not issues regarding distributed authentication mechanisms, and there is usually not a need to create arbitrary connections between hosts; any relationships between machines are generally well-known and static.
However, in a lab or corporate environment, the situation is much less controlled. Central administrators want each user’s experience to be the same. Users should authenticate against a common database of credentials. If the central authentication system is not NetInfo, Mac OS X must be configured to communicate properly in order to authenticate users. Finally, users should have the opportunity to discover local services in a secure and scalable fashion.
This chapter will cover some issues that may be encountered when deploying Mac OS X clients in an enterprise situation. First, customization of the login process will be discussed. Then we will dive into Rendezvous and its capability to find and use local services. Finally, Kerberos will be covered as a mechanism to implement secure enterprise authentication.
When deploying managed client workstations, it is often desirable to customize the login screen. For some, this is only an aesthetic change to brand machines with an organization’s logo. For others there are legal reasons for adding information to the login screen. When prosecuting an attacker who accessed a machine via the console and performed an illegal activity, defendants may claim they were unaware that the activity they were conducting was nefarious or off-limits. By displaying a banner at login time that documents what the host is to be used for, any confusion about what activities can and cannot be performed is removed.
The Login Window program controls the console login process. Even if a host is configured for automatic login, Login Window still runs and performs the automatic login. Login Window controls the graphics displayed, the test presented to the user, and any post-login activities that are common to all users.
The loginwindow graphic is a simple 400×300-pixel TIFF file. Create the new graphic, containing whatever content you want. Then copy it to the location of the default loginwindow graphic by issuing the following command from a terminal window.
Bash-2.05a$ sudo cp mygraphic.tiff /System/Library/CoreServices/SecurityAgentPlugins/loginwindow.bundle/Contents/Resources/MacOSXart.tif
Login Window will automatically use the graphic next time you attempt to log in. There is no need to restart Login Window. Note that there are other graphics in that directory that can be customized, based on your needs.
Adding a login banner using loginwindow is effectively a mechanism for hanging a “No Trespassing” sign on the host. This banner should provide an indication of who owns the host, what the host can be used for, and any contact information for the administrators of the host. This banner should be displayed prior to successfully logging in to ensure the user sees it.
To add a banner, you will need to edit /Library/Preferences/com.apple.loginwindow.plist with your favorite text editor as root or by using sudo. After the <dict> tag, add the following information:
<key>LoginwindowText</key> <string>Your banner text goes here</string>
Again, you will not need to restart Login Window for this to take effect. Figure 9.1 shows an example login window with a banner at the top.
Rather than using NetInfo for authentication, loginwindow can be configured to require Kerberos authentication. (For more information on what Kerberos is, see the following section titled “Kerberos.”)
For required Kerberos authentication, you will need to edit /etc/authorization by using your favorite text editor with root privileges. In /etc/authorization, change this
<key>system.login.console</key>
<dict>
<key>eval</key> <string>loginwindow_builtin:login,authinternal,loginwindow_builtin
:success</string>
to this
<key>system.login.console</key>
<dict>
<key>eval</key> <string>loginwindow_builtin:login,krb5auth:authnoverify
,loginwindow_builtin:success</string>
There are other options for Kerberos authentication at login. For instance, you can force a user to log into a NetInfo domain and then into Kerberos. Further, you can even make Kerberos optional for the login process to give users control over their authentication mechanisms. (For more information on using Kerberos during the login process, see AppleCare document #107154.)
Kerberos is a network authentication protocol that allows clients and servers to authenticate each other with the use of a trusted third-party authentication server. Kerberos is commonly used in corporate and academic environments to provide authentication (and often encryption) for services such as telnet and email. It was designed to allow both the client to trust the server (and vice versa) without the client having to send a password (at least not an unencrypted password) across the network. Although it is not perfect, and certainly not simple, Kerberos does solve some basic security problems.
Kerberos is developed and freely distributed by MIT, and is installed with Mac OS X and Mac OS X Server. As a result, Mac OS X users can authenticate as Kerberos clients, whereas Mac OS X Server can make use of an existing Kerberos server as a means of authenticating users to certain services.
In this section, we will cover the configuration of Mac OS X as a Kerberos client and discuss some of the security issues surrounding the use of “ kerberized” services on Mac OS X Server. Here, we do not provide an explanation of how the Kerberos protocol is designed to work. See Appendix C, “Further Reading,” for a list of resources that provide such an explanation. Also the Mac OS X Server Administration Guide details the process of configuring certain services to authenticate clients using an existing Kerberos server.
First, as with any Kerberos setup, it is important to maintain accurate time. The Kerberos protocol makes use of time values as nonces in the authentication process. The key exchange process will fail if the client host is off by more than a few minutes. A good thing to do is use a time synchronization server, which can be configured in System Preferences.app. The process is explained in Chapter 11, “Auditing,” in the section titled “The Importance of Time.”
Typically, Kerberos 5 clients on UNIX systems maintain an /etc/krb5.conf file that defines the realms and the locations of the Key Distribution Centers to use. On Mac OS X, this master Kerberos configuration file should be located in /Library/Preferences/edu.mit.Kerberos, and is not there by default. Usually, this file is supplied by an administrator and minimally contains a default realm definition; for example:
[libdefaults]
default_realm = example.com
[realms]
example.com =
{
kdc = kdc1.example.com
kdc = kdc2.example.com
kdc = kdc3.example.com
admin_server = kdc1.example.com
}
Additionally, each user can place a configuration file at the location ~/Library/Preferences/edu.mit.Kerberos. This file is read first; if it does not exist, the system file is used.
Although command-line Kerberos applications (such as kinit and klist) are installed with Mac OS X, there is also an Aqua application for managing Kerberos tickets named Kerberos.app. This application is somewhat hidden in /System/Library/CoreServices/Kerberos.app (see Figure 9.2).
This application is somewhat useless until you have created the Kerberos configuration file; however, after that is done, it can be much nicer to use in place of the various command line utilities.
Mac OS X Server can make use of an existing Kerberos server for authentication to certain services. What it means for a service to be kerberized is that the application or server is modified to make use of the Kerberos libraries for authentication purposes; this is not always an easy process. Not all services on Mac OS X Server are kerberized. At the time of this writing, the following services and applications can take advantage of Kerberos authentication:
FTP
AFP
Mail, including IMAP, POP, and SMTP
Mac OS X Login Window
Telnet
Macintosh Manager logins
The Mac OS X Administration Guide provides detailed instructions for setting up these services to make use of an existing Kerberos server.
Here, we will discuss what Kerberos does for these services as well as some of the security issues involved with using Kerberos that both users and administrators should be aware of.
Kerberos essentially provides third-party authentication for TCP/IP network services. The main goal is to provide the capability for clients and services to authenticate each other using strong cryptography and to prevent clients from having to send out passwords onto the network. In this respect, Kerberos is successful; however, it is not perfect.
First, Kerberos is used primarily to provide authentication services. It does not provide confidentiality or integrity of data exchanged between the client and the service. Although Kerberos can be used to encrypt all network traffic, it usually is not used that way. On Mac OS X Server, configuring services such as Mail (including IMAP, POP, and SMTP), AFP, and FTP to use Kerberos secures only the authentication process, not all of the network traffic for that service. Keep this in mind: Kerberos is somewhat like a bulletproof vest; it provides protection for certain elements (such as passwords), but if an attacker is aiming for the head, it’s all over. It is better than nothing, but not a perfect solution.
Second, Kerberos authentication is only as safe as the hosts involved; it assumes trusted hosts and an untrusted network. The Kerberos protocol is based upon previously established secrets. Both the client and the service have keys that are entrusted to a host that manages the Kerberos realm(s), known as the Key Distribution Center (KDC). If this host is compromised, so are all of the clients and accessible services. Likewise, if a client host is compromised, so is access to each service that has an outstanding ticket; in this case, the compromise is limited to the expiration date on the tickets. The main point here is that the use of Kerberos authentication adds another (possibly unnecessary) element of risk to a service. The security of the client host and the server are obvious elements to consider when evaluating the security of a service. By entrusting the responsibility of authorization for a service (such as AFP) to a remote Kerberos server, the security of the service now involves three hosts.
The security of most Kerberos deployments is dependant upon time. Thus, if an attacker can alter a host’s concept of time, that system is then vulnerable to replay attacks.
Another seemingly silly, yet realistic, threat has to do with Kerberos client software. It is not uncommon for universities to run kerberized versions of telnet or ftp servers. If an attacker can get naive users to download malicious Kerberos client software, that user is doomed from the start. This scenario is not unrealistic; many users in this environment will consider the software a means to an end toward obtaining access to the service. Administrators truly concerned with the security of any services need to consider such things.
The Kerberos protocol is not completely immune to password-guessing attacks. Client keys are essentially protected by passwords. Although these passwords are not usually sent over the network, weak passwords are not immune to dictionary attacks. The attack works by an attacker requesting a ticket and performing an offline attack on the response. If compromised, the attacker can then impersonate the user, including access to any services. Attacks of this nature have been addressed with preauthentication mechanisms, but this depends upon the server’s configuration. At least make sure that the Kerberos server software is up-to-date; many issues have been fixed with recent versions. Version 5 of the Kerberos protocol surfaced with MIT’s 1.2 release of Kerberos. At the time of this writing, the MIT Kerberos distribution is 1.2.7. A popular document written by Steve Bellovin and Michael Merritt reveals some serious vulnerabilities with Kerberos versions 4 and 5 (http://www.research.att.com/~smb/papers/kerblimit.usenix.pdf). The Kerberos site hosted at MIT also contains a list of security advisories for recent releases of Kerberos (http://web.mit.edu/kerberos/www/advisories/index.html).
It may sound as if we are coming down hard on Kerberos. The main problem is that it is too complicated. There are alternatives, such as SSL and SSH, that are much easier to configure and set up than Kerberos. Securing AFP with SSH is discussed in Chapter 7, “File Sharing.” Securing mail with SSH or SSL is discussed in Chapter 5, “User Applications.”
Apple was known for years for creating computers and an operating system that were easy to set up and use. At the network, much of this ease of use was due to AppleTalk, which allowed users to plug computers into a network and have them work without any configuration. AppleTalk transparently handled addressing responsibilities and service advertisement. No-brainer networking.
Fast-forward to Mac OS X and modern networking. Everything is now based on IP, and AppleTalk has been effectively shelved in favor of IP for availability and scalability reasons. However, there is still a desire to provide no-brainer networking in the modern age. Enter Rendezvous. Rendezvous allows the creation of “instant” networks of computers and smart devices simply by plugging them into the network. Rendezvous-aware devices automatically handle their networking needs without external services such as DHCP or DNS.
Rendezvous provides the following functionality:
Automatic Addressing
Naming and Name Service
Service Discovery
Rendezvous provides addressing by utilizing the link-local netblock, 169.254.0.0/16, to randomly select an IP address. The host then ARP’s to see whether another host on the network is using the same IP address. If a conflict is found, the host will choose another address until a free IP address is found. Historically, a DHCP or BootP server is required to handle addressing on a LAN. Rendezvous provides a mechanism to allow each host to allocate its own addresses.
The nameservice and service discovery go hand in hand with Rendezvous. Rendezvous uses multicast DNS with service discovery (mDNS-SD) to notify the network of hostnames and services available. By utilizing mDNS-SD, Rendezvous-enabled hosts do not require access to a central DNS server.
A host using mDNS-SD sends a multicast packet to the network with its hostname, IP address, and available services. The other hosts on the network cache this information for use later. A Rendezvous hostname is always in the .local domain so applications know the host is a local host. mDNS-SD uses multicast address 224.0.0.251 on port 5353.
Using Rendezvous brings up some security concerns. First off, if a Mac OS X host fails to successfully contact its primary DNS servers, it will send a multicast DNS request for the address. In this situation, a local attacker could respond with a malicious DNS address in an attempt to dupe the client.
This attack can be remedied in two ways. First, the applications running on a host should make a distinction between hostnames acquired through normal DNS and those acquired through Rendezvous. Rendezvous hostnames for global names (such as www.cnn.com) should be considered highly suspect by the user and application. For example, Safari, Apple’s web browser, shows web sites discovered through Rendezvous in their own pane so there is no confusion (see Figure 9.3). The other option is to use DNSSec for all nameservice lookups. DNSSec is a long way from being implemented on a global scale and is likely not a viable solution.
Another potential vulnerability in Rendezvous is an attacker’s capability to spoof traffic into a Rendezvous network from an outside network. Luckily, the creators of Rendezvous addressed this issue in the protocol specification. If an mDNS-SD packet does not have its TTL set to 255, it will be rejected by Rendezvous-aware devices. A TTL of 255 means that the packet has not been sent through a router. Remember, a router decrements the TTL of an IP packet when it passes the packet from one interface to another. A TTL of 255 is the highest possible TTL, and by definition it means that the packet has not been sent by an external party.
Deploying Mac OS X in a large enterprise presents interesting challenges. Beyond file sharing and email service, issues such as service discovery, enterprise authentication, and banner presentation become more important as your network grows. Properly used, Rendezvous provides a secure mechanism for finding local services. Also, by using Kerberos and a customized loginwindow, users will authenticate in a common, controllable fashion. By understanding the tools at your disposal and understanding your needs, OS X can be made to scale reliably and securely.