- •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
they would bow again, and so on, until they finally looked up with a pained expression and walked away. I cannot look at an Echo-Chargen trace without thinking about that little trick. The example trace is UDP, but I have found you can make the oscillation with the TCP variant of these services as well, although I haven't figured out how to spoof the address and make it
work. For fun, if you have Cisco routers, telnet to your router's Echo or Chargen port. For instance, $ telnet myrouter 7 accesses the TCP echo port. Many Cisco routers seem to
have these open by default.
Elegant Kills
Brute-force attacks tend to rely on spoofed addresses to provide a bit of cover for the attacker. One packet kills can operate with a much lower footprint. They take advantage of flaws in the IP stack's capability to deal with illegal conditions, or even bad programming. The following sections look at several of these, including Echo-Chargen, Teardrop, Land, and a fun little attack against an adventure game called Doom.
Teardrop
Smurf and Echo-Chargen work by brute force; Teardrop works by finesse. It takes advantage of a simple fact: Network protocol stacks are not good at math. They are especially bad at negative numbers. This is another ancient attack, and although it is still in use, I do not see it that often. My intrusion-detection students must complete a practical assignment to achieve certification. The assignment varies in the details, but essentially it is to collect and analyze about 10 network traces. Quite often, they instrument their cable modems and collect data for a while, and Teardrop shows up on many of the practical assignments. Therefore, it is still being tried. The next question is this: Does it still work? Sure, but only on unpatched or older operating systems. The following is an example of a Teardrop trace:
10:25:48.205383 wile-e-coyote.45959 > target.net.3964: udp 28 (frag 242:36@0+)
10:25:48.205383 wile-e-coyote > target.net: (frag 242:4@24)
Because it has been a long time since Chapter 3, "Fragmentation," perhaps a reminder is in order. The top line shows a fragment named 242 with 36 octets of data for offset 0. The second line shows 4 more octets of data for offset 24. Therefore to service this packet, the operating system would have to rewind from 36 to 24. Negative numbers can translate to very large positive numbers, and so the operating system is likely to scribble all over some other program's section of memory. Try this a couple times and you kill the system.
The core problem is that many IP stacks do not know how to deal with negative, or illegal, numbers. I most recently saw this when the PROTOS toolkit was released along with a CERT advisory on February 12, 2002. HD Moore, a security researcher, was running the toolkit against a Red Hat, Linux 7 box and caused a segmentation fault. We tried to look at this packet with Ethereal, but it killed Ethereal. A TCPdump trace is shown here:
18:49:54.519006 10.0.0.1.59108 > 10.0.0.2.161: GetRequest(33)
.1.3.6.1.2.1.1.5.0[len3<asnlen4294967295] (DF) 4500 004c 0000 4000 4011 269f 0a00 0001
0a00 0002 e6e4 00a1 0038 0efc 302e 0201
0004 0670 7562 6c69 63a0 2102 0206 9202
0100 0201 0030 1530 1306 082b 0601 0201
0105 0044 84ff ffff ff02 0100
Notice that, at the top of the trace, TCPdump is trying to tell us something about the Abstract
Syntax Notation (ASN.1) length being over 4 billion bytes long. Even with modern systems, that is one heck of a lot of memory to allocate to a single packet. The 84ff ffff ff02 near the
end of the hex dump is the value in the length field, if you were just dying to know that.
It is just a matter of time until someone finds another field in the IP stack to do this trick with.
Note that another characteristic of fragmentation is that it eludes some intrusion-detection systems that do not support packet reassembly.
Land Attack
The Land attack is famous for two reasons: It is a very elegant oneor two-packet kill, and it is the "hello world" of intrusion-detection filters. As soon as I heard about it, I wrote a filter to detect it—after all, you cannot ask for an easier signature. But we never captured an attack. I was afraid we had made some kind of silly error in the filter, so I downloaded the attack exploit and compiled it. Now what system could I run it against? I needed something that had intrusion detection running so that I could get a trace of the attack. At that time, we had only intrusion detection in the DMZ. What about the web server? It was in the DMZ. So, I put the web server's IP address into the exploit script, fired the exploit, and boom, the web server crashed as advertised. I hurried over to reboot the web server and never gave the experiment a second thought. Well, until our intrusion-detection analyst called. She was so excited because she had found an actual Land attack and had already reported it to our CIRT. I just kind of said, "Great job," and spent the rest of the day quietly whistling to myself. The detect she saw is shown in the trace below:
12/03/97 02:19:48 |
192.168.1.1 |
80 |
-> 192.168.1.1 |
80 |
192.168.1.1 |
31337 -> 192.168.1.1 |
|
12/03/97 02:21:53 |
|||
31337 |
|
|
|
I hope the statute of limitations for this deed has passed by the time this book gets printed.
We're Doomed
I love the culture I live in. First, they convince my kid to play with dolls; they just call them action figures. When he finally gets too old to play with dolls, he trades his plastic action figures in for cyber action figures. Some of the great cyber action figures, complete with horns and everything, live in the game of Doom.
Doom is played on port 666. So what is going on in the following trace?
12/03/97 02:19:48 |
0 |
206.256.199.8 |
19 |
-> 192.168.102.3 |
666 |
0 |
206.256.199.8 |
19 |
-> 164.256.23.100 |
12/03/97 02:21:53 |
666 |
0 |
206.256.199.8 |
19 |
-> 164.256.140.32 |
12/03/97 02:28:20 |
||||
666 |
0 |
206.256.199.8 |
19 |
-> 192.168.18.28 |
12/03/97 02:30:29 |
||||
666 |
0 |
206.256.199.8 |
19 |
-> 164.256.67.121 |
12/03/97 02:30:44 |
||||
666 |
0 |
206.256.199.8 |
19 |
-> 164.256.140.32 |
12/03/97 02:34:47 |
||||
666 |
0 |
206.256.199.8 |
19 |
-> 147.168.130.93 |
12/03/97 02:35:28 |
||||
666 |
0 |
206.256.199.8 |
19 |
-> 192.168.18.28 |
12/03/97 02:36:56 |
||||
666 |
0 |
206.256.199.8 |
19 |
-> 147.168.153.78 |
12/03/97 02:39:23 |
||||
666 |
0 |
206.256.199.8 |
19 |
-> 147.168.130.93 |
12/03/97 02:41:55 |
||||
666 |
|
|
|
|
Apparently, some individuals are so bored that they are spoofing a bunch of addresses, such that if these attackers chance on folks playing Doom, the Chargen output might disrupt the game in some way (and a single packet can be enough to do the trick).
The following simulated reconstructed trace shows the cause and effect of such an action, finding a Doom server. Again, 147.168.153.78 in this case is spoofed, and the activity is being caused by an unknown IP address. Although Doom traffic is becoming more rare these days, a similar game called Quake still generates a packet or two. Here is the Doom trace:
12/03/97 02:39:22 |
0 |
147.168.153.78 |
666 |
-> 206.256.199.8 |
19 |
0 |
206.256.199.8 |
19 |
-> 147.168.153.78 |
12/03/97 02:39:23 |
||||
666 |
|
|
|
|
Actually, I had not seen this trace in a long time and was going to remove it from the material; then the following variant showed up again in January 1999. Note that the intrusion-detection system did flag this. What tips us off and lets us know that?
17:58:13.725824 doomer.echo > 172.20.196.51.666: udp 1024 (DF) 17:58:13.746748 doomer.echo > 172.20.196.51.666: udp 426 (DF) 18:03:24.133079 doomer.echo > 172.20.46.79.666: udp 1024 (DF) 18:03:24.157238 doomer.echo > 172.20.46.79.666: udp 426 (DF)
21:05:22.503299 dns1.arpa.net.domain > doomer.domain: 42815 (44) 21:05:26.152327 doomer.domain > dns1.arpa.net.domain: 42815* 2/0/0 (98) (DF) 23:50:15.728480 doomer.echo > 172.20.76.2.666: udp 1024 (DF) 23:50:15.751821 doomer.echo > 172.20.76.2.666: udp 426 (DF)
Sure! The domain lookup is a big hint! We have already discussed Echo and Chargen, and we have seen them show up together. What is going on? The attacker is bouncing off an open echo port to cover his tracks, the receiving computer will see the system with echo port in the source address field, not the attacker. The attacker spoofs the address of the target machine to a machine, and then bounces traffic off these ports onto the game. The preceding signature is a tough one; 7 to 666 is also a classic signature of a UDP flood denial-of-service program called Pepsi. However, Pepsi scanners do not usually pause for a refreshing DNS lookup.