- •Network Intrusion Detection, Third Edition
- •Table of Contents
- •Copyright
- •About the Authors
- •About the Technical Reviewers
- •Acknowledgments
- •Tell Us What You Think
- •Introduction
- •Chapter 1. IP Concepts
- •Layers
- •Data Flow
- •Packaging (Beyond Paper or Plastic)
- •Bits, Bytes, and Packets
- •Encapsulation Revisited
- •Interpretation of the Layers
- •Addresses
- •Physical Addresses, Media Access Controller Addresses
- •Logical Addresses, IP Addresses
- •Subnet Masks
- •Service Ports
- •IP Protocols
- •Domain Name System
- •Routing: How You Get There from Here
- •Summary
- •Chapter 2. Introduction to TCPdump and TCP
- •TCPdump
- •TCPdump Behavior
- •Filters
- •Binary Collection
- •TCPdump Output
- •Absolute and Relative Sequence Numbers
- •Dumping in Hexadecimal
- •Introduction to TCP
- •Establishing a TCP Connection
- •Server and Client Ports
- •Connection Termination
- •The Graceful Method
- •The Abrupt Method
- •Data Transfer
- •What's the Bottom Line?
- •TCP Gone Awry
- •An ACK Scan
- •A Telnet Scan?
- •TCP Session Hijacking
- •Summary
- •Chapter 3. Fragmentation
- •Theory of Fragmentation
- •All Aboard the Fragment Train
- •The Fragment Dining Car
- •The Fragment Caboose
- •Viewing Fragmentation Using TCPdump
- •Fragmentation and Packet-Filtering Devices
- •The Don't Fragment Flag
- •Malicious Fragmentation
- •TCP Header Fragments
- •Teardrop
- •Summary
- •Chapter 4. ICMP
- •ICMP Theory
- •Why Do You Need ICMP?
- •Where Does ICMP Fit In?
- •Understanding ICMP
- •Summary of ICMP Theory
- •Mapping Techniques
- •Tireless Mapper
- •Efficient Mapper
- •Clever Mapper
- •Cerebral Mapper
- •Summary of Mapping
- •Normal ICMP Activity
- •Host Unreachable
- •Port Unreachable
- •Admin Prohibited
- •Need to Frag
- •Time Exceeded In-Transit
- •Embedded Information in ICMP Error Messages
- •Summary of Normal ICMP
- •Malicious ICMP Activity
- •Smurf Attack
- •Tribe Flood Network
- •WinFreeze
- •Loki
- •Unsolicited ICMP Echo Replies
- •Theory 1: Spoofing
- •Theory 2: TFN
- •Theory 3: Loki
- •Summary of Malicious ICMP Traffic
- •To Block or Not to Block
- •Unrequited ICMP Echo Requests
- •Kiss traceroute Goodbye
- •Silence of the LANs
- •Broken Path MTU Discovery
- •Summary
- •Chapter 5. Stimulus and Response
- •The Expected
- •Request for Comments
- •TCP Stimulus-Response
- •Destination Host Listens on Requested Port
- •Destination Host Not Listening on Requested Port
- •Destination Host Doesn't Exist
- •Destination Port Blocked
- •Destination Port Blocked, Router Doesn't Respond
- •UDP Stimulus-Response
- •Destination Host Listening on Requested Port
- •Destination Host Not Listening on Requested Port
- •Windows tracert
- •TCPdump of tracert
- •Protocol Benders
- •Active FTP
- •Passive FTP
- •UNIX Traceroute
- •Summary of Expected Behavior and Protocol Benders
- •Abnormal Stimuli
- •Evasion Stimulus, Lack of Response
- •Evil Stimulus, Fatal Response
- •No Stimulus, All Response
- •Unconventional Stimulus, Operating System Identifying Response
- •Bogus "Reserved" TCP Flags
- •Anomalous TCP Flag Combinations
- •No TCP Flags
- •Summary of Abnormal Stimuli
- •Summary
- •Chapter 6. DNS
- •Back to Basics: DNS Theory
- •The Structure of DNS
- •Steppin' Out on the Internet
- •DNS Resolution Process
- •TCPdump Output of Resolution
- •Strange TCPdump Notation
- •Caching: Been There, Done That
- •Reverse Lookups
- •Master and Slave Name Servers
- •Zone Transfers
- •Summary of DNS Theory
- •Using DNS for Reconnaissance
- •The nslookup Command
- •Name That Name Server
- •HINFO: Snooping for Details
- •List Zone Map Information
- •Tainting DNS Responses
- •A Weak Link
- •Cache Poisoning
- •Summary
- •Part II: Traffic Analysis
- •Chapter 7. Packet Dissection Using TCPdump
- •Why Learn to Do Packet Dissection?
- •Sidestep DNS Queries
- •Normal Query
- •Evasive Query
- •Introduction to Packet Dissection Using TCPdump
- •Where Does the IP Stop and the Embedded Protocol Begin?
- •Other Length Fields
- •The IP Datagram Length
- •Increasing the Snaplen
- •Dissecting the Whole Packet
- •Freeware Tools for Packet Dissection
- •Ethereal
- •tcpshow
- •Summary
- •Chapter 8. Examining IP Header Fields
- •Insertion and Evasion Attacks
- •Insertion Attacks
- •Evasion Attacks
- •IP Header Fields
- •IP Version Number
- •Protocol Number
- •The Don't Fragment (DF) Flag
- •The More Fragments (MF) Flag
- •Mapping Using Incomplete Fragments
- •IP Numbers
- •IP Identification Number
- •Time to Live (TTL)
- •Looking at the IP ID and TTL Values Together to Discover Spoofing
- •IP Checksums
- •Summary
- •Chapter 9. Examining Embedded Protocol Header Fields
- •Ports
- •TCP Checksums
- •TCP Sequence Numbers
- •Acknowledgement Numbers
- •TCP Flags
- •TCP Corruption
- •ECN Flag Bits
- •Operating System Fingerprinting
- •Retransmissions
- •Using Retransmissions Against a Hostile Host—LaBrea Tarpit Version 1
- •TCP Window Size
- •LaBrea Version 2
- •Ports
- •UDP Port Scanning
- •UDP Length Field
- •ICMP
- •Type and Code
- •Identification and Sequence Numbers
- •Misuse of ICMP Identification and Sequence Numbers
- •Summary
- •Chapter 10. Real-World Analysis
- •You've Been Hacked!
- •Netbus Scan
- •How Slow Can you Go?
- •RingZero Worm
- •Summary
- •Chapter 11. Mystery Traffic
- •The Event in a Nutshell
- •The Traffic
- •DDoS or Scan
- •Source Hosts
- •Destination Hosts
- •Scanning Rates
- •Fingerprinting Participant Hosts
- •Arriving TTL Values
- •TCP Window Size
- •TCP Options
- •TCP Retries
- •Summary
- •Part III: Filters/Rules for Network Monitoring
- •Chapter 12. Writing TCPdump Filters
- •The Mechanics of Writing TCPdump Filters
- •Bit Masking
- •Preserving and Discarding Individual Bits
- •Creating the Mask
- •Putting It All Together
- •TCPdump IP Filters
- •Detecting Traffic to the Broadcast Addresses
- •Detecting Fragmentation
- •TCPdump UDP Filters
- •TCPdump TCP Filters
- •Filters for Examining TCP Flags
- •Detecting Data on SYN Connections
- •Summary
- •Chapter 13. Introduction to Snort and Snort Rules
- •An Overview of Running Snort
- •Snort Rules
- •Snort Rule Anatomy
- •Rule Header Fields
- •The Action Field
- •The Protocol Field
- •The Source and Destination IP Address Fields
- •The Source and Destination Port Field
- •Direction Indicator
- •Summary
- •Chapter 14. Snort Rules - Part II
- •Format of Snort Options
- •Rule Options
- •Msg Option
- •Logto Option
- •Ttl Option
- •Id Option
- •Dsize Option
- •Sequence Option
- •Acknowledgement Option
- •Itype and Icode Options
- •Flags Option
- •Content Option
- •Offset Option
- •Depth Option
- •Nocase Option
- •Regex Option
- •Session Option
- •Resp Option
- •Tag Option
- •Putting It All Together
- •Summary
- •Part IV: Intrusion Infrastructure
- •Chapter 15. Mitnick Attack
- •Exploiting TCP
- •IP Weaknesses
- •SYN Flooding
- •Covering His Tracks
- •Identifying Trust Relationships
- •Examining Network Traces
- •Setting Up the System Compromise?
- •Detecting the Mitnick Attack
- •Trust Relationship
- •Port Scan
- •Host Scan
- •Connections to Dangerous Ports
- •TCP Wrappers
- •Tripwire
- •Preventing the Mitnick Attack
- •Summary
- •Chapter 16. Architectural Issues
- •Events of Interest
- •Limits to Observation
- •Human Factors Limit Detects
- •Limitations Caused by the Analyst
- •Limitations Caused by the CIRTs
- •Severity
- •Criticality
- •Lethality
- •Countermeasures
- •Calculating Severity
- •Scanning for Trojans
- •Analysis
- •Severity
- •Host Scan Against FTP
- •Analysis
- •Severity
- •Sensor Placement
- •Outside Firewall
- •Sensors Inside Firewall
- •Both Inside and Outside Firewall
- •Analyst Console
- •Faster Console
- •False Positive Management
- •Display Filters
- •Mark as Analyzed
- •Drill Down
- •Correlation
- •Better Reporting
- •Event-Detection Reports
- •Weekly/Monthly Summary Reports
- •Summary
- •Chapter 17. Organizational Issues
- •Organizational Security Model
- •Security Policy
- •Industry Practice for Due Care
- •Security Infrastructure
- •Implementing Priority Countermeasures
- •Periodic Reviews
- •Implementing Incident Handling
- •Defining Risk
- •Risk
- •Accepting the Risk
- •Trojan Version
- •Malicious Connections
- •Mitigating or Reducing the Risk
- •Network Attack
- •Snatch and Run
- •Transferring the Risk
- •Defining the Threat
- •Recognition of Uncertainty
- •Risk Management Is Dollar Driven
- •How Risky Is a Risk?
- •Quantitative Risk Assessment
- •Qualitative Risk Assessments
- •Why They Don't Work
- •Summary
- •Chapter 18. Automated and Manual Response
- •Automated Response
- •Architectural Issues
- •Response at the Internet Connection
- •Internal Firewalls
- •Host-Based Defenses
- •Throttling
- •Drop Connection
- •Shun
- •Proactive Shunning
- •Islanding
- •Reset
- •Honeypot
- •Proxy System
- •Empty System
- •Honeypot Summary
- •Manual Response
- •Containment
- •Freeze the Scene
- •Sample Fax Form
- •On-Site Containment
- •Site Survey
- •System Containment
- •Hot Search
- •Eradication
- •Recovery
- •Lessons Learned
- •Summary
- •Chapter 19. Business Case for Intrusion Detection
- •Part One: Management Issues
- •Bang for the Buck
- •The Expenditure Is Finite
- •Technology Used to Destabilize
- •Network Impacts
- •IDS Behavioral Modification
- •The Policy
- •Part of a Larger Strategy
- •Part Two: Threats and Vulnerabilities
- •Threat Assessment and Analysis
- •Threat Vectors
- •Threat Determination
- •Asset Identification
- •Valuation
- •Vulnerability Analysis
- •Risk Evaluation
- •Part Three: Tradeoffs and Recommended Solution
- •Identify What Is in Place
- •Identify Your Recommendations
- •Identify Options for Countermeasures
- •Cost-Benefit Analysis
- •Follow-On Steps
- •Repeat the Executive Summary
- •Summary
- •Chapter 20. Future Directions
- •Increasing Threat
- •Improved Targeting
- •How the Threat Will Be Manifested
- •Defending Against the Threat
- •Skills Versus Tools
- •Analysts Skill Set
- •Improved Tools
- •Defense in Depth
- •Emerging Techniques
- •Virus Industry Revisited
- •Smart Auditors
- •Summary
- •Part V: Appendixes
- •Appendix A. Exploits and Scans to Apply Exploits
- •False Positives
- •All Response, No Stimulus
- •Scan or Response?
- •SYN Floods
- •Valid SYN Flood
- •False Positive SYN Flood
- •Back Orifice?
- •IMAP Exploits
- •10143 Signature Source Port IMAP
- •111 Signature IMAP
- •Source Port 0, SYN and FIN Set
- •Source Port 65535 and SYN FIN Set
- •DNS Zone Followed by 0, SYN FIN Targeting NFS
- •Scans to Apply Exploits
- •mscan
- •Son of mscan
- •Access Builder?
- •Single Exploit, Portmap
- •rexec
- •Targeting SGI Systems?
- •Discard
- •Weird Web Scans
- •IP-Proto-191
- •Summary
- •Appendix B. Denial of Service
- •Brute-Force Denial-of-Service Traces
- •Smurf
- •Directed Broadcast
- •Echo-Chargen
- •Elegant Kills
- •Teardrop
- •Land Attack
- •We're Doomed
- •nmap
- •Distributed Denial-of-Service Attacks
- •Intro to DDoS
- •DDoS Software
- •Trinoo
- •Stacheldraht
- •Summary
- •Appendix C. Detection of Intelligence Gathering
- •Network and Host Mapping
- •Host Scan Using UDP Echo Requests
- •Netmask-Based Broadcasts
- •Port Scan
- •Scanning for a Particular Port
- •Complex Script, Possible Compromise
- •"Random" Port Scan
- •Database Correlation Report
- •SNMP/ICMP
- •FTP Bounce
- •NetBIOS-Specific Traces
- •A Visit from a Web Server
- •Null Session
- •Stealth Attacks
- •Explicit Stealth Mapping Techniques
- •FIN Scan
- •Inverse Mapping
- •Answers to Domain Queries
- •Answers to Domain Queries, Part 2
- •Fragments, Just Fragments
- •Measuring Response Time
- •Echo Requests
- •Actual DNS Queries
- •Probe on UDP Port 33434
- •3DNS to TCP Port 53
- •Worms as Information Gatherers
- •Pretty Park Worm
- •RingZero
- •Summary
So, we had a false positive in a sense; it was not an attack. Instead, it was just a young kid who figured that because he could configure a DNS system, he was "eleet." He just needed a bit of calibrating and everything was all right. Ignoring the traffic leads to some dangerous choices; an analyst should not disable an intrusion-detection system filter, for example, for a potentially dangerous attack signature. The analyst must verify that the detect is not a false positive before reporting it. Some people think I was overly harsh with the young chap. I would ask them to keep in mind the problems such activity could cause at the CIRT level. Remember, only you can prevent false positives.
Note that modern DNS servers running BIND 8 choose an unprivileged port above 1024, but they probably won't choose 31337 consistently.
This story also illustrates how important it is for your organization not just to report detects to your CIRT, but also to share with other intrusion-detection-capable organizations that have something in common with you. This is how I determined the 31337 wasn't just a fluke. Also, at times you might need to shun an Internet address block if they are being antisocial.
Shunning Works!
Once, a major Internet service provider was not providing support when its address block was being used to attack our sites. Time and time again we tried to reach its organization to get help. Finally, we blocked them (email, web, the whole nine yards). Within three weeks, they were screaming in pain because they were starting to lose money; corporate customers were pulling out. They agreed to be responsive in the future and to triple their Internet abuse staff. Who could ask for more?
This concludes the discussion about common false positives. Strictly speaking, the exploit is when the attacker goes for the kill and the software or technique exploits a vulnerability in a computer system. In actual practice, it is very difficult to distinguish between scanning for vulnerabilities and the actual attack. In fact, the current generation of attack tools do both; they scan to find vulnerabilities and they also attack. Therefore, this section contains a bit of mix and match, primarily considering vulnerabilities, but also touching on scanning for vulnerabilities when appropriate.
I am not the only one struggling with categorizing these traces in a nice organized manner. The research side of intrusion detection has been working on this problem for years and has not yet produced an accepted taxonomy of attacks. The Database of Vulnerabilities, Exploits, and Signatures (DOVES) project released a CD-ROM with its work on categorization in February 1999. For further information, contact Dr. Matt Bishop (bishop@cs.ucdavis.edu). Mitre has fostered the creation of the Common Vulnerability Enumeration (CVE). The CVE is probably the most significant effort and enjoys wide support from the vendor community; more than 2,000 vulnerabilities have been accepted by its editorial board at this time with an additional 1,700 candidates. For further information, check out CVE's web site at cve.mitre.org.
The following section examines traces from IMAP exploit attempts.
IMAP Exploits
No series of exploits has reaped as much havoc on the Internet as IMAP. Buffer overflows, such as the IMAP vulnerability, are not uncommon; several major problems have occurred with DNS buffer overflows as well. Because these programs run as root, the attack is potentially devastating, leaving the attacker with root access.
10143 Signature Source Port IMAP
The pattern here is the classic pattern of one of the most devastating buffer overflows ever unleashed on the Internet. Note that this scan contains two destination networks. Also note the time gap between packets. The gap is so large because this scan was targeting every Class B network on the Internet. This trace comes from mid-1997, and this particular signature is rarely seen now:
14:13:54.847401 newbie.hacker.org.10143 > 192.168.1.1.143: S 14:24:58.151128 newbie.hacker.org.10143 > 172.31.1.1.143: S 14:35:40.311513 newbie.hacker.org.10143 > 192.168.1.2.143: S 14:43:55.459380 newbie.hacker.org.10143 > 192.168.2.1.143: S 14:54:58.693768 newbie.hacker.org.10143 > 172.31.2.1.143: S 15:05:41.039905 newbie.hacker.org.10143 > 192.168.2.2.143: S 15:13:59.948065 newbie.hacker.org.10143 > 192.168.3.1.143: S
111 Signature IMAP
The following trace is another IMAP scan/exploit that has a repeatable signature. The fixed source port, the fixed sequence and acknowledgment fields with the 111, and of course the window size of 0 is a nice touch. From a signature-use standpoint, this one is particularly interesting. We started to see it in late 1998 following the large numbers of source port 0 and SF set scans, (these are shown next), and then it disappeared. In early 1999, this signature reappeared. I have no idea what the story behind this behavior is; it is as if the software got lost for a few months! Here is the trace:
00:25:09.57 prober.2666 > relay.143: S 111:111(0) win 0 00:25:09.59 prober.2666 > relay.143: S 111:111(0) win 0 00:42:50.79 prober.2666 > web.143: S 111:111(0) win 0 00:43:24.05 prober.2666 > relay.143: S 111:111(0) win 0 00:43:24.07 prober.2666 > relay.143: S 111:111(0) win 0 00:44:20.42 prober.2666 > relay2.143: S 111:111(0) win 0 00:44:42.62 prober.2666 > ns2.143: S 111:111(0) win 0 00:44:42.64 prober.2666 > ns2.143: S 111:111(0) win 0 00:44:42.67 prober.2666 > ns1.143: S 111:111(0) win 0 00:44:42.69 prober.2666 > ns1.143: S 111:111(0) win 0
Exploit Ports with SYN/FIN Set
One of the fascinating patterns to watch has been the various mutations of a pattern called SYN/FIN (or more commonly, SF). This is one of the most significant patterns in intrusion detection in the sense that an analyst will almost certainly have seen this and should be expected to know this pattern. The earliest instantiation I am aware of is the attack Jackal.c from late 1996, and the most recent variation I have seen was a buffer overflow against secure shell in December 2001. Attackers set SYN/FIN because it passes through a static packet filter, because they block on a SYN only. However, if a packet with SYN/FIN gets to either a Windows or UNIX system with that port open, they respond with a SYN/ACK. This is great from an attacker's point of view, because it penetrates the perimeter and still lets them compromise the system. Take your time with this section to look at some of the major variations of this pattern and to learn its history.
Source Port 0, SYN and FIN Set
The first clue I had about the following trace was a post to bugtraq in March 1998. I did not actually pick this trace up for another month. Here, the signature is source port 0, which is not logical; and both SYN and FIN flags are set, which is also not logical. An intrusion-detection system ought to be able to pick up this kind of trace! Note the random-appearing subnets 26, 24, 17, 16, 24, as well as hosts. This is possibly to make the scan less obvious. Also note the speed of the scan. Scan detectors should be able to detect five connect attempts to five different hosts in about a quarter of a second. Take a look:
13:10:33.281198 newbie.hacker.org.0 > 192.168.26.203.143: SF 374079488:374079488(0) win 512
13:10:33.334983 newbie.hacker.org.0 > 192.168.24.209.143: SF 374079488:374079488(0) win 512
13:10:33.357565 newbie.hacker.org.0 > 192.168.17.197.143: SF 374079488:374079488(0) win 512
13:10:33.378115 newbie.hacker.org.0 > 192.168.16.181.143: SF 374079488:374079488(0) win 512
13:10:33.474966 newbie.hacker.org.0 > 192.168.24.194.143: SF 374079488:374079488(0) win 512
The preceding scan presents several interesting advantages. FINs might be allowed through filtering devices even if SYNs are not. This improves the probability of a response. Also, because the FIN signals connection tear down, some logging systems will potentially fail to report the connect attempt. SYN/FIN was a trademark of a scanning tool named jackal, which was purported to penetrate firewalls. The challenge with this signature is that more than one exploit/scan is believed responsible for creating it. A more current tool that can generate a similar signature is nmap, the most effective intelligence-gathering tool yet deployed by attackers.
Source Port 65535 and SYN FIN Set
The following trace is an interesting variant of the preceding trace. This was collected in November 1998. There is speculation that this pattern is probably the result of an attack tool that enables the user to select any source port she wants. Although I have no doubt that such a tool either exists or will exist in the near future, that does not begin to explain why intrusiondetection analysts have collected hundreds of examples with source port 0 and a large number with source port 65535. In the early days, before 1999, analysts had not yet collected any examples with any other source port and SYN/FIN set. The source port was hard-coded into the software and that the source port 65535 is a second-generation code branch from the original. The trace follows:
16:11:38.13 IMAPPER.65535 > ns2.org.143: SF 3794665472:3794665472(0) win 512 16:11:38.13 IMAPPER.65535 > ns2.org.143: SF 3794665472:3794665472(0) win 512
DNS Zone Followed by 0, SYN FIN Targeting NFS
Although IMAP has been an effective target of opportunity for attackers, it certainly isn't the only target. The following trace has similarities to the source port 0 and SYN/FIN set pattern. In this case, however, we are dealing with a double dipper. First, the attacker tries an attack against TCP 53, which is also DNS. The difference is you use TCP 53 rather than UDP 53 when you want a zone transfer—in essence, a host table of the site.