TOPIC
This document describes some actions that you can taken to adjust the security of a Mac OS X Server configuration.
DISCUSSION
Network servicesThe Network settings panel lets you turn on these services: Denying access to FTP servicesIf you turn on the FTP server, then you can deny access to specific users by listing their user names in /etc/ftpusers. Denying access to LPD servicesIf your server computer acts as a print server, then you can restrict print services to specific client computers. To do so, edit /etc/hosts.lpd so that it lists the host names of the clients. If /etc/hosts.lpd contains a line consisting of a single plus sign, then print services will be available to any client. If you want to restrict access to specific clients, make sure that /etc/hosts.lpd does not contain a line consisting of a single plus sign. If print service is turned off in the Network settings panel, then /etc/hosts.lpd will be renamed as /etc/hosts.lpd.disabled. Password shadowingPasswords in Mac OS X Server are stored in a protected form so that the original password cannot be recovered directly. However, there remains the possibility that someone might guess a password. For this reason, even the protected passwords are hidden (or "shadowed") from unprivileged users. When an executable without special privileges uses BSD-level APIs such as getpwent, getpwnam, and getpwuid, an asterisk ("*") is returned for the passwd field rather than the actual protected password. In addition, user records in NetInfo are created by default with a _shadow_passwd property. If this property exists, then unprivileged executables retrieving those records from NetInfo will receive an asterisk rather than the actual protected password. Note : This feature is actually more general. Any property in a directory that contains _shadow_propertyname will be so shadowed. The _shadow_propertyname doesn't need a value. If it has values, they are ignored. For this protection to be effective, it is still necessary that you restrict access to your NetInfo domains to trusted hosts as described later in this section. Because even protected passwords for network accounts may still be vulnerable to sniffing as they pass across the network, it's important to control all access to your local network. If it is necessary for an unprivileged executable to perform password-based authentication, then it's possible to do so by invoking the setuid-root executable /usr/libexec/chkpasswd, passing it the user name as an argument and the password via a pipe. A non-zero exit code indicates that the password is incorrect. Note : Chkpasswd accepts the same options as passwd and uses getpass() for its input. It may be necessary to call setsid() in the child before executing it. This will be done automatically if it is invoked from the Yellow Box using NSTask. Versions of NetInfo prior to that shipped with Mac OS X Server will not shadow passwords and will ignore the _shadow_passwd tag. For the most part, old and new versions of NetInfo can work together and serve both old and new clients. The one exception occurs if you perform from an older client computer an administrative operation, such as changing the password, on a user record stored on a new Mac OS X Server NetInfo server and the record contains the _shadow_passwd tag,. In this case, you may need to open the administrative application as root to perform the operation. Alternatively, you can remove the _shadow_passwd tag from the account. NetInfoYou can limit access to a NetInfo domain by creating a top-level property listing the Internet addresses of those networks that are allowed access to the NetInfo domain. In most cases, this property is created by default when you create a domain. You may want to change this property later. The values of this property should be the IP network addresses of networks to which you want to grant access. These addresses must have one of these forms: 17 17.202 17.202.15 Alternatively, it is possible to refer to a network by name, if that name is listed under /networks within the same domain. If the trusted_networks property does not exist, access will be granted to anyone. Access will always be granted to the local computer on which the domain is being served. If the property exists but has no values or no valid values, then access will be denied to all but the local computer. This should be the default for the local NetInfo domain, but this will prevent remote administration of the local domain. See the NetInfo man pages and documentation for more information. Note : Because IP is not a secure protocol, filtering based on IP addresses may not be effective, depending on your network configuration. Mach IPC and distributed objectsA number of facilities in Mac OS X Server use Mach IPC for communication. This includes those that make use of distributed objects, whose default transport mechanism uses Mach IPC, as well as others, such as the window server. The nmserver has the capability to allow Mach IPC to be communicated transparently across the network. This allows for such features as the NSHost remote window serving. NSHost in particular can be turned off for security purposes using the 'Private Window Server' setting in the Expert Preferences module. However, the private window server setting does not protect the other facilities that make use of Mach IPC, which need to be protected for the same reasons and under the same circumstances as the window server. To protect all of these facilities, nmserver has several new options. First, you can use the Network settings panel to turn on or off the capability to act as a server for remote Mach IPC. This controls the MACHIPC setting in /etc/hostconfig, setting it to either -LOCAL- or -SECURE-. With the -SECURE- setting, the nmserver will refuse all remote lookup requests. With the -LOCAL- setting, responses to remote requests will be controlled by the file /etc/nmserver.access. The default /etc/nmserver.access file contains entries allowing access to all of the standard Apple-supplied services for which remote access is likely to be useful, including NSHost, Yellow Apple Events, Terminal services, remote build services, WebObjects monitoring, etc. If you have an additional DO-based or Mach IPC-based service to which you want to grant remote access, add an additional line to this file consisting of the name under which the service is registered, followed by a colon, then by a comma-separated list of the IP network or host addresses to be granted access, or a plus sign to grant access to anyone. A question mark used in the service name acts as a wild card for any single character, an asterisk for any number of characters. If you want to restrict access to some of the Apple-supplied services, then edit the corresponding lines in the file. To disable a particular line, you may turn it into a comment by preceding it with a pound sign. Alternatively, the MACHIPC setting in /etc/hostconfig may be changed to -UNRESTRICTED-. This will grant access to any service to any host. This should be done only in well-controlled network environments. Another alternative for particularly hostile network environments, is to add a flag -nevernet after the -nonet flag in the invocation of the nmserver in /etc/startup/0500_MachMessaging. This will prevent the nmserver from ever connecting to the network and any use of remote Mach IPC. However, this will interfere with some applications (including the Blue Box) and is not intended for normal use. The IP network or host addresses used in /etc/nmserver.access may use any one of the formats given above for trusted_hosts, or a variety of other formats, including the ability to specify ranges of addresses or subnet masks. For example: 17.202.12.0 / 255.255.252.0 17.202.15.177 - 17.202.15.181 17.202.4 - 17.202.12 / 255.255.252.0 Note : Because IP is not a secure protocol, filtering based on IP addresses may not be effective, depending on your network configuration. |
Document Information | |
Product Area: | Mac OS System Software |
Category: | Mac OS X Server |
Sub Category: | General Topics |
Keywords: | kmosXserver |
Copyright © 2000 Apple Computer, Inc. All rights reserved.