A typical scenario for creating a bit-image of a running server is an incident response situation where a critical server may or may not have been compromised or otherwise tampered with and needs to be thoroughly examined, but a server shutdown procedure cannot be justified. For the purposes of this technical tip, we’ll assume a simple single-disk Windows server.
One of the most important questions when imaging a server is where to put the image. You can’t save it to the drive you’re copying. Two good options are a USB drive or over the network. We’ll explain copying it over the network.
All you need to create this disk image and copy it over the network to another computer is a Windows version of the common GNU/Linux tools DD and netcat, which are both free and open source. DD creates the bit-image disk copy and netcat will send anything over the network. Of course, you’ll need the second computer on the network that will receive the image and has enough capacity for the image. You’ll want to put these two tools on safe media — preferably a CD. This way they are known to be “good” and won’t be compromised when used on a compromised system.
More incident response resources
How should a company’s security program define roles and responsibilities: Follow this implementation plan for your security program in order to help you define incident response roles.
Acceptable use policy for Internet usage helps data protection efforts: Acceptable use policies are an inexpensive, yet effective, control in limiting exposure to data breaches.
DD creates the copy by reading each raw disk cluster, starting at the first on the disk and continuing to the end. On a running computer the drive is often changed, depending on how active the server is, so there may be changes made to the disk after DD has already copied that segment.
For DD we’ll use DCFLDD — this version of DD was created by the U.S. Department of Defense Computer Forensics Lab. It is functionally identical to the normal version of DD but has added capabilities relating to hashing the data it copies. The hash creates a signature that allows us to validate the output is the same as the input (the original disk). Since we’re imaging a live server the disk is always changing — this means a second image will not have a hash that matches the first image.
DCFLDD is a fairly simple tool to use and its documentation can be found at the projects homepage at sourceforge.net. The parameter “if=” is used to specify the input, typically the drive or drive partition you are imaging. Determining the correct name for your input device can be a little tricky — the cygwin documentation will explain it in-depth. The quick version is that “/dev/sda” refers to the first hard drive, “/dev/sdb” the second drive, “/dev/sdc” the third drive, and so on. Some other builds of DD, that do not support hashing, provide a “–list” command to enumerate the drives on the system for you, which is quite handy. You can use DD to copy an image to a physical drive by using an image file for if and a physical device as of.
dcfldd if=/dev/sdc hash=sha256 hashwindow=512M sha256=mydrivehashes.log / bs=512 conv=noerror split=2G of=mydrive.dd
1 – DCFLDD Example
This example of DCFLDD will:
Copy the third hard drive (/dev/sdc) to the file mydrive.dd.
Use SHA256 to hash the drive contents in 512 Mb segments.
Record the hashes to “mydrivehashes.log.”
Split the file into 2GB files.
Skip over read errors rather than stopping (conv=noerror).
I’ve now shown how to create a disk image, but only to a local file on the system. That’s not helpful when there is no spare physical media present. This is where we use netcat, nc.exe, to redirect the output of DCFLDD over a network connection. This copy will not be encrypted so if the server image contains sensitive material it could be intercepted by anyone who is monitoring your network. When the output (of=) is omitted DCFLDD will copy to standard output. That means you can redirect to another tool, such as netcat. Netcat for Windows can be found online. First, on the destination server, launch netcat as a listener and redirect that to a file. I’ll have netcat listen on TCP port 3333 and write the image file to myimage.dd.
nc.exe –l –p 3333 > myimage.dd
Next, you can image the server (10.1.1.1) and send the image (via insecure cleartext) to that destination server by directing the output to netcat, through standard out, by not specifying the output file (of).
dcfldd if=/dev/sdc hash=sha256 hashwindow=512M sha256=mydrivehashes.log / bs=512 conv=noerror split=2G | nc 10.1.1.1 3333
If you do need to do this, and it’s for an incident response effort, make sure and document exactly what you do and at what time. This is critical if the resulting evidence is ever going to be used in court. If you don’t need this for incident response purposes, and don’t need the hash record, then a different version of DD, one supporting –list to enumerate your drives, might be a better choice.
Tom Chmielarski is a senior consultant with GlassHouse Technologies, Inc.
This was first published in September 2009
By: T Chmielarski