Cant shake bruteforce monkey

Discuss your pilot or production implementation with other Zimbra admins or our engineers.
User avatar
JDunphy
Outstanding Member
Outstanding Member
Posts: 475
Joined: Fri Sep 12, 2014 11:18 pm
Location: Victoria, BC
ZCS/ZD Version: 8.7.11_P14 RHEL6 Network Edition
Contact:

Re: Cant shake bruteforce monkey

Postby JDunphy » Wed Oct 24, 2018 5:06 pm

Do you have the ability to use a tcp finger printing tool? Something like: https://null-byte.wonderhowto.com/how-to/hack-like-pro-conduct-passive-os-fingerprinting-with-p0f-0151191/ and p0f perhaps?
I am curious if one could design something to work for these 1 guess 1 ip address attacks assuming these are scripts coming through TOR or a botnet and block them via your FW before they connect. It might also be interesting to classify where these guessing ip's are registered? That could help mitigate some risk by reducing the ip pool down to a known/expected country, etc. see: http://www.ipdeny.com/ipblocks/ for country ranges and associated tools. Note: geoip ranging is not 100% accurate so probably best to pull some of these cidr's from your logs to make sure you don't lock customers out if this is a method you attempt.

I have a script I posted that I use sometimes to track login attacks....https://forums.zimbra.org/viewtopic.php?f=15&t=61294#p286001. It prints the user account and then the hits/misses with web, imap, pop logins... It can also help with identification of users that are not using password managers and potentially have weak passwords as a result.

Code: Select all

% su - zimbra
% check_login.pl
compliance@example.com
Total [   8] -     69.5.8.6  Failed [   3] - 69.5.8.6  failed web [   3]

a.user@example.com
Total [  10] -      72.55.77.6
Total [   3] -   7.215.121.202
Total [   2] -   17.17.127.190
Total [   2] -    17.17.122.30

So compliance@example.com doesn't use a password manager given the 3 failed and 5 successful login's from the same ip address. Note: ip addresses are random and not real ip's for this posting.


User avatar
zimico
Advanced member
Advanced member
Posts: 134
Joined: Mon Nov 14, 2016 8:03 am
Location: Vietnam
ZCS/ZD Version: 8.8.12
Contact:

Re: Cant shake bruteforce monkey

Postby zimico » Sat Nov 03, 2018 2:38 pm

L. Mark Stone wrote:
zimico wrote:Hi Mark,
I have tested zimbra dosfilter with lower threshold and fail login policy. Dosfilter recoginzed bad ip but the account was still locked out.
Could you show me your current configuration.
Regards,
Minh.


Just did a blog post on this:
https://www.missioncriticalemail.com/20 ... -together/

Please take a look and let me know if that works for you?

All the best,
Mark


Dear Mark, I tested again follow your blog. My server worked as expected. So I confirm that the combination of DosFilte and Lockout Policy works well.

Best regards,
Minh.
rickygm
Posts: 17
Joined: Sat Sep 13, 2014 1:48 am

Re: Cant shake bruteforce monkey

Postby rickygm » Wed Nov 28, 2018 9:07 pm

very good explanation the article of mark, I tried in the latest version of zimbra 8.8 but it does not work.
rickygm
Posts: 17
Joined: Sat Sep 13, 2014 1:48 am

Re: Cant shake bruteforce monkey

Postby rickygm » Wed Nov 28, 2018 9:15 pm

JDunphy wrote:
L. Mark Stone wrote:
Just did a blog post on this:
https://www.missioncriticalemail.com/20 ... -together/
Mark

That is really well done Mark. Got me thinking that perhaps an enhancement should someone wish to take this further at the fw/packet level.

1) add a single entry via iptables that matches an ipset that is time based for removal
2) add the ip address dynamically from information provided by dosfilter

We have a 4 hr ipset and a 12 hr ipset that our incoming relays will put any bad actors into time out. I have seen 1000's of ip's added in a few minutes without load to the server. Super efficient and the bad guy burns all their ip's and hopefully goes away.

where this is in your /etc/sysconfig/iptables or whatever method you use for your fw rules.

Code: Select all


-A Block -m set --match-set blacklist24hr src -j DROP

and the ipset's have been created via:

Code: Select all

% ipset create blacklist4hr hash:ip hashsize 4096 timeout 14400
% ipset create blacklist24hr hash:ip hashsize 4096 timeout 86400

then you have a script looking for triggers from logs or whatever and they are added like thus:

Code: Select all

ipset add blacklist4hr X.X.X.X

Not as elaborate as fail2ban but ipsets are super efficient and scale massively and the block is in real-time without any restart of your firewall. If this was a multi-server zimbra install, one could do it on the parameter via syslog and a script looking for those ip addresses.Note: Because the ip's decay automatically and are removed there is nothing further to do after addition... ie. a hacker that has used TOR being a usage case and why you want to might want to decay those ip's.

Note: there are variations one could do without writing any scripts and using the ipset just with FW rules. Example: control number of connections per ip over a time interval.

Code: Select all

-A Block -m set --match-set someblacklist src -j DROP
-A Block -p tcp --dport 25 -m state --state NEW -m recent --set --name SMTP
-A Block -p tcp --dport 25 -m state --state NEW -m recent --update --seconds 60 --hitcount 10 --rttl --name SMTP -j SET --add-set someblacklistr src
#allow incoming traffic if not more than 10 connections in 60 seconds per ip
-A Block -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT



Hi JDunphy , this seems interesting to me, you could share these script here in the forum so the community could contribute more, for the syntax I think you are using iptables and not firewalld.

Return to “Administrators”

Who is online

Users browsing this forum: L. Mark Stone and 16 guests