Advanced Security: Fail2Ban & Firewall Hardening

When to use it

On every server that is reachable from the internet, once it has been connected. It turns on the distribution's firewall, bans addresses that keep failing to sign in over SSH, and applies safer SSH settings, and it is built so that the one mistake nobody could fix from here, cutting off SSH, cannot happen.

Choosing the options

Firewall

• Turn on the firewall, allowing SSH and the ports below — ufw on Ubuntu and Debian, firewalld on the RHEL family and Amazon Linux. Rules are added to a firewall already in use instead of replacing its rules.
• Leave the firewall as it is — choose this when your provider's firewall or security group already filters traffic and you want only Fail2Ban and the SSH settings.

Allow ports that services are listening on now — on, what is reachable now stays reachable: a web server on 80 and 443 keeps serving. Off, only SSH and the ports you list are allowed. Turn it off for a server where you know exactly which ports should be public.

Also allow these ports — for example 80, 443, 51820/udp or 8000-8100/tcp. A port without /udp is TCP.

Install Fail2Ban for SSH — bans addresses that keep failing to sign in. Skipped where csf and lfd already do this. Amazon does not package Fail2Ban for Amazon Linux 2023: turn it off there.

Fail2Ban rule

• Standard — 5 failed logins in 10 minutes: banned for 1 hour. Right for most servers.
• Strict — 3 failed logins in 10 minutes: banned for 1 day. For servers only a few people sign in to, with SSH keys.
• Relaxed — 10 failed logins in 10 minutes: banned for 10 minutes. For servers many people sign in to with passwords.

Never ban these addresses — your office or VPN addresses, or CIDR ranges such as 198.51.100.0/24. The address this run connects from is always included.

Apply safe SSH settings — stricter sign-in limits, no empty passwords and no X11 forwarding. How anyone signs in stays the same.

Password logins — Turn off: SSH keys only is the strongest setting. It is refused while the platform itself signs in to this server with a password: give the server an SSH key credential on its page first.

Root logins — Root with SSH keys only or No root logins. Each is refused when the platform signs in as root in a way the choice would stop. To turn root logins off completely, connect the server with another account that has sudo first.

What it does on the server

1. Identifies the SSH connection the run arrives on, the account it signed in as and how, from sshd's own log.
2. Keeps copies of everything it will change in a folder under /var/lib/iap-automation/security-hardening/, named after the time of the run, writes an undo script, and arms a timer that runs the undo automatically after five minutes unless the run finishes and disarms it. A run that is cut off halfway is therefore undone by the server itself.
3. Configures the firewall. Every port sshd listens on is always allowed, whatever else you chose. csf, custom nftables or iptables rules, and rules no firewall manages are left alone, and the run says what it found.
4. Installs Fail2Ban with a jail for SSH, adds this run's address and your never-ban list to it, and proves the jail works by making one failed login the jail must detect.
5. Writes the SSH settings to /etc/ssh/sshd_config.d/00-iap-hardening.conf, checks them with sshd -t, and confirms that the platform's own account could still sign in the way it did.
6. Checks that the original SSH connection is still open, then disarms the undo timer.

If any check fails, every change is undone and the run says which check failed.

After the run

Check the result line for what was applied. Ports that were listening but are now blocked are listed. Your cloud provider's firewall or security group is outside the server and is not changed; ports Docker publishes stay reachable whatever the host firewall allows.

A later run never loosens SSH settings an earlier run applied. To undo them, delete /etc/ssh/sshd_config.d/00-iap-hardening.conf and reload sshd.

Common problems

"This run signed in … with a password, so turning off password logins would lock the platform out" — Add an SSH key credential for the server on its page in Servers, then run the playbook again.

"This run signs in as root, so turning off root logins would lock the platform out of this server." — Connect the server with a non-root account that has sudo, then turn root logins off.

"… is not available from this server's repositories, so Fail2Ban cannot be installed." — On the RHEL family Fail2Ban comes from EPEL; the playbook enables it, but a server without internet access to EPEL cannot install it. Run again with Install Fail2Ban for SSH off, or allow the server to reach EPEL.

"Firewall left as it is: this server already filters traffic with …" — The server already has another firewall. Allow the ports you need in that firewall yourself.

"Fail2Ban's sshd jail did not find a test failed login in sshd's log" — sshd logs somewhere Fail2Ban does not read. Everything was undone. Send the run's output to support.

A port you need is blocked after the run — Run the playbook again with that port under Also allow these ports.