On Fri, 2007-11-30 at 12:26 +1100, Amos Shapira wrote: > On 30/11/2007, Ross S. W. Walker <rwalker at medallion.com> wrote: > > Find out how they got in and make sure that hole is fixed. > > Do an rpm verify on all installed packages (excluding > configs), reinstall the rpms that fail the verify. > > Find all binaries that are not accountable in rpm and nuke > them. > > 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. > > Keep an eye on the system for a while to make sure you haven't > missed anything. > > Keep LVM snapshots of your OS LVs. > > > 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?) > > 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. > > --Amos I agree. Drives have been removed for evidence preservation and that machine will be rebuilt. I do appreciate all the suggestions which increases my knowledge level and hopefully I'll lock it down a bit tighter next time. BTW, traced the culprit IP to Romania. Thanks again. B.J. CentOS 5.0, Linux 2.6.18-8.1.15.el5 x86_64 19:53:46 up 14:13, 1 user, load average: 0.04, 0.06, 0.02 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20071129/ea7c2b00/attachment-0005.html>