The new Sebek version uses a redesigned Sebek protocol specification, version 3, which is not backwards compatible. Therefore, for a GenIII Honeynet it is required to use Sebek version 3 in the Roo Honeywall (available by default) and in all the honeypots. Figure 4 illustrates the Sebek protocol binary record format details. Each record has a 56 byte header.

Figure 4. Sebek protocol version 3 packet header.

The new protocol header accommodates the extra information collected at the kernel level, including the parent process identifier (PPID) and the filesystem inode. These two are 32 bits fields and complement the previous protocol version fields. [ref 2] Additionally, the version value currently used is 3 and the "Type" field now supports the new syscalls: read (0), write (1), socket (2) and open (3).

All this information is used by the new GenIII Honeywall advanced data analysis tools to correlate the actions taking place on the honeypot, tracks the attacker's activities at the process level and generates graphical flowcharts representing these events.

Ethereal includes a specific Sebek protocol dissector from version 0.10.0. This dissector is capable of inspecting Sebek protocol version 1, the one used by the previous Sebek releases. Unfortunately, there is no dissector available for Sebek protocol version 3 yet, though this article's author plans to develop one very soon.

Sebek and GenIII Honeynets integration

The result was the new GenIII Honeynet technologies based on the Roo Honeywall. Roo's main purpose was to add advanced data analysis capabilities to the previous GenII version. Sebek is the fundamental tool for advanced data capture and perfectly integrates with the new GenIII Honeynets model and its advanced data analysis features.

GenIII Honeynets implement a new data model independent of the data source. [ref 11] The model establishes the relationships between 4 different conceptual objects: hosts, representing the honeypots, processes, the programs executing in the hosts, files, representing data stored in a hard drive, and network flows, representing communications between hosts.

Sebek data helps to bind these different objects. Processes are identified by the syscalls they invoke. The "read", "write" and "open" syscalls link processes with files, the "socket" syscall links processes with network flows and the "fork" and "clone" syscalls link processes with other processes.

Sebek data is correlated with data captured from the network traffic. The network activities are collected by the Honeywall using the tcpdump network sniffer. These events are processed by different tools: the Snort IDS provides malicious traffic identification, the p0f tool performs OS fingerprinting, and the Argus tool is used for flow monitoring. The data from all these various sources is unified and correlated in a relational database. The data correlation is supported by an Hflow database schema and by the pcap-api interface, used for packet capture manipulation.

The Roo Web-based graphical interface known as Walleye allows one to display and analyze all the data captured and correlated by the honeynet. Typically, an intrusion is initially discovered through the detection of suspicious network events. Figure 5 illustrates Walleye's capabilities to display network traffic details detected by the Honeywall.

Figure 5. Walleye's network flow - Sebek "socket" syscall.

The incident handler should start the incident investigation with a network traffic analysis. In this example, some interaction between system 192.168.100.66 (owned by the attacker) and the honeypot at 192.168.100.150 was detected. This network flow corresponds to TCP traffic with a source port of 1135 and a destination port of 45295. Several packets were exchanged in each direction and the traffic generated two different Snort IDS alerts. The traffic seems to be related with process number 2340 on the honeypot.

Walleye allows one to increase the granularity of the data collected. Figure 6 illustrates the level of detail provided by GenIII Honeynets and Sebek by showing the system processes flowchart diagram associated to the previous network flow. Please note that the image below is a small, truncated version of the original figure and should be click on to be viewed properly.

Figure 6. Truncated illustration of Walleye's process flowchart - Sebek "fork" syscall. Follow the link to view the actual flowchart.

This example shows a Linux honeypot compromised through the "trans2open" Samba buffer overflow. [ref 12] The first Linux process, "init" (PID 1), forked the Samba daemon, "smbd" (PID 1525), which in turn forked a new "smbd" child process (from PID 2320 to 2339) for each new connection received and served. Every connection corresponded to a remote buffer overflow attempt trying to exploit the mentioned Samba vulnerability. Finally, this weakness was successfully exploited by the connection associated to the process with PID 2340. The compromised process generated two different Unix shell process, "sh" (PID 2341 and 2342). The second shell was the one used by the attacker to execute several commands (and processes) on the honeypot, such as "uname", "id", "cat", "ls" or "passwd". The flowchart provides a detailed view of the complete intrusion sequence.

All the information required to build the process flowchart is supplied by Sebek. The Walleye's interface also allows one to inspect additional process details collected by Sebek. By using these capabilities, it is even possible to identify the files accessed during the incident and retrieve the specific commands executed by the attacker. Figure 7 illustrates the activities associated with the shell process (PID 2342) previously referenced on the Figure 6 flowchart. This process opened various library files, such as "/etc/ld.so.cache" or "lib/libtermcap.so.2.0.8", and executed several commands typed by the attacker and captured by Sebek through the "read" syscall, like "uname -a", "id", "cat /etc/passwd" or "ls -l /".

Figure 7. Walleye's process details - Sebek "read" and "open" syscalls.

The new GenIII Honeynets data model provides improved data analysis capabilities that allow one to easily inspect all the activities taking place on the honeynet. Sebek is the key component used to obtain such a detailed level of information.

Concluding part one

The first part of this article series has described the current Sebek version features and enhancements, the lastest Sebek protocol specification, and how this tool integrates with GenIII Honeynets. The article has pointed out Sebek's strengths and weaknesses and has hinted at improving upon one of Sebek's current limitations: whether it is possible to gather what the attacker typed but not the response received. In part two we shall introduce an advanced Sebek version that allows one to overcome this limitation.

References

About the author

(C) Copyright 2006, SecurityFocus.