Brute Force Protection Against Failed Login Attempts

Introduction

Implementing a brute force protection against failing login attempts is something that usually should be done before the IDP, the load balancer or whatever component sees the requests first. Setting up Fail2ban parsing logs can be a possibility but is subject to a concrete setup. Note that this document gives an overview and assumes that you are familiar with Fail2ban.

The content has been extracted and adapted from Central, our community page, and is without any claim for correctness and eligibility for support, though feedback is welcomed.

Prerequisites

  • Logging to file needs to be enabled for Infinite Scale. See the OCIS_LOG_FILE for more details.

  • When running a container setup, the Infinite Scale logs need to be available to the host so Fail2ban can access them. Make sure to create a volume to do so.

  • Fail2ban needs to be:

    • installed and a basic setup configured.

    • able to access the Infinite Scale logs.

Configuration

Note, you need at minimum loglevel info for the idm and proxy service to get all required data logged.

The log for a failed login attempt looks like this and consists of two log entries that belong together:

{"level":"error","service":"idm","bind_dn":"uid=someuser,ou=users,o=libregraph-idm","op":"bind","remote_addr":"127.0.0.1:59672","time":"2023-03-20T19:26:04.726564978Z","message":"invalid credentials"}

{"level":"info","service":"proxy","proto":"HTTP/1.0","request-id":"blabla","remote-addr":"123.123.123.123","method":"POST","status":204,"path":"/signin/v1/identifier/_/logon","duration":135.139963,"bytes":0,"time":"2023-03-20T19:26:04.727076622Z","message":"access-log"}

  • The first log entry is used to detect the invalid credentials message only but it does not contain the correct IP address.

  • The other related log entry contains the needed IP address for further processing.

  • There can be more lines in between the first log message and the one holding the correct address. These get filtered out by the regex part ((.|\n)*) in the failregex definition. One of the cases where the two logs are not directly consecutive is when enabling the Infinite Scale debug mode.

Fail2ban Setup

Make sure to adapt the paths to configuration files according to the environment used. For ease of reading and because failregex supports multi-line, the regex used is multi-lined to match the description above, though you can write it all in one line. It is recommended to double check with fail2ban-regex.

  • Create a Fail2ban filter file /etc/fail2ban/filter.d/ocis.conf with the following example content:

    # ocis.conf
[Definition]
failregex = ^.*"service":"idm".*"message":"invalid credentials"
            ((.|\n)*)
            remote-addr"."<HOST>","method":"POST","status":204.*

ignoreregex =

datepattern = ^%%Y-%%b-%%dT%%H:%%M:%%S\.*Z

[Init]
# Maybe to be increased, in case more logs slip in between.
# Set to 3 to include lines added when in debug mode
maxlines = 3

  • Create a Fail2ban jail file /etc/fail2ban/jail.d/ocis.conf with the following example content, use the correct path to access the ocis.log file and change any settings according to your needs:

    [ocis]
enabled = true
filter = ocis
logpath = /path/to/ocis/logs/ocis.logs
maxretry = 3
findtime = 3600
bantime = 60
action = iptables-allports

After creating the necessary files, restart Fail2ban and test the setup.