The cost of tracking a single host is under 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 cache in under 5 seconds; consequently, the 'c' variable can be much lower than the real number of parallel connections happening on the wire.
The first parameter is given in seconds, and defaults to 30 s; the second one is in minutes, and defaults to min. Low-performance sites may want to increase it slightly. The second value governs for how long API queries about a previously seen host can be made; and what's the maximum interval between signatures to still trigger NAT detection and so on. Raising it is usually not advisable; lowering it to minutes may make sense for high-traffic servers, where it is possible to see several unrelated visitors subsequently obtaining the same dynamic IP from their ISP.
Well, that's about it. You probably need to run the tool as root. Some of the most common use cases:. Command-line options may be followed by a single parameter containing a pcap-style traffic filtering rule. This allows you to reject some of the less interesting packets for performance or privacy reasons. Simple examples include: 'dst net API access The API allows other applications running on the same system to get p0f's current opinion about a particular host.
This is useful for integrating it with spam filters, web apps, and so on. The queries will be answered in the order they are received. Note that there is no response caching, nor any software limits in place on p0f end, so it is your responsibility to write reasonably well-behaved clients.
Queries have exactly 21 bytes. The format is: - Magic dword 0x , in native endian of the platform. IPv4 addresses should be aligned to the left. To such a query, p0f responds with: - Another magic dword 0x , native endian.
Zero if not known. Zero if never detected. The value of 1 means OS difference possibly due to proxying , while 2 means an outright mismatch. NOTE: If the host is first seen using an known system and then switches to an unknown one, this field is not reset. May be empty if no data. A simple reference implementation of an API client is provided in p0f-client. Developers using the API should be aware of several important constraints: - The maximum number of simultaneous API connections is capped to The limit may be adjusted with the -S parameter, but rampant parallelism may lead to poorly controlled latency; consider a single query pipeline, possibly with prioritization and caching.
You should look at your traffic stats and see if the defaults are suitable. You should also keep in mind that whenever you are subject to an ongoing DDoS or SYN spoofing DoS attack, p0f may end up dropping entries faster than you could query for them.
It's that or running out of memory, so don't fret. The timeout is adjustable with -t, but you should not use the API to obtain ancient data; if you routinely need to go back hours or days, parse the logs instead of wasting RAM. Fingerprint database Whenever p0f obtains a fingerprint from the observed traffic, it defers to the data read from p0f. The fingerprint database is a simple text file where lines starting with ; are ignored.
Section identifiers are enclosed in square brackets, like so: [module:direction] module - the name of the fingerprinting module e. The 'direction' part is omitted for MTU signatures, as they work equally well both ways. The goal there is to give an answer slightly better than "unknown", but less precise than what the user may be expecting. Normal, reasonably specific signatures that can't be radically improved should have their type specified as 's'; while generic, last-resort ones should be tagged with 'g'.
Note that generic signatures are considered only if no specific matches are found in the database. To assist with this, OS-specific signatures should specify the OS architecture family here e. Other signatures, such as HTTP, should use '! NOTE: To avoid variations e. Can be the version of the identified software, or a description of what the application seems to be doing e. P0f uses labels to group similar signatures that may be plausibly generated by the same system or application, and should not be considered a strong signal for NAT detection.
To further assist the tool in deciding which OS and application combinations are reasonable, and which ones are indicative of foul play, any 'label' line for applications class '! All sections except for 'name' are omitted for [mtu] signatures, which do not convey any OS-specific information, and just describe link types. Almost all operating systems use 64, , or ; ancient versions of Windows sometimes used 32, and several obscure systems sometimes resort to odd values such as Consider using traceroute to check that the distance is accurate, then sum up the values.
A handful of userspace tools will generate random TTLs. In these cases, determine maximum initial TTL and then add a - suffix to the value to avoid confusion.
Usually zero for normal IPv4 traffic; always zero for IPv6 due to the limitations of libpcap. Please keep in mind that p0f v3 is a complete rewrite of the original tool, including a brand new database of signatures. We are starting from scratch, so especially for the first few releases, please be sure to submit new signatures and report bugs with special zeal! I am particularly interested in:. To do this, you simply need to attempt establishing a connection to a box running p0f.
The connection does not need to succeed. The current database is minimal, so all contributions are welcome. To collect these signatures, you need to compile the supplied p0f-sendsyn tool, and then use it to initiate a connection to an open port on a remote host; see README for more. HTTP request signatures - especially for older or more exotic browsers e.
MSIE5, mobile devices, gaming consoles , crawlers, command-line tools, and libraries. Why would I want to use it? P0f also gathers netlink and distance information suitable for determining remote network topology, which may serve as a great piece of pre-attack intelligence. Want to know what this guy runs? Does he have a DSL, X. What's Google crawlbot's uptime? Of course, "a successful [software] tool is one that was used to do something undreamed of by its author" ;- 3.
What's new then? The original author still contributed to the code from time to time, and the version you're holding right now is his sole fault - although I'd like William to take over further maintenance, if he's interested.
Version 2 is a complete rewrite of the original v1 code. The main reason for this is to make signatures more flexible, and to implement certain additional checks for very subtle packet characteristics to improve fingerprint accuracy. Other metrics were discussed by certain researchers before, although usually not implemented anywhere.
A detailed discussion of all checks performed by p0f can be found in the introductory comments in p0f. Sadly, this will break all compatibility with v1 signatures, but it's well worth it. Command-line P0f is rather easy to use. You can use this to load custom fingerprint data. Specifying multiple -f values will NOT combine several signature files together.
On some newer systems you might be able to specify 'any' to listen on all devices, but don't rely on this. Specifying multiple -i values will NOT cause p0f to listen on several interfaces at once.
Useful for forensics this will parse tcpdump -w output, for example. You can use Ethereal's text2pcap to convert human-readable packet traces to pcap files, if needed. This option is required for -d and implies -t. This is a method of integrating p0f with active services web server or web scripts, etc. P0f will still continue to report signatures the usual way - but you can use -qKU combination to suppress this. Also see -c notes. NOTE: The socket will be created with permissions corresponding to your current umask.
If you want to restrict access to this interface, use caution. This option is currently Unix-only. This is useful when p0f query is constructed from within a plugin to a program that does not provide source port information this holds true for some mail filters, etc.
Note that some ambiguity is introduced: the response might not refer to the exact connection the plugin is handling, which may seldom cause misidentification of NATed hosts. On some systems particularly on older Suns , the default pcap capture window of 1 ms is insufficient, and p0f may get no packets. In such a case, adjust this parameter to the smallest value that results in reliable operation note that this might introduce some latency to p0f.
The default is , which is sane for a system under a moderate network load. Setting it too high will slow down p0f and may result in some -M false positives for dial-up nodes, dual-boot systems, etc. Setting it too low will result in cache misses for -Q option. To choose the right value, use the number of connections on average per the interval of time you want to cache, then pass it to p0f with -c.
P0f, when run without -q, also reports average packet ratio on exit. You can use this to determine the optimal -c setting. This option has no effect if you do not use -Q nor -M. This is a security feature for the paranoid - when running p0f in daemon mode, you might want to create a new unprivileged user with an empty home directory, and limit the exposure when p0f is compromised.
This option is Unix-only. With this option, p0f logs only source IP and OS data. This option is useful if you don't want p0f to elaborate on OS versions and such combine with -N. Use this option if you want to keep your log file clean and are not interested in hosts that are not recognized. This option is useful when you run p0f recreationally and want to spot UFOs, or in -Q or -M modes when combined with -U to inhibit all output. This setting might decrease performance, depending on your network design and load.
On switched networks, this usually has little or no effect. Note that promiscuous mode on IP-enabled interfaces can be detected remotely, and is sometimes not welcome by network administrators. Requires -o. This option will cause p0f to fingerprint systems you connect to, as opposed to systems that connect to you default.
With this option, p0f will look for p0fa. Feel free to contribute. This option will prompt p0f to fingerprint several different types of traffic, most importantly "connection refused" and "timeout" messages. You may have to familiarize yourself with p0fr. In this mode, p0f will attempt to indiscriminately identify OS on all packets within an already established connection.
The only use of this mode is to perform an immediate fingerprinting of an existing session. Because of the sheer amount of output, you are advised against running p0f in this mode for extended periods of time.
The program will use p0fo. Do not use unless you know what you are doing. NOTE: The p0fo. Do not use except for interactive runs or low traffic situations. Hence, the name may be spoofed - do not rely on it without checking twice. This is an essential option whenever you add new signatures to. This option is Windows-only. The algorithm looks over recent cached hits and looks for indications of multiple systems being behind a single gateway.
This is useful on routers and such to detect policy violations. Note that this mode is somewhat slower due to caching and lookups. Use with caution or do not use at all in modes other than default SYN. This option describes the status of all indicators, not only an overall value. Available on some interfaces, on other, will result in BPF error.
0コメント