Building a UNIX/Linux Incident response / Forensic Disk

There are many Linux distributions readily available. This however should not stop you creating your own version of a UNIX forensic tools disc. Whether you are on Solaris, HP-UX or any other variety of UNIX it is simple to create a forensic tools CD that can go between systems. The added benefit of this method is that the tools do not need to be left on the production server. This in itself could be a security risk and the ability to unmount the CD and take it with you increases security.

The ability to create a customized CD for your individual system means that the analyst can have their tools available for any UNIX system that they need to work with. It may also be possible to create a universal forensic CD. Using statically linked binaries, a single DVD or CD could be created with separate directories for every UNIX variety in use in the organization that you are working on. For instance, the same CD could contain a directory called "/Solaris" which would act as the base directory for all Solaris tools. Similarly, base directories for Linux (/Linux), HP-UX (/HPUX10, /HPUX9) and any other variety of UNIX in use in your organization could be included on the same distribution allowing you to take one disk with you but leaving you ready at all times.

The added benefits of creating your own disk that you can update the tools any time you wish and add new ones. On top of this, those scripts that you have been creating may be all listed together in one place. If you are using a KNOPPIX distribution it will not have your scripts. These tools then become your trusted source of software. As was noted above, a script could be created that runs your trusted tool and also the tool on the host to verify that the results are the same. If there are any differences it is easy to note that the system may have been compromised. The added benefit of this distribution is that you can also use it for incident response and forensic work if required.

When creating your distribution you should include the following binaries and statically linked format where possible:

• "chown", "chgrp", "chmod" ?
• "cp", "cat" and "diff",
• "find", "ls" and "ps",
• "dd".
• "df" and "du",
• "rm" and "mv",
• "netstat", "lsof" and "top"

Compression Applications including:

• "compress", "uncompress", "gzip", "gunzip", and "tar".

Include "shared libraries" and "static system libraries" and

• gdb, nm
• ps, ls, diff, su
• passwd
• strace/ltrace
• MD5, hashdeep or another has tool (preferably a number of these)
• fdisk/cfdisk
• who, w, finger
• dig
• scripts
• gcc, ldd
• sh, csh

It is also advisable to include "lsof", and the "sleuthkit" tools as well as their related libraries.

Dynamically linked executables are commonly used due to space limits. As a large number of applications can use identical basic system libraries, these are rarely stored in the application itself. An attacker could still compromise these libraries. Treat all system libraries as being suspect and compile all tools using "gcc" set with the "-static" parameter. This will create a static binary or standalone executable. The "ldd" command can be used to demonstrate the dependency discovery process:

$ /cdrom/bin/ldd calc
libc.so.6 => /lib/libc.so.6 (0x40020000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

About "ldd"

The command, "ldd" may be used to list dynamic dependencies of executable files or shared objects. The "ldd" command can also be used to examine shared libraries themselves, in order to follow a chain of shared library dependencies.
The "pvs" command may also be useful. This command displays the internal version information of dynamic objects within an ELF file. Commonly these files are dynamic executables and shared objects, and possibly reloadable objects. This version information can fall into one of the following two categories:
Version definitions described the interface made available by an ELF file. Each version definition is associated to a set of global symbols provided by the file.
Version dependencies describe the binding requirements of dynamic objects on the version definition of any shared object dependencies. When a dynamic object is built with a shared object, the link-editor records information within the dynamic object indicating that the shared object is a dependency.

For example, the command "pvs -d /usr/lib/libelf.so.1" can be used to display version definition of the ELF file "libelf.so.1".

Craig Wright is a Director with Information Defense in Australia. He holds both the GSE-Malware and GSE-Compliance certifications from GIAC and completed the GSE as well. He is a perpetual student with numerous post graduate degrees including an LLM specializing in international commercial lawand ecommerce law, A Masters Degree in mathematical statistics from Newcastle as well as working on his 4^th IT focused Masters degree (Masters in System Development) from Charles Stuart University where he lectures subjects in a Masters degree in digital forensics. He is writing his second doctorate, a PhD on the quantification of information system risk at CSU.