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.
-Ross
-----Original Message----- From: centos-bounces@centos.org centos-bounces@centos.org To: CentOS mailing list centos@centos.org Sent: Thu Nov 29 17:43:44 2007 Subject: [CentOS] CleanLog.h
Sad to say one of my file servers was exploited and used to run a Phishing scam. Have identified subject virus amongst other things. It appears twice in a virus scan; /sbin/z (which I assume can just be deleted) and /sys/bus/serio/drivers/atkbd/description. The latter file is also present in identical uninfected machines. I have been unable to open the file, even with root privileges, although it appears to be a text file. Any suggestions on how to proceed appreciated. Guess I could delete it and copy over the file from an identical machine.
Thanks in advance, B.J.
CentOS 5.0, Linux 2.6.18-8.1.15.el5 x86_64 16:26:48 up 10:46, 1 user, load average: 0.07, 0.08, 0.04
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.
On 30/11/2007, Ross S. W. Walker rwalker@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
On Fri, 2007-11-30 at 12:26 +1100, Amos Shapira wrote:
On 30/11/2007, Ross S. W. Walker rwalker@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
-
Amos Shapira -
B.J. McClure -
Ross S. W. Walker