18 — Network Security Controls

Level: Intermediate · Time: ~22 min · Prerequisites: Lesson 17 — Hardening — The Baseline Everything Starts From

Why this matters

Lesson 16 said the flat internal network is the biggest structural weakness in a small business. This lesson is what you build instead: controls that decide which traffic may move, in which direction, between which zones, and which traffic is watched while it moves. Done well, they make an attacker's first successful compromise survivable, because the machine they landed on cannot reach the systems that matter. Done badly — one any-any rule, one VLAN with no policy — they deliver the paperwork of security and none of the effect. This is also where the firewall you hardened in Lesson 17 starts doing real work.

Firewalls: what each generation actually inspects

Generation	What it looks at	What it cannot see	Where it still earns its place
Stateless packet filter	each packet alone: source, destination, port, protocol, flags	whether the packet belongs to an established conversation	simple, fast ACLs on routers and switches; basic host filtering
Stateful inspection	the connection, tracked in a state table, so replies to your outbound traffic are allowed automatically	anything inside the payload — nothing above the port level	the default in every modern firewall and host firewall
Application-aware / next-generation	the application and its content: deep packet inspection, protocol and user identification, threat signatures, URL categories	encrypted content, unless you intercept it	policy by application or user instead of by port

TLS interception is the trade-off to understand rather than adopt by reflex. To inspect HTTPS the firewall terminates the connection, examines the plaintext and re-encrypts it, which means issuing a certificate your devices must trust. The consequences: certificate-pinned applications break silently, some applications refuse to work at all, the decryption capability itself becomes a target an attacker can abuse, it is unethical and often unlawful on personal or health traffic, and you create one appliance holding a copy of everything. Decide deliberately — intercept where you must inspect something specific, and prefer endpoint visibility for the rest.

Network, host and application firewalls

Type	Where it sits	Protects against	Limitation
Network firewall	at the boundary and between zones	unauthorised connections between networks	blind to traffic that never crosses it, and to internal hosts talking to each other on the same segment
Host-based firewall	on each machine (nftables/ufw, Windows Firewall)	unsolicited connections to that host, and unwanted outbound connections	must be configured per host, and is only as good as the baseline that applied it
Web application firewall	in front of a web application	injection, malformed requests, some bots, known exploit patterns	does nothing about your logic flaws, and its false positives need tuning by someone

Firewall rule design is a craft

The principles, in the order that matters:

Default deny in both directions. Everything not explicitly permitted is dropped — including outbound, which is the direction almost everybody forgets.
Every rule states source, destination, port and protocol explicitly. A rule you cannot describe in one sentence is a rule nobody will ever dare remove.
No any-any rules, not for the guest network, not "temporarily" for a project, not for the CEO's laptop.
Order and comment every rule with the reason it exists — the comment is what lets a successor delete it safely.
Log the deny rules so you can see what is trying to get through and what your users actually need.
Review and expire. Every rule gets an owner and a review date; an expired rule is deleted, because unused permission is free access for whoever finds it.
Restrict the management plane to a management network or specific hosts, and never expose the firewall's own admin interface to the internet.

# The shape of a rule set — the syntax varies by vendor, the logic does not
DENY    any           any                 any       # default deny, logged

# DMZ services that must be public, and nothing else inbound
ALLOW   any           203.0.113.10        tcp/443   # public web front end, patched and hardened
ALLOW   any           203.0.113.11        udp/51820 # WireGuard VPN terminator

# Server zone: only what the application needs, only from where it needs it
ALLOW   10.0.10.0/24  10.0.20.10          tcp/443   # user VLAN to web application
ALLOW   10.0.20.10    10.0.20.30          tcp/5432  # web application to database
DENY    10.0.20.0/24  10.0.10.0/24        any       # servers never initiate to workstations

# The same logic on one host you own: /etc/nftables.conf
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept          # replies to my own outbound traffic
    iif lo accept                                # loopback
    tcp dport 22 ip saddr 10.0.99.0/24 accept    # admin only from the management VLAN
    tcp dport 443 accept                         # the service this host exists to provide
    log prefix "nft-drop-in: " counter drop      # see what you are blocking
  }
  chain forward { type filter hook forward priority 0; policy drop; }
  chain output  { type filter hook output priority 0; policy accept; }
}
sudo nft -c -f /etc/nftables.conf && sudo systemctl enable --now nftables

Egress control

The easiest path out of your network is HTTPS to a domain you have never seen. Allowlisting every destination breaks the business, so the realistic sequence is measure, then restrict where it matters.

Approach	Effort	Effect
Log all outbound connections and review weekly	low	you learn what normal outbound looks like, which you need before any policy
Block outbound from devices that never need it — servers, cameras, printers, IoT	low	removes whole attack classes for those devices
Allowlist destinations for servers (patch mirrors, backup targets, vendor APIs)	medium	server traffic becomes explainable, and anything else is an incident
DNS and destination filtering for users, with a bypass request process	medium	blocks obvious malicious infrastructure without stopping legitimate work

[!TIP] Start with the highest-value piece: servers should not need to talk to arbitrary internet destinations. Once your server zone has an egress allowlist, an exfiltration attempt or a command-and-control callback becomes a firewall log line instead of an invisible event.

Segmentation in practice

The zone model

Zone	What lives there	Inbound allowed	Outbound allowed
Internet	the untrusted world	nothing	publishes only specific services
DMZ	web front ends, VPN terminator, mail relay	specific ports from the internet	the specific internal service it serves; never free rein
User	workstations, phones, printers	replies to its own requests only	the services it uses, via the firewall, not by direct subnet access
Server	application, file and database servers	specific ports from user and DMZ zones	allowlisted destinations only
Management	hypervisor consoles, switch and firewall admin, monitoring	privileged workstations only, from a dedicated network	the managed devices it administers
Guest / IoT	visitors, cameras, TVs, thermostats, personal devices	—	internet access only; no route to any internal zone

Hand this table to whoever configures the appliance; it is the policy, expressed as intent rather than as rules:

From / To	Internet	DMZ	User	Server	Management	Guest/IoT
DMZ	reply only	—	deny	one specific service	deny	deny
User	filtered egress	the published service	own zone, limited	the applications used	deny	deny
Server	allowlisted only	deny	deny	own zone, specific ports	deny	deny
Management	restricted	restricted	deny	what it manages	all (that is its purpose)	deny
Guest/IoT	allowed	deny	deny	deny	deny	own zone

Two rules catch most real-world mistakes. The management plane must never be reachable from a user VLAN — if the hypervisor console sits on the same network as the office laptops, a compromised laptop is one credential away from every virtual machine. And guest and IoT devices get internet access and nothing else, because a smart camera with a known vulnerability is a foothold, not a device.

Layer 2: the controls that hold segmentation together

A VLAN is not a security boundary on its own; several layer-2 techniques can cross or subvert it. All of these are standard features on managed switches.

Control	What it prevents
802.1X port authentication	a device plugging into a wall port and getting network access without credentials
Port security and MAC limits	one port being used for a switch or a flood of devices
DHCP snooping	a rogue DHCP server handing out itself as the gateway (the man-in-the-middle from Lesson 9)
Dynamic ARP Inspection	ARP poisoning on the local segment
BPDU guard	a user device joining spanning tree and reshaping the topology
Disabling unused ports	the empty meeting-room port that anyone can plug into

Remote access

Approach	How it works	The risk or the fit
Full-tunnel VPN	all device traffic is routed through your network	maximum control; costs capacity, and everything the user does appears to originate from you
Split-tunnel VPN	only internal destinations use the tunnel; everything else goes direct	cheaper and faster, but the device is simultaneously on an untrusted network and becomes a bridge into yours if compromised
Site-to-site VPN	two networks joined permanently	branch to head office, or cloud to office
Remote-access VPN	individual users connect on demand with credentials plus MFA	staff working from anywhere

Open-source options, named honestly: WireGuard is the modern default — small, fast and hard to misconfigure; OpenVPN where broad client compatibility matters; IPsec/IKEv2 for interoperability with other vendors' equipment. Whatever you choose, harden the choice itself: MFA, short-lived credentials, logging for every connection, and never a shared account. A VPN whose credential is a pre-shared key emailed to five people is not a control.

Never expose RDP (3389), SSH (22), VNC (5900) or a database port directly to the internet. Publish one of two things instead: a VPN, so the service is reachable only after authenticated network access; or, better for contractors and third parties, a zero-trust access proxy that authenticates and authorises per application with MFA and logs each session (Lesson 20 covers the identity side). If SSH from the internet is unavoidable, use keys only, no passwords, source restrictions where possible and rate limiting — and expect the log to fill with automated attempts immediately, which is itself a lesson in how exposed the internet is.

DNS, proxies and filtering

DNS is the cheapest high-value control you have, because almost every attack needs to resolve a name first.

Control	What it gives you	What it is not
Internal resolver for everyone	one place to apply policy and collect logs; bypass attempts using a public resolver are visible and can be blocked	not filtering by itself
Category and blocklist filtering	malware, phishing and unwanted domains blocked before the connection happens	not a substitute for endpoint protection, and bypassed by hard-coded IPs
DNSSEC	authenticity: proof the answer came from the real zone	not privacy — queries remain visible in transit
DoH / DoT	confidentiality: the query is encrypted, useful on untrusted networks	also hides your DNS from your own monitoring, so choose where you use it deliberately
DNS logging	one of the best detections available: a host querying a brand-new domain, or long encoded subdomains, is a signal	useless without retention and someone looking (Lesson 44)
Forward proxy with filtering	content control and per-user visibility for web traffic	sees nothing inside TLS without interception, with all the trade-offs above

Application allowlisting is the stronger alternative to content filtering: instead of trying to recognise every bad executable, permit only the software you have approved. It is operationally demanding, and for the handful of systems that matter most — domain controllers, payment terminals, industrial controllers — it is the control that most reliably stops an unknown payload.

Detection placement

Element	What it does	Where it belongs
NIDS (passive)	analyses copies of traffic and raises alerts; blocks nothing	on a switch span port or a network TAP, watching the zones that matter
NIPS (inline)	traffic passes through it, so it can drop	at the internet edge, where a false positive costs availability — tune before enabling blocking
Network TAP	a physical device copying all traffic on a link (more reliable than a span port under load)	the busy uplink between the firewall and the core switch
Host IDS / EDR	sees inside the host: processes, files, registry, memory	every endpoint and server — this is where most modern detection actually happens

Placement, in priority order for a small network: the internet edge (what is being attacked), between the user and server zones (what succeeded), and inside the server zone for east-west visibility (what is spreading). North-south monitoring tells you about attempts; east-west monitoring is where you catch intrusions, because a compromised workstation talking to a database server it has never touched is the signature of lateral movement.

Worked design: a small business, drawn as text

Internet
   │  inbound: nothing at all, except the VPN terminator on UDP 51820
   ▼
Firewall / router  (its own management interface reachable only from the management VLAN)
   ├── management VLAN  10.0.99.0/24   firewall, switch, hypervisor consoles, monitoring
   ├── user VLAN        10.0.10.0/24   workstations, phones, printers
   ├── server VLAN      10.0.20.0/24   web application, file server, database
   ├── guest / IoT VLAN 10.0.30.0/24   visitor devices, cameras, TVs — internet only
   └── IDS sensor on a switch span port, watching the edge and the server zone

Zone-to-zone rule	Policy
Internet to firewall	deny all inbound; allow only the VPN terminator
Users to servers	HTTPS (443) to the web application; SMB (445) to the file server only
Users to management	deny, without exception
Servers to users, and DMZ to servers	deny; DMZ reaches one specific service on one host
Servers to internet	allowlist only: package mirrors, backup destination, vendor APIs
Guest/IoT to anything internal	deny; internet access only
Management to everything	allow, restricted to management protocols, and logged in full

What this costs using open-source components — an OPNsense or nftables firewall, a managed switch with 802.1X and port security, Suricata or Zeek for the sensor, WireGuard for remote access, a filtering resolver — is a modest one-off hardware cost and your own time, with no licence fees at all. Lesson 34 names the full stack and its operating requirements.

Attack it / Defend it

The attack	How it works	The control that stops it
Port scan and service discovery	an attacker maps what is exposed	default deny inbound, no unnecessary published services, alert on sweeps
Exploiting an exposed management interface	RDP, SSH or a hypervisor console reachable from the internet	VPN or zero-trust proxy with MFA; management plane on its own network
Lateral movement inside a flat network	one compromised host reaches everything	segmentation, host firewalls, least-privilege rules between zones
ARP spoofing and man-in-the-middle	forged layer-2 replies redirect local traffic	Dynamic ARP Inspection, 802.1X, encryption
Rogue DHCP server	hands out a malicious gateway and resolver	DHCP snooping, port security
Unauthorised device on a wall port	a laptop or access point gets on the network	802.1X, port security, disabling unused ports
Command-and-control over HTTPS	a beacon blends with normal web traffic	egress allowlisting for servers, DNS and destination filtering, alerting on new domains
Data exfiltration	data leaves over an allowed outbound path	egress control plus flow logging and volume anomaly alerting
VPN credential abuse	a stolen VPN login gives network-level access	MFA on the VPN, short-lived credentials, per-session logging, no shared accounts
DNS tunnelling	data encoded into queries to an attacker-controlled domain	internal resolver with logging, blocking of encoded query patterns, egress restrictions

Key takeaways

Default deny in both directions, or your firewall is a suggestion. Outbound is the direction everyone forgets, and it is the direction the data takes.
Rules are assets with owners. If you cannot explain why a rule exists, it will outlive its reason and become free access for an attacker.
A VLAN without rules between it and the rest is not segmentation. Zones are a policy, not a naming exercise.
Do not publish RDP or SSH to the internet. Publish a VPN or a zero-trust access proxy with MFA, and log every session.
East-west monitoring is where you catch intrusions, because the boundary tells you about attempts and the internal network tells you about success.

Check yourself

Why is a stateful firewall insufficient to control which applications your users can reach, and what does a next-generation firewall add?
What are the two most serious costs of TLS interception, and what would you use instead for endpoint visibility?
A camera VLAN can reach your file server because the switch routes between them. Which two controls would you apply, and what is each one for?
Why is split-tunnel VPN a risk rather than a convenience, and what would you require of a device before allowing it?
In one sentence each: what does DNSSEC prove, and what does DNS-over-TLS protect?