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. <#m_-2421472136311685306_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Mon, Oct 19, 2020 at 9:51 PM Rich Wales <ri...@richw.org> 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 > ri...@richw.org > <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Без вирусов. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
