2006-02-13
Introduction
In part one of this series, we discussed the current Sebek development and its integration with GenIII Honeynets. In this article, we take it a step further and focus on best practices to deploy Sebek inside a GenIII Honeynet, as well as the new Sebek "write" patch. This patch is a cutting edge improvement that makes it possible for a security professional to watch all the attacker's activities in real time, in a similar way that one records his family's evolutions with the video camera.Best practices to install, configure and run Sebek clients
Installation of Sebek version 2, plus its configuration and usage are extensively covered on the original Sebek KYE paper. [ref 1] This article discusses best practices to deploy Sebek version 3 on a GenIII Honeynet environment and provides details about the different Sebek Linux and Windows versions currently available.The Sebek 3 client installation and configuration process is very similar to those from former versions. Figure 1 illustrates the standard procedure to build and configure Sebek for Linux.
Build process: # ./configure # make # make install (optional) Configuration process: # vi sbk_install.sh Clean up process: # cd ..; rm -rf sebek* # rm -f /usr/local/bin/sbk_install.sh /usr/local/bin/gen_fudge.pl
The compilation process generates a binary tar file (sebek-linux-3.0.3-bin.tar or sebek-lin26-3.1.2b-bin.tar.gz) that must be copied and installed into the target honeypot. This file only contains the scripts (parameters.sh and sbk_install.sh) and kernel modules required to install Sebek.
It is recommended that one compile the module on a separate system running the same Linux kernel and deploy Sebek using this binary tar file. This is to reduce the traces about Sebek's existence in the production honeypot. If Sebek is installed in the honeypot itself, through the "make install" command, it is advisable to remove the Sebek source code directory and the two scripts installed under "/usr/local/bin", as was illustrated in Figure 1. Additionally, the user shell history files for many shells (such as Bash) typically contain the commands executed during the compilation process; these should be removed too.
To install Sebek on a Windows platform, the two executable files, "Configuration Wizard.exe" and Setup.exe must be copied to the honeypot. The kernel driver installer, Setup.exe, guides you through the kernel driver installation process. The wizard installs the driver on the standard Windows location, C:\WINDOWS\system32\drivers on Windows XP or C:\winnt\system32\drivers on Windows 2000, using the default driver name SEBEK.SYS. From a security point of view, the installer should be run with the "/N=NAME" command line argument to specify a non-standard driver name.
Figure 2, below, illustrates the Sebek Windows client setup wizard where a different driver name, SCSICTRL, has been specified. As in Linux, a defensive countermeasure is not to keep a copy of the configuration files on the honeypot itself once Sebek has been installed.
Figure 2. Sebek installation process on Windows.
The following recommendations detail best Sebek configuration practices for GenIII Honeynets from a security perspective. Sebek is configured on Linux by editing the "sbk_install.sh" script, which contains the different Sebek configuration variables: DESTINATION_IP and DESTINATION_MA. These variables should contain the default gateway IP and MAC addresses. If by chance the intruder could recover the Sebek configuration, these values won't disclose the real Sebek server identity. Besides, if the intruder could see Sebek packets these won't look suspicious. The packets addressed to the default gateway look like any other traffic and won't help to identify where the Sebek server resides. In a GenIII Honeynet, the stealthy Honeywall acting in bridge mode will collect all Sebek traffic no matter what values these variables have been set to.
It is also important to ensure that the default gateway does not generate ICMP port unreachable messages - it would tip off the intruder about Sebek. Below is a brief description of some of the key configuration variables:
- DESTINATION_PORT: All honeypots on the same honeynet must use the same destination port. This is because this port is used by the Sebek server to identify interesting traffic and by the Sebek clients (together with the magic value) to hide other honeypots Sebek traffic.
- MAGIC_VAL: The magic value is used in conjunction with the destination port to determine which packets to hide in the honeynet. It must be set to a difficult to guess value.
- KEYSTROKE_ONLY: This variable should be set to zero (the default value is one) in order to collect all read syscalls and be able to recover entire files exchanged through, for example, SCP. Enough disk space is required in the Honeywall to save the large amount of information generated by the honeypots when running in this mode.
- SOCKET_TRACKING: Socket activity must be monitored (by default) to be able to establish the process and network relationships showed through Walleye in the first part of this article.
- TESTING: In a production environment, this value should be set to zero (by default), so that the Sebek module is hidden and can't be removed using the "rmmod" command.
- MODULE_NAME: The Sebek module name must be set to a non-suspicious value not related with Sebek at all, such as "scsictrl" (SCSI controller kernel module). Setting this option is even preferable to leaving this variable blank, which would thereby select a random name for the module. The random name could look suspicious to an intruder if he is able to see it.
- WRITE_TRACKING: This option is only available in the Linux 2.6 version (3.1.2b) and allows one to activate the experimental feature implemented by the Sebek "write" patch, covered later in this article.
Some variables, such as INTERFACE or SOURCE_PORT, have not been mentioned above because there is no special security recommendations for GenIII Honeynets that must be associated to them. More detailed information about the variables meaning is available on the tool documentation and script files. [ref 1] [ref 2]
Sebek is set up on Windows through a graphical tool called "Configuration Wizard.exe". This wizard guides you through the Sebek customization process to define all Sebek configuration variables. These are similar to the Sebek Linux client variables explained previously, except that there is a lack of granularity when defining Sebek's capabilities, as illustrated below in Figure 3. The keystroke, socket, write or testing modes cannot be specified. Besides, the Sebek Windows version does not allow one to set the source port. It always uses the default "1101" value.
The Sebek Windows client provides an additional variable that contains the name of the process entitled access to the Sebek driver. Once the Sebek driver has been installed, it is hidden and can only be accessed and reconfigured using a program with a specific name, the one specified in this variable. It is recommended to change the name of the default "Configuration Wizard.exe" tool used to manage Sebek, and therefore the name of this variable, to a non-standard value.
Figure 3, below, compares the main differences between the Sebek Linux and Windows clients.
| Sebek version 3 | Linux 2.4 | Linux 2.6 | Windows |
| Survives reboots? | No |
No |
Yes |
Advanced configuration granularity:
|
Yes (w/patch) Yes Yes Yes Yes |
Yes Yes Yes Yes Yes |
No No (1101) No No No |
| Real rootkit hiding capabilities (*) | No |
No |
Yes |
| Additional hiding module required | Yes (cleaner.o) |
No (built-in) |
No (built-in) |
| Option not to replace the raw socket implementation (at compile time) | No |
Yes |
No |
| Complementary reconfiguration tool | No |
No |
Yes |
(*) These capabilities were removed on purpose from the initial Sebek Linux versions to reduce chances of misuse. Sebek was based on the Adore kernel rootkit.
As can be observed in Figure 3, there are still some pending improvements in both platforms. For instance, it would be desirable to have the capability to survive reboots on Linux and the fine-grained configuration capabilities on Windows.
Once the client has been installed and configured, Sebek is started by running the "sbk_install.sh" script on Linux or by rebooting the honeypot on Windows.
Best practices to run the Sebek server
The Sebek 3 server (v3.0.3) is installed and configured by default on the Roo Honeywall, so the details about how to compile it won't be covered. It follows the Linux standard build procedure.The Sebek server tools [ref 2] manage the network traffic logged by the Sebek clients. The main extraction tool is called "sbk_extract" and it is based on libpcap. [ref 3] It simply sniffs traffic in promiscuous mode from the Honeywall internal interface, filtering by the Sebek destination port. No matter who the Sebek traffic is addressed to, it will be captured by the Sebek server. Sebek records are processed by this tool and their binary representation is sent to the standard output. Typically, this output is piped to the input of the "sbk_ks_log.pl" utility, which processes Sebek's records and writes detailed keystroke logs to the standard output, as illustrated below in Figure 4.
Figure 4. Sebek standard usage: sbk_extract and sbk_ks_log.pl.
Another tool, called "sebekd.pl", can be used to upload the Sebek data into a MySQL database, such as the one available inside the Roo Honeywall. This tool invokes "sbk_extract" internally and inserts Sebek records as database records. "sebekd.pl" replaces the "sbk_upload.pl" command available in previous versions.
In order to avoid potential vulnerabilities on libpcap or the tools themselves, and be independent of the client implementation, it is recommended that you take proper security precautions to protect the Sebek server and minimize the risk of a Sebek compromise.
From a security perspective, the "sbk_extract" tool must run in a chroot environment. Figure 5 illustrates an example of how to invoke a chrooted instance of the tool. Both options, -u and -c, must be used simultaneously in order to avoid root to escape from the chroot environment. [ref 4] [ref 5]
# sbk_extract -i eth1 -p 29905 -u eric -c /tmp/chroot | sbk_ks_log.pl
Additionally, the environment should be protected with a system call policy enforcement application, such as Systrace [ref 6] and with stack protection software, such as stack randomization [ref 7] and ExecShield. [ref 8] [ref 9] These two stack security mechanisms are active by default on the Roo Honeywall Linux 2.6 kernel, based on the Fedora Core 3 distribution.
Finally, to decrease the likelihood of detection using the methods pointed out in the first part of this article, it is recommended that one modify the default Sebek client configuration variables as previously covered. A further security step would be to modify Sebek's source code to make it different from the publicly available version.
Continued...
