Security Hardening

What the playbook changes

Fail2Ban for SSH. A jail that bans an address after repeated failed logins: five in ten minutes earns a one-hour ban by default, with a strict and a relaxed rule to choose from. The playbook proves the jail works by making one failed login itself and checking that the jail saw it.

A firewall. ufw on Ubuntu and Debian, firewalld on the RHEL family and Amazon Linux, allowing SSH, the ports you list and, if you choose, every port a service already accepts outside connections on.

Safer SSH settings. No empty passwords, at most four authentication attempts per connection, 60 seconds to sign in and no X11 forwarding. Turning off password logins or root logins is a separate choice you make explicitly.

It checks the firewall you already have

A server that already filters traffic with csf, a hand-written nftables ruleset, saved iptables rules or rules no firewall manager owns keeps them. The run reports what it found and leaves the firewall alone.

If ufw or firewalld is already on, the playbook adds its rules to it. It never removes a rule a firewall already has, and it never installs a second firewall beside the first.

Your SSH access stays open

Before changing anything, the playbook finds the SSH connection it is running on and how that session signed in. Every port sshd listens on is allowed, and the address the platform connects from is never banned, along with any office or VPN addresses you list.

Turning off password logins is refused while the platform signs in with a password, and restricting root logins is refused while it signs in as root. The refusal comes before any change, so the server is left exactly as it was.

Undone automatically if anything fails

Before the first change, the playbook keeps a copy of every file it will replace and arms an undo on a systemd timer on the server. If a check fails, everything it changed is put back before the step ends.

If the run is cut off halfway, for example by a dropped connection, the timer puts everything back within five minutes without the platform. The undo is disarmed only after sshd, the firewall and the Fail2Ban jail have all been checked and the original connection is still open.

Start with a dry run

A dry run reports the firewall it found, the ports it would allow and, when it would turn a firewall on, the listening ports that would be blocked. Nothing is installed or changed.

Firewalls outside the server, such as cloud security groups, are not changed. Ports Docker publishes stay reachable whatever the host firewall allows, and the run says so when a server runs Docker.

Frequently asked questions

Can this lock me out of my server?

It is built not to. Every SSH port stays open, the platform’s own address is never banned, choices that would stop the current way of signing in are refused, and a run that fails or is cut off is undone. Firewalls outside the server, such as cloud security groups, are not touched, so check those separately.

Which distributions does it support?

Ubuntu 22.04 and later, Debian 12 and later, RHEL-compatible 8 and later (AlmaLinux, Rocky Linux, RHEL, CentOS Stream and Oracle Linux) and Amazon Linux 2023. Amazon does not package Fail2Ban for Amazon Linux 2023, so run it there with Fail2Ban turned off.

What if my server already uses csf, nftables or iptables?

The firewall is left exactly as it is and the run tells you what it found. The SSH settings can still be applied, and Fail2Ban is skipped where csf and lfd already ban failed logins.

How do I reverse the SSH settings later?

A later run never loosens SSH settings an earlier run applied. To return to your previous settings, delete /etc/ssh/sshd_config.d/00-iap-hardening.conf on the server and reload sshd. Packages the playbook installed stay installed.

Does Auto-Fix change firewall rules?

No. Auto-Fix never changes firewall rules, reboots a server or deletes data. Firewall changes happen only when you run this playbook.

Related features