Block SMB to WAN

With the newly publicly disclosed Outlook SMB password stealing flaw https://thehackernews.com/2018/04/outlook-smb-vulnerability.html, I'm looking for a tutorial or instructions on how to block SMB traffic to the WAN with LEDE/OpenWRT. I am running version 17.01.4.

Thanks in advance,

J

At least as I read that specific vulnerability, it is a problem in Outlook, not in the protocol itself. (Well, NTLM has its own security issues, but that is out of scope for this question.)

I personally block all Microsoft-related ports on the WAN interface of my firewalls.

I'm assuming you're running Samba. https://wiki.samba.org/index.php/Configure_Samba_to_Bind_to_Specific_Interfaces looks helpful in making sure that it only "listens" on your desired interface or interfaces.

1 Like

Does this include also outgoing traffic from a client inside the local network and if so, can you share the config?

Addendum: I tried to connect with netcat from the outside to my router on port 445 (although it is not stealthed in the standard configuration) I got a "permission denied". Not quite sure is this test is correct / sufficient.

to block inside hosts to connect with smb over the internet:

  1. in luci got to network > firewall > traffic rules
  2. scroll down and add a new forwarding rule
    any source zone, destination zone wan
    tcp+udp ip4+ip6
    destination ports 137-139
    action reject

if you also want to block cifs, add a second rule with destination port 445

2 Likes

Instead of REJECT, use DROP.

I had seen normal connection count of 8,000 getting raised to 80,000 due to traffic to port 445 from LAN to WAN.

On adding a REJECT rule, firewall has to reply back thus consuming CPU cycles. When we know that this traffic doesn't need feedback to the user as required for port 80 or 443, we can silently drop it.

Snort had raised alert for WannaCry infection as well a few times for traffic destined to port 445 from LAN to WAN.

1 Like

point is valid, thou almost every application will wait/stall for a timeout to occour if you just drop.
i prefer to be nice to "my users" and give a fail/nope quickly and thus those cpu cycles are well spent

@fuller

I also prefer doing "REJECT" on LAN to provide feedback to the user, but in this scenario when I saw my box being hammered by traffic that I already know is malicious, I had to move to "DROP".

Yes, no outgoing or ingoing "Microsoft" packets through the "WAN" interface. I also block all broadcast (as well as "bogons"), with the specific exception of the DHCP packets required for my transport.

https://msdn.microsoft.com/en-us/library/cc875824.aspx

My firewall is not on my OpenWRT boxes (they all are APs), so I'll defer to those with more experience with the OpenWRT firewall on the specifics of the rules.