> I would suggest that you fix the exploited script. Look for time
> stamps that appear in both web server logging and Postfix logging.
Thanks, Wietse. That would obviously be the best approach, if it
worked, but I tried it and (so far at least) haven't been able to find
any matching entries.
I did find some generally suspicious things in my web server logs --
including lots of clients looking for the following item:
/nette.micro?callback=shell_exec&cmd=ifconfig
but there isn't any /nette.micro anywhere on my server, and all these
GET requests failed with 404 or 302 SMTP response codes. I don't
currently think these have anything to do with the recent attacks on my
server, and I'm mentioning them just in case anyone on this list might
recognize this kind of thing.
As I said earlier, I did clean out a bunch of old, obsolete, possibly
buggy content from my web server's directories, and I rebooted the box
just for good measure. I haven't seen any more occurrences of the
problem so far, but I am keeping a close eye on the server, and if I do
see another flood of apparent open-relay messages, I hope I can capture
more (and more useful) information about the problem this time.
In the meantime, I would still like to know if there is any way to make
Postfix check for and reject messages which are coming from localhost
but which are falsely claiming (in the HELO / EHLO) to be originating
from some outside host. I realize this wouldn't solve every problem,
but it seems to me like a very useful thing for Postfix to be able to
do. If this option is intentionally not and most likely never will be
part of Postfix, I would be grateful for an explanation of why it is not
actually helpful, even if it might appear to be at first glance.
Rich Wales
ri...@richw.org
