Helix - Forensically sound ?

If no file systems are mounted or if file systems are mounted read only, why do you believe you need to set the physical drive to read only? (BTW, testing is always fantastic - you may find that using blkdev to set a drive read only actually fails to work though it may appear otherwise)

Excellent question
That's a good point about needing to test how good blockdev's write blocking is.
Will have to try that. From the testing I have done so far it seems pretty rock solid.

Setting the physical drive to RO adds another layer of security, blocking any writes.
If by default all devices are RO , no matter what u mount the files systems are they will be write blocked.

So you can't accidentally mount an evidence RW unless you first remove the blockdev RO.
Also stops you accidentally damaging anything with dd.
Means when I do a drive to drive dd , i make sure the src drive is set to RO using blockdev.

Gives me more confidence that evidence can't be accidentally altered.
I was quite happy with most linux live CD's before I discovered ones using blockdev to set all HDD's to RO.
Now i want the extra protection.

Heard that there was discovered a bug with XFS in kernel 2.6.28.
sounds like it would still write to the HDD even if mounted RO.
http//oss.sgi.com/pipermail/xfs/2009-July/041963.html
Forensic Linux live CD's may be susceptible to that bug.

So if the block devices are set to RO early enough it will protect against that sort of thing happening also.

Farmerdude,

Is there a difference in the operation of blockdev and hdparm? (I mean in the result, not the method.)

I've always used hdparm to change the whole drive (/dev/sda or /dev/hda) to RO, or to unlock it once it has been locked by the live CD that I use (SPADA, limited availability distro for LEOs and IACIS members). I've done testing and not been able to write to the disk once hdparm has locked it.

Heard that there was discovered a bug with XFS in kernel 2.6.28.
sounds like it would still write to the HDD even if mounted RO.
http//oss.sgi.com/pipermail/xfs/2009-July/041963.html
Forensic Linux live CD's may be susceptible to that bug.

There are similar bugs with ext3/ext4 (however, developers are not going to fix them)

EXT3-fs INFO recovery required on readonly filesystem.
EXT3-fs write access will be enabled during recovery.
kjournald starting. Commit interval 5 seconds
EXT3-fs recovery complete.
EXT3-fs mounted filesystem with ordered data mode.

I know 3 ways to workaround fake read-only mounts disable journal (e.g. norecovery option on XFS), mount the filesystem using -o ro,loop options (will create read-only loop device and mount it) and use blockdev to set the device read-only. Any other ideas?

I'm curious as to how you've tested 'blockdev'?

What results have you seen with USB attached storage devices?

What results have you seen with non-512 byte discs?

Cheers!

farmerdude

www.onlineforensictraining.com

www.forensicbootcd.com

As a quiet note … incrementing the journal count when a journaled file system is mounted read-only is not a bug. It is a purposeful design feature.

And incrementing a journal count should not translate into exclusion of evidence.

Cheers!

farmerdude

www.onlineforensictraining.com

www.forensicbootcd.com

I'm curious as to how you've tested 'blockdev'?

Booted GRML linux live Cd , made sure to select "forensic" on bootup.
<caution very important as this disk as not in forensic mode by default>
I see on bootup it sets all blockdevices including "all partitions" to RO

If I want to write to a device I need to manually set the device to RW.

usual testing
1. md5 device
2. try to alter device by dd or mounting.
- unable to make any changes
3. md5 device again to see if i have made any changes.
4. set device to rw
eg
blockdev –setrw /dev/sdb
blockdev –setrw /dev/sdb1
5. test to see i can now write to it. Confirm that I can change from RO to RW.

Warning
You need to also run blockdev/hdparm for all partitions on the device that u need to set to RO or RW
Just setting the device eg /dev/sdb to RO doesn't mean the partition /dev/sdb1 is set to RO also because It isn't.
(this is valid for hdparm and also for blockdev)

Now if I add any devices to this system after the boot ,they will not be automatically set to RO as that only happens on startup. but as the CD doesn't automount added hardware, you can then set them to RO yourself.

So need to boot the CD with all drives attached that u want to image for maximum protection. (using GRML)

What results have you seen with USB attached storage devices?

Same as SCSI / IDE or SATA
Protection seems fairly solid. just need to make sure all partitions are also set to RO

Just using the GRML boot disk u want to have them plugged in on bootup to have them set to RO as it doesn't set hotplugged disks to RO automatically.

What results have you seen with non-512 byte discs?

Do you mean as per this linked article ?

http//www.computerworld.com/s/article/109971/New_disk_sector_size_to_shake_up_drive_capacity

No difference the behaviour is the same.
I guess the RO/RW code is running at a higher lever and doesn't care about the sector size.

run "blockdev –getbsz /dev/sdX" to get block size
run "blockdev –getss /dev/sdX" to get sector size
USB drives and new HDD's give me 4096 for block size.
USB drives and All HDD's (SATA & SCSI) give me 512 for sector size.
CD drives give me 2048 for block size and sector size.

Further testing will be useful as I only tested a few drives of each type.

Question

I don't seem to see any difference in behaviour between hdparm or blockdev in setting drives/partitions to RO/RW , the syntax is different but the behaviour is identical.

Is there a difference ???

To find any difference between blockdev and hdparm you can 'strace' the executable and parse the output.

With respect to sector size testing I am referring to fibre channel hard drives and their non-512 byte size.

Cheers!

farmerdude

www.onlineforensictraining.com

www.forensicbootcd.com

Hi all,

for all that are interested in grml-stuff

In two weeks Mika Prokop and I will talk about the grml at the IMF 2009 - 5th International Conference on
IT Security Incident Management & IT Forensics on 09-09-17 1400.

There will be a special grml-forensic soon with all the forensic stuff enabled at boot.

If you want to contribute, report wishes or bugs, please have a look at our mailing list http//ml.grml.org/mailman/listinfo/grml-forensic that is german / english.

As soon grml-forensic is released I'll post an extra topic.

Cheers,

Ralf

Hi,

the slides are now online

http//grml.org/slides/grml-forensic_imf09.pdf

Including a practical part showing how to use iSCSI to remote access a hardisk writeblocked and boot in it on the remote windows-pc via Liveview & VMware )

In the slides there's only the iscsi-config.

Regards,

Ralf Moll

Ralf,

In your presentation on Slide 13 you state

"Most forensic systems are "hacks"" .

You didn't elaborate nor cite any forensic systems that are hacks. Can you elaborate which forensic systems are hacks that you and your partners are referring to?

Cheers!

farmerdude

www.onlineforensictraining.com

www.forensicbootcd.com