Another bug in IPFW@ ...?

[Oliver Fromme]

AT Matik <asstec at matik.com.br> 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