Samba, an open-source application that provides the ability to share resources between UNIX-based systems and Windows-based systems, is a very popular solu- tion to Windows/UNIX interoperability.The problem is that it is very difficult to configure securely.The configuration file, smb.conf, is complex, with a bevy of seldom used options. In this section, we discuss some of the better options for secu- rity within the smb.conf file and look at some of the more current Samba exploits.
The format of the smb.conf file is fairly straightforward. Here is a sample ele- ment from the file:
[accounting]
path = /export/acctg writable = yes browsable = no
valid users = tealc djackson admin users = scarter
max connections = 3
This entry sets up a share called accounting at the specified path.The writable parameter defines whether or not the share will be read/write or read only. In this case, we have specified that the share will be read/write.We will not, however, allow the share to be seen via net view or in the browse list.We prevent this by specifying that browsable is set to no.We define three valid users, one of them having administrative access. Administrative access, defined by the admin users parameter, should be carefully considered. Any user with admin access to the share will have total control and will be able to take any action, regardless of file permissions.
There are some options that you should never see in a smb.conf file.These options are detailed in Table 5.2.
Table 5.2 Dangerous Smb.conf Configuration Directives Directive Description
root postexec Indicates a command to be run once the service (share) is no longer in use. The command is run with root privileges on the server.
smbrun If Samba is properly installed, this parameter should not need to be set. The parameter takes a value that indicates the location of the Samba binary. It could be used to force the use of a “Trojaned” or altered binary. root preexec Indicates a command to be run when the service is
connected to. The command is run with root privileges. unix password sync If set to true, this parameter allows the Samba server
to run, as root, a command to change the Solaris pass- word, without any verification. The program that is run is also configurable, which makes this another hole. add user script Assuming special conditions are met, the script that is
defined by this parameter will be run, as root, to add a user.
delete user script Assuming special conditions are met, the script that is defined by this parameter will be run, as root, to delete a user.
preexec / exec Similar to root preexec, except the program is not run as root.
panic action Specifies a program to run when Samba crashes and could be used to attack the system.
hosts equiv Specifies the location of a file that contains the name of hosts and users that are allowed unauthenticated access.
Although it is very convenient to use the [home] share features to allow the addition of users’ home directories, it is not a very good security idea, primarily because of the dynamic nature of that addition. If you take the time to manually configure each user’s home directory, you’ll be able to specify much finer-grained control. An example is the addition of a hosts allow directive restricting share access.
There are some parameters that you should use as much as possible.The hosts
allow and hosts deny are two good examples.These specify systems that can or
cannot access your services. Another handy feature is the ability to specify valid interfaces, using the interfaces directive, and then only allow SMB and NMB to use defined interfaces with the bind interfaces only.This is a great way to restrict access, but remember to include the loopback address in the interfaces directive, or some SMB features won’t work as advertised.
As with NFS, always be very cautious when you allow clients to connect with write access. Any shares with writable=yes should, ideally, have access control with valid users or invalid users and hosts allow or hosts deny. Furthermore, the [net- login] share should never have write allowed.
Samba allows a few different authentication methods.These are user, share,
server, and domain. It is important to understand the differences between the four and which best suites your needs.To this end, let’s take a moment to examine the features of each option, as quoted from the smb.conf man page:
■ security=share When clients connect to a share-level security server,
they need not log on to the server with a valid username and password before attempting to connect to a shared resource (although modern clients such as Windows 95/98 and Windows NT will send a logon
Table 5.2Continued
request with a username but no password when talking to a security=
share server). Instead, the clients send authentication information (pass-
words) on a per-share basis at the time they attempt to connect to that share.
■ security=user This is the default security setting in Samba 2.0.With
user-level security, a client must first log on with a valid username and password (which can be mapped using the username map parameter). Encrypted passwords (see the encrypted passwords parameter) can also be used in this security mode. Parameters such as user and guest only, if set, are then applied and could change the UNIX user to use on this con- nection, but only after the user has been successfully authenticated. Note that the name of the resource being requested is not sent to the server until after the server has successfully authenticated the client. For this reason, guest shares don’t work in user-level security without allowing the server to automatically map unknown users into the guest account.
■ security=server In this mode, Samba tries to validate the username/
password by passing it to another SMB server, such as an NT box. If this fails, it reverts to security=user, but note that if encrypted passwords have been negotiated, Samba cannot revert to checking the UNIX password file; it must have a valid smbpasswd file to check users against. See the documentation file in the docs/ directory ENCRYPTION.txt for details on how to set this up. Note that from the client’s point of view security=
server is the same as security=user. It affects only how the server deals with
the authentication; it does not in any way affect what the client sees.
■ security=domain This mode works correctly only if smbpasswd has
been used to add this machine into a Windows NT domain. It expects the encrypted passwords parameter to be set to true. In this mode, Samba tries to validate the username/password by passing it to a
Windows NT primary or backup domain controller, in exactly the same way that a Windows NT Server would do. Note that a valid UNIX user must still exist, as must the account on the domain controller, to allow Samba to have a valid UNIX account to which it can map file access. Note that from the client’s point of view, security=domain is the same as
security=user. It affects only how the server deals with the authentication; it does
not in any way affect what the client sees.
namely Microsoft Windows.There are holes, and even the most restrictive settings won’t always plug them. As with any file-sharing service, you must be vigilant. Patch or update the software as often as available.Test, test, and test again.