
Protecting Samba file servers in heterogeneous environments
Teamwork
Whether you run Active Directory (AD) with Windows servers or Samba 4 domain controllers, you will always want to provide at least one server for file and print services. If the choice is a Samba server, you have to bring two worlds together. The first step will always be to select and install the distribution; only then can you think about configuring the Samba server. The first part of this article deals with the criteria for choosing a distribution and installing the system safely. The second section then deals with the secure configuration of the Samba service.
A Suitable Distribution
When choosing a distribution, you should consider the following points:
- Which distribution is already used in your company? Don't create a distribution zoo.
- Which distribution do you know best?
- Which distribution offers the right Samba version for you?
- How long will updates be available?
The topic of the Samba version is very important. At the time of testing, Samba versions 4.2 to 4.5 were available directly [1] and from SerNet [2]. (At the time of print, versions 4.6 to 4.8 were available.) If you always want to use the latest version (e.g., the pre-release or release candidate), you can compile Samba yourself. Another important point when choosing the Samba version, and therefore also the distribution, is support from the Samba team.
Every fall and spring a new Samba version is released. Maintenance and updates directly from the Samba team are available for the last three versions; at the time of testing, this meant versions 4.7, 4.6, and 4.5. With all other versions, you are dependent on the publishers of the distributions promptly delivering patches in case of vulnerabilities. Updating can be difficult on NAS boxes, because they are often equipped with very old Samba versions.
To be as up-to-date as possible, in this article, I want to show you the installation and configuration of a Samba file server in an AD domain with Debian Stretch. Except for the basic installation and method of installing packages, you can apply this article to all distributions. I used the network install version of Debian and only installed the default packages and the SSH server. A graphical user interface is not used for security reasons. Later, the system will be managed exclusively via SSH. Before Samba is installed and configured on the system, you will want to deal with system security and pay attention to the following during installation: (1) Partition your system, (2) do not install a GUI, and (3) do not install any services that you do not need on the system.
The first step en route to a secure file server is always partitioning. You should place the following areas in separate partitions:
-
/var
(read/write) -
/boot
(read only) -
/usr
(read only) -
/
(read/write) - Directories for your shares (read/write)
Later, the /boot
and /usr
directories only need to be read/write-mounted when updates are installed. One more tip about the partition on which you will be setting up your shares: If only user data and no executable programs are to be stored there, you can specify the noexec
option when mounting. In this case, programs that are stored here cannot be executed. This setting could be important, especially with regard to a vulnerability that was present during testing [3].
After installation, you can connect to the server via SSH. A direct connection as root is not possible; the configuration of SSH prohibits a direct login as root, and you should not change this setting. The su
command helps you become root after logging in. A dash after su
also gives you the complete environment with all the variables of the root user, because it simulates a complete login process; without the dash, you only change identity.
After the basic installation of the system, you should test which ports are open with the netstat
command. If this command is not immediately available, you need to install the net-tools package. Listing 1 shows the netstat
output.
Listing 1: netstat Output
root@fs01:~# netstat -tl Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:ssh 0.0.0.0:* LISTEN tcp6 0 0 [::]:ssh [::]:* LISTEN
As you can see, only port 22 for SSH is open for incoming connections for both IPv4 and IPv6. If you are not (yet) using IPv6 on your network, you should disable it, because what good is a secured IPv4 connection if access via IPv6 would be possible? To disable IPv6 on a Debian system, create a file called /etc/sysctl.d/01-disable-ipv6.conf
containing the line:
net.ipv6.conf.all.disable_ipv6 = 1
At the next restart or after execution of the
sysctl -p /etc/sysctl.d/01-disable-ipv6.conf
command, IPv6 is disabled. If you test the ports again with netstat
, you will notice that ssh will still respond to IPv6 requests. If you also want to deactivate this behavior, you need to enter the AddressFamily inet
value in the /etc/sshd_config
file. After restarting the SSH daemon, only the IPv4 port is now displayed. To test the system from the outside, use nmap
:
stefan@stefan-nb ~ % nmap 192.168.56.210 Nmap scan report for 192.168.56.210 Host is up (0.00056s latency). Not shown: 999 closed ports PORT STATE SERVICE 22/tcp open ssh
Here, too, port 22 is indicated as open. An additional firewall with iptables
would now round off the security concept for the file server, but I will set up the firewall at the very end of the article when I integrate the Samba service into the firewall.
Installing Samba Server
For this article, I use the Debian packages for Samba, which were available in version 4.5.8 at the time of testing. The samba package is responsible for the server service. Because the Samba server will be integrated into an AD later and the users from the AD will have to be "mapped" to the Samba server, I also install winbind. To test the releases locally, I need the smbclients package; thus, I will need the following packages: samba, winbind, smbclients, libpam-winbind, and libnss-winbind.
After the package installation, you should delete the provided /etc/samba/smb.conf
file. This configuration is not designed for use as a file server because:
- In the file, Samba is configured as a standalone system, but I want to set up a member server in an AD.
- The file contains shares that I will not be using.
- References are given to parameters that are outdated.
- The
smb.conf
file should not contain any comments. Each client that connects to the Samba server always starts its own server daemon (smbd
) process, so the entire file is always transferred to all connected clients whenever changes are made tosmb.conf
.
To later manage the Samba server completely from Windows, you want to transfer the configuration to the registry of the Samba server. Then, you can simply manage the server with Regedit, because the configuration is then in a tdb database.
With or Without NetBIOS
Windows supports two different protocols on a server: SMB and NetBIOS. NetBIOS is only used for name resolution. Without the NetBIOS protocol, the server is therefore not visible in the "network environment" of a client. However, because the names are resolved by DNS in AD, NetBIOS is no longer absolutely necessary. That said, any protocol that is present on a server and is not required is always a security issue. Therefore, I want to dispense with NetBIOS completely to remove the associated ports and traffic broadcast to the network.
Depending on your choice of distribution, different SMB versions are available. Starting with Samba v4.2, the highest version of the SMB protocol available is 3.0. On the Windows side, this version is available as of Windows 8. With the release of Samba 4.3, SMB v3.1.1 was introduced for use on Windows 10 and Windows Server 2016 or later. Besides online compression, the new v3.1.1 provides higher encryption of the transmitted data. If your network contains Windows 10 or Windows Server 2016, you should use at least Samba v4.3.
Configuration with smb.conf
The first step is to set up the file server in smb.conf
. In Listing 2, you see the basic configuration without shares. In this article, I will not be discussing the parameters for joining the domain and ID mapping, only the parameters that increase the security of the system:
Listing 2: smb.conf Basic Configuration
[global] workgroup = example realm = EXAMPLE.NET security = ADS winbind enum users = yes winbind enum groups = yes winbind use default domain = yes winbind refresh tickets = yes template shell = /bin/bash idmap config * : range = 10000 - 19999 idmap config EXAMPLE : backend = rid idmap config EXAMPLE : range = 1000000 - 1999999 inherit acls = yes store dos attributes = yes vfs objects = acl_xattr interfaces = 192.168.56.210 bind interfaces only = yes client ipc min protocol = smb2_10 client min protocol = smb2_10 disable netbios = yes
-
inherit acls = yes
: The assigned access control lists (ACLs) are inherited. This parameter can also be set in the release. -
store dos attributes = yes
: The extended attributes of a Windows system are also managed. You can also set this parameter in a share. -
vfs-objects = acl_xattr
: Ensures the Windows-compliant management of permissions in the filesystem. This parameter can also be set directly in the share. -
interfaces = 192.168.56.210
: Sets the IP address where the service will receive requests. You can enter either the IP address or the device name here. -
bind interfaces only = yes
: Enables the specification of an interface. If the system is configured with several IP addresses, Samba will bind only to these specific interfaces. -
client ipc min protocol = smb2_10
: IPC requests are only accepted by systems with at least Windows 7. -
client min protocol = smb2_10
: Connection requests are only answered by clients from Windows 7. -
disable netbios = yes
: NetBIOS is not supported. The server no longer appears in the network environment of the clients. However, connections can still be made.
After you have created the smb.conf
file, you must now ensure that the Samba server can also communicate with the domain's Kerberos server. Install the libpam-heimdal package. You can simply confirm the values that are requested during the installation of the packages with a Return. These values change the /etc/krb5.conf
file. In the next step, you want to create this file with the minimum parameters. After installing the package, create a new /etc/krb5.conf
with the following content:
[libdefaults] default_realm = EXAMPLE.NET dns_lookup_realm = false dns_lookup_kdc = true
After adding the DNS servers of the AD domain to the /etc/resolv.conf
file, you can then join the server to the domain:
root@fs01:~# net ads join -U administrator [...] root@fs01:~# net ads testjoin Join is OK
To test that all services start properly, even after a reboot, reboot the system. Now you have to adjust the /etc/nsswitch.conf
file:
passwd: compat winbind group: compat winbind
Next, test whether the new file server also responds to requests. For this, you use the smbclient
command on the server. The following shows a first attempt at connecting to the server:
root@fs01:~# smbclient -L fs01.example.net Enter root's password: protocol negotiation failed: NT_STATUS_INVALID_PARAMETER_MIX
What happened here? Because you have set the minimum protocol to version 2.1 in the smb.conf
file, smbclient
cannot connect. The connection only works if you use a protocol newer than 2.0 (see Listing 3). This example reveals that there is no master for NetBIOS in the domain – all domain controllers and the file server no longer use NetBIOS. What does the list of ports on the server look like now? To find out, use netstat
again (Listing 4).
Listing 3: Successful Connection
root@fs01:~# smbclient -L fs01.example.net -m SMB3 Enter root's password: Anonymous login successful Sharename Type Comment --------- ---- ------- IPC$ IPC IPC Service (Samba 4.5.8-Debian) Anonymous login successful Server Comment --------- ------- Workgroup Master --------- -------
Listing 4: List of Ports
root@fs01:~# netstat -tln Active Internet Connection (Only Server) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 192.168.56.210:445 0.0.0.0:* LISTEN tcp 0 0 192.168.56.210:139 0.0.0.0:* LISTEN
Two ports have been added. One is TCP port 445, which is the port for the SMB connections, and the other is TCP port 139, which provides SMB connections via NetBIOS. However, because NetBIOS has been disabled on the server, you can also disable this port. To do so, add the smb ports = 445
line to smb.conf
in the global area and restart the service. A new test with netstat
then only shows port 445 as open. Testing from the outside with nmap
also shows only two open ports. Running smbclient
will only output an error message that it always connects via NetBIOS.
The First Share
Now comes the point that makes the server usable in the first place: setting up the first share. Here, you want create an administrative Windows share to which only the Domain Admins group has write access, similar to drive shares under Windows. The directories are then made available to the users in this share. You can then assign the directories created there to users in individual shares with group policy objects (GPOs).
The advantage of this approach is that you can assign all permissions directly under Windows and thus have a uniform permissions structure on all servers, whether Windows or Samba servers. The following snippet shows the share from smb.conf
:
[admin] path = /data browsable = no read only = no
As you can see, no parameters for access rights are entered here. All authorizations are assigned from Windows. Now you want to test whether it is possible to create a connection to the share. To do this, log on to a Windows client in the domain and create a network connection (Figure 1).

To be able to create an authorization structure and a new share, you now create the Departments folder under Windows with a Production sub-folder and assign all rights for the domain admins to the Departments folder. On the system are the Production and Administration groups (Figure 2); the directories are now assigned to these groups accordingly.

If you now try to access one of the folders as a domain administrator, you will only see an error message stating that you do not have the required rights. The behavior at this point is therefore identical to that on a Windows server. The rights of the two directories on the file server are shown in Listing 5.
Listing 5: Directory Rights
root@fs01:~# ls -l /data/Departments/ in total 16 drwxrwx---+ 2 administrator domain users 4096 Jun 7 19:14 Production drwxrwx---+ 2 administrator domain users 4096 Jun 7 19:14 Administration
You can see by the +
at the end of the authorizations list that the POSIX ACLs are also set in addition to the filesystem rights. Listing 6 shows the ACLs of the Production folder and the complexity of the authorization assignment. For this reason, you should always assign authorizations from Windows (Figure 3).
Listing 6: Production Folder ACLs
root@fs01:~# getfacl /data/Departments/Production/ getfacl: Remove leading '/' from absolute path names # file: data/Departments/Production/ # owner: administrator # group: domain\040users user::rwx user:administrator:rwx user:production:rwx group::--- group:domain\040users:--- group:production:rwx mask::rwx other::--- default:user::rwx default:user:administrator:rwx default:user:production:rwx default:group::--- default:group:domain\040users:--- [...]

For users to access their department's folder, you need to set up the appropriate share. It makes sense for only the members of a department to be able see the corresponding department directory; then, you have the option of providing a share to all departments. An employee who changes departments would immediately only have the rights for their new department and would only see the corresponding directory. The following listing shows the entry in smb.conf
for the share:
[Departments] path = /data/Departments browseable = No hide unreadable = Yes read only = No
The browseable = no
parameter means that this share is a hidden share, just like a $
share under Windows. The hide unreadable = yes
parameter ensures that you only see entries for which you have at least read access. Because all employees only have rights to their department's directory, they only see that departmental directory.
Unfortunately, this parameter also has its pitfalls, because the more subdirectories and files you have in the Departments folder, the longer access can take, because the system first needs to check the access rights in all subdirectories. Therefore, test the parameter in detail in your environment before using it.
Converting to the Registry
To manage the system in the registry, and thus also in the Windows registry editor, the conversion from smb.conf
to the registry now follows. The first step is to import the file into the tdb database with the
net conf import /etc/samba/smb.conf
command. The net conf list
command reveals the content of the registry. Now save smb.conf
under a different name and create a new smb.conf
file with the following content:
[global] config backend = registry
After restarting smbd
, you can read the configuration with testparm
. You will see that the registry is now used for configuration. If you start Regedit on a Windows client as a domain administrator, you can connect to the registry of the file server, read and change the settings, create new keys for a new release, or create new values within the existing keys.
Firewall, Please
Now all you need is to set up the firewall with iptables. Of course, many settings can be made to secure a system, but Listing 7 provides a small script that shows you how to unlock the required ports for Samba and SSH and how to prohibit all other connections.
Listing 7: iptables Firewall
#!/bin/bash IPT=iptables $IPT -F $IPT -P INPUT DROP $IPT -P FORWARD DROP $IPT -P OUTPUT ACCEPT # Allow loopback $IPT -A INPUT -i lo -j ACCEPT $IPT -A OUTPUT -o lo -j ACCEPT # Allow three-way handshake $IPT -A INPUT -m state --state NEW -j ACCEPT $IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Allow input ssh $IPT -A INPUT -p tcp --dport 22 -j ACCEPT # Allow smb over Port 445 \$IPT -A INPUT -p tcp --dport 445 -j ACCEPT
After you have started the firewall, Windows access remains possible. You should further configure the firewall to detect port scanning and brute force attacks and document any attempts in the logfiles.
Conclusions
Securely integrating a Samba server into a heterogeneous environment is not rocket science. In contrast to a Windows-flavored server, you have to deal with the security of the operating system and the Samba service manually: Just installing the packages and then setting up a few shares is not enough. However, with a few simple steps, you can securely integrate a Samba server into your AD domain, with the well-known samba.conf
configuration file playing a central role.