Fix fail2ban config when using API / wallabag app
lapineige opened this issue · comments
When using the API via wallabag mobile app, fail2ban log some connections, and might ban the app for a while.
See: https://forum.yunohost.org/t/official-app-wallabag2/3966/30 (in French, but I can translate it if needed).
But it is not supposed to do that…
When looking at the log, there is indeed an "Authentication failure" message.
app.ERROR: Authentication failure for user "", from IP "some ip address", with UA: "okhttp/4.2.2". [] []
(my credentials are correct)
And that's exactly maching our regex… Does Wallabag official mobile app perform some connection test before actually doing something with the API ? (ping @di72nn @Strubbl @tcitworld, maybe you have more information about this ?)
A test that would be blocked by our SSO ? 🤔
I don't really know what's the best solution to tackle this.
I guess the easiest way is to change the regex to exclude that case. But if we exclude UA okhttp, will it create a potential security breach ?
If the app performs some kind of test, with no authentification, is it possible to allow it to pass throught the SSO ? 🤔
Also when a login is failed in the web interface, there are several messages in the log related to that failed login:
app.ERROR: Authentication failure for user (and so on, that's the one we use right now)
security.INFO: Authentication request failed.
security.DEBUG: Authentication failure, redirect triggered. {"failure_path":"/login"}
With the API, it's only the first one.
I wonder if we could try to change the regex to adapt to another message 🤔
PS: btw when looking at the look file, I saw that error message:
request.ERROR: Uncaught PHP Exception Symfony\Component\HttpKernel\Exception\NotFoundHttpException: "Wallabag\CoreBundle\Entity\Entry object not found." at /var/www/wallabag2/vendor/sensio/framework-extra-bundle/Request/ParamConverter/DoctrineParamConverter.php line 66 {"exception":"[object] (Symfony\Component\HttpKernel\Exception\NotFoundHttpException(code: 0): Wallabag\CoreBundle\Entity\Entry object not found. at /var/www/wallabag2/vendor/sensio/framework-extra-bundle/Request/ParamConverter/DoctrineParamConverter.php:66)"}
Wtf is that…
Regarding app.ERROR: Authentication failure for user ""...: wallabag/android-app#789 and wallabag/wallabag#3575.
The error is most likely to happen when app's access token expires (after the error the app requests new tokens).
I can't remember why, but that error seems to come up with /api/version access (the error follows the request.INFO: Matched route "api_get_version". ... line in the same log).
The app does set auth headers for the /api/version call even though it doesn't have to (it is easier to set headers to all requests, than to make an exception for this API method). And the servers seems to check the auth header for /api/version even though there's seemingly no point in doing so.
That's all I remember at the moment, I'm going to look into it later.
Thanks for answering ! :)
In my case the token was valid, so it doesn't seem to happen only with outdated tokens.
There's an "access token" that lives for an hour (IIRC), it is used to access API methods and it is updated whenever it gets expired. An expired token being used is what causes the error message.
So that's what happens:
- The app makes an API request using the last access token it had.
- If the token is older than one hour, the error message is logged.
- The app requests a new access token.
- The app repeats the original request with a new access token.
First of all, I don't think this should be logged as an error (as I mentioned in wallabag/wallabag#3575). The error should be logged if the token is incorrect, but not if it is expired.
The Android app should skip the first step and request a new token if it knows that the previous one is expired. I'll probably implement it soon.
In the mean time you can try to whitelist an IP if the error message is shortly followed by a successful /api/ request (not /api/version though) from the same IP. Successful requests are not logged in the wallabag log though (but may be logged by webserver).
Oh, and don't mind my mention of /api/version from the last time - it is not relevant to the problem.
Thanks a lot for explaining all of that :)
In the mean time you can try to whitelist an IP if the error message is shortly followed by a successful /api/ request (not /api/version though) from the same IP. Successful requests are not logged in the wallabag log though (but may be logged by webserver).
It's a bit complicated to implement, I'll keep it simpler with a temporary fix (until the issue you mentioned is solved) I think.
The android app fix is available for testing in 2.4.0-beta.3 (APK, beta on Google Play, eventually on F-Droid).
Closing as the fix was released.