[CentOS] what percent of time are there unpatched exploits against default config?

Fri Dec 30 15:58:16 UTC 2011
Lamar Owen <lowen at pari.edu>

On Friday, December 30, 2011 10:24:15 AM Johnny Hughes wrote:
> Agree with this.  At the very least, some kind of image (dd) of the
> original disk for further study even if you have to get the machine back
> on line and you don't have a failover machine.

Speaking of dd, ddrescue in my experience is faster, but even then you will have downtime during the imaging.  For a large drive this can easily take hours; I did a 500GB drive yesterday on my laptop using CentOS 6.2+the EPEL ddrescue package (LiveCD on a USB stick, by the way, with a 1GB overlay) and using a USB 3.0 Western Digital 2.5 inch external; took roughly the same time as eSATA; about 4.5 hours, even over USB 3.0 (the CentOS 6.2 Live media's kernel fully supports my USB 3.0 ExpressCard controller, by the way).

I did this because the laptop's internal hard drive is doing sector reallocations; there are 97 reallocated sectors at this point, which can be a predictor of drive failure, so it was time to image it....  (Les is likely to mention clonezilla at this point.....but my partitioning and use of unallocated space for things precludes clonezille; tried it, didn't work).  CAINE or similar tool would work jsut as well;  but I'd rather set up a CentOS USB stick to do it rather than yet another distribution, even though CAINE has uses beyond just imaging and should be seriously considered for forensics even for die-hard CentOS users; the Fedora-based NST is a close second in my book.  Something like CAINE or NST based on CentOS would be fun..... :-)

Now, SAN snapshotting or VM snappshotting can help reduce downtime (take the snap, start imaging the snap, re-image/re-install to the underlying LUN/volume while the snap is imaging, then blow away the snap once it's imaged; requires lots of space for the snap delta files but the downtime is only the time required to take the snap (extremely quick on SAN, slightly less quick on something like vSphere) plus the time to reimage/reinstall to the underlying LUN/volume).  Even here a large VM can take hours to re-image/re-install.

Better to plan ahead for failover while forensic imaging takes place.