From owner-freebsd-ipfw@FreeBSD.ORG Sun Aug 19 14:51:11 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 34B0816A46B for ; Sun, 19 Aug 2007 14:51:11 +0000 (UTC) (envelope-from dudu.meyer@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.229]) by mx1.freebsd.org (Postfix) with ESMTP id BABB613C428 for ; Sun, 19 Aug 2007 14:51:10 +0000 (UTC) (envelope-from dudu.meyer@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so666938wra for ; Sun, 19 Aug 2007 07:51:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ULDmn3dzDIlTU8kGDkmLJ2WhfxG1FrKHeN78XhWjJUo1GEU3EiThkR75DgzgSkht6EOu4UApXxtmFaeosFuvGikATBQAvjpWIQHvdOMr/DJGKPLLKhqGXteSAkPvWVKejgakcRRF1Gq4re5EHJqeJezpmzYHpwBRAiMLJtldrDM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AY8zs+ZctUlCB2W59iWsencdTw4St3x6s0jvMAC2EaRwze+TiPBidC2lEMYDqJP1oR3QczbD+gijuGQMl2KlVBHc3JA51oMKTBh2OFS3kEUrBYk3jleNdWF+Tn7TYEEB2tKo4B5ICQNON/UAfTW4ZmJurhqHcm7gN296kA/kbh0= Received: by 10.90.95.11 with SMTP id s11mr7520554agb.1187535068444; Sun, 19 Aug 2007 07:51:08 -0700 (PDT) Received: by 10.65.159.7 with HTTP; Sun, 19 Aug 2007 07:51:08 -0700 (PDT) Message-ID: Date: Sun, 19 Aug 2007 11:51:08 -0300 From: "Eduardo Meyer" To: "Vadim Goncharov" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: 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: Sun, 19 Aug 2007 14:51:11 -0000 On 8/8/07, Vadim Goncharov wrote: > 06.08.07 @ 23:05 Eduardo Meyer wrote: > > > I have tried, for many weeks, ng_tag to tag packets for ipfw > > filtering. I could make it work fine. However, I have one problem. I > > want to make a state that will match any packet, on any protocol, > > between the peers. Why? Because all I have, is one packet. And this > > packet however, wont always be in the same transport protocol. > > > > For example, I can identify session initialization on TCP packets, but > > once initialized, all communication between peers happen via UDP. > > > > I know such a thing dont exist in ipfw. However, I would like to know > > if someone can suggest changes to the code that would do this. Would > > also be great if I could have a sysctl OID to tune state-timing of > > this unusual behavior, differently from the existing sysctl mibs on > > "dyn" stuff on ipfw. > > > > Every suggestion on a feature like that, would be appreciated. > > 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 SYNs 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? -- =========== Eduardo Meyer pessoal: dudu.meyer@gmail.com profissional: ddm.farmaciap@saude.gov.br