Log of failed login attempts

[Don42]

If Seahub would log failed login attempts with IP and username, fail2ban could be used to prevent brute force attacks against seafile. I know there already is a captcha feature to do this. But I think with current captcha solving programs the fail2ban approach is more secure.

[shoeper]

Afaik this is done in pro edition.

Edit: I was wrong, there is no log file.

[Don42]

As far as I can tell, the pro edition only displays that in the web interface. But I cannot tell how I would be implemented in the backend.

[freeplant]

@Don42 Yes, you are right. We haven't implement it yet. How fail2ban can help if we log the failed login attempts with IP and username to a file?

[shoeper]

fail2ban can keep an eye on the log file and create iptable rules if there are more than x login tries within y minutes from the same ip. This can help against bruteforce attacks, as long as they aren't too distributed.

[Don42]

@freeplant It is exactly as @shoeper described. The username is just for debugging purposes.

[lins05]

@Don42 I think this can be achieved by using fail2ban to watch the seafile http access logs on your seafile server.

• If you're running seafile with nginx, add a fail2ban jail based to filter patterns like POST /seahub/accounts/login.* 403 in /var/log/nginx/access.log.
• If you're running seafile's builtin server (guincorn), add a fail2ban jail to watch "/path/to/seafile-server-latest/runtime/access.log.

[Don42]

@lins05 That sounds like a good idea. I am using nginx as a reverse proxy, with the Config file from the installer. https://github.com/SeafileDE/seafile-server-installer/blob/master/community-edition/seafile-ce_debian

When I try to log in with wrong password or username the login fails as expected, but nginx still logs a 200 status code for the request.

[rawbertp]

I second that! There are no useful log entries in the nginx access log in case of a failed login.

[gdm85]

I think the status code should not be 200 in case of a failed login attempt.

[shoeper]

I agree on it. Sending 403 in case of login failure would be fine.

[freeplant]

The login page posts a form to the server and server returns a normal page with error message. 403 can't be returned.

[shoeper]

Having a look at https://stackoverflow.com/questions/12476452/how-can-i-return-http-status-code-204-from-a-django-view it seems like there is a way to return a custom status code. What would be the problem when returning the login page with a 403 error code? (or maybe also some other error code)

[gdm85]

It is indeed possible in django and already being used for the 404 not found responses. As far as I have dug out in the code, it would be a matter of adding a return value to auth_login, not even a complex patch.

Official documentation reference: https://docs.djangoproject.com/en/1.9/ref/request-response/#django.http.HttpResponse.status_code

Also, being this for security hardening, I consider it (personally) as very important.

[shoeper]

To keep the issue tracker clean this feature request has been moved to https://forum.seafile-server.org/t/log-of-failed-login-attempts/4343

[gdm85]

@shoeper in this open source project feature requests are moved to forums?

[shoeper]

What doesopen source have to do with the way feature requests are kept track of?

[gdm85]

@shoeper using an issue tracker on a collaborative platform like Github favors open source development rather than burying issues/feature requests in a forum. But yes, it applies to any software project probably: forums are not for issue tracking/feature requests, as you want to keep them close to the code, but of course every project can do as it's decided and works best for it, I will just politely opt out and definitely not register in a forum to follow this feature request.

[shoeper]

I did talk back to the developers and we did have very many issues on github. The result was: to keep the issue tracker clean, we keep the feature requests on the forums. This way it is much easier to work on the bugs using github. Bugs need to get fixed, but feature requests do often have very specific usecases in mind and might not always be the best for the majority - for the project. Of course there might be projects handling it another way, but we've decided to keep track of feature requests on the forums for now. Any feedback is always appreciated.

By the way, you don't need to register you can login using github at the forum.

[gdm85]

I am under the impression that many other web applications do return a 403 in case of login failed (instead of a 200 which means everything went fine), thus I thought it's more of a bug than a feature request (application reports request successful when it's not really). But of course I do not want to discuss that, if it's considered a feature request fine - thanks for the info! :)

[shoeper]

Yes, I did think the same. freeplant - one of the heads behind Seafile - did say it wouldn't be possible that easy for some reason. That's why it has been changed to a feature request.

@freeplant could you shortly explain why returning a 403 (or some other return code) is not possible?

[gdm85]

@shoeper ok, thanks for the clarification. (For the records, I had already attempted to make a pull request for this a few weeks ago, but stopped half-way because I am not really fluent in django/python)