Download The Use of Honeynets to Detect Exploited Systems Across Large

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
The Use of Honeynets to Detect
Exploited Systems Across Large
Enterprise Networks
John Levine*, Richard LaBella***, Henry Owen*,
Didier Contis*, Brian Culver**
*School of Electrical and Computer Engineering
**Office of Information Technology
Georgia Institute of Technology
*** South Florida Honeynet Project
Agenda
• Introduction
• Establishment of the Honeynet on the
Georgia Tech Campus
• Exploitations Detected on the Georgia Tech
Network
• Lessons Learned
• Conclusions and Further Recommendations
Introduction
•
•
•
•
Definition of a Honeynet
Concept of Data Capture and Data Control
Generation I vs. Generation II Honeynets
Description of the Georgia Tech Campus
Network
Introduction
• Current Vulnerabilities on the Internet
• Current Tools to Protect Networks
– Firewalls
– Intrusion Detection Systems (IDS)
Shortcomings Associated with
Firewalls
1. The firewall cannot protect against attacks that
bypass it, such as a dial–in or dial-out
capability.
2. The firewall at the network interface does not
protect against internal threats.
3. The firewall cannot protect against the
transfer of virus–laden files and programs
Shortcomings Associated with
Intrusion Detection Systems
(IDS)
1. Increase Complexity of Security
Management of Network
2. High Level of False Positive and False
Negative Alerts
3. Must Know Signature or Anomoly
Detection Pattern
Definition of a Honeynet
• Network Established Behind a Reverse
Firewall
• Captures All In-Bound and Out-Bound
Traffic
• Any Type of System
• Network is Intended To Be Compromised
• All Honeynet traffic is suspicious
Data Capture and Data Control
• Data Capture
– Collect all information entering and leaving the
Honeynet covertly for future analysis
• Data Control
– Covertly protect other networks from being
attacked and compromised by computers on the
Honeynet
Generation I vs. Generation II
• GEN I Honeynet
–
–
–
–
–
Simple Methodology, Limited Capability
Highly effective at detecting automated attacks
Use Reverse Firewall for Data Control
Can be fingerprinted by a skilled hacker
Runs at OSI Layer 3
• GEN II Honeynet
– More Complex to Deploy and Maintain
– Examine Outbound Data and make determination to
block, pass, or modify data
– Runs at OSI Layer 2
Georgia Tech Campus Network
• 15000 Students, 5000 Staff, 69 Departments
• 30000-35000 networked computers on campus
• Average data throughput 600Mbps/4 terabytes per
day
• NO FIREWALL BETWEEN CAMPUS &
INTERNET!
– Why? Requirement for Academic Freedom, high
throughput
– However, individual enclaves within Georgia Tech use
firewalls
• IDS is run at campus gateway
– Out of band monitoring and follow-on investigation
Establishment of the Honeynet
on the Georgia Tech Campus
• Established in Summer of 2002
• Uses Open Source Software
• Initially Established As One Honeynet
Machine behind the firewall
• IP Address Range Provided by Georgia
Tech Office of Information Technology
(OIT)
Georgia Tech Honeynet
Hardware and Software
• No Requirement for State of the Art
Equipment (Surplus Equipment)
• No Production Systems
• Minimum Traffic
• Use Open Source Software (SNORT,
Ethereal, MySQL DB, ACID)
• Use Reverse Firewall Script Developed by
Honeynet.org
Intrusion Detection System (IDS)
• SNORT
– Open Source
– Signature-Based, with Anomaly-Based Plug-in
Available
– Can Write Customized Signatures
• Run Two Separate SNORT Sessions
– One Session to Check Against Signature
Database
– One Session to Capture All Inbound/Outbound
Traffic
Analysis Console for Intrusion
Detection (ACID)
Logging and Review of Data
• Honeynet Data is stored in two separate locations
– Alert Data is stored in SQL database
– Packet Capture Data is stored in a daily archive file
• Data Analysis is a time consuming process
In my Experience:
– One hour/day to analyze traffic
– One hour of attack traffic can result up to one week of
analysis
Ethereal Analysis Tool
Exploitations Detected on the
Georgia Tech Honeynet
• 36 possible exploited machines have been
detected at Georgia Tech in previous 9
months (through June 2003)
• A report is made to OIT on each suspected
compromise
Identification of a System with a
Compromised Password
• Previously Compromised Honeynet Computer
Continued to Operate as Warez Server
• Another Georgia Tech Computer Connected to
the Warez Server
• Investigation Revealed that Password had been
Compromised on Second Georgia Tech
Computer
Detection of Worm Type Exploits
• GEN I Honeynet Well-Suited to Detect
Worm Type Exploits
– Repeated Scans targeting specific ports
– Analyze captured data for time lapses
• Ability to Deploy Specific Operating
System on Honeynet
Exploitation Pattern of Typical
Internet Worm
• Target Vulnerabilities on Specific Operating
Systems
• Localized Scanning to Propagate (Code Red)
– 3/8 of time within same Class B (/16 network)
– 1/2 of time within same Class A (/8 network)
– 1/8 of time random address
• Allows for Quick Infection Within Internal
Networks with High Concentration of
Vulnerable Hosts
Lessons Learned from Gen I
Honeynet
1. Start Small
2. Maintain Good Relations with Enterprise
Administrators
3. Focus on Attacks and Exploits Originating
within your Enterprise Network
4. Don’t Publish Honeynet Addresses
5. Don’t Underestimate Time Requirement
6. Powerful Machines are NOT Necessary
Georgia Tech Honeynet Gen II
Initial Observations of Gen II
Honeynet
• Configuration is more complex than Gen I
• Must use variants of Linux 2.4 kernel in
order to run Sebek keystroke logger
capability
• Data must continue to be monitored on a
daily basis
• Lessons Learned from Gen I Honeynet still
apply
Conclusions and Further
Recommendations
• Honeynet Assists in Maintaining Network
Security
• Provides Platform for Research in
Information Assurance and Intrusion
Detection
• Deployment of a Distributed Honeynet
Jul_31
• Date Public: 7/24/02 Date Attack: 1/25/03
Sep_10
Jun_10
Apr_20
Apr_12
Apr_04
Mar_27
Mar_19
Mar_13
Mar_07
Feb_27
Feb_20
Feb_13
Feb_05
Jan_28
Jan_22
Jan_14
Jan_06
Dec_29
Dec_21
Dec_13
Dec_05
Nov_29
Nov_21
Nov_19
Nov_09
Nov_08
Oct_20
Oct_28
Oct_04
Oct_12
Sep_24
Sep_17
Sep_09
Aug_21
Aug_29
Aug_06
Honeynet Portscan Activity
Port 1434 (MS-SQL) scans
1200
1000
800
600
Series1
400
200
0
M
ay
_
M 20
ay
_
M 21
ay
_
M 22
ay
_
M 24
ay
_
M 27
ay
_
M 27
ay
_
Ju 3 1
n_
Ju 0 2
n_
Ju 0 3
n_
Ju 0 5
n_
Ju 0 9
n_
Ju 1 3
n_
Ju 1 7
n_
Ju 2 1
n_
Ju 2 5
n_
3
Ju 0
l_
02
Ju
l_
0
Ju 6
l_
1
Ju 0
l_
1
Ju 4
l_
1
Ju 8
l_
2
Ju 1
l_
2
Ju 5
l_
A u 29
g_
A u 02
g_
A u 06
g_
A u 10
g_
A u 14
g_
A u 18
g_
A u 22
g_
A u 26
g_
S e 31
p_
S e 03
p_
07
co
un
t
Honeynet Portscan Activity
Port 135 (MS-BLASTER) scans
3500
3000
2500
2000
Series1
1500
1000
500
0
• Date Public: 7/16/03 Date Attack: 8/11/03
M
ay
_
M 20
ay
_
M 21
ay
_
M 22
ay
_
M 24
ay
_
M 27
ay
_
M 27
ay
_
Ju 3 1
n_
Ju 0 2
n_
Ju 0 3
n_
Ju 0 5
n_
Ju 0 9
n_
Ju 1 3
n_
Ju 1 7
n_
Ju 2 1
n_
Ju 2 5
n_
3
Ju 0
l_
0
Ju 2
l_
0
Ju 6
l_
1
Ju 0
l_
1
Ju 4
l_
1
Ju 8
l_
2
Ju 1
l_
2
Ju 5
l_
A 29
ug
_
A 02
ug
_
A 06
ug
_
A 10
ug
_
A 14
ug
_
A 18
ug
_
A 22
ug
_
A 26
ug
_
S 31
ep
_
S 03
ep
_0
7
co
un
t
Honeynet Portscan Activity
Port 554 (RTSP) scans
3500
3000
2500
2000
Series1
1500
1000
500
0
• Date Public: 8/15/2003 Date Attack: 8/22/03