Martin Roesch Sourcefire Inc.

Topics Background –What is Snort? Using Snort Snort Architecture The Future of Snort and Snort 2.0

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 the 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

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: :1032 -> :23 TCP TTL:128 TOS:0x0 ID:31237 IpLen:20 DgmLen:59 DF ***AP*** Seq: 0x16B6DA Ack: 0x1AF156C2 Win: 0x2217 TcpLen: 20 FF FC 23 FF FC 27 FF FC 24 FF FA E 53..#..'..$....ANS 49 FF F0 I.. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 11/09-11:12: :23 -> :1032 TCP TTL:255 TOS:0x0 ID:49900 IpLen:20 DgmLen:61 DF ***AP*** Seq: 0x1AF156C2 Ack: 0x16B6ED Win: 0x2238 TcpLen: 20 0D 0A 0D 0A E 4F E 37 0D 0A 0D....SunOS D 0A 0D =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

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… 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 Rules

Snort rules are extremely flexible and are easy to modify, unlike many commercial NIDS Sample rule to detect SubSeven trojan: alert tcp $EXTERNAL_NET > $HOME_NET any (msg:"BACKDOOR subseven 22"; flags: A+; content: "|0d0a5b52504c5d d0a|"; reference:arachnids,485; reference:url, sid:103; classtype:misc-activity; rev:4;) Elements before parentheses comprise ‘rule header’ Elements in parentheses are ‘rule options’

Snort Rules alert tcp $EXTERNAL_NET > $HOME_NET any (msg:"BACKDOOR subseven 22"; flags: A+; content: "|0d0a5b52504c5d d0a|"; reference:arachnids,485; reference:url, sid:103; classtype:misc-activity; rev:4;) alert action to take; also log, pass, activate, dynamic tcp protocol; also udp, icmp, ip $EXTERNAL_NET source address; this is a variable – specific IP is ok source port; also any, negation (!21), range (1:1024) -> direction; best not to change this, although <> is allowed $HOME_NET destination address; this is also a variable here any destination port

Snort Rules alert tcp $EXTERNAL_NET > $HOME_NET any (msg:"BACKDOOR subseven 22"; flags: A+; content: "|0d0a5b52504c5d d0a|"; reference:arachnids,485; reference:url, sid:103; classtype:misc-activity; rev:4;) msg:”BACKDOOR subseven 22”; message to appear in logs flags: A+; tcp flags; many options, like SA, SA+, !R, SF* content: “|0d0…0a|”; binary data to check in packet; content without | (pipe) characters do simple content matches reference…; where to go to look for background on this rule sid:103; rule identifier classtype: misc-activity; rule type; many others rev:4; rule revision number other rule options possible, like offset, depth, nocase

Snort Rules bad-traffic.rulesexploit.rulesscan.rules finger.rulesftp.rulestelnet.rules smtp.rulesrpc.rulesrservices.rules dos.rulesddos.rulesdns.rules tftp.rulesweb-cgi.rulesweb-coldfusion.rules web-frontpage.rulesweb-iis.rulesweb-misc.rules web-attacks.rulessql.rulesx11.rules icmp.rulesnetbios.rulesmisc.rules backdoor.rulesshellcode.rulespolicy.rules porn.rulesinfo.rulesicmp-info.rules virus.ruleslocal.rulesattack-responses.rules

Snort Rules Rules which actually caught intrusions –alert tcp $EXTERNAL_NET any -> $SQL_SERVERS 1433 (msg:"MS-SQL xp_cmdshell - program execution"; content: "x|00|p|00|_|00|c|00|m|00|d|00|s|00|h|00|e|00|l|00|l|00 |"; nocase; flags:A+; classtype:attempted-user; sid:687; rev:3;) caught compromise of Microsoft SQL Server –alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"WEB-IIS cmd.exe access"; flags: A+; content:"cmd.exe"; nocase; classtype:web-application- attack; sid:1002; rev:2;) caught Code Red infection –alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"INFO FTP \"MKD / \" possible warez site"; flags: A+; content:"MKD / "; nocase; depth: 6; classtype:misc- activity; sid:554; rev:3;) caught anonymous ftp server

Snort Architecture

Data Flow Packet Decoder Preprocessor (Plug-ins) Detection Engine (Plug-ins) Output Stage (Plug-ins) Packet Stream Sniffing Snort Data Flow Alerts/Logs

Rule Header Alert tcp any -> any Rule Options (flags: SF; msg: “SYN-FIN Scan”;) Alert tcp any -> any (flags: S12; msg: “Queso Scan”;) (flags: F; msg: “FIN Scan”;) Detection Engine: Rules

Alert tcp any -> 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

Rule Node Rule Node Rule Node Rule Node Rule Node Option Node Option Node Option Node Option Node Option Node Option Node Option Node Option Node Option Node Option Node Option Node Detection Engine: Fully Populated

Conclusion Snort is a powerful tool, but maximizing its usefulness requires a trained operator Becoming proficient with network intrusion detection takes 12 months; “expert” 24-36? Snort is considered a superior NIDS when compared to most commercial systems Managed network security providers should collect enough information to make decisions without calling clients to ask what happened

Backup Slides

DS Implementation Map Filtering Router (Perimeter Logs) Firewall (Perimeter Logs) Generic Server (Host-Based ID) (Snort 2.0) Network IDS (Snort) Internet Honeypot (Deception System) Statistical IDS (Snort)

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

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

Snort 1.x Limitations 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

Snort 1.x Limitations 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 “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: Dip: 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”; alerttcp Dip: Dip: /24 Flags: A+; Sip: 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 –Writing Snort Rules –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