                    =============================
                    p0f v3: passive fingerprinter
                    =============================

                http://lcamtuf.coredump.cx/p0f3.shtml

     Copyright (C) 2012 by Michal Zalewski <lcamtuf@coredump.cx>

What's this?

P0f is a tool that utilizes an array of sophisticated, purely passive traffic fingerprinting mechanisms to identify the players behind any incidental TCP/IP communications (often as little as a single normal SYN) without interfering in any way.

Some of its capabilities include:

Highly scalable and extremely fast identification of the operating system and software on both endpoints of a vanilla TCP connection - especially in settings where NMap probes are blocked, too slow, unreliable, or would simply set off alarms,
Measurement of system uptime and network hookup, distance (including topology behind NAT or packet filters), and so on.
Automated detection of connection sharing / NAT, load balancing, and application-level proxying setups.
Detection of dishonest clients / servers that forge declarative statements such as X-Mailer or User-Agent.

The tool can be operated in the foreground or as a daemon, and offers a simple real-time API for third-party components that wish to obtain additional information about the actors they are talking to.

Common uses for p0f include reconnaissance during penetration tests; routine network monitoring; detection of unauthorized network interconnects in corporate environments; providing signals for abuse-prevention tools; and miscellanous forensics.

A snippet of typical p0f output may look like this:

A live demonstration can be seen here:

http://lcamtuf.coredump.cx/p0f3/

How does it work?

A vast majority of metrics used by p0f were invented specifically for this tool, and include data extracted from IPv4 and IPv6 headers, TCP headers, the dynamics of the TCP handshake, and the contents of application-level payloads.

For TCP/IP, the tool fingerprints the client-originating SYN packet and the first SYN+ACK response from the server, paying attention to factors such as the ordering of TCP options, the relation between maximum segment size and window size, the progression of TCP timestamps, and the state of about a dozen possible implementation quirks (e.g. non-zero values in "must be zero" fields).

The metrics used for application-level traffic vary from one module to another; where possible, the tool relies on signals such as the ordering or syntax of HTTP headers or SMTP commands, rather than any declarative statements such as User-Agent. Application-level fingerprinting modules currently support HTTP. Before the tool leaves "beta", I want to add SMTP and FTP. Other protocols, such as FTP, POP3, IMAP, SSH, and SSL, may follow.

The list of all the measured parameters is reviewed in section 5 later on. Some of the analysis also happens on a higher level: inconsistencies in the data collected from various sources, or in the data from the same source obtained over time, may be indicative of address translation, proxying, or just plain trickery. For example, a system where TCP timestamps jump back and forth, or where TTLs and MTUs change subtly, is probably a NAT device.

How do I compile and use it?

To compile p0f, try running './build.sh'; if that fails, you will be probably given some tips about the probable cause. If the tips are useless, send me a mean-spirited mail.

It is also possible to build a debug binary ('./build.sh debug'), in which case, verbose packet parsing and signature matching information will be written to stderr. This is useful when troubleshooting problems, but that's about it.

The tool should compile cleanly under any reasonably new version of Linux, FreeBSD, OpenBSD, MacOS X, and so forth. You can also builtdit on Windows using cygwin and winpcap. I have not tested it on all possible varieties of un*x, but if there are issues, they should be fairly superficial.

Once you have the binary compiled, you should be aware of the following command-line options:

-f fname - reads fingerprint database (p0f.fp) from the specified location. See section 5 for more information about the contents of this file.

           The default location is ./p0f.fp. If you want to install p0f, you
           may want to change FP_FILE in config.h to /etc/p0f.fp.

-i iface - asks p0f to listen on a specific network interface. On un*x, you should reference the interface by name (e.g., eth0). On Windows, you can use adapter index instead (0, 1, 2...).

           Multiple -i parameters are not supported; you need to run
           separate instances of p0f for that. On Linux, you can specify
           'any' to access a pseudo-device that combines the traffic on
           all other interfaces; the only limitation is that libpcap will
           not recognize VLAN-tagged frames in this mode, which may be
           an issue in some of the more exotic setups.

           If you do not specify an interface, libpcap will probably pick
           the first working interface in your system.

-L - lists all available network interfaces, then quits. Particularly useful on Windows, where the system-generated interface names are impossible to memorize.

-r fname - instead of listening for live traffic, reads pcap captures from the specified file. The data can be collected with tcpdump or any other compatible tool. Make sure that snapshot length (-s option in tcpdump) is large enough not to truncate packets; the default may be too small.

           As with -i, only one -r option can be specified at any given
           time.

-o fname - appends grep-friendly log data to the specified file. The log contains all observations made by p0f about every matching connection, and may grow large; plan accordingly.

           Only one instance of p0f should be writing to a particular file
           at any given time; where supported, advisory locking is used to
           avoid problems.

-s fname - listens for API queries on the specified filesystem socket. This allows other programs to ask p0f about its current thoughts about a particular host. More information about the API protocol can be found in section 4 below.

           Only one instance of p0f can be listening on a particular socket
           at any given time. The mode is also incompatible with -r.

-d - runs p0f in daemon mode: the program will fork into background and continue writing to the specified log file or API socket. It will continue running until killed, until the listening interface is shut down, or until some other fatal error is encountered.

           This mode requires either -o or -s to be specified.

           To continue capturing p0f debug output and error messages (but
           not signatures), redirect stderr to another non-TTY destination,
           e.g.:
           
           ./p0f -o /var/log/p0f.log -d 2>>/var/log/p0f.error
           
           Note that if -d is specified and stderr points to a TTY, error
           messages will be lost.

-u user - causes p0f to drop privileges, switching to the specified user and chroot()ing itself to said user's home directory.

           This mode is *highly* advisable (but not required) on un*x
           systems, especially in daemon mode. See section 7 for more info.

More arcane settings (you probably don't need to touch these):

-p - puts the interface specified with -i in promiscuous mode. If supported by the firmware, the card will also process frames not addressed to it.

-S num - sets the maximum number of simultaneous API connections. The default is 20; the upper cap is 100.

-m c,h - sets the maximum number of connections (c) and hosts (h) to be tracked at the same time (default: c = 1,000, h = 10,000). Once the limit is reached, the oldest 10% entries gets pruned to make room for new data.

           This setting effectively controls the memory footprint of p0f.
           The cost of tracking a single host is under 400 bytes; active
           connections have a worst-case footprint of about 18 kB. High
           limits have some CPU impact, too, by the virtue of complicating
           data lookups in the cache.

           NOTE: P0f tracks connections only until the handshake is done,
           and if protocol-level fingerprinting is possible, until few
           initial kilobytes of data have been exchanged. This means that
           most connections are dropped from the

P0f

Install / Use

README

Related Skills