Forensic mode suggestions

[Donuts]

This more a feature request than a tool request, but I figure this is the most appropriate forum.

[First, note that I haven't been able to use BackTrack 4 yet. Feel free to flame me if you already implemented any of these suggestions!]

The current BackTrack forensic mode (not mounting any partitions) should be sufficient for imaging purposes. But several changes could be made to give users more confidence that data won't be altered when partitions are mounted (read-only) for examination/preview purposes.

Take a look at this paper, which has the results of some research into various "forensic" Linux boot CDs:
http://www.denisfrati.it/pdf/Linux_f...estigators.pdf

Following from that, there are several ways in which the forensic mode of Backtrack could be improved, i.e. made "more secure" against accidental writes:

- Configure the kernel (and udev or whatever) to create all device files (/dev/sdX and /dev/sdXn) as read-only. Then the user must explicitly do e.g. "blockdev --setrw /dev/sda1" before being able to mount a partition read/write. It's all too easy to mount a partition, even with the ro option, and have the filesystem write to disk despite that. Not to mention the possibility of forgetting to specify ro when mounting...

- Change default mount options for all filesystems to ro,noatime, and for journalling filesystems (ext3/4, XFS, NTFS, ...) default to mounting without journal replay/recovery.

Unfortunately, the default behaviour when mounting a journalled filesystem ro, is to replay the journal (i.e. write to disk). Different filesystems have different names for their "don't replay the journal" mount option. For ext3/4 it is noload, for XFS norecovery, and for NTFS-3G norecover.

Unless the underlying block device is read-only, you're still trusting the filesystem code not to write to disk, which is not wise given various filesystems' lack of respect for the ro option, and the possibility of bugs. (Witness the recent kernel fix: "ext4: Don't update superblock write time when filesystem is read-only".)

- Modify the KDE desktop environment to mount partitions read-only using the loopback device. In other words, KDE would do something like this when mounting /dev/sda1 (say):
losetup -r /dev/loop1 /dev/sda1
mount -o ro,noatime,noload /media/test

[Question: is doing
mount -o ro,noatime,loop,noload /dev/sda1 /media/test
equivalent to the above two commands; does the ro mount option imply losetup is called with -r?]

Then you would have another layer of security against inadvertent writes: /dev/sda1 will be read-only (if the first suggestion is implemented), /dev/loop1 is read-only, and the read-only mount options. In fact, with that you could safely add another boot option to the Backtrack menu: forensic mode with auto-mounting, or at least easy mounting via the KDE desktop.

Finally, for more security, publish a patch (maybe a simple one-byte change?) to the BT4 ISO which changes the default boot menu option to forensic mode. Users who want to eliminate the possibility of accidentally booting in non-forensic mode could patch the downloaded ISO before writing it to disc. (Example: power cut or crash when user is away from system, system reboots and starts BackTrack in normal mode after menu timeout.)

[YamaArashi]

Dear Donuts you opened a door on a wide world.

I think that creating a forensic distro requires a filosophy that is not the same of a pentest distro.

I do computer forensic all days and also if I think Backtrack is the best Linux distro I've ever seen and also if his field of application is very wide, it lacks very much to be considered a good forensic tool like Helix, Deft etc...

The solution you provide is good but having all disks unmounted by default is boring and I think that modify all this (and the changes that WILL be necessary in the future to remain forensically sound) can go against the "pentest" filosophy and be unuseful for pentest activities.
This because the forensic modifications are always radical and deep, many times involving the kernel and producing sistem-wide side effects.

This is my opinion but maybe a developer can say something more right.

[coffeelove]

You could always do this with the bt4-remaster.sh script located Customize BT4.

[waydaws]

I really think that it is folly to start trying to be a forensic tool, and a pentest tool.

If the community wants to create one (and now that Helix has gone the way of nessus) that would be welcome --but that should be a separate CD completely.

We have to go to court and defend the tools we use.

[Archangel-Amael]

We have to go to court and defend the tools we use.

There is a lot in this thread to quote, but let's look at a few things.
First BT is a Penetration testing distro first and foremost.
Second as was stated by the dev team (Follow link here), BT was tested to ensure that it is "silent" when being used in Forensics mode.
A md5sum snapshot was taken, the live media booted over top of the machine, activities performed and then shut down. Another snapshot was taking showing no changes to the actual system. This means no file systems were mounted and no swap was created on the disk.
But as the final statement, if you are basing your lively hood on this distro for forensics purposes, don't take our word for it. Do your own tests.