This is a bit of a longer narrative involving Samba serving files to Windows clients.
Once upon a time in the homelab I setup a samba server. Files went in; files went out and everybody was wired up at 1gbps or hanging off wifi. Life was good. In the fullness of time various clients were used to test new and exciting features or configurations; security and performance impacts were explored. One day on this grand adventure I enabled [Microsoft network client: Digitally sign communications (always)] on my main workstation, things continued to be performant at 1gbps but now they were "Secure" and performant!
Fast forward several years and the same workstation is still in use though the samba server has rolled over once or twice. Spring of 2020 a great upgrade to the network stack occurs and all the wired bits are now connected at 10gbps! Performance testing between my workstation and the Samba shares resulted in disappointment. Despite this new robust network infrastructure transfer speeds were just "ok"; the server hardware involved can saturate at 10gbps link but my old primary workstation seemed to top out around 3gbps. Skip forward another year and I'm stepping through the output of Get-SmbClientConfiguration idly trying to determine why this workstation doesn't perform as expected and I discover the left over detritus from my earlier experimentation RequireSecuritySignature is set to true on this one machine.
Resetting the signing requirement to False now has the workstation maxing out the link speed! This leads me back to my old research and notes; signing is meant to prevent session hijacking, how can I ensure performance and security? Legacy SMB2 signing relies on HMAC-SHA256 while SMB3 introduced full encryption with AES-CMAC/AES-CCM; a far more performant option that now provides confidentiality in addition to authenticity. Setting smb encrypt = mandatory ensured all clients connecting to the server now use encryption. In testing this configuration clients are now hitting between 9gbps and 10gbps without issue while maintaining the integrity of the session.
For those who have interest in SMB security Microsoft has published some nice documentation here.
For those who have tested SMB encryption on Samba in the past and found it to be slow (I did in the past) Samba 4.12 removed their in-tree crypto in favor of using the GnuTLS library which significantly improved performance (~3x bump in their internal testing) see release notes.
Once upon a time in the homelab I setup a samba server. Files went in; files went out and everybody was wired up at 1gbps or hanging off wifi. Life was good. In the fullness of time various clients were used to test new and exciting features or configurations; security and performance impacts were explored. One day on this grand adventure I enabled [Microsoft network client: Digitally sign communications (always)] on my main workstation, things continued to be performant at 1gbps but now they were "Secure" and performant!
Fast forward several years and the same workstation is still in use though the samba server has rolled over once or twice. Spring of 2020 a great upgrade to the network stack occurs and all the wired bits are now connected at 10gbps! Performance testing between my workstation and the Samba shares resulted in disappointment. Despite this new robust network infrastructure transfer speeds were just "ok"; the server hardware involved can saturate at 10gbps link but my old primary workstation seemed to top out around 3gbps. Skip forward another year and I'm stepping through the output of Get-SmbClientConfiguration idly trying to determine why this workstation doesn't perform as expected and I discover the left over detritus from my earlier experimentation RequireSecuritySignature is set to true on this one machine.
Resetting the signing requirement to False now has the workstation maxing out the link speed! This leads me back to my old research and notes; signing is meant to prevent session hijacking, how can I ensure performance and security? Legacy SMB2 signing relies on HMAC-SHA256 while SMB3 introduced full encryption with AES-CMAC/AES-CCM; a far more performant option that now provides confidentiality in addition to authenticity. Setting smb encrypt = mandatory ensured all clients connecting to the server now use encryption. In testing this configuration clients are now hitting between 9gbps and 10gbps without issue while maintaining the integrity of the session.
For those who have interest in SMB security Microsoft has published some nice documentation here.
For those who have tested SMB encryption on Samba in the past and found it to be slow (I did in the past) Samba 4.12 removed their in-tree crypto in favor of using the GnuTLS library which significantly improved performance (~3x bump in their internal testing) see release notes.
