More pf parser fun & user error & unexpected results 'match quick'
Ohh, I cleanup a ruleset and added some quicks to sets of 'pass in on interal', match with nat-to, pass out on external' rules. I managed to put a quick directive behind a match (ie match quick ...) and that is a VERY BAD thing to do. The definition of the quick directive from the man page of pf.conf: > If a packet matches a rule which has the quick option set, this rule is > considered the last matching rule, and evaluation of subsequent rules is > skipped. And from the match directive: > match > The packet is matched. This mechanism is used to provide fine grained > filtering without altering the block/pass state of a packet. ... Thus if one applies 'quick' to a match rule one could end up consigning packets to 'packet purgatory' ? Which is what I did. Is 'match quick' ever valid? Scott Donaldson Saskatoon, SK Canada
Re: pf ruleset parser re: tag and tagged
Well, I don't expect the parser to be able to fix rulesets but if it can help identify situations that may be an error. The situation I was describing was a human error in defining the tag (using tagged instead of tag). Which causes the tag to never be defined and thus the rules with 'tagged' for that value ..never execute. Seemed like a standard "parsing is that constant variable ever defined" scenario? except as Kenneth G. pointed out if the defining tag directive appears in an anchor ...(I hinted at that by referencing authpf)... Scott > On Jan 31, 2018, at 9:42 AM, Sadegh Solati <solati.sad...@gmail.com> wrote: > > Actually I think the problem is not with the tag/tagged. It comes from the > rule that If it is a quick one or not. When the rule is not quick it won't be > matched with the tagged one for updating the tag value.If it is quick it will > never see the next rule which is going to check the new tag value. It will be > very hard for the parser to fire an accurate alarm in these cases. > > On Jan 31, 2018 09:01, "S. Donaldson" <donald...@sedsystems.ca > <mailto:donald...@sedsystems.ca>> wrote: > Hi, > > Ran into a user error situation that perhaps the pf ruleset parser > could help with. > > I was working on rules and using tag/tagged and the rule that should > have 'applied' a tag used 'tagged value' instead of 'tag value'. Thus the tag > was never set and the subsequent 'pass tagged value' rule never fired. > > It seems that tag references are not dynamically defined [ unless > perhaps they are used in authpf scenarios? ]. Would it make sense for the > parser to issue a warning if a 'tagged value' references appear but no > defining 'tag value' is found in a ruleset? > > > Scott Donaldson > Saskatoon, SK > Canada > Scott Donaldson Manager of MIS Special Projects SED Systems a division of Calian Ltd. Saskatoon, SK Canada Office Phone: 306-933-1577
pf ruleset parser re: tag and tagged
Hi, Ran into a user error situation that perhaps the pf ruleset parser could help with. I was working on rules and using tag/tagged and the rule that should have 'applied' a tag used 'tagged value' instead of 'tag value'. Thus the tag was never set and the subsequent 'pass tagged value' rule never fired. It seems that tag references are not dynamically defined [ unless perhaps they are used in authpf scenarios? ]. Would it make sense for the parser to issue a warning if a 'tagged value' references appear but no defining 'tag value' is found in a ruleset? Scott Donaldson Saskatoon, SK Canada
pfctl 'indicates' states created for 'match' rules or some other stat is being shown?
The output (somewhat redacted) below is from pfctl (OpenBSD 61, amd64,
GENERIC.MP kernel).
The rules in question deal with NATing and forwarding packets for sessions that
are very short monitoring 'is this service alive' type sessions. So we've tried
to limit the number of states, and shorten state life to match the type of
traffic.
Internal traffic (and monitoring host) --> FW_em0 pf --> FW_em1 -->
monitored systems in DMZ
Curiously the pfctl command shows states for a 'match' rule as per:
pass in quick on em0 inet from 172.a.b.c to flags S/SA
keep state (max 200, source-track rule, tcp.established 15, tcp.closing 3,
adaptive.start 120, adaptive.end 240)
[ Evaluations: 1072 Packets: 327374Bytes: 19532619States: 200 ]
[ Inserted: uid 0 pid 24982 State Creations: 29979 ]
match out on em1 inet from 172.a.b.c to received-on em0
tag monother nat-to ext.net.add.xxx
[ Evaluations: 5693609 Packets: 566240Bytes: 34069203States: 347 ]
[ Inserted: uid 0 pid 24982 State Creations: 0 ]
However 'keep state' and per rule session tracking are not allowed on match
'actions'.
The above rules are rule 10 and rule 11 in the ruleset. So when I ask to see
states by rule
pfctl -s state -R 10
shows states as expected
pfctl -s state -R 11
shows nothing
So is that State count on a 'match' action actually some other statistic?
I tried following the grammar in the pf.conf man page and to me it seems like
the match action is allowed both 'keep state'
and I just got confused trying to parse the 'filteropt' definition. See
below
Scott Donaldson
Manager of MIS Special Projects
SED Systems a division of Calian Ltd.
Saskatoon, SK
Canada
Office Phone: 306-933-1577
pf-rule= action [ ( "in" | "out" ) ]
[ "log" [ "(" logopts ")"] ] [ "quick" ]
[ "on" ( ifspec | "rdomain" number ) ] [ af ]
[ protospec ] [ hosts ] [ filteropts ]
action = "pass" | "match" | "block" [ return ]
filteropts = filteropt [ [ "," ] filteropts ]
filteropt = user | group | flags | icmp-type | icmp6-type |
"tos" tos |
( "no" | "keep" | "modulate" | "synproxy" ) "state"
[ "(" state-opts ")" ] | "scrub" "(" scrubopts ")" |
"fragment" | "allow-opts" | "once" |
"divert-packet" "port" port | "divert-reply" |
"divert-to" host "port" port |
"label" string | "tag" string | [ "!" ] "tagged" string |
"max-pkt-rate" number "/" seconds |
"set prio" ( number | "(" number [ [ "," ] number ] ")" ) |
"set queue" ( string | "(" string [ [ "," ] string ] ")" ) |
"rtable" number | "probability" number"%" | "prio" number |
"af-to" af "from" ( redirhost | "{" redirhost-list "}" )
[ "to" ( redirhost | "{" redirhost-list "}" ) ] |
"binat-to" ( redirhost | "{" redirhost-list "}" )
[ portspec ] [ pooltype ] |
"rdr-to" ( redirhost | "{" redirhost-list "}" )
[ portspec ] [ pooltype ] |
"nat-to" ( redirhost | "{" redirhost-list "}" )
[ portspec ] [ pooltype ] [ "static-port" ] |
[ route ] | [ "set tos" tos ] |
[ [ "!" ] "received-on" ( interface-name | interface-group ) ]
Re: pfctl parse issue with negated protocol list: block on $int proto ! { prot1 prot2 prot3 } leads to syntax error
Stuart,
Thanks for the feedback. The warning about list expansion is
appreciated I was aware of the downside.
It seemed to be an error in the parser to me, but I'd have to review
the grammar again. Ah yes no negation in the grammar for 'protospec' or
proto-list !!!
I've moved past simple block / allow and am trying to add 'forensic'
rules that generate log data that I can perform some low level analysis
against. I have not found documentation that clearly states that a block rule
such as you suggest:
block on $int inet
will also effectively block all non-ip protocols. I assume that it does.
> On Nov 23, 2017, at 2:21 AM, Stuart Henderson <s...@spacehopper.org> wrote:
>
> On 2017/11/21 12:21, S. Donaldson wrote:
>> Applies to stable:
>>
>> OpenBSD 6.1 GENERIC.MP amd64
>>
>> and stable
>>
>> OpenBSD 6.2 GENERIC.MP amd64
>>
>>
>> pf rules that block using the proto key work with a negation fail with a
>> syntax error.
>>
>> block on $int inet proto ! tcp
>
> I think you'll just need two rules for that:
>
> block on $int inet
> pass on $int inet proto tcp
>
>> and list based negations also fail
>>
>> block on $int inet proto ! { tcp udp }
>>
>> with a syntax error.
>
> Beware of list negations! If this was allowed it would expand to this:
>
> block on $int inet proto ! tcp
> block on $int inet proto ! udp
>
> Which is not what you want.
>
> It may seem to work in some cases with a list of IP addresses as the
> ruleset optimizer will convert them to a table if there are enough
> addresses, but this is dangerous as if you remove enough addresses it
> will start to do the wrong thing.
>
> In general avoid negation with lists.
Scott Donaldson
IS Manager
SED Systems a division of Calian Ltd.
Saskatoon, SK
Canada
Office Phone: 306-933-1577
when used pfctl should log any changes to state of FW
I have been working with OpenBSD since 2.6, have deployed it in many roles. Have hacked authpf to have authpfnoip with ip functionality (there is a reason!). So I have some experience with the OS...mostly as an implementer/admin not a dev type. Motivation: I am configuring a 'segregating' Openbsd based firewall that I want to maximize the auditibility/accountability on/for. Question/Suggestion: So why does pfctl not appear to (I could not find a command line option - nor previous request) log to syslog every command (who when what exit status) that changes anything within the pf context such as : rules, table contents, states? I don't want the detailed changes that may occur within pf - just establishing accountability. Scott Donaldson
