- •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
House Rules of CIDR
You might hear a new term, classless inter-domain routing (CIDR) to refer to addresses. For the longest time, addresses were part of a particular class and that meant your network was allocated either 16 million+, 65,000+, or 255 hosts. The most common situation was networks that required between 255 and 65,000 hosts. Because many of these sites were allocated Class B networks, many IP numbers went unassigned. Given that IP numbers are finite commodities, a remedy was needed to allocate networks without class constraints.
CIDR assigns networks, not on 8-bit boundaries, but on single-bit boundaries. This allows a site to receive the appropriate number of IP numbers, and thus reduces waste. CIDR uses a unique notation to designate the range of hosts assigned to a site. If you want to specify the 192.168 address range in CIDR, it would look like 192.168/16. The first part of the notation is the decimal representation of the bit pattern allocated to the network. It is followed by a slash and then the number of bits that represent the network portion of the address. This example is the same as a Class B network, but it can be modified easily enough to represent smaller networks.
Subnet Masks
Another concept you need to be aware of is something known as the subnet mask. This mask informs a given computer system how many bits in its IP address have been relegated to the network and how many to the host. Each bit that is a network bit is "masked" with a 1. A Class A address, for instance, has 8 network bits and 24 host bits. In binary, the 8 consecutive bits (all with a value of 1) translate to a decimal 255. The subnet mask is then designated as 255.0.0.0. Other classes have other subnet masks. A Class B network has a standard subnet mask of 255.255.0.0, and a Class C network has a standard subnet mask of 255.255.255.0. Why is this needed if you can tell what class and how many bits have been reserved for the network by examining the IP address? Some network administrators subdivide their networks. For instance, a Class C network could be divided into four individual subnets by assigning an appropriate subnet mask.
Service Ports
This section is a "bit" easier. TCP and UDP have 16-bit port number fields in their respective header fields. This means they can have as many as 65,536 different ports, or services, and they are numbered from 0 to 65,535. One very important point to register in your long-term memory is that even though a service is usually located at its assigned port number, nothing guarantees this as true. Telnet, for instance, is almost universally found on TCP port 23. There is nothing stopping your nonconformist side from offering it at port 31337. And, what better way for a hacker who has broken into a computer to hide his tracks than by offering a service at an unexpected port? If a hacker were to run telnet at some high-numbered port rather than port 23, it would make his unauthorized connection more difficult to find and identify. Any service can be run at any port. On the other hand, if you want to network with other hosts, it is best to follow the standards. For UNIX hosts, the /etc/services file can be an excellent resource to match TCP or UDP port numbers with the expected, or well-known, services likely to be offered at that port number.
You see some very common port numbers and service examples from the /etc/services file. An excerpt here shows you the format of the file and the associated services. You see that a service known as domain (Domain Name Service, or DNS) can be offered on both TCP and UDP. This is unusual, but not abnormal; most services are offered on either TCP or UDP, but there are some exceptions (such as DNS).
ftp |
21/tcp |
telnet |
23/tcp |
smtp |
25/tcp |
domain |
53/udp |
domain |
53/tcp |
Figure 1.6 shows how the service is specified in the packet. In this case, a UDP header has a 16bit field known as the destination port. This is where the desired service or port is found. In this example, the value in the UDP header's port number field would be 53, signifying that this datagram is destined for the Domain Name Service.
Figure 1.6. Not just any port.
At one time in history, special significance was attached to ports below 1024. Those lowernumbered ports were the so-called trusted ports (chuckle) because only root could use them. The term trusted port originated because ports below 1024 were allocated to system processes. Therefore, if a foreign host saw an incoming connection with a source port less than 1024, it was assumed to be trusted because it ostensibly came from a system process. This made much more sense when the Internet was a safer place. This is much less true today, but the ports above 1024 have special significance. These are often called the ephemeral ports, which means they could be used by most any service for most any reason.
IP Protocols
Turn your attention again to the four primary layers of the TCP/IP model (refer back to Figure 1.1). You (as the user) use an application to interact with the IP communications stack. You use
a program such as FTP to transfer files, telnet as a terminal emulator, and email to forward tired jokes and stories to 50 of your closest friends. The application takes the message, the information from the user or user process, and prepares it to be sent down through the IP stack. The remaining three layers are transport, network, and link.
Two different transport models are discussed at this point: a connection-oriented model (TCP) and a connectionless model (UDP). Connection-oriented means just what it sounds like: The software does everything that it can to ensure that the communication is reliable and complete and begins the process by establishing a connection known as a handshake. Connectionless, on the other hand, is a send-and-pray delivery that has no handshake and no promise of reliability. Any offered reliability must be built in to the application. Table 1.3 shows some of the TCP and UDP attributes.
Table 1.3. Attributes of TCP Versus UDP
TCP |
UDP |
Reliable |
Unreliable |
Connection-oriented |
Connectionless |
Slower |
Faster |
UDP is the easiest communication protocol to comprehend—after all, you just assemble packets and fire them into the network. The destination host scoops them up, demultiplexes (strips the headers off at one layer and sends it to the appropriate upper-layer protocol), and extracts the message. Certainly, a few datagrams might get lost along the way, but that is often okay; for plenty of applications, this is not an issue. If you were broadcasting audio, for instance, and a word got lost, your mind could probably compensate for this and fill in the missing word. If you were sending video, perhaps there would be a little blank spot where some packets got lost. Most of the time, this is acceptable. The data that travels over UDP is not necessarily unreliable; it is just that UDP itself is not responsible for it. The application must ignore the missing pieces or ask for the missing pieces.
What if you have an application that cannot tolerate the loss of packets? That is when TCP is used. It ensures that all data sent is received. Several mechanisms are in place to verify delivery and proper sequencing of TCP data. One means of control is an acknowledgement. An acknowledgement (ACK) is an important part of the TCP protocol. TCP is so reliable because each packet is acknowledged after the destination host receives it. If a packet is not received (and therefore not acknowledged), it is resent. Thus, TCP ensures that all the packets are received, and so is deemed a reliable service. This is a much slower way of doing business, but you can set certain optimizations to speed up the process. That said, TCP will always be slower than UDP.
The final IP protocol discussed here is the Internet Control Message Protocol (ICMP), which is a fascinating lightweight set of applications originally created for network troubleshooting and to report error conditions. The most well-known ICMP application is certainly the echo request/echo reply (or ping). You can use a ping to determine whether a given network host is reachable. Other ICMP applications are used for such things as flow control, packet rerouting, and network information collection (to name just a few of the functions). Chapter 4, "ICMP," discusses ICMP and its related functions in more detail.
Domain Name System
Naming a thing is not the same as knowing a thing, but it is often the first step. I remember
when I first started hearing about the Domain Name System (DNS). At the time, the major database software vendors were all talking about their distributed database products that would be available "real soon now," and then the next thing I knew I was running distributed database software. It didn't cost me a thing, and it worked from day one. DNS is a distributed database because the entire address table is not stored on a single host; instead, it is distributed across many servers.
At one point, the IP addresses and names were kept in tables that were downloaded nightly. As the Internet kept growing, this became impractical for a number of reasons related to the size of the table and issues surrounding single point of failure. Take a look at this excerpt of the static host file /etc/hosts maintained on a UNIX host:
/etc/hosts
127.0.0.1loopback
172.20.1.41relay relay.sans.org
172.20.31.19goo goo.sans.org
Although UNIX and Windows 2000 hosts still maintain a small local hosts file to identify local and frequently used hosts, this function has been augmented by adding DNS capabilities. Most UNIX and Windows 2000 hosts are configured to search the host's file first and if a host is not found there, to search DNS for the resolution for the host. This offloads most of the maintenance burden from the system administrator to individual administrators who maintain DNS servers.
Before jumping into the DNS, a discussion of DNS domains is needed. A domain is really just a logical division of DNS or the DNS database. The initial seven well-known "generic" domains have the three-letter endings such .com, .org, .edu, .net, and to a lesser extent .int, .gov, and
.mil. The list of top-level domains has been expanded to include .aero, .biz, .coop, .info,
.museum, .name, and .pro. There are also two-letter domains, which often appear as country codes (.us, .fr, and .uk for the United States, France, and the United Kingdom). Within each of those generic domains are the domains used every day (for example, yahoo.com and sans.org). Each of these domains represents a slice of the entire DNS pie.
Now that you have been introduced to the concept of DNS domains, how does DNS name resolution really work? At a very rudimentary level, there are basically two resolving routines: gethostbyaddr and gethostbyname. When you do some kind of DNS resolution, a host needs to either translate an IP number into a host name or a host name into an IP number. The real issue at hand is that people refer to hosts by their God-given host names, whereas computers refer to hosts by their binary-derived IP numbers. After all, there is no field in an IP datagram for the host name, only the IP number.
The gethostbyaddr call issued by your host delivers an IP number to a DNS server and tells it to resolve the host name and return it. There is much more to the process than meets the superficial eye, and this is discussed in Chapter 6, "DNS." Conversely, a gethostbyname call delivers a host name to a DNS server and requests resolution to an IP number. Understand that this explanation of DNS is a gross oversimplification of the processes and issues involved because it is intended to be a very introductory exposure.