Learn Samba - Firewall & Network Security

#Introduction

Up to episode 12, you built Samba's capabilities — now we secure the entrance. Samba is a network server: it's useless if it can't be reached, but equally dangerous if too open. In episode 13 we map the ports it serves, craft a firewall policy that restricts who can connect, and understand one non-negotiable rule: SMB must never be open to the internet.

#The Port Map

A modern SMB connection needs only one port — but mixed environments (AD, NetBIOS, discovery) open more. The full map:

Port	Protocol	Service
445/TCP	SMB/CIFS	Modern file/print connection — the main port
139/TCP	NetBIOS Session	Legacy SMB connections via NetBIOS
137/138	NetBIOS Name/Datagram	NetBIOS name resolution & browsing (`nmbd`)
389/TCP	LDAP	AD directory (`samba` DC)
636/TCP	LDAPS	Secure LDAP (TLS)
88/TCP	Kerberos	AD authentication
464/TCP	kpasswd	Kerberos password change
135/TCP	MS-RPC	Endpoint mapper (some admin tools)
3268/3269	Global Catalog	AD global catalog (if enabled)

#What's Really Needed

The principle: open as little as possible. A modern standalone file server only needs 445 (plus 139 only if there are legacy clients). An AD DC needs 445, 389/636, 88, and 464; 137/138 (NetBIOS) is only for old-style browsing — on modern networks, DNS has replaced it (episode 2). Don't open 135 unless your admin tooling really needs it.

Minimum recommendations

File server:  445
AD DC:        445, 88, 389/636, 464
NetBIOS:      137/138/139 (only if legacy clients)

#Firewall Policy

#ufw (Ubuntu/Debian)

ufw is an iptables frontend that's friendly to use. The most important rule: restrict sources, not just ports. Example of opening SMB only for the LAN subnet:

ufw — SMB only from LAN

sudo ufw allow from 192.168.10.0/24 to any port 445 proto tcp
sudo ufw allow from 192.168.10.0/24 to any port 139 proto tcp
sudo ufw enable
sudo ufw status verbose

Notice: there's no global ufw allow 445 rule — only from 192.168.10.0/24. An office-LAN Samba server doesn't need access from other networks, and the firewall is how you enforce that.

#firewalld (RHEL family)

firewalld works with zones. Place the server in an internal zone and open the services:

firewalld — samba service in the internal zone

sudo firewall-cmd --permanent --zone=internal --add-service=samba
sudo firewall-cmd --permanent --zone=internal --add-source=192.168.10.0/24
sudo firewall-cmd --reload
sudo firewall-cmd --list-all --zone=internal

add-service=samba opens the SMB ports (445, 139) internally. For a DC, also add --add-service=ldap, --add-service=ldaps, --add-service=kerberos.

Important

The golden firewall rule: default-deny. Start from zero — don't "close unused ports", rather "open only what's needed, from legitimate sources". You should also remember the second layer from episode 4: the firewall protects the network, but it's not a replacement for strong Samba authentication (security = user, valid users). The two complement each other.

#Never Expose SMB to the Internet

#Why It's Fatal

SMB is a protocol designed for a trusted LAN. Exposing port 445 to the internet is like inviting automated scanners (Shodan, attacker bots) to brute-force and exploit — the EternalBlue/WannaCry history shows what happens when 445 is widely open. No number of strong passwords saves you from public SMB exposure.

#The Right Remote Access: VPN

The need to "access shares from home/another office" must be met with a VPN, not port forwarding. The best-fitting choice for Samba is WireGuard — modern, fast, and easy to configure:

WireGuard as remote Samba access

sudo apt install -y wireguard
sudo wg-quick up wg0
wg show

Remote clients install WireGuard, get an IP in the LAN subnet, then access \\fileserver\share as if they were in the office — without opening a single SMB port publicly. WireGuard's port 51820/UDP is the only one that may be open to the internet.

Tip

With WireGuard, SMB ports don't even need forwarding: fileserver stays behind NAT/firewall, VPN clients enter the subnet the firewall allows (the rules we just set above). This is the simplest zero trust pattern for a file server: secure network first, then Samba authentication — two layers that don't replace each other.

#Verifying Network Security

Once the firewall is set, test from outside the subnet (or from a non-allowed host):

Test connectivity from outside

nc -zv 192.168.10.50 445    # seharusnya sukses dari LAN
nc -zv <public-ip> 445      # seharusnya gagal/timeout dari internet

And make sure there are no SMB port-forwarding rules on the edge router/firewall. Also use a simple scanner to see open ports from the outside:

Scan open ports

sudo nmap -p 139,445,389,636 --open <public-ip>

The ideal result: no SMB ports visible from the internet. If any appear, there's homework at the network edge.

#Common Pitfalls

Firewall too permissive: ufw allow 445 without a source = open to everyone — always restrict the source.
NetBIOS 137/138 open without need: they're a source of noise and some attacks; close them if all clients are modern.
WireGuard not installed: trying SMB port forwarding as a "shortcut" — that's not a shortcut, it's a security hole.
Forgot to restart the firewall: rule changes only take effect after ufw reload / firewall-cmd --reload.

#Closing

Key takeaways:

445 (SMB) is the main port; AD adds 389/636, 88, 464; NetBIOS 137/138/139 only for legacy clients.
Firewall policy should be default-deny and restrict sources, not just ports.
ufw allow from <subnet> and firewall-cmd --add-service=samba are the correct patterns.
Never expose SMB to the internet; use a VPN (WireGuard) for remote access.
Verify with nc and nmap from an external perspective.

In episode 14 next, we'll cover SMB hardening — disabling SMB1 with server min protocol = SMB2_10, considering ntlm auth = no, requiring signing/encryption, and building an audit with smbstatus and log level. This is the episode where Samba security goes from "decent" to "hard".