Status code upon login failures is not 401
-
Hello everyone,
Upon log file analysis I observerd that entering incorrect passwords / usernames does not result in 401 response code in the NGINX/Apache2 log file, but only a 200 with an verbal “Logon failed. Please verify your credentials and try again”.
When entering wrong password my reverse proxy recieves from webapp:
AAA.BBB.CCC.EEE - - [11/Apr/2020:12:56:16 +0200] “POST /webapp/?logon HTTP/1.1” 200 3096 “https://XXX/webapp/?logon” “Mozilla/5.0 (Linux; Android 7.0; DEVICENAME) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.xxx.xxx.xxx Safari/537.36”Looking into the WebAPP Apache2 access log states:
AAA.BBB.CCC.EEE - - [11/Apr/2020:12:56:16 +0200] “POST /webapp/?logon HTTP/1.1” 200 3550 “https://XXX/webapp/?logon” “Mozilla/5.0 (Linux; Android 7.0; DEVICENAME) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.xxx.xxx.xxx Safari/537.36”Looking into the WebAPP Apache2 error log reveals:
[Sat Apr 11 12:56:16.087556 2020] [:error] [pid 22604] [client AAA.BBB.CCC.EEE:49738] Kopano WebApp user: username@XXX.de: authentication failure at MAPI, referer: https://XXX/webapp/?logonAnyone else oberserving this? This causes some problems when establishing security mechanism like fail2ban, …
All involved server are:
Description: Debian GNU/Linux 9.12 (stretch)
Release: 9.12
Codename: stretch
WebApp: 3.5.14.2539+111.1
Kopano Core: 8.7.9I appreciate any help.
-
Hi,
no one experiencing this problem?
Best
-
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
-
Important to mention: I am using WebApp behind a Nginx proxy.
-
For those not using a proxy:
I just got pointed to the link https://forum.kopano.io/topic/108/how-to-protect-webapp-fail2ban/12However, this approach does not scale for Proxy setups like mine. If I get any news I will let you know.
-
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. -
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.
-
@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. -
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.
-
@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. -
@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.
- [Apache]
-
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.
-
@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. -
@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.
