- •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
target.my.com > tracer.net: icmp: echo reply (DF) tracer.net > target.my.com: icmp: echo request target.my.com > tracer.net: icmp: echo reply (DF)
tracert sends the first ICMP echo request in an IP datagram with a time-to-live (TTL) value of 1. The TTL is a value set by a sending host and decremented by each network device through which the packet traverses. TTL provides a means of discarding packets that have overstayed their welcome on the Internet and might be bouncing aimlessly. If a router decrements the TTL and the value becomes 0, the packet must be discarded and an ICMP "time exceeded intransit" error message is returned.
In the previous output, after a TTL with a value of 1 is observed, the router router.my.com sends an ICMP "time-exceeded in-transit" message. This is because it decremented the TTL and discovered a value of 0. It must then discard the packet and inform the sending host.
When used for tracert, however, the original source host receiving this ICMP error message records the router from which it came. If necessary, tracert then sends another ICMP echo request in an IP datagram, but increments the TTL value by 1. This process repeats until the ICMP echo request finally makes its way to the destination host and receives an ICMP echo reply.
By default, three different ICMP requests are sent to each new hop for redundancy in case a packet is dropped. Notice that tracer.net sends an ICMP echo request to target.my.com. Immediately, you see the reply from router.my.com complaining via the ICMP "time exceeded in-transit" message that the TTL value has been decremented to 0. This is seen for all three different ICMP echo requests. The host tracer.net then increments the TTL to 2, which is enough to allow it to get to the actual destination host, target.my.com. The reason that you do not see TCPdump display the TTL value of 2 is because the default behavior of TCPdump is to print the TTL only when it has a value of 1 to warn of an impending problem. target.my.com responds to all the ICMP echo requests with echo replies. If you want to examine the TTL regardless of value using TCPdump, use the command line option –vv.
Protocol Benders
Between the expected and abnormal falls a netherland of applications that exhibit normal, yet unconventional, behavior. These applications deviate from the expected behavior because they were designed differently. These patterns are presented so that if you encounter them, you will understand that this is normal traffic.
Specifically, FTP and UNIX Traceroute will be discussed. FTP is considered to be a protocol bender because it defies the convention of using one ephemeral and one server port for the duration of the FTP connection. The UNIX Traceroute is an unusual application because it combines ICMP and UDP to navigate from source to destination and record all routers on the way.
FTP
The expected behavior of TCP that you have witnessed so far is to establish the two ports used by the client and server during the three-way handshake. The client usually selects an ephemeral port greater than 1023, and the server listens on a well-known port. Throughout
the remainder of the established TCP session, the client and server talk only on these established ports. FTP differs from most other TCP services, because it communicates using two different server ports. The first port is port 21, which is known as the standard FTP command port. The second port is used for data passed between the client and the server. The actual port used is different for active and passive FTP, as you will soon see.
Active FTP
Active FTP is so named because the FTP server opens up the data connection to the client. Both active and passive FTP use port 21 to issue FTP commands, such as those to retrieve or store a file. But, in active FTP, the second is port 20 for FTP data passed between the client and the server. The FTP data port is used to exchange a file between the two hosts or to send a listing of file directories from the server to the client.
Look at the following TCPdump output for an active FTP session to see an unusual, but normal, change of TCP ports:
Session negotiation:
ftp.client.com.35955 > ftp.server.com. 21: S 1884312222:1884312222(0) ftp.server.com.21 > ftp.client.com.35955: S 3113925437:3113925437(0) ack 1884312223
ftp.client.com.35955 > ftp.server.com.21: . ack 1 ftp.server.com.21 > ftp.client.com.35955: P 1:24(23) ack 1 ftp.client.com.35955 > ftp.server.com.21: . ack 24
dir command issued by the user:
ftp.server.com.20 > ftp.client.com.35956: S 3558632705:3558632705(0) ftp.client.com.35956 > ftp.server.com.20: S 1901007864:1901007864(0) ack 3558632706
ftp.server.com.20 > ftp.client.com.35956: . ack 1
In the preceding example, the FTP connection is established between ftp.client.com using ephemeral port 35955 and server port 21. The three-way handshake is completed and some data (usually a welcoming message) is passed between the two. This is similar to what you have witnessed with other TCP protocols.
Next, the user issues the FTP dir command from the client requesting a listing of the directories on the server. A new connection is established from source port 20 of the server to the ephemeral port 35956 on the client. Although you do not see it in the output, the client informed the server that it would be listening on ephemeral port 35956 via the FTP port command. After this new three-way handshake is completed, ftp.server.com can send the directories to ftp.client.com on this established connection. Additional exchanges of data cause the establishment of new connections and the selection of new ephemeral ports. This is called active FTP because the FTP server initiates the data connection to the client. As you might guess, this presents some problems for packet-filtering devices that would have to indiscriminately allow traffic into the network coming from source port 20. Passive FTP avoids these problems by having the internal FTP client make the data connection.
Passive FTP
Passive FTP differs from active FTP in the manner in which the data connection is established. It uses the identical method of connecting to FTP port 21 to establish the command port. But, as you observed with active FTP, the problem arises when a packet-filtering device must allow initial SYNs in from source port 20 to a high-numbered port inside the packet-filtering device. What is to keep a hacker from using this hole as a way into the network? After all, the packetfiltering device might not be examining the content of the packet using this hole and cannot be sure it is indeed FTP traffic.
Passive FTP avoids this problem altogether by having the client initiate the connection to the server. Remember that active FTP required that the server initiate the connection to the client. Look at the following output of a passive FTP session establishment:
Session negotiation:
ftp.client.com.44890 > ftp.server2.com.21: S 4276284026:4276284026(0) win 8760 <mss 1380> (DF)
ftp.server2.com.21 > ftp.client.com.44890: S 1669630260:1669630260(0) ack 4276284027 win 8280 <mss 1460> (DF)
ftp.client.com.44890 > ftp.server2.com.21: . ack 1 win 9660 (DF) dir command issued by the user:
ftp.client.com.44891 > ftp.server2.com.3967: S 4282611109:4282611109(0) win 8760 <mss 1380> (DF)
ftp.server2.com.3967 > ftp.client.com.44891: S 1669768808:1669768808(0) ack 4282611110 win 8280 <mss 1460> (DF)
ftp.client.com.44891 > ftp.server2.com.3967: . ack 1 win 9660 (DF)
When ftp.client.com issues the dir command on the current command connection, it causes a data connection to be established. You don't see this in the TCPdump output, but ftp.server2.com informs the client via the FTP port command that it will be listening on port 3967. The client issues the SYN connection to that port and the server responds with a SYN/ACK. The directory listing is done via this connection. Because the client is making an outbound connection to the server, the subsequent responses from the server can be allowed back in the packet-filtering device with relatively strong confidence that this is a "safe" connection. This involves less risk than allowing active FTP connections by permitting all inbound source port 20 through the packet-filtering device.
UNIX Traceroute
The UNIX Traceroute program discussed next shows a combination of UDP and ICMP to discover the path that a datagram takes from source to destination. This traceroute program is similar in function to the Windows Tracert; instead of using ICMP to discover the routers and destination host, however, it uses UDP.
The intermediate routers that are discovered respond as you saw in the Windows Tracert with ICMP "time-exceeded in-transit" messages when an IP datagram has a TTL value decremented to 0. Again, this process is repeated until the UDP datagram makes its way to the destination host by incrementing the starting TTL value by 1 for each new hop to be forged beyond the previous one. The UDP destination port chosen is one typically in the 33000–33999 range—one that almost surely does not listen. The intention is to elicit an ICMP "UDP port unreachable"
message that signals to traceroute that the destination host has been found. Like tracert, the default behavior for traceroute is to send three different connections to each router or host. This example alters the behavior to send only one for simplicity:
tracer.com.62615 > target.com.33456: udp 12 (DF) [ttl 1] router.com > tracer.com: icmp: time exceeded in-transit [tos 0xc0]
tracer.com.62615 > target.com.33457: udp 12 (DF)
target.com > tracer.com: icmp: target.com udp port 33457 unreachable (DF)
In the preceding output, you see tracer.com send a UDP datagram to destination port 33456 of target.com. The initial TTL value is set to 1. As soon as this packet hits router.com, it decrements the TTL value to 0 and returns an ICMP "time exceeded in transit" message to tracer.com. When tracer.com receives this, it sends another UDP datagram to target.com. This is different from the first one because it increments the destination port to 33457 and, while you cannot tell from the standard TCPdump output, it increments the initial TTL to 2. This allows the datagram to traverse the first router, router.com, and take one more hop. That additional hop takes it to the destination host target.com that does not listen on port 33457 and returns an ICMP "port unreachable" message.
You should be aware that both the UNIX traceroute and the Windows tracert only work if specific ICMP messages are allowed into the network of the host executing the commands. Both versions require that ICMP "time exceeded in-transit" messages be allowed into the network. The UNIX traceroute requires that ICMP "port unreachable" messages be allowed, and Windows tracert requires that ICMP echo requests be allowed.
You are probably asking whether these types of ICMP messages should be permitted inbound to your network. This really depends on the security posture you adopt. At the most protected and restricted sites, this is not necessarily recommended. The risks might far outweigh the benefits because it is possible to use these ICMP messages for purposes other than the ones for which they were designed, as was witnessed with the discussion of Loki in Chapter 4.
However, if your site is a more open one and you are willing to accept the risks, allowing these ICMP messages can provide some obvious benefits of route discovery along with informative feedback to internal hosts in your network.
Summary of Expected Behavior and Protocol Benders
Here is a brief synopsis of what has been covered so far in this chapter. The RFCs are the standards documents upon which TCP/IP and the Internet were built. They describe how things are supposed to work when everyone conforms to the same rules. Unfortunately, hackers have discovered that different implementations of TCP/IP react differently to deliberate violations of the RFC standards. That's one of the foundations of hacking: deliberately exploiting exceptional conditions that the implementers of the TCP/IP code believed would never happen. Hackers often attempt to identify operating systems by sending strange stimuli and observing the host's responses. The final part of this chapter looks at some of the reactions of systems to these deliberate deviations.
As previously discussed, there are unique responses for the same stimulus depending on the circumstances and availability of the requested service. Responses also depend on a host or router's capability to respond to a particular connection. Each of the different protocols has