Second Generation Honeynets

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"UDPR
ATE"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 ltgt
• EXTERNAL_NET 80 (msg "REJECT")
• drop tcp HONEYNET any ltgt
• EXTERNAL_NET 80 (msg "DROP TCP")
• sdrop tcp HONEYNET any ltgt
• EXTERNAL_NET 80 (msg "SDROP")
• alert tcp HONEYNET any ltgt
• EXTERNAL_NET 80 (msg "Modifying HTTP GET"
• content"GET" replaceBET")

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_at_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_at_cablespeed.com

22
An Introduction to Sebek2

• Edward Balas
• ebalas_at_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.honeyn
  et.org/papers/honeynet/tools/
• For questions or comments contact Edward Balas
• ebalas_at_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

• 10525348598400sshd7c2d
• 10525348598420bash0ptsc2f
• 10525348598400sshd7c2f
• 10525348618420bash0ptsc2
• 10525348618400sshd7b2
• 10525348618400sshd7b68Filesystem
  1K-blocks Used Available
• Use Mounted on
• 10525348618400sshd7b396/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_at_sumatra sebek sbdump.pl -c ./10.0.0.1
• 024739-2003/05/10 0bash842pts0df
• 024744-2003/05/10 0bash842pts0who
• 024747-2003/05/10 0bash842pts0last
• 024828-2003/05/10 0bash842pts0scp
  10.0.0.2/tmp/svs_thinking.gif .
• 024855-2003/05/10 0ssh886pts3SSH-2.0-OpenS
  SH_3.1p1
• 024936-2003/05/10 0bash842pts0scp
  edb_at_10.0.0.2/tmp/svs_thinking.gif .
• 024936-2003/05/10 0ssh888pts3SSH-2.0-OpenS
  SH_3.1p1
• 024940-2003/05/10 0ssh888pts4thepasswdthi
  s
• 024940-2003/05/10 0scp887pts7C0644 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
  thepasswdthis
• edb_at_sumatra sebek ./sbdump.pl -s ./10.0.0.1
• 024940-2003/05/10 SCP (local)lt-remote
  svs_thinking.gif 194614 bytes
• 024940-2003/05/10 SCP passwd thepasswdthis 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

51
Summary

• A complete port of sebek is possible but
  difficult and time consuming

52
Resources

• Download
• http//project.honeynet.org
• Authors
• Michael A. Davis (mike_at_datanerds.net)
• Contributors
• Blake Watts (blake_at_blakewatts.com)

53
Virtual Honeynets

• Mike Clark

54
What is a Virtual Honeynet?

• Full OS
• Run within another OS

55
Virtualization Software

• VmWare
• User Mode Linux
• Others

56
Why use a Virtual Honeynet?

• Physical Concerns
• Portability
• Easy

57
Types of Virtual Honeynets

• Self-Contained
• Hybrid

58
Disadvantages

• Everything on 1 system
• Detection
• Cant support every OS/hardware

59

• http//www.honeynet.org
• ltproject_at_honeynet.orggt