[Feature] Register login attemps in log file

[JorTurFer]

Actually the system has its own brute force prevent system. The problem with it is that the system bans a user but not bans the IP. This makes possible to execute bruteforce attack to different users from the same origin. I understand that this is difficult to manage and my propouse is log a trace that can be monitoriced with another softwre like fail2ban.

Expected behavior Logs related with failed login attemps are available in someplace

Have a idea on how to fix? Idealy, the http response code after failed login attemp is a 401 instead a simple 302 in order to monitor nginx logs. I can imagine that this change is a very big change in the application, so if the backend registers in the log file the failed login attemps with information related with the origin IP would be great!

[github-actions[bot]]

Thank you for submitting your first issue. Please make sure it follows our Issue Template and you have provided all information.' first issue

[HDVinnie]

https://github.com/HDInnovations/UNIT3D-Community-Edition/discussions/1616

[Wiilf]

What's all the fuss about this? Simply add a INT value column to torrent table, and on each login exception thrown, UPDATE table column value = value + 1, and check for it at login, what we do is when it reaches 3, our PEAR mail class issues a email about 3 failed logins and includes a "Reset Password" button. This can go any which way (turn off account, etc etc). Adding IP logging should be another VARCHAR value as this is intended to track IP attempts. We don't use Unit3D, in-house script.

[JorTurFer]

Sorry @HDVinnie , I didn't see that post, I will public in the correct place :)

@Wiilf I am agree with you that is a think that I can fix by myself, the point here is that I think that is a good idea to introduce that feature in the main repo. The reason is that is not the same the computational effort if you deny the request inside the kernel (using fail2ban to manage iptables) than deny the request inside the application during the request pipeline in the web server. In the first situation you can deny a lot of threat with a very low resource cost, but in the second situation you need to use a lot of resources to resources, just to handle that request, process them, get the information from the database (or cache), and return the response. I feel UNIT3D as a massive software, if you tracker has several thousand users you need to optimize the resource consumption. This is just my opinion :)

[Zorlin]

The core of the issue is you need to use the template for submitting an issue so it's a lot easier to deal with.

[Wiilf]

IMO I would add SQL/exception/announce/bdecode logging to a SQL table and add whatever it is you do to add to your panel, and track the reports. Even testing announce BEPs (done lots this year alone), you know exactly what's going on. Try / catch and perform exception variable to SQL insert => logging table. This can be extended incredibly, as I might do it for the sake of it this weekend, is adding bug reporting/tracking/progress/notes/etc for any fault event within our tracker community so it be productive and assigned between staff users as tasks and BEP work further on.