Searching for Spammers

I have added a new page to our site to explain some of the processes that we go through when Searching for Spammers on a server. The hope is that this will help readers to understand where spam comes from and, using that knowledge, how to backtrack through the server logs to find the entry point on your server.It isn’t meant to be a comprehensive guide on the subject, but I hope it gives you a starting point. Hopefully it also illustrates some the work we do as part of our Anti-Spammer/Exploit Service.

Potential Apache issues due to Zend Optimizer v3.0.0

Just had a problem on a clients server which took a while to track down.Symptoms: If you rebuild apache/php and find that httpd appears to hang without spawning any children and nothing in the error log, this could be the problem. Using an strace on httpd -X shows the binary hanging on apache module loads.I finally tracked this down to Zend Optimizer v3.0.0 which is available in the current EDGE/CURRENT releases of cPanel ( 10.8.2-EDGE_41) in /scripts/installzendopt. Trick is to edit the script and set:

my $ver = ‘2.6.2’;

Then rerun the script and restart httpd. Hopefully this will help anyone who finds themselves with the same issue.

New Service: Server Recovery

As many of you may be aware we have always provided a cPanel server recovery service when asked. We have now formalised this service for anyone who needs it should they have OS disk problems:

  • Root compromise – if your server gets hacked and is therefore no longer trustworthy
  • OS disk failing – if the OS disk is starting to log errors indicating an immenent drive failure
  • OS corruption – if the file system is becoming corrupt
  • OS upgrade – if you want to upgrade from an old unsupported OS to a new one
  • Corrupt kernel – if you’ve upgraded the kernel and it has rendered the server unbootable of any kernel
  • Any situation which leaves your main OS disk unbootable

More details on the Server Recovery Service page.

Why you should use :fail: – addendum

I have added the following to the Why you should use :fail: page on our site:

Causes emails that will never be delivered onto the exim mail queue because checks such as sender verification are still carried out when processing such emails and if they cannot complete they will stay on the exim mail queue and repeatedly reprocess the email until it is finally discarded (usually 4+ days). This can cause very large mail queues full of spam which is repeatedly processed causing severe performance degradation