Another bug in IPFW@ ...?
olli at lurza.secnetix.de
Wed Aug 3 13:51:21 GMT 2005
AT Matik <asstec at matik.com.br> wrote:
> On Wednesday 03 August 2005 06:19, Oliver Fromme wrote:
> > > 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.
> packages catched by xmit IF are catched with out as well
> "xmit any" probably is another expression for "out"
Ah, now I understand you. You wrote "out and xmit is the
same", but what you really meant was "out and xmit any is
the same". The latter is right, of course, because only
packets that leave the local host have a transmit interface.
This could be regarded as a semantical coincidence. :-)
However, due to the asymmetry of the filtering, the analogy
does _not_ work for the receive interface (so "in" is not
the same as "recv any"). And this is precicesly the thing
which exhibited the bug for me; see my very first posting
in this thread.
> > > 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
> good, then you do not catch them anyway by src|dst[-ip] unless you
> deny all but the src-ip you want to pass
I'm sorry, but I do not understand that sentence. What's
wrong with trying to make sure that packets which claim
to be from this host must be really generated on this host,
i.e. have no receive inetrface?
> and a fake dst-ip don't know who would do that
Someone who wants to circument routing policies by sending
a packet through an interface different from the one the
routing tables specify.
Besides, I don't ask "who would do that". Hackers sometimes
find creative ways to abuse possibilities that nobody has
thought of before. Rather than denying specific known bad
packats (and allowing everything else), I want to allow only
certain known good packets (and deny everything else).
Making sure that outgoing packets with a local source IP
have no receive interface is certainly a very valid thing
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.
"One of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination
of their C programs."
-- Robert Firth
More information about the freebsd-ipfw