My postfix server is filled with spam, I did find the UID of apache is sending a lot of it so its probably a php script somewhere. I have disabled domains but it is still being sent out.

I found one hidden file and removed it and have added logging in PHP 5.3 for scripts, although it doesn't log the contact form on my website for some reason in a test. http://www.howtoforge.com/how-to-log...tect-form-spam.

Help getting this resolved would be great....Centos5 box running Plesk 11, php 5.3. Thank You.

I tried stopping httpd, clearing the postfix queue and mails are still going out, I guess I am wrong about the php script?

At this point you need to determine both the source of the emails and how the infection occurred. Failure to do so will greatly limit your ability to prevent it from recurring.

Here at LQ-Security, we follow the dated but still useful CERT Intruder Detection Checklist. In performing this process, you will want to disturb the system as little as possible. Do not power cycle it, do not reboot, do not try to "clean" it. Your absolute best option is to isolate the machine by either removing the network cable or raising a firewall so that it is accessible from a trusted location only. Attempting to operate the machine while investigating will only make your process harder and it may tip off the intruder as to the fact that they have been "made" causing them to either cover their tracks or destroy on their way out.

While proceeding be sure take make notes of what you are doing and keep a log/journal. Once you have secured the machine as much as possible, there are five things that I would like you to start focusing on:

1 - think back and make notes regarding when the problem started occuring. Did anything notable happen about that time, did you make any changes, etc. Also, what distribution are you running, what revision level? What server and content manager applications are you running (e.g. Apache, SSH, FTP, atmail, CPanal, plex, nagios) and what revision level. What would you say the overall patch state of the system is? Do you routinely apply updates? Do you have any sort of intrusion prevent software in place, e.g. Aide or Ossec? Do you use a firewall to close unused ports and are you running SELinux?

2 - capture a snapshot of the process tree, network connections, and open files. Be sure to run this command as root, else it will miss important process information that will help to link the pieces together.

3 - perform a detailed analysis of your log files. The best way to get started with this is to use the tool logwatch. From a known safe machine, download a copy of it and then transfer it to this host. Use the following command. Again, run it as root or else you won't be able to access all of the log files (this works on Centos, for debian you may need to use the --save /path to log instead of > redirect):

4 - Using the Cert checklist, perform the steps for finding hidden files and scripts (step 9). Pay particular attention to /dev, /temp/, and /proc. Also look for any files with setuid or setgid (step 2), check all of the cron and at tables for modifications (be sure to look in /var/spool/cron).

5 - Try to verify your system binaries. Since you are using Centos use RPM -vV.

thanks for your help, I am working through these items. A few things...

Can I clear contents of /tmp? There are a few files which make me suspicious.
Results of process tree command

Crons seem to be fine, I don't see anything suspicious. Can someone answer my earlier question about httpd and php scripts?

RPM command is failing......

Sorry about the RPM verify command syntax. Try: rpm -vVa, the 'a' tells it to verify all packages. I just tested this out on a Centos system, got the same error, and read the man page.

While performing your investigation it would be best for you to NOT clear any contents or not try to clean the system. In fact, these files may be linked and in use to whatever activity is happening. This is why it is imperative that you capture a process and file tree snapshot. Clearing things runs the risk of destroying evidence of what your trying to find. It may also tip of an active intruder that they've been discovered and prompt them to commit sabotage. In fact, you should not be trying to operate this system at all. It should be removed from the network and replaced with a backup. There are many forums who claim to help people with compromised hosts. In my opinion, the advice given by most of them is deplorable and most of the time the recommendation is for a wipe and reinstall which does nothing to address the problem. Here at LQ we strive for a higher standard and obtaining that standard requires a level of commitment from those effected.

Your output showing the PSA log tells me that you are running plesk (I see you mentioned this in your earlier post). This is yet an another avenue of potential compromise. You should confirm your versions and see if there are known vulnerabilities. I agree that on the surface that this looks suspicious and may be an indication of an intruder gaining shell or other control access. Note, that it isn't the process tree that I asked for in the previous message, which you could have gotten by running ps acxfwwwe. Please see the command set I mentioned previously.
One of the most important things you need to do is avoid jumping to conclusions. The fact that mail continued to go out after shutting down your http server and clearing the postfix queue suggests that the problem is not confined to a rogue php script but lies somewhere deeper in the system. It is true that this is common avenue for this type of intrusion, but certainly not the only one.

Examining the process tree, network connections list, and open files list provides a good chance of capturing the rogue process and showing its true location. Coupling this information with log files (which hopefully you've captured and saved) may show how the intrusion occurred. Before running these commands, verifying them with rpm verify will ensure that your not getting bogus data that is meant to throw you off. The command may also show if system files have been modified and hence provide information regarding the intrusion.