Add AirBrake for anti-bruteforcing

[LukasReschke]

Should be a relatively easy gain by implementing https://github.com/paragonie/airship/blob/e349a2a2143eadcfc578c05b3715a76476782e6b/src/Engine/Security/AirBrake.php

[jknockaert]

Implementing anti-bruteforcing at the php level is not very efficient (even if it is easy to implement). Ideally a kernel-level firewall mechanism should handle the blocking (which would also provide a degree of protection agains dos-attacking). So I suggest to implement an alternative approach. A possibility is to issue customised messages to a separate log file, which is monitored by file2ban or ossec, and publish the corresponding settings for ossec and fail2ban to handle the customised log.
When implementing an anti-bruteforcing mechanism we should not forget places in the code where e.g. it is possible to change passwords or recovery keys.

[Henni]

@jknockaert as nextcloud is a pure PHP project fail2ban and other similar approaches aren't an option.
But of course everyone is allowed to extend their setup with non-PHP tools, if they have shell access to their server.

[jknockaert]

@Henni Why not implement both approaches? A pure php approach (like sqlite support for the database) and a fail2ban/ossec interface (like postgres support for the database). They're not mutually exclusive.

[Henni]

@jknockaert It seems like there are some simple tutorials on how to setup fail2ban: https://forum.owncloud.org/viewtopic.php?t=28678
There already is a log file which contains failed logins and can be used with fail2ban, so I don't think we need a separate log file.

[jknockaert]

@Henni The problem with the current approach is that the log isn't designed with applications like fail2ban in mind. Between versions the format (what is logged, how it is logged) may change, and not all information that could be useful in a fail2ban context may be logged. At the other side, there's many third party tutorials, most without proper review and supporting them (ie. backward compatibility of the log format) is a pain. So a reference implementation with a separate and well-documented log format would definitely contribute (and function much more efficiently than a php-only implementation).

[Henni]

@jknockaert would you then mind opening a new issue for this? (feel free to mention me :) )

[jknockaert]

I don't think it should be filed as a separate issue. Basically the behaviour to be monitored is the same. Only the action to be triggered is different.

[rullzer]

This is in see: #479