General notes about Fail2ban
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 |
### Fail2Ban ### Best practise: - do NOT edit /etc/fail2ban/jail.conf BUT create a new /etc/fail2ban/jail.local file ============================================================= # Test fail2ban regex: example: fail2ban-regex /var/log/secure /etc/fail2ban/filter.d/sshd.conf example2: fail2ban-regex --print-all-matched/var/log/secure /etc/fail2ban/filter.d/sshd.conf ============================================================= # Remove email notifications: comment out 'sendmail-whois' from action in [ssh-iptables] FYI, comment with # at the BEGINNING of the line like this or it won't work!!! [ssh-iptables] enabled = true filter = sshd action = iptables[name=SSH, port=ssh, protocol=tcp] # sendmail-whois[name=SSH, dest=root, [email protected], sendername="Fail2Ban"] logpath = /var/log/secure maxretry = 5 ============================================================= # Wordpress wp-login - block POST attacks /etc/fail2ban/jail.local [apache-wp-login] enabled = true port = http,https filter = apache-wp-login logpath = /var/log/httpd/blog.tian.it-access.log maxretry = 3 bantime = 604800 ; 1 week findtime = 120 ---------------------------------------------------------------------------------------------------------------------- /etc/fail2ban/filter.d/apache-wp-login.conf [Definition] failregex = <HOST>.*POST.*wp-login.php HTTP/1.1 ignoreregex = ============================================================= # Manually ban an IP: fail2ban-client -vvv set <CHAIN> banip <IP> # Check status of sshd chain fail2ban-client status sshd |
How to “SSH” brute force
If you want to make safer your remote server, it is good practise to use a good combination of sshd setup and fail2ban.
Firstly, you should setup your server to allow only key auth, and no passwords. This will drastically reduce the risk. This means anyway that you need to keep your ssh key safe and you won’t be able to access your server unless you have this key. Most of the time is something possible 🙂
For this reason, I’m explaining here how I configured my server.
SSHD
/etc/ssh/sshd_config
Have these settings in the config file (NOTE: the verbosity is for Fail2ban)
|
1 2 3 |
LogLevel VERBOSE PasswordAuthentication no |
(restart sshd)
/etc/fail2ban/jail.local
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
[DEFAULT] # Ban hosts for # one hour: #bantime = 3600 # one day: bantime = 86400 # A host is banned if it has generated "maxretry" during the last "findtime" # # seconds. findtime = 30 # # "maxretry" is the number of failures before a host get banned. maxretry = 5 # Override /etc/fail2ban/jail.d/00-firewalld.conf: banaction = iptables-multiport [sshd] enabled = true filter = sshd-aggressive port = ssh logpath = /var/log/secure maxretry = 3 findtime = 30 bantime = 86400 |
/etc/fail2ban/filter.d/sshd.conf
Add a custom section after the ddos one:
|
1 |
custom = ^%(__prefix_line_sl)sDisconnected from <HOST> port [0-9]+ \[preauth\]$ |
This line matches whoever tries to connect without a proper ssh key.
Add this line to include custom to the sshd-aggressive setup:
|
1 2 3 |
aggressive = %(normal)s %(ddos)s %(custom)s |