Does fail2ban need iptables?

Discuss your pilot or production implementation with other Zimbra admins or our engineers.
Labsy
Outstanding Member
Outstanding Member
Posts: 380
Joined: Sat Sep 13, 2014 12:52 am

Does fail2ban need iptables?

Postby Labsy » Tue Oct 23, 2018 9:13 pm

Hi,

I have more and more attacks on user accounts and would like to stop it before it goes out of control.
Running ZCS 8.8 on Ubuntu 16.04, but I do NOT run/use IPTables, as ZCS is NATed and behind firewall.

Do I need to install/use IPtables?
Any link to conbined install of fail2ban + IPtables?

...or even newer, better aleternative to fail2ban?

And maybe more insight question: will fail2ban block direct requests via IMAP, POP3 and SMTP, but also login attacks via WEBMAIL?


User avatar
vavai
Advanced member
Advanced member
Posts: 154
Joined: Thu Nov 14, 2013 2:41 pm
Location: Indonesia
Contact:

Re: Does fail2ban need iptables?

Postby vavai » Tue Oct 23, 2018 9:21 pm

Hi,

Fail2ban need iptables to block IP suspected as spammer. You can also looking at https://forums.zimbra.org/viewtopic.php?f=15&t=65051 to see an alternative method to block brute-force attack

2FA feature from Zimbra NE can help reduce possible compromise account as it need OTP for being logged in.

https://wiki.zimbra.com/wiki/Zimbra_Two-factor_authentication
https://blog.zimbra.com/2016/02/zimbra-collaboration-8-7-two-factor-authentication-2fa-technical-preview/
Labsy
Outstanding Member
Outstanding Member
Posts: 380
Joined: Sat Sep 13, 2014 12:52 am

Re: Does fail2ban need iptables?

Postby Labsy » Tue Oct 23, 2018 10:01 pm

Thanx for the hint and links. Will study those.

What bothers me are DISTRIBUTED attacks, which probably neither fail2ban nor DOSfilter would block. See, IPs are rarely the same, but attacking mailbox is the same.
I can go with anything, but 2FA, because a lot of users are older ones, and this is Web/MailHosting service, customers will not understand 2FA complications.

Code: Select all

2018-10-23 22:37:59,480 [ip=10.10.11.50;oip=200.77.186.177;via=10.10.11.50(nginx/1.7.1);ua=Zimbra/8.8.7_GA_1964;cid=126644;] [info@domain.com]
2018-10-23 22:50:27,434 [ip=10.10.11.50;oip=177.75.160.101;via=10.10.11.50(nginx/1.7.1);ua=Zimbra/8.8.7_GA_1964;cid=126829;] [info@domain.com]
2018-10-23 22:50:52,488 [ip=10.10.11.50;oip=109.110.64.150;via=10.10.11.50(nginx/1.7.1);ua=Zimbra/8.8.7_GA_1964;cid=126832;] [info@domain.com]
2018-10-23 23:02:47,425 [ip=10.10.11.50;oip=177.128.80.54;via=10.10.11.50(nginx/1.7.1);ua=Zimbra/8.8.7_GA_1964;cid=126994;] [info@domain.com]
2018-10-23 23:03:12,590 [ip=10.10.11.50;oip=138.0.207.110;via=10.10.11.50(nginx/1.7.1);ua=Zimbra/8.8.7_GA_1964;cid=127003;] [info@domain.com]
2018-10-23 23:03:39,226 [ip=10.10.11.50;oip=170.233.117.57;via=10.10.11.50(nginx/1.7.1);ua=Zimbra/8.8.7_GA_1964;cid=127017;] [info@domain.com]
2018-10-23 23:15:16,490 [ip=10.10.11.50;oip=177.67.85.26;via=10.10.11.50(nginx/1.7.1);ua=Zimbra/8.8.7_GA_1964;cid=127159;] [info@domain.com]
2018-10-23 23:15:41,490 [ip=10.10.11.50;oip=186.236.116.14;via=10.10.11.50(nginx/1.7.1);ua=Zimbra/8.8.7_GA_1964;cid=127165;] [info@domain.com]
2018-10-23 23:16:12,482 [ip=10.10.11.50;oip=177.87.111.177;via=10.10.11.50(nginx/1.7.1);ua=Zimbra/8.8.7_GA_1964;cid=127174;] [info@domain.com]
2018-10-23 23:16:37,919 [ip=10.10.11.50;oip=67.204.1.222;via=10.10.11.50(nginx/1.7.1);ua=Zimbra/8.8.7_GA_1964;cid=127180;] [info@domain.com]
2018-10-23 23:17:03,236 [ip=10.10.11.50;oip=181.28.47.4;via=10.10.11.50(nginx/1.7.1);ua=Zimbra/8.8.7_GA_1964;cid=127184;] [info@domain.com]
2018-10-23 23:27:51,026 [ip=10.10.11.50;oip=168.232.24.2;via=10.10.11.50(nginx/1.7.1);ua=Zimbra/8.8.7_GA_1964;cid=127325;] [info@domain.com]
2018-10-23 23:28:16,299 [ip=10.10.11.50;oip=168.232.24.2;via=10.10.11.50(nginx/1.7.1);ua=Zimbra/8.8.7_GA_1964;cid=127335;] [info@domain.com]
2018-10-23 23:28:41,741 [ip=10.10.11.50;oip=168.232.24.2;via=10.10.11.50(nginx/1.7.1);ua=Zimbra/8.8.7_GA_1964;cid=127343;] [info@domain.com]
2018-10-23 23:29:11,321 [ip=10.10.11.50;oip=84.238.197.95;via=10.10.11.50(nginx/1.7.1);ua=Zimbra/8.8.7_GA_1964;cid=127347;] [info@domain.com]
2018-10-23 23:40:22,321 [ip=10.10.11.50;oip=186.250.73.5;via=10.10.11.50(nginx/1.7.1);ua=Zimbra/8.8.7_GA_1964;cid=127494;] [info@domain.com]
2018-10-23 23:40:47,632 [ip=10.10.11.50;oip=184.167.141.242;via=10.10.11.50(nginx/1.7.1);ua=Zimbra/8.8.7_GA_1964;cid=127495;] [info@domain.com]
2018-10-23 23:41:12,936 [ip=10.10.11.50;oip=208.180.33.94;via=10.10.11.50(nginx/1.7.1);ua=Zimbra/8.8.7_GA_1964;cid=127501;] [info@domain.com]
2018-10-23 23:41:38,522 [ip=10.10.11.50;oip=186.250.73.5;via=10.10.11.50(nginx/1.7.1);ua=Zimbra/8.8.7_GA_1964;cid=127508;] [info@domain.com]
2018-10-23 23:52:53,036 [ip=10.10.11.50;oip=168.90.88.14;via=10.10.11.50(nginx/1.7.1);ua=Zimbra/8.8.7_GA_1964;cid=127665;] [info@domain.com]
User avatar
DavidMerrill
Advanced member
Advanced member
Posts: 100
Joined: Thu Jul 30, 2015 2:44 pm
Location: Portland, ME
ZCS/ZD Version: 8.8.15 P3
Contact:

Re: Does fail2ban need iptables?

Postby DavidMerrill » Wed Oct 24, 2018 1:31 pm

Lately I'm running into this (distributed attacks) as well. Very pesky because as you say DOSfilter isn't as effective if there's only one bad attempt per IP, but mailbox lockout policies can still kick in and then we get a call from a client wondering what's up.
___________________________________
David Merrill - Zimbra Practice Lead
OTELCO Zimbra Hosting, Licensing and Professional Services
Zeta Alliance
User avatar
axslingr
Advanced member
Advanced member
Posts: 183
Joined: Sat Sep 13, 2014 2:20 am
ZCS/ZD Version: 8.8.15_GA_3829.RHEL7_64_20190718141

Re: Does fail2ban need iptables?

Postby axslingr » Wed Oct 24, 2018 3:08 pm

All my Zimbra servers are behind a pfSense firewall with pfblockerNG installed. I only allow traffic from countries that actually need to connect. Doesn't totally eliminate attacks but certainly reduces them drastically.

Lance
User avatar
JDunphy
Outstanding Member
Outstanding Member
Posts: 494
Joined: Fri Sep 12, 2014 11:18 pm
Location: Victoria, BC
ZCS/ZD Version: 8.7.11_P14 RHEL6 Network Edition
Contact:

Re: Does fail2ban need iptables?

Postby JDunphy » Wed Oct 24, 2018 4:22 pm

Using 2nd factor is ultimately the solution IMO. We began a project over the summer to build some U2F hardware tokens based on U2Fzero that are dead simple and based on FIDO. They cost us about $5 each to build in small quantities (10) and they are easier to use than TOTP or OTP for users. They use cryptographic challenges/signatures and are based on FIDO so most browsers have built-in support and work. My issue with them is they didn't' support NFC (ie. mobile users) nor does zimbra support this natively so that is the next step for me before we experiment with customers and probably FIDO 2 with next batch we do. I love mine and I have my wife and kids using them for everything. If anyone cares to learn more how they work - https://www.redkeyu2f.com is what our CO-OP student who built the keys put together explaining her work. 2nd factor may not be perfect for everyone but we wanted to get some operational experience with them nonetheless.

Without 2nd factor... We have gone so far with some customers to provide an openvpn access gateway. They click on a VPN file containing all the certs required and VPN setup information necessary and then their zimbra firewall allows ip address access from only the ip address of that access gateway. We have found that even $5-10/month DO droplets work well for 10-20 users for one of these openvpn access gateways. The VPN's is there to provide us with a known sane ip address we can allow access to for road warriors. The encryption is secondary here but it prevents some downgrade https attack protection if you don't have nginx adding Strict-Transport-Security, etc.

I have also disabled http access for some problem customers at times ... this can be a problem because new computers/browsers will not have our Strict-Transport-Security header saved with their browser so it will generate a phone call every time because they forget to initially add https. Not ideal but it does help with some of the attacks that begin as http guesses. Most of the ones we get are imaps dictionary attacks from unique ip addresses. 1 guess per ip address
If your users come from known locations, one can do something like this for some ranges/cidrs using an ipset.

Code: Select all

-A Block -m state --state NEW -m tcp -p tcp --dport 993 -m set --match-set trusted_hosts src -j ACCEPT

where trusted_hosts is an ipset and populated from a text file listing the cidr's one per line.

Code: Select all

#!/bin/sh

trusted_hosts=/etc/sysconfig/trusted_hosts

ipset create trusted_hosts hash:net

for host in `cat $trusted_hosts | awk -F\; '{print $1}'|grep -v '#'`
do
        ipset add trusted_hosts $host
done

We have some customers that only use zimbra from their office with the exception of 1 or 2 road warriors. If we can convince those road warriors to use one of the above methods, we can mostly mitigate dictionary attack risks for them.

As far as country's ip's, I like anything that mitigates ones risk so great solution with pfsense! ... we don't do that here but I have a milter (blackmilter) on our incoming MX's that add's a Country header to incoming email. It checks the incoming ip address with all the countries we expect email from and then adds a header if that originating email isn't from that list. We then have a SA rule that can score that country header based on different factors and risks that we see in the email. We have also added user filters where we tag their incoming email should it be a foreign country and not in their contacts lists. It helps quite a bit with education with phishing and spear phishing attacks.

This is a tough problem to mitigate completely without help from the user. I am wondering if tcp finger printing might be the next answer for those 1 ip per 1 guess problem???? Anyone trying that?

Return to “Administrators”

Who is online

Users browsing this forum: MSN [Bot] and 19 guests