- Mac OS X's Model for Securing Services
- Securing Mac OS X Services
This chapter is from the book
This chapter is from the book
This chapter is from the book
Securing Mac OS X Services
The four key Mac OS X services that you can make available through the Sharing System Preferences window are File Sharing, Web Sharing, Remote Login, and FTP (Figure 18.6). All these services give network users access to aspects of your machine that they otherwise could have only by sitting down at the machine itself. Each service provides a different form of access in a different way, but all the services use the same user name and password. As indicated in Chapter 4, this arrangement provides additional security exposure, because compromise of one service's password can lead to compromise of the other services and of the machine itself.
Of the four services, Remote Login is riskiest and also the least likely to be needed. Remote Login gives authorized network users the same level of access they would have at the machine itself, except through the Unix command line rather than through the Mac interface. Unless you are a Unix expert, follow a simple rule about Remote Login:
WARNING
Do not enable Remote Login. The Unix command line is of little use to most Mac users but potentially of great use to hackers. Enabling Remote Login exposes your machine to network attacks that could take full control of the machine at the Unix level. Many Unix machines are compromised through Remote Login.
If you feel that you need to use Remote Login, make sure that your version of Mac OS X is at least 10.0.1. To check, choose About This Mac from the Apple menu. The original release of Mac OS X, 10.0, shipped with a highly insecure implementation of Remote Login called Telnet. Telnet sends its entire session in clear text, including user name and password. Anyone listening in on the conversation between a Telnet client and your Mac OS X machine (usually through automated sniffer software) would be able to capture your name and password and log in to your machine as you.
In Mac OS X 10.0.1, Apple replaced Telnet with SSH (Secure Shell). SSH uses advanced encryption techniques to make the session much more secure. Regardless of this increased security, exposing the full command-line interface of your Mac OS X machine over the network remains risky and is not very useful unless you're a Unix expert. The risk almost never justifies the reward. If you do take the risk, however, be sure to follow these guidelines:
Use Mac OS X 10.0.1 or later.
Verify that all users on the machine have well-chosen passwords.
Install a personal firewall.
Allow access to the SSH service only from IP addresses that really need it.
FTP is another Unix-based service with high security risks; generally, you should not enable it. (See Chapter 14 for details.) FTP gives authorized network users connecting to your machine the same level of access to files that they would have if they were logged in to the machine directly. FTP shows files and folders that generally are invisible in the Finder and are more difficult to access when a user is logged in directly.
Mac OS X does not support anonymous FTP, so users who access files from your machine with FTP must have a user name and password, even if you don't want them to be able to log in to your machine. Because FTP has a particularly high risk of password compromise, you should be sure that FTP users do not have administrative access to your machine. That way, if a password is compromised, the hacker will not be able to log into your machine as an administrator.
Mac OS X's File Sharing is a much more secure, easier-to-use alternative for sharing files, especially with other Macs. File Sharing is somewhat different from Remote Login and FTP in terms of the access it gives authorized network users. If an authorized network user is an admin user, that user has complete read-only access to all files and folders on the machine, in addition to any access that he or she normally would have at the machine. Non-admin users, on the other hand, have less access than they would have if they were at the machine. Specifically, a non-admin user has full access to only the files and folders within his or her home folder and not to other files, such as applications. Also, non-admin users, like guests, have read-only access to the public folders of other users of the machine. File Sharing does not display invisible files.
Mac OS X File Sharing supports guest users, just as Mac OS 9 does, so you don't need to create accounts for users with whom you want to share files—another significant advantage over FTP. By default, any guest user has read-only access to the public folders of all authorized users on the machine. A user who wants to share files with guests simply needs to place those files within his or her public folder, which is inside the home folder. Public folders also contain a drop box where guests can put (but not see) files that they want to transfer to authorized users.
Admin users can change the access privileges of files and folders on the machine, and all users can change the access privileges of files and folders within their home folders, although only public folders are actually shared to guests through File Sharing. To change an item's access privileges, choose that item in the Finder, and then the Finder's Show Info command from the File menu. In the dialog box that appears, choose Privileges from the Show pop-up menu and select the desired privileges (Figure 18.15). Even though you can assign sharing privileges to any file or folder, you can share only the folders that the Mac OS makes available for sharing—the whole hard disk for admin users, a user's home folder for nonadmin users, and public folders for guests.
){kind=link}
Figure 18.15 Setting Mac OS X File Sharing privileges is much the same as under Mac OS 9 but somewhat more limited.
Mac OS X File Sharing uses a different AppleShare (AFP) authentication protocol than previous versions of Mac File Sharing. It uses Diffie-Hellman Exchange (DHX) rather than random-number exchange. DHX, described in Chapter 14, is highly secure and supports longer passwords than random-number exchange. (Mac OS X File Sharing currently uses only the first eight characters of the password however.) Most Macs support DHX for File Sharing, but some older ones may not. If an older Mac doesn't support DHX, it may send its user's password in clear text, which would be indicated in the Chooser (Figure 14.6). Most older Macs can be upgraded to use the latest AppleShare client, which supports DHX.
Mac OS X Web Sharing operates through the Unix-standard Apache Web server. Apache is extremely powerful, but Apple does not make its features available through the Mac OS X user interface. Experts can access these features through Apache's text-file and command-line interface, but the procedure is complex and not recommended.
When Web Sharing is enabled, specific folders are shared at specific URLs. Users of the machine can have their own Web sites, and the machine as a whole has a general Web site. Any files that users put in their Sites folders within their home folders will be available over the Web at http://computers-IP-address/~username/, in which computers-IP-address is the IP address of the machine and username is the user's short name. The tilde (~) is an unfortunate Unix standard that Apple chose not to eliminate. Any files that you put in the Documents folder, which is inside the WebServer folder in the Library folder on your hard disk, will be available at your computer's main site at http://computers-IP-address/.
Mac OS X does not provide an easy way to apply privileges to files shared through Web Sharing. Web Sharing seems to be intended for Web sites that are accessible to the whole network to which the machine is connected. Apache does provide a high level of control in this area, but this control is available only through its text-file-based interface.
As you can see, each of the Mac OS X sharing services works a bit differently, which can be confusing and can lead to security holes if you assume that one service works the same way as another. Table 18.1 summarizes the levels of access that these services grant to admin users, nonadmin users, and guests.
Table 18.1
|
Service |
Type of Access |
Admin-User Access |
Nonadmin User Access |
Guest Access |
|
Remote Login |
Unix command line |
Same as at machine |
Same as at machine |
None |
|
FTP |
Files and folders via FTP client |
Same as at machine |
Same as at machine |
None |
|
File Sharing |
Files and folders via AppleShare client |
Same as at machine, plus read-only access to everything |
User's home folder other users' public, folders |
Public folders |
|
Web Sharing |
Web site via Web browser |
Main and user sites |
Main and user sites |
Main and user sites |
You can use the NetInfo Manager utility to set many advanced items associated with Mac OS X services (Figure 18.16). NetInfo is recommended only for expert users, however, because the risk of decreasing the security of a service far outweighs the potential benefits of tweaking that service. If you feel you know what you're doing, you can use NetInfo to put a user in a specific group, change the port used by File Sharing, or enable and set details of File Sharing's logging (see "Detecting and responding to security threats" later in this chapter). You can also use NetInfo to enable the root account, but doing so is asking for trouble.
){kind=link}
Figure 18.16 You can use the NetInfo Manager to change advanced features of Mac OS X services.
Remember that Mac OS X services run as Unix processes. Most Unix processes keep running even if you've logged out of your machine. Don't assume that a service is no longer accessible just because you've logged out. Either stop the service before you log out or shut down the machine rather than just log out of it.
You should also be sure that services that could run in the Classic compatibility layer are secure. See chapters 7 through 10 for details on securing these services, although all network services that run under Mac OS 9 do not necessarily run under Classic. To secure Classic services such as Program Linking, you need to run an older application that starts the Classic environment and then choose the service from the Classic Apple menu or the third-party user interface.
The Unix security community is an active one. Black hats (hackers) are always looking for new Unix security holes, and white hats (the good guys) are always working to fix them or to find them before the black hats do. Fixes are released in the form of patches that are applied to Unix-system files. Apple makes patches available through the Software Update System Preferences window. (Unix patches usually are applied through the command line.) It's important to run Software Update periodically or set it to check for updates automatically (Figure 18.17). Apple maintains a security Web site at http://www.apple.com/support/security/ that provides details of the updates and related security issues.
){kind=link}
Figure 18.17 Software Update will help you ensure that any security patches that Apple releases are applied to your system as soon as possible.