Server Slow - Extremely High CPU Usage

One thing is clear - you have alot of running processes.
Is it a busy website? Is it a bad cron? Perhaps a bad script?

Are you running suPHP?
1. Determine who is runinng the most processes and troubleshoot from there.

Code:

ps aux | awk {'print $1'} | sort | uniq -c | sort -n

PS. This looks a bit sketchy - may be worth looking into:

 

Have you enabled user nobody to send mails in the server?

Also check whether there is any spamming going on in the server

You can use the below scritp to check whether nobody spamming is going on in the server

awk '{ if ($0 ~ "cwd" && $0 ~ "home") {print $3} }' /var/log/exim_mainlog | sort | uniq -c | sort -nk 1

For this you need to enable extended login in the server.
To enable extened login

1. Open exim.conf
pico /etc/exim.conf

2) Find this;
Ctrl + W: hostlist auth_relay_hosts = *

#########################
Runtime configuration file for Exim #
#########################



3) After hostlist auth_relay_hosts = *

add the following

log_selector = +address_rewrite +all_parents +arguments +connection_reject +delay_delivery +delivery_size +dnslist_defer +incoming_interface +incoming_port +lost_incoming_connection +queue_run +received_sender +received_recipients +retry_defer +sender_on_delivery +size_reject +skip_delivery +smtp_confirmation +smtp_connection +smtp_protocol_error +smtp_syntax_error +subject +tls_cipher +tls_peerdn


Also check for the mysql process running in the server, which might be the cause for high load, you can use the command mysqladminproc to list the mysql process. If mysql is using the load try restarting the mysql and check whether the load comes down.

 

linux/ Unix thirst

Hello ,

I believe to kill apache and exim and restart them after the load lowers

 

You should disable "nobody" from being used from your server since it's a security issue. Your server may be relaying email as a spam network. I would double check to see if your server has been flagged as spammy within spam databases online.

Make sure to use "capcha security images" for all of your email forms and always use a valid email recipent. Double check and verify each users email for valid formatting.

If you use "tell a friend scripts", get rid of them since good hackers can use the BCC to exploit your email script to send millions of emails in no time flat. (Happened to me years ago, not fun)

Cheers!

Martin Lemieux

 

Switch to using suphp and all user PHP processes will run as the user rather than nobody.

That's a good thing to check. In this case though, it's unlikely you're "relaying" email in the normal sense of the word "relay", although you may have loose scripts generating spam.

The best way to kill these scripts off is to use mod_security with a ruleset that catches Bcc, Cc and To in submitted fields.

One easy way to check the format is to write a small antispam script which checks all input fields and include it in your user's vulnerable scripts. The nice thing about doing this is that it's a one-line modification to fix a poor script. However, mod_security will catch and block most of this.

The problem is actually not with "tell a friend" scripts as much as it is with poorly secured form scripts of any sort. It's simply a matter of making sure the scripts are secure, with suphp/mod_security and some antispammer field checks in the scripts. A "tell a friend" script can be completely secure; if done well, you need never, ever, suffer spam. The use of captcha or recaptcha scripts nails form spam very nicely.

The other useful thing is using the cpanel outgoing email limit to catch any users that start generating spam. Works like a charm ...

If you couple mod_security with CSF, the spammer IP will get blocked after they've tried a few times - a very, very useful feature as it makes it MUCH harder for them to try other exploits. (CSF = Configserver Firewall = http://www.configserver.com/cp/csf.html).

Ralbano - these tips will help you also. The solution is to build in sensible safeguards at a number of levels - a single level of safeguard can always get bypassed. If you combine suphp, mod_security with a good set of rules, CSF for blocking baddies, outgoing email limits in cpanel, use of a PHP antispam script where appropriate, and either SMTP tweak or CSF port 25 blocking, there's not much that can get past.