- •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
Considering that the TCP sequence number field is 32 bits long, these are very small initial sequence numbers—quite unusual. All the TCP sequence numbers from this scan were lightweight, and when the activity was dumped in hex, the reason why was discovered. The high-order 16 bits of the TCP sequence number were always 0s. This is confirmation that some kind of sequence number manipulation was performed, and it becomes a signature of this activity.
Fragments, Just Fragments
Consider this final example of an inverse mapping technique. As you have already learned, only the first fragment chunk comes with protocol information. Attackers using this technique (along with some interesting variations) were able to penetrate older firewalls and filtering routers. The firewalls would assume that this was just another segment of traffic that had already passed their access lists. Needless to say, this has been fixed in most vendors' products.
In this case, however, the prober isn't particularly interested in firewall penetration. Once again, if one of the target hosts does not exist, the router sends back an unreachable message. The attacker can then compile a list of all the hosts that do not exist and, by taking the inverse of that list, has a list of the hosts that do exist. This is why this class of techniques is called inverse mapping. Take a look:
18:32:21.050033 PROBER > 192.168.5.71: (frag 9019:480@552) 18:32:21.109287 PROBER > 192.168.5.72: (frag 9275:480@552) 18:32:21.178342 PROBER > 192.168.5.73: (frag 9531:480@552) 18:32:21.295332 PROBER > 192.168.5.74: (frag 9787:480@552) 18:32:21.344322 PROBER > 192.168.5.75: (frag 10299:480@552) 18:32:21.384284 PROBER > 192.168.5.76: (frag 10555:480@552) 18:32:21.431136 PROBER > 192.168.5.77: (frag 11067:480@552) 18:32:21.478246 PROBER > 192.168.5.78: (frag 11579:480@552) 18:32:21.522631 PROBER > 192.168.5.79: (frag 11835:480@552)
Measuring Response Time
Lately, we've seen a lot of traffic coming from all over the place directed to DNS servers, but not for the purpose of querying for DNS information or ostensibly of malicious intent. What is happening is that companies have developed software that tries to deliver the best possible response time to web requests. It has been demonstrated that most users will tolerate about an eight-second delay in receiving responses and after that they might go to a competitor site with better response time. It has become a matter of e-business survival and profitability to offer good response time, and because necessity is the mother of invention, software has been created to accomplish the mission. The patterns explained in this section are from a product known as 3DNS.
One technique is to associate the user request with an authoritative DNS server for the user's host and find the response time to the DNS server. This assumes that the authoritative DNS server and the user's hosts are geographically close, which might not always be the case. Why not just find the distance to the user's host? Indeed, this seems more logical, but many sites are well protected, and access to the user's host is not always available. They figure there is a better chance of having some kind of access to the DNS server, which may or may not be the case.
There has been a lot of hue and cry from analysts who see their IDS fired because of the traffic generated by this software. Many sites feel violated because traffic is directed to the sacred DNS server, of all hosts. And, many more sites don't understand what is happening and perceive this activity to be an attack of some sort. The final objection is that this is unauthorized information gathering, regardless of whether it benefits the end user.
Let's take a look at some of the signatures associated with this type of traffic. One thing that you should keep in mind is that many different web sites use this software and so you will see many different source IPs. Because of the unique signatures generated from multiple source IPs, this has been mistaken for some kind of coordinated attack. As you will see, however, it
really isn't.
Echo Requests
No surprise with the following TCPdump activity to measure response time to your DNS server. The echo request is issued and the response time is measured based on receipt of an ICMP echo
reply, if there is one:
10:25:44.070000 216.32.68.13 > mydns.com: icmp: echo request 10:25:44.070000 216.32.68.13 > mydns.com: icmp: echo request 10:25:44.070000 216.32.68.13 > mydns.com: icmp: echo request 10:30:01.530000 216.32.68.13 > mydns.com: icmp: echo request 10:30:01.530000 216.32.68.13 > mydns.com: icmp: echo request 10:30:01.550000 216.32.68.13 > mydns.com: icmp: echo request 10:30:25.660000 209.67.29.8 > mydns.com: icmp: echo request 10:30:25.660000 209.67.29.8 > mydns.com: icmp: echo request 10:30:25.670000 209.67.29.8 > mydns.com: icmp: echo request 10:32:12.520000 209.67.78.200 > mydns.com: icmp: echo request
As you have learned, however, many sites block ICMP echo requests because ICMP has capability to map sites both actively with a ping, and also by eliciting error messages that give away the position of hosts and routers in a site. And, if this is the case, an attacker, or even a
service provider using a tool like 3DNS might focus their reconnaissance on the DNS server.
Actual DNS Queries
If the user's DNS server didn't respond to the ICMP echo request and the server using the 3DNS probing software is configured to continue to try to make contact with the DNS server, more
activity is sent, as shown here:
216.32.68.11.3200 > mydns.com.53: 0 [0q] Type0 (Class 0)?. (36) mydns.com.53 > 216.32.68.11.3200: 0 FormErr [0q] 0/0/0 (12) DF 216.32.68.11.3201 > mydns.com.53: 256 [0q] Type0 (Class 0)? . (36) mydns.com.53 > 216.32.68.11.3201: 0 FormErr [0q] 0/0/0 (12) DF 216.32.68.11.3202 > mydns.com.53: 512 [0q] Type0 (Class 0)? . (36) mydns.com.53 > 216.32.68.11.3202: 0 FormErr [0q] 0/0/0 (12) DF
A real DNS query is not issued, but one is sent to UDP port 53 with a DNS message of all 0s. TCPdump performs some integrity checking of the DNS message and if it discovers what it considers to be noteworthy fields, it reports them. The 0q means that there were zero queries
in the DNS message, for example. Normally, for types other than inverse queries there will be at least one query. That is why TCPdump reported it and all other 0-padded fields it considers to be odd. This elicits an error response from mydns.com, which is then used to compute the
round-trip time.
Probe on UDP Port 33434
Here is yet a third type of activity directed at the DNS server if the others have failed:
209.67.78.203.3310 > mydns.com.33434: udp 36 [ttl 1] 209.67.78.203.3311 > mydns.com.33434: udp 36 (ttl 2) 216.32.68.10.3307 > mydns.com.33434: udp 36 [ttl 1] 216.32.68.10.3308 > mydns.com.33434: udp 36 (ttl 2) 216.32.68.10.3307 > mydns.com.33434: udp 36 [ttl 1] 216.32.68.10.3308 > mydns.com.33434: udp 36 (ttl 2)