Firewall Configuration Basics: Secure Your Network

A firewall sits between your network and the outside world, deciding which traffic gets through and which gets blocked. Whether you're locking down a home network, setting up a web server, or managing enterprise infrastructure, understanding how to configure one is fundamental to security. This guide walks through the core concepts, practical configuration approaches, and common patterns that apply across different firewall types.

“There are only two types of companies: those that have been hacked and those that will be.”

— Robert Mueller

Understanding Firewall Types and Their Configuration Models

Not all firewalls work the same way. Packet-filtering firewalls examine individual packets based on IP addresses, ports, and protocols. They're fast and straightforward, but they don't understand application context. Stateful firewalls track connection states, automatically allowing return traffic and blocking unsolicited inbound connections. Application-layer firewalls go further and inspect the actual content of traffic, filtering based on HTTP headers, SQL queries, or other application-specific data.

Most modern systems use stateful firewalls by default. Linux systems typically use iptables, nftables, or ufw (Uncomplicated Firewall). Windows ships with Windows Defender Firewall. Cloud providers have their own equivalents — security groups on AWS, firewall rules on Google Cloud, network security groups on Azure. The underlying principles stay consistent across all of them: define what's allowed, block everything else, and log the important stuff.

Your first major decision is whether to use default-allow or default-deny. Default-deny blocks everything except traffic you explicitly permit. It takes more setup upfront, but it creates a much smaller attack surface. Default-allow is easier to get started with, but it leaves you exposed to services you forgot were running. For anything internet-facing, default-deny is the only sensible choice.

Core Configuration Concepts

Every firewall rule has the same basic ingredients: source and destination addresses, ports, protocols, and an action (allow, deny, or log). Rules get processed in order, and the first match wins. That ordering matters enormously. A broad "allow all" rule sitting at the top will swallow more specific "deny" rules below it, and they'll never execute.

Source and destination can be individual IP addresses like 192.168.1.50, CIDR ranges like 10.0.0.0/8, or special values like "any" or "localhost". Ports map to specific services — 22 for SSH, 80 for HTTP, 443 for HTTPS, 3306 for MySQL. Protocols are TCP, UDP, ICMP, or others. TCP is connection-oriented and handles most application traffic. UDP is connectionless and used for DNS, VoIP, and video streaming. ICMP handles diagnostics like ping.

Stateful inspection makes rule management much simpler. When you allow outbound HTTPS traffic, the firewall automatically permits the inbound response packets. You don't need separate rules for both directions. That's why most firewall configs focus on inbound rules — outbound traffic is typically allowed by default, with specific exceptions carved out for data loss prevention or compliance needs.

Practical Configuration Examples

Here's a basic ufw setup for a web server running SSH, HTTP, and HTTPS:

# Reset to defaults and enable
sudo ufw --force reset
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH (limit rate to prevent brute force)
sudo ufw limit 22/tcp

# Allow web traffic
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Enable firewall
sudo ufw enable

# Check status
sudo ufw status verbose

The limit keyword on SSH blocks IPs that try more than 6 connections in 30 seconds, which stops most brute-force attempts cold. That said, two-factor authentication is still essential for any SSH service exposed to the internet. Rate limiting and 2FA together give you real protection.

For iptables, the same setup requires more explicit rules:

# Flush existing rules
iptables -F

# Set default policies
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Allow established connections
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow loopback
iptables -A INPUT -i lo -j ACCEPT

# Allow SSH with rate limiting
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --set
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --update --seconds 60 --hitcount 4 -j DROP
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

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

# Save rules
iptables-save > /etc/iptables/rules.v4

Pay attention to that stateful connection tracking rule (--ctstate ESTABLISHED,RELATED). One line handles all return traffic for every outbound connection you initiate — software updates, API calls, email, all of it. It's doing a lot of quiet, important work.

Common Configuration Patterns

Database server isolation restricts database access to your application servers only. Say your database lives at 10.0.2.50 and your app servers are in the 10.0.1.0/24 subnet. Configure the database firewall to accept connections only from that subnet:

# On database server
ufw default deny incoming
ufw allow from 10.0.1.0/24 to any port 3306 proto tcp
ufw allow from 10.0.1.0/24 to any port 22 proto tcp  # SSH from app subnet
ufw enable

Bastion host configuration creates a hardened jump server for accessing internal infrastructure. The bastion accepts SSH from known IPs only, and internal servers only accept SSH from the bastion:

# On bastion host
ufw allow from 203.0.113.50 to any port 22  # Your office IP
ufw allow from 198.51.100.25 to any port 22  # Your home IP

# On internal servers
ufw allow from 10.0.0.10 to any port 22  # Bastion's internal IP

Pair this pattern with a strong password creation guide and certificate-based authentication, and you've got genuine defense in depth.

DMZ configuration places public-facing services in a demilitarized zone, isolated from both the internet and your internal network. Internet traffic reaches only DMZ hosts, while DMZ hosts have limited reach into internal resources:

Logging and Monitoring

Firewall logs reveal attack patterns, misconfigurations, and legitimate traffic you accidentally blocked. Enable logging for denied packets, but be selective about it. Logging every dropped packet on an internet-facing server generates enormous volume from background internet noise — scanners, bots, and general chaos that hits every public IP constantly.

# Log denied packets with rate limiting
ufw logging medium

# For iptables, log with prefix
iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables-denied: " --log-level 4
iptables -A INPUT -j DROP

The rate limiting (--limit 5/min) keeps logs manageable. The prefix makes it easy to filter for firewall events specifically. Review logs regularly as part of your security audit checklist. Watch for these patterns in particular:

• Repeated connection attempts to closed ports (port scanning)
• Connection attempts from unexpected geographic locations
• Unusual traffic volumes or timing
• Legitimate services getting blocked (which means your rules need fixing)

Most mature setups feed firewall logs into a SIEM or log aggregator like the ELK stack, Splunk, or a cloud-native logging service. Set up automated alerts for suspicious patterns — 100 SSH attempts in one minute, for instance — so you can respond before something breaks.

Testing and Validation

Never assume your firewall works as intended. Test from outside your network using a separate connection or a cloud VM. The nmap tool scans for open