On 10/7/2013 11:19 PM, li...@sbt.net.au wrote: > On Tue, October 8, 2013 3:02 pm, Stan Hoeppner wrote: >> On 10/7/2013 9:10 PM, li...@sbt.net.au wrote: > >> Without the log entries Simon asked for we can't do anything more to >> help you, as we don't know how the spam is being injected. Please provide >> logging that demonstrates the problem. > > Stan, thanks, > > sorry, I thought that part was sufficient in my message: > >> there is a php script on their web as so, I'm trying to see how it was >> uploaded at this point: >> >> --------------------- >> head xmlrpcVZY.php > > there was a php script uploaded and called > > Oct 7 23:53:07 postfix/pickup[27638]: DA64B3829CE: uid=48 > from=<lola_cl...@dom.tld> > Oct 7 23:53:07 postfix/qmgr[10092]: DA64B3829CE: > from=<lola_cl...@dom.tld>, size=891, nrcpt=1 (queue active) > > ... > Oct 7 23:53:07 geko postfix/pickup[27638]: DA64B3829CE: uid=48 > from=<lola_cl...@dom.tld> > > 216.187.94.181 - - [08/Oct/2013:15:07:17 +1100] "POST /xmlrpcVZY.php > HTTP/1.1" 404 211 "-" "-" > > --------------------------------- > > I've removed the script, I stopped ftp (it seems it was ftp'd) > > at the time I've posted, I was on a 4" mobile, and, I was looking for a > stop gap measure to 'stop further damage' from that point
Understood. For a more permanent solution to this script problem, you may want to consider locking down or disabling the pickup service, and configuring all web applications and MUAs to use the submission service with auth. This will prevent such scripts from being able to send mail in the event some crafty soul is able to get one uploaded via something other than FTP. -- Stan
