For our Blog Visitor only Get Additional 3 Month Free + 10% OFF on TriAnnual Plan YSBLOG10
Grab the Deal

How to Monitor & Secure FirewallD on Linux Server – Easy Guide

To monitor and secure FirewallD on a Linux server, verify its status, set a least-privilege baseline with zones and services, enable logging for denied packets, and automate alerts and bans with tools like Fail2Ban. Use firewall-cmd to list, audit, and harden rules, then continuously review logs and update policies for evolving threats.

FirewallD on Linux server environments is the first line of defense for your public-facing applications. In this guide, you’ll learn how to monitor FirewallD activity, audit rules, and harden configurations using practical commands and safe workflows. We’ll cover logging, rich rules, rate limiting, Fail2Ban integration, and ongoing security hygiene.

What Is FirewallD and Why It Matters

FirewallD is a dynamic host firewall that manages network rules through zones and services. On modern RHEL, Rocky, AlmaLinux, and Fedora, it uses the nftables backend. It lets you change policies without dropping connections, making it ideal for production servers that require continuous uptime and strong security.

Key Concepts: Zones, Services, Runtime vs. Permanent

Zones group interfaces and sources by trust level (for example, public, internal, trusted). Services are pre-defined rule sets (like ssh, http, https) mapped to ports and protocols.

  • Runtime: Immediate changes; lost at reboot or reload unless saved.
  • Permanent: Saved to disk; applied on reload or reboot.
  • Best practice: Build in permanent, test in runtime, then reload to persist.

Prerequisites and Safe Change Process

  • Have console access or out-of-band management before changing SSH rules.
  • Know your default zone and active interfaces.
  • Whitelist your admin IPs for SSH before tightening policies.
  • Plan a maintenance window for reloads on critical systems.

Verify FirewallD Status and Baseline

Start by confirming FirewallD is installed, active, and which zone is in use. This sets your monitoring baseline and avoids accidental lockouts.

sudo systemctl status firewalld
sudo firewall-cmd --state
sudo firewall-cmd --get-default-zone
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all

If you’re on a distro that defaults to another firewall (for example, Ubuntu’s UFW), use one firewall service at a time to prevent conflicts.

Build a Secure Baseline Policy

Your goal is least privilege: allow only what the server needs. For a typical web server, that’s SSH for admin access and HTTP/HTTPS for visitors.

Set the Default Zone and Allow Required Services

# Set default zone to "public" and allow core services
sudo firewall-cmd --permanent --set-default-zone=public
sudo firewall-cmd --permanent --zone=public --add-service=ssh
sudo firewall-cmd --permanent --zone=public --add-service=http
sudo firewall-cmd --permanent --zone=public --add-service=https

# Optional: open a specific port (e.g., PostgreSQL 5432)
sudo firewall-cmd --permanent --zone=public --add-port=5432/tcp

# Apply changes
sudo firewall-cmd --reload

# Verify
sudo firewall-cmd --list-all

Restricting SSH by source IP radically reduces brute-force risk. Use rich rules to allow SSH only from trusted addresses.

# Allow SSH only from admin IPs
sudo firewall-cmd --permanent --zone=public \
  --add-rich-rule='rule family=ipv4 source address=203.0.113.10 service name="ssh" accept'
sudo firewall-cmd --permanent --zone=public \
  --add-rich-rule='rule family=ipv6 source address=2001:db8::/64 service name="ssh" accept'

# Optionally drop SSH for everyone else (place after accepts)
sudo firewall-cmd --permanent --zone=public \
  --add-rich-rule='rule service name="ssh" drop'

sudo firewall-cmd --reload
sudo firewall-cmd --list-rich-rules

Monitor FirewallD Activity and Logs

Enable Logging for Denied Packets

Enable log-denied to see rejected traffic. This is essential for monitoring, alerting, and incident response.

# Enable logging (options: off, all, unicast, broadcast, multicast)
sudo firewall-cmd --set-log-denied=all
sudo firewall-cmd --get-log-denied

# Tail recent firewall logs
sudo journalctl -u firewalld -f

Read and Filter Logs Effectively

FirewallD writes to systemd-journald. Use journalctl to query time ranges or grep for noise-free analysis.

# Last hour of FirewallD logs
sudo journalctl -u firewalld --since "1 hour ago"

# Kernel-level drops (network stack)
sudo journalctl -k | grep -i "IN="

# Summarize hits for a specific port (e.g., SSH)
sudo journalctl -k | grep -i "DPT=22" | awk '{print $NF}' | sort | uniq -c | sort -nr | head

On RHEL 8+/Rocky/AlmaLinux/Fedora, FirewallD uses nftables. Avoid editing nft rules directly; manage rules with firewall-cmd to keep the configuration consistent.

Automated Alerts and Bans with Fail2Ban

Fail2Ban reads service logs (for example, SSH auth failures) and uses FirewallD to block abusive IPs automatically. This is a proven way to reduce brute-force noise and safeguard server resources.

# Install fail2ban (RHEL/Rocky/AlmaLinux/Fedora)
sudo dnf install -y fail2ban

# Basic jail for SSH using FirewallD rich rules
sudo tee /etc/fail2ban/jail.local >/dev/null <<'EOF'
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
backend = systemd
banaction = firewallcmd-rich-rules

[sshd]
enabled = true
EOF

sudo systemctl enable --now fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

Monitor bans with fail2ban-client status sshd. If you operate multiple services (Postfix, Dovecot, Nginx), enable their jails and use banaction = firewallcmd-rich-rules for cohesive FirewallD enforcement.

Advanced Hardening with Rich Rules

Rate-Limit SSH to Throttle Brute Force

Rate limiting complements Fail2Ban. The following rule allows up to 10 connections per minute to SSH; excess attempts are dropped. Adjust to your environment and legitimate usage patterns.

# Rate-limit SSH globally
sudo firewall-cmd --permanent --add-rich-rule='rule service name="ssh" limit value="10/m" accept'
sudo firewall-cmd --permanent --add-rich-rule='rule service name="ssh" drop'
sudo firewall-cmd --reload

Block Known-Bad IPs and Subnets

# Block a single IPv4 address
sudo firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=198.51.100.23 drop'

# Block an IPv4 subnet
sudo firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=198.51.100.0/24 drop'

# Block an IPv6 subnet
sudo firewall-cmd --permanent --add-rich-rule='rule family=ipv6 source address=2001:db8:bad::/48 drop'

sudo firewall-cmd --reload

Panic Mode and Lockdown Mode

Panic mode drops all incoming and outgoing traffic immediately—useful during incidents. Lockdown mode restricts which local apps can modify the firewall, reducing tampering risk.

# Panic mode (emergency only)
sudo firewall-cmd --panic-on
sudo firewall-cmd --panic-off

# Lockdown mode
sudo firewall-cmd --lockdown-on
sudo firewall-cmd --lockdown-off

# Manage lockdown whitelist (XML or firewall-cmd helpers on newer versions)
# /etc/firewalld/lockdown-whitelist.xml

Ongoing Maintenance and Auditing

  • Audit rules regularly: firewall-cmd --list-all and --list-rich-rules.
  • Promote tested runtime changes to permanent: firewall-cmd --runtime-to-permanent.
  • Validate configs after edits: firewall-cmd --check-config.
  • Back up FirewallD configs from /etc/firewalld/.
  • Coordinate with cloud firewalls (AWS Security Groups, Azure NSGs, GCP VPC Firewall) to avoid mismatched rules.
  • Review logs weekly; tighten rules based on denied traffic trends.

Common Mistakes to Avoid

  • Using iptables-services alongside FirewallD, causing conflicts. Choose one.
  • Editing nftables directly instead of using firewall-cmd.
  • Opening ports permanently without documenting purpose and owner.
  • Forgetting to reload after permanent changes.
  • Whitelisting 0.0.0.0/0 for SSH; always restrict or use VPN/bastion.
  • Not enabling log-denied; you can’t monitor what you don’t log.

Real-World Example: Harden a Web Server in Minutes

# 1) Confirm status and active zones
sudo systemctl is-active firewalld && sudo firewall-cmd --get-active-zones

# 2) Allow only SSH (restricted), HTTP, HTTPS
sudo firewall-cmd --permanent --zone=public --add-service=http
sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --permanent --zone=public \
  --add-rich-rule='rule family=ipv4 source address=203.0.113.10 service name="ssh" accept'
sudo firewall-cmd --permanent --zone=public \
  --add-rich-rule='rule service name="ssh" drop'

# 3) Enable denied logging and rate-limit SSH
sudo firewall-cmd --set-log-denied=all
sudo firewall-cmd --permanent --add-rich-rule='rule service name="ssh" limit value="10/m" accept'
sudo firewall-cmd --permanent --add-rich-rule='rule service name="ssh" drop'

# 4) Apply and verify
sudo firewall-cmd --reload
sudo firewall-cmd --list-all
sudo firewall-cmd --list-rich-rules

# 5) Watch logs
sudo journalctl -u firewalld -f

FAQs: Monitor and Secure FirewallD on Linux Server

How do I check if FirewallD is running?

Use: systemctl status firewalld and firewall-cmd --state. If it’s inactive, run sudo systemctl enable --now firewalld. Then verify zones and rules with firewall-cmd --get-active-zones and --list-all.

How do I enable logging of denied packets in FirewallD?

Run sudo firewall-cmd --set-log-denied=all to log all denied packets. View logs with journalctl -u firewalld or journalctl -k. You can switch to unicast, broadcast, or multicast to reduce noise.

What’s the difference between runtime and permanent in FirewallD?

Runtime changes are immediate but temporary; they disappear after a reload or reboot. Permanent changes are saved to disk and applied after firewall-cmd --reload. Convert runtime changes with firewall-cmd --runtime-to-permanent.

How do I allow SSH from a single IP address?

Use a rich rule: sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family=ipv4 source address=203.0.113.10 service name="ssh" accept' followed by sudo firewall-cmd --reload. Optionally add a drop rule for all other SSH attempts.

Is FirewallD better than iptables for servers?

For most modern Linux servers, yes. FirewallD provides dynamic rule updates, zones, and service abstractions, and it uses nftables under the hood on current distros. It’s easier to maintain safely in production compared to managing raw iptables rules directly.

Prahlad Prajapati

Prahlad is a web hosting specialist and SEO-focused organic growth expert from India. Active in the digital space since 2019, he helps people grow their websites through clean, sustainable strategies. Passionate about learning and adapting fast, he believes small details create big success. Discover his insights on web hosting and SEO to elevate your online presence.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top