The firewall is still the first line of perimeter defence for any infrastructure connected to the internet, but its role has changed profoundly. A packet filter that decides on the basis of IP address and port is no longer enough: today's attack surface demands stateful inspection, layer-7 application control, denial-of-service protection and a zero-trust model. In this technical guide we explain how to design robust ingress and egress rules, when to add a WAF and how to orchestrate DDoS mitigation without choking off legitimate traffic.
Firewall types and the filtering stack
A firewall operates at one or several layers of the OSI model, and understanding which one protects what prevents redundant configurations or, worse, silent gaps. Stateless packet filtering (layers 3 and 4) decides solely on the basis of IP/TCP/UDP headers; it is fast but blind to the connection context. The stateful firewall keeps a connection table (conntrack on Linux) and only admits packets belonging to established or related sessions, which neutralises most trivial spoofing.
Above that we find the next-generation firewall (NGFW), which adds deep packet inspection (DPI), port-independent application identification and, often, integrated IPS. Finally, the Web Application Firewall (WAF) works exclusively at layer 7 over HTTP/HTTPS and understands request parameters, headers and bodies. A common mistake is to expect an NGFW to stop a SQL injection: the traffic travels encrypted in TLS and, without termination or decryption, the NGFW only sees an opaque stream. That job belongs to the WAF.
Designing ingress rules: default-deny policy
The golden rule is default deny: anything not explicitly permitted is blocked. In practice this means closing the INPUT chain and opening only what is essential. A typical skeleton with nftables would be:
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
ct state established,related accept
iif "lo" accept
ct state invalid drop
tcp dport 22 ip saddr 203.0.113.0/24 accept # SSH only from the corporate VPN
tcp dport { 80, 443 } accept # public web traffic
ip protocol icmp icmp type echo-request limit rate 5/second accept
}
}Three principles underpin this configuration. First, least privilege: SSH is not exposed to 0.0.0.0/0 but to the VPN range. Second, order of evaluation: rules are evaluated sequentially, so the most frequent ones (established connections) go at the top to reduce CPU cost. Third, rate limiting on ICMP and new SYN packets to cushion sweeps and floods. Documenting each rule with its business justification is what separates a maintainable policy from a tangle nobody dares to touch two years later.
Egress filtering: the control almost nobody configures
Most organisations filter inbound traffic and leave the outbound direction completely open. This is a serious failing: egress filtering is what cuts the chain of an attack already in progress. A compromised server needs to communicate with its command-and-control (C2) server, exfiltrate data or download the second stage of the malware; if outbound traffic is restricted to legitimate destinations and ports, the attacker is contained.
A reasonable egress policy for an application server allows DNS only towards internal resolvers, HTTPS towards the package repository and the cloud provider's API, and NTP towards authorised sources; everything else is dropped and logged. Blocking outbound connections to ports such as 6667 (IRC, a botnet classic) or unexpected TCP/53 traffic reveals DNS tunnelling. Egress filtering also helps satisfy the minimisation principle of the ISO/IEC 27001 standard in its communications security control (A.8.20 and following in Annex A of the 2022 revision).
WAF: protecting the application layer
The WAF inspects every HTTP request against a set of rules. The de facto standard in the open-source world is the OWASP Core Rule Set (CRS), maintained by the OWASP Foundation, which covers the categories of the OWASP Top 10: injection, cross-site scripting, insecure deserialisation and so on. The CRS works on an anomaly-scoring model: each match adds points and, once a threshold is exceeded, the request is blocked. This reduces false positives compared with rule-by-rule blocking.
Deploying a WAF should always go through a detection mode phase (low paranoia level, log only) before enabling blocking. Switching the CRS on directly in production at paranoia level 4 guarantees support tickets on day one, because legitimate requests with special characters are rejected. The correct flow is: deploy in detection, collect a week of real traffic, fine-tune exclusions per endpoint, and only then move to progressive blocking by raising the paranoia level.
Layered DDoS mitigation
A firewall on its own does not stop a volumetric attack that saturates the link before it ever reaches your rule. DDoS defence is organised by the layer under attack. Volumetric attacks (UDP flood, NTP/DNS/memcached amplification) are mitigated upstream, at the provider or in a scrubbing service with absorption capacity measured in Tbps. Protocol attacks (SYN flood, Ping of Death) are contained with SYN cookies, per-source connection limits and the firewall's own state table. Application-layer attacks (HTTP flood, Slowloris) require the WAF, per-session rate limiting and JavaScript challenges or CAPTCHA.
INCIBE recommends combining distributed protection at the edge with documented response plans, because no single defence covers the full spectrum. An effective pattern is to declare rate thresholds: for example, a maximum of 100 new connections per second per IP, with automatic escalation to challenge mode when they are exceeded.
Network segmentation and the zero-trust model
The traditional perimeter, where everything inside was considered trusted and everything outside was not, has died with the hybrid cloud and remote work. The Zero Trust model starts from a different principle: never trust, always verify. Every request, wherever it comes from, is authenticated and authorised as if it came from a hostile network. The firewall remains a key piece, but its logic changes: it stops protecting a single perimeter and starts enforcing microsegmentation between workloads.
Microsegmentation divides the network into small zones with strict policies between them. A web server in the demilitarised zone (DMZ) can talk to the application server on port 8080, but not directly to the database; only the application server reaches the database on port 5432. If the web server is compromised, the attacker cannot jump laterally to the database because the east-west rule prevents it. This defence against lateral movement is what limits the reach of an intrusion, and it is one of the pillars set out in the NIST cybersecurity framework and the controls of the ISO/IEC 27000 family on network segregation.
Implementing microsegmentation with a host firewall (nftables, the Windows Filtering Platform) or with network policies in container orchestrators makes it possible to apply the least-privilege rule at the process level, not just the subnet level. The cost is operational complexity: maintaining hundreds of east-west rules demands automation and infrastructure as code so that the policy is versioned, reviewable and reproducible.
Logging, correlation and response
A firewall without logging is a guard who takes no notes. Every relevant decision—especially the drops—must be sent to a centralised security event management system (SIEM), where it is correlated with other sources. A single blocked connection attempt means nothing; a hundred attempts from the same IP to a hundred different ports in one minute is a port scan that warrants an alert. Correlation is what turns noise into actionable intelligence.
Logs must include an NTP-synchronised timestamp, source and destination IP, port, protocol, rule applied and action. To meet traceability and evidence-retention obligations, it is advisable to define a retention policy consistent with legal requirements and with INCIBE's guidance on incident management. Integrating the firewall with the SIEM closes the loop: detection, alert and, in mature architectures, automated response that dynamically updates the rules to block an offending IP during an attack in progress.
Comparison table: where each control acts
| Control | OSI layer | Stops | Does not stop |
|---|---|---|---|
| Packet filter | 3-4 | Unauthorised IP/port | Application attacks |
| Stateful firewall | 3-4 | Out-of-session packets, spoofing | Valid malicious payloads |
| NGFW / IPS | 3-7 | Known signatures, unwanted apps | Encrypted traffic without termination |
| WAF | 7 | Injection, XSS, HTTP flood | Volumetric network attacks |
| Upstream scrubbing | 3-4 | Volumetric DDoS (Tbps) | Business logic |
Common configuration mistakes
The first is the temporary "allow all" rule that stays forever: a diagnostic entry that opens a port to 0.0.0.0/0 and nobody reverts. The second is relying solely on the source IP to authenticate, ignoring that it can be spoofed or come from a proxy. The third is not logging the drops: without logs of the drop rules it is impossible to investigate an incident. The fourth is the WAF in permanent monitor mode that detects but never blocks. And the fifth is leaving the management plane (the firewall's administration interface) accessible from the internet instead of on an isolated management network.
Frequently asked questions
Does a stateful firewall replace a WAF? No. They operate at different layers. The stateful firewall validates that the connection is legitimate at the network and transport level; the WAF analyses the HTTP content. A SQL injection travels inside a perfectly valid TCP connection, so the stateful firewall lets it through and only the WAF stops it.
Do I need to filter outbound traffic if I already filter inbound? Yes, they are different objectives. Ingress prevents intrusions; egress contains an already-compromised host and prevents exfiltration and communication with C2 servers. It is a common requirement in ISO/IEC 27001 audits and compliance frameworks.
Is it worth terminating TLS at the firewall to inspect it? It depends. Termination lets the WAF see the content, but it introduces a point where the traffic travels decrypted and forces you to manage certificates rigorously. In environments with personal data you must weigh the impact against the GDPR and document the processing.
How often should rules be reviewed? At least quarterly, and always after architecture changes. Reviews detect obsolete rules, overlaps and overly broad permissions that accumulate over time.
Conclusion
Configuring a firewall today is not about writing a list of open ports, but about orchestrating a layered defence where each control does what it does best: the stateful firewall validates the session, egress filtering contains the leak, the WAF protects the application and upstream scrubbing absorbs the volume. The factor that decides the outcome is not the technology but operational discipline: a default-deny policy, exhaustive logging of drops, deploying the WAF in detection before blocking, and periodic reviews that prune dead rules. A well-governed firewall is transparent to the legitimate user and an impassable wall for everyone else. At Summum Marketing we design and deploy these policies tailored to each architecture, always measuring the impact on real traffic before moving to production.