New SMB Worm Uses Seven NSA Hacking Tools, whilst WannaCry Used Just Two
bleepingcomputer.com
bleepingcomputer.com
For those on linux or not aware, if you see 'cifs' it is the same thing (mostly).
One thing I always did was require connections to use latest smb (mitigates many old version attacks), ensure auth is using highest available methods, but more than anything is running the SMB server behind a well monitored and maintained firewall. That's the thing that gets lots of companies.
Also, this: https://wiki.archlinux.org/index.php/Samba#Block_certain_fil...
Finally, segment your damn networks with vlans/subnets!
That being said, I think the explanation is not available because ... people aren't really sure about a better option!
If we take the common (IMO complex) Network filesystem protocol implementations as having irredeemable flaws (so SMB and NFS, all versions), the only viable contenders I can think of are block level network device protocols. E.g.: iSCSI, NBD, DRBD, and probably quite a few others. These of course have the disadvantage of exposing block level protocols to clients, leaving the actual filesystem management up to the client.
Summary: it's always a tradeoff and most of the options suck in one way or another. I personally wouldn't downvote this comment. But maybe someone could enlighten me.
SMB isn't about file transfer so much as the system around authorization and authentication. SSH/SFTP gives you highly secure access to unix file systems. There isn't a good interface to advanced ACLs.
If you look at, say, Plan 9 OS, it's got a rather interesting 9P protocol which implements a webfs and ftpfs for local fileshares.
What SMB did was, as with much of Windows stuff, conflate a few things:
* The filesharing protocol was mixed in with the transport protocol. That's not all bad, as you have that on the Unix world as well (NFS, AFS). But it means you can't change one without dealing with the other (the usual argument against monolithic design).
* The mounting and share-discovery mechanism was also baked in. This is where things start bordering on lunacy. In the Unix world, you'd deal with this though an independent mount or automount / autofs system. Which is its own brand of lunacy as well, but....
* Licensing. SMB / CIFS shares carry CALS obligations which I've never been able to comprehend.
There are other bits. Like that if you were to access a CIFS share from, say, a Linux box or Cygwin session, each individual process-based access counts as a share (see CALS above, also the per-host session limit of, generally, 10 sessions).
Other options: FTP (though it's probably rightfully dying), HTTP, HTTPS (now we're looking at something remotely sensible), SSH.
There are FUSE filesystems which will work with each of these, though you've got to specify the hosts. You can automate some of that through autofs (on the Linux / Mac side). WebDAV in theory offers a read/write file-based access over HTTP(S), though in practice it's proved difficult.
Generally, this is a space that's oddly lacking in reasonable and good alternatives.
I'd argue more generally that documents-based filesystems are also exceptionally poor at what they ought really be capable of doing.
The need to open and change files right on remote pc (while it is online) always seemed strange, because companies do not work this way. Documents should be received and sent, not mounted and edited silently. I'm sure that there are thousands of info-sharing web projects, from phpbb-likes to specialized light/heavy solutions. But MS sticked to closed, indiagnosable, randomly slow SMB. Traditional file sharing must be killed as an evolution error.
There's a reason why SMB is popular - file sharing among large groups of people who need to modify the files with a web server is a complete nightmare.
Either you have an access problem (which you could solve with authentication + authorization in parent's web-based implementation) or you have a modification problem (which is really a revision control problem that I believe SMB doesn't solve at any version?). Which then leads people to tossing everything into Sharepoint (insert tirade here). Which leads to Microsoft not caring about evolving the SMB spec because it would only cannibalize sales.
So in essence:
SMB cases: "Documents need to be distributed, but not modified by more than one person/team"
Revision cases: "Documents need to be distributed, modified by more than one person/team, and redistributed"
I've seen things like what the parent describes in prosecution with tens of thousands of people work just fine. The leakage to sharepoint has nothing to do with SMB, but with the lack of an easy to use search solution.
Email and Sharepoint give you search and avoid the need for hierarchical filing systems. Search is often less effective, but the clerical people who would maintain those other systems are long gone.
Or is there something I'm missing?
The particular chapter I was thinking of was named "The Worm Turns".
I think the second was how to steal the planet.
When I was in college, I wrote a simple worm to display a new year greeting on all computers it infects. Once it infects a computer, it did the following: 1. it replicated itself to as many computers as possible 2. Displayed the greeting (till user acknowledges it through a key press) 3. self delete (in the hope that it will quickly die by itself)
I seeded it in one of the computers in our college network. I didn't expect it to be so effective; It spread itself very quickly in the entire network. With self-delete, I thought it would die on its own. I was wrong. Machines kept infecting each other in a perpetual loop. The only way I could stop it was to write a new version that replicated, and cleaned the first version. This new version kept replicating in the network even after a year. This new version was not doing anything visible to the user, and I was saved :)
If the SMB implementations in Windows and Samba had been done with due attention to security requirements of networked software, it wouldn't be especially risky either.
In a very large network that I'm familiar with, we killed SMB1 globally to mitigate exposure, and in the process killed a bunch of apps.