LarsBlog

I recently tried to secure (ie transport encryption) access to my local Samba server running on a Debian box running Samba 4.2.  By default all Samba traffic outside password exchanges is unencrypted, meaning file contents and directory listings can be 'sniffed' over the network.

Getting this working end-to-end involved a little more trial-and-error than I would have hoped.

Enabling encryption on the Samba server seems easy enough by editing /etc/samba/smb.conf and adding:

[global]
server max protocol = SMB3 #Want to ensure Win8.1+ compatible encryption is enabled (now default)
smb encrypt = required     #Force encryption on 
lanman auth = no           #Disable old insecure authentication (now default)

However I immediately started getting cryptic errors from my Linux-based clients like Kodi and Nautilus File Manager, along the lines of "File exists".  Very helpful.

It turns out clients like nautilus typically use libsmbclient to connect to SMB shares.  With some trial and error testing, I was able to successfully connect to my share using smbclient with *either* the '-e' or '-m SMB3' parameters:

smbclient -e -m SMB3 //<hostname_or_ip>/<share_name> -U <username>

The '-e' tells the smbclient to attempt an encrypted connection, however Nautilus would still fail.  It turns out I need to edit the smb.conf on the Linux client machines in order to make these settings the default:

[global]
smb encrypt = required
client min protocol = SMB2 #Tried SMB3 here, but caused errors connecting
client max protocol = SMB3

This change to the default smbclient behaviour appeared to take effect as soon as smb.conf was saved.  (It's worth noting that some linux machines have an smb.conf file under the <user_home>/.smb/ directory, and this may need to be edited too.)

I tested one of my Windows 10 devices and it could connect without issue.  (Why Windows 10 can connect without issue when encryption is on, but linux/samba clients need trial-and-error configuration changes is beyond me.)

The final step was to fire up wireshark and confirm that I was indeed now getting encrypted SMB.  I could see that prior to these changes, plaintext details of files were visible in the packet stream and after the changes these details were encrypted:

I noted my username was still transferred in plaintext.  Figuring out whether I can prevent that is a job for another day.