Date: Wed, 12 Jul 2006 14:13:31 +0100 From: "Greg Hennessy" <Greg.Hennessy@nviz.net> To: <freebsd-pf@freebsd.org> Subject: RE: PF firewall rules Message-ID: <000001c6a5b4$f8b055c0$0a00a8c0@thebeast> In-Reply-To: <44B4C782.2@thebeastie.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > While I can give you the benefit of the doubt that in some > way you are trying to help I would prefer it if you just didn't respond to me. > Your your comments are really abrasive,over the top and lacking of > useful nature. I am sorry, I cannot leave this go unchallenged, one's posting record on this and other pf mailing lists & freebsdforums.org http://www.freebsdforums.org/forums/search.php?searchid=155847 speaks for itself. It's not the fault of the audience when someone refuses to take advice on board, ignores the reference material, demonstrates a lack of basic networking knowledge and then continues to slate the implementation of something they clearly do not understand. > This is a mailing list on PF for help and information exchange not a > place to say RTFMP, and there is no argument that man pages > are really just aimed for reference use for these who already familiar with what > they need to do. Oh puhleeze, reading the man page on pf is *precisely* what you need to do. The pf.conf page covers the subject matter in detail. In particular relating to the use of tagging, the pf.conf man page provides a very easily understood explanation tag <string> Packets matching this rule will be tagged with the specified string. The tag acts as an internal marker that can be used to identify these packets later on. This can be used, for example, to provide trust between interfaces and to determine if packets have been processed by translation rules. Tags are "sticky", meaning that the packet will be tagged even if the rule is not the last matching rule. Further matching rules can replace the tag with a new one but will not remove a previously applied tag. A packet is only ever assigned one tag at a time. pass rules that use the tag keyword must also use keep state, modulate state or synproxy state. Packet tagging can be done during nat, rdr, or binat rules in addi- tion to filter rules. Tags take the same macros as labels (see above). tagged <string> Used with filter or translation rules to specify that packets must already be tagged with the given tag in order to match the rule. Inverse tag matching can also be done by specifying the ! operator before the tagged keyword. and a sample implementation. # Packet Tagging # three interfaces: $int_if, $ext_if, and $wifi_if (wireless). NAT is # being done on $ext_if for all outgoing packets. tag packets in on # $int_if and pass those tagged packets out on $ext_if. all other # outgoing packets (i.e., packets from the wireless network) are only # permitted to access port 80. pass in on $int_if from any to any tag INTNET keep state pass in on $wifi_if from any to any keep state block out on $ext_if from any to any pass out quick on $ext_if tagged INTNET keep state pass out on $ext_if proto tcp from any to any port 80 keep state # tag incoming packets as they are redirected to spamd(8). use the tag # to pass those packets through the packet filter. rdr on $ext_if inet proto tcp from <spammers> to port smtp \ tag SPAMD -> 127.0.0.1 port spamd block in on $ext_if pass in on $ext_if inet proto tcp tagged SPAMD keep state As does PF Users Guide on http://www.openbsd.org/faq/pf/tagging.html You asked specifically how to minimise the ruleset, in particular implementing effectively one filtering rule per flow. I point you at the documentation & then go onto detail not one but *two* mechanisms for doing so, and the thanks I get is to be accused of being unhelpful. Sheesh. PF != IPF. It doesn't necessarily make it any worse, it doesn't necessarily make it any better. Both have their place in the world. It's not the fault of the product when someone has obvious difficulties getting their head around simple differences in implementation detail. That's my final word on the matter.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000001c6a5b4$f8b055c0$0a00a8c0>