My Plesk server sends spam. How about yours?

[voodoochile]

So, I've opened a ticket several times with SW-Soft support about this and it never gets answered, lets see what you guys have.

Currently, Plesk only allows for suexec of CGI (Perl) scripts. Consequently, when you have a ton of domains on a server and ONE has an insecure formmail.php (or simliar) there is NO way to track down which site/form is being abused. You get to see tons of emails from [email protected] going to yahoo/hotmail/etc etc.

This means that any spammer at any time can hammer spam from your server without you being able to track it down and stop it short of just shutting off apache. I consider this a BIG Problem as I've spent probabally more hours this week tracking down spam than I have I have been devloping new plans or antyhing else.

Anyways, I'd suggest taking a look at your boxes for a dumb amout of mail coming from '[email protected]'. If you see that, then well, you're being abused and can join the crowd.

Things Iv'e done to track this so far.

Strace apache pid/children, read through strace dumps for a busy webserver. =(

Setup a script to copy the contents of apachectl fullstats > /tmp/blah so I *might* be lucky enough to find the rogue post. Of course this logs damned near every hit to my server. Not fun.

chmodded sendmail and grepped for Perm denied errors in just about ever error_log under /usr/local/psa/home/vhosts/$hostname/statistics/logs

I'm about to put a hold on reselling Plesk domains unless this can get fixed, I've got better things to do with my time than trying to get removed from spam blackholes because of the software that I run. =\

 

[CoKo]

Why do you think that is a Plesk problem? What exactly do you expect SW-Soft to do?

You will find exactly the same in every (non-secured) shared hostiing environment with Apache and PHP. As soon as you allow your customers to place their own scripts, you're open to all kind of attacks. Also very common is execution of external scripts (eg. placed in /tmp)

There are ways to avoid this - I recommend using suPHP. Works pretty nice with Plesk but needs a lot of configuration.

 

[JD Austin]

The problem is that PHP doesn't run as that user, it runs as the web server. This means that even if you identify the email itself, identifying the account that sent it is like trying to find a needle in a haystack. This could be fixed if suPHP was part of the regular build of PHP.

 

[mikk]

Actually this is fairly easy to sort.

You will need to do it for all your domains (i beleive someone posted a script at one point)

But in vhost.conf add this:

<Directory /usr/local/psa/home/vhosts/DOMAIN/httpdocs>
php_admin_value sendmail_path "/usr/sbin/sendmail -t -i -fXXXX"
</Directory>

Change the path if you are not on FreeBSD.

the XXXX is a unique code - use the domain if you wish thats up to you - but as most spamming is not your own customer i think its best to add this as some random code that means nothing to anyone but yourself

Do the normal websrvmng thing to rebuild httpd.include / restart apache .

Once that has been done each mail sent by php will have a unique per domain code in the Return-Path: using a tool such as qmHandle to view the mailqueue you can see this return-path and consequently go straight to the hosting account and disable the relevant script.