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
Manage distributed bruteforce ?
- L. Mark Stone
- Ambassador
- Posts: 2802
- Joined: Wed Oct 09, 2013 11:35 am
- Location: Portland, Maine, US
- ZCS/ZD Version: 10.0.7 Network Edition
- Contact:
Re: Manage distributed bruteforce ?
___________________________________
L. Mark Stone
Mission Critical Email - Zimbra VAR/BSP/Training Partner https://www.missioncriticalemail.com/
AWS Certified Solutions Architect-Associate
L. Mark Stone
Mission Critical Email - Zimbra VAR/BSP/Training Partner https://www.missioncriticalemail.com/
AWS Certified Solutions Architect-Associate
Re: Manage distributed bruteforce ?
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
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
- JDunphy
- Outstanding Member
- Posts: 899
- Joined: Fri Sep 12, 2014 11:18 pm
- Location: Victoria, BC
- ZCS/ZD Version: 9.0.0_P39 NETWORK Edition
Re: Manage distributed bruteforce ?
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.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
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
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