Difference between revisions of "Fail2ban"

From ArchWiki
Jump to: navigation, search
(Installation: Added usage)
(Hardening: Use ReadWritePaths (with if exists statement), ProtectSystem, etc. in example. Clean-up instructions.)
Line 24: Line 24:
 
== Hardening ==
 
== Hardening ==
  
Currently, fail2ban must be run as root. Therefore, you may wish to consider hardening the process with systemd. Ref:[http://0pointer.de/blog/projects/security.html systemd for Administrators, Part XII]
+
Currently, fail2ban must be run as ''root''. Therefore, you may wish to consider hardening the process with [[systemd]].
  
=== Capabilities ===
+
For added security, consider limiting fail2ban privileges by [[Systemd#Editing provided units|drop-in]] configuration file for {{ic|fail2ban.service}}:
  
For added security, consider limiting fail2ban capabilities by specifying {{ic|CapabilityBoundingSet}} in the [[Systemd#Editing provided units|drop-in configuration file]] for the provided {{ic|fail2ban.service}}:
+
{{hc|/etc/systemd/system/fail2ban.service.d/override.conf|2=
 
 
{{hc|/etc/systemd/system/fail2ban.service.d/capabilities.conf|2=
 
 
[Service]
 
[Service]
CapabilityBoundingSet=CAP_DAC_READ_SEARCH CAP_NET_ADMIN CAP_NET_RAW
+
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
 
}}
 
}}
  
In the example above, {{ic|CAP_DAC_READ_SEARCH}} will allow fail2ban full read access, and {{ic|CAP_NET_ADMIN}} and {{ic|CAP_NET_RAW}} allow setting of firewall rules with [[iptables]]. Additional capabilities may be required, depending on your fail2ban configuration. See {{man|7|capabilities}} for more info.
+
The {{ic|CapabilityBoundingSet}} parameters {{ic|CAP_DAC_READ_SEARCH}} will allow fail2ban full read access to every directory and file and {{ic|CAP_NET_ADMIN}} with {{ic|CAP_NET_RAW}} allow setting of firewall rules with [[iptables]]. See {{man|7|capabilities}} for more info.
 
 
=== Filesystem Access ===
 
  
{{Note|On some systems this might lead to fail2ban not working. So, first try without, before hardening fail2ban}}
+
By using {{ic|1=ProtectSystem=strict}} the [[filesystem]] hierarchy will only be read-only, {{ic|ReadWritePaths}} allows fail2ban to have write access on required paths.
  
Consider limiting file system read and write access by using ''ReadOnlyDirectories'' and ''ReadWriteDirectories'', under the {{ic|[Service]}} section. For example:
+
Finally, [[append]] {{ic|/etc/fail2ban/fail2ban.conf}} with the correct {{ic|logtarget}} path:
ReadOnlyDirectories=/
+
{{hc|/etc/fail2ban/fail2ban.conf|<nowiki>
ReadWriteDirectories=/var/run/fail2ban /var/lib/fail2ban /var/spool/postfix/maildrop /tmp /var/log/fail2ban
+
# Option: logtarget
In the example above, this limits the file system to read-only, except for {{ic|/var/run/fail2ban}} for pid and socket files, and {{ic|/var/spool/postfix/maildrop}} for [[postfix]] sendmail. Again, this will be dependent on you system configuration and fail2ban configuration. The {{ic|/tmp}} directory is needed for some fail2ban actions. Note that adding {{ic|/var/log/fail2ban}} is necessary if you want fail2ban to log its activity. Make sure all the directories exist, or you will get error code 226 on starting the service. And modify logtarget in {{ic|/etc/fail2ban/fail2ban.conf}}:
+
# Notes.: Set the log target. This could be a file, SYSLOG, STDERR or STDOUT.
logtarget = /var/log/fail2ban/fail2ban.log
+
#        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
 +
</nowiki>}}
  
 
== Configuration ==
 
== Configuration ==

Revision as of 13:31, 20 June 2018

ro:Fail2ban 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.

Warning: Using an IP banning software will stop trivial attacks but it relies on an additional daemon and successful logging. Additionally, if the attacker knows your IP address, they can send packets with a spoofed source header and get your IP address banned.

Installation

Install fail2ban.

If you want Fail2ban to send an email when someone has been banned, you have to configure SSMTP (for example).

Usage

Enable/start fail2ban.service.

Hardening

Currently, fail2ban must be run as root. Therefore, you may wish to consider hardening the process with systemd.

For added security, consider limiting fail2ban privileges by drop-in configuration file for fail2ban.service:

/etc/systemd/system/fail2ban.service.d/override.conf
[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

The CapabilityBoundingSet parameters CAP_DAC_READ_SEARCH will allow fail2ban full read access to every directory and file and CAP_NET_ADMIN with CAP_NET_RAW allow setting of firewall rules with iptables. See capabilities(7) for more info.

By using ProtectSystem=strict the filesystem hierarchy will only be read-only, ReadWritePaths allows fail2ban to have write access on required paths.

Finally, append /etc/fail2ban/fail2ban.conf with the correct logtarget path:

/etc/fail2ban/fail2ban.conf
# 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

Configuration

Note: Due to the possibility of the jail.conf file being overwritten or improved during a distribution update, it is recommended to provide customizations in a jail.local file, or separate .conf files under the jail.d/ directory, e.g. jail.d/ssh-iptables.conf.

Default jails

Jails for many different services are already present in /etc/fail2ban/jail.conf but not enabled by default. You can copy the section headers into a .local file of your choice, enable them (and optionally override settings).

Restart fail2ban.service to test your configuration. Watch out for "file not found errors" from fail2ban-client if the fail2ban service fails to start. Adjust the paths paths-arch.conf or jail.local as needed. Many of the default jails might not work out of the box.

Custom SSH jail

Warning: If the attacker knows your IP address, they can send packets with a spoofed source header and get your IP address locked out of the server. SSH keys provide an elegant solution to the problem of brute forcing without these problems.

Edit /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 ip6tables.service.

Note: If your firewall is shorewall, replace iptables with shorewall. You can also set BLACKLIST to ALL in /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:

LogLevel VERBOSE

in your /etc/ssh/sshd_config. Else, password failures are not logged correctly.

See also