Hiya folks, Ned here again. Organizations are good at firewalling the network edge to stop inbound intruders. We need to move on to preventing outbound and lateral network communications. With the rise of mobile computing and ease of phishing users, compromising an individual device means your external shield isn’t enough.
Today we discuss securing your network’s underbelly. I’m focusing on Windows and SMB, but this advice applies to your other protocols and operating systems. Your environment also uses NFS, SSH, RDP, SFTP, RPC, and more on Windows, Linux and MacOS. Once you read this, I recommend its companion piece How to Defend Users from Interception Attacks via SMB Client Defense.
Let’s block some ports!
Your network forms segments and endpoints. Segments are the partitions, be they subnets or VLANs and includes your VPN-connected devices. Your servers and clients are the endpoints. When it comes to SMB, your clients and servers aren’t limited to Windows and Windows Server – they can serve both duties on any edition. This doesn’t just mean hosting an SMB share for remote file access; SMB is itself a sort of transport protocol for many other legacy application protocols using Named Pipes, RPC, and other technology for your management tools and apps.
By default, no version of Windows allows inbound SMB communications after setup; the built-in Windows Defender Firewall (previously called Windows Firewall) rules prevent access to TCP / port 445. However, the firewall does allow outbound SMB and if you create an SMB share, it enables the firewall rules to allow inbound SMB. This article isn’t demanding you buy 1,000 hardware firewalls like you’re in some craptastic hacker movie – it is about using that Defender Firewall included in every Windows machine you own.
Our goal here is to make it much harder for your data to leave the network or for your devices to attack each other within the network. We are not trying to make the entire network impervious to all threats. We are trying to make your network so irritating to an attacker that they just lose interest and go after some other target.
I’m not here to teach you the built-in firewall, it’s a big product but a well-documented one:
Don’t worry, if you’re still using Windows Server 2012 R2 or… what the h… Windows 7, these are still applicable.
What you don’t know is that my absolute favorite presentation ever about this subject is Jessica Payne’s talk "Demystifying the windows Firewall" at Ignite New Zealand 2016. If you’ve never heard of the firewall or have been using it for years, this talk is awesome, and you should watch the whole thing.
See? I told you it was good! Jessica is the deal.
Here’s the plan:
The easiest part that you probably already completed. Block TCP/ port 445 inbound from the internet at your hardware firewalls. Now anyone inside your network, including VPN-connected devices, won’t be directly accessible from outside.
It is extremely unlikely you’ll need to allow any outbound SMB to the Internet unless you’re using it as part of a public cloud offering. With Azure Files SMB you could instead use a VPN. You should be restricting that outbound traffic to only those service IP ranges. We document those here:
If our goal is to stop unneeded communication inside your network, we need to inventory SMB.
This was the easy part. Now the hard part:
File Servers and Domain Controllers both obviously require SMB inbound to perform their role. Other built-in roles and features may as well and we’ve documented many of them in Service overview and network port requirements for Windows. DCs and file servers probably need to be accessed from anywhere inside the network, but some application server might just need access from two other application servers on the same subnet.
You can examine shares on servers and clients using a handy script called Get-FileShares by Sam Boutros and decide if these shares are legitimate, were once legitimate and now aren’t, or were made by Chad the junior wildman the CTO’s nephew you wish you could fire his… I digress. I demonstrated this script at MS Ignite 2019, catch that at 0:9:45 in my presentation “Plan for Z-Day 2020: Windows Server 2008 end of support is coming!”
You might also need to enable auditing:
Since Windows Vista and Windows Server 2008 you’ve had access to an audit trail of SMB inbound access. You enable it as part of group policy and deploy to whatever set of nodes you want to check. It’s found under:
Computer configuration \ Policies \ Windows Settings \ Security Settings \ Advanced Audit Policy Configuration \ Audit Policies \ Object Access \ File Shares
Examining these logs will let you know which nodes are talking to which endpoints over SMB and help you decide if an endpoint’s shares are really in use, which don’t need to exist, or if the server has no obvious SMB customers.
If you’re looking for a step-by-step guide on configuring firewalls, review our docs; my blog post will never be as good and also I am very lazy. But we can talk tactics. The key thing to understand is blocking both inbound and outbound communications in a very deterministic way using rules that include exceptions and add additional connection security. A common attack is to convince an end user to access an SMB share just like you’d trick them into accessing an evil website. Email them a link, convince them to click, and now they are sending along NTLM credentials or running mean executables. An outbound firewall policy that prevents use of SMB connections not just outside the safety of your managed network but even inside your network to only allow access to the minimum set of servers and not any other machines is true lateral movement defense.
You reference here for SMB firewall settings is Preventing SMB traffic from lateral connections and entering or leaving the network. This KB covers the precise SMB firewall rules you need to set for inbound and outbound connections to match your inventory. I want to call out a few important points in that KB:
Incredibly important note for all of us non-Firewall experts: to use the null encapsulation IPSEC authentication and have the rules actually work, you must create a Security Connection rule on all computers in your network that will be participating in these allow/blow rules, or the firewall exceptions above will not work and you'll only be arbitrarily blocking.
To configure in the Windows Defender Firewall snap-in or group policy:
1. Open Connection Security Rules, create a new Isolation rule.
2. Use the default Requirement "Request authentication for inbound and outbound connections."
3. Set Authentication Method to "Computer and User (Kerberos V5)
4. Set for all profiles, name your rule, and save. Remember that this must be done for all computers - clients and servers - participating in your new inbound and outbound rules or they will be blocked from connecting SMB outbound.
These may already be in place from other security efforts in your environment and like the firewall inbound/outbound rules, can be deployed via group policy.
To configure the actual rules, while following that KB article:
The “Allow the connection if is secure” option allows override of a global block rule. You can use the easy but least secure “Allow the connection to use null encapsulation” along with “override block rules” which is effectively relying on Kerberos and domain membership for authentication. Defender Firewall allows for more secure options like IPSEC, but they will require more from you. When you provide these secure connection options, you now get access to scopes like authorized computers and IP address:
If you watch Jessica Payne's video above you'll learn way more about this. Really!
The defensive impact of this layering means attackers must determine which small set of allowed servers are valid targets that must be controlled or replaced without detection, all within your inner network. Broad lateral movement and client-hopping ransomware will no longer be able to piggyback SMB on end user device. When I talk about being too irritating of a target, this is what I mean. Yes, all of those things are possible, but you‘ve increased your chance to catch them, required a huge amount of extra recon and care from the attacker, broke a ton of lazy code written by criminals, and frankly makes you unattractive.
This type of outbound protection at the Windows Firewall is also great technique for those who don’t want to walk their COVID telecommuters through changing home router firewalls to block SMB outbound to the Internet when you don’t use VPN. I know you’re out there, you all asked me about machine account password expiration rules two months ago! Even if they can’t get group policy or Intune, you at least have a consistent set of steps or script for a Help Desk remote.
Your Windows clients and even some of your Windows Servers may not require the SMB Server service to be running at all. Here’s my own work Surface Laptop with SMB server disabled:
Far more secure than any firewall is the complete lack of an SMB Server service running at all. This step that will require you to fundamentally understand your processes and apps and comes with the risk of a very confusing troubleshooting experience in a year after you’ve forgotten doing this.
Note: I've debated making this service on-demand in the future and perhaps disabled by default in certain conditions and editions like Windows 10 for home users or Professional. This might seem like an easy call to make, but you haven’t spent 7 years of SMB1 removal pain customers saw when I first started making it optional and self-uninstalling. It would initially break a lot of enterprises.
You should use phased group policy rollouts to make these changes after you do small-scale, hand-made deployments on select servers and clients – do not just blast these settings out everywhere or you’re going to have a bad day week exit interview. I recommend starting with the heaviest user of SMB – your own IT team. We call this “eating your own dogfood .” If your team’s laptops and apps and file share access appear to be working well after hand deploying your inbound and outbound firewall rules, create test group policy within your broad test and QA environments. Based on results, start sampling some departmental machines, then expand out. Take your time here – you’ve had the wild west for 20 years, you won’t cleanup Tombstone in a weekend.
That concludes the SMB steps. Now just repeat for NFS, SSH, SFTP, RDP, and the rest, figuring out all the equivalent firewall options of MacOS and Linux. Simple! ;D
Distributed system protocols help your organization make money and get things done. However, they do demand your respect if you want to make your environment unattractive to bad people. Computers, networks, and users aren’t good at defending themselves: that’s your job.
I hope you found this useful. Now go read How to Defend Users from Interception Attacks via SMB Client Defense.
- Ned Pyle
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.