Can you please add support for fail2ban by, creating a log of failed logins with the IP address, date and time stamp.
Thanks
Is there a particular format it needs to be written in? Or fail2ban can read Sonarr's existing log file if this information is written there?
@markus101
Fail2Ban can scan Sonarr's logs but, I am trying to verify that the current format is compatible.
Hi @markus101
I don't think there needs to be much change if any, perhaps just separate logs as I think this could decrease system load when analyzing.
Although, when asked, the fail2ban developers said all that was really needed for compatible was:
a date-time when is failure occurred, better in the system time zone (fail2ban supports several date-time formats, but it can be also configured separately via datepattern parameter)
an unique identifier of the intruder (most the IP address, but if not IP-related it could be also an e-mail, or user, etc)
some message part that obviously identifies a failed attempt (like Authentication failed: invalid password)
As an example:
2018-09-30 23:05:55 WARN AUTH-ERROR: 192.0.2.1 - Authentication failed for user "tester": user unknown
2018-09-30 23:15:03 WARN AUTH-ERROR: 192.0.2.5 - Authentication failed for user "root": user disallowed
2018-09-30 23:18:05 WARN AUTH-ERROR: 192.0.2.8 - Authentication failed for user "admin": invalid password
Note the best practices also:
the unique characteristic of failure (here AUTH-ERROR) as well as the identifier (here IPs) as early as possible in the message (could be found faster and with fewer load during the search);
foreign data (user input), if needed to be logged, should be escaped (if possible) and/or placed at end of line (so the parser does not need to traverse this info to find all expected failure characteristics)
if possible write it into separate log-file (or log-file with few errors) or if logged into systemd-journal resp. rsyslog provide it with some unique marks (e. g. severity: warning/critical, facility: security/auth, etc), to make possible to use selectors (to avoid parasite "traffic" by searching of the failures).
Any progress on this? I would also love to implement a fail2ban jail for Sonarr (and Radarr).
As a work around, what all the cool kids do is not bother with per-service authentication. Put all your services behind a single reverse proxy with authentication and fail2ban. https://hub.docker.com/r/linuxserver/letsencrypt is a popular one combining nginx+fail2ban+automated letsencrypt.
As a work around, what all the cool kids do is not bother with per-service authentication. Put all your services behind a single reverse proxy with authentication and fail2ban. https://hub.docker.com/r/linuxserver/letsencrypt is a popular one combining nginx+fail2ban+automated letsencrypt.
Could you please help me out with fail2ban. I already setup letsencrypt and everything working fine. I just want fail2ban on all services. How can I do that? Thank you :)
You can already implement Fail2Ban with the logs from Sonarr and Apache2. Those should give you the timestamp and IP of the failed login to write a general rule in your fail2ban jails conf file.
As @manad777 said though, just put them behind an authentication proxy. You shouldn't be facing logins to the public without a HTTPS proxy anyways.
All that is needed for Fail2Ban to work with Sonarr (or any other application) is Sonarr having to log failed login attempts (at least timestamp and origin IP of the failed login). From what I can see, failed logins are not being logged at all at the moment (else I missed it).
From there you can have Fail2Ban read those logs, parse with regex and ban the IP.
This way we could use the builtin auth and a reverse proxy for SSL and still have Fail2Ban work just fine.
Putting Sonarr behind reverse proxy works for fail2ban and HTTPs auth, but then it disables the feature of having ical feed sync with calendars because it goes over https, but needs to auth first. Having sonarr implement fail2ban within its own application would give extra security and still allow access to the ical feed sync.
Sorry about the months of delay, but here it is:
[Info] Auth: Auth-Unauthorized ip 10.0.0.10 url 'http://10.0.0.132:8989/sonarr'
[Warn] Auth: Auth-Failure ip 10.0.0.10 username 'test'
[Info] Auth: Auth-Success ip 10.0.0.10 username 'test'
[Info] Auth: Auth-Logout ip 10.0.0.10 username 'test'
[Info] Auth: Auth-Invalidated ip 10.0.0.10
The log entries get output to the console (so syslog) and the sonarr.txt log file, but nowhere else (not even sonarr.debug/trace).
Please note that the ip can also be ipv6, ::1 or the ip of a reverse proxy (I didn't bother doing X-Real-Ip stuff)
I hope that's satisfactory.
PS: build server has some delays, would be 3.0.3.617 or later.
@Taloth
Thank you.
Is this in the wiki
Not yet, but good point. :smile:
Many thanks for adding this support, it will make login very secure.
Btw, is there a Fail2ban jail that should be used now?
Most helpful comment
As a work around, what all the cool kids do is not bother with per-service authentication. Put all your services behind a single reverse proxy with authentication and fail2ban. https://hub.docker.com/r/linuxserver/letsencrypt is a popular one combining nginx+fail2ban+automated letsencrypt.