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.

1622 views
d

By. Jacob

Edited: 2023-07-25 12:46

Postfix is storing information about sent e-email in the mail.log file; this file includes information about connection and login attempts made to your server, and even mails that are successfully sent.

If you open up this file in a terminal editor like nano or vim, you will get a lot of "noise" from bots trying to connect to your server in addition to the information you are after, and 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 you; 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 analyse 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

Use grep -i 'sasl' to make it case insensitive.

Often a hacker will attempt to send spam, and if your server only has a few user accounts you should be able to easily deduce if something that was sent look suspicious. E.g. High send rate or unusual recipients. Do this by grepping for status=sent in the mail.log file. E.g:

grep -i "status=sent" /var/log/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.

Tell us what you think:

  1. How to block sender e-mail addresses and domains in Postfix to effectively eliminate marketing spam.
  2. Configure Postfix to check SPF records and fight e-mail spoofing.
  3. How to use SPF records to increase the likelihood that your e-mails will be received and not go to spam.
  4. Rate limiting your postfix server to limit the amount of e-mail a single user can send.
  5. To add or update a PTR record for an AWS IP, you will need to contact Amazon through the: Request to remove email sending limitations form. Read more in this article.

More in: Mail Servers