Greetings, I am pleased to annouce that a new version of Sebek is available for download. Sebek is a tool used to collect keystroke data and SSH/SCP file transfers from honeypots. It is kernel module based and logs remotely via covert network communication. This version represents a significant departure from the old code base and should be much easier to use. Sebek has now been split into multiple distributions, one distribution for the collector side, and one distribution for each supported OS. Currently, sebek has been only ported to run on Linux honeypots with recent 2.4.x kernels. Other ports are on their way ;-) How do I download Sebek? http://project.honeynet.org/papers/honeynet/tools/ , check out the Data Capture section. Who wrote the beast? Mike Clark was the original Sebek code monkey, for this version I have been the ringmaster ;-). At this point there an a good number of people invoved in porting this to other OSs, testing, etc. This has become a true Honeynet Project effort. What is next? Thats a good question ;-) Mostly code maturity efforts. Where do I get more info? READMEs in the tarballs should point folks in the right direction. -------------------------------------------------------------------------- Theory of operation: Sebek2 uses techniques similar to those used by LKM based rootkits. There is one module, sebek.o, that overides the sys_read call to collect interesing data from users. Once the data is collected, this module exports this data over the network to a remote host. Sebek.o also modifies the behavior of the kernel to prevent the discovery of the packets it is transmitting. The second module, cleaner.o is used to hide the presence of the sebek.o module. Whats new in version 2.0.1? - no longer based on adore rootkit, with the exception of the cleaner module. - no userspace applications running - no special files or devices - packets can not be seen from honeypot, even if libpcap is from known good source. - configuration is much simpler. - packets are no longer encrypted or obfuscated because they are hidded from the user in the kernel. Building Sebek: I have recently tested sebek on Redhat 7.3, 8.0 and Slackware 8.1. Prior to building ensure that the the /usr/src/linux-2.4 points to the proper version of the kernel source. It should also be noted that sebek must be built against the exact version you intend to run sebek on. To build sebek, do the following: - ./configure - make After successful building, a binary tarball will be generated in the source directory ex. sebek-linux-2.0.1.tar . This tarball is all that one need to copy on to the honeypot. Configuring Sebek: when configuring the sebek module there are 5 parameters that need to be defined in upper portion of the sebek.sh script. - DESTINATION_MAC This sets the destination address to use in the Ethernet header - DESTINATION_IP This sets the destination address to use in the IP header - DESTINATION_PORT This defines the destination UDP number to use. - FILTER_OUI Sebek bases the decision to hide a packet on the Ethernet Source MAC addresses VENDOR ID. When This value is set, Sebek will transmit packets that have a MAC OUI corresponding to this value. If all honeypots on a LAN use the same FILTER_OUI then it should be the case that NO sebek packets will be visible on the HONEYNET from a HONEYPOT. Only the first 3 octects provided in the FILTER_OUI will be evaluated. - INTERFACE This specifies which interface sebek packets should be exported from. Running: All files for sebek are in the same directory, within that directory is sebek.sh, this is the script that makes every thing happy, configure DESTINATION information in the script and fire it up. If you are doing some diagnosis / testing you may want to comment out the cleaner.o install and removal so you can rmmod sebek.o later. Once you have edited sebek.sh according to you desires and make it executable, then its a matter, of execution ./sebek.sh and the fun begins. Bugs: Currently there is a problem with removing sebek.o after insmod. The problem is related to the fact that after module removal, there is no longer a valid raw socket implementation and this causes some kernel stability issues. This causes kernel oops at system shutdown and will also cause problems if you try to run tcpdump after rmmoding sebek. Some systems that have been patched for the kmod/ptrace vuln seem to not be working well with sebek. This seems to be based on which patch is used. For instance the STD patch for redhat 8.0 and 7.3 seems to work just fine.
This archive was generated by hypermail 2b30 : Mon Apr 07 2003 - 10:13:04 PDT