The problem is that a user on this box appears to be launching high traffic DOS attacks from it towards other sites. These are UDP based floods that move around from time to time - most of these attacks only last a few minutes.
I've done tcpdumps within seconds of the attack starting and to date been unable to find the source of this attack (we know the server, just not sure which customer it is on the server that's been compromised). Several hours of scanning for php, cgi, pl type files have been wasted and come up nowhere...
As others have suggested turning off remote file includes is a good start in php.ini. PHP5 has some rather nice settings to allow more flexible configuration of this (while still allowing PHP programmers to be lazy and do things like file('http://foo/index.php') but I digress). Plesk uses open_basedir by default on its Apache config which will help limit what the hacker has access to via the web daemon. However it still allows unrestricted access to /tmp for obvious reasons. We generally set /tmp to be noexec and nosuid for our disk images. This helps make things more difficult for the script kiddies, but doesn't stop them completely. Most likely since you are dealing with customer data that must be maintained from each instance of the server and that is most likely the attack vector being exploited (since it is common to each instance of the server). Either a PHP based shell, something as simple as a file uploader/shell script, or the aforementioned remote file include is likely the cause. They are most likely uploading a perl script to /tmp, firing it off with a shell command via the apache user, then removing it from /tmp and masking its program name so that it doesn't appear obvious in a report from ps (I have seen httpd most of the time, which is fairly obvious to spot on a Debian server thankfully - apache runs as apache(2) on Debian rather than httpd on RedHat/CentOS). If you are able... I would create a noexec,nosuid /tmp mount and if at all possible... limit perl to only be accessible for the root user (chmod 700). This is a tad extreme, but it has helped me in the past. Another thing (if that isn't possible) is to place a wrapper around perl that will log what user accessed perl, at what time, and which script was executed. This information will prove to be invaluable in helping narrow down where the attack is originating. Once you have a timestamp, it's just a matter of going through your logs to find what was going on where at that specific instant on the server. Also take a look at the server wide apache logs (in /var/log) as there might be valuable information in there perhaps leading you closer to a culprit. Good luck, these sorts of issues are difficult to track down and take time and patience to clean up. If you would like please contact me off-list for more assistance. I have been using Plesk since 1.0 so I am pretty familiar with its ins and outs. Warm regards, Tom Walsh