Fail2ban - ArchWiki

# Fail2ban

From ArchWiki

Related articles

- sshguard
- Security

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.

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

### systemd

Enable the `fail2ban.service` unit.

## Hardening

Currently, fail2ban must be run as root. Therefore, you may wish to consider hardening 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 capabilities(7) for more info.

### Filesystem Access

Note: On some systems this might lead to fail2ban not working. So, first try without, before hardening fail2ban

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

    ReadOnlyDirectories=/
    ReadWriteDirectories=/var/run/fail2ban /var/lib/fail2ban /var/spool/postfix/maildrop /tmp /var/log/fail2ban

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. The `/tmp` directory is needed for some fail2ban actions. Note that adding `/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 `/etc/fail2ban/fail2ban.conf`:

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

### Paths

There is currently basic support for archlinux, to activate that configuration, add or alter the following section in the `jail.local` file:

    [INCLUDES]
    before = paths-arch.conf

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

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

- Using a Fail2Ban Jail to Whitelist a User
- Optimising your Fail2Ban filters
- Fail2Ban and sendmail
- Fail2Ban and iptables
- Fail2Ban 0.8.3 Howto
- Monitoring the fail2ban log

Categories:

- Firewalls
- Secure Shell