keepertoad at verizon.net
Fri Nov 30 01:58:24 UTC 2007
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
> 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
> 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.
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.
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...
More information about the CentOS