1

I work for a municipal government, using mostly Windows servers. In recent days several similar governments in our geographic area have been attacked, some successfully, by ransomware. So our security folks are alarmed, and have decreed (among other things) no more using SMB file-sharing to upload files from the "internal" network to the DMZ. I have a PowerShell script that does just that, to migrate databases; plus we have many other cases to use file shares such as uploading web sites.

They are saying we need to convert to using SSH or SFTP to transfer files. OK, this would be possible, but it would need setup work on every DMZ server, and changing all our current processes, and for what? (We don't have enough people to do that plus everything else, although we've tried to get more warm bodies budgeted.) Anyway I don't see how that's more secure. If DMZ server D is listening on a share, and the firewall prevents access from anywhere but authorized internal workstations or servers A, B, and C, then how can that be any more a security risk (specifically, the risk of malware on server D going back the other way and compromising A, B, or C) than server D listening on an SFTP port or an SSH port, with the same firewall restrictions?

If the issue is something like "the file share is open all the time, but SSH isn't," then that would be somewhat understandable, and we might deal with that by mapping and unmapping to the shares when needed. But I don't think this is their reasoning; I think it's something else. Actually I get the impression it's kind of a vague "feeling" on their part, that file shares are inherently and materially less secure, in the "backward" direction, even if firewall-protected as described above. If this is actually so, then why? I just don't see it. Actually I don't see why any of those protocols would pose a risk in the "backward" direction.

To clarify, there are two things to consider: (1) a regular user having a drive mapped all the time, and (2) an automated script or other situation where the share is accessed briefly, and then any mapping is removed. I do have to consider both situations but primarily, right now, I'm referring to (2). Case (1) would not ordinarily be used to access the DMZ.

  • 2
    Formulate your question more precisely. – mentallurg Aug 23 at 21:57
  • Ransomware could be installed on a outdated workstation and/or a user that clicks a link. As the ransomware is executed with (at least) the same permissions the user has, this might also affect any shares (automatically). Using SSH and/or SFTP there is an extra authentication layer aside from Windows (integrated) authentication. – Jeroen Aug 23 at 22:30
  • There are two things to consider: (1) a user having a drive mapped all the time, which is what you are referring to, and (2) an automated script or other situation where the share is accessed briefly, and then any mapping is removed. I'm looking at both situations but primarily, right now, at (2). – phantomflash Aug 26 at 13:07
  • "Is A less secure than B or C, and if so, why?" is already precise. – phantomflash Aug 26 at 13:16
2

The real question is how does ransom ware spread. This might seem counter intuitive, but over the last two decades there have been numerous problems with SMB that have resulted in worms, ransomware, and all kinds of crazy stuff taking down networks of interconnected systems. Your logic might be right (that your workstation can push data to the server, but the server cannot push data to the workstation), but there are other things.

You don't have to map a drive to a drive letter to connect to a remote host. //server-name/path/to/folder is another technique. Then it's all about the permissions, the other shares.

If you were to turn off network ports on the firewall to block SMB, and you were to turn off all the shares, you could finally kill SMB file sharing. That would be fantastic.

But you'd need a way to share files. SSH is an authenticated mechanism that doesn't necessarily rely on active directory and there are not 20+ years of backwards compatibility baked into it. Oh, i forgot to motion that a current windows system can still communicate with a windows system from 20 years ago, and in there lies a ton of potential bugs and weird configuration settings that might leave your network fairly insecure.

It might be time to stop updating the databases, turn off SMB, and install SSH on the systems instead. It's a valid path forward.

  • There are two things to consider: (1) a user having a drive mapped all the time, which is what you are referring to, and (2) an automated script or other situation where the share is accessed briefly, and then any mapping is removed. I'm looking at both situations but primarily, right now, at (2). And in fact the ideas is to do (2) without actually mapping a drive letter. In the broader situation (1) it would be near impossible to eliminate SMB file shares across the entire user base. Many existing programs and procedures rely on it. We just have to make permissions not too, uh, permissive. – phantomflash Aug 26 at 13:07
  • (1) and (2) are the same problem. If your user has access to an unmapped share, the user still has access to the share. Mapping is a handy way to label shares but is only an alias to the actual share path. And a malicious script can still find shares on remote systems. nmap.org/nsedoc/scripts/smb-enum-shares.html -- to be continued... – Jonathan Aug 26 at 18:48
  • You're using a push model to update the server. Another, and better solution, is to use a pull model. You don't need write access on the server, but the server needs read access on your system (Source). You setup Source server as read only. You log in to Source, pull the files down. You configure the web server to download updates from Source on a periodic basis. – Jonathan Aug 26 at 18:50
  • So, the real problem is opening a share, at all, that lets anyone write into it. Instead, make the system work so you never need to share files except in a read-only mode. – Jonathan Aug 26 at 18:51
  • > a malicious script can still find shares on remote systems Interesting point about deducing hidden shares, but (a) malware couldn't probe too much without hitting one of our honeypots, or otherwise betraying its presence, and (b) it would still need a username & password to connect. So that differentiates (1) and (2). I'm sure there is lots of malware that can spread in case (1) but not in (2). And that's not even counting the fact that a firewall setting would restrict who can connect. – phantomflash Aug 26 at 21:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.