SSH and brute force
How InfraFence detects SSH brute force with 15 log patterns and bans attackers for escalating durations, and how it protects mail, database and FTP logins.
Last updated:
What it reads
On systemd servers the agent reads SSH authentication messages from the journal (the auth and authpriv facilities), so distributions without rsyslog are covered. Elsewhere, or in a container, it reads /var/log/auth.log or /var/log/secure. AUTH_LOG_PATH points it to a non-standard file. The agent log names the source: reading authentication messages from ….
The 15 patterns
Nine patterns catch failed authentication: failed passwords and keys, invalid or illegal users, PAM authentication failures, maximum authentication attempts exceeded, disconnects for authentication failure, users not allowed, refused root logins, TCP wrappers refusals and disconnects of invalid users before authentication.
Six more catch scanning before authentication: no identification string, bad protocol version, failed key-exchange negotiation, banner exchange errors, connections closed or reset before authentication, and timeouts before authentication.
When an address is banned
An address is banned when its failed attempts reach the threshold within the window: by default 5 attempts within 60 seconds, set under Settings › Agent (Brute-force threshold, Brute-force window). Every ban is reported to the dashboard as a critical brute_force event.
An address from a country you block is banned on its first attempt. A whitelisted address is never banned.
How long a ban lasts
Settings › Agent › Ban duration:
- Escalating: 24 hours, 7 days, 30 days, then permanent (the default): each new ban of the same address lasts longer;
- or always 1 hour, 24 hours, 7 days, 30 days, or permanent.
A ban starts on the server at once and lasts 24 hours until the dashboard sets its final expiry. Bans expire on time on the server even while the dashboard cannot be reached, and they survive restarts.
From the server's Network tab you can Change duration, Unban now or Add to whitelist for any active ban. With Ban on all servers on, an address banned on one server is banned on every server of the organization.
How the ban is applied
Bans go into the ipset infrafence-bans, dropped from the agent's own INFRAFENCE chain, which INPUT jumps to (and DOCKER-USER, for container ports). With ipset the agent holds up to 65,000 bans; without it, one firewall rule per address, up to 500. At capacity the oldest bans make room, with a warning.
The agent never bans loopback, link-local and private addresses, the server's own addresses, the dashboard's address, or whitelisted addresses, even if asked to.
Mail, database and FTP
The same detection covers the other services that accept logins, with a fixed threshold of 5 failed attempts in 5 minutes:
| Service | Logs read |
|---|---|
| Postfix, Dovecot, Roundcube | /var/log/mail.log, /var/log/maillog, /var/log/dovecot.log |
| MySQL, MariaDB | /var/log/mysql/error.log, /var/log/mysqld.log, /var/log/mariadb/mariadb.log |
| PostgreSQL | /var/log/postgresql/ and the pg_log directories |
| MongoDB | /var/log/mongodb/mongod.log, /var/log/mongod.log |
| vsftpd, ProFTPD, Pure-FTPd | /var/log/vsftpd.log, /var/log/proftpd/proftpd.log, the system auth log for Pure-FTPd |
MAIL_LOG_PATH, DB_LOG_PATH and FTP_LOG_PATH override the detected files. A watcher with nothing to read says so in the log, for example [mailwatcher] no mail service found — mail attack detection disabled.
Monitor mode
With Monitor mode on, every attempt is still detected and reported, and nothing is banned.