> 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? 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? > With dd (or cp or other tools) you can take an exact image snapshot and then > use your cryptography tools of choice [...] to perform independent > verification. [...] With the md5sum of the original drive in hand 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. > With the md5sum of the original drive in hand, you can go into court and > easily argue that the image of that drive with the exact same md5sum is > identical to the drive itself 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. >>> My view is that one should ideally *never* try to carry out a disk imaging >>> in place on a suspect computer. Ideally. The reality is many of us will not be ending up in court, or anywhere else as strict. We have (and accept) lesser goals, different requirements, and limited resources. We're interested in finding out what happened so that we can stop it _now_ and then make sure it doesn't happen again, or at least mitigate the risks. The ideal goals do give us something to work towards and to compare ourselves to, and they help us to determine the costs of the compromises we're taking. >>> I would go equipped with a dedicated clean "imager" PC onto which the >>> suspect drive can be connected. This need be no more than a simple PC with >>> a spare IDE (and possibly a spare SCSI) port and a power cable splitter. 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. 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? -- | Opinions are _mine_, facts Rob Quinn | | are facts. rquinn @ sec.sprint.net | ----------------------------------------------------------------- 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 : Sat Jun 30 2001 - 09:44:10 PDT