Date: Tue, 20 Aug 2002 11:37:39 -0700 From: Joe Eykholt <jre@IPRG.nokia.com> To: Luigi Rizzo <rizzo@icir.org> Cc: ipfw@FreeBSD.ORG Subject: Re: ambiguity of filter expressions (tcpdump and ipfw2) Message-ID: <3D628C73.D5C85248@iprg.nokia.com> References: <20020820054206.A45915@iguana.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
How about giving a syntax error if TCP or UDP (or some other (future) protocol where a port number IS applicable) isn't specified? That'd remove the ambiguity and alert any existing users to any problem in their rules. I'm not on the ipfw alias, and you don't need to reply to this suggestion. Joe Luigi Rizzo wrote: > > [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-net" in the body of the message -- Joe Eykholt jre@iprg.nokia.com Nokia Internet Communications 313 Fairchild Drive, Mountain View, CA 94043 http://www.nokia.com/securitysolutions/ 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?3D628C73.D5C85248>