Lock Down Your VPS: Step-by-Step FirewallD Configuration for Maximum Security

Managing a virtual private server (VPS) implies a responsibility to protect it from unnecessary exposure and attacks. For CentOS, RHEL, Fedora and many other distributions, Firewalld provides a dynamic, zone-based firewall solution that balances ease of use with powerful features. This article walks through a practical, step-by-step Firewalld configuration designed to lock down your VPS while preserving required services and performance for production workloads.

Why Firewalld: Principles and Background

Firewalld is an abstraction layer over the packet filtering framework (nftables or iptables depending on the distribution and version). It uses the concept of zones to group network connections by trust level, supports runtime and permanent configurations, and lets you manage services, ports, rich rules, and direct rules without editing raw firewall files. Key advantages include:

• Dynamic updates — changes can be applied at runtime without restarting the firewall or disrupting existing connections.
• Zone-based trust — assign interfaces or source addresses to zones such as public, trusted, dmz, or drop.
• Rich rules and ipset — allow complex policy like rate limiting, logging, and bulk IP blocking.
• Service definitions — reuse common service profiles (ssh, http, https) via XML service files.

How Firewalld Works (Brief Technical Overview)

Firewalld talks to nftables/iptables using a daemon (firewalld.service). The runtime configuration applies immediately and can be persisted with the --permanent flag which modifies the configuration files under /etc/firewalld/. Zones are applied to interfaces or source CIDRs and are evaluated for each packet to decide accept/drop/reject. Rich rules provide conditions and actions (e.g., logging, accept, reject), and direct rules let you insert low-level rules for corner cases.

Preparation: Baseline Steps on a VPS

Before making changes, perform these preparatory checks on your VPS (assumes root or sudo access):

• Check current firewall status: sudo firewall-cmd --state
• List active zones and interfaces: sudo firewall-cmd --get-active-zones
• Backup current configuration: sudo tar czf /root/firewalld-backup-$(date +%F).tgz /etc/firewalld
• Open a persistent root console (or maintain console access via VPS provider control panel) in case you lock yourself out.

Important: Always keep an out-of-band access method (VPS console, provider rescue mode) when changing firewall rules.

Recommended Zone Strategy for VPS

Design zones around the services your VPS runs and the network trust model. A common approach:

• public — default for the primary interface, only allow essential services reachable from the internet (e.g., 80, 443, and a hardened SSH port).
• dmz — web-facing services if you want stricter rules like rate limiting and logging.
• internal/trusted — for private interfaces, management networks, or internal services.
• drop — block all incoming packets, useful for untrusted interfaces or specific IP ranges.

Example: Assign interface to a zone

Assuming your main interface is eth0 and you want to attach it to public (default):

sudo firewall-cmd --zone=public --add-interface=eth0 --permanent

Then reload to apply permanent changes to runtime:

sudo firewall-cmd --reload

Step-by-Step: Locking Down SSH

SSH is often the first vector attackers target. Harden SSH at both the SSH server and firewall layers.

• Change default SSH port in /etc/ssh/sshd_config (optional, security-by-obscurity) and restart sshd.
• Allow SSH through Firewalld on the new port (example uses 2222):

sudo firewall-cmd --zone=public --add-port=2222/tcp --permanent

or use the service alias if unchanged:

sudo firewall-cmd --zone=public --add-service=ssh --permanent

• Limit SSH to specific source IPs or networks with a rich rule (example for admin IP 203.0.113.5):

sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="203.0.113.5/32" service name="ssh" accept'

For broader protection, combine with fail2ban to ban brute-force attempts. Configure fail2ban to add IPs to an ipset, then use Firewalld to drop that ipset (shown in the ipset section).

Ports, Services, and Custom Service Files

Firewalld provides pre-defined services, but you can add ports or create a custom service XML under /etc/firewalld/services/. Example: create /etc/firewalld/services/myapp.xml:

<?xml version=”1.0″?>
<service>
  <short>myapp</short>
  <port protocol=”tcp” port=”12345″/>
</service>

Then load it and allow in a zone:

sudo firewall-cmd --permanent --add-service=myapp
sudo firewall-cmd --reload

Using ipset for Bulk Blocking and Integration with fail2ban

ipset is ideal for blocking large numbers of IPs efficiently. Firewalld integrates with ipset via the --add-rich-rule or by defining runtime ipsets. Example to create and use an ipset named banlist:

sudo firewall-cmd --permanent --new-ipset=banlist --type=hash:ip
sudo firewall-cmd –permanent –add-rich-rule=’rule source ipset=”banlist” drop’

Reload and add an IP:

sudo firewall-cmd --reload
sudo firewall-cmd --ipset=banlist --add-entry=198.51.100.23 --permanent
sudo firewall-cmd --reload

Configure fail2ban to add banned IPs to the ipset by setting the action to use the firewalld action or a custom ipset action. This avoids thousands of individual rules and keeps packet filtering efficient.

Rate Limiting, Logging, and Rich Rules

Use rich rules to implement rate limiting and logging for suspicious traffic. Example: limit SSH attempts to 5 per minute and log on first match:

sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" service name="ssh" log prefix="SSH attempt: " limit value="5/m" accept'

For more granular control, use direct rules (nftables/iptables) via Firewalld’s direct interface, but document them carefully because they bypass zone semantics.

IPv6, NAT, and Forwarding

If your VPS uses IPv6, repeat allowances for IPv6 addresses or use dual-stack service definitions. For NAT or routing setups (e.g., VPS acting as router), enable masquerading in the specific zone and open forwarding rules:

sudo firewall-cmd --zone=public --add-masquerade --permanent
sudo firewall-cmd --permanent --zone=public --add-forward-port=port=80:proto=tcp:toport=8080:toaddr=10.0.0.5

Be cautious: enabling forwarding increases attack surface; only enable what your architecture requires.

Testing, Auditing, and Maintenance

After changes, validate your firewall with the following commands:

• List rules in a zone: sudo firewall-cmd --zone=public --list-all
• Check all runtime settings: sudo firewall-cmd --list-all-zones
• Test port reachability from another host using nc or telnet.
• Monitor logs (/var/log/messages or journalctl -u firewalld) for dropped packets if you enabled logging rules.

Regular maintenance:

• Review /etc/firewalld/services and ipset contents monthly.
• Keep Firewalld and kernel packages updated; note that backend changes (nftables vs iptables) might affect direct rules.
• Backup configuration before major changes and use sudo firewall-cmd --runtime-to-permanent when ready to persist tested runtime changes.

Advantages vs Alternatives

Compared to managing raw iptables or nftables rules, Firewalld offers better manageability for dynamic environments common on VPS systems. Compared to simple hosts.allow/hosts.deny, it provides protocol-aware filtering, stateful inspection, and richer policy models. For extremely high-performance filtering on large rule sets, a carefully crafted nftables ruleset could outperform a Firewalld-managed stack, but Firewalld supports direct nftables insertion when needed.

Practical Purchase Considerations for VPS Users

When selecting a VPS provider for a production-grade environment, consider the following from a network and firewall perspective:

• Does the provider offer a control-panel firewall in addition to the OS firewall? Out-of-band provider rules can complement Firewalld.
• Are there private networking options (VLANs) to isolate backend services into trusted zones?
• Is console or rescue-mode access available to recover from accidental lockouts?
• Choose a VPS with sufficient CPU/memory to handle encryption and IDS/IPS tools if you plan to run them alongside Firewalld.

Summary and Best Practices

Locking down your VPS with Firewalld involves careful zone planning, restricting access to only necessary services, hardening SSH, leveraging ipset for scalable blocking, integrating with fail2ban, and testing thoroughly. Keep changes incremental, maintain backups, and ensure you always have a recovery path via your VPS provider console.

For administrators and developers running production workloads, pairing a reliable VPS provider with the firewall techniques above helps maintain strong security posture. If you are evaluating hosting options, consider providers that offer robust network features and reliable console access — for example, VPS.DO’s USA VPS offerings provide global infrastructure and management features that can simplify secure deployment. Learn more at https://vps.do/usa/ and the company site at https://VPS.DO/.