Copyright 2001 Martin Roesch, All Rights Reserved Martin Roesch Sourcefire Inc

Copyright 2001 Martin Roesch, All Rights Reserved

Martin Roesch

Sourcefire Inc.


Topics

• Background– What is Snort?

• Using Snort

• Snort Architecture

• The Future of Snort and Snort 2.0


Background – Intrusion Detection

• Intrusion Detection defined: “the problem of identifying individuals who are using a computer system without authorization”– Attempts to break in also have to be

identified

• Intrusion detection is NOT intrusion prevention!


Background – Policy

• Successful intrusion detection depends on policy and management as much as technology– Security Policy (defining what is acceptable

and what is being defended) is the first step

– Notification • Who, how fast?

– Response Coordination


Intro to Snort

• What is Snort?– Snort is a multi-mode packet analysis tool

• Sniffer• Packet Logger• Forensic Data Analysis tool• Network Intrusion Detection System

• Where did it come from?– Developed out of my evolving need to perform

network traffic analysis in both real-time and for forensic post processing


Snort “Metrics”

• Small (~800k source download)• Portable (Linux, Windows, MacOS X,

Solaris, BSD, IRIX, Tru64, HP-UX, etc)• Fast (High probability of detection for a

given attack on 100Mbps networks)• Configurable (Easy rules language,

many reporting/logging options• Free (GPL/Open Source Software)


Snort Design

• Packet sniffing “lightweight” network intrusion detection system

• Libpcap-based sniffing interface

• Rules-based detection engine

• Plug-in system allows endless flexibility


Detection Engine

• Rules form “signatures”• Modular detection elements are

combined to form these signatures• Wide range of detection capabilities

– Stealth scans, OS fingerprinting, buffer overflows, back doors, CGI exploits, etc.

• Rules system is very flexible, and creation of new rules is relatively simple


Plug-Ins

• Preprocessor– Packets are examined/manipulated before

being handed to the detection engine

• Detection– Perform single, simple tests on a single

aspect/field of the packet

• Output– Report results from the other plug-ins


Uses for Snort

• Standard packet sniffing NIDS

• Policy Enforcement

• Honeypot monitor

• Scan detection/traps


IDS Implementation Map

FilteringRouter

(Perimeter Logs)

Firewall(Perimeter

Logs)

Generic Server(Host-Based ID)

(Snort 2.0)

Network IDS(Snort)

Internet

Honeypot(Deception System)

Statistical IDS (Snort)


Using Snort

• Three main operational modes– Sniffer Mode– Packet Logger Mode– NIDS Mode– (Forensic Data Analysis Mode)

• Operational modes are configured via command line switches– Snort automatically tries to go into NIDS mode if

no command line switches are given, looks for snort.conf configuration file in /etc


Using Snort – Sniffer Mode

• Works much like tcpdump

• Decodes packets and dumps them to stdout

• BPF filtering interface available to shape displayed network traffic


What Do The Packet Dumps Look Like?

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

11/09-11:12:02.954779 10.1.1.6:1032 -> 10.1.1.8:23TCP TTL:128 TOS:0x0 ID:31237 IpLen:20 DgmLen:59 DF***AP*** Seq: 0x16B6DA Ack: 0x1AF156C2 Win: 0x2217 TcpLen: 20FF FC 23 FF FC 27 FF FC 24 FF FA 18 00 41 4E 53 ..#..'..$....ANS49 FF F0 I..

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

11/09-11:12:02.956582 10.1.1.8:23 -> 10.1.1.6:1032TCP TTL:255 TOS:0x0 ID:49900 IpLen:20 DgmLen:61 DF***AP*** Seq: 0x1AF156C2 Ack: 0x16B6ED Win: 0x2238 TcpLen: 200D 0A 0D 0A 53 75 6E 4F 53 20 35 2E 37 0D 0A 0D ....SunOS 5.7...00 0D 0A 0D 00 .....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


How is it different from tcpdump?

11:16:35.648944 10.1.1.8.23 > 10.1.1.6.1033: P 16:34(18) ack 16 win 8760 (DF) (ttl 255, id 49913)

4500 003a c2f9 4000 ff06 a2b4 0a01 0108

0a01 0106 0017 0409 1cf9 e7f6 001a e050

5018 2238 31c6 0000 fffe 1fff fe23 fffe

27ff fe24 fffa

11:16:35.649457 10.1.1.6.1033 > 10.1.1.8.23: P 16:19(3) ack 34 win 8727 (DF) (ttl 128, id 57861)

4500 002b e205 4000 8006 02b8 0a01 0106

0a01 0108 0409 0017 001a e050 1cf9 e808

5018 2217 6f19 0000 fffc 1f20 2020


Packet Logger Mode

• Gee, it sure would be nice if I could save those packets to disk…

• Multi-mode packet logging options available– Flat ASCII, tcpdump, XML, database, etc

available

• Log all data and post-process to look for anomalous activity


NIDS Mode

• Uses all phases of Snort + plug-ins to analyze traffic for both misuse detection and anomalous activity

• Can perform portscan detection, IP defragmentation, TCP stream reassembly, application layer analysis and normalization, etc


NIDS Mode…

• Various output options available– Database (MySQL, PostgreSQL, Oracle,

unixODBC, etc)– XML (snml DTD from CMU/CERT)– Tcpdump binary format– Unified (Snort specific) format– ASCII, syslog, WinPopup (SMB)– Etc.


NIDS Mode…

• Wide variety of rules available for signature engine (~1300 as of June 2001)

• Multiple detection modes available via rules and plug-ins– Rules/signature – Statistical anomaly– Protocol verification


Snort Architecture


Snort 1.x Data Flow

Packet Decoder

Preprocessor(Plug-ins)

Detection Engine(Plug-ins)

Output Stage(Plug-ins)

Packet S

tream

Sniffing

SnortD

ata Flow

Alerts/Logs


Snort 1.x Architecture

• Snort’s existing architecture for the 1.x series of code is a study in organic software development

• Snort’s evolution– Sniffer->packet logger->NIDS

• Speed by subsystem– Decode = very fast– Detection engine = fast– Output/preprocessor modules = implementation

dependent


Snort 1.x Detection Engine

• Implemented as a 3-dimensional linked list– Dimensions 1 & 2 contain data nodes to be tested

against current packet– Dimension 3 contains linked lists of function

pointers to test the node’s data against the packet– Entire engine is walked recursively– Very fast, very robust– “First exit” detection strategy

• First detect causes engine to perform rule action & then go on to next packet


Rule HeaderAlert tcp 1.1.1.1 any -> 2.2.2.2 any

Rule Options(flags: SF; msg: “SYN-FIN Scan”;)

Alert tcp 1.1.1.1 any -> 2.2.2.2 any

Alert tcp 1.1.1.1 any -> 2.2.2.2 any

(flags: S12; msg: “Queso Scan”;)

(flags: F; msg: “FIN Scan”;)

Detection Engine: Rules


Alert tcp 1.1.1.1 any -> 2.2.2.2 any

Rule Node

(flags: SF; msg: “SYN-FIN Scan”;)

(flags: S12; msg: “Queso Scan”;)

(flags: F; msg: “FIN Scan”;)

Option Node

Detection Engine: Internal Representation


RuleNode

RuleNode

RuleNode

RuleNode

RuleNode

OptionNode

OptionNode

OptionNode

OptionNode

OptionNode

OptionNode

OptionNode

OptionNode

OptionNode

OptionNode

OptionNode

Detection Engine: Fully Populated


Snort 1.x Performance and Flexibility

• Development process lead to very high speed decoding and stateless intrusion detection

• How fast is it?– Configuration dependent, but 100Mbps is not too difficult for

Snort to manage

• Flexibility made Snort the platform of choice for a number of applications in the R&D space– Govt and University researchers frequently use Snort as a

rapid prototyping platform for new ideas in intrusion detection


Snort 1.x Limitations

• Snort is an IP-centric program• Packet analysis

– IP defragmentation and TCP stream reassembly are via the preprocessor interface

– Internal data structures don’t scale well for addition of new protocols

• NOTE: Adding new protocol support is not hard, just a little clunky

– Application layer is not decoded by packet decoder

• Left for pattern analysis in detection engine



• Detection Engine & Preprocessors– Revelation: Not everyone is as concerned with performance

as I am!– Not all preprocessors are created equal– Adding additional protocol support to detection engine is not

well modularized• Adding “IP” rules support took about 7 lines of code, but

knowing which 7 required me to do it

– Rules description language is limited at the protocol level• Easy to describe IP/TCP/UDP/ICMP/IGMP/Etc, hard to

describe HTTP, RPC, SMTP, etc



• Output– People have a really nasty tendency to write slow

output plug-ins!– Variable output formats mean performance is

highly variable based on the selected output modes

– No way to control Snort’s performance effectively, leading to negative reviews and user e-mail

• “Snort’s eating 90% of the CPU!?!”


Snort 2.0 Architecture

• Basic goals– Faster– More extensible– Better protocol support– Better able to analyze the full gestalt of

network intrusion activity


Snort 2.0 Plug-Ins

• More of them for more flexibility– Data acquisition– Traffic decoders

• Full protocol analysis and verification• Multi-path traffic flows, packet and stream

– Multi-format rules input• DB, XML, etc

– Pluggable detection engines• Standard NIDS, Target-based IDS, Statistical IDS, Host-

based IDS


Snort 2.0 Improvements

• Improved detection & pattern matching capabilities– Aho-Corasick/Boyer-Moore implementation

from Silicon Defense– LANL/RADIANT Team work on set-wise

Boyer-Moore-Horspool algorithm– ~500% in pattern matching performance

improvement reported in research work!


Snort 2.0 Improvements

• Spooling output stage– Write Snort alert/log data to spool files,

have a secondary process (‘barnyard’) read the spools and reformat for final output

– Output plug-ins attach to barnyard instead of being directly linked to Snort main code

• Deterministic performance measurements and focused performance improvement will be possible through this method


Snort 2.0 Detection Engine

• Far more self-optimizing than 1.x– Rules will be “treed” to a greater extent– Most tests will be performed only once

• More rules can be loaded with less impact on the overall performance of the program

• Speed and structure of engine will allow “last-exit” detection strategy to be used


Snort 2.0 Detection Engine Comparison – V 1.x

Sip: 1.1.1.1 Dip: 2.2.2.2 Dp: 80

(flags: A+; content: “”foo”;)

(flags: A+; content: “bar”;)

(flags: A+; content: “baz”;)

alert

tcp


Snort 2.0 Detection Engine Comparison – V 2.0

content: “”foo”;

content: “bar”;

content: “baz”;

alert tcp

Dip: 2.2.2.2

Dip: 10.1.1.0/24

Flags: A+;

Sip: 1.1.1.1

Dp: 80


Acquisition Plugins• Libpcap allows us to be very cross platform

but is also a bottleneck• Acquisition plugins allow arbitrary data input

sources• Interesting applications

– Netfilter/divert socket input stream– Gateway IDS…– Host-based IDS…

• High speed platform specific acquistion capability


Decoder Plugins• Arbitrary protocol support in Snort• Snort is currently limited to…

– Ethernet, FDDI, T/R, SLIP, PPP, ISDN, Raw– IP, ARP– TCP, UDP, ICMP

• With plug-ins, new decoders can be painlessly dropped into Snort, automatically making Snort “aware” of that protocol and capable of performing traffic analysis on it

• Additional support for “unknown” protocols will have to be added to the detection engine


Pluggable Detection Engines

• Current signature based engine isn’t necessarily the only way to do NID

• The current primary detection engine in Snort is really just a very involved preprocessor

• Other possibilities– Snort + Netfilter (or Divert Sockets) = Gateway

IDS (or “packet scrubber”)– Snort + NMAP = Target-based IDS– Snort + SAS = Statistical Anomaly IDS (ok, just

kidding)


Learning More

• www.snort.org– Writing Snort Rules

• www.snort.org/snort_rules.html

– FAQ, USAGE file, README file, man page– Snort mailing lists

• Books– Intrusion Detection: An Analysts Handbook by Northcutt– Intrusion Signatures and Analysis by Northcutt– The Practical Intrusion Detection Handbook by Paul Proctor


FIN• Martin Roesch

– [email protected]

• Get Snort– www.snort.org– Win32 version

• www.datanerds.net/~mike

• Get Snort Rules– www.whitehats.com

• Commercial Snort Tech Support and Info– www.silicondefense.com

• Commercial Snort Network Security Appliances– www.sourcefire.com

• Security Info – www.securityfocus.com– packetstorm.securify.com– www.linuxsecurity.com– www.technotronic.com– Many more

Documents

Copyright 2001 Martin Roesch, All Rights Reserved Martin Roesch Sourcefire Inc