pf keep sate
Hello, There is something that I don’t really understand about pf keep state : - documentation says : All pass rules automatically create a state entry when a packet matches the rule. This can be explicitly disabled by using the no state option. But… I find a lot of example on the web that add the keep state on tcp pass rules, and what is worse, I have to work on a production firewall that has such rules, so I can’t test. So my question is - is there any reason to add keep state to a pass rule ? Thanks. f.g.
Re: pf keep sate
at 10:04 AM, Frédéric Goudal wrote: - is there any reason to add keep state to a pass rule ? 1) UDP rules don’t keep state by default. 2) Even for TCP connections, it’s better to explicitly throw a keep state on there for clarity, so that people who come in behind you and actually bother reading the documentation don’t have to ask the same question. There’s also other available options for TCP connections that you might want to look into, such as flags S/SA (only allow initial handshake between endpoints that don’t have an established state) and modulate state, which generates strong, random ISNs for new connections.
Re: pf keep sate
Daniel Corbe(dco...@hammerfiber.com) on 2018.10.22 11:09:08 -0400: > at 10:04 AM, Fr??d??ric Goudal wrote: > > >- is there any reason to add keep state to a pass rule ? Only if you want to use one of the "Stateful Tracking Options" (see pf.conf(5)). For example, to add no-sync (dont send the state via pfsync(4)) you would add "keep state (no-sync)" to a rule: pass in proto tcp from any to any port www keep state (no-sync) (Of course you would only consider this if you actually have a pfsync(4) interface configured). > 1) UDP rules don???t keep state by default. Yes, they do. > 2) Even for TCP connections, it???s better to explicitly throw a keep state > on there for clarity, so that people who come in behind you and actually > bother reading the documentation don???t have to ask the same question. Thats a matter of taste, but i prefer not to read and write a useless "keep state" on every line. > There???s also other available options for TCP connections that you might > want to look into, such as flags S/SA (only allow initial handshake between > endpoints that don???t have an established state) which is the default too. > and modulate state, which generates strong, random ISNs for new connections. > > > > > --
Re: pf keep sate
Thanks for your answer. The disturbing thing for me was that I work on several firewalls, and some have the flags S/SA keep state options, and some not… so as I’m quite new to pf I was really wondering. f.g. > Le 22 oct. 2018 à 17:09, Daniel Corbe a écrit : > > at 10:04 AM, Frédéric Goudal wrote: > >> - is there any reason to add keep state to a pass rule ? > > 1) UDP rules don’t keep state by default. > > 2) Even for TCP connections, it’s better to explicitly throw a keep state on > there for clarity, so that people who come in behind you and actually bother > reading the documentation don’t have to ask the same question. There’s also > other available options for TCP connections that you might want to look into, > such as flags S/SA (only allow initial handshake between endpoints that don’t > have an established state) and modulate state, which generates strong, random > ISNs for new connections. > > > > > >
Re: pf keep sate
It is due to history. ipf didn't have stateful, at all. the first version of pf didn't have stateful, but it was incrementally added starting after 1 year over a period of 3 years. during development, it was not the default. other projects started adopting pf. (here is where it ges ugly) Along with many other advances, stateful was made the default. but other projects kept their old code, or performed partial updates of the code, or didn't change the defaults like we did therefore the lack of unification in the ecosystem can be directly blamed on those other projects who adopted our code, but soon abandoned efforts to keep things updated. but there is another piece of blame which can be apportioned i suppose -- a wise man does not assume that one system is the same as another, and reads the MODERN documentation rather than something dated off the web. Keeping things identical takes much effort, and one should not assume the work was done. > Thanks for your answer. > > The disturbing thing for me was that I work on several firewalls, and some > have the flags S/SA keep state options, and some not… so as I’m quite new to > pf I was really wondering. > > f.g. > > > Le 22 oct. 2018 à 17:09, Daniel Corbe a écrit : > > > > at 10:04 AM, Frédéric Goudal wrote: > > > >> - is there any reason to add keep state to a pass rule ? > > > > 1) UDP rules don’t keep state by default. > > > > 2) Even for TCP connections, it’s better to explicitly throw a keep state > > on there for clarity, so that people who come in behind you and actually > > bother reading the documentation don’t have to ask the same question. > > There’s also other available options for TCP connections that you might > > want to look into, such as flags S/SA (only allow initial handshake between > > endpoints that don’t have an established state) and modulate state, which > > generates strong, random ISNs for new connections. > > > > > > > > > > > > >
Re: pf keep sate
On 2018-10-22, Daniel Corbe wrote: > at 10:04 AM, Frédéric Goudal wrote: > >> - is there any reason to add keep state to a pass rule ? > > 1) UDP rules don’t keep state by default. That's not correct. > 2) Even for TCP connections, it’s better to explicitly throw a keep state > on there for clarity, so that people who come in behind you and actually > bother reading the documentation don’t have to ask the same question. > There’s also other available options for TCP connections that you might > want to look into, such as flags S/SA (only allow initial handshake between > endpoints that don’t have an established state) and modulate state, which > generates strong, random ISNs for new connections. "flags s/sa" is done by default, unless overridden with a different "flags" setting. It's down to personal opinion but I don't find that adding boilerplate to every "pass" rule makes things any more clear..
