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.

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 to smb.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:

[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).

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
   ---------        -------

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.

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).

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.

#!/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.