On Sat, 1 Oct 2005 04:43:40 -0500, Travis H. wrote: >>>In pf nat rules also the first match wins >>> >>>__but__ >>> >>>in pf filter rules the __last__ match wins. >>> >>>In fact that is the one thing I don't like in pf, but to have a "first >>>match win" you can use the magic word quick in all your pass and block >>>rules. (e.g "pass in quick") > >>And thereby end up with yards of quick rules that can catch you later. > >Ah, but the matching engine doesn't have to traverse the whole rule >list that way. Unless pf is doing something really tricky, every >packet will have to traverse every firewall rule without use of >quicks. On a complicated, busy firewall setup, this might have a >noticable performance impact. > >>You should think of it this way: >>Default security is best with block everything and then pass what >>selected few things you need. >>So: >>block all >>pass in on $int_if from $safe1 to $ok2 keep state >>pass in on $ext_if from any to $ext_if port ssh keep state > >I agree, with the added use of quick on each of the pass rules. > >In fact, you can probably use quick on virtually every rule other than >that default without any loss of expressiveness. Thanks to negations, >having two different precedences is largely unnecessary (previously >you'd have to pass nonquick for some set of packets, then block again >for some subset to get the same effect as a negation).
And right there you demonstrated that you haven't thought it through. Or else you are trolling because it goes like this: <using only the logic of pf but not the syntax because obviously that is too, too hard for a beginner like you> Block everything Pass in from anywhere to webserver port http keep state Pass in from anywhere to mailserver port smtp keep state Pass in from LAN to anywhere port http or https keep state === Now where do I have to add another block? First match wins = it is already there. For the benefit of beginners who thought this guy had a point let's cast it another way. Party time: Nobody can come into my house The musos can come The beautiful babes can enter My best buddies can come The caterers can bring food The grogshop can deliver beer ==== Where did I need to add a block in quick dummies rule following that to keep out trolls? > >It's probably not necessary, and I may offend purists by my >performance optimizations, but I actually have this as my first rule: > >pass quick on lo0 Jeez, that's original. I think I saw that (or its equivalent in the pf.conf examples.) Yep, I did. Hell it was even quick..... > >I also find it useful to use the following rule right after "default deny": > >block return on $lan_if Hey, read the default pf.conf: block in is rule one. Your rule is redundant. You can set the policy for blocks to drop or return. You get to choose and it can be an intelligent choice if you are smart enough to know what the differences are. > >I do have some questions about pf though. How come you can only >modify source IP/ports outbound, and destination IP/ports inbound? >Why not the other two alternatives? > >I also don't see why NAT should necessarily occur before the filtering >rules. It makes more sense to my intuition to have the order in the >pf.conf control the order of operations, but I admit implementation >issues may make this less elegant. You are a master of several things. The politest one is understatement. When trolling the other is bator, you just <thought> it was baiter. > >Also, I find supporting $macros in pf.conf a little crufty. Why not >just do something like this: > >#! /bin/sh >lan_if=xl1 >wan_if=ex0 >pfctl -f /dev/stdin <<EOM >pass quick on lo0 >block all >pass quick in on $lan_if all keep state >pass in quick on $wan_if from any to $wan_if proto tcp port = 22 keep state >[...] >EOM > Run commands to do firewalling? iptables is your scene, is it? >That way, you have the full expressive power of the shell, including >command substitution, arithmetic substitution, variable substitution, >trimming suffixes and prefixes, and all kinds of shell magic. It >doesn't replace lists or tables of course. But you can easily do >conditional inclusion of rules, and that's useful for cases like DHCP. > The interface comes up with IP 0.0.0.0/0, which I think means it will >accept any packet as destined for this interface, no matter what the >destination IP. I only allow in replies from my ISP's DHCP server >during this stage, and only those destined to 255.255.255.255 (I don't >want rogue servers answering my DHCP requests, which are sent via >local broadcast (hence to all my neighbors). It was also pretty >useful before things supported the (interface) notation for looking up >IP addresses each time. Sad misunderstanding demonstrated there. > >That having been said, pf is way cool. Keep up the good work. That having been said, it says you are trolling again. Wanker. Back to Linux, baby. >From the land "down under": Australia. Do we look <umop apisdn> from up over? Do NOT CC me - I am subscribed to the list. Replies to the sender address will fail except from the list-server.
