Join Us!

Making Linux Forens...
 
Notifications
Clear all

Making Linux Forensically Sound  

  RSS
minime2k9
(@minime2k9)
Active Member

So there is a lot of information on how to create your own Linux distribution and a lot of 'forensic' Linux distributions, however I have been unable to find much information on how they actually achieve this, definitely no enough to create your own forensic distribution.
With the exception of a kernel patch or two I can't really find much on the techniques used and what they are actually doing.
Has anyone got any sources of information on this area?

Quote
Posted : 09/07/2018 11:25 am
jaclaz
(@jaclaz)
Community Legend

So there is a lot of information on how to create your own Linux distribution and a lot of 'forensic' Linux distributions, however I have been unable to find much information on how they actually achieve this, definitely no enough to create your own forensic distribution.
With the exception of a kernel patch or two I can't really find much on the techniques used and what they are actually doing.
Has anyone got any sources of information on this area?

With all due respect ) (and not to put you down in any way) are you really sure that there is a need for (yet another) Linux Forensic distro?

Or would it be easier/better to take an existing, already maintained one such as (examples) Caine
https://www.caine-live.net/
or Deft
http//www.deftlinux.net/

and verify/validate them (possibly giving feedback to the maintainers in case of issues)?

AFAICT both the examples above just work, the only thing that may (or may not) be needed is the patch by thefuf
https://www.forensicfocus.com/Forums/viewtopic/t=16195/

More or less (and AFAIK) all of these have simply boot-time automount disabled and easy provisions to mount read only the disks/filesystems, besides a number of useful programs pre-configured.

If you want to start from (almost) scratch, maybe you can start from the mentioned very minimal OSforensics distro (intended to only create mages) and build upon it
https://www.osforensics.com/tools/create-disk-images.html

jaclaz

ReplyQuote
Posted : 09/07/2018 11:47 am
minime2k9
(@minime2k9)
Active Member

Jaclaz,

I would love to, except we have the following issues
We need to install the distribution on a machine
and have write persistence (so cant put ISO on disk and boot)
and work on an m2 SSD.
So Deft hasn't been updated in so many years it is on kernel 3.x rather than 4 so doesn't support M2 or thunderbolt.
CAINE allows you to use M2 and install (i think) but if you install on a m2 there is no way to un-writeblock your system drive and keep persistence.
Having email DEFT several times (my preferred distribution), they still haven't released DEFT X which was supposed to be out in November/maybe earlier.
Much as I realize that it is a total pain and possibly un-necessary, at least we will be able to update as and when features come out - the system is only really used for imaging.

ReplyQuote
Posted : 09/07/2018 1:31 pm
jaclaz
(@jaclaz)
Community Legend

CAINE allows you to use M2 and install (i think) but if you install on a m2 there is no way to un-writeblock your system drive and keep persistence.

You sure? (there must be *some* ways).

I have just checked and the "persistent" installation instructions via Systemback seem to refer to the old version 6.0, but maybe the same is possible on newer versions using if not the same a similar approach? ?

jaclaz

ReplyQuote
Posted : 09/07/2018 2:04 pm
minime2k9
(@minime2k9)
Active Member

Unless I'm missing something. There is a utility to un-block devices, however it won't 'see' the M2 SSD.
I might be able to replicate the command line equivalent and pass the correct block device.

ReplyQuote
Posted : 09/07/2018 2:12 pm
thefuf
(@thefuf)
Active Member

We need to install the distribution on a machine
and have write persistence (so cant put ISO on disk and boot)

There is no one-size-fits-all solution to achieve this. In general, you need to do the following
1. Patch a kernel to include the software write blocking. Otherwise, you won't be able to mount a file system read-only (the -o ro argument for the mount command doesn't disable writes completely, the blockdev –setro <device> and hdparm -r1 <device> commands don't work as expected without such a patch).
2. Put a set of userspace scripts and an udev rule to mark all block devices as read-only when they are attached.
3. Disable anything that will automount a file system on a suspect drive (typically, this is managed by code in an initramfs, and/or in init scripts, and/or in an udev rule, and/or in a configuration tool for your desktop environment; all of these locations must be checked).
4. Disable anything that will autoactivate LVM volumes on a suspect drive (typically, this is managed by an udev rule and/or in an initramfs).
5. Disable anything that will autoactivate software RAID volumes on a suspect drive (typically, this is managed by an udev rule and/or in an initramfs).
6. Disable anything that will autoactivate swap partitions on a suspect drive (typically, this is managed by code in an initramfs, and/or in init scripts, and/or in an udev rule).
7. Ensure that booting your system with a suspect drive attached will never run untrusted code from that drive (check the value of the "root=" boot option to see if it contains a non-unique value like a file system label, it should contain an UUID of your root file system).

ReplyQuote
Posted : 09/07/2018 2:35 pm
thefuf
(@thefuf)
Active Member

a lot of 'forensic' Linux distributions

There are data modification and code execution issues with many of them Kali, CAINE, PALADIN, etc.

ReplyQuote
Posted : 09/07/2018 2:37 pm
minime2k9
(@minime2k9)
Active Member

Thanks, I'll start looking into those areas.

ReplyQuote
Posted : 09/07/2018 2:47 pm
jaclaz
(@jaclaz)
Community Legend

There are data modification and code execution issues with many of them Kali, CAINE, PALADIN, etc.

And - as suggested before - finding and listing the specific issues of a distro and letting the maintainers know about them (possibly even proposing the needed modifications/patches/whatever) would IMHO more useful than either generically stating that they are all not good or starting (yet another) distro.

Specifically, Caine seemingly adopted one of your patches in version 8 or 9
https://www.caine-live.net/page8/page8.html

Applying a special patch (Maxim Suhanov's patch) we fixed the bug, that changed the journal of the ext3/ext4 file system, when the computer was switch off not using the shutdown procedure.

if there is something else "missing" or "wrong" maybe you could point it out to Nanni.

jaclaz

ReplyQuote
Posted : 09/07/2018 3:35 pm
MDCR
 MDCR
(@mdcr)
Active Member

What i remember is that there was lots of discussion going on about mount scripts and booting up on a forensics system.

My main gripe with such distros is that they typically flood the user with tools (even pentest tools, seriously w*f?) that you should never run from the DVD/USB stick anyway against a live system, a forensics distro should be about disk/memory/network acquisition and nothing else to keep the focus clear.

Tools for analysts should be kept far, far away on another distro.

ReplyQuote
Posted : 09/07/2018 4:27 pm
Share: