Firewalls and Network Defenses

The First Line of Perimeter Defense#

A firewall monitors and controls network traffic against a set of rules, forming a barrier between zones of different trust, classically a trusted internal network and the untrusted internet. Modern defence does not rely on a single firewall at the edge; it layers several types at different points and at different layers of the stack.

1. Packet Filtering (Stateless)#

The oldest type, operating at the network and transport layers (OSI layers 3 and 4). It examines each packet in isolation and allows or drops it based on source and destination IP, port, and protocol.

# Conceptual ruleset (evaluated top to bottom, first match wins)
ALLOW  tcp  any        -> 10.0.0.5:443     # inbound HTTPS to the web server
ALLOW  tcp  any        -> 10.0.0.5:80      # inbound HTTP (redirect to 443)
DENY   tcp  any        -> 10.0.0.0/24:22   # block SSH from the internet
DENY   any  any        -> any              # default deny everything else

Its weakness is in the name: being stateless, it cannot tell whether a packet belongs to a connection the inside started or is an unsolicited probe, which makes it weaker against spoofing and harder to write correctly for return traffic.

2. Stateful Inspection#

The standard for network boundaries today. It tracks the state of connections in a table. When an internal host opens a connection outward, the firewall records it; the return traffic is allowed automatically because it matches an established entry, while unsolicited inbound packets that match no connection are dropped. This makes "allow replies to what we started, block everything unrequested" a single natural rule instead of a fragile pair.

On Linux the modern implementation is nftables (successor to iptables); on cloud platforms the same job is done by security groups. A typical stateful rule keeps established connections and permits only chosen new inbound services:

# nftables: default-deny inbound, allow established replies and inbound HTTPS
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input tcp dport 443 accept
nft add rule inet filter input ct state new drop

ct state established,related accept is the line that makes it stateful: it accepts packets belonging to connections already tracked, so you never write explicit rules for return traffic.

3. Web Application Firewalls (WAF)#

Network firewalls guard ports and IPs; they cannot see inside HTTP. Port 443 is open by design, so a request carrying an injection payload passes a network firewall untouched. A WAF operates at layer 7, inspecting the HTTP request itself: headers, URL, parameters and body. It recognises attack signatures (SQL injection, XSS, path traversal) and blocks them before they reach the application.

Common WAFs include Cloudflare, AWS WAF, and the open-source ModSecurity engine (often with the OWASP Core Rule Set). WAFs also add rate limiting, bot filtering and geo-blocking.

4. Next-Generation Firewalls (NGFW)#

An NGFW combines stateful inspection with deep packet inspection, an integrated intrusion prevention system (IPS), TLS inspection, and application awareness. It can identify and control specific applications regardless of port (allow a chat app, block file-sharing traffic even if it hops ports) and pull in threat-intelligence feeds. It is the typical enterprise perimeter device.

Network Segmentation#

Firewalls belong between internal zones, not only at the edge. Good architecture puts internet-facing servers in a DMZ, application servers in one internal subnet, and databases in a tightly restricted subnet reachable only by the app tier. If an attacker breaches the web server, an internal firewall stops them pivoting straight to the database. This is the network-level expression of least privilege and a building block of zero trust, where no host is trusted merely for being "inside."

Rule Hygiene: Where Firewalls Actually Fail#

A firewall is only as good as its ruleset, and rulesets rot. Three habits keep them effective:

• Default deny. The final rule must drop everything not explicitly allowed. A rulebase that only lists what to block silently permits every new service and every new attack. Whitelist the few things allowed; deny the rest.
• Order and logging. Most firewalls stop at the first matching rule, so specific allow-rules go first and the catch-all deny last. Log denies (and the sensitive allows) because those logs are your forensic feed for incident response and feed detection systems.
• Periodic review. Prune rules left over from decommissioned services, collapse overlapping ranges, and be able to justify every remaining rule with "which service, which hosts, why." A rule nobody can explain is usually a hole. Overly broad rules (0.0.0.0/0 to a database port, ANY-ANY allows) are the classic misconfiguration a scan will flag.

IDS and IPS: Detecting What Gets Through#

Firewalls decide what may pass; they do not deeply analyse what a permitted connection is doing. That is the job of an intrusion detection system (IDS) and intrusion prevention system (IPS). An IDS inspects traffic and raises an alert when it matches a known attack signature or an anomalous pattern; an IPS sits inline and can actively drop the offending traffic. Open-source engines like Snort, Suricata and Zeek are widely deployed, often feeding their alerts into a central detection pipeline. The trade-off is tuning: too sensitive and analysts drown in false positives; too lax and real attacks slip by. In practice an IPS handles high-confidence, well-known signatures automatically while lower-confidence anomalies become alerts a human triages. Think of the firewall as the gate, the IDS/IPS as the guard watching how visitors behave once inside.

The WAF Blind Spot#

A WAF sees the request, not your application's state or business logic. It can block a known SQL-injection string, but it cannot tell that a perfectly well-formed request is abusing a coupon code, replaying someone else's object id (IDOR), or exploiting a business logic flaw. Treat the WAF as a tripwire and a source of visibility, never as a substitute for fixing the code. Every WAF rule that blocks injection should be paired with the parameterized-query fix in the application. The division of labour is clean: firewalls control where traffic may go, application controls decide what an authenticated user may do.

Host and Cloud Firewalls#

Perimeter defence is not enough; every host needs its own firewall too. That means the OS firewall (Windows Defender Firewall, nftables), and in cloud and container environments, security groups and network policies. A well-segmented cloud deployment lets the web tier reach only the specific API it needs, and the API reach only the database, with everything else denied, regardless of how many public IPs exist in between. Kubernetes NetworkPolicy objects apply the same idea between pods. Combined with the segmentation above, this ensures a single compromised component cannot freely talk to the rest of the estate.

Checklist#

• Every firewall ends in an explicit default-deny rule.
• Inbound is closed except for the specific services that must be public.
• Internal tiers (web, app, database) are segmented, not flat.
• Rules are logged and reviewed on a schedule; stale and overly broad rules are removed.
• A WAF protects public web apps but is backed by fixes in the application code.
• Host-level and cloud security-group firewalls are configured, not just the perimeter.