Earning my Linux Firewalls badge reinforced a critical lesson in system security: protecting a Linux system isn't about a single control — it's about layering firewalls, access control, patching, and monitoring into a cohesive defensive strategy.

This badge focused on understanding how Linux firewalls work under the hood, how modern stateful filtering improves security, and why firewall rules must be paired with system maintenance and logging to be effective in real-world environments.

From Stateless to Stateful Firewalls

Early Linux firewalls were stateless packet filters, meaning they inspected packets in isolation. While functional, stateless firewalls could be bypassed by manipulating TCP flags to make traffic appear legitimate.

Modern Linux firewalls are stateful, tracking active connections and allowing or denying packets based on:

  • Packet headers
  • Connection state
  • Expected traffic patterns

This shift significantly reduces attack surface and aligns Linux firewall behavior with enterprise security expectations.

What Linux Firewalls Can (and Can't) Control

Linux firewalls make decisions based on network attributes, not applications. Firewall rules commonly evaluate:

IP header fields

  • Source IP address
  • Destination IP address

TCP/UDP header fields

  • Source port
  • Destination port

Because Linux firewalls cannot filter traffic by process name, access is granted by port, not application. For example, allowing web traffic means permitting ports 80 and 443, regardless of which process uses them.

To achieve application-level control, Linux relies on Mandatory Access Control (MAC) frameworks such as:

  • SELinux
  • AppArmor

These tools allow granular policies, such as permitting only /usr/bin/apache2 to bind to ports 80 and 443, preventing unauthorized binaries from opening network services.

Netfilter: The Core of Linux Firewalling

At the kernel level, Linux firewalling is powered by netfilter, which provides packet filtering hooks inside the Linux kernel. Netfilter itself requires a user-space front-end to manage rules, most commonly:

  • iptables
  • nftables

iptables: Traditional but Foundational

iptables provides rule-based packet filtering using predefined chains:

  • INPUT — Incoming traffic to the system
  • OUTPUT — Outgoing traffic from the system
  • FORWARD — Traffic routed through the system

To allow SSH access:

iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT

To enforce a default-deny posture:

iptables -A INPUT -j DROP
iptables -A OUTPUT -j DROP

This approach follows a core security principle: explicitly allow what's required and deny everything else.

nftables: The Modern Successor

nftables, introduced in kernel 3.13, improves scalability, performance, and rule management over iptables.

Unlike iptables, nftables starts with no tables or chains, requiring explicit creation:

nft add table fwfilter
nft add chain fwfilter fwinput { type filter hook input priority 0 \; }
nft add chain fwfilter fwoutput { type filter hook output priority 0 \; }

SSH rules are then added cleanly and consistently:

nft add fwfilter fwinput tcp dport 22 accept
nft add fwfilter fwoutput tcp sport 22 accept

nftables represents the future of Linux firewall management and is increasingly preferred in modern distributions.

Security Goes Beyond Firewalls: Patch & Lifecycle Awareness

Firewall rules alone cannot protect unpatched systems.

  • End-of-life operating systems (e.g., Ubuntu 14.04) no longer receive security updates and represent a serious risk.
  • Enterprise distributions like Red Hat Enterprise Linux provide predictable, long-term support timelines.
  • Kernel updates matter — vulnerabilities like Dirty COW demonstrated how kernel flaws can lead to full root compromise.

Maintaining a secure Linux system means:

  • Tracking OS lifecycle status
  • Applying kernel and system updates
  • Automating updates where stability allows

Monitoring and Logs: Visibility Is Security

Security also depends on visibility. Linux logs provide critical insight into authentication attempts, system events, and kernel activity.

Key logs include:

  • /var/log/auth.log or /var/log/secure
  • /var/log/messages
  • /var/log/kern.log
  • /var/log/boot.log

Two essential commands:

tail -n 20 logfile
grep FAILED logfile

Being able to quickly inspect logs is a core skill for incident response and system troubleshooting.

Final Takeaway

This badge reinforced that Linux security is holistic:

  • Firewalls enforce network boundaries
  • MAC frameworks control processes
  • Updates eliminate known vulnerabilities
  • Logs provide detection and response capability

Understanding how these components work together is essential for building secure, maintainable Linux systems in production environments.