Mail server recently became an open relay

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Mail server recently became an open relay

ilyak
If someone hacked your PHP script, he or she may add any code to it, including code that connects to your smtpd and sends email.
In PHP one can use mail() function (which can use TCP connection to the localhost:25 according to the settings in php.ini) or establish connection directly.

As we can see from
>Oct 15 14:48:06 memoryalpha postfix/postscreen[18030]: CONNECT from [127.0.0.1]:52138 to [127.0.0.1]:25

Some locally running process just connected to your server and send spam.
I think you can use iptables to log all connections to this port to catch the pid of the culprit.

As a quick-and-dirty solution you can move your smtpd to the different port (see master.cf). 
Script would not know about the new port, hence it wouldn't be able to connect to postfix.

Or you can move smtpd to the unix domain socket or even disable it and use the "sendmail" interface instead.

Greping your scripts for "socket_connect" and "mail" is also worth doing.

Btw, this is not an "open relay": relaying mail from the localhost (127.0.0.1) is the default postfix behavior because "mynewtorks = 127.0.0.0/8" in may installations,
and "smtpd_relay_restrictions" includes $mynetworks by default.

If you were running each website in the separate docker instance for example, then you would be able to create the separate port for each container in master.cf, and know for sure which one was hacked.






On Mon, Oct 19, 2020 at 9:51 PM Rich Wales <[hidden email]> wrote:
John Fawcett wrote:

> One thing I would suggest looking at is if there is a web server running
> on the same host it may be allowing email to be injected into postfix
> via smtp on the loopback interface using some scripting language like
> php or others.

I suppose that's possible.

I spent some time last night cleaning up old stuff from the server in
question -- and also rebooting the box for good measure -- so the
problem *might* just go away at this point.

Before I can say anything more about this, unfortunately, I'll probably
need to wait for another incident similar to the preceding ones, and try
to capture more evidence while the problem is ongoing.  If it never
happens again, then maybe it was the fault of an old PHP web page which
I have removed.

If the problem were in fact due to a hijacked PHP page, btw, would this
necessarily require the page to be using e-mail or TCP connections
already for its own legitimate purposes, but being co-opted by a hacker
to nefarious ends?  Or could *any* PHP script theoretically be infected
in a way that would cause this misbehaviour?

Rich Wales
[hidden email]

Без вирусов. www.avg.com
Reply | Threaded
Open this post in threaded view
|

Re: Mail server recently became an open relay

Bob Proulx
In reply to this post by Bob Proulx
Bob Proulx wrote:
> The default PHP "mail()" method sends mail by using the system's
> /usr/sbin/sendmail interface rather than SMTP.
>
>     https://www.php.net/manual/en/mail.requirements.php
>     https://www.php.net/manual/en/function.mail.php

Oh!  It depends upon the system's php.ini configuration.  For which
there might be many.  Here is an (older) 7.0 system for example.

    /etc$ find php* -name php.ini
    php/7.0/cli/php.ini
    php/7.0/apache2/php.ini
    php/7.0/fpm/php.ini

And the php.ini for both FPM and Apache contains:

    [mail function]
    ; For Win32 only.
    ; http://php.net/smtp
    SMTP = localhost
    ; http://php.net/smtp-port
    smtp_port = 25

My bad for posting my previous misguided information.  Sorry about that.

Bob
Reply | Threaded
Open this post in threaded view
|

Re: Mail server recently became an open relay

Demi M. Obenour
In reply to this post by Jaroslaw Rafa
On 10/19/20 3:29 PM, Jaroslaw Rafa wrote:

> Dnia 19.10.2020 o godz. 21:12:20 John Fawcett pisze:
>> Sorry not to be able to give a definitive answer. Typical mail injection
>> via php will use a script that already calls the php mail function or
>> similar functions that open the smtp connection. But there are other
>> attack vectors that are possible that allow hackers to gain the
>> privileges of the web server user.
>
> Very often hackers abuse web pages that allow users to upload files to the
> web server. If the input is not correctly sanitized, it may be possible to
> upload an arbitrary php script and get it executed.
>
> There were multiple attacks based on this scenario.
Can this be mitigated by denying the PHP user write permission on
any directory where PHP files will be executed?

Demi


OpenPGP_0xB288B55FFF9C22C1.asc (3K) Download Attachment
OpenPGP_signature (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Mail server recently became an open relay

Jaroslaw Rafa
Dnia 19.10.2020 o godz. 18:26:28 Demi M. Obenour pisze:
> Can this be mitigated by denying the PHP user write permission on
> any directory where PHP files will be executed?

There are multiple methods to mitigate this, this may be one of them.

But unsecured scripts that allow such behaviour are still being found here
and there.
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
Reply | Threaded
Open this post in threaded view
|

Re: Mail server recently became an open relay

ilyak
In reply to this post by Demi M. Obenour
Rock solid solution is to separate htdocs (a folder that is accessible via web) from the code folder (the one with scripts).
I do not know how that could be done with PHP (I believe you can serve static files with nginx and run php as FPM connected to the nginx with FastCGI) but in Python world we have separate process (uwsgi or gunicorn) that is connected to the nginx and it runs under the different user.
All user files are uploaded to the folder accessible by nginx, far away from the folder with python scripts.
Even if you upload a .py file, nginx will serve it as a static plain text file.

On Tue, Oct 20, 2020 at 1:27 AM Demi M. Obenour <[hidden email]> wrote:
On 10/19/20 3:29 PM, Jaroslaw Rafa wrote:
> Dnia 19.10.2020 o godz. 21:12:20 John Fawcett pisze:
>> Sorry not to be able to give a definitive answer. Typical mail injection
>> via php will use a script that already calls the php mail function or
>> similar functions that open the smtp connection. But there are other
>> attack vectors that are possible that allow hackers to gain the
>> privileges of the web server user.
>
> Very often hackers abuse web pages that allow users to upload files to the
> web server. If the input is not correctly sanitized, it may be possible to
> upload an arbitrary php script and get it executed.
>
> There were multiple attacks based on this scenario.

Can this be mitigated by denying the PHP user write permission on
any directory where PHP files will be executed?

Demi

12