Chapter 5: Configuring Firewalls: Rules Across Operating Systems

Introduction to Firewall Rule Configuration

Welcome back, future network guardian! In our previous chapters, we laid the foundational bricks of what firewalls are, why they’re indispensable, and the core concepts that govern their operation. You’ve grasped the “why” and the “what.” Now, it’s time to roll up your sleeves and dive into the “how.”

This chapter is your hands-on guide to configuring firewall rules across the most common operating systems: Linux, Windows, and macOS. We’ll explore the specific tools and commands each OS uses, breaking down the process into easy-to-follow, baby steps. Our goal isn’t just to show you commands, but to instill a deep understanding of why each rule is crafted the way it is, enabling you to secure any system effectively.

By the end of this chapter, you’ll be able to confidently define, implement, and troubleshoot firewall rules, transforming your systems from open doors to fortified castles. Let’s get started!

Core Concepts: The Anatomy of a Firewall Rule

Before we touch any command line, let’s solidify our understanding of what makes a firewall rule tick. Think of a firewall as a bouncer at a club, and each rule is a specific instruction for that bouncer.

The Five-Tuple and Action

At its heart, a firewall rule typically evaluates incoming or outgoing network traffic based on a “five-tuple” of information:

Source IP Address: Where the traffic is coming from.
Destination IP Address: Where the traffic is trying to go to.
Source Port: The port number on the sender’s side.
Destination Port: The port number on the receiver’s side (e.g., 80 for HTTP, 443 for HTTPS, 22 for SSH).
Protocol: The communication language (e.g., TCP, UDP, ICMP).

Based on whether a packet matches these criteria, the firewall then takes an action:

ALLOW (or ACCEPT): Let the traffic pass through.
DENY (or DROP): Discard the traffic silently, no response.
REJECT: Discard the traffic and send an error message back to the sender (e.g., “destination unreachable”). This is often used for services you expect to be available but are currently blocked, making debugging easier.

Rule Processing Order: The Golden Rule

Firewall rules are almost always processed in order, from top to bottom. The first rule that a packet matches dictates the action taken, and no further rules are evaluated for that packet.

This is critical: a broad ALLOW rule placed too high can inadvertently permit traffic that a more specific DENY rule further down was intended to block. Conversely, a broad DENY rule can block legitimate traffic before an ALLOW rule has a chance to permit it.

Think about it: If you have a rule that says “Deny all traffic from the internet” and then below it, “Allow SSH from your home IP,” which rule would apply to SSH traffic from your home IP? If the “Deny all” rule is first, your SSH traffic would be blocked! The order matters.

Here’s a visual representation of how rules are typically processed:

flowchart TD A["Packet Arrives/Departs"] --> B{"Matches Rule 1?"} B -- "Yes" --> C["Apply Action of Rule 1"] B -- "No" --> D{"Matches Rule 2?"} D -- "Yes" --> E["Apply Action of Rule 2"] D -- "No" --> F{"... Continue to next rule ..."} F -- "No Match for Any Rule" --> G["Apply Default Policy (Implicit Deny/Allow)"] G --> H["Packet Processed"]

Default Policies: The Safety Net

Every firewall has a default policy for each chain (e.g., INPUT, OUTPUT, FORWARD in Linux). This policy is applied to any traffic that doesn’t match an explicit rule. The most secure default policy is “Implicit Deny” (or DROP in Linux). This means if you don’t explicitly allow something, it’s blocked. This “deny all, allow specific” approach is a cornerstone of robust cybersecurity.

Now that we understand the core logic, let’s explore how to apply these concepts across different operating systems.

Step-by-Step Implementation: Configuring Firewalls

We’ll tackle Linux first, focusing on nftables, the modern standard, then move to Windows and macOS.

1. Linux Firewalls: `nftables` (and a nod to `iptables`)

For many years, iptables was the go-to firewall utility on Linux. However, nftables has emerged as its successor, offering a more flexible, efficient, and unified packet filtering framework. As of 2025, nftables is the default firewall backend for most major Linux distributions.

Version Check: We’ll be working with nftables (typically nftables 1.0.0 or later, depending on your distribution’s package versions).

Getting Started with `nftables`

First, ensure nftables is installed and running.

Check nftables service status:
```
sudo systemctl status nftables
```
If it’s not active, you might need to install it (sudo apt install nftables on Debian/Ubuntu, sudo dnf install nftables on Fedora/RHEL) and then enable/start it:
```
sudo systemctl enable nftables
sudo systemctl start nftables
```
View the current ruleset: The nft command is your primary interface.
```
sudo nft list ruleset
```
This command outputs the entire active nftables ruleset, which can look complex initially. Don’t worry, we’ll build it up.

Building `nftables` Rules Incrementally

nftables uses a hierarchical structure: tables contain chains, and chains contain rules.

Tables: Act as containers for chains. Common types are ip, ip6, inet (for both IPv4 and IPv6), arp, and bridge.
Chains: Define specific points in the packet processing path. Key chains are:
- input: For packets destined for the local system.
- output: For packets originating from the local system.
- forward: For packets passing through the system (acting as a router).
Rules: The individual instructions within a chain.

Let’s create a simple inet table and a basic input chain with a default drop policy. An inet table works for both IPv4 and IPv6, which is a modern best practice.

Start with an empty ruleset (CAUTION! This will flush all existing rules):
```
sudo nft flush ruleset
```
Warning: Running sudo nft flush ruleset will immediately remove all active firewall rules. If you’re connected via SSH, you will likely lose your connection unless you have a mechanism to re-add an allow rule for SSH quickly. It’s highly recommended to perform this in a virtual machine or a console session first.
Add a new inet table named filter:
```
sudo nft add table inet filter
```
- add table: The command to create a new table.
- inet: Specifies this table handles both IPv4 and IPv6 traffic.
- filter: The name of our table. You can choose any descriptive name.
Add an input chain to our filter table with a default drop policy:
```
sudo nft add chain inet filter input { type filter hook input priority 0; policy drop; }
```
- add chain: Creates a new chain.
- inet filter: Specifies the table this chain belongs to.
- input: The name of our chain.
- type filter: Defines this as a filtering chain.
- hook input: Attaches this chain to the “input” hook, meaning it processes incoming packets destined for the local system.
- priority 0: Determines the order in which chains are processed if multiple chains are attached to the same hook. Lower numbers mean higher priority.
- policy drop: Sets the default action for this chain to drop. Any packet not explicitly allowed will be discarded.
Now, if you run sudo nft list ruleset, you’ll see your new table and chain. Everything is blocked!
Add a rule to allow SSH (port 22) from your current IP address (replace YOUR_IP_ADDRESS):
```
sudo nft add rule inet filter input ip saddr YOUR_IP_ADDRESS tcp dport 22 accept
```
- add rule: Adds a new rule.
- inet filter input: Specifies the table and chain to add the rule to.
- ip saddr YOUR_IP_ADDRESS: Matches packets where the source IP address is YOUR_IP_ADDRESS.
- tcp dport 22: Matches TCP packets destined for port 22.
- accept: The action to take if the packet matches.
Self-Correction: If you’re using SSH and flushed your ruleset, you must add this rule immediately after flushing and before setting the drop policy, or ensure the SSH rule is added first if you are building on top of existing rules. A safer way to add rules without losing connection is to use insert rule at a specific position.
Allow established/related connections (crucial for normal browsing): This rule permits traffic that is part of an already established connection (like a web page you’re viewing) or related to an existing connection (like an FTP data transfer).
```
sudo nft add rule inet filter input ct state established,related accept
```
- ct state established,related: Matches packets belonging to established or related connections. This relies on nftables’s connection tracking.
Allow loopback traffic (for local applications to communicate):
```
sudo nft add rule inet filter input iif lo accept
```
- iif lo: Matches packets coming in through the loopback interface (lo).
Making nftables Rules Persistent: Rules added with nft add rule are volatile and will disappear after a reboot. To make them persistent, you need to save them.
```
sudo nft list ruleset > /etc/nftables.conf
```
Then, ensure the nftables service is configured to load this file on startup:
```
sudo systemctl enable nftables
```
The nftables service typically loads /etc/nftables.conf by default.

Simplified Management with `UFW` (Ubuntu/Debian)

For users on Ubuntu or Debian-based systems, UFW (Uncomplicated Firewall) provides a much simpler command-line interface to manage nftables (or iptables in older versions). It’s great for desktop and basic server configurations.

Check UFW status:
```
sudo ufw status verbose
```

Enable UFW (CAUTION: ensure SSH is allowed first if remote):

sudo ufw allow ssh  # Allows SSH on port 22
sudo ufw enable     # Activates the firewall with default deny policy

Add a rule to allow HTTP (port 80):
```
sudo ufw allow http
```
Or by port number:
```
sudo ufw allow 80/tcp
```
Delete a rule:
```
sudo ufw delete allow http
```
UFW rules are persistent by default.

2. Windows Firewalls: Windows Defender Firewall with Advanced Security

Windows has a powerful built-in firewall, “Windows Defender Firewall with Advanced Security.” It can be managed via a graphical user interface (GUI), netsh advfirewall commands, or, for modern scripting, PowerShell cmdlets. As of 2025, PowerShell is the preferred method for automation.

Version Check: We’re using Windows Defender Firewall, which is integrated into Windows 10/11 and Windows Server 2016+. PowerShell 5.1+ is standard.

Managing Windows Firewall via PowerShell

PowerShell offers robust control over the firewall.

Open PowerShell as Administrator: Right-click the Start button, then select “Windows PowerShell (Admin)” or “Windows Terminal (Admin)”.
View existing firewall rules:
```
Get-NetFirewallRule | Format-Table Name, Enabled, Direction, Action, Profile -AutoSize
```
This command lists all firewall rules, showing their name, whether they’re enabled, their direction (inbound/outbound), action (allow/block), and active profile (Domain, Private, Public).
Create a new inbound rule to allow a custom port (e.g., TCP port 8080):
```
New-NetFirewallRule -DisplayName "Allow Custom App Port 8080" `
                    -Direction Inbound `
                    -Action Allow `
                    -Protocol TCP `
                    -LocalPort 8080 `
                    -Profile Any `
                    -Enabled True
```
- New-NetFirewallRule: The cmdlet to create a new rule.
- -DisplayName: A human-readable name for the rule.
- -Direction Inbound: Specifies the rule applies to incoming traffic. Use Outbound for outgoing.
- -Action Allow: Permits the traffic. Use Block to deny.
- -Protocol TCP: Specifies the TCP protocol. Can be UDP, ICMPv4, Any.
- -LocalPort 8080: The destination port on the local machine. Use -RemotePort for the source port.
- -Profile Any: Applies the rule to all network profiles (Domain, Private, Public). You can specify one or more.
- -Enabled True: Activates the rule immediately.

Create a new outbound rule to block a specific application from accessing the internet: Let’s say you want to block notepad.exe (just for demonstration, you’d pick a real application).

New-NetFirewallRule -DisplayName "Block Notepad Outbound" `
                    -Direction Outbound `
                    -Action Block `
                    -Program "%SystemRoot%\system32\notepad.exe" `
                    -Profile Any `
                    -Enabled True

-Program: Specifies the full path to the executable.

Modify an existing rule (e.g., disable the rule we just created):

Set-NetFirewallRule -DisplayName "Block Notepad Outbound" -Enabled False

Delete a rule:
```
Remove-NetFirewallRule -DisplayName "Block Notepad Outbound"
```
Windows firewall rules created this way are persistent by default.

3. macOS Firewalls: Application Firewall and `pf`

macOS provides two layers of firewall:

Application Firewall: User-friendly, GUI-based, controls network access for specific applications.
pf (Packet Filter): A powerful, low-level firewall inherited from OpenBSD, primarily managed via the command line for advanced network configurations.

Version Check: macOS Ventura (13.x) and Sonoma (14.x) are current. The Application Firewall is standard. pf versions align with the underlying BSD kernel.

Managing the macOS Application Firewall (GUI)

This is the most common way macOS users interact with their firewall.

Access Firewall Settings:
- Go to System Settings (or System Preferences on older macOS).
- Navigate to Network > Firewall.
- Click Turn On Firewall if it’s off.
- Click Options... to configure application-specific rules.
Configure Application Rules:
- In the Firewall Options, you’ll see a list of applications.
- You can click the + button to add an application not on the list.
- For each application, you can choose to Allow incoming connections or Block incoming connections.
- There’s also an option to “Automatically allow built-in software to receive incoming connections” and “Automatically allow downloaded signed software to receive incoming connections.” These are usually enabled for convenience but can be disabled for stricter security.

Managing macOS `pf` (Packet Filter)

pf is much more complex and powerful, typically used for server configurations, advanced routing, or specific network appliance roles. It’s configured via a configuration file (/etc/pf.conf) and managed with the pfctl command. For most end-users, the Application Firewall is sufficient.

Warning: Misconfiguring pf can easily lock you out of your system or disrupt network connectivity. Proceed with extreme caution and ideally in a test environment.

Check pf status:
```
sudo pfctl -s info
sudo pfctl -sr # Show rules
```
By default, pf is usually disabled or has a minimal ruleset on client macOS installations.
Example: Basic pf rule to block all inbound traffic (for demonstration, do NOT run on a live system unless you know how to revert): First, create a temporary pf.conf file.
```
echo "block all" > ~/temp_pf.conf
```
Then, load it (this will likely cut off your network connection):
```
sudo pfctl -f ~/temp_pf.conf
sudo pfctl -e # Enable pf
```
To disable and flush:
```
sudo pfctl -d
sudo pfctl -F all
```
Best Practice: When using pf, always test your rules with sudo pfctl -n -f /path/to/pf.conf first. The -n flag checks the syntax without loading the rules.

Mini-Challenge: Fortify Your Test Machine!

It’s your turn to apply what you’ve learned! Pick one of your test virtual machines (Linux or Windows) and implement the following:

Challenge:

Block all inbound traffic to your test machine by default.
Allow inbound SSH (port 22) from only your current workstation’s IP address.
Allow inbound HTTP (port 80) and HTTPS (port 443) from any IP address.
Verify that you can SSH from your workstation, access a web server (if installed) on ports 80/443, but cannot ping the machine from another arbitrary IP.

Hint:

Remember the default policy. Start with a DROP or Block policy.
For Linux nftables, you’ll need add table, add chain with policy drop, and then add rule commands for SSH, HTTP, and HTTPS. Don’t forget ct state established,related accept and iif lo accept rules!
For Windows PowerShell, use New-NetFirewallRule with -Direction Inbound and -Action Allow or Block. You might need to disable existing broad Allow rules if they interfere.

What to Observe/Learn:

How the order of rules impacts connectivity.
The difference between Allow and Block actions.
The importance of specific source/destination configurations.
The crucial role of “established,related” rules for stateful firewalls.

Common Pitfalls & Troubleshooting

Even the most experienced administrators trip up with firewalls. Here are common issues and how to approach them:

Blocking Yourself Out (The “Oops” Moment):
- Pitfall: Applying a deny all rule or a specific deny rule that affects your current administrative connection (e.g., SSH, RDP) without an explicit allow rule for it first.
- Troubleshooting:
  - Always test rules in a console session or with a “break glass” recovery plan (e.g., an out-of-band management interface).
  - On Linux, if you lose SSH, you might need to access the VM console or reboot into a rescue mode to edit nftables.conf or ufw rules.
  - On Windows, if you lose RDP, you may need physical access or use cloud provider console access.
  - Always add allow rules for administrative access before implementing broad deny policies.
Rule Order Confusion:
- Pitfall: Placing a broad ALLOW rule before a specific DENY rule, or vice-versa, leading to unintended traffic flow.
- Troubleshooting:
  - Remember: “First rule matched wins.”
  - Review your ruleset from top to bottom.
  - Generally, place more specific DENY rules higher, and more specific ALLOW rules higher than broad ALLOW rules. The default DENY is always at the very end.
  - Use sudo nft list ruleset -n (Linux) or Get-NetFirewallRule (Windows) to review the exact order and details.
Forgetting Persistence:
- Pitfall: Adding rules with nft add rule (Linux) or netsh (Windows, though less common now) and forgetting to save them, causing them to disappear after a reboot.
- Troubleshooting:
  - For nftables, ensure you save your rules to /etc/nftables.conf and systemctl enable nftables.
  - UFW and PowerShell New-NetFirewallRule commands are persistent by default.
Misunderstanding Chains/Profiles (Linux/Windows):
- Pitfall: Applying a rule to the wrong chain (INPUT vs. OUTPUT vs. FORWARD in Linux) or the wrong network profile (Domain, Private, Public in Windows).
- Troubleshooting:
  - INPUT (Linux): Traffic to the firewall host.
  - OUTPUT (Linux): Traffic from the firewall host.
  - FORWARD (Linux): Traffic through the firewall host (if it’s routing).
  - Windows Profiles: Ensure your rule applies to the active network profile. If your laptop is on a public Wi-Fi, the “Public” profile is active. If at home, “Private.” If on a company network, “Domain.” Using -Profile Any is often safest for general rules but less secure.

Summary

Phew! You’ve just taken a massive leap in your cybersecurity journey by learning to configure firewalls across different operating systems. Here are the key takeaways:

Firewall rules are based on a “five-tuple” (source/destination IP, source/destination port, protocol) and an action (allow, deny, reject).
Rule order is paramount: The first matching rule dictates the action. More specific rules should generally precede broader ones.
Default policies (often “Implicit Deny”) are critical for security, blocking anything not explicitly allowed.
Linux uses nftables (modern) or iptables (legacy), managed via the nft command. UFW provides a simpler interface for Debian/Ubuntu.
Windows uses Windows Defender Firewall, best managed programmatically with PowerShell New-NetFirewallRule cmdlets.
macOS offers an Application Firewall (GUI) for user-friendly control and pf (Packet Filter) for advanced, command-line configurations.
Troubleshooting often involves checking rule order, persistence, and ensuring rules apply to the correct traffic direction or network profile.

You now possess the practical skills to configure fundamental firewall rules, a cornerstone of network security. But firewalls are just one piece of the puzzle. Next, we’ll dive into the fascinating world of DNS (Domain Name System), understanding how it translates human-readable names into machine-readable IP addresses, and its critical role in network communication and security. Get ready to peel back another layer of the internet!

References

nftables Wiki: https://wiki.nftables.org/wiki-nftables/index.php/Main_Page
Arch Linux nftables Guide: https://wiki.archlinux.org/title/nftables
Microsoft Docs: New-NetFirewallRule: https://learn.microsoft.com/en-us/powershell/module/netsecurity/new-netfirewallrule
Apple Support: Change Firewall settings on Mac: https://support.apple.com/guide/mac-help/change-firewall-settings-mh34040/mac
OpenBSD pf User’s Guide: https://www.openbsd.org/faq/pf/index.html (While specifically for OpenBSD, pf on macOS shares much of the same syntax and concepts.)

This page is AI-assisted and reviewed. It references official documentation and recognized resources where relevant.