Webdiggity wrote:Just recently, I updated all of the system software and whm so that could possibly be alot of the reason, right?
Most certainly, depending on what system software you updated. If they were RPMS then it wouldn't account for all the permissions problems.
My provider seems to think it might have been a script kiddie using an exploit off of a 3rd party php package like nuke or something.
Very likely. One of the members here alerted me to a security issue with my phpMan pages. You could read any file on my system using the right URL Well, not any file, only files that the apache user had read access to, which still can give out key information.
I downloaded a new PS and another package that has find, ls and a bunch of others. I can upload them to a dirctory call audit and 'make' them static from what I learned reading up today. However, how do I make sure I'm running those commands and not the ones on the system?
Couple of ways. One way is to preface each command with a "./" if you have changed into the directory where they reside, or better yet just type this on the command line after logging in:
# export PATH=/path/to/your/static/commands
Sorry about all the questions, I also have a new server coming this weekend complete with dual 80gig drives. I'll be using rsync to make daily incremental backups on the second drive unless you have a better suggestion.
That is better than nothing, but it would be far better if the backups could be moved off to a separate machine, or to tape, etc. A person that has root can wipe out your entire system with a single bound.
This has definitely been a big lesson for me. Can you point me at some good resources for security? I think I need brushing up in that area. I can upload packages and edit files and do searches comfortably now but I think, no, I KNOW, I have to bone up on my security practices.
Security is one of the most important things and something you can never stop trying to be better at. This will get you started:
http://www.sans.org/
http://www.cert.org/
It's a humbling experience no? :)
EDIT: I forgot to mention that if it is a script kiddie that exploited a flaw in a php script etc, then if you build the new system just like the old you'll still have that hole open. I wouldn't personally feel comfortable until I found out exactly how the person was able to modify those files. For instance, I would want to know what the owner/group and the mode (permissions) on the files that were changed. If the permissions were such that the user your web server runs under could not have modified them then it's likely they were in with root access, that's more than exploiting a PHP script vulnerability. The user the web server runs under should not have permission to do squat.