On 3 Jun 2018, at 7:25 (-0400), Proxy wrote:
Hello,
I'm seeing lot of emails coming from local IP address trying to send
message to non existing accounts. Sending accounts are valid and even
authenticated. They all try to send messages to domain matching the
sending one. For example:
supp...@example.org -> u...@example.org
supp...@example.net -> u...@example.net
and so on. support@* is valid, user@* is not. In logs they are coming
from inet_interfaces address set in main.cf.
Your system has been compromised. The most common vectors are vulnerable
web applications (e.g. carelessly-written PHP or CGI scripts) but there
are many other possible modes of attack.
This is the handshake part:
Out: 220 mail.example.com ESMTP Postfix
In: EHLO localhost.localdomain
Out: 250-mail.example.com
Out: 250-PIPELINING
Out: 250-SIZE 24800000
Out: 250-ETRN
Out: 250-STARTTLS
Out: 250-ENHANCEDSTATUSCODES
Out: 250-8BITMIME
Out: 250 DSN
In: STARTTLS
Out: 220 2.0.0 Ready to start TLS
In: EHLO localhost.localdomain
Out: 250-mail.example.com
Out: 250-PIPELINING
Out: 250-SIZE 24800000
Out: 250-ETRN
Out: 250-AUTH PLAIN LOGIN
Out: 250-AUTH=PLAIN LOGIN
Out: 250-ENHANCEDSTATUSCODES
Out: 250-8BITMIME
Out: 250 DSN
In: AUTH LOGIN
Out: 334 fjUIrwvlXCkR
In: t3VncG6ydiBwpGZ2v3ducmRjb476ZXJ0ZXIub3Jn
Out: 334 dfjklaeuYFGL
In: dEgzfjklsaliQwMxl
Out: 235 2.7.0 Authentication successful
In: MAIL FROM:<supp...@example.org>
Out: 250 2.1.0 Ok
In: RCPT TO:<u...@example.org>
Out: 451 4.3.0 <u...@example.org>: Temporary lookup failure
Session aborted, reason: lost connection
Jun 3 06:12:04 mail postfix/smtpd[26186]: connect from
mail.example.com[DD.DDD.DD.DDD]
Jun 3 06:12:04 mail postfix/smtpd[26186]: setting up TLS connection
from mail.example.com[DD.DDD.DD.DDD]
Jun 3 06:12:04 mail postfix/smtpd[26186]: Anonymous TLS connection
established from mail.example.com[DD.DDD.DD.DDD]: TLSv1 with cipher
DHE-RSA-AES256-SHA (256/256 bits)
Jun 3 06:12:04 mail postfix/smtpd[26186]: NOQUEUE: reject: RCPT from
mail.example.com[DD.DDD.DD.DDD]: 550 5.1.1 <u...@example.org>:
Recipient address rejected: User unknown in virtual mailbox table;
from=<supp...@example.org> to=<u...@example.org> proto=ESMTP
helo=<localhost.localdomain>
Jun 3 06:12:04 mail postfix/smtpd[26186]: lost connection after RCPT
from mail.example.com[DD.DDD.DD.DDD]
Jun 3 06:12:04 mail postfix/smtpd[26186]: disconnect from
mail.example.com[DD.DDD.DD.DDD]
Obfuscating IP addresses and hostnames in email log snippets here is
pointless and removes any value these log lines might have had in
analyzing your problem.
Also, those log lines are NOT from a session similar to the purported
SMTP chat you included above. If Postfix logs that it sent a 550 5.1.1
reply, it did NOT send a 451 4.3.0 reply as in the SMTP chat.
My postconf -n (Postfix 2.6.6) is in the attachment.
Why are you using obsolete software? 2.6.6 was released over 8 years
ago. The last 2.6.x support release was 2.6.19, over 5 years ago.
If this is generally how software on your system is maintained, it is
unsurprising that it has been taken over by a spammer.
How can I find out from where these emails are coming?
You've already said it: they are coming from your own broken system.
If they are really from
localhost, what program/script?
That's not a question that can be answered from the outside.
If from outside how to prevent IP spoofing?
Even a system so old that it is running Postfix 2.6.6 is extremely
unlikely to be vulnerable to an external attacker spoofing a local IP
address for a TCP-based protocol like SMTP. Functional IP spoofing
generally is a UDP or ICMP trick, not TCP (at least not in THIS
millennieum...)
Seing that it tries several passwords and succeed make me worried even
more.
That's common for spammers.
Again: A spammer has taken over your server, either in a limited way
through a vulnerable web inteerface of some sort or possibly in an
unlimited way, restricted only by the risk of discovery.
Unmunged log entries and output from postconf -n and postconf -M might
help us to help you make this easier to analyze but there is a very
strong possibility that the first step towards an actaul fix is to wipe
the system clean and reinstall everything from the ground up (hopefuly
in non-obsolete versions.)
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steadier Work: https://linkedin.com/in/billcole
