- •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
dns.verbose.com source port domain (53). That is why the three-way handshake is never completed and the large DNS response is never delivered. To avoid this problem, block traffic to TCP destination port 53 only and allow traffic from TCP source port 53 that has an already
established connection.
Summary of DNS Theory
DNS relies on a complex interweaving of many DNS servers.You must be able to examine traffic to and from your DNS server to understand the nature of the activity. TCPdump is an adequate tool to use; but at times, you have to use other tools to examine the content of the datagrams to see whether problems exist. Typical DNS servers on active networks receive a lot of traffic, and hackers can use the volume of normal activity as a smoke screen for malicious activity.
Using DNS for Reconnaissance
Given the notion that DNS is a global database, it is an excellent source for reconnaissance. DNS information is intended to be freely shared and freely available in the spirit of cooperation. At one time in the evolution of the Internet, this was a relatively innocuous philosophy. In today's climate of hungry pirates, however, it seems quite naive. Here are some
ways in which reconnaissance can be done using DNS.
The nslookup Command
nslookup acts much like a DNS client would, but displays the information so that you can see it. In fact, that is how the authoritative name server host names and IP addresses for the sans.org domain were obtained. This is a very helpful interactive tool that can be used on a UNIX or Windows NT (and beyond) host. Some UNIX operating systems are beginning to replace the nslookup command with the dig (Domain Internet Groper) command.
You can ask many more questions of a DNS server than just the host name. Using nslookup, you can formulate queries and see the kinds of responses you get. There is also a debug setting that enables you to see more of the data in the DNS message that is sent and returned than just the query and response values.
Look at the following output to get an idea of the capabilities of the nslookup tool. You see host.my.com issue the nslookup command. You then enter into the nslookup interactive process and receive notification of the default DNS server, dns.my.com and its associated IP
address (192.168.4.4) used to resolve your queries. The output follows: host.my.com% nslookup
Default Server: dns.my.com Address: 192.168.4.4
> www.sans.org
Server: dns.my.com Address: 192.168.4.4
Name: www.sans.org Address: 12.33.247.6
At the greater than (>) prompt, www.sans.org is entered to find its IP address. Again, you
get confirmation of the DNS server and IP address being used to resolve the query. You see the answer below that of 12.33.247.6.
Name That Name Server
How does someone discover what your DNS server is? Given the number of reconnaissance
attempts targeting DNS servers only, there must be a way to find out. Actually, it is rather
easy to find this out using nslookup:
> set type=ns > sans.org
Server: dns.my.com Address: 192.168.4.4
NON-AUTHORITATIVE ANSWER sans.org nameserver = NS.DELOS.COM sans.org nameserver = server1.sans.org sans.org nameserver = NS.BSDI.COM
AUTHORITATIVE ANSWERS CAN BE FOUND FROM NS.DELOS.COM Internet address = 65.102.83.117 server1.sans.org Internet address = 167.216.198.40 NS.BSDI.COM Internet address = 206.196.44.241
Assuming that you are at a subcommand prompt of the nslookup command, enter the subcommand set type=ns. You have just set the option to return an answer of a name server(s) to subsequent queries issued. Bump up one node on the DNS tree and query for sans.org to see the name servers for this domain. You discover all the name servers for sans.org, both host names and IP addresses. This appears to be a pretty good place to start the reconnaissance effort for a site. After discovering the name servers, one might scan those name servers for potential security deficiencies or to see what kind of Internet services or
daemons are being run on the DNS server.
HINFO: Snooping for Details
HINFO records are yet another record type stored by DNS. These are information records and another potential source for reconnaissance. A DNS server administrator has the option of entering host information, specifically the CPU type and operating system, when creating a new or maintaining an existing DNS record. If trusted intranet hosts use the DNS server, this is a way to maintain an inventory of the hosts without too much risk.
Because this provides too much information to unknown Internet users, many administrators do not enter these parameters. Obviously, if this type of information can be harvested from a
DNS server, a hacker can get some serious intelligence about the site.
> set type=hinfo > host49
Server: dns.my.com Address: 192.68.4.4
host49.my.com CPU = SunSparc |
OS = Solaris |
|
my.com nameserver =dns.my.com |
|
|
dns.my.com |
Internet address = 192.68.4.4 |
|
Set the type to hinfo as a subcommand in nslookup. Information is queried for host49, which is a fictional renaming of a real host. host49.my.com is a Sun SPARC running a version of the Solaris operating system. It is possible that a hacker's efforts might be foiled by outdated data kept in the HINFO records. This is probably one of the few times that less-than diligent
maintenance is a desirable thing.
List Zone Map Information
One of the easiest ways to discover a lot of information about a domain is to try to list all the zone map information. Assume that there is a domain with the lackluster name of fakeplace.com. You can attempt to dump the records associated with the domain using the
following subcommand in the nslookup utility:
> ls –d fakeplace.com
If the site has not disabled the dissemination or transfer of the data, the DNS server lists all records for the domain fakeplace.com. As a bonus to the information collector, this site also
maintains HINFO records. |
"SGI" "Irix" |
|||
whish |
1D |
IN HINFO |
||
1D |
IN A |
1D |
IN HINFO |
192.168.1.239 |
susie |
"IBM-RS/560F" "unix" |
|||
1D |
IN A |
1D |
IN HINFO |
172.16.16.13 |
pixie |
"IBM-RS/560F" "unix" |
|||
1D |
IN A |
1D |
IN HINFO |
172.12.16.14 |
bandit |
"PC" "Win98" |
|||
1D |
IN A |
1D |
IN HINFO |
192.168.3.107 |
adder |
"IBM-RS/530" "unix" |
|||
1D |
IN A |
1D |
IN HINFO |
172.16.133.4 |
hub21 |
"Cabletron-MMAC3" "SNMP" |
|||
1D |
IN A |
1D |
IN HINFO |
192.168.26.80 |
switch3 |
"Switch" "3COM" |
|||
1D |
IN A |
|
|
192.168.7.130 |
This information harvesting can occur only if the site allows indiscrimate access to TCP
destination port 53, because TCP is the transport protocol used to deliver this information.
Dig
Another information gathering technique is to query a DNS server for its BIND version
number:
dns.my.com% dig @MYDNS.COM version.bind txt chaos
;<<>> dig 8.1 <<>> @MYDNS.COM version.bind txt chaos
;(1 server found)
;;res options: init recurs defnam dnsrch
;;got answer:
;;->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;;flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;;QUERY SECTION:
;;version.bind, type = TXT, class = CHAOS
;;ANSWER SECTION:
VERSION.BIND |
0S CHAOS TXT |
"4.9.7-REL" |
A tool called dig (which stands for Domain Internet Groper) comes with many implementations of BIND. It has many of the same capabilities as nslookup. You have an option to display the version number of BIND running on a DNS server. The format of the command is as follows: dig followed by the at sign (@), followed by the name of the DNS server you want to examine, followed by the option version.bind, followed by the word TXT and the word CHAOS. The word TXT tells DNS that the type of entry you are searching for is a TXT record found in the DNS database. This is just a different record type, much as HINFO records and NS records are different types. Finally, you see the word CHAOS, which is a query class that is mostly obsolete.
This dig command has queried for the version number of MYDNS.com. You see that it is running an older version 4.9.7 of BIND. For someone conducting reconnaissance, this is valuable information. If a hacker can pair a BIND vulnerability with the version discovered, she is better able to target the name server for attack. BIND versions 8.2 and later have an options statement in the configuration file /etc/named.conf that will return a message instead of the version number. You select the contents of the message, perhaps something like "unknown version of BIND." But, if you feel mischievous, your message can return the wrong version of BIND just to confuse the information gatherer.