First, install [[Gamin]] so that Fail2ban can detect modification to the log files:

+

First, install python2-pyinotify so that Fail2ban can detect modification to the log files:

−

# pacman -S gamin

+

# pacman -S python2-pyinotify

Then, install {{Pkg|fail2ban}}:

Then, install {{Pkg|fail2ban}}:

Line 14:

Line 14:

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''.

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''.

# pacman -S whois

# pacman -S whois

+

===systemd===

+

Use the service unit fail2ban.service, consult [[systemd]] for instructions

−

Now you can start the {{Ic|fail2ban}} daemon:

+

Please note that this currently requires {{ic|syslog-ng}} logging. This is because a pure systemd {{ic|journalctl}} does not log to {{ic|/var/log/auth.log}} which is parsed by the service in default.

−

# /etc/rc.d/fail2ban start

−

You can add it into DAEMONS array in {{ic|/etc/rc.conf}}:

+

==Hardening==

−

DAEMONS=(... fail2ban ...)

+

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===

−

If using systemd, the service file that ships with fail2ban does not create the working directly and will fail. In stead, override with your own service file:

+

For added security consider limiting fail2ban capabilities by adding ''CapabilityBoundingSet'' under {{ic|[Service]}} section of the systemd service file, e.g.:

−

+

CapabilityBoundingSet=CAP_DAC_READ_SEARCH CAP_NET_ADMIN CAP_NET_RAW

−

{{hc|/etc/systemd/system/fail2ban.service|<nowiki>

+

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.

−

[Unit]

+

===Filesystem Access===

−

Description=Ban IPs that make too many password failures

+

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

−

After=syslog.target network.target

+

ReadOnlyDirectories=/

−

+

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

−

[Service]

+

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.

−

Type=forking

−

PIDFile=/run/fail2ban/fail2ban.pid

−

ExecStartPre=/bin/mkdir -p /var/run/fail2ban

−

ExecStart=/usr/bin/fail2ban-client start

−

ExecReload=/usr/bin/fail2ban-client reload

−

ExecStop=/usr/bin/fail2ban-client stop

−

−

[Install]

−

WantedBy=multi-user.target</nowiki>}}

−

−

Then use:

−

# systemctl start fail2ban.service

−

−

And enable it at boot if you like:

−

# systemctl enable fail2ban.service

==SSH jail==

==SSH jail==

Revision as of 20:51, 23 January 2013

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 log files like /var/log/pwdfail or /var/log/apache/error_log and bans IP that makes too many password failures. It updates firewall rules to reject the IP address.

Hardening

Capabilities

For added security consider limiting fail2ban capabilities by adding CapabilityBoundingSet under [Service] section of the systemd service file, e.g.:

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:

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.