
- •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
different expected responses. Finally, you see in protocol benders some unusual, but not abnormal, behavior exhibited by some applications.
Abnormal Stimuli
This section examines some of the blatantly anomalous behaviors that hackers might throw your way. These behaviors have many purposes, and each is examined for the different categories discussed. These categories and anomalies are not all-inclusive; you might find
many more.
Evasion Stimulus, Lack of Response
You see a port scan of victim.org from stealthy.com with the FIN flag alone set in the TCPdump output that follows. This is a sneaky way of determining whether a given port is active. The expected behavior per RFC 793 is that a listening port that is scanned should not respond; a port that is not listening should respond with a RESET/ACK. This maps the services
that a target host offers. Take a look:
stealthy.com.50141 > victim.org.5: F 0:0(0) win 4096 (DF) stealthy.com.50141 > victim.org.3: F 0:0(0) win 4096 (DF) stealthy.com.50141 > victim.org.26: F 0:0(0) win 4096 (DF) stealthy.com.50141 > victim.org.45: F 0:0(0) win 4096 (DF) stealthy.com.50141 > victim.org.17: F 0:0(0) win 4096 (DF) stealthy.com.50141 > victim.org.7: F 0:0(0) win 4096 (DF) stealthy.com.50141 > victim.org.51: F 0:0(0) win 4096 (DF) stealthy.com.50141 > victim.org.52: F 0:0(0) win 4096 (DF) stealthy.com.50141 > victim.org.30: F 0:0(0) win 4096 (DF) stealthy.com.50141 > victim.org.53: F 0:0(0) win 4096 (DF) stealthy.com.50141 > victim.org.20: F 0:0(0) win 4096 (DF)
The reason that this scan is considered more stealthy than a scan that probes ports with an attempted SYN connection is that some intrusion detection systems might not pick up a FIN scan. Historically, probes of open ports were done using SYN scans, and earlier intrusion detection systems were developed using this signature. When the hackers realized that their scans were being detected, however, they tried to elude notice by launching FIN scans that would map the active ports but might not be noticed. This scan can be launched using nmap
–sF victim.org to inform nmap to do a stealthy FIN scan.
Evil Stimulus, Fatal Response
Denial-of-service (DoS) attacks might attempt to starve a host of resources needed to function correctly. There are many different varieties of DoS attacks. Jolt2 is an attack that consumes so much of the target host's memory resources that it cannot function. Here is some sample
output from Jolt2:
10:48:56.848099 verbo.com > win98.com: (frag 1109:9@65520) 10:48:56.848099 verbo.com > win98.com: (frag 1109:9@65520) 10:48:56.848295 verbo.com > win98.com: (frag 1109:9@65520) 10:48:56.848295 verbo.com > win98.com: (frag 1109:9@65520) 10:48:56.848351 verbo.com > win98.com: (frag 1109:9@65520) 10:48:56.848351 verbo.com > win98.com: (frag 1109:9@65520) 10:48:56.848420 verbo.com > win98.com: (frag 1109:9@65520) 10:48:56.848420 verbo.com > win98.com: (frag 1109:9@65520) 10:48:56.848584 verbo.com > win98.com: (frag 1109:9@65520)
Jolt2 sends an endless stream of ICMP echo requests (by default, although other protocols can be used) to a target Windows host. These are sent as fragments with the same fragment ID

but also with duplicate non-zero fragment offsets.
Because all fragments but the first in the fragment train carry only data, not protocol headers, the receiving host only knows the embedded protocol is ICMP. A problem exists for certain Windows 98, Windows NT, and Windows 2000 hosts when they do not receive the initial 0 offset fragment. The target host becomes consumed with packet reassembly, and memory usage shoots way up leading to a DoS.
When looking at the TCPdump output of the Jolt2 activity, all you know is that host verbo.com is sending some kind of packets to the win98.com host. You see a repeated fragment ID of 1109, a fragment length of 9, and a fragment offset of 65520. The Jolt2 source code assigns the fragment offset a static value of 65520. This brings the total close to the 65535 maximum. Initially, you might think this worked because of the fragment offset number. However, when this value was changed in the source code to something quite a bit lower and the code was recompiled, the DoS still occurred.
To test the response of the target host, a ping process was executed on the malicious host verbo.com to win98.com before and during the time the Jolt2 code was run. The DoS was almost immediate after the Jolt2 code was executed. The win98.com host neither responded to pings nor keyboard input. It recovered after the attack was stopped and did not require rebooting.
The Motivation Behind Scanning
One of the first phases in any attempt to break into a host on a network is to do some kind of reconnaissance on the network or a particular host. An attacker might have a new piece of code that was just released that enables him to get root access if he can find a vulnerable host. Or, an attacker might just be interested in getting into a host or multiple hosts in any way possible. Different hackers have different goals for hacking. Perhaps the host or network is being sought to participate in a distributed denial-of-service attack. Or, perhaps the interest is in compromising a host from which to launch other attacks and hide the true identity of the hacker. The attacker must scan the network in some fashion to discover live hosts, and later discover hosts susceptible to exploits by scanning service ports. For instance, the attacker might have acquired some software that could gain root access on hosts offering vulnerable DNS servers. Chances are good that he would scan the network for any host listening on the DNS port. After discovering those, the attacker might try to execute the DNS exploit code on hosts running DNS.
The scanning phase is one that might be done blatantly at night when it is less likely that a network is being watched. It might be done from a compromised host so that when it is discovered, the attacker's identity will not be known. Or, the hacker might try to launch the scans using methods that might go undetected, known as stealth scans. These scans are considered more furtive because they use unconventional techniques that NIDS are not likely to pick up. Some of the scanning techniques also attempt to fingerprint the operating system. Many times a given exploit might plague a subset of operating systems. For the hacker to have a better chance of success, reconnaissance must be done to find hosts running a particular operating system.
No Stimulus, All Response
This is really just a fancy name for IP spoofing. Appendix A, "Exploits and Scans to Apply Exploits," discusses this in more detail. In the following TCPdump output, it appears that many 1.2 hosts are receiving ICMP "time exceeded in-transit" messages. They are being informed that traffic, which they sent to a host, had a TTL expire in a datagram. Naturally enough, this implies that all the 1.2 hosts sent some kind of traffic that elicited these responses. That is not
the case, however; no outbound traffic is found from these hosts. Here is the output: router.com > 1.2.10.72: icmp: time exceeded in-transit
router.com > 1.2.18.13: icmp: time exceeded in-transit

router.com > 1.2.11.67: icmp: time exceeded in-transit router.com > 1.2.16.13: icmp: time exceeded in-transit router.com > 1.2.19.1: icmp: time exceeded in-transit router.com > 1.2.1.252: icmp: time exceeded in-transit router.com > 1.2.13.56: icmp: time exceeded in-transit router.com > 1.2.143.6: icmp: time exceeded in-transit router.com > 1.2.13.15: icmp: time exceeded in-transit
Can you guess the explanation for this traffic? Given the title of the section, it should be a nobrainer. The 1.2 hosts were spoofed, and traffic was sent to a foreign network using them as a source IP. The reason for this is sheer speculation because you see only one side of the action; however, the most likely explanation is that some kind of flood of activity or harassment against the foreign network was undertaken.
How do you know that source IP router.com is not doing some kind of reconnaissance of the destination 1.2 hosts? Couldn't this type of traffic elicit some kind of response from a router, if not a host? The problem is that this is an ICMP error message, and RFC 1122 dictates that an ICMP error message cannot elicit another ICMP error message because that might lead to some kind of endless loop when an error condition was encountered. Because no other protocol would respond to this activity, the spoofing theory is the most logical.
Backscatter
A very interesting study was conducted and a paper was written about attacks such as the one discussed in the section, "No Stimulus, All Response." The authors nicknamed the attacks backscatter. The authors studied activity on their class A network on the Internet over an extended time. They were able to infer backscatter attacks on the Internet by examining different protocol responses for which there were no requests. This indicated that IP addresses from their network were being spoofed. Using this information, they were able to deduce the number and types of attacks that occurred on the Internet during that time. The frequency and types of activity occurring on the Internet are pretty amazing. The study, "Inferring Internet Denial-
of-Service Activity," can be found at www.cs.ucsd.edu/~savage/papers/UsenixSec01.pdf.
Unconventional Stimulus, Operating System Identifying Response
This section discusses some examples of attempts to fingerprint the operating system of a target host by sending unconventional stimuli and then evaluating the target host's responses. The nmap program is one scanning tool that can remotely attempt to identify a target host's operating system.
The reason that malicious hackers attempt to identify a host's operating system is because they can then pair appropriate exploits with vulnerable operating systems. It is potentially damaging reconnaissance information if someone can determine the operating system of a remote host. Sure, some sites are open enough that the operating system type and version can be harvested from banners associated with telnet or FTP connections. These might not be readily available for all sites, however; and even if they are, they might not be accurate. Every operating system has a TCP/IP stack implementation that differs slightly. If a hacker or software can send specific packets, knowing how a particular operating system should respond, the hacker can tell Linux from Solaris, (sometimes) without requiring any other information.
nmap sends some unexpected stimuli, including the following, to identify a host's operating system based on the replies:
●An unsolicited FIN to an open port. There should be no response according to RFC 793, but some hosts do respond with a RESET. The output was examined in the previous section, "Evasion Stimulus, Lack of Response," to show how this traffic can be used to map listening ports with more stealth than conventional SYN scans.

●Bogus "reserved" TCP flag values. nmap sends these to see whether the target host resets the bits to 0 for those nonexistent flags. Many operating systems think these bits are bogus; however, those that are ECN-aware might not, as discussed in the following section.
●Anomalous TCP flag combinations. Mutant flag combinations are sent with the expectation that most target hosts will not respond, but a handful might respond, uniquely identifying their operating system.
●No TCP flag values. nmap sends these to see how the target host handles this anomalous situation.
Bogus "Reserved" TCP Flags
One fingerprinting method is to send bogus TCP flag settings. Figure 5.1 shows the configuration of the TCP flag byte. The TCP flag byte contains all the possible TCP flag settings. Remember from Chapter 2, "Introduction to TCPdump and TCP that the TCP flag settings tell much about the purpose of a given TCP segment. Because there are only six TCP flags, there are 2 extra bits in the TCP flag byte. Before the invention of something known as Explicit Congestion Notification (ECN), these high-order reserved bits were expected to have a value of 0. ECN is discussed more thoroughly in Chapter 9.
Figure 5.1. TCP flag byte.
To examine all the bits set in the TCP flag byte, you need to execute the standard version of TCPdump with the -x option that dumps the collected datagram in hexadecimal. You cannot check the value of the 2 high-order bits with standard TCPdump output.
A byte is represented as two hexadecimal characters, or nibbles. The low-order nibble contains the bit settings for the PUSH, RESET, SYN, and FIN flags. Turn your attention to the high-order nibble to examine the value of the reserved bits. The bogus TCP flag settings that nmap tests attempt to give these bits a value. If the high-order nibble has a value greater than 3, this indicates that one or both of the reserved bits are set. You can arrive at this value because the ACK bit when set has a value of 1 times 20 (or 1) and the URG bit when set has a value of 1 times 21 (or 2). These two values combined equal 3. Any value greater than 3 in the highorder nibble is anomalous unless ECN is being used.
The following TCPdump output shows an nmap scan that attempts to discover more about the behavior of the TCP/IP stack of target.com to help identify the operating system. This particular attempted connection set one of the reserved TCP flag bytes—specifically, the bit to the left of the URG bit. First, you see the regular TCPdump output, but it gives no clue to the underlying bogus TCP flag bit settings. The following hexadecimal output shows all fields,
including the TCP flag byte field:
scanner.com.44388 > target.com.domain: S 403915838:403915838(0) win 4096 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol> (DF)
[4500 003c 7542 4000 3b06 15bd 0102 0304 0102 0305] ad64 0035 1813 443e 0000 0000 a042 1000 fa4c 0000 0303 0a01 0204 0109 080a 3f3f 3f3f 0000 0000 0000
Looking at the hexadecimal output, the first 20 bytes of the IP header are in brackets. The TCP header and any data follow this; the 13th byte into the TCP header (marked in bold) is the TCP flag byte. You see that the value is a hexadecimal 42. Looking at the high-order nibble (or the