- •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
will expire it. This is a signature of traceroute. Therefore, let's embellish the traceroute filter to include the TTL value to eliminate some of the noise associated with discovering traceroutes. The TTL field is found in the IP header; it has no macro to reference it and if you look once again at Figure 12.1, you find it in the 8th byte offset. Here is what the new
filter would look like:
udp[2:2] >= 33000 and udp[2:2] < 34000 and ip[8] = 1
This gives you an idea of some of the UDP filters. TCPdump filters can also be used for ICMP traffic. Specifically, some of the good candidates for detection of anomalous ICMP traffic are address mask requests, someone trying to discover the MTU of your network sending datagrams with the don't fragment bit set and receiving back messages from your router with the MTU, and Loki. All these filters are so simple to write. We will leave these for you to try. Here are the signatures of TCPdump filters for you to write on your own:
●The address mask request has a value of 17 in the 0 byte offset of the ICMP message.
●The fragmentation required, but DF flag set message has a 3 in the 0 byte offset of the ICMP message and a 4 in the 1st byte offset of the message.
●A signature for Loki was an echo request (an 8 in the 0 byte offset of the ICMP message) or an echo reply (a 0 in the 0 byte offset of the ICMP message and in the 6th and 7th bytes offset of the ICMP message). You would have a hexadecimal value of 0xf001 or 0x01f0.
Answers to ICMP filters:
- icmp[0] = 17
- ((icmp[0] = 3) and (icmp[1] = 4))
- (((icmp[0] = 0) or (icmp[0] = 8)) and ((icmp[6:2] = 0xf001) or (icmp[6:2] = 0x01f0)))
TCPdump TCP Filters
TCPdump filters for TCP traffic are mostly concerned with initial SYN connections and other types of anomalous flag combinations that might indicate some kind of reconnaissance or mapping efforts. We want to look for initial SYN connections because they inform us of attempted connections to a TCP port. This doesn't necessarily mean that they were successful. If your TCPdump sensor is located outside a packet-filtering device that blocks access to the TCP destination port, it will never reach the host. And, if the traffic is allowed through the packet-filtering device, it is possible that the host doesn't offer the attempted service. You can glean a lot of intelligence by detecting this activity, the least of which is
discovering rogue TCP ports that hosts on your network might be offering.
Filters for Examining TCP Flags
Figure 12.5 relates to most of the remaining filters in this chapter.
Figure 12.5. The TCP flag byte.
The TCP flag bits are located in the 13th byte offset of the TCP header. Because you are looking for individual bits in the bytes, you need to perform some bit masking to select the flag or flags you want to examine. Begin by writing a filter to extract records with the SYN
flag alone set: tcp[13] & 0xff = 2
Why this filter? We see that our mask consists of all 1s. Why didn't we use a mask of 0s in all fields except the SYN flag (tcp[13] & 0x02 = 2)? By masking a bit with a 0, the resulting value is necessarily 0. The value bit could be 1, however, and the 0 mask would discard it. If this is confusing, try an example.
Suppose that you want to look at TCP segments with the SYN flag alone set. Okay, now suppose that you have a TCP flag byte with both the SYN and ACK flags set. The binary value that you would see for the TCP flag byte would be 0001 0010. If that were masked with 0000 0010, you would end up with a result of 0000 0010, which is 2. Therefore, masking with 0s in fields other than the SYN flag selects TCP segments with other flags set along with the SYN flag. To prevent this from occurring, you use the original filter and preserve all the value bits; the resulting value will not be 2 if any other value bit is set. If the ACK bit were set, you would have a resulting value of 18 from the new mask. This filter does not select records with other flags set along with the SYN flag.
Because you are looking for the SYN flag alone set, to be perfectly simple about this
particular filter, you can specify it by: tcp[13] = 2
This will assure that only the SYN flag is set because if any other flag is set, the resulting value when adding up all the bits set in the byte will not be 2. For instance, let's say that you have a byte with an errant SYN and URG flag set together. The URG flag is found in the position of the byte that has a value of 32 and the SYN flag is found in a position with a value of 2. Therefore, the resulting combined value of these two bits set would be 34 and would not match the filter.
Take a look at some other TCP flag combinations you might want to know about:
●tcp[13] & 0xff = 0 alternatively tcp[13] = 0 This shows null scans with no flags set. This condition should never occur.
●tcp[13] & 0xff = 3 alternatively tcp[13] = 3 This shows activity where both the SYN and FIN flags are set simultaneously; this is definitely an anomalous condition. You might want to alter the filter to tcp[13] & 0x03 = 3, because this gets any activity with both the SYN and FIN flags set, as well as any other flags set. In this case, you don't necessarily want to exclude this to SYN and FIN alone.
●tcp[13] & 0xff = 0x10 and tcp[8:4] = 0 This shows activity with the ACK flag set, but with an acknowledgement value of 0. This is usually an anomalous condition because the three-way handshake necessarily consumes a sequence number. Logically, an acknowledgement value would have to be 1 greater than the initial sequence number meaning it will be non-zero. This filter is offered because it often captures nmap operating system fingerprinting scans that send TCP traffic to various destination ports with the ACK flag alone set, but a 0 value in the acknowledgement field.
It is rarely possible that a 0 acknowledgement can be legitimate if the sender has sent a sequence number where all the bits in the sequence number are 1 – in other words 232 – 1. The next expected sequence number would then wrap around and be 0.
●tcp[13] >= 64 Figure 12.5 shows two high-order bits in the TCP flag byte that are labeled reserved bits. These two bits should be 0s; if they are not, something might be amiss. The first reserved bit is found in the 26 (64) position, and the second is found in the 27 (128) position. If either or both bits are set, the value for the TCP flag byte is greater than or equal to 64. Our old friend nmap sometimes sets the bit that is in the 64 position to perform operating system fingerprinting. Most hosts reset these values to 0s, but some leave the set value. This is used by nmap to help classify the operating system behavior.
More recently, these erstwhile-reserved high-order TCP flag bits are now associated with something known as Explicit Congestion Notification (ECN). This is a technique for reducing congestion in a network. How can you distinguish legitimate ECN traffic from nmap operating system scans? ECN traffic should have a non-zero value in the differentiated services byte (formerly known as the type of service byte), whereas nmap will have a 0 in this field. If you care to read more about ECN, reference RFC 3168.
These are just some of the different combinations of TCP flags that you can examine. This is not an exhaustive list and I encourage you to play with these filters and develop
different combinations.
Detecting Data on SYN Connections
Before letting you loose to develop some TCPdump filters of your own, let's take a look at one advanced filter that will summon up all the various bits and pieces you have learned in the chapter about developing filters and then some. In Chapter 2, "Introduction to TCPdump and TCP," you learned that data should not be sent before the three-way TCP handshake has been completed. You saw this activity with the 3DNS product, which is a nuisance but ostensibly not malicious. You also read about the example of a scan that a site received in which there was data included on the SYN. It was feared that this type of activity might be an attempt to elude an IDS that started stream or data assembly for data received after the three-way handshake only.
It seems prudent then to try to develop a TCPdump filter that would detect this activity. You could later put in exclusions for annoying false alarms from 3DNS activity. The problem is that no field in the TCP header has the number of bytes in the TCP payload. You do have a bevy of other fields that have length values in them, however. Specifically, in the IP datagram, you have two length fields in the IP header. One is the length of the entire IP datagram, and the other is the length of the IP header alone. In the TCP segment, you have the length of the TCP header. Figure 12.6 shows that the length of the IP datagram minus the length of the IP header minus the length of the TCP header should leave the TCP payload length.
Figure 12.6. Calculating the TCP payload length.
"Piece of cake," you say? You will encounter some complications, or challenges (your choice). Notice the different metrics in different fields; the IP datagram length is in bytes, whereas the IP header and TCP header are in 32-bit words. You must standardize to bytes and convert the header lengths to bytes by multiplying them by a factor of 4. This is quite manageable. You have already dealt with the IP header length, and so you have pretty much conquered that.
One final bit of nastiness that you need to address is the TCP header length seen in Figure 12.7. Look carefully at where this is located; it is in the high-order nibble of the 12th byte. You already know that you have to zero-out the low-order nibble to deal with the highorder nibble exclusively, but you aren't quite ready to tackle the formula just yet. Because this is in the high-order nibble, it is really multiplied by a factor of 16, so it has to be normalized.
Figure 12.7. The TCP header.
Suppose, for example, that you have a TCP header length of 24 bytes that includes a 20byte header and some TCP options. Remember that you have to convert to 32-bit words, so you need to divide by 4 to compute the value that would be found in the TCP header length field. You would find a value of 6 in this field. Assume you have also masked the loworder nibble so that the hexadecimal value remaining in this byte is 60. The binary