telekom-security/tpotce
1
0
Fork 0
mirror of https://github.com/telekom-security/tpotce.git synced 2025-07-02 01:27:27 -04:00
Code Issues Packages Projects Releases Wiki Activity

include docker repos

Browse Source 
... skip emobility since it is a dev repo
This commit is contained in:
Marco Ochse
2017-10-13 18:58:14 +00:00
parent f1ada16414
commit 0d5d80b1e3
152 changed files with 22265 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

498
docker/p0f/docs/COPYING Normal file
View File

@ -0,0 +1,498 @@
GNU LESSER GENERAL PUBLIC LICENSE
Version 2.1, February 1999
Copyright (C) 1991, 1999 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
Licenses are intended to guarantee your freedom to share and change
free software--to make sure the software is free for all its users.
This license, the Lesser General Public License, applies to some
specially designated software packages--typically libraries--of the
Free Software Foundation and other authors who decide to use it. You
can use it too, but we suggest you first think carefully about whether
this license or the ordinary General Public License is the better
strategy to use in any particular case, based on the explanations below.
When we speak of free software, we are referring to freedom of use,
not price. Our General Public Licenses are designed to make sure that
you have the freedom to distribute copies of free software (and charge
for this service if you wish); that you receive source code or can get
it if you want it; that you can change the software and use pieces of
it in new free programs; and that you are informed that you can do
these things.
To protect your rights, we need to make restrictions that forbid
distributors to deny you these rights or to ask you to surrender these
rights. These restrictions translate to certain responsibilities for
you if you distribute copies of the library or if you modify it.
For example, if you distribute copies of the library, whether gratis
or for a fee, you must give the recipients all the rights that we gave
you. You must make sure that they, too, receive or can get the source
code. If you link other code with the library, you must provide
complete object files to the recipients, so that they can relink them
with the library after making changes to the library and recompiling
it. And you must show them these terms so they know their rights.
We protect your rights with a two-step method: (1) we copyright the
library, and (2) we offer you this license, which gives you legal
permission to copy, distribute and/or modify the library.
To protect each distributor, we want to make it very clear that
there is no warranty for the free library. Also, if the library is
modified by someone else and passed on, the recipients should know
that what they have is not the original version, so that the original
author's reputation will not be affected by problems that might be
introduced by others.
Finally, software patents pose a constant threat to the existence of
any free program. We wish to make sure that a company cannot
effectively restrict the users of a free program by obtaining a
restrictive license from a patent holder. Therefore, we insist that
any patent license obtained for a version of the library must be
consistent with the full freedom of use specified in this license.
Most GNU software, including some libraries, is covered by the
ordinary GNU General Public License. This license, the GNU Lesser
General Public License, applies to certain designated libraries, and
is quite different from the ordinary General Public License. We use
this license for certain libraries in order to permit linking those
libraries into non-free programs.
When a program is linked with a library, whether statically or using
a shared library, the combination of the two is legally speaking a
combined work, a derivative of the original library. The ordinary
General Public License therefore permits such linking only if the
entire combination fits its criteria of freedom. The Lesser General
Public License permits more lax criteria for linking other code with
the library.
We call this license the "Lesser" General Public License because it
does Less to protect the user's freedom than the ordinary General
Public License. It also provides other free software developers Less
of an advantage over competing non-free programs. These disadvantages
are the reason we use the ordinary General Public License for many
libraries. However, the Lesser license provides advantages in certain
special circumstances.
For example, on rare occasions, there may be a special need to
encourage the widest possible use of a certain library, so that it becomes
a de-facto standard. To achieve this, non-free programs must be
allowed to use the library. A more frequent case is that a free
library does the same job as widely used non-free libraries. In this
case, there is little to gain by limiting the free library to free
software only, so we use the Lesser General Public License.
In other cases, permission to use a particular library in non-free
programs enables a greater number of people to use a large body of
free software. For example, permission to use the GNU C Library in
non-free programs enables many more people to use the whole GNU
operating system, as well as its variant, the GNU/Linux operating
system.
Although the Lesser General Public License is Less protective of the
users' freedom, it does ensure that the user of a program that is
linked with the Library has the freedom and the wherewithal to run
that program using a modified version of the Library.
The precise terms and conditions for copying, distribution and
modification follow. Pay close attention to the difference between a
"work based on the library" and a "work that uses the library". The
former contains code derived from the library, whereas the latter must
be combined with the library in order to run.
GNU LESSER GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License Agreement applies to any software library or other
program which contains a notice placed by the copyright holder or
other authorized party saying it may be distributed under the terms of
this Lesser General Public License (also called "this License").
Each licensee is addressed as "you".
A "library" means a collection of software functions and/or data
prepared so as to be conveniently linked with application programs
(which use some of those functions and data) to form executables.
The "Library", below, refers to any such software library or work
which has been distributed under these terms. A "work based on the
Library" means either the Library or any derivative work under
copyright law: that is to say, a work containing the Library or a
portion of it, either verbatim or with modifications and/or translated
straightforwardly into another language. (Hereinafter, translation is
included without limitation in the term "modification".)
"Source code" for a work means the preferred form of the work for
making modifications to it. For a library, complete source code means
all the source code for all modules it contains, plus any associated
interface definition files, plus the scripts used to control compilation
and installation of the library.
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running a program using the Library is not restricted, and output from
such a program is covered only if its contents constitute a work based
on the Library (independent of the use of the Library in a tool for
writing it). Whether that is true depends on what the Library does
and what the program that uses the Library does.
1. You may copy and distribute verbatim copies of the Library's
complete source code as you receive it, in any medium, provided that
you conspicuously and appropriately publish on each copy an
appropriate copyright notice and disclaimer of warranty; keep intact
all the notices that refer to this License and to the absence of any
warranty; and distribute a copy of this License along with the
Library.
You may charge a fee for the physical act of transferring a copy,
and you may at your option offer warranty protection in exchange for a
fee.
2. You may modify your copy or copies of the Library or any portion
of it, thus forming a work based on the Library, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) The modified work must itself be a software library.
b) You must cause the files modified to carry prominent notices
stating that you changed the files and the date of any change.
c) You must cause the whole of the work to be licensed at no
charge to all third parties under the terms of this License.
d) If a facility in the modified Library refers to a function or a
table of data to be supplied by an application program that uses
the facility, other than as an argument passed when the facility
is invoked, then you must make a good faith effort to ensure that,
in the event an application does not supply such function or
table, the facility still operates, and performs whatever part of
its purpose remains meaningful.
(For example, a function in a library to compute square roots has
a purpose that is entirely well-defined independent of the
application. Therefore, Subsection 2d requires that any
application-supplied function or table used by this function must
be optional: if the application does not supply it, the square
root function must still compute square roots.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Library,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Library, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote
it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Library.
In addition, mere aggregation of another work not based on the Library
with the Library (or with a work based on the Library) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may opt to apply the terms of the ordinary GNU General Public
License instead of this License to a given copy of the Library. To do
this, you must alter all the notices that refer to this License, so
that they refer to the ordinary GNU General Public License, version 2,
instead of to this License. (If a newer version than version 2 of the
ordinary GNU General Public License has appeared, then you can specify
that version instead if you wish.) Do not make any other change in
these notices.
Once this change is made in a given copy, it is irreversible for
that copy, so the ordinary GNU General Public License applies to all
subsequent copies and derivative works made from that copy.
This option is useful when you wish to copy part of the code of
the Library into a program that is not a library.
4. You may copy and distribute the Library (or a portion or
derivative of it, under Section 2) in object code or executable form
under the terms of Sections 1 and 2 above provided that you accompany
it with the complete corresponding machine-readable source code, which
must be distributed under the terms of Sections 1 and 2 above on a
medium customarily used for software interchange.
If distribution of object code is made by offering access to copy
from a designated place, then offering equivalent access to copy the
source code from the same place satisfies the requirement to
distribute the source code, even though third parties are not
compelled to copy the source along with the object code.
5. A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled or
linked with it, is called a "work that uses the Library". Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.
However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.
When a "work that uses the Library" uses material from a header file
that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not.
Whether this is true is especially significant if the work can be
linked without the Library, or if the work is itself a library. The
threshold for this to be true is not precisely defined by law.
If such an object file uses only numerical parameters, data
structure layouts and accessors, and small macros and small inline
functions (ten lines or less in length), then the use of the object
file is unrestricted, regardless of whether it is legally a derivative
work. (Executables containing this object code plus portions of the
Library will still fall under Section 6.)
Otherwise, if the work is a derivative of the Library, you may
distribute the object code for the work under the terms of Section 6.
Any executables containing that work also fall under Section 6,
whether or not they are linked directly with the Library itself.
6. As an exception to the Sections above, you may also combine or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications.
You must give prominent notice with each copy of the work that the
Library is used in it and that the Library and its use are covered by
this License. You must supply a copy of this License. If the work
during execution displays copyright notices, you must include the
copyright notice for the Library among them, as well as a reference
directing the user to the copy of this License. Also, you must do one
of these things:
a) Accompany the work with the complete corresponding
machine-readable source code for the Library including whatever
changes were used in the work (which must be distributed under
Sections 1 and 2 above); and, if the work is an executable linked
with the Library, with the complete machine-readable "work that
uses the Library", as object code and/or source code, so that the
user can modify the Library and then relink to produce a modified
executable containing the modified Library. (It is understood
that the user who changes the contents of definitions files in the
Library will not necessarily be able to recompile the application
to use the modified definitions.)
b) Use a suitable shared library mechanism for linking with the
Library. A suitable mechanism is one that (1) uses at run time a
copy of the library already present on the user's computer system,
rather than copying library functions into the executable, and (2)
will operate properly with a modified version of the library, if
the user installs one, as long as the modified version is
interface-compatible with the version that the work was made with.
c) Accompany the work with a written offer, valid for at
least three years, to give the same user the materials
specified in Subsection 6a, above, for a charge no more
than the cost of performing this distribution.
d) If distribution of the work is made by offering access to copy
from a designated place, offer equivalent access to copy the above
specified materials from the same place.
e) Verify that the user has already received a copy of these
materials or that you have already sent this user a copy.
For an executable, the required form of the "work that uses the
Library" must include any data and utility programs needed for
reproducing the executable from it. However, as a special exception,
the materials to be distributed need not include anything that is
normally distributed (in either source or binary form) with the major
components (compiler, kernel, and so on) of the operating system on
which the executable runs, unless that component itself accompanies
the executable.
It may happen that this requirement contradicts the license
restrictions of other proprietary libraries that do not normally
accompany the operating system. Such a contradiction means you cannot
use both them and the Library together in an executable that you
distribute.
7. You may place library facilities that are a work based on the
Library side-by-side in a single library together with other library
facilities not covered by this License, and distribute such a combined
library, provided that the separate distribution of the work based on
the Library and of the other library facilities is otherwise
permitted, and provided that you do these two things:
a) Accompany the combined library with a copy of the same work
based on the Library, uncombined with any other library
facilities. This must be distributed under the terms of the
Sections above.
b) Give prominent notice with the combined library of the fact
that part of it is a work based on the Library, and explaining
where to find the accompanying uncombined form of the same work.
8. You may not copy, modify, sublicense, link with, or distribute
the Library except as expressly provided under this License. Any
attempt otherwise to copy, modify, sublicense, link with, or
distribute the Library is void, and will automatically terminate your
rights under this License. However, parties who have received copies,
or rights, from you under this License will not have their licenses
terminated so long as such parties remain in full compliance.
9. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Library or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Library (or any work based on the
Library), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Library or works based on it.
10. Each time you redistribute the Library (or any work based on the
Library), the recipient automatically receives a license from the
original licensor to copy, distribute, link with or modify the Library
subject to these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties with
this License.
11. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Library at all. For example, if a patent
license would not permit royalty-free redistribution of the Library by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Library.
If any portion of this section is held invalid or unenforceable under any
particular circumstance, the balance of the section is intended to apply,
and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
12. If the distribution and/or use of the Library is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Library under this License may add
an explicit geographical distribution limitation excluding those countries,
so that distribution is permitted only in or among countries not thus
excluded. In such case, this License incorporates the limitation as if
written in the body of this License.
13. The Free Software Foundation may publish revised and/or new
versions of the Lesser General Public License from time to time.
Such new versions will be similar in spirit to the present version,
but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Library
specifies a version number of this License which applies to it and
"any later version", you have the option of following the terms and
conditions either of that version or of any later version published by
the Free Software Foundation. If the Library does not specify a
license version number, you may choose any version ever published by
the Free Software Foundation.
14. If you wish to incorporate parts of the Library into other free
programs whose distribution conditions are incompatible with these,
write to the author to ask for permission. For software which is
copyrighted by the Free Software Foundation, write to the Free
Software Foundation; we sometimes make exceptions for this. Our
decision will be guided by the two goals of preserving the free status
of all derivatives of our free software and of promoting the sharing
and reuse of software generally.
NO WARRANTY
15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY
KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME
THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY
AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU
FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF
SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Libraries
If you develop a new library, and you want it to be of the greatest
possible use to the public, we recommend making it free software that
everyone can redistribute and change. You can do so by permitting
redistribution under these terms (or, alternatively, under the terms of the
ordinary General Public License).
To apply these terms, attach the following notices to the library. It is
safest to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least the
"copyright" line and a pointer to where the full notice is found.
<one line to give the library's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Also add information on how to contact you by electronic and paper mail.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the library, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the
library `Frob' (a library for tweaking knobs) written by James Random Hacker.
<signature of Ty Coon>, 1 April 1990
Ty Coon, President of Vice

128
docker/p0f/docs/ChangeLog Normal file
View File

@ -0,0 +1,128 @@
Version 3.09b:
--------------
- Fixed a likely only cosmetic bug with a one-byte overread of the pcap
packet buffer, which would cause an error under ASAN. Spotted by
Xavid Pretzer.
- Added a new signature for Chrome.
- Updated another signature for Chrome.
Version 3.08b:
--------------
- An awful fix for a packet loss bug (probably kernel or libpcap-related)
with some VMs.
- Improvement to avoid warnings with -r.
Version 3.07b:
--------------
Bug fixes:
- Improvement to API handling to avoid FATAL() on short API reads & writes.
- Minor bug fix to IP parsing in one of the companion utilities.
Improvements:
- New signatures.
Version 3.06b:
--------------
Bug fixes:
- Made os_match_q actually functional in api.c (thanks to Anthony Howe).
- Fixed api.c struct packing issue (thanks to Tomoyuki Murakami).
- Improved logic around the vlan behavior (thanks to Anthony Howe).
Version 3.05b:
--------------
Bug fixes:
- Cleaned up hash.h to avoid pointless OOB reads, alignment issues.
- Fixed divide-by-zero in MSS calculations
Version 3.04b:
--------------
Bug fixes:
- Fixed a realloc bug (not normally triggered in p0f)
Version 3.03b:
--------------
Bug fixes:
- Potential NULL ptr in p0f-client on some 64-bit systems.
Version 3.02b:
--------------
Bug fixes:
- Cygwin compile issue fixed.
Improvements:
- New signatures.
Version 3.01b (2012-01-17):
---------------------------
Bug fixes:
- 'Date' comparisons for server sigs now work as expected.
- Bad TS reading now allowed on initial SYN (improves uptime detection).
Improvements:
- New signatures.
- Solaris support (in theory).
Version 3.00b (2012-01-17):
---------------------------
Bug fixes:
- Alignment-related SIGBUS non-x86 fixed.
- Cache expiration algorithm now works as expected.
- p0f -L no longer leads to NULL ptr when no interfaces visible.
- Greppable output format no longer mixes up cli and srv fields.
- Added '|' to banned characters in reported header values.
Improvements:
- Multiple new HTTP and TCP signatures.
- Improved MSS/MTU matching to account for peer MTU.
- New HTTP fingerprinting logic with optional headers (? prefix).
- Memory leak detection added (but nothing found).
- API now indicates the value of 'generic' / 'fuzzy' fields and several
other parameters.
- General style improvements.
- Delay added to p0f-sendsyn to aid with packet ordering.
Version 3.00-rc0 (2012-01-10):
------------------------------
- Initial public release, complete rewrite.

916
docker/p0f/docs/README Normal file
View File

@ -0,0 +1,916 @@
=============================
p0f v3: passive fingerprinter
=============================
http://lcamtuf.coredump.cx/p0f3.shtml
Copyright (C) 2012 by Michal Zalewski <lcamtuf@coredump.cx>
---------------
1. 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:
.-[ 1.2.3.4/1524 -> 4.3.2.1/80 (syn) ]-
|
| client = 1.2.3.4
| os = Windows XP
| dist = 8
| params = none
| raw_sig = 4:120+8:0:1452:65535,0:mss,nop,nop,sok:df,id+:0
|
`----
.-[ 1.2.3.4/1524 -> 4.3.2.1/80 (syn+ack) ]-
|
| server = 4.3.2.1
| os = Linux 3.x
| dist = 0
| params = none
| raw_sig = 4:64+0:0:1460:mss*10,0:mss,nop,nop,sok:df:0
|
`----
.-[ 1.2.3.4/1524 -> 4.3.2.1/80 (mtu) ]-
|
| client = 1.2.3.4
| link = DSL
| raw_mtu = 1492
|
`----
.-[ 1.2.3.4/1524 -> 4.3.2.1/80 (uptime) ]-
|
| client = 1.2.3.4
| uptime = 0 days 11 hrs 16 min (modulo 198 days)
| raw_freq = 250.00 Hz
|
`----
A live demonstration can be seen here:
http://lcamtuf.coredump.cx/p0f3/
--------------------
2. 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.
-------------------------------
3. 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):
-j - Log in JSON format.
-l - Line buffered mode for logging to output file.
-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 cache in under 5 seconds;
consequently, the 'c' variable can be much lower than the real
number of parallel connections happening on the wire.
-t c,h - sets the timeout for collecting signatures for any connection
(c); and for purging idle hosts from in-memory cache (h). The
first parameter is given in seconds, and defaults to 30 s; the
second one is in minutes, and defaults to 120 min.
The first value must be just high enough to reliably capture
SYN, SYN+ACK, and the initial few kB of traffic. 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 5-10 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:
# ./p0f -i eth0
# ./p0f -i eth0 -d -u p0f-user -o /var/log/p0f.log
# ./p0f -r some_capture.cap
The greppable log format (-o) uses pipe ('|') as a delimiter, with name=value
pairs describing the signature in a manner very similar to the pretty-printed
output generated on stdout:
[2012/01/04 10:26:14] mod=mtu|cli=1.2.3.4/1234|srv=4.3.2.1/80|subj=cli|link=DSL|raw_mtu=1492
The 'mod' parameter identifies the subsystem that generated the entry; the
'cli' and 'srv' parameters always describe the direction in which the TCP
session is established; and 'subj' describes which of these two parties is
actually being fingerprinted.
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 10.0.0.0/8 and port 80'
'not src host 10.1.2.3'
'port 22 or port 443'
You can read more about the supported syntax by doing 'man pcap-fiter'; if
that fails, try this URL:
http://www.manpagez.com/man/7/pcap-filter/
Filters work both for online capture (-i) and for previously collected data
produced by any other tool (-r).
-------------
4. 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.
Clients are welcome to connect to the unix socket specified with -s using the
SOCK_STREAM protocol, and may issue any number of fixed-length queries. 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 (0x50304601), in native endian of the platform.
- Address type byte: 4 for IPv4, 6 for IPv6.
- 16 bytes of address data, network endian. IPv4 addresses should be
aligned to the left.
To such a query, p0f responds with:
- Another magic dword (0x50304602), native endian.
- Status dword: 0x00 for 'bad query', 0x10 for 'OK', and 0x20 for 'no match'.
- Host information, valid only if status is 'OK' (byte width in square
brackets):
[4] first_seen - unix time (seconds) of first observation of the host.
[4] last_seen - unix time (seconds) of most recent traffic.
[4] total_conn - total number of connections seen.
[4] uptime_min - calculated system uptime, in minutes. Zero if not known.
[4] up_mod_days - uptime wrap-around interval, in days.
[4] last_nat - time of the most recent detection of IP sharing (NAT,
load balancing, proxying). Zero if never detected.
[4] last_chg - time of the most recent individual OS mismatch (e.g.,
due to multiboot or IP reuse).
[2] distance - system distance (derived from TTL; -1 if no data).
[1] bad_sw - p0f thinks the User-Agent or Server strings aren't
accurate. The value of 1 means OS difference (possibly
due to proxying), while 2 means an outright mismatch.
NOTE: If User-Agent is not present at all, this value
stays at 0.
[1] os_match_q - OS match quality: 0 for a normal match; 1 for fuzzy
(e.g., TTL or DF difference); 2 for a generic signature;
and 3 for both.
[32] os_name - NUL-terminated name of the most recent positively matched
OS. If OS not known, os_name[0] is NUL.
NOTE: If the host is first seen using an known system and
then switches to an unknown one, this field is not
reset.
[32] os_flavor - OS version. May be empty if no data.
[32] http_name - most recent positively identified HTTP application
(e.g. 'Firefox').
[32] http_flavor - version of the HTTP application, if any.
[32] link_type - network link type, if recognized.
[32] language - system language, if recognized.
A simple reference implementation of an API client is provided in p0f-client.c.
Implementations in C / C++ may reuse api.h from p0f source code, too.
Developers using the API should be aware of several important constraints:
- The maximum number of simultaneous API connections is capped to 20. 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.
- The maximum number of hosts and connections tracked at any given time is
subject to configurable limits. 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.
- Cache entries with no activity for more than 120 minutes will be dropped
even if the cache is nearly empty. 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.
-----------------------
5. Fingerprint database
-----------------------
Whenever p0f obtains a fingerprint from the observed traffic, it defers to
the data read from p0f.fp to identify the operating system and obtain some
ancillary data needed for other analysis tasks. The fingerprint database is a
simple text file where lines starting with ; are ignored.
== Module specification ==
The file is split into sections based on the type of traffic the fingerprints
apply to. Section identifiers are enclosed in square brackets, like so:
[module:direction]
module - the name of the fingerprinting module (e.g. 'tcp' or 'http').
direction - the direction of fingerprinted traffic: 'request' (from client to
server) or 'response' (from server to client).
For the TCP module, 'client' matches the initial SYN; and
'server' matches SYN+ACK.
The 'direction' part is omitted for MTU signatures, as they work equally well
both ways.
== Signature groups ==
The actual signatures must be preceeded by an 'label' line, describing the
fingerprinted software:
label = type:class:name:flavor
type - some signatures in p0f.fp offer broad, last-resort matching for
less researched corner cases. 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.
class - the tool needs to distinguish between OS-identifying signatures
(only one of which should be matched for any given host) and
signatures that just identify user applications (many of which
may be seen concurrently).
To assist with this, OS-specific signatures should specify the
OS architecture family here (e.g., 'win', 'unix', 'cisco'); while
application-related sigs (NMap, MSIE, Apache) should use a
special value of '!'.
Most TCP signatures are OS-specific, and should have OS family
defined. Other signatures, such as HTTP, should use '!' unless
the fingerprinted component is deeply intertwined with the
platform (e.g., Windows Update).
NOTE: To avoid variations (e.g. 'win' and 'windows' or 'unix'
and 'linux'), all classes need to be pre-registered using a
'classes' directive, seen near the beginning of p0f.fp.
name - a human-readable short name for what the fingerprint actually
helps identify - say, 'Linux', 'Sendmail', or 'NMap'. The tool
doesn't care about the exact value, but requires consistency - so
don't switch between 'Internet Explorer' and 'MSIE', or 'MacOS'
and 'Mac OS'.
flavor - anything you want to say to further qualify the observation. Can
be the version of the identified software, or a description of
what the application seems to be doing (e.g. 'SYN scan' for NMap).
NOTE: Don't be too specific: if you have a signature for Apache
2.2.16, but have no reason to suspect that other recent versions
behave in a radically different way, just say '2.x'.
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 '!') should be followed by a comma-delimited list of OS
names or @-prefixed OS architecture classes on which this software is known to
be used on. For example:
label = s:!:Uncle John's Networked ls Utility:2.3.0.1
sys = Linux,FreeBSD,OpenBSD
...or:
label = s:!:Mom's Homestyle Browser:1.x
sys = @unix,@win
The label can be followed by any number of module-specific signatures; all of
them will be linked to the most recent label, and will be reported the same
way.
All sections except for 'name' are omitted for [mtu] signatures, which do not
convey any OS-specific information, and just describe link types.
== MTU signatures ==
Many operating systems derive the maximum segment size specified in TCP options
from the MTU of their network interface; that value, in turn, normally depends
on the design of the link-layer protocol. A different MTU is associated with
PPPoE, a different one with IPSec, and a different one with Juniper VPN.
The format of the signatures in the [mtu] section is exceedingly simple,
consisting just of a description and a list of values:
label = Ethernet
sig = 1500
These will be matched for any wildcard MSS TCP packets (see below) not generated
by userspace TCP tools.
== TCP signatures ==
For TCP traffic, signature layout is as follows:
sig = ver:ittl:olen:mss:wsize,scale:olayout:quirks:pclass
ver - signature for IPv4 ('4'), IPv6 ('6'), or both ('*').
NEW SIGNATURES: P0f documents the protocol observed on the wire,
but you should replace it with '*' unless you have observed some
actual differences between IPv4 and IPv6 traffic, or unless the
software supports only one of these versions to begin with.
ittl - initial TTL used by the OS. Almost all operating systems use
64, 128, or 255; ancient versions of Windows sometimes used
32, and several obscure systems sometimes resort to odd values
such as 60.
NEW SIGNATURES: P0f will usually suggest something, using the
format of 'observed_ttl+distance' (e.g. 54+10). Consider using
traceroute to check that the distance is accurate, then sum up
the values. If initial TTL can't be guessed, p0f will output
'nnn+?', and you need to use traceroute to estimate the '?'.
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.
olen - length of IPv4 options or IPv6 extension headers. Usually zero
for normal IPv4 traffic; always zero for IPv6 due to the
limitations of libpcap.
NEW SIGNATURES: Copy p0f output literally.
mss - maximum segment size, if specified in TCP options. Special value
of '*' can be used to denote that MSS varies depending on the
parameters of sender's network link, and should not be a part of
the signature. In this case, MSS will be used to guess the
type of network hookup according to the [mtu] rules.
NEW SIGNATURES: Use '*' for any commodity OSes where MSS is
around 1300 - 1500, unless you know for sure that it's fixed.
If the value is outside that range, you can probably copy it
literally.
wsize - window size. Can be expressed as a fixed value, but many
operating systems set it to a multiple of MSS or MTU, or a
multiple of some random integer. P0f automatically detects these
cases, and allows notation such as 'mss*4', 'mtu*4', or '%8192'
to be used. Wilcard ('*') is possible too.
NEW SIGNATURES: Copy p0f output literally. If frequent variations
are seen, look for obvious patterns. If there are no patterns,
'*' is a possible alternative.
scale - window scaling factor, if specified in TCP options. Fixed value
or '*'.
NEW SIGNATURES: Copy literally, unless the value varies randomly.
Many systems alter between 2 or 3 scaling factors, in which case,
it's better to have several 'sig' lines, rather than a wildcard.
olayout - comma-delimited layout and ordering of TCP options, if any. This
is one of the most valuable TCP fingerprinting signals. Supported
values:
eol+n - explicit end of options, followed by n bytes of padding
nop - no-op option
mss - maximum segment size
ws - window scaling
sok - selective ACK permitted
sack - selective ACK (should not be seen)
ts - timestamp
?n - unknown option ID n
NEW SIGNATURES: Copy this string literally.
quirks - comma-delimited properties and quirks observed in IP or TCP
headers:
df - "don't fragment" set (probably PMTUD); ignored for IPv6
id+ - DF set but IPID non-zero; ignored for IPv6
id- - DF not set but IPID is zero; ignored for IPv6
ecn - explicit congestion notification support
0+ - "must be zero" field not zero; ignored for IPv6
flow - non-zero IPv6 flow ID; ignored for IPv4
seq- - sequence number is zero
ack+ - ACK number is non-zero, but ACK flag not set
ack- - ACK number is zero, but ACK flag set
uptr+ - URG pointer is non-zero, but URG flag not set
urgf+ - URG flag used
pushf+ - PUSH flag used
ts1- - own timestamp specified as zero
ts2+ - non-zero peer timestamp on initial SYN
opt+ - trailing non-zero data in options segment
exws - excessive window scaling factor (> 14)
bad - malformed TCP options
If a signature scoped to both IPv4 and IPv6 contains quirks valid
for just one of these protocols, such quirks will be ignored for
on packets using the other protocol. For example, any combination
of 'df', 'id+', and 'id-' is always matched by any IPv6 packet.
NEW SIGNATURES: Copy literally.
pclass - payload size classification: '0' for zero, '+' for non-zero,
'*' for any. The packets we fingerprint right now normally have
no payloads, but some corner cases exist.
NEW SIGNATURES: Copy literally.
NOTE: The TCP module allows some fuzziness when an exact match can't be found:
'df' and 'id+' quirks are allowed to disappear; 'id-' or 'ecn' may appear; and
TTLs can change.
To gather new SYN ('request') signatures, simply connect to the fingerprinted
system, and p0f will provide you with the necessary data. To gather SYN+ACK
('response') signatures, you should use the bundled p0f-sendsyn utility while p0f
is running in the background; creating them manually is not advisable.
== HTTP signatures ==
A special directive should appear at the beginning of the [http:request]
section, structured the following way:
ua_os = Linux,Windows,iOS=[iPad],iOS=[iPhone],Mac OS X,...
This list should specify OS names that should be looked for within the
User-Agent string if the string is otherwise deemed to be honest. This input
is not used for fingerprinting, but aids NAT detection in some useful ways.
The names have to match the names used in 'sig' specifiers across p0f.fp. If a
particular name used by p0f differs from what typically appears in User-Agent,
the name=[string] syntax may be used to define any number of aliases.
Other than that, HTTP signatures for GET and HEAD requests have the following
layout:
sig = ver:horder:habsent:expsw
ver - 0 for HTTP/1.0, 1 for HTTP/1.1, or '*' for any.
NEW SIGNATURES: Copy the value literally, unless you have a
specific reason to do otherwise.
horder - comma-separated, ordered list of headers that should appear in
matching traffic. Substrings to match within each of these
headers may be specified using a name=[value] notation.
The signature will be matched even if other headers appear in
between, as long as the list itself is matched in the specified
sequence.
Headers that usually do appear in the traffic, but may go away
(e.g. Accept-Language if the user has no languages defined, or
Referer if no referring site exists) should be prefixed with '?',
e.g. "?Referer". P0f will accept their disappearance, but will
not allow them to appear at any other location.
NEW SIGNATURES: Review the list and remove any headers that
appear to be irrelevant to the fingerprinted software, and mark
transient ones with '?'. Remove header values that do not add
anything to the signature, or are request- or user-specific.
In particular, pay attention to Accept, Accept-Language, and
Accept-Charset, as they are highly specific to request type
and user settings.
P0f automatically removes some headers, prefixes others with '?',
and inhibits the value of fields such as 'Referer' or 'Cookie' -
but this is not a substitute for manual review.
NOTE: Server signatures may differ depending on the request
(HTTP/1.1 versus 1.0, keep-alive versus one-shot, etc) and on the
returned resource (e.g., CGI versus static content). Play around,
browse to several URLs, also try curl and wget.
habsent - comma-separated list of headers that must *not* appear in
matching traffic. This is particularly useful for noting the
absence of standard headers (e.g. 'Host'), or for differentiating
between otherwise very similar signatures.
NEW SIGNATURES: P0f will automatically highlight the absence of
any normally present headers; other entries may be added where
necessary.
expsw - expected substring in 'User-Agent' or 'Server'. This is not
used to match traffic, and merely serves to detect dishonest
software. If you want to explicitly match User-Agent, you need
to do this in the 'horder' section, e.g.:
User-Agent=[Firefox]
Any of these sections sections except for 'ver' may be blank.
There are many protocol-level quirks that p0f could be detecting - for example,
the use of non-standard newlines, or missing or extra spacing between header
field names and values. There is also some information to be gathered from
responses to OPTIONS or POST. That said, it does not seem to be worth the
effort: the protocol is so verbose, and implemented so arbitrarily, that we are
getting more than enough information just with a simple GET / HEAD fingerprint.
== SMTP signatures ==
*** NOT IMPLEMENTED YET ***
== FTP signatures ==
*** NOT IMPLEMENTED YET ***
----------------
6. NAT detection
----------------
In addition to fairly straightforward measurements of intrinsic properties of
a single TCP session, p0f also tries to compare signatures across sessions to
detect client-side connection sharing (NAT, HTTP proxies) or server-side load
balancing.
This is done in two steps: the first significant deviation usually prompts a
"host change" entry (which may be also indicative of multi-boot, address reuse,
or other one-off events); and a persistent pattern of changes prompts an
"ip sharing" notification later on.
All of these messages are accompanied by a set of reason codes:
os_sig - the OS detected right now doesn't match the OS detected earlier
on.
sig_diff - no definite OS detection data available, but protocol-level
characteristics have changed drastically (e.g., different
TCP option layout).
app_vs_os - the application detected running on the host is not supposed
to work on the host's operating system.
x_known - the signature progressed from known to unknown, or vice versa.
The following additional codes are specific to TCP:
tstamp - TCP timestamps went back or jumped forward.
ttl - TTL values have changed.
port - source port number has decreased.
mtu - system MTU has changed.
fuzzy - the precision with which a TCP signature is matched has
changed.
The following code is also issued by the HTTP module:
via - data explicitly includes Via / X-Forwarded-For.
us_vs_os - OS fingerprint doesn't match User-Agent data, and the
User-Agent value otherwise looks honest.
app_srv_lb - server application signatures change, suggesting load
balancing.
date - server-advertised date changes inconsistently.
Different reasons have different weights, balanced to keep p0f very sensitive
even to very homogenous environments behind NAT. If you end up seeing false
positives or other detection problems in your environment, please let me know!
-----------
7. Security
-----------
You should treat the output from this tool as advisory; the fingerprinting can
be gambled with some minor effort, and it's also possible to evade it altogether
(e.g. with excessive IP fragmentation or bad TCP checksums). Plan accordingly.
P0f should to be reasonably secure to operate as a daemon. That said, un*x
users should employ the -u option to drop privileges and chroot() when running
the tool continuously. This greatly minimizes the consequences of any mishaps -
and mishaps in C just tend to happen.
To make this step meaningful, the user you are running p0f as should be
completely unprivileged, and should have an empty, read-only home directory. For
example, you can do:
# useradd -d /var/empty/p0f -M -r -s /bin/nologin p0f-user
# mkdir -p -m 755 /var/empty/p0f
Please don't put the p0f binary itself, or any other valuable assets, inside
that user's home directory; and certainly do not use any generic locations such
as / or /bin/ in lieu of a proper home.
P0f running in the background should be fairly difficult to DoS, especially
compared to any real TCP services it will be watching. Nevertheless, there are
so many deployment-specific factors at play that you should always preemptively
stress-test your setup, and see how it behaves.
Other than that, let's talk filesystem security. When using the tool in the
API mode (-s), the listening socket is always re-created created with 666
permissions, so that applications running as other uids can query it at will.
If you want to preserve the privacy of captured traffic in a multi-user system,
please ensure that the socket is created in a directory with finer-grained
permissions; or change API_MODE in config.h.
The default file mode for binary log data (-o) is 600, on the account that
others probably don't need access to historical data; if you need to share logs,
you can pre-create the file or change LOG_MODE in config.h.
Don't build p0f, and do not store its source, binary, configuration files, logs,
or query sockets in world-writable locations such as /tmp (or any
subdirectories created therein).
Last but not least, please do not attempt to make p0f setuid, or otherwise
grant it privileges higher than these of the calling user. Neither the tool
itself, nor the third-party components it depends on, are designed to keep rogue
less-privileged callers at bay. If you use /etc/sudoers to list p0f as the only
program that user X should be able to run as root, that user will probably be
able to compromise your system. The same goes for many other uses of sudo, by
the way.
--------------
8. Limitations
--------------
Here are some of the known issues you may run into:
== General ==
1) RST, ACK, and other experimental fingerprinting modes offered in p0f v2 are
no longer supported in v3. This is because they proved to have very low
specificity. The consequence is that you can no longer fingerprint
"connection refused" responses.
2) API queries or daemon execution are not supported when reading offline pcaps.
While there may be some fringe use cases for that, offline pcaps use a
much simpler event loop, and so supporting these features would require some
extra effort.
3) P0f needs to observe at least about 25 milliseconds worth of qualifying
traffic to estimate system uptime. This means that if you're testing it over
loopback or LAN, you may need to let it see more than one connection.
Systems with extremely slow timestamp clocks may need longer acquisition
periods (up to several seconds); very fast clocks (over 1.5 kHz) are rejected
completely on account of being prohibited by the RFC. Almost all OSes are
between 100 Hz and 1 kHz, which should work fine.
4) Some systems vary SYN+ACK responses based on the contents of the initial SYN,
sometimes removing TCP options not supported by the other endpoint.
Unfortunately, there is no easy way to account for this, so several SYN+ACK
signatures may be required per system. The bundled p0f-sendsyn utility helps
with collecting them.
Another consequence of this is that you will sometimes see server uptime only
if your own system has RFC1323 timestamps enabled. Linux does that since
version 2.2; on Windows, you need version 7 or newer. Client uptimes are not
affected.
== Windows port ==
1) API sockets do not work on Windows. This is due to a limitation of winpcap;
see live_event_loop(...) in p0f.c for more info.
2) The chroot() jail (-u) on Windows doesn't offer any real security. This is
due to the limitations of cygwin.
3) The p0f-sendsyn utility doesn't work because of the limited capabilities of
Windows raw sockets (this should be relatively easy to fix if there are any
users who care).
---------------------------
9. Acknowledgments and more
---------------------------
P0f is made possible thanks to the contributions of several good souls,
including:
Phil Ames
Jannich Brendle
Matthew Dempsky
Jason DePriest
Dalibor Dukic
Mark Martinec
Damien Miller
Josh Newton
Nibbler
Bernhard Rabe
Chris John Riley
Sebastian Roschke
Peter Valchev
Jeff Weisberg
Anthony Howe
Tomoyuki Murakami
Michael Petch
If you wish to help, the most immediate way to do so is to simply gather new
signatures, especially from less popular or older platforms (servers, networking
equipment, portable / embedded / specialty OSes, etc).
Problems? Suggestions? Complaints? Compliments? You can reach the author at
<lcamtuf@coredump.cx>. The author is very lonely and appreciates your mail.

26
docker/p0f/docs/TODO Normal file
View File

@ -0,0 +1,26 @@
Signatures:
- More SYN sigs,
- A lot more SYN+ACK signatures,
- A lot more server signatures - maybe write a tool.
Modules:
- SMTP
- FTP
- POP3
- IMAP
- SSH
- SSL
Misc:
- Manpage.

29
docker/p0f/docs/existential-notes.txt Normal file
View File

@ -0,0 +1,29 @@
-----------------------------
Some random food for thought:
-----------------------------
1) If you run p0f on any reasonably popular server, you will probably see quite
a few systems that seem to be leaking memory in TCP headers (e.g. ACK number
or second timestamp set on SYN packets, URG pointer without URG flag, etc).
You will also see HTTP traffic with non-stripped Proxy-Authorization headers
and other hilarious abnormalities.
Unfortunately, pinpointing the sources of many of these leaks is pretty hard;
they often trace to proprietary corporate proxies and firewalls, and unless
it's *your* proxy or firewall, you won't be finding out more. If you wish to
put some investigative effort into this, there are quite a few bugs waiting
to be tracked down, though :-)
2) After some hesitation, I decided *against* the inclusion of encrypted traffic
classification features into p0f. Timing, packet size, and direction
information lets you, for example, reliably differentiate between interactive
SSH sessions and SFTP uploads or downloads; automated and human password
entry attemps; or failed and successful auth.
The same goes for SSL: you can tell normal HTTPS browsing from file uploads,
from attempts to smuggle, say, PPP over SSL. In the end, however, it seems
like stretch to cram it into p0f; one day, I might improve my ancient 'fl0p'
tool, instead:
http://lcamtuf.coredump.cx/soft/fl0p-devel.tgz

73
docker/p0f/docs/extra-sigs.txt Normal file
View File

@ -0,0 +1,73 @@
These need to be investigated:
# AVM FritzBox 7112 w/ BusyBox Linux - sendsyn response
4:64+0:0:1460:mss*4,0:mss:df:0
4:64+0:0:1460:mss*4,1:mss,nop,ws:df:0
4:64+0:0:1460:mss*4,1:mss,nop,nop,sok,nop,ws:df:0
4:64+0:0:1460:mss*4,1:mss,sok,ts,nop,ws:df:0
4:64+0:0:1460:mss*4,1:mss,nop,nop,ts,nop,ws:df:0
4:64+0:0:1460:mss*4,0:mss,nop,nop,sok:df:0
4:64+0:0:1460:mss*4,0:mss,sok,ts:df:0
4:64+0:0:1460:mss*4,0:mss,nop,nop,ts:df:0
# LaCIE Network storage - sendsyn response
4:64+0:0:1460:mss*4,0:mss,nop,nop,sok:df:0
4:64+0:0:1460:mss*4,0:mss,sok,ts:df:0
4:64+0:0:1460:mss*4,0:mss,nop,nop,ts:df:0
# HP LaserJet printer CP1515 - sendsyn response
4:64+0:0:*:mss*7,0:mss,nop,nop,sok::0
4:64+0:0:*:mss*7,0:mss,nop,nop,sok,nop,nop,ts::0
4:64+0:0:*:mss*7,0:mss,nop,nop,ts::0
# HP LaserJet printer CP1515 - http response
1:Server,Transfer-Encoding=[chunked],Content-Type,?Expires,?Cache-Control:Connection,Keep-Alive,Accept-Ranges,Date:Virata-EmWeb/R6_2_1
1:Server,?Content-Length,Content-Type,?ETag,?Last-Modified,?Cache-Control:Connection,Keep-Alive,Accept-Ranges,Date:Virata-EmWeb/R6_2_1
1:Server,Transfer-Encoding=[chunked],Content-Type,?Expires,?Cache-Control:Connection,Keep-Alive,Accept-Ranges,Date:Virata-EmWeb/R6_2_1
Cherokee 1.0.8-5:
1:Connection=[Keep-Alive],Keep-Alive=[timeout=15],Date,Server,?Content-Length,Content-Type,?Cache-Control,?Pragma:Accept-Ranges:Cherokee/1.0.8 (Debian GNU/Linux)
AOLserver 4.5.1-12:
1:MIME-Version=[1.0],Date,Server,Content-Type,?Content-Length,Connection=[close]:Keep-Alive,Accept-Ranges:AOLserver/4.5.1
BOA 0.94.14rc21-3.1:
1:Date,Server,Accept-Ranges=[bytes],Connection=[close],Content-Type:Keep-Alive:Boa/0.94.14rc21
Yaws 1.88-2:
1:Connection=[close],Server,Date,?Content-Length,Content-Type:Keep-Alive,Accept-Ranges:Yaws/1.88 Yet Another Web Server
Ocsigen 1.3.3-1squeeze1:
1:accept-ranges=[none],cache-control=[no-cache],content-type=[text/html; charset=iso-8859-1],date=[Wed, 18 Jan 2012 09:32:55 GMT],expires=[0],server=[Ocsigen],transfer-encoding=[chunked]:Content-Type,Connection,Keep-Alive,Accept-Ranges,Date:
dhttpd 1.02a-18:
0:Date,Server,Content-type=[text/html]:Content-Type,Connection,Keep-Alive,Accept-Ranges:dhttpd/1.02a
thttpd 2.25b-11:
1:Server,Content-Type,Date,?Last-Modified,Accept-Ranges=[bytes],Connection=[close]:Keep-Alive:thttpd/2.25b 29dec2003
------------
uhttpd version 7 (running on OpenWrt):
0::Content-Type,Connection,Keep-Alive,Accept-Ranges,Date:
Cherokee 1.0.8-5:
0:Connection=[close],Date,Server,Content-Type:Keep-Alive,Accept-Ranges:Cherokee/1.0.8 (Debian GNU/Linux)
AOLserver 4.5.1-12:
0:MIME-Version=[1.0],Date,Server,Content-Type,?Content-Length,Connection=[close]:Keep-Alive,Accept-Ranges:AOLserver/4.5.1
BOA 0.94.14rc21-3.1:
0:Date,Server,Accept-Ranges=[bytes],Connection=[close],?Last-Modified,Content-Type:Keep-Alive:Boa/0.94.14rc21
Ocsigen 1.3.3-1squeeze1:
1:accept-ranges=[none],cache-control=[no-cache],content-type=[text/html; charset=iso-8859-1],date=[Tue, 17 Jan 2012 22:46:08 GMT],expires=[0],server=[Ocsigen]:Content-Type,Connection,Keep-Alive,Accept-Ranges,Date:
dhttpd 1.02a-18:
0:Date,Server,Content-type=[text/html]:Content-Type,Connection,Keep-Alive,Accept-Ranges:dhttpd/1.02a
Yaws 1.88-2:
1:Connection=[Keep-Alive],Server,Date,?Last-Modified,Etag=["2nu+xcAAGwK"],?Content-Length,Content-Type:Keep-Alive,Accept-Ranges:Yaws/1.88 Yet Another Web Server
thttpd 2.25b-11:
0:Server,Content-Type,Date,?Last-Modified,Accept-Ranges=[bytes],Connection=[close]:Keep-Alive:thttpd/2.25b 29dec2003