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 audit 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 auditing. 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 audit 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 audit 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 of 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”,
- “df” and “du”,
- “rm” and “mv”,
- “netstat”, “lsof” and “top”
- Include “shared libraries” and “static system libraries”
- gdb, nm
- ps, ls, diff, su
- MD5 or another has tool (preferably a number of these)
- who, w, finger
- gcc, ldd
- sh, csh
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. Threat 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 calcAbout ”ldd”
libc.so.6 => /lib/libc.so.6 (0x40020000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
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.
Alternatively, if you are starting out, there is still the SIFT workstation from SANS if you do not wish to go to all the trouble of creating your own. This works for general forensics, but in any organization where you have a set *NIX build, I would recommend creating your own system disk based on those systems you actually deploy.