- •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
Single Exploit, Portmap
The following trace is fairly simple. In this case, a system is targeting multiple sites looking for portmapper. An interesting thing about this scan is that the attacking host comes from a U.S. Government lab. Despite the way the government is portrayed by the X-Files and in various movies, this probably is not a covert plot. Instead, when you get attacked by government computers, it is an opportunity to make a difference: That system is probably compromised. When I called that lab, the fellow in charge of security was so thankful for the tip that he was willing to send me the attack code and data files from the attacker. The attack code was targeting rpc.statd. The data files had two names: XXX.domains and XXX.results, in which XXX was the target of the attack such as mil.domains and isp.domains. This is called the shopping list. The results file was a listing of systems that had systems with active, unprotected portmappers. These results files were presumably the shopping lists for the next stage of this attack, the actual exploit. The sensors in this case were TAMU netloggers, an interesting but
obsolete network-logging software package and their trace is shown below.
994 -> relay.nnnn.arpa.net
994 -> relay.nnnn.arpa.net
994 -> relay.nnnn.arpa.net
995 -> ns1.nnnn.arpa.net
954 -> 192.168.16.7
954 -> 192.168.16.7
861 ->
861 ->
861 ->
Port 111 TCP is an attempt to access portmapper. This trace was particularly interesting because for several years access attempts on TCP 111 were fairly rare, although UDP 111 attempts were quite common. This particular attempt was a harbinger of things to come. Note that the source ports are all below 1024, which indicates the process running on the government system is running as root. This system is compromised! By March 1998, this exploit was mowing down a large number of Sun Solaris systems, many of which were the DNS, web, or mail servers for their sites. This is particularly interesting because the vulnerability was widely known and the fix was widely available, as shown here:
● Computer Emergency Response Team (CERT) put out a warning in December 1997 at
http://www.cert.org/advisories/CA-97.26.statd.htm.
●More and more UNIX operating systems were shipping with "secure" portmappers.
●Wietse Venema's code to protect portmapper was available at
http://coast.cs.purdue.edu/pub/tools/unix/portmap.
rexec
The following trace is just a variety of rexec attempts. The interesting thing about rexec is that it does expect a password for authentication. So, why don't the attackers use rlogin instead? They are probably trying default passwords, because rexec does not tend to log. Also, SGI systems shipped for a long time with a guest account with a password of guest. An attacker could then use this at least to get reconnaissance information and probably to also begin privilege escalation. An attacker has a low chance of being detected unless the site has either networkor host-based intrusion detection.
The following trace represents how many attempts?
21:30:17.210000 prober.1439 > 172.20.18.173.512: S 334208000:334208000(0) win 61440
21:30:22.720000 prober.1439 > 172.20.18.173.512: S 334208000:334208000(0) win 61440
21:30:46.720000 prober.1439 > 172.20.18.173.512: S 334208000:334208000(0) win 61440
21:31:02.170000 prober.1449 > 172.20.18.173.512: S 340608000:340608000(0) win 61440
21:31:07.720000 prober.1449 > 172.20.18.173.512: S 340608000:340608000(0) win 61440
21:31:31.720000 prober.1449 > 172.20.18.173.512: S 340608000:340608000(0) win 61440
Two attempts. Observe the source ports 1439 and 1449—each is retried two times. Also, note the sequence numbers: 33420… for the first three packets and 34060… for the second set of three packets. You need more data to make an educated assessment, but notice that the two sequence numbers end in 08000. Given two distinct TCP sequence numbers, it is very unlikely that they would have this pattern. This might indicate some kind of crafting of the sequence number. Look at other TCP sequence numbers referenced in the book, and you will discover
that most are fairly unique and do not show such patterns.
POP3
Here, we have a fast scan with nicely uniform arrival times. If this doesn't set off our scan detect code, nothing will! A number of POP buffer exploits exist, so the target is easy to understand.
What is odd about this trace is the host selection. The scan is targeting a particular subnet, number 14. But what is the deal with the hosts? If you were the analyst on duty and you saw
this, what would you check for?
20:35:25.260798 bad.guy.org.4086 > 192.168.14.101.110: S 20:35:25.279802 bad.guy.org.4129 > 192.168.14.119.110: S 20:35:25.281073 bad.guy.org.4141 > 192.168.14.126.110: S 20:35:25.287761 bad.guy.org.4166 > 192.168.14.128.110: S 20:35:25.290293 bad.guy.org.4209 > 192.168.14.136.110: S 20:35:25.295865 bad.guy.org.4234 > 192.168.14.141.110: S 20:35:25.303651 bad.guy.org.4277 > 192.168.14.146.110: S 20:35:25.317924 bad.guy.org.4302 > 192.168.14.173.110: S 20:35:25.319275 bad.guy.org.4378 > 192.168.14.171.110: S
(If my answer differs from yours, it's okay.) I would want to know whether these were actually active hosts on the 14 subnet. If they are, the attacker already clearly has some information about us from a previous intelligence-gathering effort. If they are active hosts, and also run
popd, it is past time to consider increasing the countermeasures for that subnet!
Targeting SGI Systems?
The following trace shows a port scan, but it is pretty specific and it looks like a UNIX system is the target. This is believed to be targeted at SGI UNIX systems due to port 5232, part of their distributed graphics. Unless the intrusion-detection system is weighting the IMAP and telnet
port (and most do), this scan could easily be missed because it is only three packets:
21:17:12 prober.1351 > 172.20.4.6.imap: S 19051280:19051180(0) win 512 <mss
1460>
21:17:12 prober.1352 > 172.20.4.6.5232: S 12879079:12879079(0) win 512 <mss 1460>
21:17:12 prober.1353 > 172.20.4.6.telnet: S 42734399:42734399(0) win 512 <mss 1460>
Discard
When Discard gets a packet, it throws it away. When we detected this, we joked that it must be a student of Richard Stevens (because he uses Discard for many of the examples in his book). In this case, four SYNs were attempted to each host in the scan before moving on to the next
host in the scan:
08:02:35 dscrd.net.268 > 192.168.160.122.9: S 1797573506:1797573506(0) win 16384 (DF)
08:02:38 dscrd.net.268 > 192.168.160.122.9: S 1797573506:1797573506(0) win 16384 (DF)
Three-Port Scan
I added this scan primarily because the added latency of the HTTP portion of the scan. It is much slower than the rest of the trace. And as an added bonus, I bet you haven't seen a daytime scan before! Most likely, this is a benign network mapping effort out of Bell labs called Netsizer—of course, if the source address happens to be your primary competitor, you might
want to look into this further! Here it is:
20:50:04.532822 prober.54934 > myhost.domain: S 2118852885:2118852885(0) win 8760 (DF)
20:50:08.028023 prober.54934 > myhost.domain: S 2118852885:2118852885(0) win 8760 (DF)
20:50:14.432349 prober.54934 > myhost.domain: S 2118852885:2118852885(0) win 8760 (DF)
20:50:27.226116 prober.54934 > myhost.domain: S 2118852885:2118852885(0) win 8760 (DF)
20:50:52.824148 prober.54934 > myhost.domain: S 2118852885:2118852885(0) win 8760 (DF)
20:53:26.414741 prober.54944 > myhost.http: S 2144702009:2144702009(0) win 8760 (DF)
20:53:29.913485 prober.54944 > myhost.http: S 2144702009:2144702009(0) win 8760 (DF)
20:53:49.111043 prober.54944 > myhost.http: S 2144702009:2144702009(0) win 8760 (DF)
20:54:14.710959 prober.54944 > myhost.http: S 2144702009:2144702009(0) win 8760 (DF)
20:55:05.905554 prober.54944 > myhost.http: S 2144702009:2144702009(0) win 8760 (DF)
21:00:10.209063 prober.54968 > myhost.daytime: S 2196732969:2196732969(0) win 8760 (DF)
21:00:13.703247 prober.54968 > myhost.daytime: S 2196732969:2196732969(0) win 8760 (DF)
21:00:20.103798 prober.54968 > myhost.daytime: S 2196732969:2196732969(0) win 8760 (DF)
21:00:32.902480 prober.54968 > myhost.daytime: S 2196732969:2196732969(0) win 8760(DF)
21:00:58.500635 prober.54968 > myhost.daytime: S 2196732969:2196732969(0) win 8760(DF)
Weird Web Scans
This scan earns no speed records, but that is intentional. Is the attacker looking for web servers? We could hypothesize they are and UNIX-based web servers at that. Sending the
packet to the 0 host address is an old-style BSD broadcast; Windows systems will fail to answer. The scan proceeds at a slower rate so that all the inputs can be processed.
Note the source port remains the same for each subnet:
18:45:06.820 b.t.t.6879 > 172.20.1.0.http: S 1025092638:1025092638(0) win 61440
18:45:09.356 b.t.t.7136 > 172.20.2.0.http: S 1041868014:1041868014(0) win 61440
18:45:12.626 b.t.t.6879 > 172.20.1.0.http: S 1025092638:1025092638(0) win 61440
18:45:14.375 b.t.t.7395 > 172.20.3.0.http: S 1059077568:1059077568(0) win 61440
18:45:15.184 b.t.t.7136 > 172.20.2.0.http: S 1041868014:1041868014(0) win 61440
18:45:16.790 b.t.t.7650 > 255.255.255.255.http: S 1075727476:1075727476(0) win 61440
18:45:17.970 b.t.t.7905 > 172.20.5.0.http: S 1092175088:1092175088(0) win 61440
18:45:20.190 b.t.t.7395 > 172.20.3.0.http: S 1059077568:1059077568(0) win 61440
18:45:20.442 b.t.t.8160 > 172.20.6.0.http: S 1108940634:1108940634(0) win 61440
18:45:22.695 b.t.t.7650 > 255.255.255.255.http: S 1075727476:1075727476(0) win 61440
18:45:23.648 b.t.t.7905 > 172.20.5.0.http: S 1092175088:1092175088(0) win 61440
TCP Broadcast?
Well, the 0 host ID looks like old-style broadcasts, and smells like old-style broadcasts, but here is a comment from one of the book's reviewers:
"First, there is no such thing as broadcasting using TCP. See TCP/IP Illustrated, Volume I, p. 169: 'Broadcasting and multicasting only apply to UDP, where it makes sense for an application to send a single message to multiple recipients. TCP is a connection-oriented protocol that implies a connection between two hosts (specified by IP addresses) and one process on each host (specified by port numbers).'
"In fact, to be sure I tried this out against our test network, which contains about 25 hosts—all different OSs and hardware, old software and new software—against several different TCP ports, using both the .0 and the .255 broadcasts…and no hosts will answer this request. The .0 or .255 address is interpreted as a unicast address and no other hosts on the net will pick up the packet. This further makes sense when we think about how TCP identifies connections according to the tuple (src ip, dst ip, src port, dst port). In the case of a broadcast address, there is no way to include that address in the tuple. The attacker cannot obtain a broadcast-type response from these SYN packets because there is no way to negotiate a three-way handshake using a broadcast address."
However, routers do not work at the TCP layer, they work at the IP layer; so this packet is not actually looking for web servers, it is doing reconnaissance hoping for ICMP error messages such as unreachables.
The following excerpt is another web-based scan, from the access_log of a UNIX computer running the Apache web server code. This captured the contents of the traffic destined for the httpd port. By using both the network IDS and the host-based logs, we can fuse what is happening. Apache is the most popular web server software in use on the Internet. This trace is the result of a popular web server multi-CGI-BIN exploit; whisker or the nessus tools are
famous examples. These are commonly in use. We cannot seem to go a day without someone trying to run one of these against www.sans.org: