Harden Your Linux Server: Essential Firewall Rule Configuration

Introduction

Securing a Linux server begins with a properly configured firewall. For site owners, developers, and enterprises running services on virtual private servers, a misconfigured or permissive firewall is one of the most common causes of compromise. This article explains the underlying principles of modern Linux firewalling, step-by-step configuration guidance for common tools (nftables, iptables, firewalld, UFW), practical rulesets, testing and auditing techniques, and purchasing considerations when choosing a VPS provider. The goal is to give you portable, repeatable firewall rules that harden your server while preserving necessary access.

Core Principles of Effective Firewall Configuration

Before diving into commands, it’s essential to understand the design principles that guide robust rule creation:

• Default deny (least privilege): Set the default policy to deny all incoming traffic, and only allow what you explicitly need.
• Stateful filtering: Use connection tracking (ESTABLISHED, RELATED) to simplify rules and avoid breaking legitimate responses.
• Explicit outbound policy: For servers that shouldn’t initiate arbitrary connections, restrict outbound traffic to required destinations/ports.
• Layered defense: Combine firewall rules with host-based tools (fail2ban, SELinux/AppArmor, rate limiting) and network-level protections (VPC security groups).
• Least exposure of management ports: Limit SSH/RDP to fixed IPs or use port knocking/VPN for administrative access.
• Consistent logging and monitoring: Log dropped packets and rate-limit logs to avoid filling storage; integrate with centralized logging.

Tools and When to Use Them

Linux offers several firewall tooling options. Choose based on distribution, familiarity, and features required.

nftables (recommended)

nftables is the modern netfilter framework that replaces iptables, ip6tables, arptables, and ebtables. It is more efficient, supports sets, maps, and atomic rule updates. Use nftables on modern kernels and distributions (Debian 10+, Ubuntu 20.04+, CentOS 8+, etc.).

iptables (legacy)

iptables still exists on many systems and is useful for compatibility. For new deployments prefer nftables, but iptables commands and iptables-save format remain relevant.

firewalld

firewalld provides dynamic zone-based firewall management and uses nftables internally on newer systems. It’s suitable for administrators who prefer zone concepts and runtime changes without disrupting active connections.

UFW (Uncomplicated Firewall)

UFW is an easy-to-use front-end for iptables/nftables commonly found on Ubuntu servers. It’s ideal for developers and small sites who want a simple CLI to manage rules.

Practical Configuration Examples

Below are practical, copy-paste-ready rule examples. Replace IPs and ports with those appropriate to your environment.

Baseline nftables ruleset (IPv4 + IPv6)

Save as /etc/nftables.conf and enable via systemd. This example enforces default deny inbound, allows established connections, permits SSH from an admin IP, and rate-limits SSH attempts.

nftables.conf snippet

Note: Lines are shown as plain text you can paste into the config file.

table inet filter {

set allowed_ssh_ipv4 { type ipv4_addr; elements = { 203.0.113.45 } }

chain input { type filter hook input priority 0; policy drop; }

chain forward { type filter hook forward priority 0; policy drop; }

chain output { type filter hook output priority 0; policy accept; }

chain input {

ct state established,related accept

iif “lo” accept

tcp dport 22 ip saddr @allowed_ssh_ipv4 ct state new limit rate 3/minute accept

tcp dport 80 ct state new accept

tcp dport 443 ct state new accept

icmp type { echo-request, echo-reply } accept

counter log prefix “nft_drop: ” drop

}

}

iptables-compatible example

For systems still using iptables, a minimal script to be run at boot (e.g., /etc/iptables.rules) can implement similar behavior.

iptables -F

iptables -P INPUT DROP

iptables -P FORWARD DROP

iptables -P OUTPUT ACCEPT

iptables -A INPUT -m conntrack –ctstate ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -p tcp –dport 22 -s 203.0.113.45 -m conntrack –ctstate NEW -m recent –set

iptables -A INPUT -p tcp –dport 22 -s 203.0.113.45 -m conntrack –ctstate NEW -m recent –update –seconds 60 –hitcount 4 -j DROP

iptables -A INPUT -p tcp –dport 22 -s 203.0.113.45 -m conntrack –ctstate NEW -j ACCEPT

iptables -A INPUT -p tcp –dport 80 -m conntrack –ctstate NEW -j ACCEPT

iptables -A INPUT -p tcp –dport 443 -m conntrack –ctstate NEW -j ACCEPT

iptables -A INPUT -p icmp -j ACCEPT

iptables -A INPUT -j LOG –log-prefix “ipt_drop: “

iptables -A INPUT -j DROP

Using UFW for quick setups

UFW is suitable for VPS users who want simple commands:

• ufw default deny incoming
• ufw default allow outgoing
• ufw allow from 203.0.113.45 to any port 22 proto tcp
• ufw allow 80/tcp
• ufw allow 443/tcp
• ufw limit ssh/tcp
• ufw enable

Advanced Considerations

Rate limiting and brute-force protection

Rate-limiting SSH and login ports prevents automated attacks. Use nftables “limit” or iptables “recent”/“hashlimit”. Complement firewall rules with fail2ban to automatically ban offending IPs at the host level.

Protecting against port scans and SYN floods

Use SYN cookies (net.ipv4.tcp_syncookies=1) and connection limit rules. nftables can match on tcp flags and drop suspicious patterns. Additionally, use the raw table to bypass conntrack for known-heavy flows:

• Limit new connections per IP: nft add rule inet filter input tcp dport 80 ct state new limit rate 50/minute accept
• Drop null scans: nft add rule inet filter input tcp flags & (fin|syn|rst|psh|ack|urg) == 0 drop

Containers and Docker considerations

Docker manipulates iptables by default, which can interfere with host rules. Recommended approaches:

• Run Docker with –iptables=false and manage NAT and forwarding rules manually.
• Use firewalld or nftables and add explicit rules for Docker bridge networks.
• Place sensitive services outside containers or behind a reverse proxy on the host.

IPv6 parity

If your server has IPv6 enabled, ensure firewall policies apply to ip6tables/nftables inet family as well. Don’t accidentally block IPv6 while securing IPv4; attackers can bypass IPv4-only rules via IPv6.

Logging and monitoring

Log important drops with rate limits to prevent log flooding. Forward logs to a central collector (syslog-ng, rsyslog, or a SIEM) and create alerts for unusual patterns. Use tools like nft list ruleset, iptables-save, or firewall-cmd –list-all to generate rule snapshots for audits.

Application Scenarios and Example Rule Sets

Tailor rules to the server role. Examples:

Web server (NGINX/Apache) public-facing

• Allow TCP 80 and 443 to public interface.
• Limit access to management ports (SSH) to admin IPs or VPN.
• Allow outbound to package repositories for updates.
• Block uncommon high-risk ports (NetBIOS, RPC) at the host level.

Database server in private subnet

• Deny all inbound except from the application tier IP range on the database port (e.g., 3306, 5432).
• Disable outbound internet access unless needed for backups/replication.
• Use host-based firewalls plus cloud/VPC security groups for layered access control.

Jump host / bastion

• Permit SSH only from corporate IPs and MFA-protected VPN.
• Log all connections, and use short lived SSH keys or certificate-based authentication.
• Restrict outbound to internal networks; avoid allowing arbitrary tunneling.

Advantages Comparison and Selection Guidance

Choosing the right firewall approach depends on scale, complexity, and team skillset:

• nftables: Best for new installations and performance-sensitive environments; supports complex sets and atomic updates.
• iptables: Good for legacy compatibility; more verbose; consider migrating to nftables for future-proofing.
• firewalld: Easiest for managing zones and runtime changes; integrates well with desktop and server management tools.
• UFW: Simplest for single-server setups where minimal configuration is desired.

For enterprise deployments, use nftables/firewalld with centralized configuration management (Ansible, Puppet) and CI for rule changes. For small sites and developers, UFW paired with fail2ban provides a fast, secure baseline.

Auditing, Testing, and Recovery

Always test firewall changes in a maintenance window or via an out-of-band console. Steps to reduce lockout risk:

• Place temporary rules that revert automatically (use at + cron or systemd-run timed units).
• Open a secondary management channel (serial console, VNC, cloud provider web console).
• Document and store rules with version control; use iptables-save/nft list ruleset to produce exports.
• Perform penetration testing/scanning from an external host to validate expected exposure.

Summary

Hardening your Linux server firewall is a critical component of a defense-in-depth strategy. Adopt the principle of least privilege, use stateful filtering, and prefer nftables when possible. Rate-limit and protect management services, ensure IPv6 parity, and log intelligently. For production environments, integrate firewall rules with orchestration and monitoring systems so changes are auditable and reversible. By combining sound rulesets with host-based protections like fail2ban, and by testing changes safely, you significantly reduce the attack surface of your VPS.

If you’re setting up hardened servers on a trusted platform, consider reliable VPS hosting with strong network performance to support your security measures. Learn more about available options at USA VPS or visit the provider site at VPS.DO for regional plans and specifications.