Limit Number of Failed Login Attempts

[richardwlu]

Your Rocket.Chat version: 0.24

Is there a way to limit the number of failed login attempts for a user account? How much security can be put into place from this end?

This should be helpful for those of us who run an instance that is available on the public internet.

[engelgabriel]

I believe there is already. 5 per second, but we can change it.

[richardwlu]

That sounds good. Is there a way to also block based on IP?

[richardwlu]

I forgot to mention, does it still apply for LDAP users?

[engelgabriel]

Applies to all method calls, so it still apply for LDAP users.

[richardwlu]

And if there is a way to set how many attempts for how long til we lock it and possibly get a notification, that would be ideal.

[pa-de-solminihac]

👍

I intended to secure it with fail2ban but I did not find where these failed login attempts are logged. I am using https://github.com/RocketChat/Deploy.to.Cloud/tree/master/GenericLinux to deploy, with this docker-compose.yml:

db:
  image: mongo
  volumes:
    - ./data/runtime/db:/data/db
    - ./data/dump:/dump
  command: mongod --smallfiles
web:
  image: rocketchat/rocket.chat
  environment:
    - MONGO_URL=mongodb://db:27017/meteor
    - ROOT_URL=https://rocket.domain.com
    - MAIL_URL=smtp://user@domain.com:password@smtp.example.com:465
  links:
    - db:db
  volumes:
    - logs:/home/app/logs
  expose:
    - "3000"
  ports:
    - "3000:3000"

Anyway, 5 per second is a much too high limit for my needs (and it does not seem to work, maybe I missed something?).

[ghost]

Hi I am also trying to reduce the chances of brute forcing our LDAP via Rocket Chat. Fail2Ban is useless until there is error reporting in the nginx log I cannot act upon the brute forcing.

Interestingly the api/login route will provide a 401 (HTTP/1.1 401 Unauthorized) response back and into the access log in nginx but normal users are not coming in via API calls.

Can you provide some timescales to add the standard user login fail 401 error output back to nginx? That would sort this problem out allowing me to use fail2ban.

p.s. fail2ban has worked to block /api/logon brute forcing :-)
Thanks for your help.

Mark

[engelgabriel]

@mdearlove I am not sure how we would be able to do that. All the logins are done via a single open web-socket connection, so there is not 401. Maybe the only way would be to redirect the browser to a route that returns 401 so NGINX and pick that up. @rodrigok what do you think?

[rodrigok]

@engelgabriel If the DDOS is scripted, redirect to another route probably will not work. Since the login requires a WebSocket connection, normal tools for DDOS does not work, so it's harder to do that on Rocket.Chat.

We can add the ability to ban IPs based on loggin or connection attempts.

[engelgabriel]

@rodrigok one alternative is to get Rocket.Chat it self to record on the logs the failed login attempt, so @mdearlove can configure fail2ban to monitor our logs too and this would make it work. Makes sense?

[ghost]

@rodrigok @engelgabriel I believe that would be do-able from a fail2ban pov as it uses a regex to spot the machine behaviour to identify the issue. The log entry would also need to identify the source IP of the request so that fail2ban can take action.

[engelgabriel]

@rodrigogs wan we log failed login attempts with the IP? This would be very useful for everyone.

[ghost]

@rodrigok @engelgabriel Hi guys Ive been away sunny my ar$e for several weeks :-). Have you made any progress on this issue? Thanks in advance.

[pa-de-solminihac]

@engelgabriel i'm afraid you notified @rodrigogs instead of @rodrigok

BTW, I believe this is still a much needed improvement for security

[mddvul22]

I agree with pa-de-solminihac that 5 per second is way too high. But regardless, @pa-de-solminihac you suggested earlier on this ticket that the block didn't seem to work. Is that still the case?

[juniorsemacento]

@engelgabriel @rodrigok would be great to have this feature enabled... so we can monitor the logs and use fail2ban.. any idea if it will be available any time soon? Thanks

[dmeier86]

+1
Push

[Marx1st]

+1
Push

[mrsimpson]

+1

[Adirio]

Is the 5-attempts-per-second rule still aplying? If so, is it configurable? Gitlab, for example, offers a limit and period variables to be set, defaulting to 6 attempts per minute (source).

[ruKurz]

+1

[secopsbot]

+1

[privacyintchat]

i would love some simple access-log like apache is creating, so fail2ban can be activated +1

[zzeesstt]

+1

[isdneuroimaging]

@engelgabriel This security-related issue is rather old. Is there a change implemented already? Still 5 per second limit for login attempts? 5 per minute would sound more reasonable to me!

[isdneuroimaging]

@engelgabriel @rodrigok Any update on this critical security issue? Thanks!

[akerkau]

+1 for enabling rocket.chat itself to record the failed login attempt on the logs, so I can configure fail2ban to monitor application logs

[mannp]

+1 here too please.

[isdneuroimaging]

@engelgabriel @rodrigok I dont' understand why there is no comment regarding such a critical security issue? Many thanks!

[stardude900]

+1

[isdneuroimaging]

@engelgabriel @rodrigok Why no response?

[ruKurz]

Would be great to see a comment/solution for this issue.

[horstepipe]

can anyone guide through a fail2ban implementation?

[dpunkturban]

a fail2ban implementation would be nice :)

[ruKurz]

What I do like about Issue #6152 is the title. It states out the actual motivation "protection against brute force attacks" in the foreground.

What I like about #13387 is the proximity to a task that is easy to implement and independent of third party solutions such as fail2ban.

[Tom5421]

+1

Really need this simple security feature.

[m-roshani]

+1

[wellington1993]

+1

[ulit3]

+1

[ankar84]

@engelgabriel @rodrigok any updates about that security issue?

[arunoruto]

+1

[Tulkas59]

I really need this feature too. Just a log line with attacker's IP and fail2ban will do the rest :-)

[ruKurz]

IMHO limit failed login should be featured by the application itself.

I think logging failed logins would be a first step in the right direction (#13387). One could then install fail2ban to block sources from which attacks are made. But this issue here (#2737) aims to limit the number of failed logins. And this is what you really want: Block user accounts that are the target of an attack.

Besides the fact that Fail2Ban must be installed as a system component and is therefore not part of the application, login attempts per user should be stored in the database. This allows the locking of user accounts after a certain number of failed login attempts.

And then it would be very easy for any operator of Rocket.Chat (without installing additional log analysis tools) to take effective measures against brute force attacks.

EDIT: As discussed in issue #6152, better to lock of users is to delay the time until the next login attempt after several consecutive incorrect password entries. For example, if you make 5 failed attempts, your iPhone will lock for 1 minute, 6 attempts will lock it for 5 minutes, 7 will lock it for 15, and anything more than that will lock it for 1 hour.

[Tulkas59]

Thank you for mentioning issue #13387 !

Of course it would be better if it was featured by the application itself. I wanted to emphasize the fact that the log-based solution is quite easy to implement :-)

[zzeesstt]

+1 push