A brief post about enabling Samba file share encryption on your TrueNAS CORE-based file server.
I’m running a TrueNAS-based file server (version 12) for the purpose of data safekeeping, and only recently did I decide to look into whether the system is, by default, encrypting data sent and received via Samba file shares. I had a suspicion that encryption of SMB connections wasn’t enabled by default. Investigation time! 💻🔍👀
The first thing I did when looking into this was to run a packet capture on the machine accessing SMB shares hosted on my file server. In brief, I found that—indeed—TrueNAS was not sending (or accepting) encrypted file data. By means of scrutinizing the data captured by Wireshark on the client machine (running Windows 10 version 20H2), I found that I was able to see plaintext SMB packets to and from the file server. NOTE: I would typically post a screenshot of my findings for this sort of thing but, since some of the data I was previewing is sensitive, I’ve decided to forego redaction and review of it in this case. I’m sorry for not providing an example of what to look for in this part.
An additional diagnostic step that I took was to see what the Samba server running on the TrueNAS machine was seeing for client connections. Running the smbstatus command on the file server resulted in the following:
I was also curious to see what particular Samba client version that my machine was using for these connections. I found a quick PowerShell applet, Get-SMBconnection, which gives you a summary of open SMB connections made from the computer:
This PowerShell applet shows the active SMB connections in use on the machine: the server and share name, the user name and credential used for the connection, the version of the Samba client in use for the given share (listed in the “dialect” column), and the number of file transfers conducted for said file share.
With the Samba client version now known (in this case, version 3.1.1), I briefly researched Microsoft’s documentation repository to see if I could find a quick answer about what sort of encryption options are supported by the Samba client on my Windows 10 machine. A page from the Windows Server knowledge base turned up which discusses encryption with Windows Server-based SMB shares. Of note, however, was the upcoming support for AES 256-based encryption in Windows Server 2022 and Windows 11, but also a note that there’s existing support for AES-128 for SMB-based file shares. I felt it was safe to presume that this meant Windows 10 supported AES-128 for SMB connections. While this page did discuss what sort of SMB encryption was supported at the time, it’s targeted more to configuration of file shares on Windows Server. Let’s move on.
At this point, I decided to go directly to the Samba settings within TrueNAS to see what, if any, sort of fine-grained settings might be available. (click on Services on the panel’s left-side menu, then on the next page click the pencil icon to the right of the SMB item; click the Advanced Options button on the bottom of the SMB settings page to access the Auxiliary Parameters field)
While I didn’t immediately find a particular setting for SMB file encryption, I did notice the Auxiliary Parameters field on the bottom of the advanced settings section, leading me to believe that I could input custom Samba server parameters from the web interface. A quick glance at the TrueNAS CORE documentation page for SMB shares confirmed my suspicions: the Auxiliary Parameters field is exactly for that!
Conveniently linked from the TrueNAS’ documentation, the Samba documentation page for the smb.conf configuration file discusses the encryption parameters available for Samba file sharing services. In particular, let’s take a look at the smb encrypt parameter.
I won’t duplicate the documentation page’s verbiage here, but the parameter prescribed in the smb encrypt section is smb encrypt = <setting>. The options available are:
- default or enabled
- desired
- required
- off
The documentation for smb encrypt also states that these encryption parameters can be set globally (as in, for all shares handled by the SMB service) or per-share. In my case, I’m looking for to require encryption on some particular shares, and to enable “opportunistic” encryption for other shares where it would be nice to have, but not necessary.
A reboot of the server later (just to make sure I cleared out any weird bugs that may have occurred while testing my settings), I re-opened my SMB shares to establish connections—and it worked!
And, just to independently confirm, I started up Wireshark again to see what I could find:
A note about understanding risk
Considering the sensitivity of the data and the fact that the Samba traffic is being transmitted on a trusted internal network, I don’t feel that the use of SMB encryption is bolstering my security posture by a significant amount. I do believe it’s wise, though, to implement security in depth—it’s just one more thing that will frustrate an adversary when they find their way into said network. And the extra “peace of mind” is always nice to have.