S 4.328 Secure basic configuration of a Samba server

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

After the Samba server has been installed, it is necessary to specify a secure basic configuration of the service. This includes the settings for the access controls, amongst other settings, but also settings that have an influence on the performance of the server.

The main configuration file for Samba is the smb.conf file . This file is normally located in the directory /etc/samba/. This configuration file contains several different sections, one section for global settings and several sections for share-specific configurations. The share-specific configuration sections are easy to recognise, because these sections start with a label that is not "[global]". Parameters located in the global section apply to the entire configuration. Parameters in share-specific sections, on the other hand, only apply to the corresponding share. All configuration parameters are described in the documentation and in the man page for smb.conf.

The following describes the most important configuration settings:

Security modes

The most important parameter relating to user authentication is the parameter "security". The Server Message Block (SMB) protocol defines two different security levels:

In the share level security level, access is controlled at the share level. A share is only protected by a password in this security level. Any user who knows the password may access the share in this case. In contrast, the user level security level controls access at the user level. This means that it is possible to grant each user individual rights for a share. The user must provide authentication before being allowed to use the share. Samba implements these two security levels in five different ways, which are referred to as security modes. The user level security level is implemented in four different ways (user, server, domain, and ads security modes), while the share level security level is only implemented in one way (share security mode). The share security mode is the only mode in which access is controlled at the share level. All other security modes control access at the user level.

The individual security modes are described in more detail in the following:

Samba only delegates authentication to a domain controller in the same manner as a Windows NT server would delegate authentication when it is in the domain security mode.

The domain and ads security modes are very similar. The following aspects should be taken into consideration when deciding to use one of these two security modes.

In the domain security mode, every Active Directory can add Samba services as members. This does not only apply to domains operating in the so-called mixed mode, but domains operating in the Windows 2003 infrastructure mode are also able to add members that are NT-compatible. The difference is that domains in the Windows 2003 infrastructure mode do not allow the addition of an NT4 backup domain controller (BDC). This aspect is irrelevant anyway, though, because Samba cannot use such a BDC (see S 2.437 Planning the use of a Samba server).

The security policies of the information system may require the use of Kerberos. Kerberos is generally considered to be much more secure than NTLM (NT LAN Manager), although NTLMv2 also provides a perfectly acceptable security standard.

By default, Samba uses the NTLM or NTLMv2 procedure for authentication. In order to force Samba to use NTLMv2 only, the parameter "ntlm auth = no" must be specified in the configuration file smb.conf.

One advantage of Kerberos over NTLM is the lower load on the domain controller and the lower network load. In an NT domain, a member server must query the domain controller every time a user attempts to log in. A Kerberos ticket, on the other hand, is valid for a specific time and is also independent. If a user is able to provide authentication to the Samba service using a valid ticket, the user does not have to provide additional authentication to the domain controller. The load placed on the domain controller and on the network can also be reduced through the use of Winbind (see S 4.333 Secure configuration of Winbind under Samba).

When the NT-compatible RPCs are used, Windows 2003 only lists the first 100 users. In contrast, all users are displayed when LDAP is used. Listing the users is a practice that should be avoided, because this process may take a long time on a large domain. If it is necessary to list the users, though, the ads security mode should be selected.

The Active Directory scheme also includes a concept referred to as the site concept. Every domain controller and every member computer is assigned to a site. If a member computer wants to connect to a domain controller, the domain controller must be located in the specified site. Samba only offers the corresponding mechanisms when in the ads security mode.

The time synchronisation and the existence of a properly functioning domain name system (DNS) are very critical for the ads security mode. When Samba looks for a domain controller, it only searches in the ads security mode using DNS and not using the Network Basic Input/Output system (NetBIOS) name resolution. Kerberos is used for authentication purposes. The security of Kerberos depends in part on having synchronised clocks on all computers in the network. If this is not the case, authentication using Kerberos will fail. If the ads security mode is used, consideration should be given to using a Windows DNS server as a name server and to using it for the Samba service as a time server. This can be realised in the Samba service by entering the corresponding parameters in the /etc/resolv.conf and /etc/ntp.conf files.

Older versions of the Kerberos libraries often cause serious problems for the cryptographic algorithms used in the Active Directory. They either completely lack support for the HMAC-MD5 hash procedure required or the implementation of this hash procedure is incorrect. Amongst other problems, this may also cause computer crashes due to the use of Kerberos. Manufacturers of proprietary Unix operating systems in particular are prone to supplying Kerberos libraries that are sometimes too old.

The ads security mode is also significantly more advanced when compared to the domain security mode. Due to the more complex installation and configuration procedures required when operating Samba in the ads security mode, it is recommend to use the domain security mode in small domains with only one site or one LAN. If Winbind will be used with the ads ID mapping backend (S 4.333 Secure configuration of Winbind under Samba), Samba must be operated in the ads security mode.

User-based protection

In general, only selected users and user groups should be allowed to connect to the Samba service. For this reason, access to the service should be restricted in the configuration file smb.conf using the "valid users" option. It is important in this case to set this option in the [global] section of the configuration file smb.conf. The parameter can also be used in a share-specific section of the configuration file, but this will only restrict access to this share. An example of such a setting includes:

valid users = @smbusers Administrator

The example shown above restricts all access to the server to only those users who are members of the "smbusers" group and the "Administrator" user. This option is not set by default. In this case, every user who has a valid account can log in to the server.

If a user is entered in both the "valid users" and the "invalid users" list, attempts to log in by the user will be denied.

The special characters in the group names are interpreted in the following manner:

The special characters + and & can be combined in any way desired to specify the order in which the groups will be searched when resolving names.

Host-based protection

By default, Samba accepts connections from every host. For this reason, Samba should be configured in such a way that only connections from hosts and networks considered secure will be accepted. Samba offers its own "tcpwrapper" implementation for this purpose. The "hosts allow" and "hosts deny" options are available in the configuration file smb.conf for the use of this tcpwrapper. An example of such a setting includes:

hosts allow = 127.0.0.1 192.168.2.0/24

hosts deny = 0.0.0.0/0

The example shown above only allows connections from the localhost (127.0.0.1) and from IT systems with Internet Protocol (IP) addresses between 192.168.2.1 and 192.168.2.255. All other attempts to establish a connection are denied by the Samba service and the message "not listening on called name" is returned by the service.

The network address 127.0.0.1 must be allowed in order for the following Samba applications to function properly:

Network interfaces

By default, Samba connects to all available network addresses of the system. Samba should be configured in such a way that it only connects to network addresses considered secure. Undesired packets will not be forwarded to Samba processes in this case.

The "interfaces" and "bind interfaces only" options in the configuration file smb.conf are available for this purpose. An example of such a setting includes:

interfaces = lo eth0 bind interfaces only = yes

In the example shown above, Samba will only connect to the addresses of the lo and eth0 network interfaces. If someone attempts to connect to the Samba service using the network device ppp0, for example, the operating system will deny a request to establish a transmission control protocol (TCP) connection. In this case, the client receives a message stating that the attempt to establish a TCP connection has been denied. This information can be useful to an attacker under some circumstances. For this reason, the safeguard described in S 4.331 Secure configuration of the operating system of a Samba server for the configuration of a local packet filter should be implemented.

A packet filter can be used to ensure that undesired incoming packets are simply ignored.

Packets from address 127.0.0.1 (lo interface) should be allowed so that programs running in the Samba environment operate properly. Additional information on this subject can be found in the section on host-based protection.

Shares

The "follow symlinks" parameter specifies if Samba will follow a symbolic link in the Unix file system or if an error message will be displayed for the user. By default, this parameter is set to "yes". The default setting of the parameter should be used even if it takes smbd a little more time when listing directories.

The "wide links" parameter specifies if the user will be able to follow symbolic links in the Unix file system whose destination is located outside of the shared directory structure. This includes files and directories on the other end of the links as long as the corresponding file system authorisations are available. The default setting for this parameter is "yes". This parameter is ignored when "follow symlinks = no" is specified. If "wide link= no" is specified, it is possible that smbd will run noticeably slower because every link needs to be checked first. If this parameter is set to "yes", it is possible to prevent a user from accessing the information in the folder /etc/ via a symbolic link, for example. If the security policies state that users are not allowed to have any access to information located outside of the shares, it is recommended to set "wide link = no".

Samba offers additional capabilities in case high requirements are placed on the performance and it is still necessary to prevent access to files located outside of the shares, although this comes in conjunction with more complex administration.

The "root directory" parameter specifies the directory to which Samba will switch after initialisation. The chroot() system call is used to do this. By default, the root directory parameter is set to "/". If this parameter is set to "root directory = /var/fileserver/", for example, none of the processes started by Samba in the future will be able to access files not in "/var/fileserver/". This also includes some files that are needed by Samba for proper execution. In this case, it must be ensured that the following files are available for Samba in the directory /var/fileserver/:

In addition, there may even be more files that need to be available in /var/fileserver/ for Samba. Whether or not this is true depends on which operating system is used.

[netlogon] share

On the [netlogon] share, Samba can provide clients with Windows NT-compatible policies or login scripts, for example. If a [netlogon] share is configured, it absolutely must be ensured that unauthorised users are not able to modify any files in this share. This can be achieved using the share-specific parameter "read only = yes", for example.

User databases

Samba cannot authenticate users with the help of the mechanisms of the underlying Unix operating system. Samba must store the hash values (LAN Manager (LM) and/or NTLM Hashes) of the user passwords used in the Windows environment separately. Samba uses backends for saving the Hash values used. Depending on the backend used, Samba may also be able to store other information on the users in addition to the hash values.

A simple text file, a database, or an LDAP directory service that is provided by OpenLDAP, for example, can be used as a backend. Several backends can be used simultaneously in Samba 3.0.0 to Samba 3.0.23. Earlier versions as well as later versions of Samba do not support this function. Possible backends are:

It must be ensured that users are not able to read the hash values from the backend. For this reason, only the "root" user should have read and write access to the file in which the user information is stored when using the smbpasswd and tdbsam backends. No other user should have these access rights to this file. If the ldapsam backend is used, the access rights can be implemented in an equivalent manner using access control lists (ACLs).

Since the hash values are synonymous with plain text passwords in Windows, the users should not have any access to the hash values. To illustrate the consequences of this fact, the following contains a short description of the NTLM and NTLMv2 authentication procedures of Windows. The procedure used by a Windows computer for encrypted authentication is an implementation of a symmetric encryption algorithm and is realised using a challenge/response procedure. The procedure is executed roughly in the following manner:

If an attacker obtains access to the user name and the hash value of the corresponding password, the following procedure could be used by the attacker: if an SMB client is provided with the user name and the hash value of the user password as the password, the SMB client normally applies a hash function to the password entered before it sends its response to the server. Authentication would fail in this case. However, if an attacker uses an SMB client (for example a modified version of smbclient) that sends the user name and password to the server without applying a hash function to the password entered first, the attacker will be able to authenticate successfully. For this reason, the hash values of the plain text passwords are just as valuable in Windows as plain text passwords.

Review questions:

© Federal Office for Information Security. All rights reserved.