Manage distributed bruteforce ?

Discuss your pilot or production implementation with other Zimbra admins or our engineers.
Post Reply
rokoyato
Advanced member
Advanced member
Posts: 86
Joined: Mon Jun 29, 2020 9:12 am

Manage distributed bruteforce ?

Post by rokoyato »

Hi,

Does anyone have a proper solution to deal with distributed bruteforce ?

I've got an attack with thousands of ips where ip are used only twice, which make it hard to ban in f2b due to the risk of false positive.

Regards
User avatar
L. Mark Stone
Ambassador
Ambassador
Posts: 2796
Joined: Wed Oct 09, 2013 11:35 am
Location: Portland, Maine, US
ZCS/ZD Version: 10.0.6 Network Edition
Contact:

Re: Manage distributed bruteforce ?

Post by L. Mark Stone »

You can try this:

https://www.missioncriticalemail.com/20 ... n-attacks/

Hope that helps,
Mark
___________________________________
L. Mark Stone
Mission Critical Email - Zimbra VAR/BSP/Training Partner https://www.missioncriticalemail.com/
AWS Certified Solutions Architect-Associate
rokoyato
Advanced member
Advanced member
Posts: 86
Joined: Mon Jun 29, 2020 9:12 am

Re: Manage distributed bruteforce ?

Post by rokoyato »

Hi Mark,

Thanks for the link sadly I cannot apply this kind of policy in my company :(

I think I will just go down to an IPS solution like crowdsec or something close to that.

Sadly zimbra does not provide efficient means of protection imo with the kind of attacks we can encounter theses days....

Regards
User avatar
JDunphy
Outstanding Member
Outstanding Member
Posts: 889
Joined: Fri Sep 12, 2014 11:18 pm
Location: Victoria, BC
ZCS/ZD Version: 9.0.0_P39 NETWORK Edition

Re: Manage distributed bruteforce ?

Post by JDunphy »

rokoyato wrote:Hi,

Does anyone have a proper solution to deal with distributed bruteforce ?

I've got an attack with thousands of ips where ip are used only twice, which make it hard to ban in f2b due to the risk of false positive.

Regards
I moved to a zero trust model on one of our installs. It works by blocking all traffic and using ipset's for access from known locations. For the majority of the users, they don't know anything changed as we know the ip's they come from which do not change often (office and remote office locations, homes, etc). For those that are mobile or it did change, we have an access server (wireguard) they must authenticate first as that wireguard server's ip is allowed access. That takes less than a second for them to bring up and their initial configuration is simple as we provide them with a qrcode to configure their wireguard client the first time. It is also fast as we are seeing 400Mb/s down and 100Mb/s up in our environment where my home access is 500Mb/s down and 100Mb/s up for that VPN client. Battery appears to be no different when needed (sending/receiving) so the wireguard client is incredibly efficient to mobile battery life. We don't run a NAT'd zimbra here but if we did, that might require one to run wireguard keep-alive's that could use more battery so that firewalls don't drop connection pathways.

Our firewall rule looks like this with the default to block all incoming port 443

Code: Select all

-A INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport 443 -m set --match-set trusted_email_hosts src -j ACCEPT
-A INPUT -j DROP
One can add ip's to the ipset dynamically so the firewall rules doesn't have to be touched again and to eliminate the need for future use of that wireguard vpn. Our goal is they don't have to use the VPN. We periodically look over the logs looking for ip's that have successfully authenticated anyway to look for compromised accounts and which accounts were under attack - I have a check_login.pl script in my github to do this. The first week this went active, I asked the users to text me for access problems. We had only 1 text and that was because we were too strict and changed the ip range to a /24 from a /32 for a worker that was taking university courses and on campus. While it's not perfect it, having less potential ip's that can mount an attack against zimbra is my approach thus far. I had thought of the reverse case where we block bad ip's (from our's, geo blocking, and known bot networks) and wrote a tool that dynamically sent ip's around so you could attack just a few times from a pool of zimbra servers (some honeypots) but that led to false positives as some users still don't use password managers and make mistakes in entering their passwords from time to time.

I have a script to create the individual wireguard clients and qrcodes if that is a direction you want to go and I could post it. It isn't perfect but once setup (hardcoded wireguard servers public key and ip address) will create as many accounts as needed. Cloudflare teams is another solution but I wanted to test here first if the concept is worth it and gain some operational experience with help desk issues as I believe WARP is wireguard under the covers. Not having to worry about attackers does give peace of mind. Note: we don't have direct access to zimbra from port 25 (never have) so that is already handled by our primary mx's. As for other protocols, imap, pop, 587 there would be similar ipset rules to control access. Currently our users are port 443 only for mobile and desktop here as we have the Network version so exchange discovery is simple enough for them to configure for MUA's.

I wasn't initially sure we should try this but after looking at the possible list of known ip's the users come from; it wasn't a big pool of ip's and less than 50 cidr's. Having many users doesn't necessarily mean having a huge pool of ip's to account for. In our case, we predicted which users might have a problem so they probably wouldn't have required the VPN if we had been more generous with the initial cidr's for them. Note: we pulled the rule for 24 hours in the second week until we could get a handle on why a remote user was having a problem connecting. They texted me and I pulled the rule but it turned out to be a connection issue on their end. Some users don't use the vpn as they don't have a need. We offered it to all of them.

HTH,

Jim
Post Reply