Date: Tue, 20 Aug 2002 05:42:06 -0700 From: Luigi Rizzo <rizzo@icir.org> To: ipfw@freebsd.org Subject: ambiguity of filter expressions (tcpdump and ipfw2) Message-ID: <20020820054206.A45915@iguana.icir.org>
next in thread | raw e-mail | index | archive | help
[Bcc to -net, but please keep the discussion on -ipfw]
Hi,
we have the following issue (both in tcpdump and ipfw2):
when you specify a match pattern that is not applicable to the
packet being processed (e.g. "src-port 80" on an ICMP packet),
the match will simply fail and the packet will not be selected.
However, when you put in a "not" operator (as in "not src-port 80")
there are really two ways to implement the operation:
1. the basic match fails, so its negation will succeed.
This is the way tcpdump operates (try a "tcpdump not port 80"
and see how it matches all sort of non-tcp traffic), and also
ipfw2 does the same thing for consistency with tcpdump
(that is the official excuse -- in reality, i did not think of
the issue in the first place, maybe the same happened to
the tcpdump/libpcap authors).
2. The match operator is "not applicable" so both the
direct form and the negation will fail.
Now, using the first approach in a firewall might be somewhat dangerous,
in the sense that, yes, the rule does exactly what you write, but
that might not be what you really want. E.g. consider
ipfw add allow not src-port 80
which could be meant to pass all tcp traffic not coming from a web
server -- however, this rule would also leak all non-tcp and non-udp
packets. The correct way to express the rule is of course to
to include a "proto tcp" match pattern, but sometimes this can escape.
The second approach would prevent such mistakes, though it might
be non-obvious to people used to tcpdump syntax (although, i suspect
"not" operators are not widely used there either).
So, what do we do ? Implementing the second behavior requires rather
trivial changes in the kernel, and no changes in the kernel-user
interface or in the userland programs. ipfw2 syntax is not yet
widely used so changing between one mode and the other would not
give too much trouble to people. It might even be possible to provide
a sysctl variable to choose between the two behaviours, though i'd
rather not do that because it has a little bit of impact on run-time
performance, and also because having yet another tunable increases
confusion.
I'd be inclined to leave things as they are, surely remark the issue
in the manpage, and maybe make ipfw2 print out a "Warning" message
about the use of a potentially unsafe match pattern, same as the
compiler does when you use a "gets".
Opinions anyone ?
cheers
luigi
----------------------------------+-----------------------------------------
Luigi RIZZO, luigi@iet.unipi.it . ICSI (on leave from Univ. di Pisa)
http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704
Phone: (510) 666 2927
----------------------------------+-----------------------------------------
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020820054206.A45915>