How to Harden SMB and File Sharing on Windows Server 2012 R2
Server Message Block (SMB) is the protocol behind Windows file sharing, named pipes, and printer sharing—and it has been a primary target for attackers for decades. From EternalBlue (MS17-010) to NTLM relay attacks, SMB vulnerabilities have enabled some of the most devastating network breaches in history. Windows Server 2012 R2 supports SMB 3.0.2 with full encryption capabilities, but it also supports SMB 1.0 by default—a protocol with critical vulnerabilities that should be disabled in any modern environment. This guide covers disabling SMBv1, enabling SMB encryption, requiring SMB signing, and restricting access to shares.
Prerequisites
- Local Administrator or Domain Admin access
- An inventory of all clients that access this server via SMB—ensure none require SMBv1 before disabling it
- All clients should run Windows Vista/2008 or later to support SMB 2.x; Windows 8/2012 or later to support SMB 3.0 encryption
Step 1: Audit Current SMB Configuration
# Check which SMB versions are currently enabled
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, EnableSMB2Protocol, EncryptData, RequireSecuritySignature
# Check active SMB sessions and connections
Get-SmbSession | Select-Object ClientComputerName, ClientUserName, NumOpens, Dialect
# Check which SMB dialect is being used by current sessions
# Dialect 1 = SMBv1 (vulnerable), 2.002/2.1 = SMBv2, 3.0/3.0.2 = SMBv3
Get-SmbConnection | Select-Object ServerName, UserName, Dialect
Step 2: Disable SMBv1
SMBv1 has multiple critical vulnerabilities including EternalBlue (used in WannaCry and NotPetya). Disable it immediately:
# Disable SMBv1 server-side (prevents the server from accepting SMBv1 connections)
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force
# Verify
(Get-SmbServerConfiguration).EnableSMB1Protocol # Should be False
# Also disable via registry (belt-and-suspenders approach):
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesLanmanServerParameters" `
-Name "SMB1" -Value 0 -Type DWord
# Disable SMBv1 client-side (prevents the server from initiating SMBv1 connections to other servers)
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesmrxsmb10" `
-Name "Start" -Value 4 -Type DWord # 4 = Disabled
# Confirm
(Get-ItemProperty "HKLM:SYSTEMCurrentControlSetServicesLanmanServerParameters").SMB1
A reboot is recommended after disabling SMBv1 to ensure the driver is fully unloaded.
Step 3: Require SMB Signing
SMB signing cryptographically signs every packet, preventing man-in-the-middle attacks and NTLM relay attacks against SMB connections:
# Require SMB signing on the server side (all SMB connections to this server must be signed)
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force
# Require SMB signing on the client side (all SMB connections from this server must be signed)
Set-SmbClientConfiguration -RequireSecuritySignature $true -Force
# Verify server configuration
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature
# Verify client configuration
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
Also configure via Group Policy for domain-wide enforcement:
Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options:
- Microsoft network server: Digitally sign communications (always) — Enabled
- Microsoft network client: Digitally sign communications (always) — Enabled
Step 4: Enable SMB Encryption (SMBv3 Only)
SMB encryption (SMBv3) encrypts the entire SMB session, protecting data in transit from eavesdropping even on compromised network segments. This requires both the server and client to support SMBv3 (Windows 8/2012 or later):
# Enable encryption for ALL shares on this server (server-wide encryption)
Set-SmbServerConfiguration -EncryptData $true -Force
# Verify
(Get-SmbServerConfiguration).EncryptData
# Alternatively, enable encryption per-share (more granular)
Set-SmbShare -Name "SensitiveData" -EncryptData $true
# Verify share-level encryption
Get-SmbShare | Select-Object Name, EncryptData
# Check if encryption is in use for current sessions
Get-SmbSession | Select-Object ClientComputerName, Dialect, Encrypted
Step 5: Restrict Anonymous Access to SMB
Anonymous (null session) SMB access allows unauthenticated enumeration of shares, users, and groups. Restrict it:
# Disable anonymous access to named pipes and shares
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesLanManServerParameters" `
-Name "RestrictNullSessAccess" -Value 1 -Type DWord
# Remove named pipes accessible without authentication
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesLanManServerParameters" `
-Name "NullSessionPipes" -Value "" -Type MultiString
# Remove shares accessible without authentication
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesLanManServerParameters" `
-Name "NullSessionShares" -Value "" -Type MultiString
# Restrict anonymous enumeration of SAM accounts and shares
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsa" `
-Name "RestrictAnonymous" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsa" `
-Name "RestrictAnonymousSAM" -Value 1 -Type DWord
Step 6: Audit and Harden Share Permissions
Review all existing shares and remove unnecessary ones. The IPC$, ADMIN$, and drive letter administrative shares are required for domain management but should be access-controlled:
# List all shares and their current permissions
Get-SmbShare | Select-Object Name, Path, Description
Get-SmbShareAccess | Select-Object Name, AccountName, AccessRight
# Remove overly permissive "Everyone" access from shares
# First identify shares with Everyone access:
Get-SmbShareAccess | Where-Object { $_.AccountName -eq "Everyone" } |
Select-Object Name, AccountName, AccessRight
# Remove Everyone from a share and replace with specific group
# Example: Replace Everyone/Read with Domain Users/Read on ShareName
Revoke-SmbShareAccess -Name "SharedDocs" -AccountName "Everyone" -Force
Grant-SmbShareAccess -Name "SharedDocs" -AccountName "CORPSharedDocs-Readers" -AccessRight Read -Force
# Always ensure NTFS permissions are also configured restrictively (share permissions alone are insufficient)
Step 7: Enable SMB Audit Logging
# Enable SMB file access auditing
auditpol /set /subcategory:"File Share" /success:enable /failure:enable
auditpol /set /subcategory:"Detailed File Share" /success:enable /failure:enable
# Verify
auditpol /get /subcategory:"File Share"
# Monitor for unauthorized access attempts
# Event ID 5140 = Network share object accessed
# Event ID 5142 = Network share object added
# Event ID 5144 = Network share object deleted
Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=5140]]" -MaxEvents 20 |
Select-Object TimeCreated, Message
Step 8: Configure Windows Firewall Rules for SMB
# Restrict SMB access to specific source IP ranges (e.g., internal network only)
Get-NetFirewallRule -DisplayName "*File and Printer*" | Select-Object DisplayName, Enabled
# Create a restricted SMB rule (block SMB from public IP ranges, allow from internal)
New-NetFirewallRule `
-DisplayName "Allow SMB from Internal Network" `
-Direction Inbound `
-Protocol TCP `
-LocalPort 445 `
-RemoteAddress "10.0.0.0/8","172.16.0.0/12","192.168.0.0/16" `
-Action Allow
New-NetFirewallRule `
-DisplayName "Block SMB from External" `
-Direction Inbound `
-Protocol TCP `
-LocalPort 445 `
-RemoteAddress "Any" `
-Action Block `
-Priority 1
Summary
SMB hardening on Windows Server 2012 R2 involves multiple complementary controls: disabling the vulnerable SMBv1 protocol, requiring SMB packet signing to prevent relay attacks, enabling SMBv3 encryption to protect data in transit, removing anonymous access, tightening share permissions, and restricting SMB to internal network segments via the firewall. These controls together eliminate the most exploited SMB attack vectors and satisfy the network encryption requirements of compliance frameworks. Document all share permissions changes in your ITSM system and audit them quarterly to prevent permission creep over time.