Brute-Force Protection for user logins

Infinite Scale
1

Hi,

is there brute force protection against failed login attempts? With that I mean something like in ownCloud (php version) where there is the option to set the amount of attempts and ban seconds (admin → settings → admin/security).

If there is the option, how can if be configured?

If there is not, would you advise to use something like fail2ban and is there an example configuration somewhere available? If there is none available, I will hack something together with the help of the logs and fail2ban and can contribute it here if you point me in the direction where to put that (Github/Docs).

Fyi, I have tried logging in with the wrong password like a hundred times but no brute force protection / penalty kicked in.

Current setup:

  • Using the docker compose example (from your “Discover oCIS with Docker” guide on your .dev page)
  • Image: owncloud/ocis:2.0.0
  • OCIS_INSECURE: “false”
  • PROXY_TLS: “false”
  • Reverse proxy with nginx (nginx manages ssl)
2

Hi,

no, Infinite Scale does not have a built in brutforce protection yet. That is something that probably should be done even before the IDP, a load balancer or whatever component sees the requests first.

Setting up fail2ban might be a great idea, but that is subject to the concrete setup.
I’d appreciate if you would share your fail2ban setup for your installation.

Klaas

1 Like
3

Hi again,

I managed to hack something together which works good enough for me.

The log file for a failed login attempt looks like this:

{"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"}

To make it work with fail2ban, two-lines of the logs are needed because the IP address of the source (123.123.123.123 in this case) is not in the line where the failed login attempt is detected.

The fail2ban setup is the following:

Fail2ban filter file (/etc/fail2ban/filter.d/ocis.conf):

#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 increase, in case some other log slips in between
maxlines = 2

Fail2ban jail file (/etc/fail2ban/jail.d/ocis.conf):

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

Add OCIS_LOG_FILE: “/path/to/ocis/logs/ocis.logs” to the environment/docker compose file. Make sure to create a volume and bind it depending on your setup when using docker.

Nginx config:

server {

        server_name yourservername.com;

    	listen [::]:443 ssl http2; # managed by Certbot
    	listen 443 ssl http2; # managed by Certbot
    
	ssl certs stuff...


        location / {
                proxy_pass http://localhost:9200;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                client_max_body_size 0;
        }
}

There are two things that need some follow up:

  1. Somebody take a look at the regex, I am not the best at this and it might have some loopholes.
  2. Maybe there are other ways of logging in and the failed attempts look different in the logs, the one addressed above is the regular login from the browser. So it would be appreciated if somebody that knows more about all the possible ways to sign could share the logs for the failed attempts if there are any.

Cheers
Soren

2 Likes