Mark Martinec wrote:
Daryl C. W. O'Shea,
BTW... has anyone ever got the -Q option to have p0f itself listen on a
socket to work, instead of using their own wrapper?
The core problem is that p0f needs the full TCP session specification
in a query: client and server IP address, as well as client and server TCP
port number. Most of these is know or can be guessed, except for the
client TCP port number.
Yeah, I know. I've been doing tcp fingerprinting of smtp traffic for
about 4 years, using p0f for it for about 2 years. I just have never
been able to get the built in cache mechanism of p0f to work when
supplied with all the necessary session info (which is trivial to get
from Sendmail, but that really doesn't have anything to do with "p0f -Q
socket" never having data about the requested session).
There have been requests to let Postfix provide this information to
a policy daemon or via XFORWARD protocol extension, but the change
has deep consequence (extensibility path - why this and not that info),
so it has not yet been implemented.
Well, that's Postfix. It seems that workarounds to do what you can
trivially do with Sendmail are abundant with Postfix.
Lack of source TCP port number information is the sole reason for
existance of p0f-analyzer.pl: it can supply the information without
knowing the client-side TCP port number, based on assumption that
in recent past only one or few hosts have been connecting from
the given IP address.
Yeah, but I have the session info, p0f -Q socket just seems to be broken. :)
Daryl
