Microsoft Windows edges closer to SMB security signing fully required by default Microsoft is getting closer to requiring cryptographic signing of SMB traffic by default for all connections on Windows 11 at least. By that, the software giant means all SMB messages over the network will be digitally signed so that any tampering can be automatically detected, and senders and receivers can verify who they're …
Yep, and all the NAS stuff based on it out there like QNAP Synology etc. Scanners with network file drop etc ... lots of stuff.
I can only assume that it will still be possible to configure fallback eg down to SMB2, 3.02 and it's only the default that's changing.
At least I *really* hope so !
Based on past experience with NAS over SMB, for those of us running Macs this could have one of three outcomes.
1. Apple will implement the new protocol so it meets the intent of the specs and everything in the garden will be rosy
2. Apple will implement the new protocol tweaked slightly so that it meets Apple's view of what secure SMB would do if they'd designed it in the first place - and nothing will work quite properly again without a suite of terminal commands.
2. Apple will decide it's going to wait a couple of years before it gets round to updating and my NAS drives, scanner and backups will be a pain in the arse until they do.
This post has been deleted by its author
Ehm, well things may and probably go pear shaped quickly and often given M$ft's way of handling certificates, especially their own certificates. I've lost count of the number of times I've found expired certificates in fully patched, supported and licensed applications.
But hey, things could actually work for most of the time and most users. What could possibly go wrong?
This post has been deleted by its author
Thus following the general rule that you don't attack the encryption but rather the key exchange.
Personally, I wonder how this will impact the NAS disk that holds my music files. I don't really need to encrypt/sign/countersign/whatever anything because its a closed system; an outside might get access somehow and access the (read only) files but they won't do any harm. (Based on past form stuff will just stop working and I'll have to waste a bunch of time figuring out why and dealing with it.)
SAMBA file transfer performance on low powered ARM devices is going to end up in the toilet once server signing is required - not so easy to add another core, or replace with a more powerful CPU.
I can see this being disabled by users on the Microsoft end. Hopefully it can be disabled on a per-share basis.
I can see lots of LANs with Samba traffic happily flying between Arm devices, NAS boxes, DVRs, media players etc - and the poor old Windows 11 laptop suddenly being shut out of the game.
Maybe Windows can have the requirement disabled, but by the poor sod who just updated and wants his photos "back"?
It's not that.
I get very annoyed because what usually happens is the following:
1) Everything is working
2) Suddenly, several things stop working
3) Microsoft (or local IT) insist nothing has changed
4) I waste a day proving that something has changed
5) Microsoft (or local IT) admit that they did change something "to improve security".
6) I ask how to properly reconfigure so the things work.
7) Silence
8) More silence...
9) Several weeks later, I find some blog posts from some rando on the Internet explaining how to configure so things mostly work. I have no idea whether what they suggest is defeating the supposed security improvement (eg "enable SMB1) or is the right way to use it.
The problem isn't security, it's that these changes are almost always unannounced, always break things, and there is almost never any support for actually using them properly.
It usually is announced, just not shouted from the rooftops.
By definition improving security will break things if there are devices that only support down level insecure protocols.
As to 'never any support for actually using them properly' it's called 'reconfigure/firmware upgrade your old device' (not Microsoft's job), or more probably 'buy something newer'. Blame your manufacturer, not Microsoft.
Just as TLS1.0 has largely gone away, at some point you need to move on, and as someone mentioned about low powered ARM boxes (and certainly with old TLS boxes too) the only recourse is a hardware upgrade.
The issue is that people 'want' security, and they also don't want to pay anything, or expend any effort to do so.
> low powered ARM boxes (and certainly with old TLS boxes too) the only recourse is a hardware upgrade.
Except in the situation that the Arm boxes are still running a level of security that is sufficient for their use-case (e.g. on a LAN that is itself sufficiently disconnected from anything outside) so upgrading that hardware is a needless expense. But if you can't (easily, nay trivially) connect your Windows laptop to all the devices on that LAN then - angry faces all around.
I have SMB1 re-enabled on a Windows 10 box connected to a cabled LAN; if anyone is on that LAN then I've got worse issues than worrying about that particular Samba traffic. If -when - Windows plain stops allowing SMB1 then will I chuck all the perfectly working devices on that LAN? Or is it cheaper & simpler to stop using Windows with that LAN? (Hint: the answers are "No" and "Yes" respectively).
> The issue is that people 'want' security
People want security that matches their requirements. For Joe Bloggs or anyone who doesn't "want" to think about it (or, more likely, simply isn't knowledgeable about it and isn't in the job of becoming so) they want the *defaults* to be as good as possible. For many readers here, we want to use *appropriate* settings (and know it is on our heads if we choose badly) - and do so in a *supported* fashion, not from random web trawls.
> and they also don't want to pay anything
We don't want to pay for what we don't actually need
> or expend any effort to do
Joe Bloggs ought not need to expend any energy, he gets the defaults. For us here, following supported methods is fine, that is an appropriate amount of effort.
Reverse engineering Registry settings to disable excessive protocols, or even just trawling the web praying someone else has succeeded in doing so, is not something we want to do (or ought to have to be forced to consider doing).
"6) I ask how to properly reconfigure so the things work.
Generally it will have something to do with printing... on the day you REALLY need it!
Windows 7 works with my printer. All Linux and FreeBSD boxen on my network work with my printer.
But a Win-10-nic VM (that I had to use to run tax software this year) does NOT. It will not scan from it either (it's an all-in-one fax/scan/print unit).
So I printed 'required forms' to PDF and used Atril (on FreeBSD) to make the hard copies. For scanned stuff I made the jpeg file on FreeBSD and copied to the Win-10-nic box and then opened it within the tax software (something you print, sign, and scan for filing basically).
Micros~1 does not seem to care much about printers. Nor scanners. Not any more. If yours is "too old", even if it works perfectly, a broken driver may be in your "update future" because "something changed" instead of being properly fixed.
You seem to assume that Microsoft knows what security actually is other than a means to lock people out.
Given that their products forms the one common thread between every single successful ransomware attack out there I'd venture that this move too is more likely to have its origin in some anti-competitive strategy rather than to protect their victims customers.
This is actually improving security.
Getting windows boxes to dump all its creds with SMB signing not enforced is a relatively simple MITM attack that is used to laterally move in an environment by crims.
This doesn't use certificates. And as for the overhead, couldn't quantify it for you, but I know we didn't notice it when we enabled it.
SMB signing was a feature of SMB1.
There may well be printers out there that can't do SMB signing, but I'd of thought that any printer that *required* SMB would also *support* SMB. I mean, it's just a policy setting -- would you expect that there was never anybody before that set the domain policy to 'required'?
However, our old HP network printers used PCL over TCP/IP, not SMB, so I've not a lot of experience with SMB1 printers.
Can this be enabled in Win7? Asking for a friend with his old Win7 box he hasn't upgraded as it works as a file share box.
I guess this will appear in the various Raspberry PI's - just burn more electricity when moving things around a home network where no one is hacking anything...
Can already see the complaints on the Unraid forum... hard enough trying to explain to them why Network Neighbourhood doesn't work and stop trying to do Samba with no username and password....
Yes - Windows 7 supports SMB Signing - Enforced. The policy is called "Microsoft network client/server: Digitally sign communications (always)" in secpol.msc. (There's one policy for Microsoft Network Server and another for Microsoft Network Client.)
Signing has been available since Server 2000, FYI.
Windows security always seems to assume a domain controller, yet in most small LANs there isn't one and never will be.
There are also a lot of closed LANs with no (intentional) access to the Internet, that are updated via sneakernet and also occasionally visited by "normal" laptops.
Presumably the machines can all be coaxed into creating self-signed certificates for either a fixed IP or mDNS name, but how do I convince Windows to store that the first time it connects?
Or is this simply transport and no identity verification needs to take place?
In my org they've moved all the network shares from on-prem servers to Azure, meaning that file transfers take at least 20 times longer than they used to, even though we have a massively fat WAN pipe. It's much worse for apps that read/write relatively small records. I imagine that many other orgs have done similarly, so it's possible that almost no one with notice any further degradation.
-A.
A drawback experienced by every small business that moved to Win2003 server, where the signing requirement was the default for domain members connecting to the AD/file server.
I can think of other reasons why connecting to Azure might be slow -- I would expect that it is using an encrypted connection
This feels like it is just ensuring that the data in transit is secure. Much like HTTPS.
This doesn't help to secure the end points, either or both of which can be compromised. Malware can still take over a client system, but the network communications it employs to communicate with other systems will be encrypted.
Not that adding security to such a thing isn't a good idea, but being realistic about what it will achieve and the scope of improvement is important. Much like a firewall, most of the vulnerabilities are at the end points and not the firewall itself through which holes have been intentionally made. In this case it's data transit encryption which helps to prevent network packet snooping related attacks - which is all HTTPS does.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
