PyFlag cannot, however, handle having one disk missing from the RAID. I keep meaning to get into the source and add that but I'm a singularly lazy person.
That is where Encase and RR can handle things.
Thanks for all the tips so far. I have a couple of scenarios that I wouldn't mind some pointers on.
1. We have to copy the NAS device in the office where we find it. We can't remove the device to our place to work on. What's the best way to image it for forensic analysis back at our lab?
2. We've copied the NAS in our lab. We have made dd images of each disc, but now need to search the images for interesting files. Can we just load the images into Encase/FTK for analysis, or do we have to analyse them in case we need to reconstruct the RAID?
Sorry to be asking obvious questions but copying NAS/RAID devices is quite new to us. We have mainly concentrated on single disc PC's and Laptops in the past.
Many thanks,
Mark
1. We have to copy the NAS device in the office where we find it. We can't remove the device to our place to work on. What's the best way to image it for forensic analysis back at our lab?
Tough, I don't know if this is possible. Depends on the NAS device. Back in the early 2000s Dell had some devices run by a stripped down version of Windows 2000/2003. If it is one of those devices, it should have a USB port. Use Helix and do a live acquisition to a USB device. You can also dump to a network device but that might be slower.
If it is a device that is *Nix based, you can log into the console, you should be able to either dump a dd image to a network location or if you have a USB port, dump to there.
If you cannot log into the console, the only method of access is going to be through a shared drive. I am not aware of a way to capture a shared drive to include anything other than allocated files.
2. We've copied the NAS in our lab. We have made dd images of each disc, but now need to search the images for interesting files. Can we just load the images into Encase/FTK for analysis, or do we have to analyse them in case we need to reconstruct the RAID?
I am not sure of FTK's abilities to build RAIDs because I don't use it much, if at all.
Encase should do the trick. Add the images and then go to the Devices tab. Right click and click on Edit Device Configuration. Add the disks in order, specify the starting and ending sectors, RAID type and stripe size. Once it builds the RAID properly, I recommend making an image of that RAID volume, then doing your analysis on the RAID volume as it takes up less resources than analyzing a RAID built in memory.
There are some obscure RAIDs with striping that do not follow the standard striping, as pointed out earlier in this thread. In that case, you will probably have to use one of the tools mentioned to build the RAID before analyzing in Encase or FTK.
What gkelley said. Discovering the configuration and rebuilding by hand is sort of a pain, and using Raid Reconstructor's heuristics can be unreliable.
This is important no matter what, ALWAYS get the following things if you can
1) RAID card manufacturer or software RAID program
2) RAID type
3) Disk order
4) Block size
This will make your life much easier.
AFAIK FTK doesn't do RAID analysis.
Thanks again for the pointers. I am going to ask a couple more things now though…
My company contracts to the Police and sometimes we have to copy data on the premises where we find it. This is due to the warrants not covering the removal of items. Sometimes we don't know any of the RAID parameters. In this case should we use Raid Reconstructor to analyse the DD Images we take before feeding the details into Encase for analysis?
If the NAS has an Ethernet port on it, is there any way of acquiring over a Network? We'll get a license for Helix so we can acquire an image over USB, though I imagine this is time consuming if you're facing a device with 4 x 2TB drives in it!
If time is limited, is there a better way of just pulling off one file type, say all the .doc or .xls files?
Once again, sorry for the annoying questions, but up until recently we've just done single drive PC's (nice and easy to copy with a Talon)
Mark
First, if you are using a boot disk, chances are that you are imaging the RAID volume. What that means is instead of imaging the separate disks, you are imaging the already built RAID. So you don't have to worry about the parameters of the RAID because you won't have to rebuild it. It is only when you image the physical disks that make up the RAID separately that you have to rebuild it.
Second, if you have an Ethernet port, you can acquire it over the network. However, you have to get to the console of the NAS device and have it initiate the imaging. Or be able to get it to run an applet on the NAS device that allows you to use a forensic tool to acquire the NAS device over the network, such as the Encase Network Boot Disk.
If time is limited, you can just pull off a specific file type using RoboCopy, SafeCopy, Titan or countless other apps out there for selective acquisitions. But realize then that your analysis is confined to only what you can grab and if you are grabbing over the network, what you see is confined to what you have the right to see.
Admittedly, I haven't used RAID Reconstructor very much so there may very well be a way to configure it to deal with this but I haven't seen it.
At least twice in this thread you've made negative comments about RAID Reconstructor, most recently that RR's heuristics are unreliable, but you've also said that you've not used in much leading me to suspect that your criticism is unfounded.
When called on your earlier criticism you replied in part with the above quote. I'd really like to see some support for your claim that the heuristics are unreliable.
I'm not in any way associated with the vendor, I'm just a satisfied user of the tool and haven't run into any problems with it at all. Maybe I've not stressed it enough and you've done so, in which case I would clearly benefit from your experiences if you're willing to share them.
-David