From owner-freebsd-ipfw@FreeBSD.ORG Wed Aug 3 09:19:27 2005 Return-Path: X-Original-To: freebsd-ipfw@FreeBSD.ORG Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC7D516A420 for ; Wed, 3 Aug 2005 09:19:27 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id E898B43D4C for ; Wed, 3 Aug 2005 09:19:26 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (bczgzu@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.1/8.13.1) with ESMTP id j739JP6G010572 for ; Wed, 3 Aug 2005 11:19:25 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.1/8.13.1/Submit) id j739JPAL010571; Wed, 3 Aug 2005 11:19:25 +0200 (CEST) (envelope-from olli) Date: Wed, 3 Aug 2005 11:19:25 +0200 (CEST) Message-Id: <200508030919.j739JPAL010571@lurza.secnetix.de> From: Oliver Fromme To: freebsd-ipfw@FreeBSD.ORG In-Reply-To: <200508022151.45925.asstec@matik.com.br> X-Newsgroups: list.freebsd-ipfw User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-RELEASE (i386)) Cc: Subject: Re: Another bug in IPFW@ ...? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-ipfw@FreeBSD.ORG List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2005 09:19:27 -0000 AT Matik wrote: > On Tuesday 02 August 2005 14:46, Oliver Fromme wrote: > > > P.S. looks very strange "out not recv any xmit" > > > > It's perfectly valid syntax according to ipfw(8). > > (1+1-1)/1 also ... ;) I should have added: "perfectly valid syntax _and_ it makes sense". > > 1. "out" --> match only outgoing packets. > > > > 2. "not recv any" --> match packets that haven't been > > received through any interface (i.e. which originate > > from the local host). It's simply a negation of > > "recv any", see the ipfw(8) manpage. > > > > 3. "xmit dc0" --> match packets which are going to be > > transmitted through the dc0 interface. > > even if I agree to your logic aspect in general I thought The ipfw(8) manpage certainly agrees with my logic. I suggest you have a look at it, it's quite well written. > out and xmit is probably exactly the same No, it's not. "out" just says that this rule matches only outgoing packets. It doesn't specify anything about inter- faces or addresses. > still especially as you set > src-ip and dst-ip so the interface where this packages are xmit is > defined by the routes src-ip and dst-ip can be both faked and need not have anything to do with the interfaces on which a packet is received or transmitted. Sure, for "normal" packets, the routes specify the transmit interface, but a malicous program can just circumvent that and send packets with arbitrary content out through any interface. Therefore it is always a good idea to check _both_ (i.e. addresses _and_ interfaces). If you don't check interfaces, you might open holes for spoofed packets. > localhost normally runs on lo0 which is an interface as any other That's an entirely different thing. I was not talking about packets going through lo0 -- those don't leave the local host anyway, and are handled by rules earlier in the rule set. I was rather talking about packets generated by the local host, destined for a remote host, for example someone is using ping(1) or telnet(1) on the machine. Packets generated that way do not have a receive interface (neither a physical interface nor lo0 or some- thing else). > so which ghost packages you try to catch here? *sigh* The rule should allow packets going out through dc0 which have not been received through any interface. (Furthermore, the rule verifies that the source IP is the address configured on dc0, and that the destination I is OK for the LAN connected to dc0, but these checks are not the problem.) I didn't imagine that it could be _that_ difficult to understand. :-) > probably this rule you try is a deny all rule since any package is > beeing received by some IF before it can go out or xmit No. See above. If you type "ping remotehost", the ICMP ECHO request packets that your machines is going to send do not have a receive interface. (And in the same way, the ECHO REPLY packets that it's going to receive won't have a transmit interface, of course.) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. > Can the denizens of this group enlighten me about what the > advantages of Python are, versus Perl ? "python" is more likely to pass unharmed through your spelling checker than "perl". -- An unknown poster and Fredrik Lundh