Honeypots and User Mode Linux Part 2: Forensic Analysis

  • Article

by MichaelF on August 04, 2006 05:50pm

UML (User Mode Linux) and Forensic Analysis

(Special thanks to Dan Simonton for the testing and writing in support of this tech tip)

Processes running under UML will have no access to the hosting system, accept where explicitly allowed. Because of this UML is an ideal candidate for operating a honeypot. While processes running in UML have no outside access to the host operating system memory or filesystem; hypothetically, if an attacker managed to break out of userspace into some section of the host filesystem, they could do further damage on the host . Best-practice demands that host access be limited within the UML instance wherever possible.

For any of this to be practical, obviously some services would need to be established. We’ll just assume these are already in place and forwarding iptables rules setup on the host. For instance, to forward inbound http connections to your UML instance:

iptables -t nat -A PREROUTING -i eth0 -p tcp -s 0/0 \
       --dport 80 -j DNAT --to-destination (uml ip):80

This process could be repeated for any other service you wish to run. Just be sure the appropriate destination port is specified both with the “--dport” option and also at the end of the command. Essentially you are instructing all inbound traffic to port 80 to be forwarded to your UML. The same process could be repeated for ssh,ftp and others.                                                                               

Typically, the first order of business for an intruder with root access is to wipe out log files. It is best therefore to have log files written to the host (or another remote) machine. To achieve this,  the host system’s syslogd daemon must be configured to receive inbound logs. Add “-r” to the runlevel script of the host machine where it invokes syslogd the correct path is: /etc/rc.d/syslog. On the client machine, add the following to /etc/syslog.conf:

                        *.*         @yourhostmachine  
                                     (note: @ipaddress will work also)

Now inbound connections to the UML honeypot and activity on the honeypot can be investigated through log files on the host machine.

Conveniently for the purpose of running UML as a honeypot, tty_logging of UML into a directory on the host machine is built as an option into the kernel. The simplest way to achieve this is to add the following to the kernel command line:

            tty_log_dir=dir

This way, even if they zap the shell log files on the UML, you will still have an account of their activity on the machine.

There are a few quick and common methods of checking running activity. The following two should be familiar to anyone with a relatively basic understanding Linux, but we’ll mention them here for propriety’s sake:

            ps auxwww (check running process table)

            netstat –lvnap|less (check open sockets, associated process, and user ids)

In the past, whenever I’ve found any strange binaries (sometimes named something really vague or obscure), I’ll run the following command, sift through, and evaluate the output:

            strings (filename)|less

An all-to-commonly overlooked tool for inspecting a system is “lsof” (list of open files). It can be used to check file-to-file access, files listening on a socket and evaluate the state of a running process. It is helpful to know the normal running health of a system for comparison when using lsof. For a quick check of a specific process:

             lsof –p (pid)

To get socket info on a process:   

               lsof  -i  -nP|grep -i (process name)

To protect against potential outbound denial-of-service attacks, it might be prudent to explicitly declare hosts you wish to allow outbound ICMP traffic to (the host ip being one for example) and deny everything else. This can be done on the host by adding the following rules to iptables. You can add as many “ACCEPT” rules as you need, just be sure to put them before  the “DROP” rule.

        iptables -A INPUT -p icmp –s (uml ip) –d (host ip) –j ACCEPT
        iptables –A INPUT –p icmp –s (uml ip) –d (other ip) –j ACCEPT
        iptables –A INPUT –p icmp –s (uml ip) –d 0/0 –j DROP

Similiarly, you could block potential outbound syn-flooding:  

   iptables -N syn_flood
     iptables -A INPUT -p tcp --syn –s (uml ip) -d 0/0 -j syn_flood
     iptables -A syn_flood -m limit --limit 1/s --limit-burst 3 -j
RETURN
   iptables -A syn_flood -j DROP

A quick search of https://sourceforge.net or https://freshmeat.net will quickly realize a vast sea of various analysis tools. Provided the disk image size for your is adequate, any of these can be copied to the drive image or simply downloaded once you have the UML instance running.  A few useful tools are:

Tripwire: Useful for monitoring data integrity. In a nutshell, it takes a snapshot of your system binaries (or other specified directory), creates a checksum, runs routine system integrity checks against it, and reports any deviation.

The Coroner's Toolkit: A suite of utilities for checking running process and file/filesystem information, recent changes and other such information.

Snort: Snort is so prevalent, it almost needs no description. Still, it is one of the best tools for traffic analysis and intrusion detection. To accurately provide a description that does this monster justice would be a blog unto itself. There is a great FAQ on their website:

https://www.snort.org/docs/faq/1Q05/

Chkrootkit: A utility for identifying rootkits installed on the system.

This is but a small (microscopic) primer into a much larger world of intrusion detection and integrity analysis, but we hope some may find this useful. We will likely delve into these subjects in the future.