Difference between revisions of "Fail2ban"
(→Configuration: Added Enabling jails)
(→Usage: Added fail2ban-client)
|Line 21:||Line 21:|
== Service hardening ==
== Service hardening ==
Revision as of 14:41, 20 June 2018
Fail2ban scans log files (e.g.
/var/log/httpd/error_log) and bans IPs that show the malicious signs like too many password failures, seeking for exploits, etc. Generally Fail2Ban is then used to update firewall rules to reject the IP addresses for a specified amount of time, although any arbitrary other action (e.g. sending an email) could also be configured.
If you want Fail2ban to send an email when someone has been banned, you have to configure SSMTP (for example).
The fail2ban-client allows monitoring jails (reload, restart, status, etc.):
E.g. to check the status of the sshd jail:
# fail2ban-client status sshd
Status for the jail: sshd |- Filter | |- Currently failed: 1 | |- Total failed: 9 | `- Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd `- Actions |- Currently banned: 1 |- Total banned: 1 `- Banned IP list: 18.104.22.168
Currently, fail2ban must be run as root. Therefore, you may wish to consider hardening the process with systemd.
Create a drop-in configuration file for
[Service] PrivateDevices=yes PrivateTmp=yes ProtectHome=read-only ProtectSystem=strict NoNewPrivileges=yes ReadWritePaths=-/var/run/fail2ban ReadWritePaths=-/var/lib/fail2ban ReadWritePaths=-/var/log/fail2ban ReadWritePaths=-/var/spool/postfix/maildrop CapabilityBoundingSet=CAP_AUDIT_READ CAP_DAC_READ_SEARCH CAP_NET_ADMIN CAP_NET_RA
CAP_DAC_READ_SEARCH will allow fail2ban full read access to every directory and file,
CAP_NET_RAW allow setting of firewall rules with iptables. See for more info.
ProtectSystem=strict the filesystem hierarchy will only be read-only,
ReadWritePaths allows fail2ban to have write access on required paths.
/etc/fail2ban/fail2ban.conf with the correct
# Option: logtarget # Notes.: Set the log target. This could be a file, SYSLOG, STDERR or STDOUT. # Only one log target can be specified. # If you change logtarget from the default value and you are # using logrotate -- also adjust or disable rotation in the # corresponding configuration file # (e.g. /etc/logrotate.d/fail2ban on Debian systems) # Values: [ STDOUT | STDERR | SYSLOG | SYSOUT | FILE ] Default: STDERR # logtarget = /var/log/fail2ban/fail2ban.log
Finally, reload systemd to apply the changes of the unit:
# systemctl daemon-reload
Due to the possibility of the
/etc/fail2ban/jail.conf file being overwritten or improved during a distribution update, it is recommended to provide customizations in a
/etc/fail2ban/jail.local file. For example to change default bantime to 1 day:
[DEFAULT] bantime = 1d
Or create separate name.conf files under the
jail.d directory, e.g.
# # JAILS # # # SSH servers # [sshd] #mode = normal enabled = true port = ssh logpath = %(sshd_log)s backend = %(sshd_backend)s
/etc/ssh/sshd_configto allow full fail2ban monitoring.
fail2ban.service to apply configuration changes.
Firewall and services
Tips and tricks
Custom SSH jail
/etc/fail2ban/jail.d/jail.conf, add this section and update the list of trusted IP addresses.
If your firewall is iptables:
[DEFAULT] bantime = 1d ignoreip = 127.0.0.1/8 [sshd] enabled = true filter = sshd action = iptables backend = systemd maxretry = 5 findtime = 1d bantime = 2w
fail2ban has IPv6 support since version 0.10. Adapt your firewall accordingly, e.g. start and enable
shorewall. You can also set
/etc/shorewall/shorewall.conf, otherwise the rule added to ban an IP address will affect only new connections.
Also do not forget to add/change:
/etc/ssh/sshd_config. Else, password failures are not logged correctly.