Hi all, A - I thought badlock mitigation was about encrypting SMB traffic, at least most part of it. And this encryption of most part of data transfer could (or should) lower performances. It seems I was wrong: smallest part (something like commands) are encrypted but not SMB traffic (ie file transfer). This for SMB protocol prior to SMB3 (which comes with windows 8). B - According to what I read, new options added into smb.conf with Samba versions meant to solve Badlock issue are enough by default to solve the issue. Is that true?
On Fri, Jun 03, 2016 at 02:23:23PM +0200, mathias dufresne wrote:> Hi all, > > A - I thought badlock mitigation was about encrypting SMB traffic, at least > most part of it. And this encryption of most part of data transfer could > (or should) lower performances.Well it's traffic signing, not encryption. The problem is traffic signing prevents some of the zero-copy optimizations (sendfile/recvfile) that are otherwise possible.> It seems I was wrong: smallest part (something like commands) are encrypted > but not SMB traffic (ie file transfer). This for SMB protocol prior to SMB3 > (which comes with windows 8). > > B - According to what I read, new options added into smb.conf with Samba > versions meant to solve Badlock issue are enough by default to solve the > issue. > > Is that true?Well the options come with the complete patch, so you can't separate the two.
>> A - I thought badlock mitigation was about encrypting SMB traffic, at least most part of it. >> And this encryption of most part of data transfer could (or should) lower performances.>> It seems I was wrong: smallest part (something like commands) are encrypted but not SMB traffic (ie file transfer). >> This for SMB protocol prior to SMB3 (which comes with windows 8).>> B - According to what I read, new options added into smb.conf with Samba versions meant to solve Badlock >> issue are enough by default to solve the issue.If I understood you correctly, your questions are answered here: https://www.samba.org/samba/latest_news.html "It is recommended that administrators set these additional options, if compatible with their network environment: server signing = mandatory ntlm auth = no Without "server signing = mandatory", man in the Middle attacks are still possible against our file server and classic/NT4-like/Samba3 Domain controller. (It is now enforced on Samba's AD DC.) Note that this has heavy impact on the file server performance, so you need to decide between performance and security. (...)" And here: https://www.samba.org/samba/history/samba-4.4.2.html "CVE-2016-2114 Due to a regression introduced in Samba 4.0.0, an explicit "server signing = mandatory" in the [global] section of the smb.conf was not enforced for clients using the SMB1 protocol. As a result it does not enforce smb signing and allows man in the middle attacks. This problem applies to all possible server roles: standalone server, member server, classic primary domain controller, classic backup domain controller and active directory domain controller. (...) Note that the default for server roles other than active directory domain controller, is "off" because of performance reasons." Please note this last paragraph: the default for "server signing" is "off" for server roles other than active directory domain controller, for performance reasons. If the AD DC is also operating as a file server, you will see a significant impact on file transfer speed. I was bitten by this issue after updating to Samba 4.4.2 to address the Badlock problem: I had a machine serving both roles and the sequential transfer rates to/from Windows 7 clients dropped from more than 100MB/s to just above 60MB/s maximum. I had to separate the roles and offload the AD DC function to another server because of this.
Thank you both for these replies, it's a bit clearer in my mind : ) 2016-06-03 18:52 GMT+02:00 Miguel Medalha <medalist at sapo.pt>:> > >> A - I thought badlock mitigation was about encrypting SMB traffic, at > least most part of it. > >> And this encryption of most part of data transfer could (or should) > lower performances. > > >> It seems I was wrong: smallest part (something like commands) are > encrypted but not SMB traffic (ie file transfer). > >> This for SMB protocol prior to SMB3 (which comes with windows 8). > > >> B - According to what I read, new options added into smb.conf with > Samba versions meant to solve Badlock > >> issue are enough by default to solve the issue. > > > If I understood you correctly, your questions are answered here: > > https://www.samba.org/samba/latest_news.html > > "It is recommended that administrators set these additional options, if > compatible with their network environment: > > server signing = mandatory > ntlm auth = no > > Without "server signing = mandatory", man in the Middle attacks are still > possible against our file server and classic/NT4-like/Samba3 Domain > controller. (It is now enforced on Samba's AD DC.) Note that this has heavy > impact on the file server performance, so you need to decide between > performance and security. (...)" > > > And here: > > https://www.samba.org/samba/history/samba-4.4.2.html > > "CVE-2016-2114 > > Due to a regression introduced in Samba 4.0.0, > an explicit "server signing = mandatory" in the [global] section > of the smb.conf was not enforced for clients using the SMB1 protocol. > > As a result it does not enforce smb signing and allows man in the > middle attacks. > > This problem applies to all possible server roles: > standalone server, member server, classic primary domain controller, > classic backup domain controller and active directory domain controller. > > (...) > > Note that the default for server roles other than active directory > domain > controller, is "off" because of performance reasons." > > > Please note this last paragraph: the default for "server signing" is "off" > for server roles other than active directory domain controller, for > performance reasons. > > If the AD DC is also operating as a file server, you will see a > significant impact on file transfer speed. I was bitten by this issue after > updating to Samba 4.4.2 to address the Badlock problem: I had a machine > serving both roles and the sequential transfer rates to/from Windows 7 > clients dropped from more than 100MB/s to just above 60MB/s maximum. I had > to separate the roles and offload the AD DC function to another server > because of this. > > >