The Honeynet Project Advancements in Honeypot Tools

Presented by Kirby Kuehl Background Feel free to ask questions during presentation. Websites:

About the Honeynet Project Informally began as the Wargames mailing list in Project officially formed in Became a Non-profit organization in Consists of 30 members who volunteer their time and resources to research the hacker community.

Honeynet Project Goals Learn the Tools, Tactics, and Motives of the Hacker Community Raise Awareness through release of “Know Your Enemy” series of whitepapers. Teach and Inform Scan of the Month Challenges Reverse Challenge Forensic Challenge Research Honeynet Alliance Tool Development

Layer 3 Data Control: A shell script counted the number of outbound connections initiated by the attacker and blocked all connections after a count of 10 was reached. This suspicious behavior could lead to the discovery of the firewall via TTL decrementing (traceroute) and possible attack since the firewall obviously has Layer 3 Address (IP Address). Data Capture: The IDS (snort) listens on the span port of the switch, capturing all inbound/outbound traffic.

Generation II Honeynet Sensor Components: The Bridging Firewall Counting and Blocking Connections Improvements Data Control with Snort-Inline Sebek kernel module Honeyd and arpd Sneak Peak of “The Honeywall CD”

Honeynet Data Control The Linux Bridging Firewall Bridges are Layer 2 devices that connect two or more distinct Ethernet segments. All packets received by one interface are transparently copied to the other interface based upon MAC address. A Bridging Firewall is capable of transparently filtering received frames before they are copied to the second interface. Requires a Linux kernel compiled with bridge and bridge firewall support. See for kernel patches and more information.

Honeynet Data Control Method 1: Counting and Blocking Connections IPTables Firewall Script uses the LOG and ACCEPT targets for all inbound connections allowing attackers to enter the honeynet. The IPTables Firewall Script LOGs and ACCEPTs outbound connections until a predefined limit is reached within a specified timeframe. Connection attempts beyond the limit are DROPped. Example Data Control Firewall Script

Honeynet Data Control Method 2: Snort-Inline The Honeynet Project utilizes Snort-Inline in combination with netfilter/iptables operating as a bridging firewall to send packets to userspace for processing. This is accomplished with the QUEUE target. The standard queue handler for IPv4 iptables is the ip_queue module, which is distributed with the kernel and marked as experimental. Snort-inline (the userspace application) uses the libipq API, (which is distributed with iptables) to receive and possibly manipulate the packets traversing the bridge as demonstrated in the next slides. Snort-Inline: Netfilter/iptables:

Snort-Inline Rule Options Drop – The drop rule tells iptables to drop the packet and log it via usual snort means Sdrop – The sdrop rule tells iptables to drop the packet. Nothing is logged. Reject – T he reject rule type tells iptables to drop the packet; log it via usual snort means; and send a TCP reset if the protocol is TCP or an ICMP port unreachable if the protocol is UDP.

Snort-Inline Drop Rule To drop an DNS attack, the signature would look as follows: drop tcp $HOME_NET any $EXTERNAL_NET 53 (msg:"DNS EXPLOIT named";flags: A+; content:"|CD80 E8D7 FFFFFF|/bin/sh";

Snort-Inline Drop Rule Management Kernel Space modprobe ip_queue iptables -A OUTPUT -p icmp -j QUEUE Iptables-1.2.7a Ip_queue User Space Snort-InlineSnort Rules = Drop DROP snort –Q –c /snort.conf

Snort-Inline Replace Rule Another option replaces portions of the payload (disabling the effectiveness of the attack) but allowing the connection to continue: alert tcp $HOME_NET any -> $EXTERNAL_NET 53 (msg:"DNS EXPLOIT named";flags: A+; content:"|CD80 E8D7 FFFFFF|/bin/sh"; replace:"|0000 E8D7 FFFFFF|/ben/sh";)

Snort-Inline Replace Mode Management Kernel Space modprobe ip_queue iptables -A OUTPUT -p icmp -j QUEUE Iptables-1.2.7a Ip_queue User Space Snort-Inline Snort Rules = Replace Internet /bin/sh/ben/sh

Honeyd Honeyd, when used in conjunction with arpd can simulate an entire LAN containing virtual hosts. These virtual hosts can fool various TCP and ICMP fingerprinting methods. These virtual hosts can run various virtual, proxied, or fake services.

Honeyd Operation ping arpd arpd_send: who-has to arpd_reply: is-at 00:09:6b:e0:39:9b honeyd Sending ICMP Echo Reply: > Reply from : bytes=32 time<10ms TTL=64

Honeyd: The role of arpd Like the bridging firewall used by snort- inline, arpd also operates at Layer 2. Arpd replies to any ARP request for an IP address (Layer 3) within the simulated network with the MAC address of the specified interface of the machine running arpd. This allows one host to simulate an entire network of machines.

Arpd Screenshot

Honeyd Screenshot

ARP Cache

Sample Honeyd Configuration # Example of a simple host template and its binding create default set default personality “FreeBSD STABLE” add default tcp port 80 “sh scripts/web.sh” add default tcp port 22 "sh scripts/test.sh $ipsrc $dport" add default tcp port 113 reset add default tcp port 1 reset set default uid gid bind default set uptime #add default tcp port 23 proxy :23 #set default subsystem “/usr/sbin/httpd”

NMAP Portscan and OS Fingerprint

Sebek Kernel Space data collection The Sebek kernel module collects data passing through the read() system call. This captures the intruder’s ssh keystrokes and recovers scp file transfers. Sebek utilizes the adore rootkit to hide the sebek files and processes from the attacker. Sebek : Adore:

Sdm : The Sebek Device Monitor Sdm encrypts the payload. Based on the intruder’s input, the IP addresses, MAC addresses, and UDP port numbers are falsified. Data is transferred using a variable amount of delay. Sdm transmits decoy packets when there is no legitimate traffic.

Sebeksniff and Sbdump Collects the data from sdm, unencrypts it, and stores it in a log file. Use the sbdump.pl script to examine these log files. Sbdump displays the timestamp, user id, process name, tty, file descriptor and the data (ssh keystrokes or file transferred by scp)

Sebek Diagram

Honeywall CD Coming Soon… Bootable CDROM Honeynet Gateway extracts operating system onto a ram drive. Hardware requirements: 256MB of RAM, a CD- ROM, a 10GB IDE hard drive (for logging and storage of various boot variables such as which networks to bridge), and two NICs. Capable of Generation 1 (Layer 3) or Generation 2 (Layer 2) Honeynet Data Control. Kernel contains bridge firewalling support for the inline enabled snort. Also includes Sebek, dsniff, tcpdump, and p0f.

Honeywall CD Main Screen

Initialize drive mounts a local IDE drive for Honeynet Logging and storage of settings.

Start Layer 2 Bridge

Bringing up the bridge and starting various utilities

Wininterrogate: Analysis of Win32 File systems and Processes

Wininterrogate: File system Recursively walks directory structure obtaining the following: File Name Complete Path Directory File Size Creation Time Last Access Time Last Write Time Attributes

Wininterrogate: Processes Display Process Name and Path Process ID (pid) Linked DLLs DLL Entry Point DLL Base DLL Image Size Port Bindings (Windows XP Only)

Wininterrogate: Common Options MD5 Checksum providing similar functionality to tripwire CSV (comma separated value). Import into Microsoft Excel or any database for processing. Extra information Gathered on *.DLL, *.VBX, *.DRV, *.EXE, *.OCX, *.BIN, *.SCR CompanyName FileDescription FileVersion InternalName LegalCopyright OriginalFilename ProductName ProductVersion