I'm fresh off the boat from Debian. I love OpenBSD's attitude, and the
documentation is even pretty decipherable, but I'm still a little
confused by pf. I managed to build a trivial filter, but there are a
few things I don't understand.
I read somewhere (3 books, google, the website docs, and man) that a
longer rule takes longer to do its work. Why? I don't understand how
pf works -- I'd expect pfctl, while it's munging pf.conf, to make most
of the conditions into a big mask that could just && with the IP
header and make a decision on the result. So specifying the proto and
both addresses and flags shouldn't make much difference in efficiency.
No?
pf.conf consists largely of anchors (to fork on protocol) and sub-
anchors below them to fork on service -- I'm trying to reduce the
count of rules seen by a packet to a minimum. But
pfctl -vs Anchors
gives this (in part):
/root:# pfctl -vs Anchors
TCP_IN
TCP_IN/POP3
TCP_IN/SMTP
TCP_IN/SSH
TCP_IN/TCP_IN
TCP_IN/TCP_IN/POP3
TCP_IN/TCP_IN/SMTP
TCP_IN/TCP_IN/SSH
Here's the TCP_IN anchor:
anchor "TCP_IN/*" in inet proto tcp from any port > 1023 to $OUTSIDE
flags S/SA {
anchor "SMTP/*" inet proto tcp to port smtp {
block drop in quick from <ASIA_BLK>
block drop in quick from <SMTP_BLK>
pass in quick
}
anchor "POP3/*" inet proto tcp to port pop3 {
block drop in quick from <ASIA_BLK>
block drop in quick from <POP_BLK>
pass in quick
}
anchor "SSH/*" inet proto tcp to port ssh {
block drop in quick from <ASIA_BLK>
block drop in quick from <SSH_BLK>
pass in quick
}
pass in inet proto tcp to port rsync
}
Why does pfctl say there's a TCP_IN/TCP_IN?
Do there have to be "/*"s after all the anchor names?
Is it true that sub-anchors are 'evaluated' in alphabetical order as
opposed to the order in the file? If so, is there a reason for this?
Is the pf list from Christmas Island still viable? I tried twice to
subscribe and got bounced as spam both times.
And is there a way to get rid of an anchor without rebooting? When I
change spellings,
pfctl -s Anchors
shows the old ones still in there.
TIA...
--
Glenn English
g...@slsware.com
