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