Brute force attack

Discuss your pilot or production implementation with other Zimbra admins or our engineers.
Post Reply
kyiu
Posts: 30
Joined: Fri Mar 08, 2019 4:06 pm

Brute force attack

Post by kyiu »

I'm running the Zimbra 8.8.7 server behind my firewall. I'm getting brute force attack on a user. I want to know the actual IP address of the attacker. Here is the message for the opt/zimbra/log/mailbox.log:
2019-09-12 12:02:14,806 INFO [ImapSSLServer-0] [ip=my_address;cid=297;] imap - CAPABILITY elapsed=1
2019-09-12 12:02:14,809 INFO [ImapSSLServer-0] [ip=my_address;cid=297;] imap - authentication failed for [user@mydomain] (invalid password)
2019-09-12 12:02:14,809 INFO [ImapSSLServer-0] [ip=my_address;cid=297;] imap - LOGIN elapsed=1
2019-09-12 12:02:24,707 INFO [ImapSSLServer-0] [ip=my_address;cid=298;] imap - CAPABILITY elapsed=1
2019-09-12 12:02:24,711 INFO [ImapSSLServer-0] [ip=my_address;cid=298;] imap - authentication failed for [user@mydomain] (invalid password)
2019-09-12 12:02:24,711 INFO [ImapSSLServer-0] [ip=my_address;cid=298;] imap - LOGIN elapsed=1
2019-09-12 12:02:37,799 INFO [ImapSSLServer-0] [ip=my_address;cid=299;] imap - CAPABILITY elapsed=1
2019-09-12 12:02:37,802 INFO [ImapSSLServer-0] [ip=my_address;cid=299;] imap - authentication failed for [user@mydomain] (invalid password)
2019-09-12 12:02:37,802 INFO [ImapSSLServer-0] [ip=my_address;cid=299;] imap - LOGIN elapsed=1

My final goal is to implement fail2ban on the server. I need to know how I can determine the attacker IP address before I can achieve to goal.
Please help,
phoenix
Ambassador
Ambassador
Posts: 27272
Joined: Fri Sep 12, 2014 9:56 pm
Location: Liverpool, England

Re: Brute force attack

Post by phoenix »

Why don't you take a look at some of the web pages: https://www.startpage.com/do/dsearch?qu ... pensearch&language=english
Regards

Bill

Rspamd: A high performance spamassassin replacement

Per ardua ad astra
tonyg
Advanced member
Advanced member
Posts: 51
Joined: Fri Mar 16, 2018 5:25 pm
Location: USA
ZCS/ZD Version: 8.8.12.GA.3794.UBUNTU18.64 FOSS
Contact:

Re: Brute force attack

Post by tonyg »

Over the weekend I started tracking down a similar situation. Did a lot of reading, sifted through a lot of old/bad info, added the oip to the log, setup fail2ban, had to tweak the filter, nailed my first badguy. Also setup fail2ban to save the iptables so that they are refreshed on system restart ... not automatically done!

Thanks to everyone who participates in these forums and the wiki for info that leads to solutions like this.
BradC
Outstanding Member
Outstanding Member
Posts: 265
Joined: Tue May 03, 2016 1:39 am

Re: Brute force attack

Post by BradC »

tonyg wrote:Also setup fail2ban to save the iptables so that they are refreshed on system restart ... not automatically done!
Crikey. You restart your system??
tonyg
Advanced member
Advanced member
Posts: 51
Joined: Fri Mar 16, 2018 5:25 pm
Location: USA
ZCS/ZD Version: 8.8.12.GA.3794.UBUNTU18.64 FOSS
Contact:

Re: Brute force attack

Post by tonyg »

Ha! Old habit from Windows ... and DOS.
Really though, and this is on-topic with all-things Zimbra ... Now with fail2ban in place and IPTables holding the IPs of bad actors, the next step in protecting against known offenders BEFORE they attempt to brute force the email server.

My next goal is to rsync IPTables among systems where other applications are logging similar attacks. For example, I have several WordPress sites running. When I get attacked in WP, I want the IP blocked from my Zimbra server too. Conversely, when Zimbra blocks an IP, I don't want that IP to have any access to my WP systems. This applies to all applications and socket ports that are open to the public. The challenge here is to extract the IP addresses and block duration from each server, aggregate that data, and then regenerate new chains of rules. I think that's just simple code and perhaps simple list processing.

Has anyone else here taken on that challenge?

About fail2ban, one thing that I've changed is that I DROP packets, I don't REJECT with a response. I have no desire to respond in any way to someone who is already known to be abusing my systems. I don't want to give them a reason why they are being rejected. I don't want to waste bandwidth. I simply don't acknowledge their inbound queries. Eventually they might go away. Yeah, I know the smart ones might log the lack of response and take special interest : "What is this guy hiding?" But if we're up against that calibre of hacker then I have little faith that my feeble efforts are really going to thwart them anyway.
Post Reply