On Fri, Jun 29, 2001 at 02:32:41PM -0400, Rob Quinn wrote: > > There is definitely a major screw loose here somewhere. From what I've seen, > > the OS is largely irrelevant and md5sum and dd are parmontly defensible > > BECAUSE of their simplicity. > > ...Linux, FreeBSD and OpenBSD... > Funny you should mention OpenBSD and FreeBSD. Don't they (and Solaris, and > NetBSD) have disklabels? Which the OS will auto-generate for you if missing? Yes, they do have disklabels on disks containing *BSD-filesystems, no they will not automatically superimpose these on foreign disks, at least the *BSDs will not. You are confusing the creation of a *BSD-native filesystem with just reading raw data on a disk. Besides, verifying the path from disk to dd is not that hard, the ATA/SCSI-code is small and straightforward and the datablocks are moved to dd unchanged. This is well understood, stable and timeproven code. > Which are different from, and don't have to agree with, the partition table > most i386 Windows people are familiar with? For which large sections of the > install FAQ's are devoted because so many people get them wrong? This is the _creation_ of disklabels, not _reading_ a raw disk. > Your md5 checksum will only prove that the OS sees the new copy in the same > way the OS sees the original. The issue is that you don't know that dd is > seeing the original accurately and completely. I don't know about Linux, but > for the other OSs mentioned, when you image the "entire disk" you're just > imaging the disk as it's defined in the disklabel. You're using data on the > disk to interpret the disk. No. You are reading the whole disk, sector for sector, as advertised by the disk itself. Modulo differences in addressing (LBA et al), this is exactly what any other system, including the original host, can and will see. The addressing issues need to be adressed in the same way for any other system, regardless of the OS you are using, if you want to _interpret_ the data. This is just a reordening of data. > No, dd md5's only prove that the image of the drive now is the same image you > saw when you looked at the original drive. That doesn't prove you saw > everything on the original drive. Your glasses were rose colored then, and > they still are. Correct. The completeness is provided by dd+raw-device. By the way, completeness may become more difficult with the newer generation ATA drives that (will?) have commands for limiting the addressable data with options of password protecting them. Detecting these limits is possible (the drive advertises them), but circumventing them is not that obvious. > The subject "drive" is several dozen large SCSI drives in a hardware > array. The array driver isn't on the stock OS boot disk or your > incident analysis boot CD. SCSI-RAID arrays present themselves to the connecting host systems as just one very large disk device for purposes of reading and writing, only the specific commands for things like disable disk and give RAID status are non-standard (and even these are standardised now). So there should problem whatsoever in accessing these drives from a *BSD system. > Every hour of downtime has a well documented dollar figure attached to > it. Your primary business objective (and paycheck) is based on your > company making money, not prosecuting criminals. Do you settle for a > copy of last night's full dump? This is not a technology question, this is a cost/benefit analysis. With kind regards, Wouter Slegers ----------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Sun Jul 01 2001 - 14:22:41 PDT