1. JMU GenCyber Boot Camp Summer, 2015

2. Intrusion Detection Systems (IDS)
What is an IDS?
Definition
Characteristics
Examples of existing IDS 2

3. 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

4. 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

5. 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

6. 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?

7. Information Sources Host-based Network-based Security appliances
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

8. IDS Characteristics Detection Model Scope Operation Architecture
Misuse detection vs. anomaly detection
Scope
Host based, multihost based, network based
Operation
Off-line vs. real-time
Architecture
Centralized vs. distributed

9. 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

10. IDS Scope Host based Multihost based Network 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)

11. 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

12. 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

13. 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

14. Tripwire – Overview (cont)
generate
New database
Config file
Old database
compare
Apply masks
Report
Files residing on file system

15. 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)

16. 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)

17. 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

18. Tripwire Configuration File - Example
# file/dir mask
/etc R # all files under /etc are read-only
/etc/passwd N # ignore nothing

19. Tripwire - Overview Files residing on file system generate
New database
Config file
Old database
compare
Apply masks
Report
Files residing on file system

20. 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 Sep 17 13:46: /.rhosts
### Attr Observed Expected
### === ======= =======
m Fri Sep 17 13:46: Tue Sep 13 20:05:
a Fri Sep 17 13:46: Tue Sep 13 20:05:

21. 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

22. Snort An open source, network-based IDS and IPS Detection:
Signature based
Protocol based
Anomaly based
Widely deployed “de facto” industry standard
URL:

23. 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

24. Snort Components

25. 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

26. 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

27. 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

28. 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

29. 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”

30. 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

31. Rule Chain Structure Chain Header Dest IP = 192.168.78.100
Dest Port = 80
Chain Header
Dest IP =
Dest Port = 25
Chain Header
Chain Option
Content = “scripts/iisadmin”
Chain Option
Chain Option
TCP Flags = URG

32. 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)

33. 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)

34. 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

35. 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

36. Snort Rules - Examples
Record all traffic inbound for port 79 going to the subnet:
log tcp any any -> /24 79
Detect attempts to access the PHF service on any of subnet ’s web servers
Generate an event notification alert
Log the packet
alert tcp any any -> /24 80 (content: "/cgi-bin/phf"; msg: "PHF probe!";)

37. 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

38. 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

39. 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

40. 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

41. 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) 41