On Wed, October 9, 2013 10:41 am, Stan Hoeppner wrote: > On 10/8/2013 3:08 PM, li...@sbt.net.au wrote:
Stan, Michael and other who responded, thanks > Others responded with some good ideas here, mostly locking down PHP > itself so it can't use the sendmail binary. But it sounds like this is a > generic web hosting server for your customers. Which means they may be > using all manner of languages other than PHP, such as Perl, Java, etc. modified php.ini as per Micheal's suggestion; yes, it is as you suggest, 'all manner..'; > In this case, the most thorough way to lock this down, other than > disabling the pickup service in master.cf, is to restrict execute > permissions on the sendmail binary to root. This prevents all web > applications from using the pickup service. Then instruct all of your > users to use the submission service on TCP 587 for sending mail. > Disabling pickup is the easiest and quickest way to stop this spamming > permanently. But it will likely break management functions that need to > send mail via pickup, such as logwatch, pflogsumm, etc. Thus restricting > which users can execute the sendmail binary is a better solution. I'll work towards that later today I'm still perplexed with access: the user claims no one else had ftp password, ftp password was a random 8-char alpha/numeric string, can there be any other reason that leaked password...?
