“I think sharing is overrated too. And helping others.” | ||
| --Bart Simpson | ||
Out of the box, Mac OS X Server supports many common file-sharing services. WebDAV allows Apache locations to be used as a repository for the collaborative file-editing activities. The AppleTalk Filing Protocol (AFP) serves to accommodate legacy Apple file sharing over AppleTalk or TCP/IP. Samba is used to provide SMB/CIFS shares for Windows clients. NFS shares provide familiar file-sharing services for UNIX and Linux users.
All these file-sharing services are disabled by default. Ideally, we would leave them this way; each one poses a security risk to your system. This is a perfect example for a security versus usability discussion. Given motive and enough time, a malicious user can eventually exploit one of these services to gain unauthorized access to a system. The truly paranoid would be advised to leave these services disabled. However, this is not always a realistic option. Only enable the services that are needed, and understand their function, keeping in mind the administration time needed to maintain them. None of these file-sharing protocols were designed with security in mind and some are completely devoid of any real security.
This chapter highlights the risks involved with each of the file-sharing services native to Mac OS X. Here, we will shed some light on what can be done to reduce those risks. In this chapter, we assume you have knowledge of any service being deployed. The material presented is not an exhaustive reference for these services, but rather a dissection of the security implications of each.
WebDAV is an extension to HTTP/1.1, the primary protocol for the web. It stands for Web-based Distributed Authoring and Versioning. WebDAV extends the HTTP protocol with an additional set of methods and headers. The primary goal behind the development of the WebDAV protocol is to allow for the collaborative editing of files over the web. A few common examples include
Distributed web site authoring and maintenance
Remote collaboration of documents
A network file system
The WebDAV protocol is still a work in progress. At the time of this writing, the completed aspects of the protocol include file properties (meta-data), concurrency control (locking), and namespace management (moving, copying, and creation of files). Aspects such as search management and version control are still being developed.
Because it is an extension to HTTP, WebDAV is commonly implemented as an add-on module to a web server. For the Apache web server, this module is called mod_dav. This module is included with the installation of Mac OS X, but is disabled by default.
Mac OS X has the capability to communicate with WebDAV-enabled servers through a built-in WebDAV client. Connections can be made directly from the Finder or on the command line. However, as of the Jaguar release this built-in client does not support SSL, so its use is quite limited. We suggest using Goliath, a WebDAV client that supports Mac OS X. Goliath is still being developed, but is quite usable. It supports SSL and the use of client certificates. Goliath is released under the GNU General Public License. Source code and binaries for Goliath can be found at: http://www.webdav.org/goliath/.
WebDAV can be used for a variety of reasons, but if not configured correctly, this service can be a security risk. Unauthorized access can lead to the denial of service, loss or theft of data, or the defacement of important web content.
This section discusses the process of securely setting up WebDAV on Mac OS X, beginning with some security considerations. Even if you are not planning to deploy WebDAV, it may be helpful to know some of the risks involved.
Obviously, it does not make sense to say that a network service is perfectly secure. When we refer to a secure deployment of any network service, what is meant is that steps were taken to reduce known risks. Over time, new vulnerabilities are exposed, and measures must be taken to address them. Although Apple does a fine job of keeping up with security patches, adding another service such as WebDAV still requires more attention on behalf of an administrator.
We advise you to strongly consider whether enabling WebDAV is necessary. Setting up a secure Apache installation is not a trivial thing. If Apache is not yet enabled, enabling it for the sole purpose of providing WebDAV access is probably not worth the risk. There may be other ways to address your requirements. For example, collaborative editing of files can be managed with Concurrent Versions System (CVS). CVS comes installed on Mac OS X and can be secured with SSH—an easier service to manage.
Only enable the locations that require WebDAV access. WebDAV can be enabled for an entire directory tree, or just a specific location in the Apache configuration. When possible, create special locations to be used specifically for WebDAV access. Allowing write access to an Apache location has some implications that may not be obvious. For example, a WebDAV user with write privileges can possibly alter the web server configuration by uploading an .htaccess file. Make wise use of Apache realms. If multiple distinct projects exist, segregate them so that users have access to only the files they need to access.
WebDAV access can be controlled on a per-user basis with the Apache Limit directive. Thus, you can limit which users can have write privileges to the location(s). WebDAV-enabled locations allow the web server to write to files under the document root. A compromised account would have obvious consequences, but malicious or ignorant users also can be problematic. Only grant authorship privileges to trusted users.
Another thing to consider with WebDAV locations is file permissions. As a result of the Apache process being a proxy for file operations, files must be read/write by the www user. There is no per-user–based access control as far as the WebDAV module is concerned. As a result, there is no quota system built into the WebDAV module. Later in this chapter we will cover some options that can be used to limit write operations, but the fact is, a malicious user with write privileges can cause problems.
Always use SSL with WebDAV-enabled sites. Always. SSL not only provides for the transport security of data, it also protects the authentication process. The process of setting up a SSL-enabled web server is covered in Chapter 6, “Internet Services.”
This section walks through the process of securely setting up WebDAV on Mac OS X and Mac OS X Server. The application Server Settings.app found on Mac OS X Server provides a graphical interface for enabling and configuring WebDAV locations. Our examples don’t use that tool because it does not allow for fine-grained control over the configuration. With a service such as WebDAV, it is important that you know exactly what the configuration specifies, and what operations it will allow.
The Apache module, mod_dav, enables Apache to provide WebDAV services. Any directory under the web server can be made available to WebDAV clients. As mentioned earlier, it is recommended that only those directories that require WebDAV access be given such.
Setting up Apache to provide WebDAV services on Mac OS X is a four-step process:
Modify the Apache configuration file.
Set up and secure passwords to restrict access to files.
Create a location for the WebDAV module to store a lock database.
Set up and secure the location where files will be stored.
Note, before setting up and enabling WebDAV, it is critical that SSL be configured and enabled for that server. WebDAV services should only be accessed through a SSL-enabled server. Given the nature of the service, access must be restricted, and thus the authentication process must be protected from eavesdropping. Setting up a secure Apache configuration with SSL is covered in Chapter 6.
The first step in enabling WebDAV access is to modify the main configuration file for apache, /etc/httpd/httpd.conf. For Mac OS X Server, the main configuration file is, /etc/httpd/httpd_macosxserver.conf. In this file, we will enable the web_dav module, set some WebDAV options, set up access control, and specify which locations will be WebDAV-enabled. We recommend creating a backup copy of the Apache configuration file before making any changes.
As mentioned earlier, the WebDAV module for Apache is disabled by default. To have the WebDAV module loaded into Apache’s address space, uncomment the following line:
LoadModule dav_module libexec/httpd/libdav.so
Next, enable the web_dav module. Uncomment the following line:
AddModule mod_dav.c
Locking information for the WebDAV module is stored in a database file. For security reasons, this file should always be kept outside the document root of the web server. The path to the lock file must be specified using the DavLockDB directive. The WebDAV module will create the file specified, if it does not already exist. WebDAV clients can specify a period of time (in seconds) that the server will wait before automatically removing a lock. This timeout value can be overridden with the DAVMinTimeout directive. The lock database directive must be placed in a global section of your Apache configuration file. The lock timeout directive can be placed in the global section, or in a container directive. In this example, we will create a directory, WebDAV, in the directory /Library/WebServer to be used to store the lock database. We also set a minimum lock timeout of 10 minutes (600 seconds).
DAVLockDB /Library/WebServer/WebDAV/locks DAVMinTimeout 600
Now that the WebDAV module is loaded, we need to specify which locations under the web server document root will be WebDAV-enabled, and establish access control for those locations.
Before making any of the following configuration changes, remember that WebDAV should only be enabled for SSL-enabled sites, and only for those locations that absolutely require it.
To enable WebDAV, specify the following under any container in the configuration file:
DAV on
If placed in a <Directory> directive, WebDAV is enabled for any subdirectories that may exist. If placed in a <Location> directive, WebDAV is enabled only for that location.
For this example, we will create a directory under the web server document root, specifically for WebDAV access. Access will be limited to three users, all of whom will have write privileges.
Create a new <Directory> directive. Set Options to None, and set AllowOverrides to None. Set the name of the realm; in our example, we set the realm to be “authors.” Set the authentication type to be basic. Digest authentication can be used, but basic authentication will be sufficient assuming this site is SSL-enabled.
Next, we need to set up access control for the users. Access to any location can be restricted with the user of an Apache Limit or LimitExcept directive. Because the WebDAV protocol extends HTTP, there are additional methods that can be specified in the limit directives. Table 7.1 lists the additional methods that are handled by the WebDAV module.
Table 7.1. Additional HTTP Methods for WebDAV
METHOD | DESCRIPTION |
|---|---|
| Fetch properties for a resource, or group of resources |
| Set, edit, or remove the properties of a resource |
| Create a new collection |
| Copy files or resources |
| Move or rename files or resources |
| Set a lock on a file or resource |
| Remove a lock on a file or resource |
We allow all these methods in our example because these users will be allowed authorship privileges. When complete, the Directory directive should appear as such:
<Directory "/Library/WebServer/Documents/webdav">
DAV on
Options None
AllowOverride None
AuthName "authors"
AuthType Basic
AuthUserFile /etc/http/.webdav.passwords
<Limit GET HEAD OPTIONS CONNECT PUT POST DELETE PROPFIND PROPPATCH
MKCOL COPY MOVE LOCK UNLOCK>
Require user preston brian bruce
</Limit>
</Directory>
This Limit statement allows authorship privileges. To add another user read access to this location, we would use an additional Limit statement. For example, the following gives Bob read access to this WebDAV location.
The lock file we specified earlier in the configuration file does not need to exist, but the path to this file should. Remember, this file must be outside the directory root, otherwise it runs the risk of being tampered with, or possibly deleted. In our example, we specified the lock database to be located in the file /Library/WebServer/WebDAV/locks. Create this directory:
bash-2.05a$ sudo mkdir /Library/WebServer/WebDAV
We need to give the www user ownership of this directory:
bash-2.05a$ sudo chown www:www /Library/WebServer/WebDAV
Only the www user needs access to this file, so we will change permissions on the directory:
bash-2.05a$ sudo chmod o-rwx /Library/WebServer/WebDAV
When the lock file is actually created, it will inherit these same permissions and ownership.
Any location that is WebDAV-enabled must be readable and writeable by the www user, or the user that the web server runs as. In our example, we specified the directory webdav under the document root. We need to create this directory and set its ownership accordingly:
bash-2.05a$ sudo mkdir /Library/WebServer/Documents/webdav bash-2.05a$ sudo chown www:www /Library/WebServer/Documents/webdav
Now deny other users access to this directory:
bash-2.05a$ sudo chmod o-rwx /Library/WebServer/Documents/webdav
All files created by the WebDAV module in this directory will now inherit these same permissions and ownership.
WebDAV-enabled locations should always require user authentication. With Mac OS X (client) using basic Apache HTTP authentication is the only option available for controlling access to Apache locations. The users and groups specified in the authorization file are separate from the system user accounts and groups. With Mac OS X Server, system accounts can be used. Mac OS X Server comes with an additional Apache module called mod_auth_apple. This module allows system accounts to be specified with the Apache “require user” or “require group” directives. Issues related to user and group authentication under Apache will be covered in Chapter 6. In our example, we have specified basic HTTP authentication, and the file /etc/httpd/.webdav.passwords to be used as the authentication file. To create the password file we use htpasswd and the -c option followed by the location where we want the password file created and the first user to be stored in the file.
bash-2.05a$ sudo htpasswd -c /etc/httpd/.webdav.passwords preston New password: Re-type new password: Adding password for user preston
Additional users can be added to this file, but because the file now exists, it is no longer necessary to use the -c option. More information about basic and other forms of HTTP authentication is covered in the section on Apache in Chapter 6.
After all users have been added to the authentication file, we need to lock down the permissions on that file. The www user needs read access for verification purposes, the root user will need write access. Because we are storing password information, no other users should have access to this file:
bash-2.05a$ sudo chown root:www /etc/httpd/.webdav.passwords bash-2.05a$ sudo chmod 640 /etc/httpd/.webdav.passwords
Setting up access control in this manner will work for both Mac OS X (client) and Mac OS X Server. Apache must be restarted for the configuration changes to take effect:
There are two more configuration options that are important to the security of WebDAV locations. The first one is an option for the WebDAV Apache module, the second is an Apache directive that can be used to limit the size of requests.
The DavDepthInfinity directive can be used to limit PROPFIND requests. WebDAV clients issue a PROPFIND request to retrieve information about a resource, or group of resources. A WebDAV client can specify a Depth value as an HTTP header to a PROPFIND request. If “Infinity” is specified in the depth header, the WebDAV module will build a response (in memory) for the resource, and all child resources, recursively. Under certain circumstances, this could present a problem. You can disallow recursive requests like this with the DavDepthInfinity directive. The syntax is
DavDepthInfinity On|Off
Place this directive under any WebDAV-enabled location, where you would place the WebDAV On directive. By default, infinite depth requests are not allowed.
LimitXMLRequestBody is a directive that can be used to limit the size of a request issued by a WebDAV client. This directive is actually a core Apache directive, but it applies because all WebDAV requests and responses are in XML. The directive takes a single argument, the size in bytes for the maximum allowed request body size. To disable any size checking, specify zero as the argument. This directive only limits the size of a single request. Thus, it is still possible for a malicious user to fill up disk space with repeated requests.
Both of these directives can be useful in securing WebDAV locations, but realistically, they come with their share of usability problems. WebDAV security really boils down to whether or not you can trust your users. If you cannot, you might want to reconsider whether you should enable WebDAV on your web server.
The remaining file-sharing services, AFS, NFS, and SMB, are generally more straightforward to configure. They are based on standard protocols and have a GUI configuration tool provided by Apple via the OS X Server Administration Tools. However, the fact that these services are easier to configure does not mean they are any less important to secure.
Apple File Service (AFS) provides file sharing for Mac OS Clients. AFS uses the Apple Filing Protocol (AFP) to control access and transport data. AFP is based largely on AppleShare IP, an older Apple file-sharing protocol used by AppleTalk. AFP has expanded AppleShare IP to handle Unicode file names and 64-bit file sizes.
AFS provides a robust user and group level authentication model. Objects within a share can be controlled on an individual level giving administrators tight control over their resources. When attempting to access AFS shares, a user must authenticate to the AFS server. After the user has been authenticated, access to objects is granted on a case-by-case basis. AFS has matured over the years to support encrypted authentication requests to prevent clear text passwords from transiting the network.
AFS can integrate with many authentication mechanisms. By default, Mac OS X supports NetInfo authentication and Kerberos. AFS also provides secure data transport via SSH.
AFS does not have IP-based access control. If you need to lock down access to AFS services based on source IP address, you will need to use an external mechanism such as a firewall to accomplish this.
In the General tab under the Apple File Service window of Server Settings, configure a logon greeting. Although this greeting does nothing to enhance the technical security of your host, it is a legal barrier. By placing a banner that states that only authorized parties are allowed to access this data, you create an electronic Do Not Disturb sign. In the event of an attacker using your AFS shares, the banner will be valuable if you seek legal recourse.
Figure 7.1 shows the Access tab. Disable guest access and enable secure connections. With secure connections enabled, clients can tunnel AFS connections to the server via SSH. See “Making Secure AFS Connections” later in this chapter. Set the maximum number of connections to a reasonable amount based on your user base. Finally, set your authentication mechanism to whatever method your host is utilizing.
Figure 7.2 shows the Logging tab. Enable the access log and select all events. This provides as complete an audit trail as possible. Finally, set an archival period that rotates logs in a timely manner based on your usage level.
By default, all shares are shared by AFS. For each share you do not want provided through AFS, you need to select the share point and disable AFS sharing under the Protocols tab.
Figure 7.3 shows the General tab for a share. Least privilege dictates that only the minimum required access is granted. Unless you absolutely require write access, set all levels to read-only. At the very least, set the Everyone value to read-only.
Server Message Block (SMB) file sharing is commonly associated with Microsoft Windows file servers. SMB was originally designed by IBM, and has become the de facto standard for all Windows operating systems. Samba provides services for NetBIOS-based applications. NetBIOS is an API that provides local network browsing, addressing, and transport for network aware applications.
Mac OS X provides SMB file services via the Samba package. Samba is an open source SMB server that has been ported to many UNIX variants, including Linux, FreeBSD, and Solaris. Samba is made up of many programs and a few servers. smbd is the primary server daemon that actually controls the file service of the host. nmbd is a daemon that provides NetBIOS name service and browsing capabilities to the host.
SMB specifies two different security models. Share Level Access provides access control on a share by share basis. A share is the term used in the SMB world to describe the root of a network accessible folder. Share level access requires only a password to gain access to a share and all files within that share. There may be a different password for read-only access versus read-write access to the share.
Obviously, this is not a very secure method of providing access to files. The password used to access the share is a shared secret. This provides no real way to determine which user has accessed the service. Also there is no fine-grained control to files within a share. If you know the read-write password for a share, you have the capability to write to any file on that share. This is completely unacceptable in a network of any reasonable size.
User Level Access is a much better way to control access to SMB accessible resources. User level access provides per user control to any resource or share. This allows for an accurate audit trail and fine-grained control of files and shares. This is the default mode for Samba and the way Mac OS X is configured.
SMB file sharing is disabled in a default Mac OS X Server installation. You must turn it on via Server Settings to use it. There are two security specific tabs in the Windows Services section. On the Access tab, you should ensure guest access is disabled (see Figure 7.4). Also, you should set a maximum number of connections to prevent a malicious user from making an infinite number of requests and eating up all system resources.
The Logging tab allows you to control how much information is logged when SMB file sharing is enabled (see Figure 7.5). Unless your server will receive incredibly high amounts of traffic, you should set the logging level to Verbose in order to track everything users are doing.
By default, all shares are shared by SMB. For each share you do not want provided through SMB, you need to select the share point and disable SMB sharing under the Protocols tab.
Figure 7.6 shows the SMB configuration options in Workgroup Manager. Be sure guest access is not allowed. Also, unless necessary, set all access to read-only. If you do require read-write access, do not assign read-write access to everyone.
Each user that requires access to SMB shares will need to have their authentication mechanism changed. Mac OS X contains a general purpose password server which can be configured to talk to other authentication servers and applications requiring authentication. Figure 7.7 shows a user configured to use password server authentication via the Workgroup Manager.
Workgroup Manager creates a configuration file in /private/etc/smb.conf, which is seeded with the data you entered into the GUI. However, there are other security-specific Samba options that you cannot access via Workgroup Manager. To implement the following changes, you will need to edit smb.conf directly using your favorite text editor.
smb.conf is structured in a hierarchical fashion. The following is an example of a smb.conf, which as been created by Workgroup Manager.
[global]
client code page = 437
coding system = utf8
guest account = unknown
encrypt passwords = YES
local master = YES
max smbd processes = 0
server string = Mac OS X Server
log file = /Library/Logs/WindowsServices/WindowsFileService.log
log level = 2
netbios name = mo
workgroup = workgroup
[homes]
comment = User Home Directories
browseable = no
read only = no
create mode = 0750
[Users]
path = /Users
public = NO
create mask = 0644
directory mask = 0755
read only = NO
comment = macosx
The [global] section specifies directives that are common to the entire samba installation. The other sections are directives that apply to specific shares. The [homes] section is a special section for allowing users’ home directories to be accessed via SMB. The other sections are standard Mac OS X shares and can be controlled at a high level via Workgroup Manager.
The directives in the default file are largely self-explanatory. The smb.conf man page contains a great deal of information for modifying your smb.conf.
Samba allows you to control access to either the entire server or to specific shares via IP address. Hosts can either be explicitly allowed or denied depending on your requirements. The hosts allow directive allows access from the IP addresses specified. Conversely, the hosts deny directive restricts access. For example to restrict access to the entire smb server to only the 192.168.0.0/24 network, add hosts deny 192.168.0.0/255.255.255.0 to the [Globals] section.
These control statements can be added to the [Globals] section or any individual share. You should examine your security requirements for any SMB shares and limit control in as fine-grained manner as possible.
You may have files within a share you do not want to expose to users. Samba allows you to veto access to files and directories that match a certain pattern. These patterns must be delimited by /’s. Veto files can be specified at the [Globals] level or for any specific share. For instance, you may not want users to access their ssh keys via the network. You also may want to block any file that ends in .tmp. To accomplish this, add veto files = /.ssh/*.tmp/ to the [Globals] section.
By default, Mac OS X logs Samba activities to /Library/Logs/WindowsServices/WindowsFileService.log. This location is configurable via smb.conf. There is generally no reason to change this.
Samba provides different logging levels depending on your need. Table 7.2 documents the different levels and what is logged.
Table 7.2. Samba Log Levels
LOG LEVEL | WHAT IS LOGGED |
|---|---|
0 | Errors only |
1 | Warnings and errors |
2 | Notices, warnings, and errors |
3 | Informational, notices, warnings, and errors |
4 | Debugging information |
The default log level of Mac OS X is 2. This can be changed via the log level directive in your smb.conf file.
Network File System (NFS) is a standard UNIX file service architecture. NFS is the final piece of Mac OS X’s file-sharing system. NFS was designed by Sun Microsystems to provide transparent access to file systems across a network. UNIX clients can import NFS filesystems and the overlying operating system is basically unaware the filesystem is not local. This seamless integration is accomplished by using remote procedure calls (RPC). NFS originally ran only via UDP but has since been modified to use TCP.
The protocol was designed many years ago when network security was not as big a concern as it is now. NFS is inherently insecure due to its architecture. It is a difficult protocol to prop up with external security mechanisms and should never be deployed outside of a LAN environment.
When a host receives a request for a NFS share, the primary mechanism of security is the UID of the remote user. When a remote user attempts to access a file on an NFS server, the user is treated as the local user with the same UID. This was originally designed to work in a closed corporate environment with central user management. If a user had a UID of 1045 on their workstation, they would have a UID of 1045 on the NFS server.
This is a problem. With the advent of inexpensive PC’s and free NFS clients, the level of authentication provided by the UID was lost. A remote workstation could spoof the UID of the client, including UID 0. Therefore, it is advisable to export filesystems read-only. Exports should be writeable only if you are sure you are in a closed environment and the security measures listed here are adhered to.
NFS also provides the capability to limit clients to select IP addresses. As with any service, you should limit access to only clients who require NFS filesystems.
NFS is made up of three components on the server side: portmap, mountd, and nfsd. Portmap is effectively a phonebook that handles RPC requests from client machines. It tells the client which port the service it is requesting is listening on. Mountd examines which files systems should be exported, and verifies clients are allowed to connect. Once mountd has been satisfied, it forks a nfsd process and hands the client off to it.
As Figure 7.8 shows, the configuration options in Server Settings for NFS are limited. Figure 7.8 shows that the configuration options allow you to control the number of servers spawned and the protocol to use. Unless you anticipate performance issues, select TCP as the protocol. This prevents potential spoofing in UDP packets in an effort to disrupt the NFS processes.
When a share is created, Mac OS X Server does not automatically export the filesystem via NFS. Figure 7.9 shows the Workgroup Manager configuration for a NFS exported filesystem. Add the IP addresses of the clients who need to connect to the server to limit access to NFS. Also, unless absolutely necessary, make the export read-only.
Via this interface, you also have the capability to map users to the user nobody. At the very least you should map root to nobody to prevent clients from reading files they should not have access to by spoofing their UID. There is an option to perform this mapping in Workgroup Manager. Ideally, you should map all NFS users to a special NFS user with no privileges. This NFS user should not be trusted to perform any sensitive activities on a host, so this is the safest manner in which to export filesystems. Unfortunately, this is not possible within Workgroup Manager. You must configure NFS from the terminal to achieve this level of security.
Normally, NFS exports are controlled via /etc/exports. Under Mac OS X, the export information is controlled through netinfo. Use nidump to view the database.
bash-2.05a# nidump -r /exports .
{
"name" = ( "exports" );
CHILDREN = (
{
"name" = ( /mp3" );
"opts" = ( "ro", "mapall=nobody" );
"clients" = ( "192.168.0.2", "192.168.0.3" );
}
)
}
Exports can be saved to a file and then manipulated by hand to modify the user to your NFS user. The exports can then be fed back into netinfo via niload -r /exports . <exportsfile.
NFS mounts are sometimes a fact of life. If your Mac OS X clients require data contained on a NFS share, the best way to secure the data is to re-export it via AFS. Mount the NFS share as a normal client on the Mac OS X server machine. Then, using the standard AFS sharing mechanisms, export the filesystems via AFS.
This setup allows for limited NFS exporting. The only NFS exposure is between the Mac OS X server and the host exporting the NFS file shares. Using AFS provides finer-grained control of data access and a more complete audit trail.
Unlike Mac OS X Server, Apple File Sharing on Mac OS X does not have a graphical configuration tool. Enabling the AFS on Mac OS X is as simple as it gets. In the System Preferences, under the sharing pane, select the Personal File Sharing checkbox (see Figure 7.10).
If you must enable this service, there are a few additional steps that can be taken to reduce the risk it poses to your system.
First, remove the capability for others to log in as a guest. Although guest users do not have a great deal of power, they have the capability to write to certain folders (called drop-box folders) and there is no reasonable way to limit the amount of data that can be written. To completely disable guest logins, open NetInfo Manager.app and navigate to the config directory. There should be a subdirectory named AppleFileServer (see Figure 7.11).
Under this directory, there are many properties for the AppleFileServer. One of them is called guest_access. Set this value to 0 to disable users from logging in as guest.
While NetInfo is still open, you may want to set up a greeting to be displayed each time users log in. Although this does not do anything for the security of your system, it can be a legal precaution. At least state who is authorized to use the system and what they are allowed to do. To add a textual greeting, edit the login_greeting property.
Finally, be sure the allow_root_login property is set to 0, to disallow root logins through AFS.
Like many other connection services, AFS connections can be initiated right from the Finder. However, this built-in AFS client is more concerned with connectivity than it is with security. This section explores issues related to initiating secure AFS connections, from a client perspective.
Secure connections for AFS can be accomplished with SSH and port forwarding. All that is needed is a means of authenticating the remote host and a secure communications channel. SSH provides this, and does so quite well. Also, because AFS now works over TCP/IP, it is easy to use with the portforwarding feature of SSH.
To initiate a connection, from the Go menu in the Finder, choose Connect to Server. This brings up the SLP dialog. Choose a remote host from the list, or enter the desired hostname or IP address in the address field, prefixed with the string, afp:// (see Figure 7.12).
The authentication dialog shown in Figure 7.13 contains an Options button.
The options for AFS connections can be misleading. There is an option to allow secure connections using SSH (see Figure 7.14). However, checking this box does not necessarily mean your connection will use SSH.
To ensure that every AFS connection attempt makes use of SSH, we need to modify a general preferences file. Each user has such a file located in ~/Library/Preferences/.GlobalPreferences.plist. Edit this file and locate the com.apple.AppleShareClientCore key. This key has a dictionary object with various attributes related to AFS. In this dictionary, locate the key, afp_cleartext_allow, and make sure the value for this key is false.
<key>afp_cleartext_allow</key> <false/>
Next, locate the key afp_ssh_force and be sure the value for this key is true.
<key>afp_ssh_force</key> <true/>
These two changes prevent authentication credentials from being sent in the clear, and most importantly, all successful AFS connections are tunneled over SSH. With each connection attempt, SSH is launched with options to forward some arbitrary local port to the AFS port (548) on the remote server. If the remote host doesn’t have SSH-enabled, or the host verification fails, the AFS connection attempt will also fail. At the time of this writing, it is not possible to adjust the arguments to SSH when used in this fashion.
OS X is an effective and robust platform for file services. However, file sharing is a service you should only offer if absolutely required. Understand the ramifications of any particular file-sharing method before deploying it. If you decide to use file services, only allow the access required, no more. Ideally, this means data is only provided on a read-only access. After you enable write access, proper configuration and auditing will make the difference between a secure and reliable installation and a resource that is a hazard to your entire organization.