Linux Firewall Security with nftables, UFW and Fail2ban

Linux firewalling controls which network packets may reach a host. UFW is a convenient Ubuntu frontend, nftables is the modern kernel packet-filtering framework, and Fail2ban reacts to repeated authentication failures by applying temporary blocks through a configured backend. They solve related but different problems. Installing all three without understanding their interaction can create conflicting rules or lock out an administrator.

The commands here are illustrative for Ubuntu 24.04 and Debian 12. Before changing any firewall, confirm an out-of-band console and a tested second SSH session. Review provider firewalls, IPv6, container networking, VPNs, and application ports. Do not paste a generic ruleset into production.

1. Inventory the actual network exposure

Record listeners and current firewall tools. A listening port may still be blocked upstream, and a provider rule may allow traffic the host rules deny.

sudo ss -ltnup
sudo ufw status verbose
sudo nft list ruleset

nft list ruleset may be long and contain internal topology; store it privately. If UFW is active, it may manage nftables/iptables rules underneath. Avoid editing the same traffic path through multiple uncoordinated tools.

2. Apply a minimal UFW policy on Ubuntu

For a typical web server, first allow the actual SSH port, then application ports, and only then enable the firewall. These examples assume SSH 22 and HTTP/HTTPS 80/443. Adapt them to your host and verify IPv6 handling.

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status numbered
sudo ufw enable

Open a new SSH connection after enabling UFW while keeping the existing one open. Review the rules with a change owner and rollback plan. A firewall should expose only needed services, but blocking all traffic can also break backups, monitoring agents, DNS resolution, or outbound dependencies.

3. Know when nftables is the right interface

nftables can express packet filtering, NAT, sets, and more advanced policies directly. It is appropriate when the team needs precise control and owns the complete ruleset. The syntax and persistence method depend on distribution packaging. Start by reading the active ruleset, understanding chains and hooks, and testing in a nonproduction environment.

Do not run nft flush ruleset on a production host as a troubleshooting shortcut. It can remove rules required by containers, VPNs, or security policy. If you migrate from UFW or another manager, plan which system owns the rules and how they survive reboot.

4. Add Fail2ban for selected authentication abuse

Fail2ban watches logs and can temporarily ban sources that match configured filters. It is useful for reducing repeated login noise, but it does not replace secure passwords, keys, MFA, patching, or a base firewall. Inspect the service and jails before changing them.

sudo systemctl status fail2ban --no-pager
sudo fail2ban-client status
sudo fail2ban-client status sshd

The sshd jail must actually be enabled to have a status. Behind a reverse proxy, an application jail needs a trusted real-client-IP configuration; otherwise it may ban the proxy or a shared NAT instead of an abusive client. Test filters against real log formats and use narrow thresholds to avoid blocking legitimate users.

5. Verify from the right vantage points

After a change, test SSH from a new session, the public website from outside the host, required agent connections, and critical outbound integrations. Use ss and firewall counters to distinguish a closed service from a dropped packet. Record both IPv4 and IPv6 results. Monitor the logs for false positives during normal customer activity.

Troubleshooting and common errors

• Locked out after enabling UFW: use provider console access, inspect the SSH port and provider rules, and restore the last reviewed configuration.
• Port seems open in ss but unreachable: examine host firewall, provider firewall, routing, and whether the listener is bound to the expected address.
• Fail2ban blocks a shared proxy: correct trusted-proxy handling and filter source before unbanning; do not trust arbitrary X-Forwarded-For headers.
• Rules disappear after reboot: check the distribution's persistence mechanism and which service manages the ruleset.
• Container networking breaks: investigate interaction with Docker's network rules before replacing the host firewall.

Security considerations

Firewall policies are only one layer. Keep software patched, disable unnecessary listeners, protect administrative access with keys/MFA, and log security actions. Treat client IP addresses as privacy-sensitive metadata. Rate limits should distinguish normal navigation from repeated authentication attempts so legitimate customers are not locked out by shared NAT addresses.

FAQ

Can I run UFW and nftables together?

UFW may use the system's packet filtering backend. You can inspect the resulting rules, but manually changing the same chains without a clear owner can cause conflicts.

Does Fail2ban stop all brute-force attacks?

No. Distributed attacks can rotate IPs, and false positives can block legitimate users. Strong authentication and account-based controls remain necessary.

Should I block a country at the host firewall?

Only with a documented business and security reason, accurate IP data, and a plan for false positives. It is not a substitute for service authentication.

Continue reading

Begin with Ubuntu server hardening and Linux monitoring. For a reviewed firewall and incident process, contact East4Serv.

References: Ubuntu firewall documentation, nftables project, and Fail2ban documentation.