When I changed my firewall rule policy, part the reason for doing it was because I was getting tired of seeing dovecot:auth failures in the logs. People around the world were brute forcing my mail server, and the rules were 100 lines long of just blocking. I had thought that they were coming from people hitting port 993 (IMAPS), and to a point there were. You can see below where it is dropping port 993 access attempts.

A few days later, logcheck’s emails had the line return:

What the heck, the rules  are written to deny anything not allowed, and I only allow port 22, 993 and 587 on networks I use; school, work, home, and cellular tether / data pacakge. However the rhost above is not in that list.

Googling for what’s going on, other people are seeing the same thing on occasion. Errors from Dovecot, about failed log in attempts, with IMAP, IMAPS, POP, and POP3 blocked. No one explained what what happening. I would make changes to the rules and I’d still see things showing up in the tail -f /var/log/auth.log window.

I caught one of the ip addresses as it hit the log, changed windows and did a netstat -tpan and grepped the offending ip address. What I found was it was coming in on port 25, not 993.

Well, that gave me something new to Google. Searching Dovecot auth failure port 25, brought back SASL. Which is a way to allow users to access the mail server when on the road / away from the office, to send mail. The user can authenticate to the server over port 25 and then send mail.

So it looks like my next step is to figure out how to disable SASL or install and configure Fail2Ban to cover port 25. Here is what a packet capture of that looks like for user auth on port 25.