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...?




Reply via email to