Network Xfer Client/Server Utility (nx)

nx is a command line tool that acts as either a client or server for the purposes of transferring data from more than one computer (acting as clients) to a central computer (acting as the server). The server in this case, would be the forensic workstation gathering information during an incident response. The clients would be those computers that are under investigation.

There are other tools available that perform this function such as netcat and cryptcat. nx, however, focuses on (a) secure collection, (b) archiving the file metadata and (c) creating a complete log file of all the transactions that occurred. For extracted files, an MD5 hash is logged as well as the original directory path that the file is taken from.

nx operates in one of two modes to transfer data: (a) pulling data from standard input and (b) explicitly copying files. The transport used is TCP/IP with the data content encrypted in a RC4 stream cipher. To ensure data integrity from the client computer to the final archived file on the server, a hash is computed at client side before transmission, and during receipt, by the server. A mismatch in hashes results in the archive file being labeled as having errors. Finally, the results can be controlled by the client end, meaning each specific data transfer is outputted to a separate file. Labels and filenames are allowed to be passed during each data transfer, which are consumed by the server and acted upon accordingly. The number of tunable parameters at this point is still limited, but as suggestions come in, additional flexibility can be added.

Currently, this initial version is restricted to just IPv4. Depending on need, IPv6 can be added. While there are compiled versions for Windows, Linux and Mac OS X, the architecture is such that each one is designed to play well with another instance operating on a different OS (eg. use nx on a Linux box as the server and use nx on a Windows client box to send data to the server).


How to use nx to complement live forensics collection

The terms 'client and server' are used here as 'roles' for the nx tool. Any machine that nx runs on does not require the operating system to be configured as a client or server. Any normal (non-server operating system) computer configuration will work. All that is required is that there is some network connectivity between the computers.

To configure nx as a server role, use the [-server] command option. Without the [-server] option, nx runs in client mode. The direction of data flow is always from the client to the server. One can think of the clients as those workstations you would like to extract forensics artifacts from, and the server as the workstation you would like to store the extracted artifacts to. In the server role, nx can handle multiple clients at once. Since it was designed as a multi-threaded application, nx simply spawns a separate thread per client connection. Therefore, simultaneous collection from a few clients should not be an issue under normal loading conditions. The maximum number of simultaneous client connections is really a function of: (a) the computer resources of the machine acting in the server role, (b) the amount of data being transferred from each client, and (c) the network bandwidth of the system.

nx client/server flow

Configuring nx as a server

Since nx can be configured as one of two roles (client or server), the menu options are broken out accordingly. The required parameters for the server are: (a) IP address of the server, (b) unique port number to identify how to contact the nx service, and (c) the directory to store all the collected artifacts to. The one optional parameter is the [-key] parameter that can be used to set the crypto key to some user defined passphrase. Without using the [-key] option, nx still encrypts the data transferred over the network (for clients sending data to the server) using its own internal algorithm.

nx server setup

After invoking the above command, the operating system should request permission to open up a network connection at the port specified in the 'listen' mode. For Vista or Windows 7, one should get a popup box similar to the one below.

Windows Firewall Alert

Configuring nx as a client

Configuring nx in the client role is a matter of specifying the same IP address and port number used when configuring the server, and then, issuing the desire command to transfer data. As a test, one should try to 'ping' the server from the client computer using the [-ping] option. This will ensure the crypto is synchronized between the client and server. Below is an example of doing this with an Ubuntu 64 bit computer (for the client) talking to an nx server running on Windows 7.

nx client ping

Not only does the [-ping] verify the connection, but the timing statistics get archived on the server log. For the above example, if one notices closely, one can see that the client's clock is 'behind' that of the server's clock. This is something that should be noted, since any artifacts extracted from a client computer is relative to that specific client's computer clock. In general, when taking artifacts from one computer and comparing them to another computer (perhaps from a web or mail server), one needs to be able to synchronize the time between artifacts from different machines.


Sending data to the server

There are a number of ways to send artifacts from a client computer to the server. All of the options are enumerated in the menu displayed from the command prompt, shown below:

nx cmd menu

The most basic command, which is not listed in the menu, but implied, is the ability to take any console output from some other tool and relay it to the server. Other options, combined with this basic capability, allow one to add documentation for each dataset that is transmitted. This includes: (a) comments and (b) a name to be used as part of the filename of the data archive.

As an example, one can send the network configuration as described by ifconfig (on Linux). As part of the command, one can annotate a comment to help the examiner remember any context information at the time of the collection. One can also specify a name, to be used as part of the filename that is saved on the server end.

piping ifconfig into nx

On the server end, all metadata information is archived within the server log. This log is named '<start_date_time>_results.csv'. From the extension, one can see, it is formatted as a Comma Separated Value (csv) file. This format was chosen since it is ubiquitous across various platform spreadsheet applications. The only disadvantage with the csv format, however, is that some filenames contain commas, since the comma is a valid filename character on Windows. nx handles this by converting every comma in the filename to another character when putting it into the log file. This is something to be aware of.

Below is a snapshot of the log file. From it, one can see the type of metadata recorded per transaction, such as: status, date/time, source IP/port, data type, etc. For those transactions that created a file in the archive directory, an MD5 hash will be computed and documented here. Furthermore, the name of the archive file itself will incorporate the md5 hash and any name that was requested to be used. While this makes for long filenames, it solves the problem of identifying where the data came from, what time it was collected, and ensuring all names are unique.

Looking at the last transaction, one can see the results of the 'ifconfig' command. Note, the comment, specified by the [-comment] option, was included into the log entry. Also, the name, specified by the [-name] option, was appended to the end of the filename of the archived file

nx server results file

When one opens the actual archived file for this last transaction, one will see that the data was archived with line feeds (LF) for 'end of line' characters. This behavior is normal to Linux/Unix operating systems. Windows, however, would like to see carriage return/line feed (CRLF) pairs. To address this, nx has an option [-crlf], that performs this conversion as part of the transmission, if desired. (Note: the [-crlf] option is only applicable to the Linux and Mac OS-X variants of the binary, and therefore, are not included in the Windows version of the binary).

Other commands that send data include: (a) [-comment <comment to send>], (b) [-copyfile <path/file>], and (c) [-copyfile -pipe], which is a specialized version of [-copyfile] that receives its path/filenames from standard input.


For more information

For specific details about options and how to use those options, the user's guide can be viewed here

If you have any questions about nx, contact us via email.

Downloads

Intel 32-bit VersionIntel 64-bit VersionARM 64-bit Version
Windows:nx32.v.0.41.win.zipnx64.v.0.41.win.zipnx64a.v.0.41.win.zipmd5/sha1
Linux:nx32.v.0.41.lin.tar.gznx64.v.0.41.lin.tar.gznx64a.v.0.41.lin.tar.gzmd5/sha1
Mac OS X:Not Availablenx.v.0.41.dmgnx.v.0.41.dmgmd5/sha1
*32bit apps can run in a 64bit linux distribution if "ia32-libs" (and dependencies) are present.