Honeypots are the good reason for having Overlay Filesystems as well. You could use a CD, optical drive, or even (if you can find them) seagate's write protecting Hard Drives. Then Overlay the filesystem, with a writeable filesystem. On 26 Jun 2001, at 13:39, Michael H. Warfield wrote: Date sent: Tue, 26 Jun 2001 13:39:13 -0400 From: "Michael H. Warfield" <mhwat_private> To: dave.goldsmithat_private Copies to: mhwat_private, forensicsat_private Subject: Re: Where are greater risks? > On Tue, Jun 26, 2001 at 11:42:44AM -0400, dave.goldsmithat_private wrote: > > When you use the dd command to copy the source disk, does the destination > disk > need to be the same size/geometry or just as large or larger. > > > If it is larger, how do the MD5 checksums end up being the same? Wouldn't > > there be additional data bits (in the remaining space) that would cause the > > hash to change? > > What I would generally do is dd from a raw disk to a disk image on > a target file system. That allows me easier access for post recovery > analysis. > > This is also how I rapidly rebuild my honey pots. I have a CD > with the BBC as a front end and my disk partitions as compressed files > as payloads on the rest of the CD. I boot the target system from the > CD and restore the entire drive by gunziping the images into dd and > onto the raw drive. It's bit for bit identical to when I made the > images. It don't get much better than that. > > If I wanted, for some reason, to dd to another raw disk, I > would have to make sure the geometry was the same (or the partition tables > would not work) and that the drive was as large or larger than the source > drive. To match the md5 sums with a large target drive, you would then > have to use dd to extract the correct number of blocks (determined by > the block count when the original dd was finished) and pipe it to stdout > and from there to stdin on md5sum. > > > Dave Goldsmith > > > > -----Original Message----- > > From: Michael H. Warfield [mailto:mhwat_private] > > Sent: Monday, June 25, 2001 5:18 PM > > To: mail@computer-security-awareness.co.uk > > Cc: svetlikat_private; forensicsat_private > > Subject: Re: Where are greater risks? > > > > > > On Mon, Jun 25, 2001 at 04:04:45PM +0100, Michael D. Barwise, BSc, IEng, > > MIIE wrote: > > > My ideal disk copier would be a very basic PC, probably one of those > > > compact industrial single-board ones, with a truly blank target disk and a > > > > > spare port, running nothing except a custom-written native application which > > > does nothing except read literal sectors from one hard disk to another (no > > > OS). This application would be booted from floppy disk to > > start > > > the copy process. The required code, if written in assembler, would be so > > > small that it *could* be verified and certified by anyone competent to > > read > > > the source code. > > > > > The reason we don't use disk imaging software is probably that we don't know > > > and can't find out what it is doing in detail (that's proprietary > > > information). Many disk imagers compress their archives in an unspecified > > > manner, and many use file-level copying, which both alters the layout of > > the > > > copy and omits free and deleted space, losing a useful source of evidence. > > > > Boot the system from a Linux "Bootable Business Card" CD and > > use the "dd" application to copy between the raw devices (root device > > like /dev/hda or /dev/sda, not partitions like /dev/hda[1234567]). It > > doesn't get much more basic than that unless you want to do magnetic domain > > analysis or include the low level drive sync patterns (I think not). When > > done, use md5 on both the source and the destination to verify. Since it's > > all open source, you've got the sources to audit and verfy to your heart's > > content. Since it's done on the raw devices, all the deleted space, trailing > > space, sparce files, and inter-partition gaps and tables are all preserved bit > > for bit. If they weren't your md5 sums would fail. > > > > > Mike Barwise > > > Computer Security Awareness > > > > > "Addressing the Human Equation in Information Security" > > > > > > > > >Thanks Marian > > > > > > > > > >At last someone is asking the right questions. > > > > > > > > > >My view is that one should ideally *never* try to carry out a disk > > > > >imaging > > > > in > > > > >place on a suspect computer. > > > > > > > > Yes, you are right, but you know it is not possible in many cases. > > > > > > > > >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. As it would never be used for anything > > > > other > > > > >than imaging, it could be kept clean and certified. > > > > > > > > This is the right place for the next "right" question: > > > > > > > > What is the "clean and certified" computer? > > > > > > > > Computer is allways "sophistical" machine and each program, driver, > > > > system,... > > > > must be cerified to clearly state that all computer is cerified. > > > > Certification in forensic science is not only technical, > > > > but the juridical proces. I have some (not pleasant) experience with > > > > certification ;-( > > > > The best way for success cetification (no matter what certificaction > > > > criteria you have) > > > > is to certificate as simple device as possible. For this reason I have > > > > next (may be) "right" question: > > > > > > > > Why a HW disk imaging tools (HW disk duplicators) are not used? > > > > > > > > They have all advantages (except price ;-). > > > > Simplicity, speed, safety, electronic signature, they need not so high > > > > qualify oeration and handling... > > > > > > > > > > > > > >Michael D. Barwise, BSc, IEng, MIIE > > > > >Computer Security Awareness > > > > >tel +44 (0)1442 266534 > > > > >http://www.ComputerSecurityAwareness.com > > > > > > > > > >Addressing the Human Equation in Information Security > > > > > > > > ____________________________________ > > > > Marian Svetlik > > > > Principal Consultant > > > > > > > > Risk Analysis Consultants > > > > Narodni 9, 110 00 Praha 1 > > > > Czech Republic > > > > > > > > Tel.: +420 2 220 75 352 Fax: +420 2 242 28 273 > > > > mail: svetlikat_private http://www.rac.cz > > > > > > > -- > > Michael H. Warfield | (770) 985-6132 | mhwat_private > > (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ > > NIC whois: MHW9 | An optimist believes we live in the best of all > > PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! > > -- > Michael H. Warfield | (770) 985-6132 | mhwat_private > (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC > whois: MHW9 | An optimist believes we live in the best of all > PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! > > > ----------------------------------------------------------------- > > 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 > > > --- Jason Robertson Network Analyst jasonat_private http://www.astroadvice.com ----------------------------------------------------------------- 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 : Wed Jun 27 2001 - 11:56:19 PDT