Configure Fail2Ban on DirectAdmin VPS: Step-by-Step

Why DirectAdmin Servers Need Fail2Ban

DirectAdmin is a lean control panel, and that's precisely why a lot of VPS customers choose it. But lean doesn't mean hardened. Out of the box, DirectAdmin exposes SSH on port 22, FTP on 21, and its own admin panel on port 2222 — all of which attract automated login scanners within hours of a server going live.

Fail2Ban watches your authentication logs and temporarily bans any IP that exceeds a login failure threshold. For DirectAdmin hosting environments, it's one of the most practical security layers you can add — no paid licences, no service restarts, and it works quietly in the background.

This tutorial walks through a complete Fail2Ban setup on a DirectAdmin VPS running AlmaLinux 8/9 or Ubuntu 22.04/24.04. The same steps apply to Debian 11/12 with minor package differences noted.

Before You Start

You'll need root or sudo SSH access to your VPS. If you haven't locked down SSH key authentication yet, that's worth doing first — see our guide on configuring SSH key authentication on Ubuntu VPS before continuing.

Check that DirectAdmin is running and that you can log in on port 2222:

systemctl status directadmin

Also confirm your firewall is active. If you're on Ubuntu and haven't set up UFW yet, our UFW firewall setup guide covers that step. On AlmaLinux, firewalld is the default.

Step 1: Install Fail2Ban

On AlmaLinux 8 or 9:

dnf install epel-release -y
dnf install fail2ban -y

On Ubuntu 22.04 or 24.04 (and Debian 11/12):

apt update
apt install fail2ban -y

Start and enable the service so it survives reboots:

systemctl enable --now fail2ban

Confirm it's running:

systemctl status fail2ban

Step 2: Create a Local Configuration File

Fail2Ban ships with /etc/fail2ban/jail.conf. Don't edit that file directly — it gets overwritten on upgrades. Instead, create a local override:

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Open /etc/fail2ban/jail.local in your preferred editor. Scroll to the [DEFAULT] section and set some sensible baseline values:

[DEFAULT]
bantime  = 3600
findtime = 600
maxretry = 5
ignoreip = 127.0.0.1/8 ::1

This bans an offending IP for one hour if it fails five times within ten minutes. Add your own office or home IP to ignoreip — a comma-separated list — so you don't lock yourself out during testing.

Step 3: Enable the SSH Jail

SSH brute-force is still the most common attack vector. In jail.local, find the [sshd] block and enable it:

[sshd]
enabled  = true
port     = ssh
logpath  = %(sshd_log)s
backend  = %(sshd_backend)s
maxretry = 4

If you've moved SSH to a non-standard port (say, 2244), replace port = ssh with port = 2244.

On AlmaLinux, the SSH log path resolves to /var/log/secure. On Ubuntu/Debian it uses journald, so set backend = systemd if you see log-not-found warnings after reloading.

Step 4: Protect the DirectAdmin Login Panel

DirectAdmin logs failed logins to /var/log/directadmin/errortaskq.log and /var/log/directadmin/login.log. Create a dedicated jail file to keep things tidy:

nano /etc/fail2ban/jail.d/directadmin.conf

Paste the following:

[directadmin]
enabled  = true
port     = 2222
filter   = directadmin
logpath  = /var/log/directadmin/login.log
maxretry = 5
bantime  = 7200
findtime = 600

Now create the matching filter file:

nano /etc/fail2ban/filter.d/directadmin.conf

Add this regex pattern, which matches DirectAdmin's failed-login log entries:

[Definition]
failregex = ^.*\[\].*(?:password mismatch|invalid password|login failed).*$
ignoreregex =

DirectAdmin's log format has changed slightly across versions. If the regex doesn't match, run fail2ban-regex /var/log/directadmin/login.log /etc/fail2ban/filter.d/directadmin.conf to test it and adjust the pattern against your actual log output.

Step 5: Add an FTP Jail (Pure-FTPd or ProFTPD)

DirectAdmin typically installs Pure-FTPd. Check which FTP daemon is running:

systemctl list-units --type=service | grep ftp

For Pure-FTPd, add this to jail.local or a separate file in /etc/fail2ban/jail.d/:

[pure-ftpd]
enabled  = true
port     = ftp,ftp-data,ftps,ftps-data
filter   = pure-ftpd
logpath  = /var/log/messages
maxretry = 5

On Ubuntu/Debian, the log path is /var/log/syslog. The pure-ftpd filter ships with Fail2Ban, so no custom filter is needed here.

Step 6: Reload Fail2Ban and Verify

Apply all changes:

fail2ban-client reload

Check which jails are now active:

fail2ban-client status

You should see sshd, directadmin, and pure-ftpd (or proftpd) listed. Inspect a specific jail:

fail2ban-client status directadmin

This shows the current ban list, total banned count, and the number of failed attempts tracked so far.

Step 7: Test Without Locking Yourself Out

Before declaring this done, verify the filter actually matches real log lines. Use fail2ban-regex against the DirectAdmin log:

fail2ban-regex /var/log/directadmin/login.log /etc/fail2ban/filter.d/directadmin.conf

You want to see at least a few matches. Zero matches means either the log file is empty (no one has attempted a login yet) or the regex needs adjusting.

To manually test a ban, you can simulate a failure by temporarily setting maxretry = 1 in the DirectAdmin jail, triggering one bad login from a test IP, then checking the ban list. Unban with:

fail2ban-client set directadmin unbanip 203.0.113.55

Remember to set maxretry back to 5 afterwards and reload.

Setting Up Email Alerts for Bans

Fail2Ban can email you whenever it bans an IP. This is useful during the first few weeks after launch when you want visibility into attack patterns.

In jail.local, update the [DEFAULT] section:

[DEFAULT]
destemail = you@yourdomain.com
sendername = Fail2Ban Alert
mta = sendmail
action = %(action_mwl)s

The action_mwl action sends an email with the log lines that triggered the ban — much more useful than a bare IP notification. For a full walkthrough of the alerting configuration, see our tutorial on setting up Fail2Ban email alerts on Ubuntu VPS.

Permanent Bans for Repeat Offenders

Some IPs hit your server repeatedly across multiple days. Rather than banning them for an hour each time, you can escalate the ban duration using a recidive jail. Add this to jail.local:

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
bancmd   = %(banaction)s
bantime  = 604800
findtime = 86400
maxretry = 3

This bans any IP for seven days if it gets banned three times within 24 hours. It reads Fail2Ban's own log file, so it works across all jails automatically.

Checking and Managing Bans Day-to-Day

Once Fail2Ban is running, you'll occasionally need to check the ban list or release a legitimate IP that got caught. These are the commands you'll reach for most:

• List all active bans: fail2ban-client status sshd
• Unban an IP: fail2ban-client set sshd unbanip 192.168.1.10
• Check Fail2Ban logs: tail -f /var/log/fail2ban.log
• Reload after config changes: fail2ban-client reload

If a client or colleague reports they can't reach your server, check the ban list before anything else. A mis-entered password during a migration is a surprisingly common reason for a legitimate IP to get blocked.

Speaking of migrations — if you're moving sites onto this DirectAdmin VPS from another host, our VPS migration guide covers how to sequence the move without causing unnecessary downtime or triggering security rules mid-transfer.

Keeping the Configuration Maintainable

A few habits that save headaches later:

• Always put custom jails in /etc/fail2ban/jail.d/ as separate .conf files rather than cramming everything into jail.local.
• Comment your ignoreip entries so you know why each IP is exempted.
• After a Fail2Ban or DirectAdmin update, run fail2ban-regex against the login log again to confirm filters still match.
• If you're running a Hostperl VPS, keep Fail2Ban's log rotation in sync with your server's logrotate config — otherwise the log file can grow large without being pruned.

Log management ties directly into this. If you haven't configured logrotate for your VPS yet, the logrotate setup guide for Ubuntu VPS walks through keeping all your log files under control.

Frequently Asked Questions

Does Fail2Ban work with DirectAdmin's built-in firewall (CSF)?

CSF (ConfigServer Security & Firewall) is sometimes installed alongside DirectAdmin and has its own brute-force detection. Running both simultaneously can cause conflicts. If CSF is active, use its login failure detection instead of Fail2Ban for DirectAdmin-specific jails, or disable CSF's LFD daemon and let Fail2Ban handle everything.

Why isn't the DirectAdmin jail matching any log lines?

The most likely cause is a regex mismatch. Run fail2ban-regex /var/log/directadmin/login.log /etc/fail2ban/filter.d/directadmin.conf and inspect the output. You may need to check the actual log format in your DirectAdmin version — open the log file and copy a failed-login line, then adjust the regex to match it exactly.

How do I whitelist a whole IP range, such as an office network?

In the [DEFAULT] section of jail.local, add the CIDR block to ignoreip:

ignoreip = 127.0.0.1/8 ::1 203.0.113.0/24

Reload Fail2Ban after saving. The entire /24 subnet will be ignored by all jails.

Will Fail2Ban survive a server reboot?

Yes, as long as you enabled it with systemctl enable --now fail2ban. Active bans at the time of reboot are not preserved by default — they're rebuilt from log history as new failures occur. Persistent bans require the dbpurgeage setting and a database backend, which is beyond the scope of this setup for most hosting customers.

Does this setup work on AlmaLinux 10?

AlmaLinux 10 (GA in 2026) uses the same EPEL repository flow. Install Fail2Ban via dnf install epel-release fail2ban -y. The configuration files and jail syntax are identical to AlmaLinux 9.