Centos 5.4 Root Password Changed and or System Comprimised
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Centos 5.4 Root Password Changed and or System Comprimised
I made a attempt to access my Centos 5.4 system this morning and need to modify a file that required su access. When I attempted to "su" I could not get in with the password that I set. I rebooted the server which made no difference. Either I have been comprimised or I had forgotten my password. How can one reset the admin password to a system and where would I begin looking to see if the system was comprimised?
Last edited by metallica1973; 09-15-2010 at 11:22 PM.
Click here to see the post LQ members have rated as the most helpful post in this thread.
One starting point is to start looking for unusual programs running/listening:
lsof -Pwn
netstat -pane
ps -axfwwwe
I'd also have a good look at the log files and root's .bash_history file. The CERT Checklist is always a good place to start as well. And as quanta suggested, if you have any monitoring tools running, now would be a good time to bring them into the picture.
I was thinking about installing tripwire and IDS like snort. Would that be the bare essentials?
Installing these now would be pretty pointless. Neither of those is going to work particularly well if the machine has been compromised.
As far as tripwire alternatives, take a look at Aide or Samhain. You also might want to think about SELinux since you're running CentOS. Other measures like mod_security might be worth a look, but we'd probably need to have a better idea of what this box is used for and what is currently running.
I am running a chkrootkit on the server as I type this message. I appreciate the advice and you are right that once the system has been compromised what is the worth of putting and IDS and tripwire. I am wondering if an update could have done this. This has never happened to me before so I am very suspicious.
Last edited by metallica1973; 09-13-2010 at 12:13 PM.
also " su " VS. " su -"????
is the system $PATH 100% the same for the normal user as for root ?
most of the time they are NOT the same -- for security reasons
/sbin & /usr/sbin and NOT normally in the normal user's $PATH
as to the system cracked
did you leave the SEinux default setting set to "enforcing " ? or set it to "permissive" or OFF
SE is not 100% but it will stop 95%+
when looking at the audit.log how can one tell the date and time. I dont specifically see anything that specifies that. Also SEliux is not running. I also ran
[root@Aphrodite ~]# find / -group kmem -perm -2000 -print find: /proc/15839/task/15839/fd/4: No such file or directory find: /proc/15839/fd/4: No such file or directory [root@Aphrodite ~]#
here is the root directory on the system. Do these files and directories look normal?
PHP Code:
[root@Aphrodite ~]# ls -la|more total 16424 -rw-r--r-- 1 root root 0 Mar 1 2010 -- -rw-r--r-- 1 root root 0 Mar 1 2010 --- drwxr-x--- 12 root root 4096 Sep 13 12:39 . drwxr-xr-x 27 root root 4096 Sep 13 10:55 .. -rw-r--r-- 1 root root 853 Jun 16 00:47 1 -rw------- 1 root root 0 Mar 1 2010 anaconda-ks.cfg -rw-r--r-- 1 root root 0 Mar 1 2010 Bad -rw------- 1 root root 20142 Sep 14 20:49 .bash_history -rw-r--r-- 1 root root 0 Mar 1 2010 .bash_logout -rw-r--r-- 1 root root 191 Jan 6 2007 .bash_profile -rw-r--r-- 1 root root 176 Jan 6 2007 .bashrc drwxr-xr-x 2 1000 1000 4096 Jul 30 2009 chkrootkit-0.49 -rw-r--r-- 1 root root 39421 Sep 13 12:38 chkrootkit.tar.gz -rw-r--r-- 1 root root 0 Mar 1 2010 Creating -rw-r--r-- 1 root root 100 Jan 6 2007 .cshrc drwx------ 3 root root 4096 Jun 15 12:49 .dbus -rw-r--r-- 1 root root 0 Mar 1 2010 ...done -rw-r--r-- 1 root root 0 Mar 1 2010 drwx------ -rw-r--r-- 1 root root 0 Mar 1 2010 drwxr-x--- -rw-r--r-- 1 root root 0 Mar 1 2010 drwxr-xr-x -rw-r--r-- 1 root root 0 Mar 1 2010 Fe -rw-r--r-- 1 root root 0 Mar 1 2010 Feb drwx------ 3 root root 4096 Jun 15 12:49 .gconf drwx------ 2 root root 4096 Jul 25 15:16 .gconfd drwx------ 3 root root 4096 Jun 15 12:49 .gnome2 drwx------ 2 root root 4096 Jun 15 12:49 .gnome2_private -rw-r--r-- 1 root root 0 Mar 1 2010 Implementing -rw-r--r-- 1 root root 32903 Feb 27 2010 install.log -rw-r--r-- 1 root root 5320 Feb 27 2010 install.log.syslog -rw-r--r-- 1 root root 0 Mar 1 2010 IPTABLES -rw------- 1 root root 35 May 1 14:09 .lesshst -rw-r--r-- 1 root root 0 Mar 1 2010 Loading drwxr-xr-x 2 root root 4096 Apr 12 14:43 Machines -rw-r--r-- 1 root root 35 Mar 3 2010 minicom.log -rw-r--r-- 1 root root 16542064 Feb 7 2010 otrs-2.4.7-01.noarch.rpm -rw------- 1 root root 1024 Aug 9 01:21 .rnd -rw-r--r-- 1 root root 0 Mar 1 2010 [root@c-98-231-171-220 -rw-r--r-- 1 root root 0 Mar 1 2010 -rw------- -rw-r--r-- 1 root root 0 Mar 1 2010 -rw-r--r-- -rw-r--r-- 1 root root 195 Feb 27 2010 scsrun.log -rw-r--r-- 1 root root 0 Mar 1 2010 Setting -rw-r--r-- 1 root root 0 Mar 1 2010 Shutting drwx------ 2 root root 4096 Mar 3 2010 .ssh -rw-r--r-- 1 root root 0 Mar 1 2010 Starting -rw-r--r-- 1 root root 0 Mar 1 2010 Stopping -rw-r--r-- 1 root root 129 Jan 6 2007 .tcshrc -rw-r--r-- 1 root root 0 Mar 1 2010 total drwxr-xr-x 2 root root 4096 Apr 12 15:00 .vmware drwxr-xr-x 2 root root 4096 Apr 21 20:44 .vnc -rw------- 1 root root 81 Mar 7 2010 .xauthsb4zBu
After thinking about it, why would a smart hacker change the root password and instantly give him or her away? It doesnt make sense.
Last edited by metallica1973; 09-15-2010 at 11:23 PM.
and as you can see there is no data for the tenth!
I'm assuming the innocent explanations for that have been ruled out (i.e. someone turned off the computer). If so, then yeah, this is starting to stink.
Quote:
Originally Posted by metallica1973
After thinking about it, why would a smart hacker change the root password and instantly give him or her away? It doesnt make sense.
I agree it doesn't make sense, but there are a couple of explanations. First, maybe this isn't a smart cracker and second, maybe they put themselves into a situation where they needed to change it if they wanted to continue root access. Depending on the machine, it might be some time before someone discovers that the password has changed and depending on the situation, it may take longer to determine it was changed by someone unauthorized. What this does highlight though is the need to spend some quality time developing some facts on the machine.
Quote:
Originally Posted by metallica197
here is the root directory on the system. Do these files and directories look normal?
You would be the better judge of that. Are there things that look out of place? One thing that does strike me is that none of those files have been modified since the 10th. However, if someone is installing stuff, it is probably more likely that they put it someone much less obvious than in /root.
I think at this point it would be useful to do a few things. First, look to see if there is anything unusual running on the box. The ps, lsof and netstat commands I posted earlier would be a good place to start. If there are unusual services, that is not a good sign. If the normal complement of stuff is there, it would be good to verify that the binaries are what is expected using rpm -Vv. Second, since you do have a date, I would examine the machine for files that have been altered or added since the 10th. Since the root password changed, I would also have a good look at root's .bash_history and see if anything jumps out as bizarre. If they have managed to alter the logs, they have probably also altered .bash_history, but it probably doesn't hurt to take a look. Look at your last output and see if any new users crop up or if old users are logging in at unusual times (particularly root).
By the way, feel free to email me any output too big to post here.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
