Martin Roesch Sourcefire Inc Topics Background What is
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 forensic post processing
Snort “Metrics” • Small (~800 k source download) • Portable (Linux, Windows, Mac. OS X, Solaris, BSD, IRIX, Tru 64, HP-UX, etc) • Fast (High probability of detection for a given attack on 100 Mbps 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. 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: 23 TCP TTL: 128 TOS: 0 x 0 ID: 31237 Ip. Len: 20 Dgm. Len: 59 DF ***AP*** Seq: 0 x 16 B 6 DA Ack: 0 x 1 AF 156 C 2 Win: 0 x 2217 Tcp. Len: 20 FF FC 23 FF FC 27 FF FC 24 FF FA 18 00 41 4 E 53. . #. . '. . $. . ANS 49 FF F 0 I. . =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 11/09 -11: 12: 02. 956582 10. 1. 1. 8: 23 -> 10. 1. 1. 6: 1032 TCP TTL: 255 TOS: 0 x 0 ID: 49900 Ip. Len: 20 Dgm. Len: 61 DF ***AP*** Seq: 0 x 1 AF 156 C 2 Ack: 0 x 16 B 6 ED Win: 0 x 2238 Tcp. Len: 20 0 D 0 A 53 75 6 E 4 F 53 20 35 2 E 37 0 D 0 A 0 D. . Sun. OS 5. 7. . . 00 0 D 0 A 0 D 00. . . =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
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 • Snort rules are extremely flexible and are easy to modify, unlike many commercial NIDS • Sample rule to detect Sub. Seven trojan: alert tcp $EXTERNAL_NET 27374 -> $HOME_NET any (msg: "BACKDOOR subseven 22"; flags: A+; content: "|0 d 0 a 5 b 52504 c 5 d 3030320 d 0 a|"; reference: arachnids, 485; reference: url, www. hackfix. org/subseven/; 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 27374 -> $HOME_NET any (msg: "BACKDOOR subseven 22"; flags: A+; content: "|0 d 0 a 5 b 52504 c 5 d 3030320 d 0 a|"; reference: arachnids, 485; reference: url, www. hackfix. org/subseven/; 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 27374 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 27374 -> $HOME_NET any (msg: "BACKDOOR subseven 22"; flags: A+; content: "|0 d 0 a 5 b 52504 c 5 d 3030320 d 0 a|"; reference: arachnids, 485; reference: url, www. hackfix. org/subseven/; 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: “|0 d 0… 0 a|”; 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. rules exploit. rules scan. rules finger. rules ftp. rules telnet. rules smtp. rules rpc. rules rservices. rules dos. rules dns. rules tftp. rules web-cgi. rules web-coldfusion. rules web-frontpage. rules web-iis. rules web-misc. rules web-attacks. rulessql. rules x 11. rules icmp. rules netbios. rules misc. rules backdoor. rules shellcode. rules policy. rules porn. rules info. rules icmp-info. rules virus. rules local. rules attack-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 |"; 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-applicationattack; 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: miscactivity; sid: 554; rev: 3; ) caught anonymous ftp server
Snort Architecture
Data Flow Sniffing Packet Decoder Preprocessor (Plug-ins) Detection Engine (Plug-ins) Output Stage (Plug-ins) Data Flow Packet Stream Snort Alerts/Logs
Detection Engine: Rules Rule Header Rule Options Alert tcp 1. 1 any -> 2. 2 any (flags: SF; msg: “SYN-FIN Scan”; ) Alert tcp 1. 1 any -> 2. 2 any (flags: S 12; msg: “Queso Scan”; ) Alert tcp 1. 1 any -> 2. 2 any (flags: F; msg: “FIN Scan”; )
Detection Engine: Internal Representation Rule Node Alert tcp 1. 1 any -> 2. 2 any Option Node (flags: SF; msg: “SYN-FIN Scan”; ) (flags: S 12; msg: “Queso Scan”; ) (flags: F; msg: “FIN Scan”; )
Detection Engine: Fully Populated Rule Node Rule Node Option Node Option Node Option Node
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 Honeypot (Deception System) Generic Server (Host-Based ID) (Snort 2. 0) Internet Filtering Router (Perimeter Logs) Firewall (Perimeter Logs) Statistical IDS (Snort) Network 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 100 Mbps 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 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, Hostbased 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 alert tcp Sip: 1. 1 Dip: 2. 2 Dp: 80 (flags: A+; content: “”foo”; ) (flags: A+; content: “bar”; ) (flags: A+; content: “baz”; )
Snort 2. 0 Detection Engine Comparison – V 2. 0 alert tcp Sip: 1. 1 Dip: 10. 1. 1. 0/24 content: “”foo”; Dip: 2. 2 Dp: 80 Flags: A+; content: “bar”; content: “baz”;
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
- Slides: 45