On 10/8/2013 7:15 PM, li...@sbt.net.au wrote: > 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
Look at every file in this user's publicly accessible directory tree. You may find that s/he saved the username/password in a text file (regardless of file extension, or name), which is quite common for many users, especially those who don't update the site but once every few weeks, months, etc. They bookmark the URL and "remember" the credentials this way when they need to work on the site. Crackers will often find such files, even if not exposed anywhere in the HTML content of the site. > password, ftp password was a random 8-char alpha/numeric string, > can there be any other reason that leaked password...? There are all manner of ways credentials can fall into the wrong hands. Above is only one. The simplest is the Post-it note, both literally and metaphorically. You can't control this. What you can is the password itself, and the frequency of change. Random passwords are meaningless if someone can simply copy or steal the Post-it. Changing passwords regularly helps mitigate this problem, but not if users simply put the new password in an accessible file, as in the scenario above. -- Stan