Intrusion Detection Systems (IDS)
Intrusion Detection Systems (IDS)
•
What is an IDS?
–
Definition
–
Characteristics
–
Examples of existing IDS
What is an IDS?
•
Definition:
–
A piece of software
–
Monitors a computer system to detect:
•
Intrusion
: unauthorized attempts to use the system
•
Misuse
: abuse of existing privileges
–
Responds:
•
Log activity
•
Notify a designated authority
•
Take appropriate countermeasures
Why Use an IDS?
•
Security is often expensive/cumbersome:
–
Cost
–
Restrictions on users/functionality
•
Designers try to offer users “reasonable” levels of security
•
Security breaches will still occur
•
Detection allows:
–
Finding and fixing the most serious security holes
–
Perhaps holding intruders responsible for their actions
–
Limiting the amount of damage an attacker can do
Goals of an IDS
•
Run continually
•
Be fault tolerant
•
Resist subversion
•
Minimize overhead
•
Be easily configurable
•
Cope with changing system behavior
•
Be difficult to fool
–
Minimize
false positives
and
false negatives
Intrusion Detection Systems
•
Three main components of an IDS:
–
Information source – provides a stream of event
records
–
Analysis engine – finds signs of intrusions
–
Response component – generates reactions
•
What is the best information source for
intrusion detection?
Information Sources
•
Host-based
–
Operating System audit trails/system logs
–
Application information
•
Examples: database audit records, web server logs
•
Network-based
–
Network packets
–
Network devices
•
Security appliances
–
Firewall
–
Access control system
IDS Characteristics
•
Detection Model
–
Misuse detection vs. anomaly detection
•
Scope
–
Host based, multihost based, network based
•
Operation
–
Off-line vs. real-time
•
Architecture
–
Centralized vs. distributed
IDS Detection Model
•
Misuse detection
- recognize known attacks
–
Define a set of attack
signature
s
–
Detect actions that match a signature
–
Add new signatures often
•
Anomaly detection
- recognize atypical behavior
–
Define a set of metrics for the system
–
Build a statistical model for those metrics during “normal”
operation
–
Detect when metrics differ significantly from normal
•
Hybrid
IDS Scope
•
Host based
–
Scrutinize data from a single host
•
Multihost based
–
Analyze data from multiple hosts
•
Network based
–
Examine network traffic (and possibly data from the
connected hosts)
Case Study: Tripwire
•
A file integrity-checking tool
–
Developed at Purdue university (released in 1993)
–
Off-line, centralized, host-based, misuse detection
–
Utilizes digital signatures to check for added, deleted,
modified files
–
Popular
•
Portable
•
Configurable
•
Scalable
•
Manageable
•
Automated
•
Secure
Background – File Systems
•
Provide long-term storage for:
–
User data and programs
–
System programs and databases
•
A popular target for attackers:
–
Unauthorized access to user or system files to uncover private
information
–
Modify system databases to allow future entry (e.g. SAM
database)
–
Modify system programs to allow future entry (e.g. back doors)
–
Cleansing of system logs to thwart detection
Tripwire - Overview
•
A
checklist
is created which contains one entry for each
file being monitored
•
Checklist should:
–
Be secure against unauthorized modifications
•
Each entry in the checklist is a
fingerprint
for the
corresponding file
•
Fingerprints should:
–
Be efficient to compute
–
Be hard to invert
–
Depend on the entire contents of the file
–
Be very likely to change if the file changes
–
Be very unlikely to match fingerprints from other files
Tripwire – Overview (cont)
Tripwire Database
•
Unencrypted and world-readable
•
To prevent the database from being tampered with,
it is recommended it be:
–
Installed and updated in a secure manner (e.g. single-
user mode)
–
Stored either:
•
On a read-only media
•
On a write-protected disk
•
On a “secure server” (e.g. read-only NFS)
Tripwire Configuration Files
•
Contains:
–
A list of directories (or files) to be monitored
–
A
mask
for each that describes which attributes can change without being reported
•
Mask bits (all fields stored in a file’s inode):
–
p: permissions
–
i: inode number
–
n: number of links
–
u: user id
–
g: group id
–
s: size of file
–
m: modification timestamp
–
a: access timestamp
–
[1-10]: signature #1, signature #2, etc.
•
Signature algorithms supported (MD5, MD4, MD2, Snefru, SHA, CRC-32, CRC-16)
Tripwire Configuration Files
(cont)
•
Using masks:
–
Fields can be added (“+”) or subtracted (“-”) from the set of items
to be examined for a file
–
Example: +pinugsm12-a = report changes to all fields except
access timestamp
•
Mask templates:
–
R = +pinugsm12-a = read-only files; only access timestamp is
ignored
–
L = +pinug-sma12 = log files; changes to file size, access time,
modification time, and signatures are ignored
–
N = +pinugsma12 = ignore nothing
–
E = -pinugsma12 = ignore everything
Tripwire Configuration File -
Example
# file/dir
mask
/etc
R
#
all files under /etc are read-only
/etc/passwd
N
# ignore nothing
Tripwire - Overview
Tripwire Reports
•
New database is computed and compared with the old one
•
Any differences are passed through the masks in the
configuration file
•
If not masked out differences are written to a report:
Changed: -rw-r—r– root 20 Sep 17 13:46:43 2012 /.rhosts
### Attr
Observed
Expected
### ===
=======
=======
m
Fri Sep 17 13:46:43 2012
Tue Sep 13 20:05:10 2012
a
Fri Sep 17 13:46:43 2012
Tue Sep 13 20:05:10 2012
Limitations of Host Based
Intrusion Detection
•
No global knowledge or context
information
•
Must run IDS on host being monitored
–
Does no scale
–
Overhead
–
Host compromise = IDS compromise
•
Recovery options are limited
Snort
An open source, network-based IDS and IPS
Detection:
Signature based
Protocol based
Anomaly based
Widely deployed “de facto” industry standard
URL: www.snort.org
Snort - Overview
Goals are performance, simplicity, and flexibility
Performance depends on:
Number of rules (detection signatures)
Performance of the machine on which Snort is running
Load on the network
Use
libpcap
promiscuous packet sniffing library
for:
Packet capture
Filtering
Snort Components
Packet Decoder
Takes packets from different types of network interfaces
(e.g. Ethernet, SLIP, PPP)
Has subroutines that correspond to various network
layers/protocols:
Data link layer
Network layer (IP)
Transport layer (TCP, UDP, etc)
Application layer (HTTP, FTP, DNS, SMTP, etc.)
Annotates raw packet data by overlaying data structures
Pointers into the packet data for later analysis by the detection
engine
Preprocessors
Arrange or modify data packets prior to processing by the
detection engine
Example, detection engine contains a rule to flag the string
“scripts/iisadmin” in HTTP packets
Attackers try to evade IDS by disguising malicious strings using:
“scripts/./iisadmin”
“scripts/examples/../iisadmin”
“scripts\iisadmin”
“scripts/.\iisadmin”
Uniform Resource Identifier (URI) hexadecimal characters or Unicode
characters
A Snort preprocessor module converts all these representations
into a canonical form
Preprocessor Modules (cont)
Attackers try to evade IDS by fragmenting packets
Example:
Packet 1:
“scrip
Packet 2: ts/ii
Packet 3: sadmin”
No signatures match because half the payload is in
one packet while half is in a subsequent one
A Snort preprocessor module is responsible for
defragmenting packets
Preprocessor Modules (cont)
Attackers try to evade IDS by manipulating the TCP data stream
Example:
“scdef
<bs><bs><bs>
ripts/ijk
<bs><bs>
isade
<bs>
min
”
No signatures match if the TCP stream isn’t reassembled
A Snort preprocessor module is responsible for TCP stream
reassembly
Preprocessor Modules (cont)
Attackers try to evade IDS by showing the IDS different data
than what is seen by the end host
Example:
Packet 1 (TTL set to reach end host): “scrip
Packet 2 (TTL set to be dropped one hop beyond the IDS):
ABCDEFGHIJKLMNOP
Packet 3 (TTL set to reach end host): ts/iisadmin”
Detection Engine
Detection is guided by a set of rules
Standard rule database available from Snort
Can add custom rules
Rules can apply to:
IP header fields
TCP, UDP, ICMP header fields
Application header fields
Data
Rules are stored in a (chained) data structure to
optimize matching
Two dimensional linked list
Rule Chain Structure
Chain Header
Dest IP = 192.168.78.100
Dest Port = 80
Chain Header
Dest IP = 192.168.78.101
Dest Port = 25
Chain Option
Content = “scripts/iisadmin”
Chain Option
TCP Flags = URG
Chain Option
Chain Header
Logging and Alerting
Logging options
Store packets flagged by the detection engine in decoded,
human readable format to an IP-based directory structure
(slow)
Store packets in tcpdump binary format to a single log file
(faster)
Do not store packets (fastest)
Logging and Alerting (cont)
Alerting options
Send to syslog
Send to an alert text file (different formats)
Send as WinPopup messages using Samba
Discarded (during security testing)
Output Modules
Process log entries and alerts
Generate final output:
Logging to a database
Generating eXtensible Markup Language (XML) output
Etc.
Execute response actions:
Modifying configuration on routers and firewalls
Sending Server Message Block (SMB) messages to
Microsoft Windows-based machines
Snort Rules
Rules tell the detection engine:
What patterns to match
What to do with packets that match a given rule
Three basic directives:
Pass – silently drop the packet
Log – write the packet to the logging routine
Alert – log the packet and generate an event notification
Snort Rules - Examples
•
Record all traffic inbound for port 79 going to the 10.1.1.0
subnet:
–
log tcp any any -> 10.1.1.0/24 79
Detect attempts to access the PHF service on any of
subnet 10.1.1.0’s web servers
Generate an event notification alert
Log the packet
–
alert tcp any any -> 10.1.1.0/24 80 (content: "/cgi-bin/phf";
msg: "PHF probe!";)
Snort Rules - Structure
Every Snort rule has two parts:
Rule header (required)
What action a rule takes
Some matching criteria
•
Rule options (optional) - Enclosed in parentheses
Additional actions and matching criteria
Rule Header Rule Options
Rule Header
Seven fields:
Action (e.g. pass, log, alert, etc.)
Protocol (e.g. IP, ICMP, UDP, TCP, etc.)
Address – IP address specifying a single host,
multiple hosts, or network address
Port – UDP/TCP source and destination ports
Direction – specifies which address and port
number is the source and which is the destination
Rule Header – Action Field
Basics – pass, log, alert
Advanced:
Activate
Create an alert
Activate another rule for checking more conditions
Dynamic
Invoked by other rules using the “activate” action
User defined actions
Rule Header – Direction Field
A -> symbol shows that address and port numbers on the left
hand side of the direction field are the source
A <- symbol shows that address and port numbers on the right
hand side of the direction field are the source
A <> symbol means that the rule will be applied to packets
traveling in either direction
Intrusion Detection Systems (IDS)
•
An
Intrusion Detection System
(IDS) is a piece of software that
monitors a computer system to detect:
–
Intrusion
(unauthorized attempts to use the system) and
Misuse
(abuse of
existing privileges)
•
And responds by:
–
Logging activity, notifying a designated authority, or taking appropriate
countermeasures
•
Many different IDSs are available and they can be categorized
according to their:
–
Detection model (misuse detection, anomaly detection, hybrid)
–
Scope (host based, multihost based, network based)
•
Tripwire (file integrity checking IDS)
•
Snort (network-based IDS)
Intrusion Detection Systems (IDS) are software pieces that monitor computer systems to detect unauthorized intrusions and misuse, responding by logging activity, notifying authorities, and taking appropriate countermeasures. IDS help address security challenges, aiming to find and fix serious security holes, hold intruders accountable, and limit the potential damage that attackers can inflict. IDS run continually, are fault-tolerant, resist subversion, minimize overhead, are easily configurable, cope with changing system behavior, and aim to minimize false positives and false negatives.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Intrusion Detection Systems (IDS) What is an IDS? Definition Characteristics Examples of existing IDS
What is an IDS? Definition: A piece of software Monitors a computer system to detect: Intrusion: unauthorized attempts to use the system Misuse: abuse of existing privileges Responds: Log activity Notify a designated authority Take appropriate countermeasures
Why Use an IDS? Security is often expensive/cumbersome: Cost Restrictions on users/functionality Designers try to offer users reasonable levels of security Security breaches will still occur Detection allows: Finding and fixing the most serious security holes Perhaps holding intruders responsible for their actions Limiting the amount of damage an attacker can do
Goals of an IDS Run continually Be fault tolerant Resist subversion Minimize overhead Be easily configurable Cope with changing system behavior Be difficult to fool Minimize false positives and false negatives
Intrusion Detection Systems Three main components of an IDS: Information source provides a stream of event records Analysis engine finds signs of intrusions Response component generates reactions What is the best information source for intrusion detection?
Information Sources Host-based Operating System audit trails/system logs Application information Examples: database audit records, web server logs Network-based Network packets Network devices Security appliances Firewall Access control system
IDS Characteristics Detection Model Misuse detection vs. anomaly detection Scope Host based, multihost based, network based Operation Off-line vs. real-time Architecture Centralized vs. distributed
IDS Detection Model Misuse detection - recognize known attacks Define a set of attack signatures Detect actions that match a signature Add new signatures often Anomaly detection - recognize atypical behavior Define a set of metrics for the system Build a statistical model for those metrics during normal operation Detect when metrics differ significantly from normal Hybrid
IDS Scope Host based Scrutinize data from a single host Multihost based Analyze data from multiple hosts Network based Examine network traffic (and possibly data from the connected hosts)
Case Study: Tripwire A file integrity-checking tool Developed at Purdue university (released in 1993) Off-line, centralized, host-based, misuse detection Utilizes digital signatures to check for added, deleted, modified files Popular Portable Configurable Scalable Manageable Automated Secure
Background File Systems Provide long-term storage for: User data and programs System programs and databases A popular target for attackers: Unauthorized access to user or system files to uncover private information Modify system databases to allow future entry (e.g. SAM database) Modify system programs to allow future entry (e.g. back doors) Cleansing of system logs to thwart detection
Tripwire - Overview A checklist is created which contains one entry for each file being monitored Checklist should: Be secure against unauthorized modifications Each entry in the checklist is a fingerprint for the corresponding file Fingerprints should: Be efficient to compute Be hard to invert Depend on the entire contents of the file Be very likely to change if the file changes Be very unlikely to match fingerprints from other files
Tripwire Overview (cont) New database generate Apply masks compare Report Old Config file database Files residing on file system
Tripwire Database Unencrypted and world-readable To prevent the database from being tampered with, it is recommended it be: Installed and updated in a secure manner (e.g. single- user mode) Stored either: On a read-only media On a write-protected disk On a secure server (e.g. read-only NFS)
Tripwire Configuration Files Contains: A list of directories (or files) to be monitored A mask for each that describes which attributes can change without being reported Mask bits (all fields stored in a file s inode): p: permissions i: inode number n: number of links u: user id g: group id s: size of file m: modification timestamp a: access timestamp [1-10]: signature #1, signature #2, etc. Signature algorithms supported (MD5, MD4, MD2, Snefru, SHA, CRC-32, CRC-16)
Tripwire Configuration Files (cont) Using masks: Fields can be added ( + ) or subtracted ( - ) from the set of items to be examined for a file Example: +pinugsm12-a = report changes to all fields except access timestamp Mask templates: R = +pinugsm12-a = read-only files; only access timestamp is ignored L = +pinug-sma12 = log files; changes to file size, access time, modification time, and signatures are ignored N = +pinugsma12 = ignore nothing E = -pinugsma12 = ignore everything
Tripwire Configuration File - Example # file/dir /etc all files under /etc are read-only /etc/passwd mask R # N # ignore nothing
Tripwire - Overview New database generate Apply masks compare Report Old Config file database Files residing on file system
Tripwire Reports New database is computed and compared with the old one Any differences are passed through the masks in the configuration file If not masked out differences are written to a report: Changed: -rw-r r root 20 Sep 17 13:46:43 2012 /.rhosts ### Attr Observed ### === ======= m Fri Sep 17 13:46:43 2012 Tue Sep 13 20:05:10 2012 a Fri Sep 17 13:46:43 2012 Tue Sep 13 20:05:10 2012 Expected =======
Limitations of Host Based Intrusion Detection No global knowledge or context information Must run IDS on host being monitored Does no scale Overhead Host compromise = IDS compromise Recovery options are limited
Snort An open source, network-based IDS and IPS Detection: Signature based Protocol based Anomaly based Widely deployed de facto industry standard URL: www.snort.org
Snort - Overview Goals are performance, simplicity, and flexibility Performance depends on: Number of rules (detection signatures) Performance of the machine on which Snort is running Load on the network Use libpcap promiscuous packet sniffing library for: Packet capture Filtering
Packet Decoder Takes packets from different types of network interfaces (e.g. Ethernet, SLIP, PPP) Has subroutines that correspond to various network layers/protocols: Data link layer Network layer (IP) Transport layer (TCP, UDP, etc) Application layer (HTTP, FTP, DNS, SMTP, etc.) Annotates raw packet data by overlaying data structures Pointers into the packet data for later analysis by the detection engine
Preprocessors Arrange or modify data packets prior to processing by the detection engine Example, detection engine contains a rule to flag the string scripts/iisadmin in HTTP packets Attackers try to evade IDS by disguising malicious strings using: scripts/./iisadmin scripts/examples/../iisadmin scripts\iisadmin scripts/.\iisadmin Uniform Resource Identifier (URI) hexadecimal characters or Unicode characters A Snort preprocessor module converts all these representations into a canonical form
Preprocessor Modules (cont) Attackers try to evade IDS by fragmenting packets Example: Packet 1: scrip Packet 2: ts/ii Packet 3: sadmin No signatures match because half the payload is in one packet while half is in a subsequent one A Snort preprocessor module is responsible for defragmenting packets
Preprocessor Modules (cont) Attackers try to evade IDS by manipulating the TCP data stream Example: scdef<bs><bs><bs>ripts/ijk<bs><bs>isade<bs>min No signatures match if the TCP stream isn t reassembled A Snort preprocessor module is responsible for TCP stream reassembly
Preprocessor Modules (cont) Attackers try to evade IDS by showing the IDS different data than what is seen by the end host Example: Packet 1 (TTL set to reach end host): scrip Packet 2 (TTL set to be dropped one hop beyond the IDS): ABCDEFGHIJKLMNOP Packet 3 (TTL set to reach end host): ts/iisadmin
Detection Engine Detection is guided by a set of rules Standard rule database available from Snort Can add custom rules Rules can apply to: IP header fields TCP, UDP, ICMP header fields Application header fields Data Rules are stored in a (chained) data structure to optimize matching Two dimensional linked list
Rule Chain Structure Chain Header Chain Header Chain Header Dest IP = 192.168.78.100 Dest Port = 80 Dest IP = 192.168.78.101 Dest Port = 25 Chain Option Chain Option Content = scripts/iisadmin Chain Option TCP Flags = URG
Logging and Alerting Logging options Store packets flagged by the detection engine in decoded, human readable format to an IP-based directory structure (slow) Store packets in tcpdump binary format to a single log file (faster) Do not store packets (fastest)
Logging and Alerting (cont) Alerting options Send to syslog Send to an alert text file (different formats) Send as WinPopup messages using Samba Discarded (during security testing)
Output Modules Process log entries and alerts Generate final output: Logging to a database Generating eXtensible Markup Language (XML) output Etc. Execute response actions: Modifying configuration on routers and firewalls Sending Server Message Block (SMB) messages to Microsoft Windows-based machines
Snort Rules Rules tell the detection engine: What patterns to match What to do with packets that match a given rule Three basic directives: Pass silently drop the packet Log write the packet to the logging routine Alert log the packet and generate an event notification
Snort Rules - Examples Record all traffic inbound for port 79 going to the 10.1.1.0 subnet: log tcp any any -> 10.1.1.0/24 79 Detect attempts to access the PHF service on any of subnet 10.1.1.0 s web servers Generate an event notification alert Log the packet alert tcp any any -> 10.1.1.0/24 80 (content: "/cgi-bin/phf"; msg: "PHF probe!";)
Snort Rules - Structure Every Snort rule has two parts: Rule Header Rule Options Rule header (required) What action a rule takes Some matching criteria Rule options (optional) - Enclosed in parentheses Additional actions and matching criteria
Rule Header Seven fields: Action (e.g. pass, log, alert, etc.) Protocol (e.g. IP, ICMP, UDP, TCP, etc.) Address IP address specifying a single host, multiple hosts, or network address Port UDP/TCP source and destination ports Direction specifies which address and port number is the source and which is the destination
Rule Header Action Field Basics pass, log, alert Advanced: Activate Create an alert Activate another rule for checking more conditions Dynamic Invoked by other rules using the activate action User defined actions
Rule Header Direction Field A -> symbol shows that address and port numbers on the left hand side of the direction field are the source A <- symbol shows that address and port numbers on the right hand side of the direction field are the source A <> symbol means that the rule will be applied to packets traveling in either direction
Intrusion Detection Systems (IDS) An Intrusion Detection System (IDS) is a piece of software that monitors a computer system to detect: Intrusion (unauthorized attempts to use the system) and Misuse (abuse of existing privileges) And responds by: Logging activity, notifying a designated authority, or taking appropriate countermeasures Many different IDSs are available and they can be categorized according to their: Detection model (misuse detection, anomaly detection, hybrid) Scope (host based, multihost based, network based) Tripwire (file integrity checking IDS) Snort (network-based IDS)
