First off, a few observations:
-Even though the banner grabbed is for LiteSpeed (a drop-in Apache replacement), the resulting access is through the Apache user
-Since the initial resulting access is through the Apache user, most likely this is an Apache/LiteSpeed level vulnerability, not a kernel vulnerability.
-.bash_history: Another ouch.
Secondly, how to better secure the system:
-Using an Intrusion Dection System like OSSEC, would have alerted the admins as critical files were changed.
-Using a Layer 7 (Application Layer) firewall could have filtered out the bad input that resulted in the initial web user compromise
-Don't store user's / customer's passwords. Always use a salted hash.
-Don't tick off attackers. :)
Finally, resources for md5 rainbow tables:
http://www.freerainbowtables.com/en/tables/md5/
http://project-rainbowcrack.com/table.htm
btw, I agree with Unknown, which is why I posted these links as evidence.
Anapologetos
Try to lower down var_size. If we had value at 64MB, after a few hours it started to swap a lot, and after next few hours it was completely down. Try to keep original settings at 32M, maybe this should help you a lot - we had the same problem at our travel site Xcache is still a lot of buggy software :(
Best Answer
Use the open_basedir directive to confine your PHP scripts to their home directory and eventual extra application directories. This is very efficient by itself.
Use hardened php because that costs nothing and it can help.
Use suPHP to have PHP scripts execute as the owner of the file (one user per website) and avoid using files with bad permissions such as 777... suPHP can also allow you to have on php.ini per website so that one site's stupid requirement don't destroy everything.
Mod_security is a big plus but needs to be well used and configured.