On 30/11/2007, <b class="gmail_sendername">Ross S. W. Walker</b> &lt;<a href="mailto:rwalker@medallion.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rwalker@medallion.com</a>&gt; wrote:<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><p><font size="2">Find out how they got in and make sure that hole is fixed.<br>
<br>
Do an rpm verify on all installed packages (excluding configs), reinstall the rpms that fail the verify.<br>
<br>
Find all binaries that are not accountable in rpm and nuke them.<br>
<br>
Harden your host with selinux and audit, keep audit logs of all changes to binary files and essential configs&nbsp; and make sure the audit logs are immutable.<br>
<br>
Keep an eye on the system for a while to make sure you haven&#39;t missed anything.<br>
<br>
Keep LVM snapshots of your OS LVs.</font></p></div></blockquote><div>I&#39;d Frank Cox&#39;&nbsp; - you can&#39;t trust anything on the system now (e.g. how can you be sure that the rpm, bash, ls, ps binaries and various kernel modules haven&#39;t been replaced to hide some processes and files? That the boot loader haven&#39;t been tweaked to run some snooper or who knows what?)
<br><br>The only benefit of investigating the current system is in learning what went wrong, report bugs and maybe change configuration in the reinstalled system, but other than that you shouldn&#39;t allow one bit of it to touch a CPU, so to speak.
<br><br>--Amos<br><br></div></div>