Configuring a Client Network

The basic purpose of secure network configuration is to maximize security and minimize access. The default configuration of Mac OS X is already relatively minimal in terms of the network-accessible services it provides, but it tends to enable network access over all available interfaces (Ethernet, AirPort, modem, FireWire, and so on), and for both IP version 4 (IPv4) and version 6 (IPv6). To control network access, there are two main changes that you should make to the network settings:

• Disable unneeded network interfaces. In the Network preferences pane, review the network locations listed in the Location pop-up menu. For each location, select Network Port Configurations (these are actually network interfaces, not ports, but the interface calls them ports) from the Show pop-up menu, and deselect all ports (interfaces) that are not actually needed. This will limit unintended and unauthorized connections.

  

• Disable IPv6. IP version 6 is intended as a replacement for the currently popular IPv4 protocol; however, it is not yet widely supported in most organizations, or on the Internet. Because of this, it is rarely needed. Since support for securing it is also not universalfor example, the firewall built into Mac OS X does not filter ityou should disable it unless you actually need it.

  IPv6 is controlled on a per-port (interface) configuration basis; as a result, disabling it requires reviewing each network location just as you did to limit the active ports. For each location, go through each active port (those listed in the Show pop-up menu) and, for each one, select the TCP/IP tab, click the Configure IPv6 button, and select Off in the Configure IPv6 pop-up menu. Then click OK and go on to the next active port.

  

In addition to disabling these two settings, the System Preferences Sharing pane has a variety of options for enabling and controlling network access to Mac OS X. From a security perspective, less access is almost always better than more access. So the most secure sharing settings are:

• All services off

• Firewall on

• Internet Sharing off

But this is not always practical, so you should understand the implications of the available sharing options.

Services

On the Services tab in the Sharing preferences pane, you can enable a number of different network sharing protocols. As a general rule, each sharing protocol represents a potential security hole and should be enabled only if it is needed.

Personal File Sharing

This enables Apple Filing Protocol (AFP) serving from this computer. Enabling AFP raises a possible security issue: Since guest access is always enabled, a network attacker can easily connect and get a list of user accounts and users' Public folders.

Which folders are accessible over an AFP connection depend on the details of how the connection is made:

• Guest connections are allowed access to all users' Public folders.

• Connections that authenticate as a normal user are allowed access to the authenticated user's home folder and other users' Public folders.

• Connections that authenticate as admin users may be treated like normal users (above), or may be allowed to access to all volumes mounted on the computer with sharing enabled. In the default configuration, the difference is dependent on which version of AFP the client supports; older clients get access to entire volumes by default.

You can turn off guest access by changing the guestAccess key in the file com.apple. AppleFileServer.plist (located in /Library/Preferences) from Yes to No. Since most preference files are now saved as binary files, you will need an application called Property List Editor, which is installed with Apple Developer Tools.

You can also turn off the sharing of a user's Public folder by opening NetInfo Manager (located in /Applications/Utilities), selecting the "users" category, and clicking the user whose Public folder you want to stop sharing. Authenticate as a local administrator and select the value for the sharedDir attribute (NetInfo calls them properties) and remove it. Click another user to prompt NetInfo Manager to ask you to save the changes.

Windows Sharing

This enables Server Message Block/Common Internet File System (SMB/CIFS) serving from this computer. Doing so raises somewhat different issues than enabling AFP. First, since the password hashes that Mac OS X normally uses to authenticate users are not compatible with CIFS, accounts that will be accessed via Windows Sharing need to have their password hashes stored in additional formats. Unfortunately, one of these formats, known as NTLMv1, is particularly susceptible to dictionary attack; if an attacker manages to get a copy of the hashes (stored in /private/var/db/shadow/hash, which is readable only by root), the attacker has a good chance of recovering users' passwords. Only accounts that need Windows access should have their passwords stored this way.

Also, Windows sharing does not just share the users' Public folders; it shares their entire home folders. This can lead to exposure of files that should not be network-accessible. Fortunately, this exposure is limited because guest access to the home folders is not allowed over SMB.

Personal Web Sharing

This enables the Apache Web server, serving the contents of the folder /Library/WebServer/Documents as well as each user's Sites folder. By default, each of these contains a generic placeholder page, which generally doesn't represent much of a security risk, although it does allow an attacker to test what user names are in use on the systema first step toward a password-guessing attack.

Replacing these documents with real contentadding CGI scripts to /Library/WebServer/CGI-Executables or changing the config files for Apachecarries the same risks as running an Apache-based Web server on any other platform, with several notable additions:

• Since the standard Mac OS Extended file system is not case-sensitive, realm and other access restrictions can sometimes be bypassed by using nonstandard capitalization in a URL. This is mitigated in two ways in the default configuration file: the mod_hfs_apple module blocks nonstandard capitalization, and the built-in access restrictions (for example, to block reading of .htaccess files) use case-insensitive patterns like "^\.([Hh][Tt]|[Dd][Ss]_[Ss])".

• The Macintosh Finder creates files named .DS_Store throughout the file system with information about folder display formats, icon arrangement, and so on. If these files are served over the Web, they can leak information about the structure of files on the server to a Web client. The default config file includes a directive to block access to these files (see the example pattern above).

• The Mac OS X file system allows access to files' contents through unusual syntax, such as "filename/..namedfork/data" or "filename/rsrc," which might get past normal access restrictions. The default config file includes directives to block access via these tricks.

All of these possible problems are blocked by directives in the default httpd.conf file. If you modify or replace this file, take care to retain and/or extend these directives.

Remote Login

This enables remote shell access to the local computer over the Secure Shell Protocol (SSH). SSH is relatively secure and can be used to increase the security of other protocols (by tunneling them over an SSH connection); however, its power and flexibility make it a double-edged sword. Among the possible security problems SSH can raise are:

• SSH allows remote access to the entire file system (subject to standard authorization limitations) via just logging in and viewing files, or using the Secure Copy (SCP) or Secure File Transfer Protocol (SFTP) commands/subprotocols. Unlike other file sharing protocols, this access cannot be (easily) restricted to chosen share points.

• Since SSH can tunnel TCP/IP connections, it can provide a way to bypass firewall protection. For example, if a company's firewall is set to block all incoming AFP access, a user with SSH access to any computer behind the firewall can use that access to connect to any AFP server behind the firewall. The AFP connection will, as far as the company network and the AFP server can tell, appear to be originating from the computer the user has used SSH to log in to.

  

FTP Access

This enables File Transfer Protocol (FTP) serving from the local computer. FTP is a very old and insecure protocol; among its problems are:

• Passwords are normally passed in plaintext and are trivial for a network sniffer to capture.

• FTP gives access to the entire file system (subject to standard permissions limitations), not just selected share points as with AFP or SMB.

Some implementations (such as the one supplied with Mac OS X Server) include improved security features such as Kerberos authentication and the ability to control which folders are accessible via FTP. By default, the FTP server configuration included with Mac OS X does not do any of these things. Thus its use is not recommended in a secure environment.

Apple Remote Desktop

This enables remote control and monitoring of the computer from an Apple Remote Desktop (ARD) administrator workstation. ARD can be an extremely useful tool for remote administration, monitoring, and support, but it also carries its fair share of security risks.

To administer the computer, the administrator user must authenticate as one of the users on the computer. You can control which users are allowed to do this and which operations they may perform. Many of the operations have a high potential for misuse (for example, screen observing could be used to spy on a user), so access to these capabilities should be strictly limited.

Remote Apple Events

This enables remote computers to send Apple events to the local computer (such as AppleScript events). This should not be enabled in a secure installation.

Printer Sharing

This enables access to the local computer's print queues via Internet Printing Protocol (IPP). Aside from the inherent risk of publishing unintended information about printers and their status, this also opens several possibilities for network-based attacks:

• Denial of Service (DoS) attacks can be launched by submitting large print jobs. (No doubt followed by spam that is advertising sales for replacement paper and ink!)

• Some printers can be configured via PostScript code; a malicious print job may be able to use this to cause problems with the printers themselves.

• Since some parts of job processing on the local computer takes place under the root identity, it might be possible for a malicious job to exploit a bug in a print driver to gain root access to the local computer.

Xgrid

This enables the local computer to act as an Xgrid agent, accepting jobs from an Xgrid controller. There are three main areas of security risk that this feature opens up:

• The risk of a malicious job being used to attack the local system. This risk is minimized by running jobs under a completely unprivileged identity (or user) named "nobody." Nonetheless, jobs still have the equivalent of guest access to files throughout the computer, as well as the ability to monitor local activity through unprivileged commands (for example, the ps commandand some programs use sudo in such a way that administrator passwords may be displayed by ps).

• The risk of running unauthorized jobs (such as those that have not been through the Xgrid controller's submission process). Xgrid has two features to limit this problem. It can be configured to accept jobs only from a specified controller (and since the agent initiates the connection to the controller, spoofing would be difficult). It can also require the controller to authenticate with either a password or a single sign-on (Kerberos) ticket. Since the password may be widely knownall agents use the same passwordsingle sign-on is the more secure option.

  Note

  Single sign-on is available only if the agent and controller are members of an Open Directory master domain.

  
  

• The risk that the compute jobs themselves may be attacked, by having their data, results, or programs stolen or tampered with. Since jobs are run under the same identity used for other minimal-access processes, and because their data is stored in relatively accessible locations (such as the /tmp directory), there is relatively little protection against attack by nearly anyone with access to the local system (including even previously-executed Xgrid jobs).

Firewall

The Firewall tab provides a basic interface for configuring the firewall built into the Mac OS X kernel. When enabled, it blocks incoming TCP connections (except for specifically allowed services), but allows all outgoing, local, and (by default) UDP traffic. It also does not filter IPv6 traffic, so disabling IPv6 is recommended when the firewall is in use (as mentioned earlier in this section).

The default configuration of Mac OS X 10.4 does not provide any network services over TCP (except to itself), so this default configuration is not strictly necessary for network security. What it does do is provide protection against unintended network services, such as third-party or user-level programs that may open network ports and create security holes. The firewall blocks everything but the services you've explicitly allowed (or enabled on the Services tab), giving you a master-switch protection against such problems.

Services fall into four different categories, depending on how "built in" they are, and each is allowed by slightly different methods:

• Services that have been enabled on the Sharing tab are automatically allowed.

• Protocols enabled in other places (Network Time, iTunes, iPhoto, and iChat) are available in the Allow list. To allow access to them, simply select the box next to the protocol.

  

• Common services that may be added by third-party software (such as ICQ, Retrospect, and VNC) are preconfigured but not included in the standard list. To allow one of these, click the Add button, choose the service from the Port Name pop-up menu, and click OK. This adds the service to the main list and automatically allows it.

  

• You must manually add services that don't fall into any of the above categories. To do so, click the Add button, choose Other from the Port Name pop-up menu, enter the TCP and/or UDP port numbers that the service uses, and enter a short description (or name) for the service. Then click OK to add the service to the main list and allow access to it.

Click the Advanced button to make some additional changes to the firewall's behavior:

• Block UDP Traffic: Turns on filtering of UDP as well as TCP traffic. Unlike TCP traffic, the default for UDP is not to block all traffic other than what has explicitly been allowed; it implicitly allows access to ports 53 and 5353 (standard DNS and multicast DNS/Bonjour, respectively), 67 and 68 (DHCP and BootP requests and replies), 137 and 427 (SLP and SMB service advertisements, respectively), and 631 (IPP printer sharing advertisements). It also adds a keep-state rule to automatically allow replies to UDP packets sent from the local computer.

• Enable Firewall Logging: Logs blocked packets to /var/log/ipfw.log; click the Open Log button to launch the Console utility and view this log. In most normal circumstances, the firewall will block a lot of irrelevant packets (random chatter on a campus network and/or Windows-oriented worm attacks on the Internet), and this file can grow quite large. Generally, logging should be left disabled unless a significant network event or attack is in progress, or a network problem is being debugged.

• Enable Stealth Mode: Disables sending denials in response to blocked packets. Some attack programs use the replies they receive to profile a target computer. As a result, not replying at all can limit the information you leak. Unfortunately, this is not a panacea. Some information can be inferred from just the pattern of which probes get replies (even immediate rejection) and which get no reply.

  

Internet Sharing

The Internet Sharing feature of Mac OS X allows a workstation to act as a NAT-enabled gateway router between two networksmuch like the router/NAT capability of Mac OS X Serverbut without the configurability or security controls. This feature can be very convenient for home users, allowing, for instance, a computer to share a DSL Internet connection with other computers over its AirPort interface. In a secure network, it is mainly a security risk. For instance, if the home computer is connected to a corporate network, it would become in effect a rogue wireless base station allowing access to the corporate network. In the default configuration, it will not even require a WEP password for access.

So the simple rule for Internet Sharing is: Don't enable it if you value your network integrity. Enabling it does require administrator rights, but since its implications extend so far beyond the integrity of the local desktop (the normal limits of what an administrator can mess up), you may want to take additional steps to make sure it does not get activated. One option is to delete or rename the program that implements sharing. To delete it, launch the Terminal utility and run the following command:

sudo rm /usr/libexec/InternetSharing

Note that this will not prevent Internet Sharing from being selected in System Preferences, but it will prevent it from actually functioning. Also, it is possible that a subsequent system update may replace (effectively reinstalling) the Internet Sharing program. Check after system updates (especially if they mention improvements to the Internet Sharing feature) and delete it again if necessary.

Enabling Temporary Administrative Access

Mac OS X provides several methods for a user to temporarily enable administrative access from a less-privileged starting point. These mechanisms allow users who need administrator access to do most of their work in an unprivileged account, and enable their privileges only when they're actually needed.

The most commonly used mechanism is the Authorization framework, which displays the standard Authenticate dialog whenever a padlock icon is unlocked, the installer is run, etc. The rules for how to authorize users for various operations are defined in the /etc/authorization file. Normally most operations require authentication with an administrator account, but do not require that operations be performed while logged in as an administrator. As long as you know the name and password for your adminenabled identity, you can use this to perform administrative functions from within a nonadmin account.

The /etc/authorization file maintains both rights and rules. Rights are described by what you are attempting to do at the moment. Do you want to unlock a System Preference? Do you want to install software? Do you want to drag a file not owned by you (in a folder not owned by you) to the trash? These are rights.

Rules simply define whether certain conditions are met. For example, a rule might be to allow an owner of a file or any user with administrative privileges to permit the right to take place. The following table shows some examples of rights, rules, and comments extracted from the /etc/authorization file:

Rights	Associated Rules	Comments extracted from the authorization file
system.login.screensaver	authenticate-session-owner-or-admin	The owner, as well as any admin, can unlock the screensaver. Modify the group key to change this.
system.printingmanager	authenticate-admin	The associated right is checked for printing to locked printers.
system.install.admin.user	none	Used by installer tool: user installing in admin domain (/Applications)

Not all rights have associated rules. A right may look for a given user, permission, or an authentication mechanism. Whatever is associated with the class key will be used when attempting to comply with that right. An example of what is currently associated with a class:

• rule

• user

• allow

• deny

• evaluate-mechanisms

Note

Rights can also have their authentication credentials shared with other rights.

Fast User Switching

For operations that actually require being logged into an administrator account, Fast User Switching (if enabled) allows you to log in to an administrator account without shutting down your normal environment, doing what you need to do, then logging out the administrator identity and going back to normal. This is actually a good idea even for operations that could be done simply with the Authorization dialog, because once an Authorization right is enabled for a particular application, it remains active by default for 5 minutes (300 seconds) unless it is explicitly disabled (and it's not always easy to disable rights). If the right had been enabled from within an administrator account, switching back to a normal account would make the right inaccessible, removing the possibility that some other operation might sneak through on the coattails of the one you really wanted to authorize.

Command-Line Operations

For command-line operations, there are two commandssu and sudothat allow you to either temporarily open a more privileged shell session, or perform specific commands with a higher privilege level. Their functions are similar, but different enough that it's important to understand and be able to use both.

su is the traditional UNIX command for switching user identities. Entering the command

su localadmin

will attempt to open a shell session with the user identity localadmin. It requires that the password for the localadmin account be entered. To go back to the normal account, use the exit command to close the shell that su opened under the alternate identity.

Using su to switch to the root user is not possible in a standard Mac OS X configuration for two reasons:

• Root does not have a password and, even if it did, su has a special security restriction that allows only members of the wheel group to su to root.

• By default, root is the only member of the wheel group.

This command is useful, however, to switch from a nonadministrator account to an administrator user account.

sudo is a newer program intended to provide a more flexible capability to run single commands from a different user identity (especially root). Unlike su, it does not open a session in its default mode; instead, it switches identities, runs the specified command, then switches back to normal (or at least, back to the identity you were using before). Also, unlike su, sudo requires the password for the account you're switching from, not the account you're switching to. (To save typing, it also caches credentials. Once you provide your password, you will not be asked for it again for the next 5 minutes.

Note

Each time you use sudo, the credential is renewed; so this is really a 5-minute timeout between invocations.

The file /etc/sudoers defines which accounts are allowed to perform which operations using which temporary identities. By default, only members of the admin group are allowed to do anythingand they are allowed to do virtually anything.

For example, consider the command

sudo srm -rf '/Trash'

What this command does is attempt to execute the command

srm -rf '/Trash'

under the root identity. If the command is run from an administrator user account, and the administrator's password is provided correctly, it will succeed.

You can also use sudo to open a shell session, rather than just execute a single command. Using its -s flag invokes this mode:

sudo -s

Because this -s option leaves the privileged session open and possibly available for misuse, this is not recommended. The safest way to use root is to get in, do exactly what you need to do, and get right back out; this is exactly what sudo does in its normal (single-command) mode.

Because using sudo to get root access does not require either a root password or wheel membership, it is the preferred tool for getting root access on the command line in Mac OS X.

You can use su and sudo together to get root access while logged in as a normal (nonadmin) user: First use su to switch to an administrator identity, then from there use sudo to perform commands as root. Both commands will require the same administrator password to authorize their operations. This may seem redundant, but the two-step process provides protection against things like misuse of cached sudo credentials. For example, if you run sudo while logged into an administrator account and then run a malicious program, the program could use the cached credentials to gain full root access.

A weakness in the Secure Empty Trash or srm approach is that programmers often utilize a technique called a "safe save." When an application needs to save changes to a file, it does not write out the changes to the original file. Instead, it renames the original file to a temporary name, so for example, it might rename Myfile.doc to Myfile.doc~. Then it writes the new content to a new file which has the same name as the original and deletes the renamed original file. This ensures that the old content is not deleted until after the new content has safely been written to disk.

However, the deletion of the renamed original file does not go through the Secure Empty Trash or srm process and leaves a copy of the document on the disk in unallocated free space, which is precisely the vulnerability that Secure Empty Trash or srm seeks to avoid. To prevent this problem you can use one of two approaches. The first is to regularly run the Erase Free Space tool from Disk Utility on your volume on a regular basis, but that can take a long time if you have a large amount free space on your drive. The second approach is to store your documents on an encrypted disk image, whether through FileVault or a stand-alone disk image. By using an encrypted disk image, any erased files are still left on the disk in encrypted form, making them unrecoverable to an attacker.

More Info

For more information on creating encrypted disk images, see Lesson 14, "Optimizing Data Confidentiality."