OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Re: feature req: more info on TCP session for content filter and/or policy delegation server

From: Mark Martinec (Mark.Martinec+postfixijs.si)
Date: Mon Jan 03 2005 - 08:36:28 CST


Wietse,

> > The source port number (i.e. the whole TCP quadruple) is needed to be
> > able to distinguish between boxes behind NAT, e.g. when they are
> > firewalled.
>
> NAT is not a firewalling technique. Without a proper firewall on
> top of NAT, is is possible to break into systems behind NAT boxes.

I wasn't clear enough and you missed my point. I'll explain.

> > > Neither source port nor destination port are relevant for
> > > client fingerprinting.

That is only true when the service that has accepted the TCP session
(e.g. smtpd Postfix service) is the one that is also doing the
passive fingerprinting. It is undesirable to clutter smtpd with
such extensions, which more naturally belong to some external
process and/or policy daemon.

If an external component (e.g. p0f daemon) is gathering such intelligence,
there must be a way to correlate the SMTP sessions in smtpd with
external database of information on current and recent TCP sessions.

The information that uniquely identifies a TCP session is a quadruple
(IP address + port on the source and destination end). A policy daemon
needs to provide this quadruple in a query to p0f in order to obtain
the corresponding information. This is why a policy delegation protocol
needs to pass this information from smtpd to a policy daemon which
in turn can then query a p0f daemon.

One might argue that the remote host at some IP address will provide
the same signature, regardless of the source TCP port it uses.
This is only true when NAT is not being used at the remote end.
In general case where multiple hosts may be lurking behind some
IP address, the source TCP port number is needed to distinguish
between TCP sessions.
(this is what I was trying to say in my previous short mail).

(a modification of p0f to do a wildcard search on source port number
is also not practical, as it would require a change in its query
protocol and a change in its internal data representation along with
a replacement of a quick lookup by a search algorithm)

  Mark