Network Security Architecture

Design defense-in-depth network security. Covers zero trust networking, network segmentation, firewall policies, WAF configuration, DDoS protection, and network monitoring.

Network Security Architecture defines how traffic is classified, allowed, denied, and inspected as it moves through interconnected systems. It matters when you’re provisioning new subnet ranges, migrating to cloud or on-prem hybrid environments, deploying zero‑trust boundaries, or responding to lateral‑movement incidents. This page covers the practical mechanics of building, verifying, and troubleshooting a network security posture using standard tooling and generic configuration patterns. The focus is on data‑plane controls—firewalls, ACLs, routing filters, and flow‑logging—rather than application‑level code or vendor‑specific SDKs.

Define Zones and Segmentation

The first step in any network security architecture is partitioning address space into trust zones and applying implicit‑deny boundaries between them. Zones are typically expressed as VLANs, subnet prefixes, or cloud subnet groups, and each receives its own set of inbound and outbound rules.

A concrete way to model zones on a Linux host is with ip and nftables. The following creates a VLAN‑tagged interface and assigns it to a security zone:

# Create a VLAN interface on top of an physical link
ip link add link eth0 name eth0.100 type vlan id 100
ip addr add 10.0.10.1/24 dev eth0.100
ip link set dev eth0.100 up

# Attach the new zone to nftables for policy attachment
nft add table inet fw
nft add chain inet fw zone_internal { type filter hook input priority 0; policy accept; }
nft add rule inet fw zone_internal iif "eth0.100" ip saddr 10.0.10.0/24 accept

The iif (input interface) filter ensures that only traffic arriving on the designated zone interface is evaluated against its rule set. Traffic arriving on any other interface falls through to the default chain, which typically holds an implicit deny at the bottom.

A common confusion is treating zone membership as a static property of an IP address rather than as a property of the interface on which the packet arrives. An attacker who can spoof a source address within a subnet can bypass zone‑based filters if the upstream router does not enforce reverse‑path forwarding (uRPF). Verifying uRPF on the border router is a routine check:

# Enable strict uRPF on the external interface
sysctl -w net.ipv4.conf.eth1.rp_filter=2

If rp_filter is set to 2 (strict), the kernel drops packets whose source address cannot be routed out the interface on which they arrived. A silent failure occurs when rp_filter is 1 (loose) or 0 (disabled); the kernel accepts the packet, and the firewall may see a source address that does not match the expected zone.

Enforce Inbound and Outbound Policy

Once zones are defined, the next task is to write the actual permit/deny logic. The governing principle in nearly every packet‑filter implementation is that rules are evaluated top‑to‑bottom and the first match wins. An implicit deny (often called “catch‑all drop”) must be the final rule in every chain, or traffic will be permitted by default.

Using iptables as a concrete example, a typical inbound policy for a bastion host might look like this:

# Drop all inbound traffic by default (implicit deny at the chain foot)
iptables -P INPUT DROP

# Allow established and related connections (stateful inspection)
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow inbound HTTP and HTTPS from any source
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Allow SSH only from a management subnet
iptables -A INPUT -p tcp -s 10.0.20.0/24 --dport 22 -j ACCEPT

# Log and drop everything else (optional, for audit)
iptables -A INPUT -j LOG --log-prefix "iptables Dropped: "
iptables -A INPUT -j DROP

Key flags and their meanings:

A sharp edge that catches many newcomers is the interaction between -P INPUT DROP and the final LOG/DROP rules. If the policy is set to ACCEPT and a LOG/DROP rule is placed at the bottom, traffic that falls through will be logged *and* accepted, because the policy target overrides the rule’s DROP action. The correct pattern is either iptables -P INPUT DROP with no trailing accept, or iptables -P ACCEPT with an explicit DROP rule as the last entry. Mixing the two produces silent “allowed” traffic that should have been blocked.

Outbound policy follows the same ordering constraints. A typical outbound rule set on a workstation might allow DNS and NTP, then permit outbound TCP to approved destinations, and finally drop everything:

iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT          # DNS
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT        # NTP
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT        # HTTPS egress
iptables -A OUTPUT -j DROP                              # implicit deny

One frequently confused option is -j ACCEPT versus -j RETURN. In a user‑defined chain, ACCEPT stops evaluation and counts as accepted; RETURN exits the chain and resumes evaluation in the calling chain. Using RETURN when you meant ACCEPT can leave a rule “unreached” without an obvious error, especially in deep rule hierarchies.

Verify and Audit Traffic Flow

After rules are in place, verification is essential both during initial deployment and after any change. Several standard tools provide real‑time and snapshot views of the active rule set.

nft list ruleset dumps the entire nftables configuration, showing tables, chains, and rules with their current states:

$ nft list ruleset
table inet fw {
  chain input {
    type filter hook input priority 0; policy accept;
    iif "eth0.100" ip saddr 10.0.10.0/24 accept
  }
  chain forward {
    type filter hook forward priority 0; policy accept;
  }
  chain output {
    type filter hook output priority 0; policy accept;
  }
}

tcpdump is the de‑facto packet‑capture tool for observing what actually traverses an interface. A common audit pattern is to capture traffic on a specific zone interface and filter for rules that should or should not match:

# Capture inbound traffic on the internal zone, show only TCP packets to port 22
tcpdump -i eth0.100 -nn 'tcp and port 22'

If the rule iptables -A INPUT -p tcp --dport 22 -s 10.0.20.0/24 accept is active, only source addresses within 10.0.20.0/24 will appear in the capture. If no packets appear despite legitimate SSH attempts from that subnet, the issue is usually either a missing -s flag, a reversed source/destination in the rule, or an upstream device performing NAT that rewrites the source address.

systemctl status nftables (or systemctl status iptables) reports whether the firewall service is running, whether the backend kernel modules are loaded, and whether any startup errors prevented rule installation:

$ systemctl status nftables
● nftables.service - nftables firewall
     Loaded: loaded (/usr/lib/systemd/system/nftables.service; enabled; vendor preset: enabled)
     Active: active (exited) since Wed 2025-03-12 14:32:10 UTC; 2min ago
       Docs: man:nftables(8)

If the service is failed, the journal typically shows a message such as Job for nftables.service failed because the control process exited with error code. A frequent cause is a syntax error in /etc/nftables.conf, for example an unclosed brace or an unsupported expression. The exact text syntax error, unexpected INTEGER, expecting END'' from nft` indicates a parse failure before any rules are loaded.

Cloud‑native environments often replace iptables/nftables with security groups or network ACLs. The mechanics remain analogous: rules are ordered, first‑match wins, and an implicit deny is applied at the chain bottom. When hybrid environments host both host‑based firewalls and cloud security groups, a silent failure mode is rule conflict—host firewall permits what the cloud group denies, or vice‑versa. The only reliable way to detect this is to audit both rule sets independently and compare allowed port/protocol combinations.

Sharp Edges and Failure Modes

Rule ordering and “first‑match wins”

The most common operational surprise is re‑ordering rules without re‑evaluating downstream effects. Adding a broad rule (e.g., allow all UDP) after a specific rule (e.g., allow SSH from mgmt subnet) will never be reached if the specific rule already matches. Conversely, inserting a specific rule after a broad one effectively disables the broad rule for that subset. The discipline is to review the full rule chain after every edit, preferably with nft list ruleset or iptables-save.

MTU blackholes

Path MTU discovery (PMTUD) can silently drop packets when a middlebox blocks ICMP “fragmentation‑needed” messages. The result is TCP connections that hang, time out, or achieve dramatically reduced throughput. A diagnostic command:

# Probe MTU to a remote host, forcing the DF (don't fragment) flag
ping -M do -s 1472 <remote-host>

If the ping returns Frag needed and DF set with an MTU of 1480 or higher, the path is fragmenting or blocking PMTUD. Lowering the probe size incrementally (e.g., ping -M do -s 1460) will eventually yield successful replies, revealing the maximum transmittable unit. Network security architectures that rate‑limit ICMP or block type 3 code 4 (fragmentation‑needed) inadvertently create these blackholes.

DNS rebinding and split‑tunnel VPN leaks

When a VPN client routes only a subset of traffic (split‑tunnel), the remaining traffic exits the host’s default interface. If the host’s DNS resolver is configured to use an external resolver (e.g., 8.8.8.8) while the VPN tunnel terminates at an internal resolver, DNS queries for internal hostnames may leak outside the tunnel. The symptom is that a client can resolve internal-service.corp.example.com from the clearnet, bypassing intended access controls. The fix is to push DNS server addresses through the VPN tunnel and ensure the client uses the tunnel’s resolver for all lookups.

ARP spoofing on local segments

On switched Ethernet, ARP caches are trustful by default. An attacker who sends forged ARP Who-Has replies can redirect traffic intended for another host through their machine, enabling man‑in‑the‑middle inspection or denial‑of‑service. Defense patterns include static ARP entries for critical endpoints (arp -s 10.0.10.5 00:11:22:33:44:55) and enabling kernel hardening features such as net.ipv4.conf.all.arp_ignore and net.ipv4.conf.all.arp_announce, which restrict when the host will respond to ARP requests.

Conflicting host and cloud firewalls

In AWS, EC2 instances can have both a security group and a network ACL attached to the same subnet. Security groups are stateful and evaluate at the instance level; network ACLs are stateless and evaluate at the subnet level. A rule allowing inbound TCP 443 from 0.0.0.0/0 in a security group, combined with a network ACL denying inbound TCP from the same range, will result in the security group permit taking effect because security groups are evaluated first for the instance. The subtle failure is that the network ACL appears “ineffective,” leading operators to add redundant rules or mistakenly open broader access elsewhere. The remedy is to document the evaluation order per cloud provider and treat one layer as the primary enforcer, the other as defense‑in‑depth.

Silent rule deletion by cron or configuration management

Configuration management tools (e.g., Ansible, Puppet) sometimes push firewall rules via templates. If a previous run’s template omitted a rule that was present in the prior run, the rule disappears without an error message—iptables-save simply no longer contains it. A periodic audit script that captures iptables-save > /tmp/rules.before, applies the configuration management run, and diffs against a known‑good baseline is a lightweight safeguard against this class of drift.

Summary

Network Security Architecture is the layered practice of partitioning address space, ordering permit/deny rules, and validating that the resulting data‑plane behavior matches the intended policy. The mechanics—stateful vs. stateless filtering, implicit deny, rule ordering, MTU handling, and ARP trust—are portable across Linux iptables/nftables, BSD pf, and cloud‑native security groups. Concrete tooling (iptables, nft, tcpdump, systemctl) provides immediate visibility and control, while awareness of the sharp edges—rule ordering pitfalls, PMTUD blackholes, DNS split‑tunnel leaks, ARP spoofing, and cloud‑host firewall conflicts—prevents the silent failures that often go unnoticed until an incident unfolds. Regular audits, baseline diffs, and explicit documentation of evaluation order across all enforcement layers are the most reliable guards against configuration drift and mis‑aligned intent.

This page was rewritten on 16 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.