[pf4freebsd] Re: About using reassemble tcp/modulate state

[A. Wright]

Hello All,

The email below actually came from another pf mailing list,
pf at benzedrine.cx.  I thought I should ask my question here first since I'm
using the FreeBSD port of pf.  If it turns out not to be some difference
with the port, I'll try the other list.

I'm running FreeBSD 5.1-Release-p10 with pf 2.00 installed from the ports.
In the email below, Daniel Hartmeier says that 'reassemble tcp' should clean
TCP packets so they don't disclose your machine's uptime, as well as prevent
the counting of boxes behind a NAT.  In my pf.conf I have the line "scrub
all reassemble tcp fragment reassemble".  However, when I telnet to another
box running p0f v2 (http://lcamtuf.coredump.cx/p0f.shtml) it correctly
determines my uptime.  (It also correctly determines my OS as well, which I
thought the scrub option would prevent, but one thing at a time).

Can anyone offer me insight on why p0f can correctly determine my uptime
when the 'reassemble tcp' option is supposed to prevent it?

Thanks for your time!
Aaron


----- Original Message ----- 
From: "Daniel Hartmeier" <daniel at benzedrine.cx>
To: "Toni Riekkinen" <list-toni at nettitieto.fi>
Cc: <pf at benzedrine.cx>
Sent: Friday, December 12, 2003 7:46 PM
Subject: Re: About using reassemble tcp/modulate state


> On Sat, Dec 13, 2003 at 01:51:49AM +0200, Toni Riekkinen wrote:
>
> > What is the difference between using "scrub all reassemble tcp" and
using
> > "modulate state" in incoming traffic rules, i.e for webserver in DMZ:
>
> 'modulate state' applies to sequence numbers (th_seq, th_ack), which are
> a very basic part of TCP. When a connection is established each peer
> should choose a random initial sequence number, which then gets
> increased with the amount of data sent. It's crucial for security that
> these initial sequence numbers are unpredictable for outside parties,
> otherwise attackers can inject data into the connection or stall or
> reset it. Some OS' TCP/IP stacks are known to generate weak (non-random,
> predictable) initial sequence numbers, and modulate state will
> compensate for them by adding/subtracting a random modulator value.
>
> 'reassemble tcp' enables multiple normalization features for TCP
> packets, one of them is 'timeout modulation'. It's a similar scheme, but
> applied to timestamp TCP options. Such timestamps need not be random for
> security reasons, but non-random values can disclose your uptime or
> number of hosts (behind a NAT gateway), so you may wish to modulate them
> to not disclose that information. For instance, netcraft.com shows
> uptimes for certain hosts because they don't use random timestamps, and
> some ISPs prohibit use of multiple (NATed) hosts, analyzing timestamps
> to detect violations.
>
> So, these are two different and independant things. You can enable
> either of them, both or none. All of this is detailed in pf.conf(5),
> BTW.
>
> Daniel