From owner-freebsd-ipfw@FreeBSD.ORG Mon Aug 20 11:59:48 2007 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F09D316A419 for ; Mon, 20 Aug 2007 11:59:47 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from relay1.tpu.ru (relay1.tpu.ru [213.183.112.102]) by mx1.freebsd.org (Postfix) with ESMTP id 55A3A13C4D3 for ; Mon, 20 Aug 2007 11:59:47 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from localhost (localhost.localdomain [127.0.0.1]) by relay1.tpu.ru (Postfix) with ESMTP id 630F2104F95; Mon, 20 Aug 2007 18:59:45 +0700 (NOVST) X-Virus-Scanned: amavisd-new at tpu.ru Received: from relay1.tpu.ru ([127.0.0.1]) by localhost (relay1.tpu.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YoCv23fWpJR; Mon, 20 Aug 2007 18:59:44 +0700 (NOVST) Received: from mail.main.tpu.ru (mail.main.tpu.ru [10.0.0.3]) by relay1.tpu.ru (Postfix) with ESMTP id F3FE3104F1F; Mon, 20 Aug 2007 18:59:43 +0700 (NOVST) Received: from mail.tpu.ru ([213.183.112.105]) by mail.main.tpu.ru with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Aug 2007 18:59:44 +0700 Received: from nuclight.avtf.net ([83.172.2.235]) by mail.tpu.ru over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Aug 2007 18:59:44 +0700 Date: Mon, 20 Aug 2007 18:59:42 +0700 To: "Eduardo Meyer" References: From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/7.54 (Win32, build 3865) X-OriginalArrivalTime: 20 Aug 2007 11:59:44.0065 (UTC) FILETIME=[98D1A310:01C7E321] Cc: ipfw@freebsd.org Subject: Re: All I have is one packet! X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2007 11:59:48 -0000 19.08.07 @ 21:51 Eduardo Meyer wrote: >> Yes, dynamic rules in ipfw are not intended for supporting state created >> in the middle of the session, wuth the default sysctl settings it will >> be >> kept for 1 second (which, however, is enough for shaping of fast >> transfers). I think, precise controlling of dynamic rules from both >> userland and kernel should be added to ipfw, to modify existing rules on >> the fly (or even more features, like pfsync). As a hackish dirty >> workaround, may be it should be only one keyword, something like >> "keep-state-middle", to create normal dynamic rule without initial SYNs. >> >> But you've said about even more complex behaviour, like init on TCP, >> continue with UDP. That's difficult to implement in kernel, and may be >> even not suitable for ipfw. Currently (I think), you can try to emulate >> this behaviour by divert'ing tagged by ng_tag packet to userland >> program, >> like snort_inline (from ports collection) with needed scripting, which >> will trigger adding proper rules to firewall (you should also care about >> expiring that connection on FINs and RSTs, though). > > That's exactly the point. However, from a simplistic and probably > ignorant point of view on this matter, like mine, I believed it to be > in fact a much more simple "state", which would only compare IP > addresses (src<->dst) for the match, so I could just > > ipfw add X allow { tcp or udp } from any to any keep-iponly-state tagged > Y > > It would be helpfull with many protocols which in fact use a transport > proto (like TCP) to do actual session initialization while using > another transport proto (UDP, DDP, whatever) for the real traffic; > many things do this nowadays; > > Would such a feature be possible? Yes, in theory. But I'm not sure that such a patch will be merged into official tree. Also, one can think about link negotiation with another IP (src<->dst) pair, not this hosts: imagine direct FTP transfer between two servers or P2P application where clients negotiate connection parameters via server, and then only actual data in undetectable connection flows between them. So in general case you again need specialized protocol analyzer. For example, in your case with only IPs - can you say when dynamic rule will expire? -- WBR, Vadim Goncharov