On 30/11/2007, <b class="gmail_sendername">Ross S. W. Walker</b> <<a href="mailto:rwalker@medallion.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rwalker@medallion.com</a>> 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  and make sure the audit logs are immutable.<br>
<br>
Keep an eye on the system for a while to make sure you haven't missed anything.<br>
<br>
Keep LVM snapshots of your OS LVs.</font></p></div></blockquote><div>I'd Frank Cox'  - you can'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't been replaced to hide some processes and files? That the boot loader haven'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't allow one bit of it to touch a CPU, so to speak.
<br><br>--Amos<br><br></div></div>