Detecting Attacks Anomaly-based Detection Signature-based - PDF document

Detecting Attacks • Anomaly-based Detection Signature-based • Signature-based (Misuse) Detection Intrusion Detection • Host-based • Network-based Boriana Ditcheva and Lisa Fowler – Active/Passive University of North Carolina at Chapel Hill February 16 & 22, 2005 1 2 Signature-based Detection Anomaly-based detection • Central idea: “abnormal” = “suspicious” • Looks for specific and explicit indications of attacks • Automatically learns – Identified by raw byte sequences (strings), protocol type, port numbers, etc. • Detects novel attacks (and its variations) • Can be left to run unattended • Low false positives – “Knows for a fact” what is suspicious, what is normal • Requires a notion and definition of “normal” • Detects only behavior that was previously defined to be suspicious • Susceptible to false negatives – Can have tight signatures (high confidence) – Unusual is not necessarily illicit/malicious • Simple and efficient process – Usual is not necessarily benign • e.g. attacks that manifest slowly • Easy to share • Computation intensive – Repositories of signatures 3 4 Problems Signature-based Detection • System must be trained • Goal: – Requires time-consuming manual identification and specification of – Find a pattern or signature that can allow for the each new attack – Often requires ‘expert’ knowledge detection of a specific attack – Cannot detect novel attacks on its own • Think about virus detection… • False negatives – Be narrow to be more precise (reduce false – May not detect simple variations – Unless previously detected and identified… negatives) • False positives – Be flexible to cover as many of the variants as – May detect failed attacks possible while minimizing false positives – Loose signatures (low confidence) – Poorly configured systems 5 6

IDS Placement IDS Placement • Outside firewall – Detects all attacks directed at your network – Detects more events – Generates more logs • Inside firewall – Only detects what the firewall lets in – Less state information Typical placement of an IDS system (in this example, Bro For more info, see http://www.netoptics.com/products/pdf/Taps-and-IDSs.pdf 7 8 http://bro-ids.org/Bro-quick-start/Network-Tap.html Making a Signature Making a Signature++ • DIY (Manual) • Automated – Become a “security officer” – If we can extract or isolate suspicious network data, can conceive of a system that can – Know detailed information regarding the exploit aggregate the data and generate signatures – Generate the signature by manual inspection – Can generate false positives or false negatives 9 10 Example Signature SNORT Trin00 • Lightweight signature-based intrusion detection http://www.snort.org/snort-db/sid.html?sid=223 system • Only 100 kilobytes in compressed source GEN:SID 1:223 distribution Message DDOS Trin00 Daemon to Master PONG message • Don’t need sophisticated training to use like with detected other commercial NIDSs • Configurable (Easy rules language, many Rule alert udp $EXTERNAL_NET any -> $HOME_NET 31335 logging/alerting options) (msg:"DDOS Trin00 Daemon to Master PONG message detected"; content:"PONG"; reference:arachnids,187; • Free classtype:attempted-recon; sid:223; rev:3;) 11 12 All Snort signature examples from http://snort.org

Snort’s architecture Snort’s architecture • Packet Decoder • Detection Engine • Logging/Alerting Subsystem – These subsystems ride on top of the libpcap promiscuous packet sniffing library. 13 14 Packet Decoder Detection Engine • Organized around the layers of the protocol • Uses comparison to predetermined rules ( to stack present in the supported data-link and be discussed in a minute ) to decide whether TCP/IP protocol definitions. a packet should be flagged or not. • Sets pointers into the packet data for later • Maintains detection rules in a two access and analysis by the detection engine. dimensional linked list of Chain Headers and Chain Options. • First rule that matches a decoded packet triggers the specified action and returns. 15 16 Rule Chain Structure Logging/Alerting Subsystem Chain Header Chain Header • Logging options: Source IP Address Source IP Address Destination IP Address Destination IP Address – Log packets in their decoded human readable Source Port Source Port Destination Port Destination Port format to an IP-based directory structure – Log packets in tcpdump binary format to single Chain Option Chain Option log file ( much faster ) Content Content TCP Flags TCP Flags ICMP Codes/Types ICMP Codes/Types – Do not log Payload Size Payload Size Etc. Etc. Chain Option Content TCP Flags ICMP Codes/Types Figure 3. Rule Chain logical structure (From [4]) Payload Size 17 18 Etc.

Logging/Alerting Subsystem Snort Rules • Alert options: • Snort can take three base actions when it finds a matching packet: – Alerts sent to syslog – Pass (drop the packet) – Alerts logged to specified alert text file • Full alerting: write the alert message and packet – Log (write full packet to logging routine) header info through the transport layer protocol – Alert (generates notification as specified by user) • Fast alerting: write condensed subset of the header info – Alerts sent as WinPopup messages – Disable alerting 19 20 Snort Rules Option Fields 1. content – search packet payload for specified item 2. flags – test TCP flags 3. ttl – check IP ttl field • Header Features: 4. itype – match on ICMP type field • Look at uni- or bi-directional traffic 5. icode – match on ICMP code field • IP addresses 6. minfrag – set threshold for IP fragment size – negation, CIDR ranges • TCP/UDP ports 7. id – test IP header for specified value – Negation, ranges, greater than/less than 21 22 Option Fields Example Signature Trin00 8. ack – TCP ack number http://www.snort.org/snort-db/sid.html?sid=223 9. seq – TCP seq number GEN:SID 1:223 10. logto – log packets matching this rule to this specified filename Message DDOS Trin00 Daemon to Master PONG message 11. dsize – packet payload detected 12. offset – begin content search at this offset Rule alert udp $EXTERNAL_NET any -> $HOME_NET 31335 (msg:"DDOS Trin00 Daemon to Master PONG message 13. depth – search content to this byte depth in file detected"; content:"PONG"; reference:arachnids,187; 14. msg – message to be sent when packet classtype:attempted-recon; sid:223; rev:3;) generates event 23 24 All Snort signature examples from http://snort.org

Stacheldraht Ping of Death • One attack may have many different signatures 25 26 All Snort signature examples from http://snort.org SQL Slammer SQL Slammer 27 28 All Snort signature examples from http://snort.org Nimda Trying for high performance • Content matching is most expensive process – Performed after all other rules are tested – Can use offset and depth keywords to limit amount of data to be searched 29 30 All Snort signature examples from http://snort.org

Trying for high performance Uses of Snort 1) To fill holes in commercial vendor’s network-based • Deep packet inspection attempts to solve intrusion detection tools: the problem of expensive content matching – When new attack comes out and signature updates from • DPI engines scrutinize each packet vendor are slow – Run Snort locally on test network to determine signature (including the data payload) as it traverses – Write a Snort rule the firewall, and rejects or allows the packet – Use BPF command line filtering to watch only service or based upon a ruleset that is implemented by protocol of interest the firewall administrator. – Snort can be used as a specialized detector for a single attack or family of attacks in this mode 31 32 Uses of Snort Uses of Snort 2) As a Honeypot monitor 3) Used as a “passive trap” – Problem with honeypots is that the services they run – Administrators know which services are NOT have to be started before they will record anything, thus available on their networks miss events such as stealth port scans or binary data – By default, packets looking for those services streams (unless they perform packet level monitoring) are malicious traffic (port scanning, – The data coming out of a honeypot requires a skilled analyst to properly interpret results. backdoors,…) – Snort can be of great help to the analyst/administrator – Write Snort rules to watch for traffic headed to with its packet classification and alerting functionality. these non-existent services 33 34 Challenges Snort faces as a Uses of Snort stand-alone NIDS 4) In focused monitoring: • The constant increase in network speed and – Watch a single critical node or service on the network. throughput – processors cannot keep up – Example: the Sendmail SMTP server has a well-known • Sensors cannot maintain information about (and extensive) list of vulnerabilities. attacks in progress (e.g., in the case of multi- – Single Snort sensor can be deployed with a rule set step attacks) covering all known Sendmail attacks. – This concept can be extended to any network • Novel approaches to NID necessary to technology that is under-represented by commercial manage ever-increasing data volume NIDS. 35 36