Imaging a live syst...
 
Notifications
Clear all

Imaging a live system

10 Posts
6 Users
0 Likes
1,934 Views
turtlecove
(@turtlecove)
Posts: 34
Eminent Member
Topic starter
 

Does anyone have recommendations on imaging a live system without bringing it down?

In this particular instance I am imaging the system to hand over all data to the opposing side in a company's legal dispute between owners. There is NO suspicion of any viruses or trojans so I do not need to image any 'volatile' data (such as running processes, open ports, etc). But to minimize disruption to the business they would like me to do the imaging without bringing down the servers.

I am thinking to use a Windows executable version of 'dd' and 'netcat' such as those found at http://users.erols.com/gmgarner/forensics/ and run them directly off a floppy or CD. I can netcat the drive image across the network to my forensic portable.

However, I am concerned with the quality of the image because the system will be updating the drive as I copy, in effect a moving target. Instead of a 'snapshot' of the drive I will get a 'smearshot' of the data.

I could solve this problem on Solaris or Linux by using the 'snapfs' snapshot filesystem that will present me with a "frozen" image of the drive even while the drive is active. But with Windows NT/XP that isn't available.

There is the unspoken implication that they do want the deleted file space as well, so it isn't a great idea for me to be installing software either (although the system is a live server that has been running for months after the dispute began so any data in deleted file space is in jeopardy anyway).

 
Posted : 24/11/2004 7:45 pm
 Andy
(@andy)
Posts: 357
Reputable Member
 

To image a live system is extremely difficult, and whatever method you adopt will take an age to complete and possibly cause the target system to lag and disrupt the business in any case. You are right … It will be a moving target (a fast one too). What size is the data store? (the word server conjures up terabytes of data in my mind). Can you not do a complete backup of the system to some other media, tape for example? Or attach some large capacity removable data store to it and simply copy off all the data.

In some cases it is not always possible to make a completely forensically sound copy of the media, but as long as you document the reasons…

Andy

 
Posted : 28/11/2004 10:26 am
(@steve)
Posts: 10
Active Member
 

I have to agree with Andy on this one. After normal business hours or even over the weekend if needed. That is, unless, the client is willing to pay for the Encase solution. 😯

 
Posted : 30/11/2004 4:56 am
turtlecove
(@turtlecove)
Posts: 34
Eminent Member
Topic starter
 

I have just discovered a little known service in WIndows XP and Windows Server 2003 called "Volume Shadow Copy". This does the same thing as Unix SnapFS. It allows one to "freeze" an entire filesystem for backing up while the system is still running uninterrupted. It does this by keeping a copy of any data that changes during the process. Applications running on the system see the changed data. The backup application sees the unchanged data. After the backup is done, the unchanged data is no longer needed.

I am going to try to see if I can use this service to initiate a Snapshot (A Volume Shadow Copy) and then do a 'dd' image from the snapshot filesystem. This would allow me to make a true image of a filesystem while it is still running.

I'll report my progress back here…

 
Posted : 02/12/2004 3:51 am
(@gmarshall139)
Posts: 378
Reputable Member
 

Sounds interesting, I look forward to your report. Do you think it will allow you to capture the unallocated space as well? Let us know how it goes.

 
Posted : 02/12/2004 1:21 pm
 Andy
(@andy)
Posts: 357
Reputable Member
 

Yeah this does sound promising, please keep us updated.

Andy

 
Posted : 02/12/2004 2:40 pm
turtlecove
(@turtlecove)
Posts: 34
Eminent Member
Topic starter
 

Just a quick followup- it does appear that 'Volume Shadow Copy' will allow you to make a perfect snapshot image of a Windows filesystem while it is active… However in order to do that 'Volume Shadow Copy' will need to actively write data on another filesystem. So if you are imaging one drive or partition and have another available you don't care about overwriting this is perfect. But in the more usual case of imaging all drives this will not help, since it needs space to write on.
I will next attempt to direct 'Volume Shadow Copy' to use an attached FireWire or USB drive as it's write space in order to NOT touch the onboard drives.

 
Posted : 14/12/2004 9:58 pm
taylormade
(@taylormade)
Posts: 12
Active Member
 

I know I'm a couple of weeks behind the curve here, but there is one thing about this topic that has been bothering me:
What exactly is the problem?

There is nothing in the imaging process that says the data HAS to be static to copy it.

"volume shadow copy" or snapfs will lock the file system and write changes to another volume. But then what do you do as soon as you are done imaging? When you turn that feature off all the changes from the other volume will be written to drive you just imaged, right? So, what is the gain?

Is the problem that you want to prevent changes to the system by the imaging software? YOU've modified the system in order to lock the file system. A defense attorney could ask what other changes you made prior to collecting the evidence? It's a slippery road you don't want to go down.

Is the problem that the drive cannot be hashed before and after acquisition to verify integrity? Using EEE, dcfldd, or Garner's dd an acquisition MD5 hash can be obtained DURING the imaging process. This hash will not match an MD5 of the drive from 5 minutes prior to the imaging nor will it match a hash from after the imaging is complete. But it is the hash of the data as it was when it was copied and it will match the output file.

Even if a hash cannot be obtained, the image is still viable under the rules of "best evidence". As long as the methodology is sound, documented, and you understand in detail what you did, it will stand up.

Is the problem that a file may be being modified at the same time the imaging software is trying to copy it? That is a problem for the drive and file system's I/O routines. The OS opens and locks file according to file name; the imaging software copies by block and not by file name. There won't be a conflict.

I have imaged several "mission critical" servers while they were live. And imaged countless test servers in my lab getting ready for those jobs. I got a clean image every time. Even with dozens of users connected and a backup running while I was imaging, I got a clean image from sector 0 all the way through partition slack.

The best solution is always to image the drive using your own OS and hardware write-blockers, but that is not the only solution.

You can push the image across a network:
-use EEE and follow it's instructions.
-use dd | nc to nc listening on your forensic system
-use dd and for the of= specify a network share on your forensic system that you setup to be universally writeable

You can image locally:
-use a 400GB USB or firewire drive, if the server's data will fit on it (don't forget about compression!)
-use the backup hardware that is already attached to the server (tape, cd, etc)

It's never fun. It's never ideal. But a live system can be directly imaged without any adverse effects to it's file system or the image.

I apologize for the dissertation… I was only planning on writing a paragraph, but I get carried away easily 😉

 
Posted : 03/01/2005 11:36 pm
(@Anonymous)
Posts: 0
Guest
 

well,

i have not run into having to do this myself but i can tell you that i wouldn't rely on any dlt backup as you don't get unallocated space and with most backup software suites such as arc serve if there are any files open (such as oracle databases) they are usually either skipped or not intact (usually.)

Does anyone have recommendations on imaging a live system without bringing it down?

In this particular instance I am imaging the system to hand over all data to the opposing side in a company's legal dispute between owners. There is NO suspicion of any viruses or trojans so I do not need to image any 'volatile' data (such as running processes, open ports, etc). But to minimize disruption to the business they would like me to do the imaging without bringing down the servers.

I am thinking to use a Windows executable version of 'dd' and 'netcat' such as those found at http://users.erols.com/gmgarner/forensics/ and run them directly off a floppy or CD. I can netcat the drive image across the network to my forensic portable.

However, I am concerned with the quality of the image because the system will be updating the drive as I copy, in effect a moving target. Instead of a 'snapshot' of the drive I will get a 'smearshot' of the data.

I could solve this problem on Solaris or Linux by using the 'snapfs' snapshot filesystem that will present me with a "frozen" image of the drive even while the drive is active. But with Windows NT/XP that isn't available.

There is the unspoken implication that they do want the deleted file space as well, so it isn't a great idea for me to be installing software either (although the system is a live server that has been running for months after the dispute began so any data in deleted file space is in jeopardy anyway).

 
Posted : 23/01/2005 1:56 am
turtlecove
(@turtlecove)
Posts: 34
Eminent Member
Topic starter
 

Taylormade, the issue is that when making an image you may grab blocks belonging to a file just as the operating system is making changes to the file. Therefore you may, for example, get a directory header pointing to a file that isn't there anymore, or a file with a data structure that is corrupted. Eg: You could get the first block of an XLS file with data important to your case and find that the second block doesn't "match" the first block because the file was being written to as you imaged it. The file may be unreadable.

Normally, the Operating System handles all locking issues to the file system never gets corrupted, but when imaging block by block you are ignoring the Operating System.

 
Posted : 24/01/2005 3:01 pm
Share: