On 2020-10-21 09:18, Benny Pedersen wrote: > why do you SHOUT at Wietse ?
I was not shouting -- at least not intentionally. I was being emphatic, and perhaps a little frustrated at the suggestion that I might have been hit by a WordPress exploit even after I had said earlier in this thread that I'm not using WordPress. I intended no offence to Wietse or anyone else, and I wish to apologize to anyone I might have inadvertently offended. > try wget 127.0.0.1:25 and se what postfix responce to http remotes $ wget 127.0.0.1:25 --2020-10-21 10:20:27-- http://127.0.0.1:25/ Connecting to 127.0.0.1:25... connected. HTTP request sent, awaiting response... 200 No headers, assuming HTTP/0.9 Length: unspecified index.html: Permission denied Cannot write to ‘index.html’ (Permission denied). $ Not surprising that this command failed, I suppose, since Postfix isn't an HTTP server. I've also checked for illicit listeners -- though I will check again. Since this box lives behind a physically separate firewall appliance system, in addition to having its own host-based firewall rules in place, a breakin -- though obviously not impossible -- is probably less likely than if the server were connected directly to the Internet. For the time being, I am going to continue to monitor the system in question and see if any further instances of the "fake open relay spam flood" problem occur. No more incidents in the last several days (cross fingers and touch wood). The next time it happens (assuming it does), I will take a much more careful look at what is going on, in hopes of catching the offender in the act. In order not to scatter any more spam onto the Internet, I'll temporarily block inbound and outbound SMTP in the firewall while I'm investigating the next incident (again, assuming there is one) -- previously, I stopped Postfix, but this may have made it harder for me to track down the issue in real time. I would still like to figure out a way, btw, to catch locally generated spam of this sort in Postfix. I've already asked here about rejecting HELO/EHLO when the client is localhost but the HELO/EHLO host is not localhost -- I still think this would make sense, but I'm getting the clear impression that it's just not there and just isn't going to get added. Or maybe I can reduce my use of permit_mynetworks in my configuration -- I am currently invoking permit_mynetworks in my client, HELO, sender, relay, and recipient smtpd restrictions, maybe this is excessive. I'll also check on other lists, do more extensive web searches, etc., to see if anyone else out there has encountered this kind of attack. As a very last resort, I may consider wiping and rebuilding the system, but I'm not willing to expend the time and energy to do that without first having some reasonably specific evidence indicating exactly what has happened. Rich Wales ri...@richw.org
