Data plane hardening — defaults, IDS/IPS posture, TLS inspection, and the ruleset

The data plane is where the user traffic flows. The rules that govern that traffic are the rules that determine what the firewall allows and blocks. A hardened data plane has rules that reflect the security policy, IDS/IPS that catches malicious payloads, TLS inspection that provides visibility into encrypted traffic, and state-table protections that prevent the firewall from being overwhelmed.

This lesson covers the data plane hardening checklist: default-deny posture, Suricata IDS/IPS tuning, TLS inspection trade-offs, state-table protections.

Default-deny posture

The default-deny posture is the discipline of blocking all traffic that is not explicitly allowed. The default-deny rule is the last rule in the ruleset; it blocks everything; every legitimate flow must match an earlier, more specific rule.

The default-deny posture is the foundation of a hardened data plane. Without it, every new service that is not explicitly blocked is implicitly allowed. The implicit-allow posture is what the operator who said “I did not block it, so it must be allowed” lives in; the implicit-allow posture is what the attacker who discovers an unblocked service exploits.

The control has three parts:

1. The default-deny rule at the bottom of every interface ruleset. The rule blocks all traffic that has not matched a previous rule.
2. Logging on the default-deny rule so the operator can see what is being blocked. Without logging, the default-deny is invisible; the operator cannot verify it is working.
3. Periodic review of the default-deny logs to identify traffic that should be explicitly allowed (and to identify potential reconnaissance).

The threats addressed: implicit-allow exploits (services that were never explicitly blocked), lateral movement (attacker uses an unblocked service to pivot), reconnaissance (attacker probes for open services).

The evidence produced: the default-deny rule in pfctl -s rules, the log entries showing what is being blocked, the periodic review report.

$ pfctl -s rules | grep -E '^block' | tail -5

block drop in on igb0 inet all
block drop in on igb1 inet all
block drop in on igb2 inet all
block drop in on igb3 inet all
block drop in on enc0 inet all

Suricata IDS/IPS

Suricata is the IDS/IPS OPNsense ships with. The IDS/IPS posture has three levels:

1. IDS only. Suricata inspects traffic and generates alerts, but does not block. The IDS posture is the starting point; the operator tunes rules to reduce false positives before considering IPS.
2. IPS in alert mode. Suricata inspects traffic and blocks matched signatures, but with the ability to fall back to IDS for specific rules. The IPS posture is the production posture after the IDS tuning is complete.
3. IPS in blocking mode. Suricata inspects and blocks all matched signatures. The strict posture; used when the rule set is well-tuned and the false-positive rate is low.

The hardening choice depends on the rule set. A rule set with many false positives (legacy Emerging Threats rules, broad category rules) is appropriate for IDS only. A rule set with low false positives (ET Open rules tuned over months, custom rules for the environment) is appropriate for IPS.

The threats addressed: known malicious payloads (signatures for malware, exploits, scanners), command-and-control traffic (signatures for known C2 protocols), lateral movement (signatures for known attack tools).

The evidence produced: Suricata alerts in the log, the alert rate (false positives vs true positives), the rule hit counts in Suricata’s stats.

TLS inspection trade-offs

TLS inspection is the discipline of terminating the TLS connection at the firewall, inspecting the unencrypted traffic, and re-encrypting for the destination. The firewall sees the application-layer data; IDS/IPS can match signatures against the unencrypted payload.

The trade-offs:

1. Visibility. TLS inspection provides visibility into encrypted traffic. Without it, the firewall sees only the TLS handshake (SNI, certificate) and cannot inspect the payload.
2. Privacy. TLS inspection sees the content of every TLS connection. The operator’s personal email, the HR system’s traffic, the user’s banking — all visible to the firewall.
3. Certificate trust. TLS inspection requires a trusted CA on every client. The CA signs the re-encrypted certificates; the clients must trust the CA. The CA itself is a high-value target.
4. Performance. TLS inspection adds latency and CPU load. The firewall terminates and re-encrypts every TLS connection; the CPU cost is non-trivial.
5. Compliance. Some compliance regimes (PCI-DSS, HIPAA) may require TLS inspection for traffic handling sensitive data. Other regimes (GDPR for personal data, attorney-client privilege) may restrict or forbid it.

The hardening choice depends on the environment. A firewall with no TLS inspection has no visibility into encrypted traffic; IDS/IPS sees only the metadata. A firewall with TLS inspection everywhere has visibility but the privacy and performance trade-offs.

The typical compromise: TLS inspection for traffic to/from the Internet (where most threats are); no inspection for traffic within the trusted internal network; explicit exception categories (banking, healthcare, legal) where inspection is disabled by policy.

The threats addressed: encrypted malware delivery, command-and-control over TLS, data exfiltration over TLS.

The evidence produced: the TLS inspection rules in the firewall configuration, the inspection logs, the certificate of the trusted CA.

State-table protection

The state table is the firewall’s record of every established connection. The state table has a finite size; a firewall under attack (SYN flood, connection flood) can fill the state table and refuse new connections.

The hardening controls:

1. State-table size limits. The operator sets the maximum state-table size (System → Settings → Firewall → Firewall Maximum States). The size is appropriate to the firewall’s memory and the expected traffic volume.
2. State-table timeouts. The operator tunes the timeouts for TCP, UDP, and ICMP states. Shorter timeouts free state-table entries faster; longer timeouts preserve state for legitimate long-lived flows.
3. Syncookie activation. Under SYN flood, the firewall enables syncookies (System → Settings → Firewall → Firewall Syncookies). Syncookies allow the firewall to handle SYN floods without filling the state table.
4. Per-rule state limits. Rules can have state limits — maximum states per source, per destination, per rule. A rule with a state limit caps the number of connections any single source can establish.

The threats addressed: SYN flood (attacker sends SYNs without completing handshakes), connection flood (attacker establishes many connections), state exhaustion (attacker fills the state table to deny service).

The evidence produced: the state-table size and utilisation, the syncookie activation logs, the per-rule state counts.

Summary

• Default-deny posture: block everything not explicitly allowed; log the default-deny; review the logs.
• Suricata IDS/IPS: start with IDS, tune to reduce false positives, then move to IPS. IPS in blocking mode requires a well-tuned rule set.
• TLS inspection trade-offs: visibility vs privacy, certificate trust, performance, compliance. The typical compromise is inspection for Internet-bound traffic, exception categories for sensitive flows.
• State-table protection: size limits, timeouts, syncookies, per-rule state limits.