Difference between revisions of "Fail2ban"

From ArchWiki
Jump to: navigation, search
(Tidied up section on initscripts and systemd configuration)
m (mv warning to the top as there is currently no general config section on the tool functionality; fits better here than in the ssh-jail section)
(24 intermediate revisions by 9 users not shown)
Line 3: Line 3:
 
{{Warning|Using an IP blacklist will stop trivial attacks but it relies on an additional daemon and successful logging (the partition containing /var can become full, especially if an attacker is pounding on the server). Additionally, if the attacker knows your IP address, they can send packets with a spoofed source header and get you locked out of the server. [[SSH keys]] provide an elegant solution to the problem of brute forcing without these problems.}}
 
{{Warning|Using an IP blacklist will stop trivial attacks but it relies on an additional daemon and successful logging (the partition containing /var can become full, especially if an attacker is pounding on the server). Additionally, if the attacker knows your IP address, they can send packets with a spoofed source header and get you locked out of the server. [[SSH keys]] provide an elegant solution to the problem of brute forcing without these problems.}}
  
[http://www.fail2ban.org/wiki/index.php/Main_Page Fail2ban] scans log files like {{ic|/var/log/pwdfail}} or {{ic|/var/log/apache/error_log}} and bans IP that makes too many password failures. It updates firewall rules to reject the IP address.  
+
[http://www.fail2ban.org/wiki/index.php/Main_Page Fail2ban] scans various textual log files and bans IP that makes too many password failures by updating firewall rules to reject the IP address, similar to [[Sshguard]].  
  
==Installation==
+
{{Warning|For correct function it is essential that the tool parses the IP addresses in the log correctly. You should always '''test''' the log filters work as intended per application you want to protect.}}
First, install [[Gamin]] so that Fail2ban can detect modification to the log files:
+
# pacman -S gamin
+
  
Then, install {{Pkg|fail2ban}}:
+
== Installation ==
# pacman -S fail2ban
+
  
If you want Fail2ban to send an email when someone has been banned, you have to configure [[SSMTP]] (for example). You will also have to install {{Pkg|whois}} to get some information about the ''attacker''.
+
Install {{Pkg|fail2ban}} from the [[official repositories]].
# pacman -S whois
+
===initscripts===
+
Now you can start the {{Ic|fail2ban}} daemon:
+
# /etc/rc.d/fail2ban start
+
  
You can add it into DAEMONS array in {{ic|/etc/rc.conf}}:
+
If you want Fail2ban to send an email when someone has been banned, you have to configure [[SSMTP]] (for example).
DAEMONS=(... fail2ban ...)
+
===systemd===
+
If using systemd, then use:
+
# systemctl start fail2ban.service
+
  
And enable it at boot if you like:
+
=== systemd ===
# systemctl enable fail2ban.service
+
 
 +
Use the service unit {{ic|fail2ban.service}}, refer to [[systemd]] for instructions.
 +
 
 +
== Hardening ==
  
==Hardening==
 
 
Currently, fail2ban requires to run as root, therefore you may wish to consider some additional hardening on the process with systemd. Ref:[http://0pointer.de/blog/projects/security.html systemd for Administrators, Part XII]
 
Currently, fail2ban requires to run as root, therefore you may wish to consider some additional hardening on the process with systemd. Ref:[http://0pointer.de/blog/projects/security.html systemd for Administrators, Part XII]
===Capabilities===
+
 
For added security consider limiting fail2ban capabilities by adding ''CapabilityBoundingSet'' under {{ic|[Service]}} section of the systemd service file, e.g.:
+
=== Capabilities ===
CapabilityBoundingSet=CAP_DAC_READ_SEARCH CAP_NET_ADMIN CAP_NET_RAW
+
 
In the example above, '''CAP_DAC_READ_SEARCH''' will allow fail2ban full read access, and '''CAP_NET_ADMIN''' and '''CAP_NET_RAW''' allow setting of firewall rules with [[iptables]]. Additional capabilities may be required, depending on your fail2ban configuration. See {{ic|man capabilities}} for more info.
+
For added security consider limiting fail2ban capabilities by specifying {{ic|CapabilityBoundingSet}} in the [[Systemd#Editing_provided_unit_files|drop-in configuration file]] for the provided {{ic|fail2ban.service}}:
===Filesystem Access===
+
 
 +
{{hc|/etc/systemd/system/fail2ban.service.d/capabilities.conf|2=
 +
[Service]
 +
CapabilityBoundingSet=CAP_DAC_READ_SEARCH CAP_NET_ADMIN CAP_NET_RAW
 +
}}
 +
 
 +
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 {{ic|man capabilities}} for more info.
 +
 
 +
=== Filesystem Access ===
 +
 
 
Also considering limiting file system read and write access, by using ''ReadOnlyDirectories'' and ''ReadWriteDirectories'', again under the under {{ic|[Service]}} section. For example:
 
Also considering limiting file system read and write access, by using ''ReadOnlyDirectories'' and ''ReadWriteDirectories'', again under the under {{ic|[Service]}} section. For example:
 
  ReadOnlyDirectories=/
 
  ReadOnlyDirectories=/
 
  ReadWriteDirectories=/var/run/fail2ban /var/spool/postfix/maildrop
 
  ReadWriteDirectories=/var/run/fail2ban /var/spool/postfix/maildrop
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.
+
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. Note that adding {{ic|/var/log}} is necessary if you want fail2ban to log its activity.
 +
 
 +
== SSH jail ==
  
==SSH jail==
 
 
Edit {{ic|/etc/fail2ban/jail.conf}} and modify the ssh-iptables section to enable it and configure the action.
 
Edit {{ic|/etc/fail2ban/jail.conf}} and modify the ssh-iptables section to enable it and configure the action.
  
Line 50: Line 51:
 
  logpath  = /var/log/auth.log                                                                     
 
  logpath  = /var/log/auth.log                                                                     
 
  maxretry = 5
 
  maxretry = 5
 +
 +
Fail2Ban from version 0.9 can also read directly from the systemd journal by setting {{ic|1=backend = systemd}}.
  
 
If your firewall is shorewall:
 
If your firewall is shorewall:
Line 66: Line 69:
 
in your {{ic|/etc/ssh/sshd_config}}. Else, password failures are not logged correctly.
 
in your {{ic|/etc/ssh/sshd_config}}. Else, password failures are not logged correctly.
  
==See also==
+
== See also ==
*[[sshguard]]
+
 
 +
* [[sshguard]]

Revision as of 23:23, 18 March 2014

Warning: Using an IP blacklist will stop trivial attacks but it relies on an additional daemon and successful logging (the partition containing /var can become full, especially if an attacker is pounding on the server). Additionally, if the attacker knows your IP address, they can send packets with a spoofed source header and get you locked out of the server. SSH keys provide an elegant solution to the problem of brute forcing without these problems.

Fail2ban scans various textual log files and bans IP that makes too many password failures by updating firewall rules to reject the IP address, similar to Sshguard.

Warning: For correct function it is essential that the tool parses the IP addresses in the log correctly. You should always test the log filters work as intended per application you want to protect.

Installation

Install fail2ban from the official repositories.

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

systemd

Use the service unit fail2ban.service, refer to systemd for instructions.

Hardening

Currently, fail2ban requires to run as root, therefore you may wish to consider some additional hardening on the process with systemd. Ref:systemd for Administrators, Part XII

Capabilities

For added security consider limiting fail2ban capabilities by specifying CapabilityBoundingSet in the drop-in configuration file for the provided fail2ban.service:

/etc/systemd/system/fail2ban.service.d/capabilities.conf
[Service]
CapabilityBoundingSet=CAP_DAC_READ_SEARCH CAP_NET_ADMIN CAP_NET_RAW

In the example above, CAP_DAC_READ_SEARCH will allow fail2ban full read access, and CAP_NET_ADMIN and CAP_NET_RAW allow setting of firewall rules with iptables. Additional capabilities may be required, depending on your fail2ban configuration. See man capabilities for more info.

Filesystem Access

Also considering limiting file system read and write access, by using ReadOnlyDirectories and ReadWriteDirectories, again under the under [Service] section. For example:

ReadOnlyDirectories=/
ReadWriteDirectories=/var/run/fail2ban /var/spool/postfix/maildrop

In the example above, this limits the file system to read-only, except for /var/run/fail2ban for pid and socket files, and /var/spool/postfix/maildrop for postfix sendmail. Again, this will be dependent on you system configuration and fail2ban configuration. Note that adding /var/log is necessary if you want fail2ban to log its activity.

SSH jail

Edit /etc/fail2ban/jail.conf and modify the ssh-iptables section to enable it and configure the action.

If your firewall is iptables:

[ssh-iptables]
enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]                                         
           sendmail-whois[name=SSH, dest=your@mail.org, sender=fail2ban@mail.com]
logpath  = /var/log/auth.log                                                                    
maxretry = 5

Fail2Ban from version 0.9 can also read directly from the systemd journal by setting backend = systemd.

If your firewall is shorewall:

[ssh-shorewall]
enabled  = true
filter   = sshd
action   = shorewall
           sendmail-whois[name=SSH, dest=your@mail.org, sender=fail2ban@mail.com]
logpath  = /var/log/auth.log                                                                    
maxretry = 5
Note: You can set BLACKLISTNEWONLY to No 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