Re: barbut anyone?
Steve Holdoway <[email protected]> Wed, 16 Nov 2011 20:28:14 +1300
| Newsgroups | gmane.org.user-groups.linux.new-zealand.general |
|---|---|
| Organization | Green Gecko Global Ltd. |
| Message-ID | <1321428494.687.822.camel@steve-desktop> |
On Wed, 2011-11-16 at 19:23 +1300, Martin D Kealey wrote: > On Wed, 16 Nov 2011, Jaco wrote: > > > Hate to say it, but root ownership means server ownership in most > > > cases. I'd be disinclined to trust any executables on that server now. > > > Especially since you say that keeps returning. > > Yip - you may already be in a bad way (thinking rootkits). > > If your system is already compromised, you may need to boot up with some sort > > of live/recovery system & try your recovery from that. > > First thing I use is a hand-rolled version of "ls" that's written entirely > in Perl (see attached). > > It does pretty much everything that normal "ls" does, and you can read it to > make sure it hasn't been compromised. It's conceivable that /usr/bin/perl > gets compromised, or the kernel, but it's a good start. > > If the "mtime" is older than the "ctime" on a file, my "lsx" puts a "*" next > to the date. This is useful for spotting files which have been touched and > then rewound. Some of them will be harmless -- like if you've unpacked a > tarball -- but anything like that in /bin or /etc indicates trouble. > > I'd start with "lsx -3 --find /*bin /usr/*bin /etc" to check what's been > interfered with. As long as "/bin/mount" and "/etc/fstab" are OK, I'd then > mount an external drive with a root filesystem, and set $PATH to point at > /mnt/bin:/mnt/usr/bin:...etc... > > All this assumes you can't (or can't afford) to reboot the host off a > LiveCD, which is on the whole a lot simpler. > > > Recover what data you can & start again from a sterile environment. > > > > This may also mean that other hosts/nodes on your network could be compromised > > - nmap may help with analysing suspicious traffic. > > > > Some interesting reading-material as mitigation for future reference: > > * DSD Top 35 Mitigation Strategies > > (http://www.dsd.gov.au/infosec/top35mitigationstrategies.htm) > > (still struggling to get my head around AppArmor/SELinux - it's a beast!) > > > > Would be curious to know what AV's & other security suites/products/solutions > > other folks are using (Clam just doesn't cut it) > > > > - J > > To the best of my knowledge linux doesn't save the file creation time. There's the last mod time of the inode, but that's not the same thing... I just compared and contrasted md5s of a known, clean, up to date system. The few files left, I checked by hand. As I had a last mod date on the files - all 3 the same, as was the last mod of rc.local, I'm pretty sure it's clean. It's only a web server, so no need to be that paranoid about it... I just needed to work out how it was hacked, and being reinfected (: Cheers, Steve -- Steve Holdoway BSc(Hons) MNZCS <[email protected]> http://www.greengecko.co.nz MSN: [email protected] Skype: sholdowa _______________________________________________ NZLUG mailing list [email protected] http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug