Status code upon login failures is not 401

fixundfertig123

Hello everyone,

I just reviewed my issues on Kopano and this is still the only issue to me, since Fail2Ban does not catch the login failures.

No one ever had this problems?
How do you catch login failures?

Any help appreciated.

Kind regards,

Hanno

P.S.: I updated to Debian Buster and WebApp 5.3.0.0-1+172.1

fixundfertig123

Important to mention: I am using WebApp behind a Nginx proxy.

fixundfertig123

For those not using a proxy:
I just got pointed to the link https://forum.kopano.io/topic/108/how-to-protect-webapp-fail2ban/12

However, this approach does not scale for Proxy setups like mine. If I get any news I will let you know.

fixundfertig123

For everyones information:
I just got feedback from Kopano. They informed me, that indeed you recieve a 200 response status code upon failed logins. Therfore there is no “easy” way to handle login failures via fail2ban using a proxy. Alternatives are of course more sophisticated IDS approaches like Crowdsec. They might consider to change it, but NOT in the near future.

umgfoin

Hi @fixundfertig123,

Probably, you’re scanning the wrong log:

Let fail2ban evaluate nginx’s error.log.
A config of nginx + php-fpm produces the following example:

2022/03/22 16:50:50 [error] 1190#1190: *148740 FastCGI sent in stderr: "PHP message: Kopano WebApp user: fixundfertig123: authentication failure at MAPI. IP: 199.65.27.7" while reading response header from upstream, client: 199.65.27.7, server: webapp.batzipost.nz, request: "POST /?logon HTTP/2.0", upstream: "fastcgi://unix:/var/fpm-pools/batzipost.nz/php81fpm.sock:", host: "webapp.batzipost.nz"

++umgfoin.

umgfoin

@fixundfertig123 said in Status code upon login failures is not 401:

For those not using a proxy:
I just got pointed to the link https://forum.kopano.io/topic/108/how-to-protect-webapp-fail2ban/12
However, this approach does not scale for Proxy setups like mine.

The quoted patch explicitely targets proxy-setups, but it is about fail2ban for z-push and not fail2ban for webapp.
++umgfoin.

fixundfertig123

Hi @umgfoin, thank you for your feedback and sorry for not responding earlier. Somehow I missed the notifcation. Just from a very quick review I could not verify your statement, which might be due to my setup / configuration. I will dive into it later the day / tomorrow and keep you updated.

fixundfertig123

@umgfoin
Hi, I evaluated your suggestion but I cannot reproduce your results - at least not in my setup. In my environment login failures are is logged at the error log in the upstream server and not propaged to the proxy. This is in sync with what has been reported back to me by Kopano.
Although I like the in depth dive of the patch, I am not a fan of suggestions like in https://forum.kopano.io/topic/108/how-to-protect-webapp-fail2ban/12. In my understaning it requires permanent manual override of of source code, since the change has not been integrated into release. In particular when using package managing this would cause problems, since I would permanently need to be aware where source code has to be adapted.

umgfoin

@fixundfertig123 said in Status code upon login failures is not 401:

I cannot reproduce your results - at least not in my setup.

My config is nginx + php-fpm - no need for apache in this case.

Are you familiar with:

[Apache] LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" proxy_combined
[nginx ] /etc/nginx/proxy_params:
e.g. proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

++umgfoin.

fixundfertig123

My config is nginx + php-fpm - no need for apache in this case.

I am sorry, do I understand you correctly, you use nginx to proxy your nginx-instances? Or what do you mean by " … no need for apache"

And thank you for you “log” suggestions. I am familiar with those. But maybe I have to give it another look.

umgfoin

@fixundfertig123 said in Status code upon login failures is not 401:

you use nginx to proxy your nginx-instances?

No, I’m using nginx as a webserver for webapp’s static content and as a proxy for upstream requests to php-fpm.
For my workload, there’s no benefit in proxying to apache.

fixundfertig123

@umgfoin Hi thanks for clarifying. Since our setups are quite different, I think they are hard to compare. I will have another look in the log-setup anyway.