1 / 59

Second Generation Honeynets

Second Generation Honeynets. JedHaile Mike Clark Rob McMillen Edward Balas Mike Davis Dragos Ruiu. Purpose. An introduction to Second Generation Honeynet Technologies. Agenda. Inline Snort Sebek2 Virtual Honeynets. Honeynets. Nothing more then one type of honeypot.

ostinmannual
Download Presentation

Second Generation Honeynets

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Second Generation Honeynets JedHaile Mike Clark Rob McMillen Edward Balas Mike Davis Dragos Ruiu

  2. Purpose An introduction to Second Generation Honeynet Technologies.

  3. Agenda • Inline Snort • Sebek2 • Virtual Honeynets

  4. Honeynets • Nothing more then one type of honeypot. • High-interaction honeypot designed to capture in-depth information. • Its an architecture, not a product or software. • Populate with live systems.

  5. How it works • A highly controlled network where every packet entering or leaving is monitored, captured, and analyzed. • Any traffic entering or leaving the Honeynet is suspect by nature. http://www.honeynet.org/papers/honeynet/

  6. Honeynet Requirements • Data Control • Data Capture • Data Collection (for distributed Honeynets) http://www.honeynet.org/alliance/requirements.html

  7. Honeynet - GenI

  8. Honeynet - GenII • Easier to Deploy • Both Data Control and Data Capture on the same system. • Harder to Detect • Identify activity as opposed to counting connections. • Modify packets instead of blocking.

  9. Honeynet - GenII

  10. Honeynet Tools Find all the latest Honeynet tools for Data Control, Capture, and Analysis at the Honeynet Tools Section. http://www.honeynet.org/papers/honeynet/tools/

  11. Data Control Rob McMillen

  12. No Data Control

  13. Data Control

  14. IPTABLES Packet Handling

  15. rc.firewall • Configure the gateway mode • Sets default policies • Allows ALL traffic to our Honeynet • Limits traffic from our Honeynet • Alerts on certain traffic • Sets restrictions on the management interface

  16. rc.firewall (data control) ### Set the connection outbound limits for different protocols.SCALE="day"TCPRATE="15"UDPRATE="20"ICMPRATE="50"OTHERRATE="15" iptables -A FORWARD -p tcp -i $LAN_IFACE -m state --state NEW -m limit --limit ${TCPRATE}/${SCALE} --limit-burst ${TCPRATE} -s ${host} -j tcpHandler iptables -A FORWARD -p tcp -i $LAN_IFACE -m state --state NEW -m limit --limit 1/${SCALE} --limit-burst 1 -s ${host} -j LOG --log-prefix "Drop TCP after ${TCPRATE} attempts“ iptables -A FORWARD -p tcp -i $LAN_IFACE -m state --state NEW -s ${host} -j DROP

  17. snort_inline iptables -A FORWARD -i $LAN_IFACE -m state --state RELATED,ESTABLISHED -j QUEUE

  18. snort_inline reject tcp $HONEYNET any <> $EXTERNAL_NET 80 (msg: "REJECT";) drop tcp $HONEYNET any <> $EXTERNAL_NET 80 (msg: "DROP TCP";) sdrop tcp $HONEYNET any <> $EXTERNAL_NET 80 (msg: "SDROP";) alert tcp $HONEYNET any <> $EXTERNAL_NET 80 (msg: "Modifying HTTP GET"; content:"GET"; replace:“BET";)

  19. Future • Get ip_queue functionality in other OS. • Create a generic way to get packets to SI. • Better way to do connection limiting. • Integrate snort_inline into snort. • Feel free to contact me at (rvmcmil@cablespeed.com) if you have ideas or suggestions.

  20. Summary

  21. Resources • http://www.honeynet.org/papers/gen2/ • http://bridge.sourceforge.net/ • http://www.honeynet.org/papers/gen2/rc.firewall • http://snort-inline.sourceforge.net • Contact: rvmcmil@cablespeed.com

  22. An Introduction to Sebek2 Edward Balas ebalas@iu.edu

  23. What is Sebek • A forensic tool used to record activities on a honeypot • Designed to record keystrokes even when intruder uses secure communication channel. • Provides ability to recover files copied to or from a honeypot with SCP. • Operates as a hidden kernel module on a honeypot.

  24. Who developed Sebek • Sebek is a collaborative effort within the Honeynet Project. • Originally based on the adore rootkit and coded by Mike Clark for the linux OS. • The second version, written by Edward Balas, included a number of improvements that made it more covert and comprehensive. • This second version is currently being ported to a number of OSs by members of the team

  25. Sebek ports under development • Solaris • Job de Hass • Windows • Mike Davis • OpenBSD • Dragos Ruiu

  26. Sebek Design • There are 2 components: • The client, which collects the data on the honeypot • The server, which records and processes the data exported by the honeypots.

  27. Sebek Client • Two fundamental issues for the client • collection of forensic data • covert export of the data to a collector

  28. Forensic data collection • Client code uses a kernel module to replace the function that implements the read system call. • When data of interest is observed by this module, it is copied and queued for export. • all data recorded in newest version • A variety of techniques are used to hide the existence of the kernel module. These are similar to those used by modern rootkits. • All actions take place in kernel space outside the view of users.

  29. Data export • The kernel module creates its own ethernet frames and then sends them directly to the ethernet driver, bypassing firewall filters, and packet sniffing. • A special source MAC OUI is used in the ethernet frames created by Sebek. • When a honeypot running Sebek receives packets with the source OUI, it silently ignores them and prevents users for seeing them. • It is impossible for a user on the honeypot to detect the Sebek traffic being exported.

  30. The data that Sebek gathers • In the past Sebek has used a number of heuristics to determine what data if found interesting. • The newest and yet to be released version gathers all data that is seen in the “sys_read” function call. • This ensures that there are no blind spots as there are in the current version. • Once the data is exported and gathered on the collector it is the responsibility of a tool called sbdump.pl to do the interpretation.

  31. The Data Export Format • Sebek data is colon delimited and has the following fields: • Timestamp, in seconds since epoch • Process ID for process making read request. • User ID for process making read request. • Command Name for the process. • File Descriptor Number. • TTY name. • Length of Data • Data

  32. Sebek: The Server Side • The Sebek server code involves two applications: • sebeksniff • sbdump.pl. • sebeksniff can extract Sebek records from an packet capture file or can sniff directly from a LAN. • Records are stored in a file based on the Source IP address of the honeypot. • sbdump.pl attempts make viewing the data easy, it includes ability to recover SSH copied files.

  33. Where Can I get Sebek • Sebek can be downloaded from http://project.honeynet.org/papers/honeynet/tools/ • For questions or comments contact Edward Balas • ebalas@iu.edu

  34. Using Sebek • Example shows a user logging into a honeypot with SSH and then copying a file to the honeypot • First we will look at the raw data recorded • Second we will how how sbdump.pl can process the data for the user.

  35. Raw Data: the df command 1052534859:840:0:sshd:7::c:2:d 1052534859:842:0:bash:0:pts:c:2:f 1052534859:840:0:sshd:7::c:2:f 1052534861:842:0:bash:0:pts:c:2: 1052534861:840:0:sshd:7::b:2: 1052534861:840:0:sshd:7::b:68:Filesystem 1K-blocks Used Available Use% Mounted on 1052534861:840:0:sshd:7::b:396:/dev/sda5 505605 131737 34776 4 28% / /dev/sda1 101089 12566 83304 14% /boot /dev/sda3 679912 16428 628948 3% /home none 127956 0 127956 0% /dev/shm /dev/sda2 1873772 834856 943732 47% /usr /dev/sda6 505605 434100 45401 91% /var

  36. Raw Data Observation • It is difficult to read the raw data • Redundancy of data for related key strokes • Redundancy for same data getting piped through multiple processes • Control chars and non-text data

  37. What can sbdump.pl do? • Run as sbdump.pl -c 10.0.0.1 [edb@sumatra sebek]$ sbdump.pl -c ./10.0.0.1 02:47:39-2003/05/10 [0:bash:842:pts:0]df 02:47:44-2003/05/10 [0:bash:842:pts:0]who 02:47:47-2003/05/10 [0:bash:842:pts:0]last 02:48:28-2003/05/10 [0:bash:842:pts:0]scp 10.0.0.2:/tmp/svs_thinking.gif . 02:48:55-2003/05/10 [0:ssh:886:pts:3]SSH-2.0-OpenSSH_3.1p1 02:49:36-2003/05/10 [0:bash:842:pts:0]scp edb@10.0.0.2:/tmp/svs_thinking.gif . 02:49:36-2003/05/10 [0:ssh:888:pts:3]SSH-2.0-OpenSSH_3.1p1 02:49:40-2003/05/10 [0:ssh:888:pts:4]thepasswd=this 02:49:40-2003/05/10 [0:scp:887:pts:7]C0644 194614 svs_thinking.gif

  38. Things to notice • The -c argument attempts to get all interactive terminal “character” data, it is not always 100% accurate as you can see by some of the scp data that came through. • We can see that the intruder first checked the disk for capacity, then checked to see who was logged and the last time folks logged in, after that came a failed file transfer attempt then the good attempt • Lets take a closer look at the file transfer…

  39. Recovering SCP files • Run sbdump.pl with -s arg • Following points descovered: • A file called svs_thinking.gif was copied to the box from a remote site, we know from the eariler run of sbdump that it was 10.0.0.2. • Password used to authenticate was “thepasswd=this” edb@sumatra sebek]$ ./sbdump.pl -s ./10.0.0.1 02:49:40-2003/05/10 SCP (local)<-remote svs_thinking.gif 194614 bytes 02:49:40-2003/05/10 SCP: passwd thepasswd=this 1

  40. The file…

  41. Limits • Data export mechanism uses UDP and thus does not provide reliable stream transport. • Heuristics used in Sebek to detect interesting data are not 100% fool proof, some tuning may be necessary. • Same heuristics rely on static signatures for interesting data, thus providing target for evasion techniques. • All heuristics have been removed from the client for the newest version, however sbdump.pl is still vulnerable to evasion.

  42. Windows port of Sebek Michael A. Davis Lead Developer SecurityProfiling, Inc.

  43. The Problem 100% Sebek UNIX functionality on Win32 while maintaining interoperability with Sebek UNIX.

  44. Requirements • Stealth • Filter sebek packets from ALL IP network drivers. • Undetectable • Logging of GUI and Console I/O • Example: cmd.exe via IIS. • Secure configuration

  45. The Solution • In memory patching of syscalls • Hook the console and GUI subsystems • Spy on all the read/write calls performed by the subsystem. • Determine any undocumented structures by reverse engineering • Use a private key for configuration changes

  46. Stealth • Hook Registry functions(ZwQueryKey, ..) • Hook File System functions(ZwQueryDirectoryObject, …) • Hide all packets we transmit or receive(NDIS hooking) • Use a special configuration application to configure the driver. • Configuration is stored in the actual driver

  47. Advantages • Not easily detectable. • Full “view” of the system.

  48. Disadvantages • Never 100% undetectable. • May degrade system performance. • Undocumented structures etc lead to a longer development cycle.

  49. Current Version • Filters network traffic for specific OUI • Will hide other sebek packets from remote hosts • Console monitoring (cmd.exe etc) • Initial version of the configuration application • Can change OUI to filter • Stores configuration in the driver

  50. Future • Enable stealth features • Hook registry and file system functions • Transmit monitored data to remote host • Once keystroke have been logged send them to the UNIX based archiver • Monitoring GUI applications

More Related