S 5.82 Secure Use of SAMBA

Initiation responsibility: Head of IT Section, Administrator

Implementation responsibility: Administrator

SAMBA is a freeware software package for UNIX operating systems which, amongst other things, provides file, print and authentication services over the Server Message Block (SMB) and Common Internet File System (CIFS) protocols. The most important examples of SMB/CIFS clients are definitely the operating systems in the Microsoft Windows family. With SAMBA it is possible, for example, for Windows 9x or Windows NT computers to access shared files on a UNIX server directly. This obviates the need to take a detour over the FTP or NFS protocols or to install additional software on the client. In the current version, SAMBA simulates a whole range of Windows NT server functions so that in many cases it is possible to use a UNIX system with SAMBA in lieu of such a server.

If SAMBA is in use within the agency/company, the recommendations set out below should be considered.

Programming errors which sometimes can induce security loopholes have been discovered in older versions of SAMBA. An up-to-date version should be used, in which as far as possible all known security-relevant errors have been eliminated.

Using the file smb.conf, it is possible to configure the SAMBA server in an extremely flexible and detailed manner. However, this also makes the system somewhat complex. Before using SAMBA, it is therefore important to read the documentation thoroughly. The configuration should be carefully planned, documented and implemented through appropriate parameter settings in file smb.conf. For example, a long description of the various parameters can be viewed by entering the command man smb.conf. In the event that configuration settings are altered, checks should be performed using the documentation and appropriate tests to ensure that the change in configuration does not result in unwanted side-effects.

The following parameters are particularly problematic in terms of the possible security risks associated with them. They should therefore only be used after checking thoroughly all the possible effects on the IT security of the server.

With the testparm program it is possible to check whether the settings in file smb.conf are permitted. Of course it is not possible using that program to draw any conclusions as to whether the settings do have the desired effect or security-relevant effects. Creation and maintenance of the smb.conf file can also be supported by graphical user interfaces, for example using the Samba Web Administration Tool (SWAT) which is supplied as standard with the SAMBA package.

SAMBA currently offers four different means of achieving client authentication. With the setting security = user, the SAMBA server checks whether the client is transmitting a valid combination of user ID and password. With security = server or security = domain it leaves this check to one or more other SMB/CIFS servers which it trusts and are specified via the parameter password server. On the other hand, if security = share is set, only a simple password check is performed and the client does not have to transmit any user ID. This procedure is considerably weaker than authentication via user ID and password and should only be used if the data on the SAMBA server does not have to be protected. An example here might be a server with write-protected data medium and data that can be accessed by the public. In this case it is appropriate not to have any authentication, and the easiest way of implementing this is via the setting security = share.

Either plaintext passwords or encrypted passwords can be used for client authentication. As plaintext passwords can easily be intercepted during their transportation over the network using freely accessible tools, in principle only encrypted passwords should be used. On the client side, encrypted passwords are supported e.g. by Windows 95 (with installed SMB update), Windows 98, Windows NT 4.0 and Windows 2000. In file smb.conf on the SAMBA server, encrypted passwords are activated by the parameter encrypt passwords = yes. Unlike plaintext passwords, a SAMBA server cannot check encrypted passwords with the authentication mechanisms of the underlying UNIX operating system (which, for example, references /etc/passwd or /etc/shadow). It is therefore necessary to have an additional password file, which is specified via the parameter smb passwd file. This file contains the encrypted passwords and must be carefully protected from unauthorised access.

The rights of a user to access directories and files via SAMBA are derived partly from the settings in file smb.conf and partly from the access rights of the file system on which the shared data is held. Here too careful configuration is necessary to ensure that access rights are granted in a consistent manner. Unlike on Windows NT servers with NTFS drives, when SAMBA is used it is not always appropriate to grant access rights exclusively through the file system. The reason for this is that commonly used UNIX file systems implement a different security model, based on permissions and ownership, than NTFS. Depending on the specific application, it is therefore necessary to check whether certain superordinate access restrictions can be better configured through file smb.conf. Reference is made here to the parameters (in)valid users and read/write list.

The following parameters can potentially allow access restrictions to be circumvented:

admin users
force group / group
force user
guest account
hosts equiv
username / users / user
username map

If any of these parameters are used, the possible security implications should therefore be carefully examined.

Symbolic links in shared directories can have the result of giving clients unauthorised access to files outside of the shared area. It is recommended that this is prevented by setting the parameter wide links = no. However, it should be noted that this parameter can slow down throughput as the extra checks required use up some of the processor capacity. If this could result in operations being hampered, one could try setting the parameter getwd cache = yes. As an alternative to checking symbolic links, consideration should be given to using the parameter root directory = . This setting prevents access to directories and files outside of <path>. However, all the files needed to run SAMBA, including the password files, must then be copied to subdirectories of <path>, including the password files.

Amongst other things, logon scripts for clients can be provided on the server via the share [netlogon]. Under no circumstances should users be able to modify files in this share. It is recommended that writeable = no and guest ok = no or that equivalent parameters are set for this share.

The following parameters are preconfigured and should not be altered as this might impair proper and secure operation of IT systems.

kernel oplocks =
locking = yes
magic [...] =
map to guest = Never
passwd chat debug = no
password level = 0
share modes = yes
use rhosts = no

If the services of a SAMBA server are used over larger networks which are not completely under the organisation's own control, consideration should be given to protecting the communications links through the use of cryptographic procedures. This is especially recommended if there are compelling reasons as to why plaintext passwords have to be used. Protection can be provided through appropriate hardware or software components. SAMBA provides special support for the use of SSL. To avail oneself of this possibility, an SSL software package, normally the freeware SSLeay software, must be installed on the SAMBA server. On the client side, a SSL proxy software package is needed; this is available free of charge for Windows NT and UNIX clients. Windows 9x clients can use the SSL proxy of a Windows NT or UNIX client in their subnetwork. The first steps of configuration involve defining a Certification Authority (CA) and generating key pairs and certificates for the server and clients (assuming this has not already been done). The corresponding procedures are explained in the documentation for SSLeay. To activate SSL on the SAMBA server, as a minimum the parameters ssl = yes and ssl server cert = should be set in file smb.conf. If the private key of the server is not stored in the same file as the server certificate, the parameter ssl server key = is necessary as well. It is recommended enabling checking of server and client certificates. This requires the parameter settings ssl require clientcert = yes and ssl require servercert = yes, also ssl CA certDir = or ssl CA certFile = . For every client on which an SSL proxy is used, the key pair and the certificate for that client must be copied to a protected directory. The paths of these files and the name of the SAMBA server are sent to the SSL proxy on start-up as parameters. The clients can now call up the desired SMB/CIFS services from the relevant SSL proxy. The proxy forwards the requests - protected through the SSL protocol - to the actual SAMBA server. As a result, as far as the clients are concerned, the services appear to be provided by the SSL proxy rather than by the SAMBA server.

If there are compelling reasons why plaintext passwords have to be used, this can be enforced on clients which run under the operating systems Windows 9x, Windows NT 4.0 and Windows 2000 through particular Registry entries. For example, this is necessary under Windows NT 4.0 with Service Pack 3 or higher, as unless the Registry entries are modified this version of the operating system also refuses to transmit plaintext passwords even if the server does not support encrypted passwords. Otherwise the client may be unable to log on successfully to the server. However, it should be noted that where plaintext passwords are used, additional protective measures (e.g. VPN or SSL) are needed for the communications links in every case.

Even once the Registry has been modified, it may be difficult for a Windows NT 4.0 client to log on to the server using a plaintext password, as in this case the user is asked to enter his password every time he wishes to establish a connection, and where different resources are used on the server this can be very annoying. This is another reason why, if possible, the use of plaintext passwords should be avoided completely.

Further recommendations regarding the secure configuration of clients will be found in safeguard S 5.38 Secure Integration of DOS PC's into a UNIX Network and in the modules 5.5 "PC under Windows NT" and 5.6 "PC with Windows 95".

Additional controls:

• Are changes in the SAMBA configuration documented and tested in actual operation prior to use?

• Are encrypted passwords used?

• Are write accesses to the share [netlogon] prohibited?