Facilitating Fluffy Forensics – Part 1

CloudPassage / 04.22.13

I’ve always known that CloudPassage Halo could help facilitate forensic acquisition in cloud environments but we’ve been missing the ability to acquire disk images from target servers in a reliable, repeatable, and free manner.

After reading Ken Pryor’s excellent NBDServer blog post on Wednesday, April 10th, and while preparing for my SOURCE Boston 2013 talk entitled Facilitating Fluffy Forensics, I found myself wondering if the tool might help with investigations in public cloud environments.

In fact, I contacted Ken via a Direct Message on Twitter to share my idea (and thank him for the inspiration):

Ken Convo

I also had a conversation with Windows forensics expert, Harlan Carvey, about his Forensic Scanner application and potentially using NBDServer in place of the commercial acquisition tool, F-Response, to mount the drive.

Of course, a native Windows nbd-client does not exist so I put my efforts into detailing a configuration that would allow a nbd-client server, running on Linux, to act as a relay for Read-Only file system access. For the sake of brevity, and due to the detailed nature of this configuration, CloudPassage Halo policies to secure the documented process will be discussed in a later blog post.

Network Diagram

diag

The Configuration

Step 1) Prepare your nbd-client server

For the purpose of this example we used an Ubuntu Server 12.10 32-bit micro instance image to act as the nbd-client instance on Amazon EC2. After launch, the first thing you should do is update your server’s packages:

ubuntu@ip-10-50-201-39:~# sudo apt-get update && sudo apt-get upgrade –y

You must install a few packages to satisfy the undocumented dependencies:

ubuntu@ip-10-50-201-39:~# sudo apt-get install libglib2.0-dev pkg-config build-essential -y

And then downloaded and extracted the nbd-3.3.tar.gz from SourceForge.net:

ubuntu@ip-10-50-201-39:~# wget http://sourceforge.net/projects/nbd/files/nbd/3.3/nbd-3.3.tar.gz
ubuntu@ip-10-50-201-39:~# tar zxvf nbd-3.3.tar.gz ubuntu@ip-10-50-201-39:~# cd nbd-3.3

You must then configure, make, and make install the application:

ubuntu@ip-10-50-201-39:~/nbd-3.3# sudo ./configure
ubuntu@ip-10-50-201-39:~/nbd-3.3# sudo make && sudo make install

Step 2) Preparing your Windows nbd-server target

Using a Windows Server 2008 R2 system on Amazon EC2, I downloaded and installed the NBDServer from Jeff Bryner’s GitHub repository. You can either use the browser to download the file or use the following quick PowerShell command:

PS C:UsersAdministratorDownloads> Invoke-WebRequest https://github.com/jeffbryner/NBDServer/archive/master.zip -OutFile master.zip

Change to the NBDServer-master directory and launch the NBDServer:

PS C:UsersAdministratorDownloads> cd NBDServer-master
PS C:UsersAdministratorDownloadsNBDServer-masterNBDServer-master> .NBDServer.exe -c 10.50.201.39 -f .PHYSICALDRIVE0 -n0

This instructs the server to connect to the private client IP (10.50.201.39) and serve up the first partition on drive 0.

Step 3) Ensuring communications

By default, the Windows Firewall will block communications between the nbd-client server and the target running the nbd-server. Using Halo, you can adjust your firewall policy to allow communications between your nbd-client and nbd-server instances via their private IP addresses. A Windows firewall policy must be created for the nbd-server target that:

  • Only allows authorized incident responders to access the server,
  • Allows nbd-client connections, on 60000/tcp, from the private IP address of your nbd-client system, and
  • Allows outbound connections to GitHub, on port 443, for the downloading of the NBDServer executable.

A Linux firewall policy must also be created for the nbd-client server that:

  • Only allows authorized authenticated incident responders to access the server,
  • Allows outbound nbd-client connections, on 60000/tcp, from the private IP address of your nbd-client system to the nbd-server, and
  • Allows outbound connections to Ubuntu repositories, on port 443, for the downloading of updates.

Note, a full Halo policy for performing the above firewall configurations will be discussed in a follow-on blog post.

Finally, the Amazon EC2 Security Groups must be configured to allow nbd communications between servers via TCP port 60000. Even though Amazon utilizes 10.0.0.0/8 for its private addressing scheme, each network is chopped up into /24 networks. As such, it’s impossible to guarantee that your nbd-client and nbd-server target will be in the same network – unless of course you launch everything within the same VPC. Note: Samba rules will also need to be added to the local firewall policy and the EC2 Security Groups if the nbd-client is going to be relaying the Read-Only share to additional servers.

Step 4) Connecting the client

To connect the nbd-client to the nbd-server, you must first load the nbd module into the kernel:

ubuntu@ip-10-50-201-39:~/nbd-3.3# sudo modprobe nbd

You can then launch the client:

ubuntu@ip-10-50-201-39:~/nbd-3.3# sudo ./nbd-client 10.198.86.84 60000 /dev/nbd0

Where 10.198.86.84 is the target Windows Server IP address, 60000 is the default port for the nbd-client to connect on, and /dev/nbd0 is the first nbd block device to connect the remote target as.

Upon successful connection you should see something similar to the following lines within your Linux terminal:

Negotiation: ..size = 30718MB bs=1024, sz=32210157568 bytes

And a connection message within your Windows terminal:

[+] Connection made with: 10.50.201.39

Step 5) Mounting the target drive locally

You must first create a directory against which you will mount the target drive:

ubuntu@ip-10-50-201-39:~/# mkdir /mnt/target10-198-86-84
ubuntu@ip-10-50-201-39:~/# sudo mount -t ntfs-3g -o ro,show_sys_files,streams_interface=windows /dev/nbd0 /mnt/target10-198-86-84

You might notice that the directory was mounted with the ro setting (for Read-Only) configured. This actually doesn’t matter as the target’s drive is shared as Read-Only. You can mount using the rw settings if you wish, but it will still not allow you to modify the contents or structure of the target server’s file system.

Step 6) Sharing the target’s drive

You may want to share the target’s Read-Only drive to additional systems. This is useful when you need to run Windows-based tools, such as Forensic Scanner or a collection of malware scanners, against the target system. Perhaps the easiest way to share the target’s drive is to use Samba. The first thing you must do is install the Samba packages on your nbd-client server:

ubuntu@ip-10-50-201-39:~/# sudo apt-get install samba –y

Once installed, edit the /etc/samba/smb.conf file. Ensure that the security = user setting is enabled (i.e. the hash character is removed) and that the following is added to the bottom of the file:

[share]
comment = Forensic Share
path = /mnt/target10-198-86-84
browsable = yes
guest ok = yes
read only = yes
create mask = 0755

Save and exit the file. In order for the changes to work, you must restart the smbd and nmbd daemons:

ubuntu@ip-10-50-201-39:~/etc/samba# sudo restart smbd && sudo restart nmbd

Conclusion

The steps mentioned above help you configure the servers and the NBDServer client/server application. Using nbd-client, nbd-server, Samba, and Amazon EC2 micro instances, you should now be able to mount the share from your server without the possibility of tainting the file system or any forensic artifacts of the nbd-server target. In my next blog post I’ll expand on using NBDServer, cloud server instances, and CloudPassage Halo to facilitate secure cloud forensics. Topics that will be discussed include how to:

  • Automate the isolation of the target server,
  • Restrict remote access to incident responders,
  • Dynamically restrict, and selectively allow, inter-server communications,
  • Generate logs that prove file system integrity of all servers and applications throughout the investigation, and
  • Validate the configuration settings of required services (e.g. Samba).

References: