Got told off the other day by IT, had uninstalled anti-virus to upgrade to 1803^H4^H5.
They asked me to reinstall asap, but I could not reach file server, since I had disabled SMBv1 forcefully... and it was running the obsolete protocol...
The Windows 10 April 2018 Update has been out for over a month now, and the rumbling of user dissatisfaction continues. This time it's networking problems for users still clinging to the venerable SMB1 protocol. Users have taken to support forums, including Microsoft's own, complaining that the latest version of Windows 10 is …
You might need to have a word with the head of your IT dept. as if a file server is being used in a work environment that doesn't support at least SMBv2 then something needs to change ASAP
Even if you disable SMBv1 on Windows 10, it will either use SMBv2 or if possible then SMBv3
"You might need to have a word with the head of your IT dept. as if a file server is being used in a work environment that doesn't support at least SMBv2 then something needs to change ASAP"
Probably including users being able to uninstall their own antivirus if they feel like it, too.
"Even if you disable SMBv1 on Windows 10, it will either use SMBv2 or if possible then SMBv3"
As Microsoft note on one of their support pages, disabling a particular version of SMB in an environment with mixed versions of Windows is a right kerfuffle -- and this really is the URL:
Replacing old NAS devices sounds like a good idea most of the time.
I recall working with a £x00,000 NAS device which had been written according to the CIFS/SMB standards of the time. We were dumping files generated on Windows XP systems for an OS upgrade. The official spec for SMB 2.0 -- as interpreted by the NAS vendor -- was that some extended file attributes were optional, so the vendor did not support them for SMB 2.0 file transfers. If a file with certain extended attributes was transferred to the NAS from a Windows 2008 R2 server, the file was rejected. However the file was deemed valid when transferred by SMB 1.0.
The NAS vendor suggested a very long timescale for a fix. So we turned off SMB 2.x on the intermediary Windows servers and progressed at a s-l-o-w-e-r pace.
No doubt that bug/misunderstanding is fixed, but there'll be different bugs or the need to go back in time which require SMB 1.0.
Depending on how pissed off you are, you might want to argue that the device is not fit for purpose. MS have spent about half a decade pleading with everyone to stop using it ASAP. There's no way this device is fit for purpose even now, let alone for however many years a consumer product is supposed to receive support. (Looks like 6 in the UK: https://www.which.co.uk/consumer-rights/advice/what-do-i-do-if-i-have-a-faulty-product)
Failing that, name the vendor here and we can all tell as many of our friends as possible to steer clear of the brand forever.
D-Link is one, I own their DNS-323. I am avoiding D-Link from now onwards.
That's Gemini which is actually nice hardware, but the software originally skirted GPL by not releasing working kernel sources for it. The original software was actually Debian based by the way. There was a ghastly "original kernel grafted onto a generic Debian distro" load for it a while back, but that died due to lack of maintenance.
That has now been fixed, so after a very long hiatus it should work with the latest kernels. I believe 4.17 works out of the box, there are backport patches for openwrt and Debian. As a result there will be firmware for it in the next releases (finally). I am waiting for the next LEDE release to pull mine out of the dusty drawer and put it to use - the hardware in it is actually quite good.
And whilst I'm thinking about this, if Ned Pyle really wants to see the end of SMB1 he should push for MS and people like CERT to issue official statements that any device that defaults to SMB1 is, their considered expert view, not safe to connect to a network in 2018 and therefore not fit for purpose. *That*, from them, would greatly assist anyone who wants to pick a fight with vendors on this point. They could go to their Trading Standards people and say "Expert opinion is on my side here.".
"And whilst I'm thinking about this, if Ned Pyle really wants to see the end of SMB1 he should push for MS and people like CERT to issue official statements that any device that defaults to SMB1 is, their considered expert view, not safe to connect to a network in 2018 and therefore not fit for purpose."
Think more or less everyone now has issued such statements. Repeatedly. For most of the last 5 years.
"he should push for MS and people like CERT to issue official statements that any device that defaults to SMB1 is [...] not safe to connect to a network"
If you read Ned's blog, who works for MSFT, he just about says that:
"Hi folks, Ned here again and today’s topic is short and sweet:
Stop using SMB1. Stop using SMB1. STOP USING SMB1!
In September of 2016, MS16-114, a security update that prevents denial of service and remote code execution. If you need this security patch, you already have a much bigger problem: you are still running SMB1.
The original SMB1 protocol is nearly 30 years old, and like much of the software made in the 80’s, it was designed for a world that no longer exists. A world without malicious actors, without vast sets of important data, without near-universal computer usage. Frankly, its naivete is staggering when viewed though modern eyes. I blame the West Coast hippy lifestyle :).
If you don’t care about the why and just want to get to the how, I recommend you review:
How to remove SMB1
The SMB1 clearinghouse
SMB1 is being removed from Windows and Windows Server
Otherwise, let me explain why this protocol needs to hit the landfill.
SMB1 isn’t safe"
ASUS are another one.
Currently shipping "top of the line" ASUS routers are being shipped with firmware that includes Samba 3.0.33, which is a decade old for crying out loud, riddled with security bugs, and supports only SMB1 (which is being deprecated everywhere, fast). And ASUS have no plans to update their current (let alone legacy) products to a modern, (more) secure version of Samba, such as Samba 4.
You can use third-party firmware alternatives for the ASUS routers that do include a more recent version of Samba 3, which would at least get you SMB2 support, but apparently the devices don't have enough flash storage to allow Samba 4 to be included.
So please, give ASUS routers a very wide berth as ASUS don't give a fsck about basic security, or their users. Alternatively, disable the outdated and insecure ASUS Samba server entirely, and use something else (Raspberry Pi3+?) for your Samba file sharing.
"So please, give ASUS routers a very wide berth as ASUS don't give a fsck about basic security, or their users. "
About 20 years ago, ASUS responded to a plethora of customer complaints about problems with their TNT2 video cards by shutting down their entire customer forum system. This caused me to set a policy of "never deal with ASUS"
More recent interactions caused by a vendor who sold us rebadged ASUS servers showed that the attitude hasn't changed (when the stuff arrived I expressed my misgivings and was overruled, things quickly turned to shit from there on the support front as the vendor was left high and dry by ASUS.)
"Was wondering why my NAS wasn't working. Never mind, I'll just go upgrade to the latest firmware. Oh, there isn't any and they're not planning the upgrade? For this device still in shops? Fk off."
SMB2 came out in 2006. I am amazed that anyone would buy a NAS in the last decade that didn't support it.
My experience has been that the people selling such rubbish are severely clue-deficient, and take the labelling on trust, which as often as not never mentions SMB version support. SMB is SMB is SMB.
So it's a combination of piss-poor documentation from the manufacturer, and low-paid sales staff.
For most of this century the well-informed salesman has been a dying breed, but at least I can download the manuals. But does that help?
Last week I was working on an old Dell workstation, it is good kit and I got a good deal. But the manual (and Dell support) are inadequate on how to fit anything in the front-of-case drive bays. Problem sorted, but it doesn't impress.
Given that the protocol has been depricated for nearly 2 decades, it is astonishing how many products still use it as standard / don't support SMBv2 or SMBv3!
At a previous employer, we had it the other way round, we disabled SMBv1 on all servers, only for the Minolta scanners to stop working, because the scan-to-folder option only supported SMBv1, and they were new (less than 2 years old) printers!
"Oh, there isn't any and they're not planning the upgrade? For this device still in shops? Fk off."
Add Netgear to the list. We
bought had some of their switches foisted on us recently by sales. Turns out you can't remove the vlan 1 untag on all the ports or something daft along those lines.
Last firrmware update was 2013 and they are still being sold.
I don't think it was "fecked up by design" - i.e. the original intention in the design being to feck it up.
"The design was fecked-up" is perhaps what you meant.
Then again, that's pretty standard for any networking protocol designed at the same time, when security was, well, not considered at all. SMTP probably stands out most of all :-) (although that does of course predate SMB by some considerable margin)
It's called "being expressive" by use of punctuation, capitalization, etc.. I think it is MUCH better than "monotone" and puts the emphasis where _I_ want it. (NOT putting emphasis on the right words changes its meaning, JUST a bit)
facepalm icon for various reasons.
Why not use the tools that come with the silver badge next to your name? Things like bold, italics, and underlining can add just as much emphasis in the same places and make your posts easier to read at the same time. You have earned the privileges and no one will think less of you for using them.
On the other hand, by insisting on using caps to accomplish your goals you are coming across like a guy that thinks the volume of the message makes it a better argument. People will discount what you have to say because of it. Or worse, just ignore you.
"Why not just patch the vulnerability rather than disabling it?"
Microsoft HAVE patched all the SMBv1 OS security vulnerabilities to date in supported OSs - and in quite a few that were no longer supported.
There is however an unpatched denial of service issue called SMBLoris:
“The case offers no serious security implications and we do not plan to address it with a security update,” a Microsoft spokesperson told Threatpost. “For enterprise customers who may be concerned, we recommend they consider blocking access from the internet to SMBv1.”
May I point you to medical hardware?
As a rule-of-thumb, any medical hardware that needs a dedicated control computer with a specific OS version (e.g. WinXP) should not be networked (or on an isolated network with its own e.g. file server). It's not going to have a problem with SMB1, as it won't be using SMB, unless its partner hardware requires it - which will also be kept off any general network, and certainly never let near t'interwebz.
SMB is a bit naff (and its actually well over 30 years old) but -- and this is a big BUT -- being an 'old' protocol doesn't necessarily make it a bad protocol.any more than being a 'modern' protocol makes something good. I've noticed a tendency for modern code and protocols to be both bulky and bandwidth hogs, attributes that open up all sorts of failure modes but in the general haze of inefficiency its just easy to point the finger at something else and claim that one's own work is perfect. Not true.
(Incidentally, 'pure' SMB is so old that it can't run on a routed network so its pretty difficult to abuse or hack. What most people see as SMB is a protocol running on UDP.)
Most stuff is OK to transmit in the clear. For the really sensitive stuff, like backups, it should probably be stored in encrypted form and so transmitting in the clear is fine. For other stuff, if you are still bothered, a better option is probably to use IPsec and then stop worrying about whether your various higher level protocols have encryption built-in. Sadly, IPsec appears to be stuck in the same tar-pit as IPv6.
I haven't heard of this so assume it hasn't happened. But if not it would of been nice for MS to pop up a warning message when connecting to SMB1 shares to alert the user. More props if they pop up a warning for SMB1 capable servers even if the clients are able to connect via a newer version of the protocol.
I'd wager ~98% of the users out there have no idea what SMB version they might be using(or even how to tell). I count myself among those. My usage of SMB is quite small though I do have a samba system at home, just doing a quick check on Samba and SMB v1 I came across this article for how to turn SMB v1 off:
I checked the config (fairly default config) on my system and there is no mention of the "min protocol" setting(don't know what the default is for Samba 4.2), so maybe SMB v1 is enabled, or maybe not. The only clients that access it are windows 7, and there too I really have no idea what protocol version they use to connect.
(small disclaimer linux has been my main OS of choice desktop/server for 20 years now, though I have used windows from 3.0 -> 7(client) windows, and I do manage a dozen or so windows server VMs(win2k8 and 2k12) as well, so not totally green)
Same goes for enterprise stuff, I have SMB on an EMC Isilon cluster(code is fairly current) but no idea what version of SMB it runs(a quick search shows one person wanting to disable SMB v1 on Isilon 2 years ago, and another person suggesting a specific code version that introduced the option to disable SMBv1)
"I'd wager ~98% of the users out there have no idea what SMB version they might be using"
98%+ of the users out there probably have no idea what SMB is so a pop up warning will just result in another call to IT support and a response that will probably just reinforce the "dont worry just click ok" mindset that these warnings can engender
It's could be a bind if you run say RHEL/CentOS 6 which is still supported by RHEL to which you may be locked for support contracts etc.
Until quite recently there were no Samba 4 packages available for it, apart from Sernet who then pulled their open source packages behind a paywall some time ago.
RHEL slipped out some S4 packages a while back but they are only at 4.2.x and W10 I believe really wants 4.3.x + for SMB 3.1+
Messy. Probably even worse if you run a NAS and rely on upstream firmware.
If I had my cynics hat on I'd almost say 'contrived'
But that would be too cynical, wouldn't it?
...Win10 Pro and above have natively supported being an NFS4 client. It just works, once you enable it. In fact, if your NFS server is exporting a volume formatted with ntfs-3g it works for storing backups. With the right export options you can even store a Win10 system image. Imagine it: Win10 accessing a mapped network drive like a *nix client and treating it like a native MS server share.
Now, I know there has to be a down side to it. I just don't know what it is yet. What I do know is that I don't need SMB on my network anymore. Thank RNGesus for that!
Ditto, as someone who rarely uses windows but has been using linux and unix for years i've rarely seen kernel panics, and those i have seen were usually down to either hardware faults or me testing/writing experimental kernel patches.
The few times i've used windows, or seen someone else using it, i always wonder how they put up with it. Just last week a friend of mine was unable to connect to wifi and had to reboot before it would work, and after rebooting the system was sluggish for several minutes and inundated with focus-stealing popups.
To be fair, since Vista (when Microsoft changed the way drivers were allowed to interact with the kernel), the only BSoD's I've seen have been either bad hardware, or bad drivers/software.
I've still probably seen more BSoDs than kernel panics, but that's partly because most of the linux machines I interact with are servers, with the higher grade of hardware that implies.
BSOD's on the other hand, are a frequent occurence
I don't think I've only ever seen a BSOD when there's not a hardware fault. The last time it was a faulty RAM module, and the BSOD message was diagnostic enough to be able to google it and then pop in a memtest86 boot CD to diagnose it properly.
Maybe back in the mists of pre-history I might have seen one or two on a 386 running Win3.1, due to dodgy drivers or IRQ conflicts.
Please forgive my extreme amplification of Bob's posting style. I was just trying to make a point, perhaps it didn't work.
As far as my views on windows go: I hate it with a passion. For over 25 years I have been a passionate user and supporter of FLOSS. However I try not to let my idealism get in the way of actually being able to do things and using the best tools for the job.
Sadly, sometimes that means I have to use things like Windows, Java, systemd based distros, gasoline engines, dish-washing detergent, and a whole legion of other first world problems. Happily, I get things done every now and then.
Anyway I gave you an up vote because I didn't think your comment was bad enough to deserve the down votes.
Linux is not without it's faults.
Seems like even "secure" distros (no GUI) are now experiencing memory leaks due to questionable scripts being enabled by default.
These bugs are being called "mostly cosmetic" by their authors even though they are listed as known exploits.
Things went downhill rapidlyafter systemd was introduced.
"Now, I know there has to be a down side to it. I just don't know what it is yet."
I don't know either, but I do know that the Samba people have put in a lot of work over the years trying to find interoperability compromises between the Windows and UNIX rules for filenames, user identities, security descriptors and locking semantics. It more or less works, so if Microsoft have studied Samba's efforts in detail and put in a similar amount of effort in their NFS client then you'll be fine. (That's not impossible, People like Ned Pyle do appear to be very familiar with Samba.)
Imagine it: Win10 accessing a mapped network drive like a *nix client and treating it like a native MS server share.
So exactly like Win 7 then, although hopefully with a few fewer bugs.
I was rather hoping they'd have managed to do the same with sftp by now in Win 10.
But on my way whom a colleague contacted me to say they couldn't reach a fileserver which happens to be W2003.
Now colleague is on Win7Pro and they haven't installed any updates (because in a hunt for free space on another server, a third party IT provider deleted the WSUS db thereby knocking out any new updates)
But this is a good spur to replace the 2003 server.
Why do I have to be constantly reminded that the aging AS400 we have at work is running an out of date version of the OS and only supports SMB1 without which we can not send direct debits.
Sigh. Its not fun when you give the financial users a brand new dell laptop with which they process the direct debits via the ERP on the AS400 to then have them phone up when the client software on their laptops no longer sends the direct debits because a windows update was installed that turned off smb1 so the client software can't write to the ifs on the AS400. They then call you expecting a fix in the last few mins of the day OR NOBODY GETS PAID their monthly salary, including you!
Talk about pressure followed by flood of relief as you manage to turn it back on.
Then you sit back wiping the sweat from your forehead and wonder why MS can't let you override it by group policy that you can apply to only certain laptops as needed while you wait for the big wigs to finish approving the migration to the new cloud based ERP which keeps getting pushed back month by month no matter how often you tell them what smb1 is and why MS keep trying to kill it and how that should fast track the new ERP approval.
So you are angry with MS wondering why you are not in full control of your computer thus realizing Richard Stallman was right after all and angry at the big wigs for wasting time stuffing their faces at as many meetings they can find an excuse for, while waiting till pay day knowing that you will go through it all again.
No wonder I love reading Dilbert.
So your organisation depends on a propietary 3rd party protocol for a mission critical service. Do all of your vendors support indefinite end of life?
Probably not. Boo hoo.
The important thing is to strictly control the reach of any protocol and manage interfaces appropriately. Not rocket science, and never has been.
"wonder why MS can't let you override it by group policy that you can apply to only certain laptops as needed while you wait for the big wigs to finish approving the migration to the new cloud based ERP"
Perhaps you could arrange it so it's just their salaries that don't get paid one month...
Well perhaps someone should have thought about that before implementing a critical system using such a poorly designed protocol...
Really the problem is that SMBv1 was so badly designed in the first place that it needs to be turned off for security reasons. There are plenty of other protocols that are old and still in use and also still widely supported by backwards compatibility even when newer versions also exist.. SMTP/ESMTP, HTTP 1.0, DNS etc.
I think microsoft has a point here. Never mind that the protocol was made insecurely; that was a problem before but it's just reality now and it has to be dealt with. Microsoft can't seem to get people to change from one protocol to the next version that is more secure just by making it available. SMB2 is twelve years old, after all. In that case, it may be needed to add an incentive for that to happen. Sure, it'd be nice if nothing ever broke and people only had to upgrade when they wanted new features, but that's not how software works.
A month ago, I found this old device with an ancient linux kernel on it (version 2.6, proprietary interface on it) in my closet. I played around with it, trying to see if you could run modern stuff on it. The device had no package manager and no C compiler, but it did have various other packages and python. So I tried to download some code from github, and what happened? It wouldn't download because github had instituted a security policy the browser didn't support. I'm not quite sure what it was. I think this is new enough to support https in general, so I assume it was a new version of SSL. So, technically, SSL changed its security policy in such a way that my device couldn't even browse the internet. Still, we want that kind of thing to happen because if we just left it out, we wouldn't have security. We'd have plain HTTP, and whatever version of SSL we started with. That version has become insecure, so we've canceled it. Security requires protocols to change. Sometimes, that means we can't use our windows 2003 servers anymore because it's now 2018. In my case, it means my powerhouse of a 520mhz ARM processor from I don't know how old with its 64mb of ram can't be expected to go online anymore. Of course, if the hardware on which it was running was that important, we could always reinstall it with something modern. Sometimes, that's just how things should be.
"They then call you expecting a fix in the last few mins of the day OR NOBODY GETS PAID their monthly salary, including you!"
Or the people who would have signed off the updates on the AS400. You had a useful tool there.
But you probably still do, as SMB1 will be forcibly disabled sooner or later, probably sooner.
you wait for the big wigs to finish approving the migration to the new cloud based ERP which keeps getting pushed back month by month no matter how often you tell them what smb1 is and why MS keep trying to kill it and how that should fast track the new ERP approval
I don't see any mention in there of the thing you should be telling them.
>>>> NOT doing the migration costs X amount of money in lost productivity etc. every single month.
Speak their language: Quantify the cost of not doing it.
@as400 AC (if you ever read this, it’s been 2 days since your comment): what are you running ? And are you using smb with the as400 as a host or a client ? I’ve switched over to qntc a long time ago (when we were running 5.4 or 6.1), as then the as400 acts as a client and gets its files from a windows file server. And that file server is the one where the users put their files, which might have a share that still supports smb1. Oddly enough that gave better results.
Posted as AC as well, since I want to keep that as400 my dirty little secret.
What exactly is wrong with smbv1 thats fixed in newer versions?
I still use NFS, sometimes NFSv2 or v3 depending on the use case - i'm aware it lacks security features present in newer versions, but in many cases those features are not necessary. I have a readonly share full of videos and music for instance which is shared by multiple clients in my house, including linux based media centre boxes. I don't care if someone gains access to that data, and i'm not aware of any vulnerabilities in the server software itself.
>I still use NFS, sometimes NFSv2 or v3 depending on the use case - i'm aware it lacks security features present in newer versions<
SMB2 is not more secure by design than SMB1. The security angle is that SMB1 servers are out of support.
At Win2K, SMB1 was transitioned to TCP, and encryption was added on top. As a result, network latency became much worse (packet delays and handshaking). SMB2 was introduced to try to recapture some of the lost performance capability. By reducing the number of protocol transactions required, the effect of waiting for packet consolidation and encryption transactions is reduced.
You can, I presume, get an even better latency by using SMB2 and /also/ turning off encryption and using "NBF" (what wikipedia calls NetBEUI). You're welcome to try it :)
My wifes business has been bought to its knees because post update the machines she relies on no longer work reliably. 10 minutes and then a complaint, a reboot, another 5 or 10 minutes and another complaint (not always the same one) and another reboot, sometimes two or three on the trot, sometimes 20 minutes. Some comments on forums saying to update device drivers and so on... but I have had enough, the wife is going to have to swap to linux, Microsoft have finally managed to fuck one of their previous employees off so much that even I am ditching them after being with them since DOS
It seems quite reasonable to disable an outdated and vulnerable network protocol when alternatives have been provided for years (newer SMB versions). It protects the immense majority of users of a class of vulnerabilities.
However, as Microsoft gets a lot of telemetry data from Windows 10 PCs, it should have seen that a few of its customers insisted on using SMB 1, and hence written a warning on the release notes of the latest Windows 10 update informing them of the plan, and perhaps offer a workaround.
I have an old Seagate 4-bay NAS (Actually a LaCie NAS in disguise) and since the first update in September have not been able to SMB connect to my NAS. I can connect by typing the IP address i and get logged into the administrative console. But the problem is the version of linux that this machine is using only know about SMB 1.0 and it been ages sicne Seagate updated this piece of hardware. So my only option is to get a new NAS and copy everything over to it and abandon this reliable piece of hardware.
I have an old Seagate 4-bay NAS (Actually a LaCie NAS in disguise) and since the first update in September have not been able to SMB connect to my NAS. I can connect by typing the IP address i and get logged into the administrative console. But the problem is the version of linux that this machine is using only know about SMB 1.0 and it been ages sicne Seagate updated this piece of hardware. So my only option is to get a new NAS and copy everything over to it and abandon this reliable piece of hardware
Biting the hand that feeds IT © 1998–2019