Date: Thu, 16 Sep 2004 03:59:00 -0000 From: "A. Wright" <wright.546@osu.edu> To: <pf4freebsd@freelists.org> Subject: [pf4freebsd] Re: About using reassemble tcp/modulate state Message-ID: <072301c3c89c$0c3d1950$41040c0a@gswa.tld> References: <003301c3c10a$e94f7c00$aa66df50@FAITH> <20031213004650.GS24011@insomnia.benzedrine.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello All, The email below actually came from another pf mailing list, pf@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 cl= ean TCP packets so they don't disclose your machine's uptime, as well as prev= ent 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 anoth= er 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 -----=20 From: "Daniel Hartmeier" <daniel@benzedrine.cx> To: "Toni Riekkinen" <list-toni@nettitieto.fi> Cc: <pf@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 ar= e > 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, bu= t > applied to timestamp TCP options. Such timestamps need not be random fo= r > security reasons, but non-random values can disclose your uptime or > number of hosts (behind a NAT gateway), so you may wish to modulate the= m > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?072301c3c89c$0c3d1950$41040c0a>