Beamtic's logo
  1. Create user
Home

Share via:

How To Know If Postfix Was Hacked Into

We can find out if Postfix was hacked by reading the mail and syslog files, learn what to look for in this article.

91 views

Edited: 2020-07-20 22:58

Postfix is storing information about sent e-email in the mail.log file; the file also includes information about connection and login attempts made to your server.

If you just open up this file in a terminal editor like nano or vim, you will also get a lot of "noise" from bots trying to connect to your server; typically this noise is not of any interest, so we can safely ignore it: It might look like this:

Jul 10 05:02:12 ip-172-31-1-1 postfix/smtps/smtpd[61016]: lost connection after CONNECT from unknown[xxx.xxx.xxx.xxx]
Jul 10 05:02:12 ip-172-31-1-1 postfix/smtps/smtpd[61016]: disconnect from unknown[xxx.xxx.xxx.xxx] commands=0/0

Instead of reading the file directly by opening it, you should filter out all the junk that does not interest us; to do that, you can use the grep command (or zgrep in case you are dealing with .gz files).

Using grep allows us to only return entries (lines) that include specific text strings; and you should carefully analyze both the syslog and the mail.log file in /var/log/, as both of them may contain useful information.

Note. When grepping, remember that your grep is case-sensitive. So, grep 'SASL' mail.log will not give the same result as grep 'sasl' mail.log

Filtering mail.log and syslog for break ins

A successful login attempt will typically include "username" in the string; that is, if you configured Postfix to only allow authenticated users to send e-mail. If you know the username of the user that got hacked, you can grep like this:

grep 'username=root' /var/log/mail.log

The result will look like this:

Jul  5 10:92:01 ip-172-31-1-1 postfix/smtps/smtpd[4328]: 9248D303TU: client=unknown[xxx.xxx.xxx.xxx], sasl_method=PLAIN, sasl_username=root

This tells you two things, the time the attacker managed to login, and the IP address used by the attacker at the time of the break in. You should know which IP address the user normally logs on from, and if the IP address is different from normal, you will know that something suspicious is going on.

In this case, the user is root, so determining that the server was hacked is very easy, since the root user is not normally used to send e-mail outside of the LAN.

Checking for failed login attempts

Looking through the log files for failed login attempts can be useful when manually banning attackers; but ideally you should setup something like fail2ban so that they are banned automatically, as you really can not look through all this manually.

To look for failed login attempts, you can grep 'authentication failed' mail.log:

Jul  10 12:20:20 ip-172-31-1-1 postfix/smtps/smtpd[189325]: warning: unknown[xxx.xxx.xxx.xxx]: SASL LOGIN authentication failed: BPFzy4dlcmE4

These authentication attempts was successfully denied, so there is nothing to worry about. The only thing you need to make sure, is that you got some sort of rate-limiting in place, so that hackers can not just keep trying passwords and brute force their way in; fail2ban is very useful in this regard.

Tracing an attack

The IP address of the attacker will often belong to a proxy, VPN, or compromised system; so it may be incredibly difficult to trace an attacker.

You can, however, still report the hack to the ISP that owns the IP. When you do a whois on the IP address, typically the ISP will have an abuse e-mail address that you can contact. You can perform a whois lookup directly from the terminal:

whois xxx.xxx.xxx.xxx

Other times the attacker may have carelessly used their own home IP address, in which case, you can sometimes be lucky and track them simply by Googling their IP address, and other info that you might find.

Comments

  1. Rate limiting your postfix server to limit the amount of e-mail a single user can send.
  2. How to configure a SMTP server with letsencrypt on an amazon EC2 instance.
  3. How to use SPF records to increase the likelihood that your e-mails will be received and not go to spam.
  4. How to configure Postfix to use Lets Encrypt certificates.
  5. How to debug problems with a Dovecot server using log files.

More in: Mail Servers