Transcript Honeynets

Honeynet
By: A.Qahtan
Prepared for: Dr. Khaled Salah
A. Qahtan
1
Outlines
 Introduction
 Terminology
 Honeynet Requirements
 Honeynet Usage
 Honeynet Risks
 Honeypot Virtualization
 Honeynet Tools
 Defeating Honeynets
A. Qahtan
2
Introduction
 Computer security was primarily defensive
 Firewalls, Intrusion Detection Systems,
Encryption
Mechanisms to defensively protect computer
resources
Attackers have the initiative
 Honeynet attempts to change that
A. Qahtan
3
Introduction
 Honeynet attempt to attract attackers to a
system where everything is monitored.
 Using Honeynets
Attackers can be identified
New attacking tools can be discovered
Attack patterns can be determined
Attacker motives can be studied
A. Qahtan
4
Honeypot
 A honeypot is a security resource whose value lies in
being probed, attacked or compromised
 Detect automated probes and attacks
 Capture tools, new worms, etc.
 Raise awareness
 Identify infected/compromised machines
A. Qahtan
5
Honeypot Advantages
 There is no normal traffic
 Everything is suspicious and potentially malicious
 Less data to analyze than IDS system
 Dramatically reducing if not eliminating false positives
 Provide valuable information about attackers
 Capture new types of malware
 Work in IPv6 and encrypted environments
A. Qahtan
6
Honeypot Disadvantages
 Potential risks for your network
 Time consuming to maintain
 Narrow view
Bad guys have to probe, use or communicate with
the honeypot for it to work
A. Qahtan
7
Types of Honeypots
 Low-interaction
Emulate some parts of services and systems
Attacker does not have access to the real OS
Attacker can’t compromise the honeypot
Easy to install and maintain
Low risk
Limited information gathering
Examples
 Listeners, Service emulators, honeyd, tiny honeypot
A. Qahtan
8
Types of Honeypots
 High-interaction
More difficult to install and maintain
High risk
Need containment mechanisms
Extensive information gathering
Examples
 Honeynets, Virtual honeynets
A. Qahtan
9
HoneyToken
 A honeypot that is not a computer (some type of
digital entity)
 e.g. Credit card number, Excel spreadsheet, PowerPoint
presentation, a database entry, or even a bogus login
 Bogus credit card numbers can be embedded in a database
 SSN honeytokens in the students’ database at universities
 IDS sensors could be configured to watch the local networks
for these honeytoken numbers
 If detected on the wire, then the databases have most likely
been compromised
A. Qahtan
10
HoneyToken (example)
 Company is concerned about internal employees
attempting to find company secrets
Create a bogus email, or honeytoken
To: Chief Financial Officer
From: Security help desk
Subject: Access to financial database
Sir, The security team has updated your access to the company's
financial records. Your new login and password to the system can
be found below. If you need any help or assistance, do not
hesitate to contact us.
https://finances.ourcompany.com
login: cfo
password: Ch13ff1n
Security Help Desk
A. Qahtan
11
HoneyMonkey
 Honeymonkey is a new way of detecting malicious
codes from websites that try to exploit certain
vulnerabilities of Internet browsers
 Automated web/internet patrol system
To detect harmful materials in the Internet
To come up with solutions
To catch the people behind these malicious acts.
 Computer system logs on to websites like a
normal computer system to detect harmful codes
that a certain website might try to inject or silently
install onto computers that access it.
A. Qahtan
12
Commercial Honeypots
 Mantrap from Recourse Technologies
(requires Solaris)
Emulates up to 4 hosts (each running Solaris)
running various services
Virtually run any application
 Specter (requires Windows NT)
Can emulate 11 operating systems. Limited to
emulating 13 different vulnerable services.
A. Qahtan
13
Commercial Honeypots
 Netfacade (requires Solairs)
Able to simulate 8 different OSes and 13 different
services.
 Deception Toolkit
Set of PERL scripts that can emulate various
vulnerable services.
A. Qahtan
14
Commercial Honeypots
 Easy to install, configure, deploy, manage and
maintain
 normally very expensive
 managed by administrators with less skills
and knowledge
Via administrative GUI
Come with many different functions and utilities
A. Qahtan
15
Homemade Honeypots
 Require a considerable amount of effort and
time to implement
 Require one with good skill and knowledge to
manage it
 Not limited to customization and configuration
A. Qahtan
16
Honeynet
 A network of high-interaction honeypots
 Real system computers left in their default
(and insecure) configuration
 Multiple systems and applications
 Sits behind a firewall where all inbound and
outbound data is contained, captured and
controlled
 Captured information is then analyzed to learn
the tools, tactics, and motives of the hacker
community
A. Qahtan
17
Honeyfarm
 Honeypots alone have a limited field of view
 Solution – honeyfarms
 Multiple honeypots or even honeynets running vulnerable
services are centrally operated
 Each honeypot virtually belonging to different network
domains.
 Distributed presence
 Deploying redirectors
 A redirector acts as a proxy or 'worm hole' that transports an
attacker's probes to a honeypot within the honeypot farm
 Centralized management
 Convenient attack correlation and data mining.
A. Qahtan
18
Honeynet Farm - example
Honeynet Research Alliance
A. Qahtan
19
Honeypot Farm - example
Honeypot Farm
A. Qahtan
20
Honeynet GEN I
Internet
Firewall
Gateway
Switch
Router
Sys Log
Sparc
Linux
Windows XP
Log/Alert
Server
A. Qahtan
Production Network
IDS
21
Honeynet GEN II
Internet
Production
Production
Production
Router
Honeynet Sensor
Honeypot
Honeypot
A. Qahtan
Honeypot
22
GEN II
 Honeynet sensor (honeywall gateway)
 Layer two bridge (layer three routing gateway can be
used also)
 Bridge is preferred, as it is harder to detect
 Separates production systems from the honeynet
network
 Three interfaces
 eth0 connected to the production systems' network
 eth1 connected to the honeynet systems' network
 eth2 for remote administration of the gateway
A. Qahtan
23
Honeynet Requirements
Data Control
Data Capture
Data Collection
Alerting Mechanism
A. Qahtan
24
Data Control
 Prevent attackers from using the honeynet to
attack or harm other non-honeynet systems
 Mitigates risk, it does not eliminate it
 stealthiness vs safety
More you allow = more you can learn
More you allow = more harm they can potentially
cause
A. Qahtan
25
Data Control: Firewall
 Firewall is the primary tool for controlling
inbound and outbound connections.
 Firewall is designed to allow any inbound
connection and limit the number of outbound
connections
A. Qahtan
26
Data Control: Router
 Supplements the firewall
 Protect against spoofed or ICMP based
attacks
 Allows only packets with the source IP
address of the Honeynet to leave the router
(ingress filtering)
A. Qahtan
27
Data Control: NIPS
 Inspecting each packet as it travels through
our gateway
 On matching any of the IDS rules, alert is
generated and packet can be dropped
(blocking the attack) or modified (disabling the
attack)
A. Qahtan
28
Data Capture: NIDS
 Log all attacker activities
 Firewall logs all connections initiated to and
from the Honeynet
 IDS logs ALL data in tcpdump format
 IDS configured to send an alert when certain
attack signatures are seen
A. Qahtan
29
Data Capture: SysLog
 The central syslog server is a hardened host
within the honeynet
 Attract more sophisticated attacks once a
blackhat has compromised one of the default
configuration honeynet systems
A. Qahtan
30
Data Collection
 Applies to organizations that have multiple
honeynets in distributed environments
 Single honeynet requires only data control and
data capture
 Multiple honeynets have to collect all of the
captured data and store it in a central location
 Captured data can be combined, exponentially
increasing its value
 Honeyfarm
A. Qahtan
31
Alerting
 Some organizations that cannot support 24/7
staff
 Alternative is automated alerting
 Automated monitoring using Swatch, the
Simple Watcher
A. Qahtan
32
Honeynet Usage
 Learn about hackers
 Tune the IT security process
 Intrusion prevention
 Honeypot-based forensics
 Eliminating false positive of the IDSs
A. Qahtan
33
Honeynet Risks
 Attracting attention to their seemingly insecure
configuration
 Require constant maintenance and
administration
 Data Analysis is very time consuming
Single compromise on average requires 30-40
hours of analysis
 Risk of detection
A. Qahtan
34
Honeypot Virtualization
 Tar pits
 VMWare
 Honeyd
 UML
A. Qahtan
35
Tar Pits
 Computer entity that intentionally responds slowly
to incoming requests
 Delude clients
 Unauthorized or illicit use of a fake service might be
logged and slowed down
 Layer 7 tarpits (defeating spammers)
 Looks like open mail relays, but instead answer very
slowly to SMTP commands
 Layer 4 Labrea tarpit
 Slow down the spread of worms over the Internet
 TCP window size reduced to zero
 Tar pit continues to acknowledge incoming packets
A. Qahtan
36
VMWare
 Commercial software for virtual machines
 Allows you to launch multiple instances of
different operating systems on a single piece of
hardware
 Isolates OSes in secure virtual machines
 Maps the physical hardware resources to the virtual
machine's resources
 Emulates x86 hardware
 Widely used by honeypot operators
 Allows easy deployment of honeypots
A. Qahtan
37
Honeyd
 Open source honeypot daemon
 Was used with another tool arpd
 Arpd answeres ARP requests in order to redirect
needed traffic to Honeyd
 Simulates several virtual hosts at the same time
 Permits configuration of arbitrary services
 Supports only IPv4, TCP, UDP and ICMP
protocols
A. Qahtan
38
User-Mode Linux (UML)
 Free software under the GPL
 Create virtual machines
 Virtualizes Linux itself
 Runs an entire Linux environment in user-space
 Runs multiple instances of Linux on the same hardware
 Dedicated to Linux
A. Qahtan
39
Building Blocks
 Honeywall
 Sebek
 Bait and switch technique
A. Qahtan
40
Honeywall
 Data capture and data control
 IDS snort / IPS snort_inline
 Netfilter/iptables for traffic limiting
 Further monitoring - swatch
A. Qahtan
41
Snort_inline
 Inline packet modification engine
 Modified version Snort (in recent snort version it
becomes part of snort)
 Adds several new rule types (drop, sdrop and reject)
 Provides packet rewriting from something dangerous
into something harmless
 e.g replacing the string /bin/sh by /ben/sh using the rule
alert ip $HONEYNET any -> $EXTERNAL_NET any
(msg:"SHELLCODE x86 stealth NOOP"; sid:651;
content:"|EB 02 EB 02 EB 02|";
replace:"|24 00 99 DE 6C 3E|";)
A. Qahtan
42
Netfilter/iptables for traffic limiting
 Netfilter/iptables-functionality of the Linux kernel for
connection limitation
 Prevents the abuse of a compromised honeypot for:
 Denial-of-service attacks, mass scanning, download toolkits
and setup automated bots
 Honeynet Project allows 15 outgoing TCP-connections and
50 outgoing ICMP packets per day
[...]
### Set the connection outbound limits for
different protocols.
SCALE="day"
TCPRATE="15"
UDPRATE="20"
ICMPRATE="50"
OTHERRATE="15"
A. Qahtan
[...]
43
Sebek
 Client/server based application
 The primary data capture tool used by honeynet researchers
 Kernel-module on Linux & Solaris, patch on OpenBSD /
NetBSD, device driver for Windows
 Kernel-based rootkit that hijacks the read() system call
 Remember API Hooking ??
 Record all data accessed via read()
 Send data passing through sys_read() in covert manner over
the network to the sebek server
 Overwrites part of the network stack (packet_recvmsg) to
hide Sebek data passing on to the network
 Network counters and data structures have to be adapted
A. Qahtan
44
Bait and switch technique
 Follows the security paradigm of "Protect, Detect and
React“
 Protect the network as best as possible (Firewalls)
 Detect any failures in the defense (IDS)
 React to failures (alerting)
 Bait and Switch redirects all malicious network traffic to
a honeypot
 Attacker is attacking a trap instead of real data
 based on Snort, iproute2, netfilter/iptables and some
custom code
A. Qahtan
45
Defeating Honeynets






Tarpits
VMWare
Snort_inline
Netfilter/iptables
Sebek
Bait and switch
A. Qahtan
46
Detecting Tar Pits
 Attacker (10.0.0.2) trying to reach a fake web server, (10.0.0.1)
 looking at the answers from 10.0.0.1 with records from tcpdump
 Window size starts at 3 and then 0 for the next connection
 Attacker figures this very easily
A. Qahtan
47
Detecting Tar Pits
 Attacker on the same network segment as Labrea can
do fingerprinting at layer 2
 Tarpits answers with the same unique MAC address
0:0:f:ff:ff:ff
 Looking at such ARP responses
 04:59:00.889458 arp reply 10.0.0.1
(0:0:f:ff:ff:ff) is-at 0:0:f:ff:ff:ff
 you can find and change this hard coded value in the
sources of Labrea (PacketHandler.c)
 u_char bogusMAC[6] = {0,0,15,255,255,255};
A. Qahtan
48
Detecting VMWare
 IEEE standards assigned MAC addresses to VMWare
in the ranges
 00-05-69-xx-xx-xx
 00-0C-29-xx-xx-xx
 00-50-56-xx-xx-xx
 MAC addresses can be obtained via
 arp –a
 Unix: ifconfig or Windows: ipconfig /all
 Honeypots operators usually the NetBIOS port
 Attacker interacts with NetBIOS services can obtain the
MAC address using commands
 Unix: nmblookup or Windows: nbtstat -A @IP
A. Qahtan
49
Detecting VMWare
A. Qahtan
50
Detecting VMWare
A. Qahtan
51
Detecting Snort_inline
 Dropping of outgoing packets = blackhole
 Modification = can be detected by sophisticated
attacker
 Stealthiness of Snort_inline can be increased
with fewer rules, but this leads to more attacks
that will not be noticed
A. Qahtan
52
Detecting Netfilters/iptables
 Aggressor can simply try to
Open many outgoing connections to different hosts
Send a lot of ICMP echo request packets to varying
hosts
 If after some time no more outgoing packets
can reach the target then it is a honeypot
A. Qahtan
53
Detecting Sebek
 Latency
 Read a single byte via a read(1) call = Sebek will transfer
nearly 100 bytes of data
 Do it tens of thousands of times = network congestion
 e.g. ping a local IP (the gateway)
 dd if=/dev/zero of=/dev/null bs=1
 Ping again
 Average round-trip time grew from 0.7 milliseconds to
over 4800 milliseconds
A. Qahtan
54
Detecting Sebek
 Displaying hidden modules
 Sebek uses cleaner.c, a simple loadable kernel module
that unlinks the last module in the kernel's module list
 module_hunter.c is able to locate hidden modules
 module_hunter.c searches for patterns of module
structures in the kernel's address space and is able to
detect modules hidden via unlinking
 Using the same technique one can get the address of
Sebek’s cleanup_module() and disable Sebek
 Toolkit written in Python 2.3 can detect and remove
Sebek from honeypot
 Get the source code at md.hudora.de
A. Qahtan
55
Detecting Sebek
A. Qahtan
56
Detecting Sebek
 Modification of sys-call table
 Commonly used by rootkit
detection tools
 Looking at the system call table
and analyzing the pointers to the
various system calls
 Unmodified system call table,
the pointers to the read() and
write() system calls are adjacent
 Sebek changes the pointer of
the read() system call
 Adjacency is no longer given
A. Qahtan
57
Detecting Sebek
 Network traffic counters
Sebek adjusts some counters to conceal the
transmission of the logging data
Sophisticated attacker compares the kernel's
internal network counters and the output of
ifconfig or other tools
A. Qahtan
58
Kebes
 Anti-Sebek techniques
Sebek activity (log)
Anti-Sebek
All network traffic
Use encrypted communication /
attack logging host (hard!)
All calls to read()
don’t use read()
Forensic data obtained keep most things in memory only
by disk analysis
Syslog-data
avoid it as best as possible
A. Qahtan
59
Kebes
 Under the project name NoSEBrEaK
 Entirely written in Python 2.3 for portability with no
external dependency
 Uses mmap() to avoid read() system calls
 Implements all basic functionality of a shell
 Reading and writing of files
 Secure deleting
 Direct executing of programs
 Implements an encrypted channel between the
attacker and the honeypot
 logging of network activity is useless
A. Qahtan
60
Summary
 Never end fight between hackers and security
community
 Honeynets should be carefully deployed and
should act as real system (stealthness vs
safety)
 Be aware of hackers techniques in detecting
honeypots
A. Qahtan
61
Q&A
Thank you
A. Qahtan
62