Most of webmasters today have some kind of SSH console remote access to the server and the OpenSSH Secure Shell service is usually not filtered for specific Networks but fully accessbible on the internet. This is especially true for home brew Linux Web servers as well as small to mid sized websites and blogs hosted on a cheap dedicated servers hosted in UK2 / Contabo RackSpace etc.
Brute force password guess attack tools such as Hydra and a distributed password dictionary files have been circulating quite for a while and if the attacker has enough time as well as a solid dictionary base, as well as some kind of relatively weak password you can expect that sooner or later some of the local UNIX accounts can be breaked and the script kiddie can get access to your server and make quickly a havoc, if he is lucky enough to be able to exploit some local vulnerability and get root access …
If you're a sysadmin that has to manage the Linux server and you do a routine log reading on the machine, you will soon get annoyed of the ever growing amount of different users, that are trying to login unsucessfully to the SSH (TCP port 22) service filling up the logs with junk and filling up disk space for nothing as well as consuming some CPU and Memory resources for nothing, you will need some easy solution to make brute force attacks from an IP get filtered after few unsuccessful login attempts.
The common way to protect SSH would then be to ban an IP address from logging in if there are too many failed login attempts based on an automatic firewall inclusion of any IP that tried to unsuccessfully login lets say 5 or 10 reoccuring times.
In Linux there is a toll called “fail2ban” (F2B) used to limit brute force authentication attempts.
F2B works with minimal configuration and besides being capable of protecting the SSH service, it can be set to protect a lot of other Server applications like;
Apache / NGINX Web Servers with PHP / Mail Servers (Exim, Postfix, Qmail, Sendmail), POP3 IMAP / AUTH services (Dovecot, Courier, Cyrus), DNS Bind servers, MySQL DBs, Monitoring tools such as Nagios, FTP servers (ProFTPD / PureFTP), Proxy servers (Squid), WordPress sites (wp-login) brute force attacks, Web Mail services (Horde / Roundcube / OpenWebmail), jabber servers etc.
To get a better overview below is F2B package description:
linux:~# apt-cache show fail2ban|grep -i description-en -A 21
Description-en: ban hosts that cause multiple authentication errors
Fail2ban monitors log files (e.g. /var/log/auth.log,
/var/log/apache/access.log) and temporarily or persistently bans
failure-prone addresses by updating existing firewall rules. Fail2ban
allows easy specification of different actions to be taken such as to ban
an IP using iptables or hostsdeny rules, or simply to send a notification
email.
.
By default, it comes with filter expressions for various services
(sshd, apache, qmail, proftpd, sasl etc.) but configuration can be
easily extended for monitoring any other text file. All filters and
actions are given in the config files, thus fail2ban can be adopted
to be used with a variety of files and firewalls. Following recommends
are listed:
.
– iptables/nftables — default installation uses iptables for banning.
nftables is also suported. You most probably need it
– whois — used by a number of *mail-whois* actions to send notification
emails with whois information about attacker hosts. Unless you will use
those you don't need whois
– python3-pyinotify — unless you monitor services logs via systemd, you
need pyinotify for efficient monitoring for log files changes
Using fail2ban is easy as there is a multitude of preexisting filters and actions (that gets triggered on a filter match) already written by different people usually found in /etc/fail2ban/filter.d an /etc/fail2ban/action.d.
as well as custom action / filter / jails is easy to do.
Fail2ban is available as a standard distro RPM / DEB package on most modern versions of Ubuntu (16.04 and later), Debian, Mint and CentOS 7, OpenSuSE, Fedora etc.
1. Install Fail2ban package
– On Deb based distros do the usual:
linux:~# apt update
linux:~# apt install –yes fail2ban
On RPM distros Fedora / CentOS / SuSE etc.
linux:~# sudo yum -y install epel-release
linux:~# sudo yum -y install fail2ban
2. Enable fail2ban ban rules for SSH failed authentication filtering
Create the file /etc/fail2ban/jail.local :
# cat > /etc/fail2ban/jail.local
Paste below content:
[DEFAULT]
# Ban hosts for one hour:
bantime = 360
# Override /etc/fail2ban/jail.d/00-firewalld.conf:
banaction = iptables-multiport
[sshd]
enabled = true
maxretry = 10
findtime = 43200
# ban for 1 day
bantime = 3600
# ban for 1 day
#bantime = 86400
This config will ban for 1 day any IP that tries to access more than 10 unsuccesful times sshd daemon.
This works through IPTABLES indicated by config banaction = iptables-multiport config making fail2ban to automatically add a new iptables block rule valid for 1 day.
To close the file press CTRL + D simulanesly
- maxretry controls the maximum number of allowed retries.
- findtime specifies the time window (in seconds) which should be considered for banning an IP. (43200 seconds is 12 hours)
- bantime specifies the time window (in seconds) for which the IP address will be banned (86400 seconds is 24 hours).
If SSH listens to a different port from 22 on the machine, you can specify the port number with
port = <port_number>
in this file.
3. Start fail2ban service
Either use the /etc/init.d/fail2ban start script or systemd systemctl
linux:~# systemctl enable fail2ban
linux:~# systemctl restart fail2ban
4. Fail2ban operational principle in short
Fail2ban uses Filters, Actions And Jails:
Filters – specify certain patterns of text that Fail2ban should recognize in log files.
Actions – are things Fail2ban can do once a filter is matched.
Jails – tell Fail2ban to match a filter on some logs. When the number of matches goes beyond a certain limit specified in the jail, Fail2ban takes an action specified in the jail.
If still wonder what is Fail2ban jail? Each configured jail tells fail2ban to look at system logs and take actions against attacks on a configured service, in our case OpenSSH service.
5. Blocking repeated unsuccessful password authentication attempts for longer periods
If more than number of failed ssh logins happen to occur (lets say 35 reoccuring ones in /var/log/auth.log (the debian failed ssh login file) or /var/log/secure (redhat distros failed ssh log file).
You will perhaps want to permanently block this IP for 3 days or so, here is how:
banaction = iptables-multiport
maxretry = 35
findtime = 259200
bantime = 608400
enabled = true
filter = sshd
Add this to [sshlongterm] section to make it finally look like this:
[sshlongterm]
port = ssh
logpath = %(sshd_log)s
banaction = iptables-multiport
maxretry = 35
findtime = 259200
bantime = 608400
enabled = true
filter = sshd
Of course to load new config restart fail2ban
# /etc/init.d/fail2ban restart
Default jail as well as the sshlongterm jail should now work together. Short term attacks will be handled by the default jail under [sshd], and the long term attacks handled by our own second jail [sshlongterm].
6. Checking which intruders were blocked by fail2ban
Fail2ban creates a separate chain f2b-sshd to which it adds each blocked IP for the period of time preset in the config, to list it:
linux:~# /sbin/iptables -L f2b-sshd
Chain f2b-sshd (1 references)
target prot opt source destination
REJECT all — 165.22.2.95 anywhere reject-with icmp-port-unreachable
REJECT all — ec2-13-250-58-46.ap-southeast-1.compute.amazonaws.com anywhere reject-with icmp-port-unreachable
REJECT all — cable200-116-3-133.epm.net.co anywhere reject-with icmp-port-unreachable
REJECT all — mail.antracite.org anywhere reject-with icmp-port-unreachable
REJECT all — 139.59.57.2 anywhere reject-with icmp-port-unreachable
REJECT all — 111.68.98.152.pern.pk anywhere reject-with icmp-port-unreachable
REJECT all — 216.126.59.61 anywhere reject-with icmp-port-unreachable
REJECT all — 104.248.4.138 anywhere reject-with icmp-port-unreachable
REJECT all — 210.211.119.10 anywhere reject-with icmp-port-unreachable
REJECT all — 85.204.118.13 anywhere reject-with icmp-port-unreachable
REJECT all — broadband.actcorp.in anywhere reject-with icmp-port-unreachable
REJECT all — 104.236.33.155 anywhere reject-with icmp-port-unreachable
REJECT all — 114.ip-167-114-114.net anywhere reject-with icmp-port-unreachable
REJECT all — 142.162.194.168.rfc6598.dynamic.copelfibra.com.br anywhere reject-with icmp-port-unreachable
REJECT all — server.domain.cl anywhere reject-with icmp-port-unreachable
REJECT all — ip202.ip-51-68-251.eu anywhere reject-with icmp-port-unreachable
REJECT all — 188.166.185.157 anywhere reject-with icmp-port-unreachable
REJECT all — 93.49.11.206 anywhere reject-with icmp-port-unreachable
RETURN all — anywhere anywhere
Conclusion
What we have seen here is how to make fail2ban protect Internet firewall unrestricted SSHD Service to filter out 1337 skript kiddie 'hackers' out of your machine. With a bit of tuning could not only break the occasional SSH Brute Force bot scanners that craw the new but could even mitigate massive big botnet initiated brute force attacks to servers.
Of course fail2ban is not a panacea and to make sure you won't get hacked one days better make sure to only allow access to SSH service only for a certain IP addresses or IP address ranges that are of your own PCs.
More helpful Articles
Tags: attacks, attempt, authentication, bruteforce, fail2ban