- •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
vectors.
Threat Determination
Your goal for the purposes of establishing a business case for intrusion detection is to list wellknown, probable threats as opposed to all threats. How do you find these threats? Sources might include the following:
∙Newspaper or web articles on attacks at other places. If it happens to them, it could happen to you.
∙Firewall/intrusion-detection logs for specific threats.
∙System audit trail logs.
∙Demonstration of an intrusion-detection system.
Many commercial intrusion-detection vendors allow you to take their systems for a test drive, with a 30-day trial or something similar. If you are serious about wanting to implement an IDS capability, I can't stress how important this is to do. It gives you a list of actual attacks against your network; this is helpful for establishing the threat. It helps establish the groundwork for part three of the plan when you show why you recommend an intrusion-detection system as opposed to, say, another firewall. And, it gives you experience with a couple commercial offerings. All too often, folks make their decision either based on something they read or on how friendly the salesperson is. If you have tried a few "loaner" IDSs, in part three of the plan, you can make honest statements about the tradeoffs between various systems.
If you can find the time to do it, interviews with folks in various parts of your organization can be a rich source of threats and vulnerabilities that you might otherwise have missed. I have had people tell me about shockingly bad practices when I ask them what they consider the largest dangers to the organization's information assets to be. Yet, they never came forward with the information on their own. As they say in Alabama, "Whaay-el, you never asked."
Asset Identification
Chapter 17 discussed asset valuation. Now, you focus on the concept a bit more. The huge value is the investment in data. If most of your workers use computers most of their workday, the value of the data on the computer is the cost of putting that worker in front of the console. The threats to that data are that it will be copied, destroyed, or modified.
We have touched on this throughout the book. So that we are really clear, however, I will reiterate: The most probable threat to that data is destruction from the system owner. As my Catholic friends would point out, this could be by a sin of commission, or a sin of omission. By commission, I mean an overt act, deleting the data accidentally, or on purpose, and never telling anyone so that it can be recovered. By omission, I mean the failure to back up the data properly, and that includes off-site backup. At least for the things that are within your power to change, work to ensure your data is backed up.
It turns out to be an almost impossible task to ensure that all the data throughout the organization is protected from being copied, destroyed, or modified. In the same way, making sure every data element is backed up, on and off site, is beyond the capabilities of any
organization that I know of. This is a great lead-in to the notion of crown jewels, or critical program information (CPI) as they say in security texts.
Valuation
All your data is not of the same value. In fact, a small portion of the information that exists in your organization is what distinguishes you from your competition. Although all your data has value, crown jewels are the information that has critical value and must be protected.
You reflect this in the threat section of your plan. Find as many of the crown jewels as possible. Consider the threat vectors, and the known common threats, and use these as the examples of threats and vulnerabilities in part two of your intrusion-detection business plan.
In part three, you will discuss countermeasures to protect these clusters of high-value information. These might include the following:
∙Host-based IDS software on the critical systems.
∙Honeypot files. If your organization has sensitive documents, you can add special tagged strings into the document. One way to do this is invent acronyms that do not actually exist. Then you can program your IDS watch for these with a string, or content matching rule. This would tell you if these files are entering or leaving your network.
∙Instrumenting internal systems with personal firewalls. (Technically oriented employees often enjoy doing this.)
∙Network-based IDS in high-value locations.
Vulnerability Analysis
Vulnerabilities are the gateways by which threats are made manifest. All the threats in the world don't matter if there are no vulnerabilities.
Were you disappointed because I didn't give a long list of vulnerabilities from which to work? Well, they change almost daily so you need a pointer to a current list, not a static one that will
be obsolete before the book is even printed. I like the Computer Vulnerabilities and Exposures (CVE) project (cve.mitre.org) the best because it cross-indexes a number of great
vulnerability lists such as bugtraq and ISS's X-Force. However, you do not need to do this manually. Getting your general threat list as well as an assessment of your vulnerabilities is a fairly simple matter. A number of good vulnerability assessment tools are available. These tools test for specific threats, and they find potential vulnerabilities. Let's consider three classes of tools: system-vulnerability scanners, network-based scanners, and also phone-line scanners.
Tools such as COPS, SPI, tiger, and STAT are examples of system-vulnerability scanners. They work within the system looking for missing patches, incorrectly set file permissions, and similar problems.
Tools such as nmap, nessus, saint, ISS' Internet Scanner, and Axent's NetRecon are examples of network-based scanners. These are fairly fast and effective and scan the network looking for unprotected ports or services.
While conducting vulnerability assessments, you might also want to assess your risk from the attackers who scan your phone lines looking for active modems. Toneloc, available from fine hacking sites everywhere, is the most used tool for this. Phonesweep from http://www.sandstorm.net is a commercial tool with some additional features.
If at all possible, your vulnerability assessment should offer three views:
∙A system view. Taken from selected systems with system scanners.
∙A network view. Done from an internal scan of your network.
∙An Internet view. Done from outside your firewall and, if possible, a phone scan as well.
Of course, you want some juicy vulnerabilities to spice up your report, but please also scan your firewall, DNS, mail, and web servers, as well as systems related to your crown jewels. These are the systems that your organization depends on.
Whew! Sounds like a lot of work, doesn't it? Correct, it is a lot of work and vulnerability assessments are not something that should be done only once. Why does it make sense for the intrusion-detection analyst to be involved in vulnerability assessments? It keeps you aware of specific problems and where in the organization your vulnerabilities are located.
Risk Evaluation
You have a lot of data. What do you do with it? Just because you collected it, do not stuff it all in your report, even as labeled appendixes. On the other hand, you do want it organized and available. Whenever you brief senior management, you want at least one supporting layer of data available—that is, if your slide says 12 systems are deemed to contain CPI, you darn sure want to be able to list those systems and explain the rationale for choosing them and not others.
Okay, we have answered the question of what you are not going to put in the second section of the report. What should you provide?
∙A top-level slide with the value of the organization's information assets. Suppose you have 100 computers with a five-year life cycle, for instance. The hardware, software, and maintenance costs are $200k/year with information valued at $1 million.
∙A network diagram that defines the boundary you are trying to protect.
∙A basic description of the threat vectors.
∙A general summary of your general vulnerability assessment.
∙A description of the crown jewels: where they are, their value, and so on (include the firewall, DNS, mail, and web servers).
∙Specific threats against the crown jewels.