What hardening a firewall actually means (we did ours first)

Most business firewalls are doing about a third of their job. They block inbound traffic, they hand out addresses, and then they sit on their factory defaults for five years. That is a locked front door on a house with the windows open.

We run opnsense at our own edge — the same open-source firewall we deploy for clients who don't need a full commercial appliance. Before we'll call any firewall “hardened,” it goes through the checklist we ran on ours. Here is what that actually involves.

Segment first, filter second

A flat network is the single biggest thing that turns a small compromise into a bad week. One machine gets popped and it can see everything: the server, the cameras, the till, the boss's laptop. So the first job is separation — voice on its own network, the general fleet on another, guests and BYOD walled off, and the gear nobody patches (the cameras, the printer, the smart TV) quarantined where it can reach the internet and nothing else. Only once the network is carved up does filtering between those segments start to mean something.

Default-deny, including outbound

Everyone blocks inbound. Far fewer control what leaves. We default-deny outbound and then allow what the business actually needs, because most modern malware phones home before it does damage — and a firewall that notices a till trying to reach an address in another hemisphere is a firewall earning its keep. It is more work to run this way. It is also the difference between catching something and reading about it later.

From detection to prevention: the IPS work

This is the big one, and it deserves more than a bullet point. Most edge firewalls ship with an intrusion detection system that watches traffic and raises alerts — but never actually stops anything. It is a smoke detector, not a sprinkler. Turning it into a true intrusion prevention system that drops malicious traffic inline is one of the highest-value hardening steps available, and also one of the easiest to get catastrophically wrong. Flip the wrong 200,000 rules to “block” and you will take down VoIP, break a line-of-business app, or lock yourself out of the firewall entirely.

So we do it methodically.

1. Assess the attack surface, and triage honestly

Before changing anything, we map what the internet can actually see and baseline the noise already hitting the perimeter. A critical skill here is triage discipline — not every scary-sounding alert is a real threat. In one recent assessment, an external scanner flagged a listening service with an alarming “backdoor” label. Investigation showed it was a benign router management endpoint (a standard TR-069 auto-configuration port), not a compromise at all. Chasing false flags wastes hours; missing a real one is worse. Knowing the difference is the job.

2. Move to inline IPS — with a fail-safe

We switch the Suricata engine from passive alert-only mode to inline prevention using netmap capture, so malicious packets are dropped rather than merely logged. Crucially, we scope inspection to the WAN interface only. That keeps the internal management path — admin GUI, SSH — outside the drop path, so even a badly-written rule can never lock the client or our team out of the firewall. Fail-safe by design.

3. Tier the rollout: measure before you block

This is the heart of the method. We never bulk-enable dropping.

• Tier 1 — block immediately. High-confidence, near-zero-false-positive threat intelligence: public reputation and indicator-of-compromise feeds (abuse.ch ThreatFox/URLhaus/Feodo, Spamhaus DROP, DShield, known botnet command-and-control and compromised-host lists), restricted to their highest-confidence entries. These are safe to drop on day one.
• Tiers 2 and 3 — observe first. Broader and higher-severity rulesets are staged in alert-only “observe” mode. They log exactly what they would have blocked, without blocking it. We then review a week of that data for hits against legitimate destinations — the would-be false positives — and only promote a ruleset to active blocking once it is proven clean. Anything that is not clean gets a surgical per-signature exception first.

Measure, review, then block. Every time.

4. Prove it actually works

An IPS you have not tested is an assumption, not a control. We validate live blocking with the industry-standard EICAR test string — a harmless file every security engine is built to recognise — confirming it is dropped inline in real time while identical control traffic passes cleanly. Proof, not hope.

5. Tune for correctness and performance

Two subtleties separate “IPS installed” from “IPS actually protecting you”:

• Network variable scoping. The firewall's definition of “home” versus “external” networks governs which rules can ever match. Get it wrong — by omitting IPv6, for example — and the vast majority of your rules become structurally inert: loaded, counted, and completely incapable of firing. We audit this explicitly, including full IPv6 coverage, so the ruleset you are paying for is the ruleset that is actually working.
• Engine performance and freshness. We select the pattern-matching engine and size CPU and memory so the IPS runs at full speed without exhausting a modest appliance, and we enforce nightly threat-feed updates. Reputation-based blocking is only as good as its most recent data; stale indicators protect no one.

6. Keep it reversible

Every change is reversible in seconds — a single toggle returns any policy to alert-only, and the full configuration is backed up before we touch it. Hardening should never be a one-way door.

The other parts nobody turns on

• Geo-blocking. If a business only trades in Australia, there is little reason to accept connections from networks on the far side of the world. Blocking whole regions cuts the background noise dramatically.
• DNS filtering. Resolving lookups through a filtered service stops a lot of phishing and malware at the name-lookup stage, before a connection is ever made.

Lock the management plane

The firewall's own admin interface is the crown jewels; reach that and the rest is academic. So the web UI never faces the internet, administration is restricted to a management network, logins are multi-factor, and the default accounts are gone on day one. We drive the configuration through the API, so changes are deliberate, repeatable and logged rather than clicked in ad hoc.

Watch it, or it didn't happen

A firewall that logs only to itself is one power-cycle away from amnesia. Ours ships its logs off-box to a central collector, so there is a record that outlives the device and a place to actually notice a pattern. A block you never look at is just a smaller kind of blind spot.

The outcome

The result is a firewall that has gone from a passive alarm to an active defence — dropping known-malicious traffic at the edge, validated end to end, tuned to the hardware, and fully reversible. No “we turned on IPS and broke production” horror story. Just a perimeter that finally does what most people already assume their firewall is doing.

None of this is exotic. It is the unglamorous work of doing the boring things properly, in an order that cannot bite you. We run it on our own edge because we would rather find the gaps on our own gear than on yours — and the same disciplined approach transfers straight to the commercial platforms built on the same engine. If your firewall has hummed along untouched since the day it went in, it is worth a look under the lid.