From owner-freebsd-pf@FreeBSD.ORG Thu Sep 16 03:59:04 2004 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 674) id E342916A4CF; Thu, 16 Sep 2004 03:59:04 +0000 (GMT) Delivered-To: mlaier@vampire.homelinux.org Received: (qmail 17784 invoked by uid 1005); 23 Dec 2003 03:38:10 -0000 Delivered-To: max@vampire.homelinux.org Received: (qmail 17781 invoked from network); 23 Dec 2003 03:38:10 -0000 Received: from moutng.kundenserver.de (212.227.126.173) by p50839e79.dip.t-dialin.net with SMTP; 23 Dec 2003 03:38:10 -0000 Received: from [212.227.126.153] (helo=mxng02.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1AYdIq-00047J-00 for max@vampire.homelinux.org; Tue, 23 Dec 2003 04:33:48 +0100 Received: from [206.53.239.180] (helo=turing.freelists.org) by mxng02.kundenserver.de with esmtp (Exim 3.35 #1) id 1AYdIq-0006Gd-00 for max@love2party.net; Tue, 23 Dec 2003 04:33:48 +0100 Received: from turing (localhost [127.0.0.1])ESMTP id 3DA95394921 for ; Mon, 22 Dec 2003 22:33:37 -0500 (EST) Received: with ECARTIS (v1.0.0; list pf4freebsd); Mon, 22 Dec 2003 22:33:27 -0500 (EST) X-Original-To: pf4freebsd@freelists.org Delivered-To: pf4freebsd@freelists.org Received: from ns.kt-is.co.kr (ns.kt-is.co.kr [211.218.149.125]) ESMTP id 73BDA394A37 for ; Mon, 22 Dec 2003 22:33:25 -0500 (EST) Received: from michelle.kt-is.co.kr (ns2.kt-is.co.kr [220.76.118.193]) (authenticated bits=128) by ns.kt-is.co.kr (8.12.10/8.12.10) with ESMTP id hBN3VsAh091786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 23 Dec 2003 12:31:55 +0900 (KST) Received: from michelle.kt-is.co.kr (localhost.kt-is.co.kr [127.0.0.1]) by michelle.kt-is.co.kr (8.12.9/8.12.9) with ESMTP id hBN3XS1n000688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Dec 2003 12:33:28 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Received: (from yongari@localhost) by michelle.kt-is.co.kr (8.12.9/8.12.9/Submit) id hBN3XRIS000687 for pf4freebsd@freelists.org; Tue, 23 Dec 2003 12:33:27 +0900 (KST) (envelope-from yongari@kt-is.co.kr) From: Pyun YongHyeon To: pf4freebsd@freelists.org Message-ID: <20031223033327.GA595@kt-is.co.kr> References: <003301c3c10a$e94f7c00$aa66df50@FAITH> <20031213004650.GS24011@insomnia.benzedrine.cx> <072301c3c89c$0c3d1950$41040c0a@gswa.tld> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <072301c3c89c$0c3d1950$41040c0a@gswa.tld> User-Agent: Mutt/1.4.1i X-Filter-Version: 1.11a (ns.kt-is.co.kr) X-archive-position: 246 X-ecartis-version: Ecartis v1.0.0 Sender: pf4freebsd-bounce@freelists.org Errors-To: pf4freebsd-bounce@freelists.org X-original-sender: yongari@kt-is.co.kr Precedence: normal X-list: pf4freebsd Content-Transfer-Encoding: quoted-printable X-Provags-Forward: max@love2party.net -> max@vampire.homelinux.org X-UID: 364 X-Length: 7950 X-Mailman-Approved-At: Thu, 16 Sep 2004 03:59:49 +0000 Subject: [pf4freebsd] Re: About using reassemble tcp/modulate state X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Reply-To: pf4freebsd@freelists.org List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Thu, 16 Sep 2004 03:59:05 -0000 X-Original-Date: Tue, 23 Dec 2003 12:33:27 +0900 X-List-Received-Date: Thu, 16 Sep 2004 03:59:05 -0000 On Mon, Dec 22, 2003 at 09:58:23AM -0500, A. Wright wrote: > Hello All, >=20 > 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 differen= ce > with the port, I'll try the other list. >=20 > I'm running FreeBSD 5.1-Release-p10 with pf 2.00 installed from the po= rts. > 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 p= revent > the counting of boxes behind a NAT. In my pf.conf I have the line "sc= rub > all reassemble tcp fragment reassemble". However, when I telnet to an= other > box running p0f v2 (http://lcamtuf.coredump.cx/p0f.shtml) it correctly > determines my uptime. (It also correctly determines my OS as well, wh= ich I > thought the scrub option would prevent, but one thing at a time). >=20 p0f does not report correct uptime on my box. The rule I used: set loginterface fxp0 scrub all reassemble tcp fragment reassemble The clinet's uptime is 18 min. When I disable scrub rule, p0f display uptime correctly. p0f - passive os fingerprinting utility, version 2.0.2 (C) M. Zalewski , W. Stearns p0f: listening (SYN) on 'fxp0', 193 sigs (9 generic), rule: 'all'. 192.168.10.9:49157 - FreeBSD 5.1-current (2) (up: 0 hrs)=20 -> 192.168.10.28:22 (distance 0, link: ethernet/modem) But when I enable 'scrub all reassemble tcp fragment reassemble'. p0f reports incorrect uptime. 192.168.10.9:49158 - FreeBSD 5.1-current (2) (up: 2894 hrs)=20 ^^^^^^^^^^^^^ -> 192.168.10.28:22 (distance 0, link: ethernet/modem) My client's uptime is not 2894 hours but 18min. Did you have 'options RANDOM_IP_ID' in your kernel config? I think OS guessing is different area. Most OSes use differnt signature in its SYN packet. p0f just compares this signature with predefined tables as pf's finger printing does. In FreeBSD 5.2R, all ip_id value is set to 0 which is differnet from previous behavior when fragmentation is not occurred. This means that having simple tcpdump can indicate remote OS is FreeBSD 5.2R or -CURRENT or Linux. Thanks. > Can anyone offer me insight on why p0f can correctly determine my upti= me > when the 'reassemble tcp' option is supposed to prevent it? >=20 > Thanks for your time! > Aaron >=20 >=20 > ----- Original Message -----=20 > From: "Daniel Hartmeier" > To: "Toni Riekkinen" > Cc: > Sent: Friday, December 12, 2003 7:46 PM > Subject: Re: About using reassemble tcp/modulate state >=20 >=20 > > On Sat, Dec 13, 2003 at 01:51:49AM +0200, Toni Riekkinen wrote: > > > > > What is the difference between using "scrub all reassemble tcp" an= d > using > > > "modulate state" in incoming traffic rules, i.e for webserver in D= MZ: > > > > '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 th= at > > 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-ran= dom, > > 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 timestam= ps > > 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 >=20 >=20 Regards, Pyun YongHyeon --=20 Pyun YongHyeon