At http//
If you image via a network you should be prepared to answer questions on how you ensured the integrity and confidentiality of the image. People tend to use netcat with an encryption program in the pipeline or "cryptcat" on untrusted networks to solve that problem.
I do not recommend netcat at all because I consider the command line syntax inconsistent and I'm missing encryption in netcat. Personally instead of netcat or cryptcat I use socat ( http//
My prefered way of using socat to get images from 'evidence' to 'fileserver' is
fileserver % socat openssl-listen1234 > /imagefiles/evidence.image
evidence % dd if=/dev/hda bs=8192 | socat - opensslfileserver1234
Note that this still does not protect you from anybody using a MiM attack to snoop on or modify the image in transit between 'evidence' and 'fileserver'. To protect against that you need to use OpenSSL certificates which is a somewhat uncomfortable thing.
Note also that the dd is in fact completely superfluous. It has no special magic to "read from a harddisk" A hard disk on Unix is just a file. So every tool which can read from a file has the potential to image a harddisk. You could do something like
evidence % socat -u open/dev/hda opensslfileserver1234
to image over the network. I advice against that since even NIST acts as if dd adds something special to the imaging process (see http//
If you have only the most basic tools at hand and no netcat or socat you also can use ssh to do imaging over the network. Assuming your fileserver is running sshd you can type
evidence % dd if=/dev/hda bs=8192 | ssh MYNAME@fileserver "cat > /imagefiles/evidence.image"
Regards
Max
Nice post, Max. I'm a cryptcat user but I'll certainly be taking a look at socat.
Cheers,
Jamie
While we are on the subject of open source forensics…
This is a great quick and dirty intro to forensics on linux
For those of you not familure with EnCase Enterprise Edition (EEE), it may not be open source, it may not be cheap, but it certainly does the job.
The ability to acquire a system across the WAN without having to deploy personnel around the globe is awesome.
The Incident Response Concurrent Connection (IRCC) provides all the information you could want on a live system to rapidly review if a incidnet has occured. We have detected zero day viruses and initial attacks using the IRCC technology.
Hi Azariah, I am interested in you comment relating to EnCase Enterprise Edition.
The ability to acquire a system across the WAN without having to deploy personnel around the globe is awesome.
It’s not quite what I had in mind - I was thinking more along the lines of imaging across a secure network and not altering the original data in any way. The use of the Enterprise Edition requires the installation of a servelet on the target drive (thus altering the original evidence) - which is ok if monitoring activity on a network, with permission and authority, but when your are trying to make a forensically sound copy (i.e. - not altering it in any way and verified with MD5 hashing) of a seized hard drive - it's a bit awkward.
I have used EEE in the past and agree for forensic network monitoring it’s a fantastic piece of kit; however I would not like to attempt an acquisition of any reasonable sized drive across a WAN, as even with a super fast connection it would an incredible amount of time to complete. For example - I recently tried downloading a version of Linux off the internet with my 1MB connection. It was 1.5GB in size and took 2 attempts and almost 8 hours. Now times that by 100 (for a 150 GB HDD). It only takes a dodgy connection and it fails….. a nightmare prospect when its an important investigation. My understanding of its best use is to use it to identify a suspect machine – then isolate it, then image it locally.
I actually took my time trial version of EEE home and used it on my wireless network (11 MB). I managed to examine/preview my other machines on my home LAN. However they took ages to mount and I noticed a quite bit of lag. I imagine I could have grown a beard waiting for an acquisition. 🙂
What experiences have you had with bandwidth and benchmarking such acquisitions?
Andy
I predominantly image across networks, rather than direct disk to disk imaging.
Typically I will obtain speeds between 700mb / min and 1GB / min.
Someone raised the question earlier in the post regarding how you can ensure the integrity and confidentiality of the image. Their suggested solution was to use socat - and that's fine, too, it works. However, instead of encryption, why not just use the md5 hash that you are calculating anyway?
My process is to pipe dcfldd into nc at the source, and nc into dcfldd at the destination, recording the md5 from both. If they match, there is your integrity. And as far as confidentiality is concerned, configure your IP's in a closed subnet, so no hosts can snoop.
The reason why I use this so much more than disk to disk is because around 80% of my work is imaging servers with RAID arrays, and typically I won't have an IDE port available. Using the network is so much easier than having to stuff around with the actual hardware.
Cheers,
Blare Sutton
PPB Forensics
Blare,
Welcome to Forensic Focus.
Kind regards,
Jamie