Wednesday, August 10, 2016

Active (Nmap) vs Passive (p0f) information gathering

In most cases, while attempting to learn about an environment, you may wish to either actively obtain information about the environment or passively do so.

Active information gathering means you are in one way or the other directly interacting with the system(s). An example of active information gathering is when a tool such as Nmap is used.

Passive information gathering on the other hand, means you passively “sit” and learn about the system(s) as information passes in your path. Note, these examples are specifically from a network perspective. Basically, you are not doing anything that will cause the remote system(s) to perform any response or any activity based on what you are doing.

Let’s look at this in practice.

Let’s “actively” learn about a remote system using Nmap.
From below we tell Nmap to target the host The options we specify are as follows:
-Pn - no need to ping the host, assume it is online
-sS - perform a SYN scan
-p1-65535 - Scan all TCP port
-sV - determine service version numbers - The host we are would like to scan

From the above we see Nmap learned that the host has TCP ports 135, 139 and 445 opened.

As we look at the Wireshark snapshot below, we can see a sample of the packets which were sent to and seen by host This is what is meant by “active” information gathering, the target host was “touched" and there is (in this case) supporting evidence to show that it was.

Alternatively, as we perform “passive” information gathering we can simply start up “p0f” and let it listen on the interface. Note, for this to work properly, you would need to be in the path of the traffic. This can be inline or even seeing the traffic off a SPAN port.

Once again, let’s look at this in practice.
We will use p0f with the following options.
-f /usr/share/p0f/p0f.fp - specify the fingerprint file to use
-i eth0 - specify the interface to listen on
-p - put the interface in promiscuous mode

From above we see that p0f “learned” that the system is running Windows NT kernel and this was learned via a SYN packet.

While the example above shows how we can use p0f to listen on an interface, we can actually run p0f against an existing .pcap file to learn about the environment.

To demonstrate this further, let’s borrow the attack-trace packet capture from honeynet project.

When running p0f against the pcap file, we can get even more creative. Let’s examine some of this creativity.

First up, let’s run p0f against our downloaded pcap. The main difference between the command line arguments when using p0f live vs reading a packet is the “-r” option.

-r attack-trace.pcap - use the attack-trace.pcap file as input.

From above we see a snapshot of the OS, client, server, etc from the pcap.

Let’s dig more. To find out the various OSes in the file, let’s run that through some additional tools, such as grep, awk, sort and uniq.

From the above, we see we have a count of all the different systems detected within the pcap.

The image below shows the various IPs. In this example, we introduce another Linux utility - “cut”.

Ok, let’s do one more before we go. Let’s use the same command above, but this time we will ask “cut” to use field 2 thus allowing us to see all the unique ports found in the file.

So there you go. In this post we looked at the difference between active and passive information gathering from the perspective of network reconnaissance.

Hope you enjoyed this post. If you did, please feel free to leave a comment.

honeynet project


  1. HI Nik,

    Great post. One thing to add is that sV will override the sS. Service detection cannot be performed without more than a SYN ACK return.

    Easy twist to your scan to make it a bit faster: nmap -sV -Pn -n -T4 -p- --open
    -sV: service detection
    -Pn: disabled ping
    -n: no DNS resolution (why waste time)
    -T4: faster execution (default is T3. Never got good results with T5)
    -p-: all ports (equiv. to -p1-65535)
    --open: list only open ports