Second Generation Honeynets by 28w075I


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

An introduction to Second Generation
 Honeynet Technologies.
    Inline Snort
    Sebek2
    Virtual 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.
               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.
      Honeynet Requirements

 Data Control
 Data Capture
 Data Collection (for distributed Honeynets)
Honeynet - GenI
            Honeynet - GenII
 Easier to Deploy
   Both Data Control and Data Capture on the
    same system.
 Harder to Detect
   Identify activity as opposed to counting
   Modify packets instead of blocking.
Honeynet - GenII
            Honeynet Tools

Find all the latest Honeynet tools for Data
Control, Capture, and Analysis at the Honeynet
Tools Section.
Data Control

 Rob McMillen
No Data Control
Data Control
IPTABLES Packet Handling


   INPUT                       OUTPUT
   CHAIN                       CHAIN

   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
           rc.firewall (data control)
### Set the connection outbound limits for different protocols.

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
iptables -A FORWARD -i $LAN_IFACE -m state




                                   Packet Flow



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";)

   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
  ( if you have
  ideas or suggestions.


 Contact:
An Introduction to Sebek2

       Edward Balas
             What is Sebek

 A forensic tool used to record activities on
  a honeypot
 Designed to record keystrokes even when
  intruder uses secure communication
 Provides ability to recover files copied to or
  from a honeypot with SCP.
 Operates as a hidden kernel module on a
             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
             Sebek ports under
 Solaris
   Job de Hass
 Windows
   Mike Davis
 OpenBSD
   Dragos Ruiu
                  Sebek Design

 There are 2 components:
   The client, which collects the data on the
   The server, which records and processes
    the data exported by the honeypots.
                   Sebek Client

 Two fundamental issues for the client
   collection of forensic data
   covert export of the data to a collector
            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.
                      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.
                The data that Sebek
 In the past Sebek has used a number of
  heuristics to determine what data if found
 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 to do the interpretation.
              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
            Sebek: The Server Side

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

 Sebek can be downloaded from
 For questions or comments contact
  Edward Balas
                  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 can
  process the data for the user.
                          Raw Data: the df
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
             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
                   What can do?

 Run as -c
[edb@sumatra sebek]$ -c ./
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 .
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@ .
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
                   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
 Lets take a closer look at the file transfer…
                                 Recovering SCP files

 Run 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
        Password used to authenticate was

edb@sumatra sebek]$ ./ -s ./
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
The file…

 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
 All heuristics have been removed from the client
  for the newest version, however is still
  vulnerable to evasion.
Windows port of Sebek

     Michael A. Davis
     Lead Developer
   SecurityProfiling, Inc.
            The Problem

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

 Stealth
   Filter sebek packets from ALL IP network
   Undetectable
 Logging of GUI and Console I/O
   Example: cmd.exe via IIS.
 Secure configuration
             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

 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

 Not easily detectable.
 Full “view” of the system.

 Never 100% undetectable.
 May degrade system performance.
 Undocumented structures etc lead to a
  longer development cycle.
            Current Version

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

 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

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

 Download
 Authors
   Michael A. Davis (
 Contributors
   Blake Watts (
Virtual Honeynets

    Mike Clark
      What is a Virtual Honeynet?

 Full OS
 Run within another OS
        Virtualization Software

 VmWare
 User Mode Linux
 Others
  Why use a Virtual Honeynet?

 Physical Concerns
 Portability
 Easy
   Types of Virtual Honeynets

 Self-Contained
 Hybrid

 Everything on 1 system
 Detection
 Can’t support every OS/hardware

To top