-9

I needed to block port 135 and 445 on Window Server 2008 R2 due to WannaCry . Having done it, workstations could not access the shared folders on the server. Is it possible to configure the file share management with another port? So users can still access the shared folder even the two ports have been blocked.

6
  • 7
    Why don't you just patch the servers and clients?
    – Drifter104
    May 16, 2017 at 15:35
  • Our network is not on domain
    – hohoho236
    May 16, 2017 at 15:50
  • 4
    Thats not a reason to not apply patches? Have you not applied any patches to any machine on the network to date? Applying a readily available patch is much easier than changing SMB ports all client and host
    – Drifter104
    May 16, 2017 at 15:54
  • 1
    Your senior is wrong. Blocking functional ports towards your clients is wrong. Blocking ports from being accessed insecurely from outside your network is a basic precaution you should have already taken.
    – Reaces
    May 16, 2017 at 18:20
  • 1
    Blocking the ports is NOT more secure than applying the patch because blocking the ports does NOT remediate/fix the vulnerability. Patching the machines IS more secure because it actually remediates/fixes the vulnerability.
    – joeqwerty
    May 17, 2017 at 0:42

2 Answers 2

5

Band-Aids don't fix security vulnerabilities

The real problem here is that your computers have a serious security vulnerability. Blocking ports 135 and 445 serves as a Band-Aid to the problem. While doing this may be a viable temporary solution to do damage control, the proper solution is to install the patch throughout your environment.


Blocking ports 135 and 445 has the effect of disabling SMB file-sharing on your Windows Server. If your boss is asking you to do this to "fix" the threat posed by WannaCry, then you should make your boss aware that this is the equivalent of deleting your e-mail address in order to avoid getting spam messages.

Suppose you don't need file sharing enabled. Fine. But by leaving this vulnerability unpatched you arm an explosive land-mine that will make a fantastic mess of your organization the day someone comes along and re-enables file sharing. Don't do this.

Always install security patches, even if you don't currently use the patched service.

2

As mentioned in Twisty's answer, this idea of your "senior" colleague's like deleting your email address to prevent spam. Yeah, that would prevent spam, but it also prevents legitimate use of the service.

In actuality, there are three mitigations to this particular piece of malware.

  1. Apply the relevant patch on your systems.
  2. Disable SMB v1, which is the protocol that the EternalBlue vulnerability exploits.
    • This is actually pretty easy, and for most use-cases, SMB v1 shouldn't be used anyway. The newer versions of the protocol are [much] faster and more secure.
    • Disable-WindowsOptionalFeature -Online -FeatureName smb1protocol
  3. Block the ports that SMB uses.
    • This prevents the malware from spreading by disabling the file sharing vector it uses to spread, which means it also prevents legitimate uses of Windows file sharing.
    • Note that changing the default port doesn't really solve the problem - this malware uses SMB v1 to spread. If you just change the port for your SMB traffic without patching or disabling SMB v1, you're still exposed to the EternalBlue vulnerability that this malware uses. This particular piece of malware may or may not be stopped by changing the port, but the underlying vulnerability would still be exposed.
5
  • Excellent answer. I've not looked closely at options for disabling SMBv1. Is there any way to audit possible use of SMBv1 in the environment before "cutting the cord"? May 17, 2017 at 15:22
  • 1
    @Twisty Not that I'm aware of, but there's probably a way. SMB 2 was introduced with Vista/Server 2008, so the only Windows clients that use it natively are older than that, which should make it a very short list (of clients that probably have no business being on the network anyway, but that's not a guarantee). May 17, 2017 at 15:25
  • Yeah...that wouldn't be a guarantee at NHS May 17, 2017 at 15:26
  • Found a way to audit: Run Set-SmbServerConfiguration –AuditSmb1Access $true Then just examine the SMBServer\Audit event log on the systems. Source May 20, 2017 at 13:05
  • However, this command only works on Server 2016... :-/ May 20, 2017 at 13:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .