Can FreeNAS CIFS traffic be forced to encrypt?

[Steve Lumponalog]

I'm running FreeNAS 9.3 stable, with CIFS shares to Windows, Mac, and Linux systems. Looking at the SMB traffic in Wireshark, I see that all traffic -- except for the share password -- is sent in plain text: authentication username, domain, directory listings, and file contents.

This isn't really a big deal for me, as my WiFi is encrypted, and my network uses smart switches. To be compromised, I'd probably need to have a process with elevated privileges running on a machines reading a sensitive file over SMB. Unlikely, but not impossible, so it nags at me because I know that Microsoft added AES transport encryption in CIFS 3, as detailed on this page under the heading "SMB encryption in Windows 8 and Server 2012". Extract:

SMB 3.0 in Windows 8 and Server 2012 has the ability to encrypt the SMB data while it’s in transit, at a much lower cost than deploying other in-transit encryption solutions such as IPsec. Encryption in transit protects the communications from eavesdropping if intercepted as it passes through the network.

You can enable SMB encryption for specific shares in Server 2012 via the File and Storage Services in Server Manager. You can do it when you create a new file share via the New Share Wizard, as shown in Figure 4.​

Is the ability to encrypt SMB traffic in transit unique to Windows, or can it be done by FreeNAS too?

Stack Overflow suggests that adding server signing = mandatory to smb.conf might force SMB transport to be encrypted, though doing that on the client (Fedora 21) didn't make any difference for me. It it possible and advisable to try adding that to smb.conf (or its equivalent) on FreeNAS?

Another suggestion says that adding -e or --encrypt to the smbclient options should force clients to use encryption. It does work, but I don't really want to use smbclient -- it's an FTP-like command-line utility, and I'd like to mount shares on my desktop using box-standard Finder, File Explorer, or Thundar, and feel easy that the transport is being encrypted.

I've got a kick-ass Xeon in my FreeNAS box with plenty of cycles to spare. Is there any way to get FreeNAS to force encrypted SMB on all its clients, or should I start looking at alternatives like sshfs?

 

[anodos]

CIFS / SMB traffic should not be traversing untrusted networks (unlike FTP). I think you are just making more work for yourself.

If needed you can set "smb encrypt = yes" on a per-share basis via auxiliary parameters. You will see a performance hit since AES-NI isn't supported.

 

[cyberjock]

AFAIK there is no way to ensure you aren't being hit with a mitm attack with this method either.

I'm with anodos on this. If you aren't doing this over paths that you already trust or already are encrypted, I think you are making a terrible mistake with regards to security of your network, your server, and your data.

 

[Ajedi32]

So what's the point of CIFS encryption then? Microsoft claims it's specifically designed to be used with untrusted networks. See https://technet.microsoft.com/en-us/library/dn551363(v=ws.11).aspx

> SMB Encryption offers an end-to-end privacy and integrity assurance between the file server and the client, regardless of the networks traversed, such as wide area network (WAN) connections that are maintained by non-Microsoft providers.​

 

[anodos]

So what's the point of CIFS encryption then? Microsoft claims it's specifically designed to be used with untrusted networks. See https://technet.microsoft.com/en-us/library/dn551363(v=ws.11).aspx

> SMB Encryption offers an end-to-end privacy and integrity assurance between the file server and the client, regardless of the networks traversed, such as wide area network (WAN) connections that are maintained by non-Microsoft providers.​

Technically, that's SMB3 encryption. Not CIFS. That said, the quote you provided explains the use-case -- WAN connections. Encryption isn't a security panacea. If an attacker has managed to penetrate your local network enough to be able to MITM SMB traffic between your server and clients on your LAN, then you have much bigger fish to fry. For almost all users (especially home users), it makes sense NOT to encrypt transport.

Samba has supported encrypted transport between Samba servers for years through Unix extensions. It is controlled by the parameter "smb encrypt". The same parameter controls SMB3 encryption as well (which is a different sort of thing).

This parameter can be set globally and on a per-share basis. Possible values are:

• off (same as 'disabled'
• disabled (same as 'off')
• enabled (same as 'auto' or 'if required'. Puts the onus on the client to request an encrypted session)
• auto (same as 'enabled or 'if required')
• if required (same as 'auto' and 'enabled')
• desired (setting it will enable negotiation and turn on data encryption on sessions and share connections for clients that support it)
• required (same as mandatory).
• mandatory (same as required)
• default (implicit default setting of 'enabled')

The default setting on the version of samba shipped with FreeNAS 9.10.1 is "smb encrypt = default". Note the following:
1) Encryption is either Samba to Samba or SMB3
2) No encrypted transport for Win7, Vista, Server 2008, Server 2008R2.
3) There will be overhead if your encrypt transport.