0

One of my mail servers (postfix if it matters) has been target of what seems to me to be an attack. The attacker tries to deliver messages to a non-existent user formed as a long hex string with SMTP sessions happening one every second. Here is a fragment of one single session:

 In:  MAIL FROM:<xxxx@xx.xxx.xx> SIZE=2881 BODY=7BIT
 Out: 250 2.1.0 Ok
 In:  RCPT TO:<35150aa4c74ba30f04ede17ca25f18cd@xxxx.yy
 Out: 451 4.3.0 <35150aa4c74ba30f04ede17ca25f18cd@xxxx.yy>: Temporary lookup
     failure
 In:  RCPT TO:<357f21a54e272af6a629ff7657eae27c@xxxx.yy>
 Out: 451 4.3.0 <357f21a54e272af6a629ff7657eae27c@xxxx.yy>: Temporary lookup
     failure
 In:  RSET
 Out: 250 2.0.0 Ok
 In:  MAIL FROM:<xxxxx@xx.xxx.xx> SIZE=2881 BODY=7BIT
 Out: 250 2.1.0 Ok
 In:  RCPT TO:<947a7c9627f3977247586a4fca58bc67@xxxx.yy>
 Out: 451 4.3.0 <947a7c9627f3977247586a4fca58bc67@xxxxx.yy>: Temporary lookup
     failure
 In:  QUIT
 Out: 221 2.0.0 Bye

Anyone know what this is and how to protect the servers? Thanks.

  • 2
    Looks like it's already protecting itself. – symcbean Jun 18 '13 at 16:17
  • Yes it is, but it seems that there is an attack vector that is being exploited. Not knowing what this vector is and taking appropriate action may prove very bad for the email server. – ank Jun 19 '13 at 5:10
1

After looking at this for a few days and getting some help on onther site here is what is happening:

Apparently we are dealing with a blind emai address harvester. Note that all user names (string before @) are all 32 hex characters. Going into the log files I noticed that such values appear in the message-id's during SMTP transactions but also as part of the header in the actual messages.

Apparently there has been some harvesting going on of mail addresses where everything that has a "@" is picked up. The question is: was this harvesting from our log files or our mail storage - a very serious possibility which would indicate a break in - or from some other location like mailing lists etc. It turns out that each type SMTP server assigns a slightly different message-id, so checking the logs and querying a few domains it turns out that 32 character long message-id's are assigned by EXIM. Sigh of relief, I only operate with Postfix.

My conclusion is that the harvester is blindly picking usernames and domains from wherever it can (possibly from mailing lists) and pairing them at random!! Upgrading Postfix so to use postscreen could help as well as fixing the configuration to emit a permanent error instead of a temporary one.

So no attack, really, against a vulnerability, just blind messages.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.