Intrusion Detection FAQ: How can passive techniques be used to audit and discover network vulnerability?

Hee So


This paper examines methods to identify vulnerabilities within a network by only passively listening to network traffic. Since these techniques do not write any packets to the network, they could also be used in network forensics analysis. First, a history of operating system identification implementations using active TCP/IP stack fingerprinting is summarized. Second, current operating system identification implementations using passive techniques are discussed. Third, information cannot be trusted if it is crafted, but crafted packets also leave signatures. Therefore there is a discussion identifying the level of packet crafting. Fourth, vulnerabilities cannot be determined from OS alone, and passive banner grabbing technique is discussed. Finally, passive techniques for discovering the network topology and data flow are discussed.


Having a strong perimeter defense is less effective if the attacks can come from inside the network as well as from the Internet connection. In campus or corporate environments, machines may be compromised from within or through alternate entry points into the network e.g. wireless using WEP/802.11b protocol, laptops that have been infected while attached to other networks, or through email. The defense in depth concept for internal networks can be enumerated into the different layers of the device protocol stack -- physical layer, data-link link layer, TCP/IP layer, and application layer – as well as the network topology. How do you know if the ATM machine you are entering your pin into is a legitimate ATM? How do you know the van, driving next to you, is not acting as a cell site and your cell phone conversation is not being relayed through it? These questions can be answered with more confidence by identifying the level of packet craft. A back door router or an unsolicited host attached to the network, however, can be detected by passively detecting the network topology and its changes, and bandwidth utilization and direction from connection initiator to responder.

Ideally, a network analysis tool should not inject packets into the network by actively scanning machines. Not only will IDS be set off, possibly causing a feedback loop, there could be undesirable results from machines auto responding to port scans like those from Psionic’s PortSentry tool. Passive network sniffers put the network card into promiscuous mode, which can be detected as demonstrated by AntiSniff tool by L0PHT. Some sniffers like tcpdump and ethereal by default resolve IP addresses which inject DNS requests into the network. The existence of these sniffers can be detected by the presence of additional DNS requests due to the gethostbyaddr() from the sniffer on the same subnet. Thus, the first form of protection is to protect at the physical layer by using a one-way cable that only receives and does not transmit packets. Some name resolution can be achieved without injecting packets into the network by caching the netbios-ns, and the DNS replies.

Monitoring inside the LAN in addition to the DMZ and WAN connection point has the added advantage of using additional passive techniques to identify source spoofing at the Data Link layer. For example, the minimum Ethernet length is 60 bytes while the minimum TCP/IP packet is 40 byes. The frame header is 14 bytes so the remaining 6 bytes are filled in by the sending host. Solaris8 fills this in with 0x55 while many systems fill in using 0x00. A Netgear firewall uses a unique six(6) byte signature. Seeing a Windows signature coming from a Solaris box is suspicious. Once the packet is forwarded through a device like a router or firewall, these padded bytes could change thus making the detection of spoofing more difficult.

OS, applications and services visible from the network can be identified through passive OS fingerprinting and passive banner grabbing. If an internal host is exploited or a new exploit is announced, a comparison against existing hosts can be made to identify if other machines need to be hardened or patched. Finally, network topology mapping with direction of traffic flow can reveal where the perimeter defenses are necessary or if any have been violated.

OS Fingerprinting Implementations

An operating system can be identified by comparing slight differences in the implementations of the network protocol stack. When specifications are written, it is often unclear what to do under certain error conditions so implementations can vary. As specifications improve, not all implementations get updated thus leaving distinguishable differences between vendors. Initially abnormal combinations of TCP flags and options were used to see how a system responded and that difference could identify an operating system. These OS fingerprinting techniques eventually matured and injecting abnormal stimuli into the network was no longer necessary and fingerprinting could be achieved by reading one normal packet. A generalization is made that since OS fingerprinting using TCP has matured from an active technique to a passive one, that the current active fingerprinting using ICMP packets will eventually mature to passive techniques.

History of Active OS Fingerprinting Implementations

The first implementation of operating system fingerprinting was seen with SIRC by Johan, which used abnormal TCP flag tests to categorize hosts into four(4) categories ~VLinux, 4.4BSD, Win95, and Unknown. The logic was hard coded into the program. checkos by Shok used much of the same code as SIRC and also had telnet banner grabbing. By the time ss-3.11 by Su1d came out, twelve(12) operating systems could be identified. queso (Sep 1998) by Savage added additional checks and was the first to move the OS fingerprinting outside of the code into a text data file. cheops by Mark Spencer used the same OS fingerprinting file and added a graphical interface to queso as well as network topology mapping using traceroute. While queso used port 80(http) as a default, Cheops uses ports 80(http),139(netbios-ssn),and 23(telnet) -- probably because if a system didn~Rt have web running on it, it would be a Windows box using netbios-ssn or a Unix box with telnet. Below is an examination of the Cheops traffic.

0.00s (46) cheops > target: icmp echo request(id=9933,seq=3)
 (DF) (ttl 64, id 0)

+0.02s (54) cheops.8983 > target.80: ****S* seq=16552525 ack 0 win 4660 (ttl 255, id 151)
+0.02s (54) cheops.8985 > target.80: *A**S* seq=16552525 ack 0 win 4660 (ttl 255, id 152)
+0.02s (54) cheops.8986 > target.80: *****F seq=16552525 ack 0 win 4660 (ttl 255, id 153)
+0.02s (54) cheops.8987 > target.80: *A***F seq=16552525 ack 0 win 4660 (ttl 255, id 154)
+0.02s (54) cheops.8989 > target.80: ****SF seq=16552525 ack 0 win 4660 (ttl 255, id 155)
+0.04s (54) cheops.8990 > target.80: ****S* seq=16552525 ack 0 (rsvd bits=000011) win 4660 (ttl 255, id 156)

Notice the initial ICMP request and six packets with TCP flags set to SYN, SYN+ACK, FIN, FIN+ACK, SYN+FIN, and SYN with reserved bits set. For all the TCP packets, a random sequence number was the same, acknowledgement number=0, window size=4660, TTL=255, and the IP identification increased for every packet. Notice also that the timing is 20ms between packets and the last packet was 40ms apart. The queso/cheops algorithm for determining the OS was based on whether a response was received, TCP sequence number, acknowledgement number, TCP window size, and TCP flags. Since snort, a common network intrusion detection software, does not look at a sequence of packets for its signatures. Without a snort plugin, the easiest way to detect this sequence is to look for a unique packet. The last packet could be considered unique to the queso/cheops scans. A simple snort rule to detect this activity:

alert tcp any -> $HOME_NET any (msg:”queso scan”; flags:21S; ack: 0)
Unfortunately there is no window size in a snort rules, i.e. win: 4660 would have been better since a router with CWR/ECN congestion support could set the two reserved bits thus any TCP connection request would trigger a false positive.

nmap by Fydor

was the first active fingerprinting tool to bring the OS determination logic outside of the source code into a text based database which could allowed the number of detectible operating systems to scale very rapidly. When an OS signature is not known, the unknown signature is displayed and information on how to submit it to the nmap database is given thus utilizing the whole community to build the database. The tests looked at TCP flags and options that included measuring the TCP initial sequence numbers of the target host, several TCP packets that don’t contain normal information, and a UDP packet to a closed port. Again, the first packet is an ICMP echo request.
From the nmap OS fingerprint file describes the active fingerprint tests Tseq, T1 through T7, and PU.
# Tseq is the TCP sequenceability test
# T1 is a SYN packet with a bunch of TCP options to open port # T2 is a NULL packet w/options to open port
# T3 is a SYN|FIN|URG|PSH packet w/options to open port
# T4 is an ACK to open port w/options
# T5 is a SYN to closed port w/options
# T6 is an ACK to closed port w/options
# T7 is a FIN|PSH|URG to a closed port w/options
# PU is a UDP packet to a closed port
nmap classification of the TCP sequenceability or differences between TCP Initial Sequence Numbers (ISN)
TR – Truly random or difference between ISNs were >50K (Good Luck!)
C – Constant Sequence Numbers (Trivial Joke)
64K – Initial Sequence numbers are modulus of 64K (Trivial Joke)
I800 – Increments by 800 (Easy)
TD – Microsoft style time dependency i.e. 1 per millisecond (Easy)
RI – Random positive increments (Easy,Medium,Formidable,Worthy Challenge
The T1 through T7 tests look at responses to packet and examines the DF bit, window size, TCP ack, TCP flags, and TCP options. Tseq classifies the ISNs into TR, C, 64K, and I800 classes. If nmap can’t classify the ISN as TD class, then they are lumped into the RI class. According to SecuriTeam, beginning with Windows NT4.0 w/SP4 the Microsoft “one per millisecond” algorithm has changed, but is still predictable. The measurements used Tseq i.e. the ISN class in addition to the greatest common denominator, T5 tests, and PU tests is useful for passive fingerprinting and can provide additional OS resolution.


by Simple Nomad
In May 2001, icmpid was released as a proof of concept code, based on Ofir Arkin's ICMP research, to identify OS using the existence of stimulus/response pairs to ICMP Request packets and the responses to ICMP Echo Request packets that don’t contain normal information. The logic of OS identification was hard coded into the code.
ICMP Echo Request(type=8)     -> ICMP Echo Reply(0)

ICMP Timestamp Request(13) -> ICMP Timestamp Reply(14)
ICMP Address Mask Request(15) -> ICMP Address Mask Reply(16)
ICMP Information Request(17) -> ICMP Information Reply(18)
For passive OS fingerprinting, the unusual ICMP packets are not readily available on the network. If a Timestamp Reply was received or an Information Reply, then there would be a finite list of known boxes that could have responded. Values useful for passive compare of ICMP packets are a combination of IP identification, ToS, DF bit, IP reserved flag, TTL, existence of Timestamp Reply, existence of Address Mask Reply, existence of Info Reply.


by Ofir Arkin and Fyodor Yarochkin

xprobe-0.0.2 was released in Oct 2001. It sends on UDP packet to a default port 32132 and based on the response, sends additional ICMP packets to identify systems based on hard coded logic to determine OS. Currently there are 29 signatures.

 0.00s (46) xprobe.63667 > target.32132: udp 70 (DF)

+0.00s (68) xprobe > target: icmp: […varies depending on response from udp
ICMP Echo Reply and ICMP Destination Unreachable messages include a partial copy of the original IP packet received. Hosts return Destination Unreachable messages code=1 through 5 while routers return codes 6-12. Examination of this field as well as the length of the partially copied packet can distinguish different OS implementations. Typically most systems return the required IP header plus eight(8) additional bytes, but Linux and Solaris boxes return more.

Ofir Arkin’s research is relatively new as are the tools using the research. Just as p0f and ettercap have achieved a one line passive signature, and looking at the history of active fingerprinting using TCP flags and options, it is very likely to see one line passive fingerprints based on UDP/ICMP in the near future.
Below are the packet fields being compared by p0f.
IP Packet Length Is the packet a specific size (or ignore this comparison)
IP Don’t Fragment bit Is this flag set or not set
IP TTL This is the maximum Time To Live value.
TCP Window Size Observed window size.
TCP Option NOP Is the NOP option observed in the TCP options?
TCP Option Max Segment Size Observed mss value.
TCP Option Window Scale Should the wscale option be present? If so, what value
TCP Option Selective Ack OK Is SACKOK option specified?


by Alberto Ornaghi (ALoR) and Marco Valleri (NaGA)

This project began Nov 2000. This tool can actively scan the network but also has a passive OS fingerprinting feature with one line OS signatures similar to p0f. Ettercap not only compares the initial client SYN packet, but also the initial server SYN+ACK response packet, thus allowing both server and client to get fingerprinted when a TCP connection is established. The fields compared are very similar to those of p0f except that ettercap does not use the IP packet length, and does compare the existence of the Timestamp TCP option. By default ettercap-0.6.2 comes with about 85 SYN signatures and about 420 SYN+ACK signatures, but many of the signatures are very similar with one bit turned on and the other bit turned off. There are about 300 unique OS signatures. Notice that the ettercap algorithm can ignore the MSS and WSCALE TCP options which is slightly different than the p0f implementation. It is not clear which implementation is more effective.
v Ettercap looks at MAC addresses and ARP messages for mapping on the same broadcast domain. The routers are identified by identifying the MAC address of the packets destined to external IP addresses. Also the ICMP TTL-exceeded or redirect messages come from the hosts acting like a router. Identifying a non-local IP address requires the netmask. In forensics analysis, this might not be known, thus identifying which MAC address has multiple IP addresses can identify routers.

One slight improvement over the p0f implementation is that the TTL values are compared to the next power of two thus allowing for packets from over 30 hops away or packets through congested routers to get fingerprinted correctly.
Below are the nine(9) packet fields used by ettercap to passively OS fingerprint:
IP Don’t Fragment bit Is this flag set or not set
IP TTL This is the maximum Time To Live
TCP Flags This signature is valid for client SYN or server SYN+ACK comparison.
TCP Window Size Observed window size (or ignore this)
TCP Option NOP Is the NOP option observed in the TCP options?
TCP Option Max Segment Size Compare MSS value from options (or ignore this comparison)
TCP Option Window Scale Compare Window Scale value (or ignore this comparison)
TCP Option Selective Ack OK Is SACKOK option specified?
TCP Option Timestamp Is the timestamp option present?

Passive OS Fingerprinting on RST

When a TCP connection is requested by a client, the server will respond with a SYN+ACK to establish a connection or on most systems a RST+ACK if the server port is closed. Since OS fingerprinting is available on the SYN+ACK packet, by fingerprinting on the RST, both sides of the communication can be fingerprinted not only when a connection is established, but also if a connection is merely attempted. Below is an examination of the return RST+ACK packet of a telnet to a closed port. It shows that a certain level of OS distinction can be made.

len id set TTL seq win Operating System
=== == === === === === =====================
40B >0 yes 64 0 0 Solaris8
40B >0 no 128 0 0 WinME, Win2K Server
40B =0 yes 255 0 0 RedHat Linux 2.4.2
40B >0 no 255 0 0 RedHat Linux 2.0.30
40B >0 no 60 0 0 AIX Version 4

Note: The TCP sequence and/or acknowledgement numbers can change to a non-zero value when passed through a firewall.

From the data above plus evaluating the reply similar to T5 test from nmap, the OS can be identified on RST+ACK to a much better degree of accuracy by also looking at the following header information.

IP Don’t Fragment bit Is this flag set or not set
IP identifier Is this set to zero?
IP TTL This is the maximum Time To Live value.
TCP Flags TCP flags in addition to RST.
TCP Window Size Observed window size
TCP Options Which options are set.

Classification of Packet Crafting

Evidence of packet crafting is evidence of potential source spoofing. Identifying if a stimulus or response was crafted gives better insight to the method of attack and lethality of the attacker. Being able to classify what tools were used to craft packets makes it more predictable what the attacker can do. p0f was first to provide packet craft signatures e.g. queso and nmap in their database. Depending on what layer in the protocol stack was crafted, a tool would give the same signature for all platforms it was run from. If a system gave the signature that it was a Linux box and from time to time gave a different signature, then that could indicate signs of a crafted packet vs. authentic packet from the OS. Writing a TCP/IP protocol stack and using sockets() is possible but with new standard libraries like RawIP and Route’s libnet, it has become too easy to craft packets that could be run from a variety of systems. Below is a classification of levels of packet. Signs of a higher level of packet crafting is can indicate a higher potential for source spoofing. Some of the higher level of packet crafting could be used to fingerprint legitimate systems. Later, an example detecting packets crafted from one of these libraries is shown.
Authentic – either the packets are from real host or are too indistinguishable from a real machine e.g. a virtual machine. Normal passive OS fingerprinting techniques could be used to identify these systems.

Script Kiddie – Packets are from tools which are easily accessible to hackers e.g. queso and nmap. The limits of these crafted packets are or can be well understood as and easily identifiable and good guesses as to the attackers intent can be made.

Application - socket() – TCP or UDP packets can be generated using socket() relying on the operating system to handle a combination of TCP/UDP packet headers, TCP state, IP datagrams, and link layer frames. This could include DNS crafted packets. The IP portion of the packet is authentic as well as the TCP or UDP headers, however the application layer is completely crafted.

Atomic – These are packets that are crafted in quantities of one and possibly retransmitted in a loop with some counters. There is one stimulus and a response from the target could be expected. This can be subdivided further into the network protocol layers. socket() and SOCK_RAW, Route’s Libnet, or other libraries such as RawIP can be used to generate these packets.
Transport - socket() provides for crafting other packets like ICMP or your own TCP or UDP packets including header. The IP layer is authentic but IP protocol above is not.

Network – The next layer down, the IP headers, can be crafted.

Data Link – Complete frames can be crafted. Currently libnet_build_ethernet() only allows valid Ethernet frames to be transmitted. It is conceivable to build frames with additional data appended at the end of the normal IP packet as a covert means of communications within a LAN segment.
TCP Stateful – These crafted packets might try to exploit weaknesses in TCP state implementations like firewalls that consider a connection established if a SYN+ACK packet is seen or don’t close the firewall connection until after both sides finish a FIN+ACK transaction. Example of crafted packets in this category might go so far as only establishing a TCP three way handshake and data transfer but not handling the FIN+ACK connection termination properly. Atomic, or stateless, packets under error conditions will not retransmit packets. A TCP packet SYN packet to a non-responding port should retry. The TCP protocol is designed to retry in case a client to server or server to client packet is lost. How many retries are there? If normally there are three(3) retries are expected, and only one, two, or four are seen, then these are signs of stateful packet crafting or signatures for identifying different implementations. Different responses should be seen depending on where the connection was in the TCP state diagram. Other exploits might be based a looking for firewall implementations with a single TCP state table for the connection when there are really two TCP states – one for the connection initiator and responder. Packet injection could be such to change the TCP state of one side of the connection or hijack the connection by making the legitimate connection invalid. Using abnormal packets to maintain one TCP state in a firewall and a different one in the target host is another example of TCP Stateful crafted packets like that shown in Thomas Ptacek and Timothy Newsham’s research paper “Insertion, Evasion, and DoS Eluding Network Intrusion Detection.”

TCP Timer – Packet crafting signatures can also be identified by examining expected TCP flow control, timeout and retransmission values, and timers. Crafted packets might implement a simple or no retry algorithm. TCP retry time would double after each failure i.e. 3seconds, 6seconds, 12 seconds. How many times was this done before the retries ended? Was there evidence of a delayed ACK packet? Many implementations wait up to 200ms before responding to an ACK to see if the source will send more packets. The RFCs say that the TCP implementation of delayed acks must be less than 500ms. Was there evidence of the Nagle Algorithm? Nagle Algorithm is a form of congestion control to reduce tiny packets going across the WAN that says that TCP segments smaller than the segment size cannot be sent until the outstanding ACK arrives. Is there evidence of slow start algorithm, which limits the amount of data initially sent. If there was a UDP or ICMP packet repeated a few times every 500ms, would this be suspicious – especially since UDP is doesn’t retry sending packets. The LaBrea Tarpit written by Tom Liston to slow down the spread of the Code Red worm is a whitehat example of crafted packets in this category. If another attacker was crafting the Code Red packet, it might not retry, it might not retry five(5) times, or might not double the delay between retries, all of which should be suspicious and leave a signature.
With libraries like Route’s libnet, it is very easy to craft packets. Attacks can be achieved with only implementing a simple TCP table and no error or congestion handling. Omitting these leave signatures that distinguish one program from another. Both Stateful and Timer based crafting would require examination of multiple packets and are considered advanced techniques.

Sample fingerprinting of crafted packet using libraries

There are many libraries to craft IP level packets such as the very popular Route’s libnet. Not everyone’s choice language is C. Some might want to use the Net/RawIP libraries for Python or Perl. Below is an example of a network layer packet craft using Perl’s Net/RawIP libraries.
Hex dump of IP packet header defaults
45 10 00 00  00 00 40 00  40 pp vv vv  ss ss ss ss  tt tt tt tt is the source IP, is the destination IP. pp = IP protocol and vvvv = valid checksum. The IP packet header defaults indicate an 8bit ToS of 0x10 (Minimum Delay), DF flag set, and TTL=64 with no IP options. The checksum is always valid since it is automatically calculated.
Hex dump of TCP header defaults
ss ss dd dd  00 00 00 00  00 00 00 00  50 0A FF FF
  vv vv 00 00

ssss = source port, dddd = dest port, vvvv = valid checksum. The TCP segment header defaults have no TCP options, Push & SYN flag are set, window size=0xffff, and URG pointer =0. The window size is the most notable.
Sample Code

# This is how simple it is to craft your own packet. The coder is not thorough
# and has not defined all values for every header field thus the defaults are
# used. These defaults can be used to identify a detailed hacker.
# What about the ToS value? DF bit? IP id? TCP window size?

use Net::RawIP
$a = new Net::RawIP;

$a->set({ip=> {saddr => "", daddr => "”},
tcp=> {source=> 2314, dest=> 2828, psh => 1, syn => 1}
What are these other values for the rest of the IP header and TCP header? They would contain the defaults. This should be easy to identify as a crafted TCP packet as seen below.
45 10 00 00  00 00 40 00  40 06 vv vv  01 02 03 04  05 06 07 08

09 0A 0B 0C 00 00 00 00 00 00 00 00 50 0A FF FF vv vv 00 00
Passive Banner Grabbing

Banner grabbing is commonly available in many scanning tools. However, analyst tools that examine packet headers such as tcpdump or snort capture a fixed length of the packet header and save it in a libpcap file format. The larger the snapshot length, or snaplen, the more the payload can be examined, but more disk space is required to save the dumps; while a shorter snaplen has the advantage of saving more disk space, however, there is more likelihood of truncation of the packet header information. By default, tcpdump uses a snaplen=144 Bytes while the maximum is 1500 Bytes for Ethernet. While packet header analysis is very helpful, the header information of a TCP stream could easily get truncated. Using a “dynamic snapshot length” solves this problem. To illustrate this concept, if the TCP snaplen was set to 2KB, then after the TCP connection state is change to ESTABLISHED, the 2KB of server and 2KB of the client TCP payload would get recorded into the libpcap dump file. This is analogous to the phone company recording the first few seconds of the phone conversation (TCP stream) for identification of callers as well as the phone numbers dialed from and to (TCP+IP headers). For passive banner grabbing, only the 2KB of the server TCP stream needs to be saved. For libpcap implementations, “dynamic snaplen” could be used when saving the dump file by setting pcap_file_header.snaplen=1500 and pcap_pkthdr.caplen=size_of_headers. Once a TCP connection is ESTABLISHED, then the capture length should be set to capture the TCP payload, pcap_pkthdr.caplen=size_of_headers+TCP payload, until the 2KB was reached, then would continue to just store the headers.

There is an excellent article “Passive System Fingerprinting using Network Client Applications” by Jose Nazario. He shows that from looking at a three letter abbreviation in a pine Message-ID, the OS flavor can be determined. The article shows other examples of OS information being leaked in other headers like HTTP headers as seen below.
Example of application, application version, and operating system:
root@dell103 init.d]# telnet 80

Connected to (
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.1 200 OK
Date: Sun, 13 Jan 2002 11:47:13 GMT
Server: Apache/1.3.19 (Unix) (Red-Hat/Linux)
Last-Modified: Thu, 29 Mar 2001 17:53:01 GMT
ETag: "b6c7-b4a-c33a767d"
Accept-Ranges: bytes
Content-Length: 2890
Connection: close
Content-Type: text/html
Example of application and application version:
[watts@myhost ~watts]$ telnet some.mail.server.out.there 25

Connected to some.where.out.there (
Escape character is '^]'.
220 some.where.out.there ESMTP Exim 1.73 #1 Sat, 12 Jan 2002 20:46:22 –0800
Not all systems are nice enough to give the product name and version number. e.g.
220 some.where.out.there ESMTP Exim
But this is still useful for auditing your network for potential vulnerabilities. If it is known that a specific version of software has a known vulnerability, e.g. CVE-1999-0971 Exim 1.62 local root exploit, then this system running Exim should be tagged as a possible vulnerable system, but that some details are unknown.

The problem with the passive banner grabbing method is that the banner is only available when someone connects to the server. Banners are being removed as a security measure, but sometimes this cannot be turned off as it is part of the protocol for both sides to identify the versions that each side supports for example in the case of SSH.
[watts@myhost ~watts]$ telnet some.ssh.server.out.there 22

Connected to some.where.out.there (
Escape character is '^]'.
Passive Network Mapping

Network managing and mapping can be done using the Simple Network Management Protocol (SNMP) however not all devices support SNMP nor is access to those devices always granted. Plus, SNMP is not necessarily secure. SNMP doesn’t identify when an unauthorized host has been attached to the network, doesn’t identify when the switched network traffic path has been altered through ARP cache poisoning or if additional backdoors into the network exist with additional routers or hosts acting as routers with IP_FORWARD enabled. In combination with the other passive techniques described in this paper, the list of devices, services running, and topology can be detected and compared against a database of known vulnerabilities. Mapping is broken down to each network layer – Data-Link layer, Network/Transport layer, and Application Layer; as well as the network topology and direction of traffic flow.

  1. All available devices on the network and visiting hosts
    Identify source and destination MAC addresses and amount of traffic in each direction and associate the IP address with each MAC. The arpwatch tool is an example of this. At least one of these MAC addresses should be a router. If there are duplicate IP addresses for a given MAC, this is a possible ARP cache poisoning. Visiting hosts can be identified by monitor port 68 and port 67 and any dynamic IP requests. Traffic routed through a visiting host would be suspicious.
  2. Routers
    If the netmask is known, then the MAC address of any traffic to an external subnet identifies a router. If the netmask is not known and packets destined to multiple external IP addresses are seen go to one MAC address, then this device is a possible router. Using a combination of ICMP Destination Unreachable, TTL Exceeded and a number of packets that only come from routers e.g. routing protocol messages, these can identify routers as well as any box acting like a router. Passively identifying different operating systems from the same IP address could indicate the size of the network behind the NAT box. ARP cache poisoning with a man in the middle acting like a router, using IP_FORWARD, would decrement the TTL count of the packet and show up as an altered topology unless the attacker was more clever and only replayed the original packet.
  3. All servers and services
    Systems offering TCP services can be identified by using SYN+ACK packet and passive banner grabbing. UDP datagrams requires examination of the payload to determine server side and client side stimulus or response.
  4. Passive Topology Building and traffic flow
    Routing information as well as router neighbor discovery is a good source which gives you an idea of the devices on the local subnet, the router and an idea of the subnets on the other side of the router. Netmask is difficult to obtain since it is possible for different devices on the same LAN segment to have different netmasks. Netbios-ns transmits a packet to the subnet broadcast address regularly. Below is a further breakdown of additional sources of network topology information.

    Non-Routing: ICMP messages from routers e.g. TTL exceeded or destination unreachable. There are enough stray traceroutes in the network to get this information. For traceroute, Windows sends ICMP packets while Unix sends UDP packets. Since the ICMP TTL Exceeded message puts a copy of the original IP header in the reply it is easy to identify which are stimulus and which are response packets Additional topology information can be found from other less commonly seen packets e.g. ICMP route record, IP loose and strict source routing. If the network is monitored using SNMP, there are plenty of stray SNMP packets containing host interface and neighbor information in the standard MIBS.

    Switching: Spanning Tree protocol and MPLS.

    Internal Routing protocols: Routing protocols are noisy as the routers need to keep each other informed about their link states. A number of sources are available to map out small to medium networks such as RIP, OSPF, IGRP/EIGRP, IS-IS.

    External routing protocols: BGP

    Multicast: Using the Multicast group join messages as well as multicast router neighbor discovery messages from IGMP, PIM-Sparse Mode, PIM-Dense Mode, DVMRP, and MOSPF can give more network topology information.
Using multiple distributed sensors to capture attacker information concurrently can give more information about the attacker. To use multiple device sources during forensics, the timestamps of the different sources would have to be synced up. The tcpdump files stores a pcap_file_header.thiszone GMT to local time correction and a pcap_file_header.sigfigs timestamp accuracy information, but I haven’t seen any application use these fields yet.


Looking at the trends of active OS fingerprinting and current passive techniques available, there is no doubt that passive OS fingerprinting can be done on TCP connection establishment, acknowledgement, and rejection. In the near future ICMP packets will be passively fingerprinted from a single line in a text file. In addition to identifying the potential lethality of the attackers, identifying packet crafting signatures can help distinguish authentic vs. spoofed data to properly audit the network state. Combining passive OS fingerprinting, passive banner grabbing, and passive network topology, the traffic flow and a good idea of the state of the internal network can be acquired. Having catalogued the network devices, their operating systems, and services provided, a quicker response time can be achieved in prioritizing and patching up vulnerable systems within the network.


Stevens, W. Richard. TCP/IP Illustrated, Volume 1. Reading: Addison Wesley Longman, Inc, 1994.

Ptacek, Thomas H. et al. “Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection.” Jan 1988.
URL: (20 Jan 2002)

Fydor, “Remote OS detection via TCP/IP Stack FingerPrinting.” 10 Apr 1999.
URL: (20 Jan 2002) “AntiSniff - find sniffers on your local network.” 31 Jul 1999.
URL: (20 Jan 2002) “NT Predictable initial TCP sequence vulnerability revisited.” 28 Aug 1999.
(20 Jan 2002).

Al-Herbish, Thamer. “Raw IP Networking FAQ” 1.3. 11 Nov 1999
URL: (20 Jan 2002)

Schiffman, Michael D. “Libnet 101, Part1: The Primer.” 19 Jun 2000
URL: (20 Jan 2002)

Nazario, Jose. “Passive System Fingerprinting using Network Client Applications.” 19 Jan 2001.
URL: (20 Jan 2002)

Chmielarski, Tom. “Reconnaissance Technique using Spoofed IP Addresses.” 4 Apr 2001.
URL: (20 Jan 2002)

Arkin, Ofir. “ICMP Usage in Scanning – The Complete Know How.” 3.0. Jun 2001.
URL: (20 Jan 2002).

Honey net Project. “Passive Fingerprinting: Idling remote hosts, without them knowing.” 3 Sep 2001.
URL: (20 Jan 2002).

Track 3: The Most Advanced Intrusion Detection Immersion Training Avilable
< Previous Question | Back to Intrusion Detection FAQ Home | Next Question >