On 3 Jun 2018, at 18:08 (-0400), Proxy wrote:
On 2018-Jun-03 17:06, Bill Cole wrote:
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.
It's most likely our own script, the one that have these credentials
in
it. How it is exploited I still don't know, but not likely that it's
possible to send after I have disabled this account.
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.
Not sure why. Care to elaborate?
You were inquiring about traffic being really from a local IP address or
not. If you wipe out all distinctions between different IP addresses and
hostnames, possible issues relevant to the problem become invisible.
Also: there's almost never any marginal risk in "exposing" an IP address
of a mail server. It might be prudent to obfuscate an IP address of a
SMTP client in some circumstances, but not in this case.
According to
http://www.postfix.org/DEBUG_README.html#mail it's the way to go.
That does not recommend obfuscating IP addresses.
It speaks of anonymizing email addresses. IP addresses are NOT email
addresses.
You
just need to use same substitutions. So DD.DDD.DD.DDD is always the
one
and same real world IP. Different IP would get different value.
That is not obvious from the obfuscated log & config.
Note that we have seen problems here entirely due to transposing or
omitting characters in an IP address or hostname.
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.
Probably not. Handshake is sent to postmaster@me from MAILER-DAEMON.
That's how I noticed the problem. I'm just not sure what is the value
for spammer in sending to the user@mydomain. It would make more sense
to
send to some outside victims.
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.
I assume you are using some bleeding edge distro,
I don't use any system vendor's version of any open source MTA on
production mail servers that are exposed to the Internet.
However, as Wietse noted, I wrote that a bit too hastily and harshly,
and I apologize for the tone and implication. I realize that this may
not even be a "production mail server" in the sense of being primarily
tasked with handling mail to and/or from the world at large, so it may
be entirely reasonable to stick with the base MTA.
but for us using
production servers, it makes more sense to use long supported distro
with regular security patches. Like CentOS 6. I'm confident that
CentOS
security team does a good job providing latest security patches RedHat
releases including those related to Postfix.
That would be an issue to debate in some other venue.
For here, it is generally a good idea to note if you're using a variant
vendor-custom version of Postfix. Debian, Apple, and RedHat have all
distributed customized versions.
[...]
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.)
You probably know that there is no postconf -M on my ancient Postfix,
so
you're just pulling my leg, right?
No, just not editing myself well.
The alternative to 'postconf -M' would be 'grep -v '^#'
/etc/postfix/master.cf' and this MIGHT have been useful to discover if
you had something like amavisd configured, which could make it look like
mail is originating locally when it is not.
I'm glad that you've identified the specific problem script. I hope you
figure out its breakage well enough not actually need to do a full wipe
and reload.
--
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
