- •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
attack is, and any system or network countermeasures that might mitigate the attack.
●Criticality. This is a 3, because no specific servers are targeted.
●Lethality. This is a 4, because there are many known ftp vulnerabilities.
●System countermeasures. This is a 2, because all operating systems are running the latest patches, but some are listening on the ftp port.
●Network countermeasures. This is a 4, because the firewall blocks all incoming ftp.
●Severity score. This severity score is 1. The formula is this:
Severity = (Criticality + Lethality) – (System Countermeasures + Network
Countermeasures)
Sensor Placement
A network-based intrusion-detection system isn't going to work unless there is a sensor. It will not work optimally if the sensor is not placed correctly. Generally, somewhere in the vicinity of the firewall is a good location for the sensor.
Outside Firewall
Usually, intrusion-detection sensors are placed outside the firewall in the DMZ (as shown in Figure 16.4). This allows the sensor to see all attacks coming in from the Internet. However, if the attack is TCP and the firewall, or filtering router, blocks the attack, the intrusion-detection system might not be able to detect the attack. Many attacks can be detected only by matching a string signature. The string is not sent unless the TCP three-way handshake is completed.
Figure 16.4. A sensor, or event detector, is used to instrument the DMZ.
Although some attacks cannot be detected by a sensor outside the firewall, this is the best sensor location to detect attacks. The benefit to the site is that analysts can see the kinds of attacks to which their site and firewall are exposed. One of the reviewers of the book puts it this way: "Outside the firewall is attack detection, and inside it is intrusion detection." Well put! During late 1997 and early 1998, a large number of sites detected attempts against the portmapper port (TCP/UDP 111). Sites with active portmappers are likely locations for rpc.statd. I ran a vulnerability scanner internally at two locations to see whether any risk existed. The scan turned up more than 50 systems that would answer an rpcinfo –p request (which means an unsecured portmapper) and further analysis showed that they were running statd. The firewall at both locations blocked the attacks, both via portmapper, and any attempt to directly access statd. Having information that sites I was concerned with protecting were under a concerted attack and that there was an internal exposure redoubled my efforts in the neverending battle to get those portmappers secured and see whether patches were available from vendors for statd. For more information, refer to www.cert.org/advisories/CA-97.26.statd.html.
DMZ (demilitarized zone) is the area between an ISP and the outermost firewall interface.
Sensors Inside Firewall
A school of thought says that sensors should be placed inside firewalls. Several reasons compel this placement. If attackers can find the sensor, they might attack it so that there is less chance of their activities being audited. Systems inside firewalls present less vulnerability than systems outside firewalls. If the sensor is inside the firewall and exposed to less noise, it might generate fewer false positives. Also, inside the firewall, you can detect whether a firewall is misconfigured
(if attacks get through that are supposed to be stopped, for example).
It is certainly true that well-configured firewalls stop most low-end exploit attempts. It is also
true that far too much attention is devoted to detection and analysis of these low-end attacks.
Both Inside and Outside Firewall
More is better. Best of both worlds. You have heard both of these slogans. For me, they are more than mere slogans. I deploy sensors on both sides of the firewall. If your organization can afford a sensor both inside and outside the firewall, this has certain advantages, such as:
●You never have to guess whether an attack penetrated a firewall.
●You might be able to detect insider, or internal, attacks.
●You might be able to detect misconfigured systems that can't get through the firewall so that you can help the system administrator.
If your organization is using an expensive IDS solution, this is not worth the cost and effort. If you do deploy dual sensors, the sensor on the inside of the firewall is the one to set up to page you in an emergency.
Misconfigured Systems
Intrusion-detection systems and their analysts should be able to troubleshoot the network. When I was involved in deploying Shadow, we usually spent the first week or two helping the site fix problems with the network. This is just as true today. Below are some of the common problems:
●localhost 127.0.0.1 or 127.0.0.2 broadcasting to an internal subnet.
●Misconfigured DNS files. These read from right to left; so if your site's network ID is 172.20.0.0/24 and you detect a host (172.20.30.40) doing a broadcast to 255.30.20.172, that could be a clue that someone didn't get the word that domain files read right to left.
●Incorrect subnet mask. Broadcast to 172.20.255.255 rather than to 172.20.30.255.
●Backdoors. When you see a packet coming from the Internet to 172.20.30.255 (using the network ID from the preceding example), there is a pretty good chance your network has sprung a leak—that is, a packet should not be coming from you, to you, outside your firewall.
Additional Sensor Locations
The most common place for a sensor is outside the firewall, but it is certainly not the only place that benefits an organization. Many intrusion-detection systems can be used to support the organization in a variety of additional locations, including the following:
●Partner networks, to which you have direct connections to customers and suppliers often inside your firewall.
●High-value locations, such as research or accounting networks.
●Networks with a large number of transient employees (consultants and/or temps, for example).
●Subnets that appear to be targeted by outsiders, or that have shown indications of intrusions or other irregularities.
A final issue in sensor placement is what the sensor is connected to. Networks today operate almost exclusively on switched VLAN environments. Sensors can operate in these environments. If the switches' spanning ports are not configured properly, however, intrusion detection is all but impossible. One thing to be aware of is that spanning puts a load on the switch. If a sensor is to be operated in a switched network, the implementation must be tested. TCP is a duplex
protocol, and the analyst should ensure that the sensor is receiving both the source and destination side of the conversation. The sensor should also be tested to ensure that it sends data reliably from the switched location. It might be necessary to configure the sensor with two interface cards. The first can monitor in promiscuous mode (listening to all packets regardless of whether they are addressed to the sensor) attached to a spanning port. The second interface would be placed on a separate VLAN to communicate with the analysis station. Of course, throwing money at the problem is always a handy trick in intrusion detection. If you are having load and configuration problems, here are a couple of options:
●Consider a network tap. These are connected directly to the media and allow the sensor to see the data that passes by the tap.
●TopLayer, www.toplayer.com, has a switch designed to copy data from the network to an IDS.
●Cisco Catalyst 6000 switches can support an optional Policy Feature Card that allows you to control the data copied to the IDS in about the same way the TopLayer does.
Push/Pull
Now that you have determined where you want to place your sensor, how will you extract the data from it? The preferred behavior, at least when you first deploy a sensor or event generator, is to push events to the analysis system as they occur. When the sensor detects an event, it creates a packet with the pertinent data and shoots it to the analysis station. An obvious protocol for this would be something like an SNMP trap. Most commercial products have their own proprietary protocol for communications between the sensor and analysis station. The number-one feature potential customers look for when they compare intrusion-detection systems is "real-time" response.
Pushy Intrusion-Detection Systems
One of the more interesting selling points for intrusion-detection systems is how obnoxious they can behave. It seems like a good idea when looking for a system that the IDS will beep the console, send us email, page us, or call our cell phones. It usually takes only a couple weeks to turn off these handy real-time notification features. Even the most dedicated analyst will accept only so many false alarms at three o'clock in the morning.
Real-time is not possible until the intrusion-detection capability exists in the network switch fabric and computer system operating system and programs themselves. Even so, prospective customers of intrusion-detection systems want the event-detection information available to them as quickly as possible, and that makes a whole lot of sense. Certainly then, push is the correct architecture for network-based intrusion detection, right?
Push-based architectures have one very severe flaw. If their behavior is such that they generate a packet in response to a detect, and if the sensor can be observed, it is fairly easy to determine how it is configured. Over time, this would allow an attacker to determine what the sensor ignores. This kind of effort and patience is unlikely with low-end script-kiddie attackers, but almost guaranteed behavior from the high end, such as high-value economic espionage. The obvious solution to this problem is to push out the events on a regular basis as a stream. This gives the same, just a little later than real-time response, capability and masks what the sensor detects. If there are no detects, the stream is just filled with encrypted null characters. Figure 16.5 shows the differences in architecture between push and pull systems. On the whole, push is the better architecture for intrusion detection. One of the best applications for pull is a covert sensor, which can be employed in an investigation. It can be focused on a particular computer system. It can also just passively monitor communications until a key phrase occurs,