Zimbra Forums

Good evening everyone,

I am in dire need of the collective brain power of these forums. I have someone attempting to log in to my account via the Zimbra web interface. They are making multiple attempts which is causing my account to become disabled, and it's very frustrating. I attempted to see who it was by viewing the /opt/zimbra/log/audit.log file but what is logged there is the IP address of the Zimbra server itself (domain name, user name, and server IP changed to provide an example below )...

2018-11-10 17:03:48,966 WARN [qtp335471116-59207:https:https://webmail.example.com:7073/service/admin/soap/] [name=admin@example.com;ip=1.2.3.4;port=36300;soapId=7de4b14;] security - cmd=Auth; account=admin@example.com; protocol=soap; error=authentication failed for [admin@example.com], invalid password;

The IP address 1.2.3.4 shown in the log entry is the IP address of the VPS where I have Zimbra Collaboration running. It never shows me their public IP address. However, if there is a successful log in, THEN the log file shows the users IP address. Is there a setting that I can change to show this? I've heard of people using fail2ban for these things, but if the log file is showing the IP address of the server, wouldn't that just block the server from itself?

I'm in need of some education here, and would most sincerely appreciate any suggestions or feedback that you are willing to provide.

Respectfully,

Martin

Hi,

You need 3 things:
1. Enable login of the originating IP
https://wiki.zimbra.com/wiki/Log_Files# ... inating_IP

2. Configure the DoSFilter to block the IPs
https://wiki.zimbra.com/wiki/DoSFilter

3. Configure the account login policy via COS

As complementary lecture, take a look at this post from Mark. https://www.missioncriticalemail.com/20 ... -together/

No need for fail2ban, just use the DoSFilter that comes with zimbra.

If the attack is distributed (comming from different IPs), then these messures won't be of much help and the account will keep locking (and it should). If you need something to handle perimetral security, then you should add some perimetral security to your enviroment (fortinet, cisco, etc) that is prepared to deal with distributed attacks.

Beside that, I guess that you could "script" enabling/disabling the accounts so at least, during off work hours, they won't be able to brute force those accounts.

Good luck,

That information was perfect! I have already implemented all of your suggestions and have already found the culprit! I cannot thank you enough.

Martin

happy it worked and happy about your feedback!

Thank you!