Forensicating with Interconnected VMs Part 3 - Directing Traffic

Directing Traffic

I was BSing with Mr. Rosen over some pizza a couple months back.  I described the scheme I'm about to lay out and how it was borne from my (ir)rational paranoia about The Cloud.  I told him that I had set up my system this way "because I'm paranoid that someone's going to hack in and mess up my shit." to which he replied something like, "I'd be less afraid of the that, and more afraid that I'm going to do something stupid."  Touché.  Perhaps the biggest threat to our data isn't the anonymous blob outside our network.  Maybe our data is more likely to be corrupted by the ijit sitting at the keyboard.

Whatever the motivation, I believe it's good practice to limit my evidence's exposure to the outside world.  However, to make our lives easy, some data flow is required.  In true blogger fashion, let me confuse you with a diagram before properly explaining it:

Network Traffic Flow

In this diagram, you see that the Acquisition & RAID computer has two shared folders.

The Evidence (RW) is an rw share used for dumping case data, extracted files, logs, and other data created on the Analysis machine.  It is a temporary directory - more on that later.

The Disc Images (RO) folder is a read-only share.  It contains the disc images created during acquisition that are stored on the RAID.

Over on the Analysis machine, I named two hard drives RW and RO, to follow the nomenclature used on the Acquisition computer.  Remember how I said that the Analysis computer itself doesn't do any actual analysis?  Here's why.  Each drive is fully-available to the Host OS; however, each drive is shared with the VM Clients as either read-only or read-write.  Hopefully you're seeing a pattern here.

The LAPTOP-looking icons are Virtual Machines hosted on the Analysis PC

The pattern is that each Virtual Machine has the exact same setup as the Analysis machine.  They all believe they are connecting to a Server with read-only or read-write shares.  Of course, in the case of the Virtual Machines, the network is pretend, meaning the usual bottlenecks of LAN traffic don't exist.

Simplified Workflow

This may seem overly complicated, but it's mind-numbingly simple to put together.  For me, it makes my casework organization easy.  Once it's all set up, you'll have the equivalent of multiple copies of evidence on multiple machines.  Of course, it's all imaginary - only one working copy actually exists - but I don't think these Atreyus are going to look into any magic mirrors any time soon, so our secret is probably safe.

Here's what it looks like from SIFT (Linux).  Notice that Linux thinks I have write privileges, but when I tried to write a file to the RO directory, the request was denied:

SIFT Workstation

This is how it looks to the Windows Virtual Machines:

The view from XP

With this all in place, my usual workflow is as follows:

1. Acquire the disc images with the acquisition machine, saving them to the RO directory on the RAID.
   
   
2. Access the disc image directly over the network from a VM, or copy it to the analysis machine's RO directory if I'm going to do a bunch of work with the image (keyword searches, IEF, etc.).
   
   
3. Scan, search, attack images from multiple VMs at the same time, directing all output to the RW drive.
   
   
4. Scan, search, attack output on RW drive from multiple VMs.
   
   
5. When I'm ready to archive the case, I move everything to the RW drive on the Acquisition machine.  Then it's Sneakernet time.  I access the Acquisition machine directly, and move the files either to the RO folder, or to another location inaccessible by the network.  Because, in reality, I'm just moving files from one directory to another on the same drive, this takes very little time.

Forensicating with Interconnected VMs Part 2 - Division of Labor

Unlike most forensicators, my professional background is neither in Law Enforcement or Information Technology.  My adult life has been spent working in the Railroad industry.  I'll write more on that some other time, but it suffices to say that my background causes me to approach problems differently than most.

One concept that is common on the railroad is Division of Labor.  Certain people are assigned a specific job.  That's what they do.  That's all they do.

On freight trains, the Engineer operates and is responsible for the engines, and the Conductor is responsible for the body of the train.  If you're in the rail yard and have a problem with your train, a Carman helps with car problems and an Electrician diagnoses the locomotive, a Clerk brings you your paperwork, and a Switchman or Utility Man generally lines those pesky switches for you.

Up in the control tower, the Yardmaster plans and directs the various aspects of the operation, but only a Control Operator is allowed to request signals and provide on-track protection.  Once your train leaves the yard, the Train Dispatcher (who is also a Control Operator and a Clerk) is charged with safely and efficiently moving you to your destination.

This division of labor may seem antiquated to many, but the railroad is an old industry with old habits.  "We've done it this way for 150 years," an old bastard of a manager once told a certain idealistic young Train Dispatcher who was trying to computerize a process, "...and we're not going to change it now."  Although seemingly outdated, there is some beauty in the division of responsibilities.  One person simply cannot do everything, and a person with too many tasks can never master them all.  It is this concept that I've carried into my forensics work - at least into the design of my system.


Computer 1 - The Evidence Machine

I don't trust that Windows will keep its hands off my media.  None of us do.  But thanks to great marketing by the "big boy" software vendors, most of us operate with a blind devotion to using only Windows-based tools, miring ourselves in the consequential (and reasonable) FUD that Windows is going to reach out and touch our discs every time when we plug them in.  Hardware write-blockers, like lubricating cream specifically developed to keep our big fat legs from chafing each other while we walk, represent a gazillion-dollar industry that sprang up to solve a problem that shouldn't have existed in the first place.

Because I don't trust Windows, I don't let it anywhere near my evidence media.  I have a computer that, for forensic work flow purposes, only does acquisition. Like the railroad workers described above, that's what it does.  That's all it does.  This workstation runs a forensically-sound OS (Andy Rosen's SMART Linux, which is built atop a stripped down Ubuntu).  This workstation can't play videos.  It doesn't analyze data.  It can't even access the Internet.  All it does is run SMART and save the disc images to a RAID which is directly attached via eSATA.

As far as specifications are concerned, there's nothing fancy here.  This is actually a slightly outdated computer workstation that I picked up for $140 at my local used computer shop.  (Here in Austin, we have plenty of used Dell computers previously donated to schools by the Dell Corporation available in shops.)  I added an eSata card and was good to go.  I have found that the acquisition computer doesn't need to be speedy.  Also, SMART being a slick, scaled-down distro, not much memory is required. 

Computer 2(a)(b)(c)(d) - The Analysis Machine

For analysis, I use VMware Workstation on a Windows 7 Host.  This computer is fancier - it boasts a hex-core processor and 16 GB of RAM - but I didn't take out a second mortgage to get it.  With the monitor and a few 2TB hard drives I picked up on Black Friday, this workstation cost me about $1200 to build.

It's important to note that the host system itself does no forensic analysis.  All work is performed via VMs.  This helps keep my host system uncluttered and free to do important things - like making invoices.  :-)

At any one time, I have the following VMware workstations running or paused:

• SMART by ASR Data
• BackTrack
• Windows XP Professional (for surfing the Internet - more on that in Part 3)
• SANS SIFT Workstation (Linux)
• SANS FOR-408 Workstation (Windows XP)
• SANS FOR-408 Workstation (Windows 7)

Each operating system has distinct strengths and weaknesses.  For example, one method I use for extracting binary data from pcap files only works in Windows XP.  Also, tools like NetworkMiner work best in XP, while fls, mmls, and others are Linux-based.

Each of these workstations is networked together in such a way that they can all attack the evidence together.  That's for Part 3.  Stay tuned!

Forensicating with Interconnected VMs Part 1

I don't believe that this series of posts will be particularly novel or ground-breaking.  I'm also not purporting that this is how everyone should do things.  There may be better ways to skin this proverbial cat, and I'd love to hear them!

The idea of using VMs that communicate with each other was introduced to me in FOR-508 by the fine folks at the SANS Institute.  I tip my hat to Rob Lee and Company for all of their hard work in developing tools and techniques for the entire DFIR community.

Stove Pipe Philosophy

I'm super-paranoid about the client data stored on my PC, and I have this nagging suspicion that The Cloud is out to get me.  Perhaps it won't kill me in my sleep as I imagine.  Most likely it will creep silently into my humble abode, traveling through the mysterious ether in my net, and enter through the back of my forensicator machine.  From there, it will corrupt my data, kick my dog, erase my pr0n or generally make me have really a bad day.

With that in mind, sometimes my forensicating requires that I tap into The Cloud's vast knowledge.  And although it'd be hip and "old school" to have a stove-piped Sneakernet, it's just not practical to keep all my workstations segregated from each other.

Connected, but not connected.  What to do?  See part Two!

Welcome - The Obligatory First Post

Welcome to my humble home on the Internet. With this blog, I will do my best to amuse you, inspire you, and occasionally pass along the occasional useful nugget lucky enough to form in the weird, wild universe between my ears.

I don't claim to be an expert, or particularly interesting. However, I've been known to come up with a good idea now and then. All offers subject to credit approval. Your mileage may vary. Not available in all states.