<br><br><div class="gmail_quote">On Thu, Jan 22, 2009 at 1:48 PM, Wilton Helm <span dir="ltr">&lt;<a href="mailto:whelm@compuserve.com">whelm@compuserve.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">






<div bgcolor="#ffffff">
<div><font face="Arial" size="2">There have been a number of answers provided.&nbsp; 
The one that was given to me when I encountered this same problem was to boot a 
live CD, mount the root file system and delete the password file which would 
force your normal distro boot to request a new root password next 
time.</font></div>
</div></blockquote><div><br>I&#39;d highly recommend to NOT simply delete your password files (/etc/passwd &amp; /etc/shadow)... you are deleting a lot more than just your compromised your root password by deleting these files.&nbsp; You are also deleting every other account that is on your system (ie. you should be running Asterisk under its own account and not as root!).&nbsp; Of course it depends on what other things are running on your server, but you cannot reasonably expect your distro to keep track of every change you have ever done to these and re-create it.&nbsp; It might give you a skeleton version like you are suggesting, but you are certainly going to lose data.<br>
<font face="Arial" size="2"><br></font><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div bgcolor="#ffffff"><div><font face="Arial" size="2">Step 
3 was replace a few key executables like ps so I couldn&#39;t do administrative 
tasks</font><font face="Arial" size="2">&nbsp; </font></div></div></blockquote><div><br>I can&#39;t really speak about your case specifically, but generally replacing certain executables like ps, netstat, login, w, who, etc. etc. are not done to prevent administrative tasks - infact, a person that actually knows what they are doing with a rootkit doesn;t actually want to prevent you from doing administrative tasks.&nbsp; Generally they don&#39;t want you to know at all that they have broken into your system.&nbsp; The reason why these binaries get replaced is to try and cover their tracks.&nbsp; for example, they replace &#39;ps&#39; so that it will not display certain processes running on the system (making it harder for you to even notice), the same with netstat, it will not display network connections to certain IPs, &#39;login&#39; gets replaced with a version that has a hard-coded login &amp; password that will grant root access to your system without knowing (or caring) what the real root password is, and might also not do a few things that are part of the normal login process... like writing to UTMP / WTMP so there is no record of the login.<br>
&nbsp;<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div bgcolor="#ffffff"><div><font face="Arial" size="2">The problem is that you don&#39;t know exactly what 
files have been changed and if they have left a trap door or something.&nbsp; 
You could fix the root password, and even discover and restore a few key files, 
only to find it hacked 5 minutes later because you didn&#39;t know everything that 
had been altered.&nbsp; For that reason, few people will put a system back on 
line after the root password has been compromised.&nbsp; Re-installation is the 
only safe way.&nbsp; If some of your directories like /home and /user have 
separate mount points, they don&#39;t have to get wiped out in the 
process.</font></div>
</div></blockquote><div><br>This is getting a little off topic... but there actually are ways of determining exactly which files have been changed.&nbsp; Stuff like &#39;tripwire&#39; has been around for like a decade and is designed to do exactly this... everytime you run it, it will tell you every single file that has changed.&nbsp; It does this by creating hash of every file when you run it and then compares those hashs to previously stored values.&nbsp; If the hashes do not match, then something has changed and gets reported.&nbsp; Of course hashes can be defeated, it is however not entirely easy, and way beyond what your typical script kiddie hacker is going to be capable of doing.&nbsp; And of course, that is just what trip wire does... there are plenty of other intrustion detection systems that I;m sure do things a little differently.&nbsp; Some other things like FreeBSD used to (maybe still does?) come with some basic security stuff that was installed by default and emailed you daily reports about things that changed.&nbsp; Like any new binaries it found on the system that were setuid root (ie. cp /bin/bash /var/spool/.myhiddenrootshell ; chown root /var/spool/.myhiddenrootshell ; chmod u+s /var/spool/.myhiddenrootshell).&nbsp; Something like FreeBSD&#39;s scripts were intelligent enough to find basic things like that.<br>
<br>That being said, I do agree with you, re-installation in 99% of cases is a superiour option when compared to trying to restore a compromised system.&nbsp; Typically its much quicker too.<br></div></div><br>