Transcript process

Intrusion Detection
“Intrusion detection is the process of
identifying and responding to malicious
activity targeted at computing and
networking resources.”
1
IDS vs. Surveillance Camera
•
•
•
•
2
Constant vigilance
Stealth Design
Infrastructure support
Adversary belief
Basic concepts
• Monitor
• Report
• Respond
3
The Seven Fundamentals
1.
2.
3.
4.
5.
6.
7.
4
What are the methods used
How are IDS organized
What is an intrusion
How do we trace and how do they hide
How do we correlate information
How can we trap intruders
Incident response
What are the methods used by
IDS?
• Audit trail processing
– Use log file from various processes
– Proper collection and consolidations of logs
• On-the-fly processing
– Mostly network based
– Looks at raw traffic
– Tries to find known “signatures”
5
What are the methods used by
IDS? (cont.)
• Profiles of normal behavior
– Estimation of initial behavior
– Fine-tuning
– Using out-of-band information
• Signatures of abnormal behavior
– Known attacks
– Suspicious patterns
• Parameter pattern matching or anomaly discovery
6
How are IDS organized
• Architecture
• CIDF
7
How are IDS organized (cont.)
• Sensor
• System Management (custom, SYSlog, SNMP,
…etc.)
• Processing (Analysis)
• Knowledge Bases
• Audits and Archives
• Alarms (Static and Dynamic)
• User interface (GUI, tail –f, …etc.)
8
What is an Intrusion
• Intrusion vs. attack
“Sequence of actions that maybe interleaved with
other unrelated actions”
9
How do we trace and how do
they hide
• In-band techniques
– May use cryptography, weaving approaches,
compromised systems, ..etc
• Out-of-band techniques
– Public access areas: Cyber cafes, telephony
techniques, ..etc.
10
How do we correlate information
• Single sessions and multiple session
correlation
• Real time vs. After the fact correlation
• In-band vs. all-band information
11
How can we trap intruders
• Real systems
• Trap systems
• IDS diverting
12
Incident response
• Ignore the problem, and hope it goes away
• Panic
• Consider the real factors:
–
–
–
–
–
–
13
Does the incident involve critical assets
Has it occurred before
It is still going on
Has damage occurred
What policies and procedures have been violated
Are traps available for use
Intrusion Detection Methods
“Intrusion detection is the process of
identifying and responding to malicious
activity targeted at computing and
networking resources.”
14
The Seven Fundamentals
1. What are the methods used
2.
3.
4.
5.
6.
7.
15
How are IDS organized
What is an intrusion
How do we trace and how do they hide
How do we correlate information
How can we trap intruders
Incident response
Some fundamental questions
• Are ID methods only suited for manual use
by experts?
• Are ID methods well defined enough to be
automated?
• What are some of the manual methods used
by experts?
• What ID methods are available in tools
today?
16
ID methods
•
•
•
•
Audit trail processing
On-the-fly processing
Profiles of normal behavior
Signatures of abnormal behavior
• Parameter pattern matching or anomaly discovery
Are the above methods independent? Dependant?
Mutually exclusive?
17
Audit Trail Processing
• Activities are first logged and stored in a log
file via audit probs.
• Audit probes are [mostly] selected based on
what constitutes security critical events.
• System and security administrators (and
designers) are changed with
enabling/disabling probs.
Auditing
What
are vs.
the Performance?
TCSEC requirements
What areforthe
Audit?
issues?
(See Page 40)
18
Case study: TCP logs
Internal net
(in)
Router/
Gateway
External net
(out)
log
<src_ip, dst_ip, src_port,
dst_port, protocol, time,
direction, status>
19
Case study: TCP logs (cont.)
<in,in, 4050, 80, tcp, 07:02:22, inbound, success>
<outx,gw, 6025, 23, tcp, 07:51:12, inbound, failure>
<outx,gw, 6025, 23, tcp, 07:51:55, inbound, failure>
<outx,gw, 6025, 23, tcp, 07:52:17, inbound, failure>
<outx,gw, 6025, 23, tcp, 07:52:58, inbound, failure>
.
.
.
<outx,in, 3000, 23, tcp, 13:04:22, inbound, success>
<outy,gw, 6025, 23, tcp, 23:54:22, inbound, success>
20
How much of the previous
discussion can be
automated?
21
Examples of things to watch for!
•
•
•
•
•
Users logging in at strange hours
Unexpected reboots or clock changes
Unusual error messages
Failed login attempts
Unauthorized use of the su command
• Users logging from unusual locations
22
Problems to be considered while
using logging systems
Most administrators don’t collect audits,
and if they do, they rarely process them!
23
Problems to be considered while
using logging systems (cont.)
• Large size of audit files
- About 5M per week for a workgroup
server
- Becomes more problematic for
centralized logging
24
Problems to be considered while
using logging systems (cont.)
• Degraded system performance
Reached 85% on some typical unix and NT
systems
http://www.iamsam.com/papers/thesis/thesis.htm
25
Problems to be considered while
using logging systems (cont.)
• Difficulty in protecting the log
- Log files growing smaller!
- Print everything
26
Problems to be considered while
using logging systems (cont.)
• Unknown storage duration of logs
How long should logs be kept?
How long are they kept on your linux
system?
27
Unix Syslog
• Syslogd is a daemon (background process)
• Receives message for the log file from:
– User processes running on the same mchaine (as
syslogd) via /dev/log
– Kernel routines (/dev/klog)
– Processes on another machine via UDP port 514
• Syslogd defines an associated API for application
authors
28
/etc/syslog.conf
# Log all kernel messages to the console.
# Logging much else clutters up the screen.
kern.*
/dev/console
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;news.none;authpriv.none
/var/log/messages
# The authpriv file has restricted access.
authpriv.*
/var/log/secure
# Log all the mail messages in one place.
mail.*
/var/log/maillog
# Everybody gets emergency messages, plus log them on another
# machine.
*.emerg
*
# Save mail and news errors of level err and higher in a
# special file.
uucp,news.crit
/var/log/spooler
29
/var/log/messages
F25
F25
F25
F25
F25
F25
F25
F25
F25
F25
F25
F25
F25
F25
F25
F25
F25
F25
F25
F25
F26
F26
F26
F26
21:37:44
21:40:00
21:42:18
21:50:01
21:51:24
21:52:27
22:00:00
22:01:00
22:10:00
22:20:01
22:30:00
22:40:01
22:50:00
23:00:00
23:01:01
23:10:01
23:20:00
23:30:00
23:40:00
23:50:01
00:00:00
00:01:01
00:10:00
30
00:20:01
rnd
rnd
rnd
rnd
rnd
rnd
rnd
rnd
rnd
rnd
rnd
rnd
rnd
rnd
rnd
rnd
rnd
rnd
rnd
rnd
rnd
rnd
rnd
rnd
PAM_pwdb[17775]: (sshd) session opened for user sherif by
CROND[17784]: (root) CMD (
/sbin/rmmod -as)
PAM_pwdb[17789]: (sshd) session opened for user sherif by
CROND[17813]: (root) CMD (
/sbin/rmmod -as)
PAM_pwdb[17789]: (sshd) session closed for user sherif
PAM_pwdb[17775]: (sshd) session closed for user sherif
CROND[17851]: (root) CMD (
/sbin/rmmod -as)
CROND[17856]: (root) CMD (run-parts /etc/cron.hourly)
CROND[17887]: (root) CMD (
/sbin/rmmod -as)
CROND[17969]: (root) CMD (
/sbin/rmmod -as)
CROND[17999]: (root) CMD (
/sbin/rmmod -as)
CROND[18034]: (root) CMD (
/sbin/rmmod -as)
CROND[18061]: (root) CMD (
/sbin/rmmod -as)
CROND[18087]: (root) CMD (
/sbin/rmmod -as)
CROND[18092]: (root) CMD (run-parts /etc/cron.hourly)
CROND[18123]: (root) CMD (
/sbin/rmmod -as)
CROND[18149]: (root) CMD (
/sbin/rmmod -as)
CROND[18175]: (root) CMD (
/sbin/rmmod -as)
CROND[18201]: (root) CMD (
/sbin/rmmod -as)
CROND[18228]: (root) CMD (
/sbin/rmmod -as)
CROND[18264]: (root) CMD (
/sbin/rmmod -as)
CROND[18269]: (root) CMD (run-parts /etc/cron.hourly)
CROND[18302]: (root) CMD (
/sbin/rmmod -as)
CROND[18352]: (root) CMD (
/sbin/rmmod -as)
/var/log/mail
F25 22:32:22 rnd sendmail[18009]: g1PKU1x18007:
to=<[email protected]>,
delay=00:02:21, xdelay=00:00:03, mailer=esmtp, pri=589605,
relay=mx2.mail.yahoo.com. [64.157.4.88],
dsn=2.0.0, stat=Sent (ok dirdel)
F25 22:32:42 rnd sendmail[18009]: g1PKU1x18007:
to=<[email protected]>,
delay=00:02:41, xdelay=00:00:20, mailer=esmtp, pri=589605,
relay=ob-mail-com.mr.outblaze.com. [205.158.62.26],
dsn=2.0.0, stat=Sent (g1PJVqt94451 Message accepted for delivery)
31
SWATCH
• Simple and effective tool
• Written in perl
/pattern/[, /pattern/] action[,action] duration
32
Case Study : Secureview Firewall-1
Audit
Intranet
Database
Builder
Firewall-1
log
Data
Mart
Admin
Module
Internet
Firewall-1
Reporting
Module
Other
Firewall-1
Log
Processing
Tools
SecureIT
SecureView
33
Security Administrator
Mar
2 23:53:51 148.63.149.144:1072 -> 208.160.134.38:1214 VECNA ****P***
Mar
2 23:54:33 148.63.149.144:1072 -> 208.160.134.38:1214 VECNA ****P***
Mar
2 23:55:39 148.63.149.144:1072 -> 208.160.134.38:1214 VECNA ****P***
Mar
2 23:56:44 148.63.149.144:1072 -> 208.160.134.38:1214 VECNA ****P***
Mar
2 23:57:50 148.63.149.144:1072 -> 208.160.134.38:1214 VECNA ****P***
Mar
2 23:58:49 148.63.149.144:1072 -> 208.160.134.38:1214 VECNA ****P***
Mar
3 00:00:00 148.63.149.144:1072 -> 208.160.134.38:1214 VECNA ****P***
Mar
3 00:01:01 148.63.149.144:1072 -> 208.160.134.38:1214 VECNA ****P***
Mar
3 00:02:05 148.63.149.144:1072 -> 208.160.134.38:1214 VECNA ****P***
Mar
3 00:03:11 148.63.149.144:1072 -> 208.160.134.38:1214 VECNA ****P***
Mar
3 00:04:14 148.63.149.144:1072 -> 208.160.134.38:1214 VECNA ****P***
34
35
36
On-the-fly processing
•
•
•
•
Timeliness
Processing method
Storage requirements
Information capacity
Target
System
Probe Ponts selected by
37system administrators
Direct system
feeds
Intrusion
Detection
System
on-the-fly
processing
Network management and NIDS
• Use SNMP and RMON (RFC 1271) as a
basis for ID collection and processing
–
–
–
–
38
Analyze traffic history and statistics
Examine network trends
initiate alarms
Traffic generation for testing
Netmetrix
Analysis applications
for trending, alarms,
analysis, display, etc
39
Enterprise
WAN(SNMP
transport)
LAN(Ethernet)
LanProbe
LAN(token ring)
Noninvasive
monitors
LanProbe
Case Study : NFR
Decision
Engine
Target
System
Packet
Sucker
Backend
Filter 1
Filter 2
Query
Backend
Filter 3
Filter N
GUI
Backend
Alert Manager
40
Methods for extracting traffic
from the network for processing
• In-line diversion of traffic by network
components
• Off-line extraction (passive sniffing)
– Most used: Ethernet promiscuous mode
– Other examples:
• Serial lines
• Wireless networks
• Tempest effect aka The van Eck effect
41
Case Study : BorderGuard Firewall Extraction
for NetRanger Processing
• NSX device : local intrusion Monitoring Function
Gateway Traffic
Protected
System
BorderGuard
Firewall
NSX
Intrusion
Detection
42
Target
System
Diverted Traffic for
NetRanger Intrusion
Detection
Normal Behavior profiling
Refine
Security
Administrator
Update
User
Profile
Knowledge Base
(Comparable users)
User Profiling Method
43
User
Activity
Normal Behavior profiling
• Initial profiling of new systems and users
based on estimations of expected behavior
• Observed user and system behavior should
be used to fine-tune profiles
• Information from other (external) resources
is used to improve the accuracy of
prediction
44
System Activity
Activity Observed
(audit log)
Activity Expected
(Profiles)
Compare and Respond
Concept of Profile-based Processing
45
Case study: IDES model
• Audit trail information is collected in
protected logs
• Profile based tools as used for off-line
analysis
System
Activity
Anomaly
Records
46
Audit
Trail
IDES
Processing
IDES Design
User/System
Profiles
Alarms
Case study: IDES model (cont.)
<subject, object, profiles, auditrecords, anomaly records, alarms>
• Subjects and Objects: from classical
INFOSEC view of the initiator and the
target of an activity
47
Case study: IDES model (cont.)
• Profile: Characterization of behavior
• Audit records: the data structures used to
capture the system’s observed behavior
• Anomaly records: the data structures used
to capture anomalous behavior
• Alarms: problem reporting methods
48
Toll fraud and similar problems
• How can toll fraud-like problems be solved
using “Normal Behavior profiling?”
• How about credit card fraud?
• Phone card fraud?
49
http://www.atcomm.com/advisor/basics/call-account.htm
• Boost Security
50
– Highlight Suspicious Activity and Review
Unrecognizable Call Data for Hacker Detection
– Prevent/Locate Unauthorized System Access
– Real Time Notification of Exception Calling
– Track After Hours Security Guards
– Detect Bomb Threats
– Selective Reporting/Display for Top Secret/Sensitive
Materials
– Account for Calls But Delete Detail (Call Processing)
– Password Security to Prevent Moving from Call
Processing
– Keyboard Macro Available to Provide Additional
Security
The Abnormal Behavior (Attack)
Signature Method
• Commonly used in on-the-fly IDS
• Attack signatures
– May require temporal and state machine like
modeling
• Special character strings
– E.g.: /etc/password in an ftp session
51
Target
System
Probe
Point
Strings
Feed
Selected via
traffic content
modeling of attack
52
Intrusion
Detection
Systems
Profiles
Selected via
activity sequence
modeling of attack
Should correlate
string and profile
based processing
Case Study: SNORT rules
• http://www.snort.org/docs/writing_rules/
53
alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP .forward"; content:
".forward"; flags: A+;reference:arachnids,319; classtype:suspiciousfilename-detect; sid:334; rev:2;)
alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP .rhosts";flags: A+;
content:".rhosts"; reference:arachnids,328; classtype:suspiciousfilename-detect; sid:335; rev:2;)
alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP CWD ~root";
content: "cwd ~root"; nocase; flags: A+;reference:arachnids,318;
classtype:bad-unknown; sid:336; rev:1;)
alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP EXPLOIT aix
overflow";flags: A+;dsize:>1300; content:"CEL "; reference:arachnids,257;
classtype:attempted-admin; sid:337; rev:1;)
alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP EXPLOIT format
string"; flags: A+; content: "SITE EXEC |25 30 32 30 64 7C 25 2E 66 25 2E
67 6C 0A|"; depth: 32; nocase; reference:arachnids,453;
classtype:attempted-user; sid:338; rev:1;)
54
Parameter pattern matching or
anomaly discovery
• Based on continuous monitoring of network
and systems attributes
• The monitoring is not necessary security
focused
• The use of day-to-day operational
experience and the basis for detecting
anomalies
55
Intrusion
Detection
System
Target
System
(network,
OS,applicat
ion, etc
Noarmal
Operations
These monitoring
operations may
not be disciplined
or predictable
56
Operational View
(Patterns)
Normal system
Operation and
Administration
Interpretations
of Patterns
(intrusion
detection)
This
interpretation
is triggered by
and
detection of
change
from normal
57
58
59
60
61
62
63
recent criticism of intrusion detection
method
•
•
•
•
•
•
64
on the fly traffic interpretation problem
server audit interpretation problem
fail-open nature of intrusion detection
intrusion detection methods may be vulnerable to insertion attacks
intrusion detection methods may be vulnerable to evasion attacks
Intrusion detection methods may be vulnerable to denial of service
attacks
Intrusion Detection Methods
“Intrusion detection is the process of
identifying and responding to malicious
activity targeted at computing and
networking resources.”
65
The Seven Fundamentals
1. What are the methods used
2. How are IDS Organized
3.
4.
5.
6.
7.
66
What is an intrusion
How do we trace and how do they hide
How do we correlate information
How can we trap intruders
Incident response
The Major components of IDS
•
•
•
•
•
•
•
•
•
67
•
Target System
Feed
Processing
Knowledge base
Storage
Alarms
Operator interface
Communications infrastructure
Multiple IDS
Network management
GUI
Target
System
Feed
Processing
Alarms/
Directives
System
Management
KB
Storage
Communcations Infrastucture
IDS
Target
System
IDS
Network
Managment
Target
System
68
Text book: figure 3-1
Major components of IDS (cont.)
• Target System
– Important networks and systems!
• Feed
– Information collected from the target systems
and sent back for processing
– Q: should feeds carry raw traffic back to the
processing system? Should they carry alarms?
What are the considerations?
69
Major components of IDS (cont.)
• Processing
– The execution of the detection algorithms
• Knowledge Base
– Used to store information about attacks, user
profiles, ..etc.
– Ability to update is an important issue
• Storage
– Short term vs. long term storage
– Performance and capacity issues
70
Major components of IDS (cont.)
• Alarms and Directives
– Various types of configurable alarms and notification
methods are typically supported
– Increasing trend towards using them for automatic
reconfiguration of other network components (See
CIDF for messaging model)
• Communications infrastructure
– Used for communications between IDS components
– Security needs?
71
Major components of IDS (cont.)
• Multiple IDS
– Common in many environments
– The need for secure integration
• Network management
– Integration and interaction issues
72
IDS processing
• Processing components in IDS include:
– Engines
• Filters
• Set of autonomous agents each performing a
specified task
– Management
– Correlation
• Combine results!
• Interface with other components
73
IDS algorithms
• Baseline processing
while (true) {
target_system_feed(info);
intrusion_processing(info, results);
If (result == intrusion)
initiate_response(result);
}
74
IDS algorithms (cont.)
• Dynamic association
while (true){
target_system_feed(info);
if (suspicious(info) && new(info))
create new association
if(suspicious(info)&& not new(info))
add to existing association
}
75
IDS algorithms (cont.)
• Audit trail data reduction
– Loop over log records
• Consider combinations of records
• Check if they are relevant to current incident
– Append to report
• Other types of data reduction?
76
IDS algorithms (cont.)
• Out-of-band correlation processing
while (true){
target_system_feed(info);
if (OOB_data)
get_OOB(operator_input);
if(relevant(info, operator_input)
combine(info, operator_input);
}
77
IDS algorithms (cont.)
• Attack filter pattern matching
while (true){
target_system_feed(info);
For (i=0; i< NumFilters; i++)
if (match(filter[i], info))
AttackFound(i)
}
78
IDS Knowledge Base
•
•
•
•
79
Profiles of normal and abnormal behavior
Attack signatures
Suspicious traffic patterns / strings
Information used to initiate responses and
actions
IDS
Target
System
Processing
Feed
System
Management
user
profiles
system
profiles
Storage
other
attack
response
signatures actions static info
Knowledge Bases
80
Alarms/
Directives
GUI/
Operator
Interface
IDS Storage
• Archives
• IDS logs
• Dynamic buffer
• The case of Oklahoma bank Camera
• The case of the Cuckoo's Egg
81
IDS
Target
System
Processing
Feed
System
Management
Alams/
Directives
Knowledge
Base
audit
log
archive
buffer
Intrusion Detection Storage
82
GUI/
Operator
Interface
CIDF
• Architectural conventions
• Message specifications (GIDO: generalized
ID objects)
• Transmission standards for sending GIDOs
between components
• Communications protocol for CIDF
components
• API for CIDF
83
CIDF
•
•
•
•
Event generator (E-Box)
Analysis Engine (A-box)
Storage (D-Box)
Response component (R-Box)
http://www.isi.edu/~brian/cidf/
http://www.isi.edu/~brian/cidf/drafts/architecture.txt
84
Intrusion Detection Methods
“Intrusion detection is the process of
identifying and responding to malicious
activity targeted at computing and
networking resources.”
85
The Seven Fundamentals
1. What are the methods used
2. How are IDS Organized
3. What is an intrusion
4.
5.
6.
7.
86
How do we trace and how do they hide
How do we correlate information
How can we trap intruders
Incident response
What is an intrusion?
87
What is an intrusion
A sequence of related actions by a
malicious adversary that results in an
occurrence of unauthorized security
threats to a target computing or network
domain.
88
Temporal models of Intrusions
89
Neumann—Parker Taxonomy of
Intrusions
• NP1: External misuse indicator
– OOB indicators
• NP2: Hardware misuse indicators
• NP3: Masquerading indicators
• NP4: Subsequent misuse indicators
– Plans, backdoors, or bugs
• NP5: Control bypass indicator
– Users finding a way around a firewall (icq?)
90
NP Taxonomy of Intrusions (cont.)
• NP6: Active Resource misuse indicator
- unknown users on your system
• NP7:Passive resource misuse indicator
- Users or systems know things they have no way of
knowing without listening to others conversations
• NP8: misuse via inaction indicators
- Defensive measure not working. Things that should
have been prevented are not!
• NP9: Active Resource misuse indicator
- System being used to brute force passwords offline
91
How are intrusions indicated
• The role of indication and warning (I&W)
• Some evidence based indicators:
–
–
–
–
–
–
–
–
92
Repetition
Mistyped commands in an automated session
Exploitation on known vulnerabilities
Directional inconsistencies in traffic
Unexpected attributes of traffic
Unexplained problems
Out of band knowledge about intrusions
Suspicious character traffic on a network
Repetition
• Repetition thresholds
• Time between repeat instances
• Repetitive patterns: what is being repeated!
• Example:
– Syn flood
– EHLO DOS
93
Mistyped commands in an
automated sessions
• Human typing vs program output
– ^H^H
– Failed attempts followed by successful ones
– Incremental learning/corrections
• Example:
– Bedford at AT&T
94
Exploitation on known
vulnerabilities
• Detecting the scanning tools
• Detecting the signature
• Correlation between scanning and
exploitation
95
Intrusion Detection Methods
“Intrusion detection is the process of
identifying and responding to malicious
activity targeted at computing and
networking resources.”
96
The Seven Fundamentals
1. What are the methods used
2. How are IDS Organized
3. What is an intrusion
4. How do we trace and how do they
hide
5. How do we correlate information
6. How can we trap intruders
7. Incident response
97
It is possible to associate a packet
with a human initiator?
98
Why is hiding on the Internet
easy?
• Spoofed source
addresses
• Changing installed
address
• Dynamic address
allocation
• Anonymous entry
points
• Anonymizing services
99
• Daisy-chain
connections
• Cryptographic
anonymity
• Hacker advice
Self test
• Please read Blind signature based E-cash,
Page 133
• Next class:
– What are the possible attacks on this scheme?
– Build the associated attack tree
100
The trace back workbench
•
•
•
•
•
•
•
101
Finger
Ph
Ping
Traceroute
Rusers
Nslookp/Dig/host
Whois
• Phone records and
caller id
• Internet directories
• Reverse hacking!
• Traceback traps
Self test
• Please read “Internet Cookies,” Page 140
• Next class:
– Discussion on the cookies issue.
102
Intrusion Detection Methods
“Intrusion detection is the process of
identifying and responding to malicious
activity targeted at computing and
networking resources.”
103
The Seven Fundamentals
1.
2.
3.
4.
What are the methods used
How are IDS Organized
What is an intrusion
How do we trace and how do they hide
5. How do we correlate information
6. How can we trap intruders
7. Incident response
104
Intrusion correlation
• Refers to the interpretation, combination,
and analysis of information from all
available sources.
105
Statistical correlation
•
•
•
•
Variables
Change
Trends
Calculations: Mean, standards deviation, zscore (distance between values/stand dev)
• Predictive techniques
• Curve-fitting
106
Intrusion correlation
• Single and Multiple Correlation of Packets
– IP Address, Port, Protocol
• Real Time and after-the-fact correlation of
Information
• In-band vs. all-band correlation of available
information
107
Early warning using Statistical
Process Controls (SPC):
• We parsed snort logs from the period of April
2000 through January 2001.
• For each of the top ten snort rules reported on, we
calculated the number of times each rule was
reported each day.
• Next, we calculated the three day moving average
(3DMA) of each reported rule, and plotted on a
control chart the number of reports for each rule
set each day, and the 3DMA.
• Control limits were calculated by obtaining the
108 standard deviation of the average over the period,
and multiplying times 2 (2-sigma control limits).
109
110
Intrusion Detection Methods
“Intrusion detection is the process of
identifying and responding to malicious
activity targeted at computing and
networking resources.”
111
The Seven Fundamentals
1.
2.
3.
4.
5.
What are the methods used
How are IDS Organized
What is an intrusion
How do we trace and how do they hide
How do we correlate information
6. How can we trap intruders
7. Incident response
112
Internet Trap
• A set of functional and procedural
components that use legal and authorized
deception to divert the activity of potential
intruder from real valued asset to bogus
assets (and vice versa) for the purpose of
gathering intrusion related information
and initiating response.
113
Technical considerations
•
•
•
•
Detecting the intruder
Detecting the trigger
Reversing decision about activity
Remain Stealth
Real system
Real system
Trap
114
Types of Internet Traps
• Real environment with trap elements
– Unix system with fake password file
– Win2K with phony open shares
– Web servers with phony vulnerable CGIs
• Small environment to large trap
• Large environment to small trap
• Mirrored environment and trap
– Trap serves as hot stand by system
115
Design considerations
• Proper design
– Advisory notice
– Keep the intruder in mind (what would cs485
students like to break into?)
– Don’t be too obvious
– Software tools as gifts
116
Design considerations (cont.)
• Bait
–
–
–
–
Administrator correspondence
Rigged email
Rigged scan points
System messages
• OOB Traps
• Legal considerations
117
Intrusion Detection Methods
“Intrusion detection is the process of
identifying and responding to malicious
activity targeted at computing and
networking resources.”
118
The Seven Fundamentals
1.
2.
3.
4.
5.
6.
What are the methods used
How are IDS Organized
What is an intrusion
How do we trace and how do they hide
How do we correlate information
How can we trap intruders
7. Incident response
119
The Emergency Action Card
When a computer security incident occurs, and you are not
prepared, follow these ten steps:
Emergency Step 1.
Remain calm.
Even a fairly mild incident tends to raise
everyone's stress level. Communication and
coordination become difficult. Your calm can
help others avoid making critical errors.
120
http://www.sans.org/newlook/publications/incident_handling.htm
Emergency Step 2.
Take good notes.
Make sure you answer the four Ws - Who, What,
When, and Where- and, for extra credit, How
and Why.
121
http://www.sans.org/newlook/publications/incident_handling.htm
Emergency Step 3.
Notify the right people and get help.
Begin by notifying your security coordinator
and your manager and asking that a coworker
be assigned to help coordinate the incident
handling process. Get a copy of the corporate
phonebook and keep it with you. Ask your
helper to keep careful notes on each person
with whom he or she speaks and what was said.
Make sure you do the same.
122
http://www.sans.org/newlook/publications/incident_handling.htm
Emergency Step 4.
Enforce a "need to know" policy.
Tell the details of the incident to the
minimum number of people possible. Remind
them, where appropriate, that they are
trusted individuals and that your
organization is counting in their discretion.
Avoid speculation except when it is required
to decide what to do. Too often the initial
information in an incident is misinterpreted
and the "working theory" has to be scrapped.
123
http://www.sans.org/newlook/publications/incident_handling.htm
Emergency Step 5.
Use out of band communications.
If the computers may have been compromised,
avoid using them for incident handling
discussions. Use telephones and faxes
instead. Do not send information about the
incident by electronic mail, talk, chat, or
news; the information may be intercepted by
the attacker and used to worsen the
situation. When computers are being used,
encrypt all incident handling e-mail.
124
http://www.sans.org/newlook/publications/incident_handling.htm
Emergency Step 6.
Contain the problem.
Take the necessary steps to keep the problem
from getting worse. Usually that means
removing the system from the network, though
management may decide to keep the connections
open in an effort to catch an intruder.
125
http://www.sans.org/newlook/publications/incident_handling.htm
Emergency Step 7.
Make a backup of the affected system(s) as
soon as practicable.
Use new, unused media. If possible make a
binary, or bit-by-bit backup.
126
http://www.sans.org/newlook/publications/incident_handling.htm
Emergency Step 8.
Get rid of the problem.
Identify what went wrong if you can. Take
steps to correct the deficiencies that
allowed the problem to occur.
127
http://www.sans.org/newlook/publications/incident_handling.htm
Emergency Step 9.
Get back in business.
After checking your backups to ensure they
are not compromised, restore your system from
backups and monitor the system closely to
determine whether it can resume its tasks.
128
http://www.sans.org/newlook/publications/incident_handling.htm
Emergency Step 10.
Learn from this experience, so you won't get
caught unprepared the next time an incident
occurs.
129
http://www.sans.org/newlook/publications/incident_handling.htm
Incident response
• The real-time decisions and actions of
asset managers that are intended to
minimize incident related effects on their
assets and to mitigate residual security risk
based on available evidence from the
incident.
130
Incident Response factors
• Soft factors
– Management policies
– Organizational
structure
– Administrative
procedures
131
• Hard factors
– IDS
– Traps
– Trace back tools
Incident Response Process
em d
st re
Sy st o
e
R
132
ID
Process
onse
Resp ted
Initia
R es
Com ponse
plet
ed
Incident
Detected
th
i
tw
c
ra tem
e
t
I n Sy s
Response
• Human initiated response
• Automatically initiated response
• Coordinated Human & Automatic response
133
Factors influencing Response
• Passive factors
– What assets have been affected or damaged by
the incident
– How did the incident occur
– How was it detected
– How trustworthy is the incident related
information
134
Factors influencing Response
• Active factors
– What would the effect of altering the target
system’s functionality
– What would the effect of initiating trace backs
and traps
– What would the effect of doing nothing
– How legal is the response
135
Robin Hood and Friar Tuck
!X id1
id1: Friar Tuck... I am under attack!
Pray save me!
id1: Off (aborted)
id2: Fear not, friend Robin!
Sherif of Nottingham's men!
I shall rout the
id1: Thank you, my good fellow!
Each ghost-job would detect the fact that the other had been
killed, and would start a new copy of the recently slain program
within a few milliseconds. The only way to kill both ghosts was
to kill them simultaneously (very difficult) or to deliberately
crash the system.
136
http://www.tuxedo.org/~esr/jargon/
Examples
• Real secure + Firewall-1
• Snort + IP-tables
137
Other issues!
138
Attack trees
139
140
141
142
143
144
145
146
147
148
DOS attacks
149
150
151
152
Managing the Threat of
Denial-of-Service Attacks
CERT® Coordination Center
Allen Householder, CERT/CC
Art Manion, CERT/CC
Linda Pesante, CERT/CC
George M. Weaver, CERT/CC
In collaboration with:
Rob Thomas
v10.0
153
October 2001
In general, systems and networks can be engineered to respond to a
DoS attack by doing one of these things:
•Absorb the attack. This implies that additional capacity has
already been planned for, installed, and tested before an attack
begins.
•Degrade services. Once the critical services have been
identified, it may be possible to design the network, systems,
and applications in such a way that noncritical services can be
degraded in favor of keeping critical services functional through
an attack.
•Shut down services. It is plausible that an organization could
decide to simply shut down all services until an attack has
subsided.
154
Protecting a network and systems from DoS attacks centers
around three topics:
a) Designing the network and systems for survivability
b) Monitoring ongoing operations – knowing what’s
“normal” for your network so that you can detect changes to
this normal behavior
c) Preparing the organization in nontechnical ways so
personnel are prepared to react effectively
155
a. Designing for Survivability
general principles that apply to the survivability objective:
•Separate, or compartmentalize, critical services wherever practical.
• Overprovision as much as possible. Have more capacity tha n you
need
• Minimize your “target cross-section.”
156
Tracing Network Attacks to
Their Sources
http://
dlib.computer.org/ic/books/ic2002/pdf/w2020.pdf
www.computer.org/internet/ic2002/w2toc.htm
157
158
159
Tracing Network Attacks to
Their Sources
The major components of [the] traceback system are
the sensor, monitoring manager, and tracer.
– The sensor, which is deployed at a target site, monitors
packets on the network. When it detects an attack, the
sensor sends a tracing request to the monitoring
manager.
– In response to a sensor request, the monitoring manager
controls tracers and manages the entire tracing process.
– The tracer, which is implemented in forwarding nodes
such as routers, maintains log information about
forwarded IP packets. The tracer also compares the log
data with information about the tracing packet and finds
a trace path.
160
Process Flow
– 1. Sensors are deployed at each target network. When a
sensor detects an attack, it creates data containing
features of the attack packet and sends a tracing request
to the monitoring manager deployed in its AMN.
– 2. The monitoring manager orders the AMN’s tracer to
trace the attack packet. The tracer identifies the adjacent
node and returns the result to the monitoring manager.
– 3. Based on the result returned, the process described
above continues until the tracer identifies the attack
packet’s source.
– 4. If a tracing process goes beyond the AMN’s boundary,
processing is handed over to the relevant monitoring
manager (the commissioned monitoring manager) that
controls that AMN.
– 5. The monitoring managers in each AMN trace the packet
in their AMN and send the tracing results to the monitoring
manager that initiated the traceback request (the requester
161
monitoring manager).
162
163
SPOOFING
164
From: [email protected] (Tsutomu Shimomura)
Newsgroups:
Subject:
Date:
Organization:
Keywords:
165
comp.security.misc,
comp.protocols.tcp-ip,
alt.security
Technical details of the attack
described by Markoff in NYT
25 Jan 1995 04:36:37 -0800
San Diego Supercomputer Center
IP spoofing,
security,
session hijacking
The IP spoofing attack started at about 14:09:32 PST on
12/25/94. The first probes were from toad.com (this info
derived from packet logs):
14:09:32toad.com# finger -l @target
14:10:21toad.com# finger -l @server
14:10:50toad.com# finger -l root@server
14:11:07toad.com# finger -l @x-terminal
14:11:38toad.com# showmount -e x-terminal
14:11:49toad.com# rpcinfo -p x-terminal
14:12:05toad.com# finger -l root@x-terminal
The apparent purpose of these probes was to determine if
there might be some kind of trust relationship amongst these
systems which could be exploited with an IP spoofing attack.
The source port numbers for the showmount and rpcinfo
indicate that the attacker is root on toad.com.
166
About six minutes later, we see a flurry of TCP SYNs (initial
connection requests) from 130.92.6.97 to port 513 (login) on
server. The purpose of these SYNs is to fill the connection
queue for port 513 on server with "half-open" connections so it
will not respond to any new connection requests. In particular,
it will not generate TCP RSTs in response to unexpected SYN-ACKs.
As port 513 is also a "privileged" port (< IPPORT_RESERVED),
server.login can now be safely used as the putative source for an
address spoofing attack on the UNIX "r-services" (rsh, rlogin).
130.92.6.97 appears to be a random (forged) unused address (one
that will not generate any response to packets sent to it):
14:18:22.516699 130.92.6.97.600 > server.login: S 1382726960:1382726960(0) win
4096 14:18:22.566069 130.92.6.97.601 > server.login: S 1382726961:1382726961(0)
win 4096 14:18:22.744477 130.92.6.97.602 > server.login: S
1382726962:1382726962(0) win 4096 14:18:22.830111 130.92.6.97.603 > server.login:
S 1382726963:1382726963(0) win 4096 14:18:22.886128 130.92.6.97.604 >
server.login: S 1382726964:1382726964(0) win 4096
167
14:18:22.943514 130.92.6.97.605 > server.login: S 1382726965:1382726965(0) win
4096 14:18:23.002715 130.92.6.97.606 > server.login: S 1382726966:1382726966(0)
win 4096 14:18:23.103275 130.92.6.97.607 > server.login: S
1382726967:1382726967(0) win 4096 14:18:23.162781 130.92.6.97.608 > server.login:
S 1382726968:1382726968(0) win 4096 14:18:23.225384 130.92.6.97.609 >
server.login: S 1382726969:1382726969(0) win 4096 14:18:23.282625 130.92.6.97.610
> server.login: S 1382726970:1382726970(0) win 4096 14:18:23.342657
130.92.6.97.611 > server.login: S 1382726971:1382726971(0) win 4096
14:18:23.403083 130.92.6.97.612 > server.login: S 1382726972:1382726972(0) win
4096 14:18:23.903700 130.92.6.97.613 > server.login: S 1382726973:1382726973(0)
win 4096 14:18:24.003252 130.92.6.97.614 > server.login: S
1382726974:1382726974(0) win 4096 14:18:24.084827 130.92.6.97.615 > server.login:
S 1382726975:1382726975(0) win 4096 14:18:24.142774 130.92.6.97.616 >
server.login: S 1382726976:1382726976(0) win 4096 14:18:24.203195 130.92.6.97.617
> server.login: S 1382726977:1382726977(0) win 4096 14:18:24.294773
130.92.6.97.618 > server.login: S 1382726978:1382726978(0) win 4096
……
14:18:25.653131 130.92.6.97.629 > server.login: S 1382726989:1382726989(0) win
4096
server
168generated SYN-ACKs for the first eight SYN requests before
the connection queue filled up. server will periodically
We now see 20 connection attempts from apollo.it.luc.edu to xterminal.shell. The purpose of these attempts is to determine
the behavior of x-terminal's TCP sequence number generator.
Note that the initial sequence numbers increment by one for
each connection, indicating that the SYN packets are *not*
being generated by the system's TCP implementation. This
results in RSTs conveniently being generated in response to
each unexpected SYN-ACK, so the connection queue on x-terminal
does not fill up:
14:18:25.906002 apollo.it.luc.edu.1000 > x-terminal.shell: S 1382726990:1382726990(0) win 4096
14:18:26.094731 x-terminal.shell > apollo.it.luc.edu.1000: S 2021824000:2021824000(0) ack
1382726991 win 4096
14:18:26.172394 apollo.it.luc.edu.1000 > x-terminal.shell: R 1382726991:1382726991(0) win 0
14:18:26.507560 apollo.it.luc.edu.999 > x-terminal.shell: S 1382726991:1382726991(0) win 4096
14:18:26.694691 x-terminal.shell > apollo.it.luc.edu.999: S 2021952000:2021952000(0) ack
1382726992 win 4096
14:18:26.775037 apollo.it.luc.edu.999 > x-terminal.shell: R 1382726992:1382726992(0) win 0
14:18:26.775395 apollo.it.luc.edu.999 > x-terminal.shell: R 1382726992:1382726992(0) win 0
14:18:27.014050 apollo.it.luc.edu.998 > x-terminal.shell: S 1382726992:1382726992(0) win 4096
14:18:27.174846 x-terminal.shell > apollo.it.luc.edu.998: S 2022080000:2022080000(0) ack
1382726993 win 4096
14:18:27.251840 apollo.it.luc.edu.998 > x-terminal.shell: R 1382726993:1382726993(0) win 0
14:18:27.544069 apollo.it.luc.edu.997 > x-terminal.shell: S 1382726993:1382726993(0) win 4096
14:18:27.714932 x-terminal.shell > apollo.it.luc.edu.997: S 2022208000:2022208000(0) ack
169 win 4096
1382726994
14:18:27.794456 apollo.it.luc.edu.997 > x-terminal.shell: R 1382726994:1382726994(0) win 0
14:18:26.094731 x-terminal.shell >
apollo.it.luc.edu.1000: S 2021824000:20218240
)0(00 ack 1382726991 win 4096
14:18:26.694691 x-terminal.shell >
apollo.it.luc.edu.999: S 2021952000:202195200
)0(0 ack 1382726992 win 4096
Note that each SYN-ACK packet sent by x-terminal has an initial
sequence number which is 128,000 greater than the previous one.
170
2021952000
2021824000
128000
We now see a forged SYN (connection request), allegedly from
server.login to x-terminal.shell. The assumption is that xterminal probably trusts server, so x-terminal will do whatever
server (or anything masquerading as server) asks.
x-terminal then replies to server with a SYN-ACK, which must be
ACK'd in order for the connection to be opened. As server is
ignoring packets sent to server.login, the ACK must be forged as
well.
Normally, the sequence number from the SYN-ACK is required in
order to generate a valid ACK. However, the attacker is able to
predict the sequence number contained in the SYN-ACK based on the
known behavior of x-terminal's TCP sequence number generator, and
is thus able to ACK the
SYN-ACK without seeing it:
14:18:36.245045 server.login > x-terminal.shell: S 1382727010:1382727010
(0) win 4096
14:18:36.755522 server.login > x-terminal.shell: . ack
win 4096
171
2024384001
The spoofing machine now has a one-way connection to xterminal.shell which appears to be from server.login. It can
maintain the connection and send data provided that it can
properly ACK any data sent by x-terminal. It sends the
following:
14:18:37.265404 server.login > x-terminal.shell: P 0:2(2) ack 1 win 4096
14:18:37.775872 server.login > x-terminal.shell: P 2:7(5) ack 1 win 4096
14:18:38.287404 server.login > x-terminal.shell: P 7:32(25) ack 1 win4096
which corresponds to:
14:18:37 server# rsh x-terminal "echo + + >>/.rhosts"
Total elapsed time since the first spoofed packet:
< 16 seconds
172
The spoofed connection is now shut down:
14:18:41.347003 server.login > x-terminal.shell: . ack 2 win 4096
14:18:42.255978 server.login > x-terminal.shell: . ack 3 win 4096
14:18:43.165874 server.login > x-terminal.shell: F 32:32(0) ack 3 win 4096
14:18:52.179922 server.login > x-terminal.shell: R 1382727043:1382727043(0) win
4096
14:18:52.236452 server.login > x-terminal.shell: R 1382727044:1382727044(0) win
4096
173
We now see RSTs to reset the "half-open" connections and
empty the connection queue for server.login:
14:18:52.298431 130.92.6.97.600 > server.login: R
1382726960:1382726960(0) win 4096
14:18:52.363877 130.92.6.97.601 > server.login: R
1382726961:1382726961(0) win 4096
14:18:52.416916 130.92.6.97.602 > server.login: R
1382726962:1382726962(0) win 4096
14:18:52.476873 130.92.6.97.603 > server.login: R
1382726963:1382726963(0) win 4096
14:18:52.536573 130.92.6.97.604 > server.login: R
1382726964:1382726964(0) win 4096
.
.
.
174
server.login
can again accept connections.
After root access had been gained via IP address spoofing,
a kernel module
named "tap-2.01" was compiled and installed on x-terminal:
x-terminal% modstat
Id Type Loadaddr
Mod Name
1 Pdrv ff050000
tap/tap-2.01 alpha
Size
1000
x-terminal% ls -l /dev/tap
crwxrwxrwx 1 root
37,
B-major
C-major
Sysnum
59.
59 Dec 25 14:40 /dev/tap
This appears to be a kernel STREAMS module which can be
pushed onto an existing STREAMS stack and used to take
control of a tty device. It was used to take control of
an already authenticated login session to target
at about 14:51 PST.
175
SQLI
176
SQL Injection!
<%@ LANGUAGE="VBSCRIPT" %>
<%
Dim oCONv, oRSu
Set oCONv = Server.CreateObject("ADODB.Connection")
oCONv.Open
"DRIVER={SQLServer};SERVER=aeneas;UID=sa;PWD=;DATABASE=paper"
Set oRSu = oCONv.Execute("SELECT * FROM tblUsers WHERE username = '" &
Request.Querystring("UserID") & "' AND password = '" &
Request.Querystring("Password") & "'")
if not oRSu.EOF then
Session("UserID") = oRSu ("username")
Response.Redirect "loginsucceeded.asp"
else
Response.Redirect "loginfailed.asp"
end if
%>
177
SELECT * FROM tblUsers WHERE username = 'foo' AND password =
'bar'
http://server/login.asp?userid='%20or%201=1--
SELECT * FROM tblUsers WHERE username = '' or 1=1--
178