Re: pf.conf parser/lint

[Chris Bennett]

On Mon, Dec 21, 2020 at 07:28:54PM -0800, Sean Kamath wrote:
> > On Dec 21, 2020, at 14:24, Aham Brahmasmi  wrote:
> > For the defaults, I try to explicitly write some of them sometimes. I
> > find this helpful because it is difficult for me to remember what the
> > defaults are. However, I do understand that I run the risk of being
> > caught unawares if the defaults are changed for some good reason.
> > Trade-offs :)
> 
> That is what I use comments for. ;-)
> 
> a) Tells me what I *think* the defaults are
> b) Reminds me I’m *using* the defaults
> c) When the defaults change, makes it easy to find out why things break (if 
> they break, which they haven’t in recent memory)
> 
> Sean

Which raises the question of knowing when the defaults change.
Waiting until things *obviously* break doesn't address the time that
things *silently* break.
Silent breakage seems like a pretty serious security problem.
Having the syntax pass OK is not the same thing as having what you need
or want.
I really don't see how any linter can accomplish such a complex question.
Is my conf REALLY doing the right thing? Seems to. But maybe not.

For a good example, a small mistake in smtpd.conf will run just fine,
but with truly disastrous results.

Chris Bennett

Re: pf.conf parser/lint

[Sean Kamath]

> On Dec 21, 2020, at 14:24, Aham Brahmasmi  wrote:
> For the defaults, I try to explicitly write some of them sometimes. I
> find this helpful because it is difficult for me to remember what the
> defaults are. However, I do understand that I run the risk of being
> caught unawares if the defaults are changed for some good reason.
> Trade-offs :)

That is what I use comments for. ;-)

a) Tells me what I *think* the defaults are
b) Reminds me I’m *using* the defaults
c) When the defaults change, makes it easy to find out why things break (if 
they break, which they haven’t in recent memory)

Sean

Re: pf.conf parser/lint

[Aham Brahmasmi]

Namaste Peter,

Tusen takk for your reply.

> Sent: Saturday, December 19, 2020 at 3:32 PM
> From: "Peter Nicolai Mathias Hansteen" 
> To: "misc" 
> Subject: Re: pf.conf parser/lint
>
> 
> 
> > 19. des. 2020 kl. 14:50 skrev Aham Brahmasmi :
> >>> 
> >> 
> >> Always put your interfaces into groups.  Identify based upon the groups.
> > 
> > In case there are more such simple rules of thumb, could you please
> > share them?
> 
> I think that piece of advice is one of the more important ones you’re likely 
> to get.
> 
> Adding to that, in my experience, the important thing is to make your 
> configurations as simple as possible but not simpler :)
> 
> I would like to stress using pf.conf readability features as helpers to 
> keeping your config maintainable, so
> 
> * use service names when feasible instead of port numbers,
> * use tables for groups of IP addresses
> * use macros where they do help readability
> * write rules that specify only what would be deviation from the default (the 
> defaults are, in general sane)
> * before actually loading a changed config, run pfctl -vnf /etc/pf.conf to se 
> what *actually* loads
> 
> That last one will among other things show you the result of the ruleset 
> optimizer’s work, so when you see obviously generated table names, you likely 
> have a set of rules that differ only in their source or destination address. 
> That is a surprisingly frequent phenomenon, and for some reason more people 
> than you would think are unaware that you can initialize a table or even load 
> new content into one from a separate file.

All of the above are good simple rules of thumb.

For the defaults, I try to explicitly write some of them sometimes. I
find this helpful because it is difficult for me to remember what the
defaults are. However, I do understand that I run the risk of being
caught unawares if the defaults are changed for some good reason.
Trade-offs :)

> If you haven’t already, you might glean a few useful bits from going through 
> the PF tutorial slides at https://home.nuug.no/~peter/pftutorial/ 
> <https://home.nuug.no/~peter/pftutorial/> and links therein.

I have, and tusen takk once again for the slides, tutorials and talks.

> All the best,
> Peter

Additionally, I encountered some more such useful rules of thumb from
Stuart's reply[0] on another thread, which co-incidentally also mentions
interface groups.

"
...Tagging...received-on...interface groups...priority or queues or flow
queues...
"

Dhanyavaad,
ab
[0] - https://marc.info/?l=openbsd-misc&m=160068271606631&w=2
-|-|-|-|-|-|-|--

Re: pf.conf parser/lint

[Peter Nicolai Mathias Hansteen]

> 19. des. 2020 kl. 14:50 skrev Aham Brahmasmi :
>>> 
>> 
>> Always put your interfaces into groups.  Identify based upon the groups.
> 
> In case there are more such simple rules of thumb, could you please
> share them?

I think that piece of advice is one of the more important ones you’re likely to 
get.

Adding to that, in my experience, the important thing is to make your 
configurations as simple as possible but not simpler :)

I would like to stress using pf.conf readability features as helpers to keeping 
your config maintainable, so

* use service names when feasible instead of port numbers,
* use tables for groups of IP addresses
* use macros where they do help readability
* write rules that specify only what would be deviation from the default (the 
defaults are, in general sane)
* before actually loading a changed config, run pfctl -vnf /etc/pf.conf to se 
what *actually* loads

That last one will among other things show you the result of the ruleset 
optimizer’s work, so when you see obviously generated table names, you likely 
have a set of rules that differ only in their source or destination address. 
That is a surprisingly frequent phenomenon, and for some reason more people 
than you would think are unaware that you can initialize a table or even load 
new content into one from a separate file.

If you haven’t already, you might glean a few useful bits from going through 
the PF tutorial slides at https://home.nuug.no/~peter/pftutorial/ 
 and links therein.

All the best,
Peter


—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.






signature.asc
Description: Message signed with OpenPGP

Re: pf.conf parser/lint

[Aham Brahmasmi]

Namaste Theo,

I apologize for reincarnating this thread.

> Sent: Friday, September 04, 2020 at 5:33 PM
> From: "Theo de Raadt" 
> To: "Tommy Nevtelen" 
> Cc: misc@openbsd.org
> Subject: Re: pf.conf parser/lint
>
> Tommy Nevtelen  wrote:
> 
> > On 04/09/2020 18.07, Brian Brombacher wrote:
> > > Well, let’s say a Linter doesn’t exist and you can’t invest time to make 
> > > one.  Do you have a lower environment, mirror-exact ideally, to run tests 
> > > on the pre-receive hook?
> > >
> > > It’s an interesting issue you’re trying to solve ;)
> > >
> > I didn't say I can't invest time. I just wondered if somebody else
> > knew of a solution before would try to dabble with it.. I do have a
> > lab env where stuff could be run but it would be very
> > un-efficient.. also openbsds interface names are based on the drivers
> > so I can't try stuff out in virtual machines since the interface names
> > would differ. I guess I could do some macros for those and change them
> > but this would be overkill for what I want to achieve. Also I do have
> > a lot of different setups and setting up test machines all of them
> > would cost a ton of money which is not worth it. And not what I was
> > after.
> 
> Always put your interfaces into groups.  Identify based upon the groups.

In case there are more such simple rules of thumb, could you please
share them?

It always helps little volks like me to learn and improve. I learnt
about packet tagging/policy based filtering from the pf user's guide. I
now use policy based filtering extensively.

> 
> Yes it is terrible that we have driver names exposed!  We should just
> have eth1-20 etc, but if one of your hardware devices fails, all the
> subsequent ones will renumber, so their names change, and you have
> precisely the same problem of exposed driver names.
> 
> We provide over FIVE ways to identify ports without using the hardware
> driver names, but hey... this discussion is about the theory you can
> check overall behaviour of a system by ignoring the important parts.
> 
> 

Dhanyavaad,
ab
-|-|-|-|-|-|-|--

Re: pf.conf parser/lint

[Daniel Ouellet]

> We provide over FIVE ways to identify ports without using the hardware
> driver names, but hey... this discussion is about the theory you can
> check overall behaviour of a system by ignoring the important parts.

I always put a description and group field in my hostname config so that
it allow me to have pf use a more generic syntax and it's been doing
wonder for me for years.

But you said 5 ways? This is most likely a stupid question, but what
other way is there? I don't mean to be sound like a jerk, I am truly
curious as I don't know 5 ways for sure, and i sure would love to learn
them.

Thanks

Daniel

Re: pf.conf parser/lint

[Theo de Raadt]

Tommy Nevtelen  wrote:

> On 04/09/2020 18.07, Brian Brombacher wrote:
> > Well, let’s say a Linter doesn’t exist and you can’t invest time to make 
> > one.  Do you have a lower environment, mirror-exact ideally, to run tests 
> > on the pre-receive hook?
> >
> > It’s an interesting issue you’re trying to solve ;)
> >
> I didn't say I can't invest time. I just wondered if somebody else
> knew of a solution before would try to dabble with it.. I do have a
> lab env where stuff could be run but it would be very
> un-efficient.. also openbsds interface names are based on the drivers
> so I can't try stuff out in virtual machines since the interface names
> would differ. I guess I could do some macros for those and change them
> but this would be overkill for what I want to achieve. Also I do have
> a lot of different setups and setting up test machines all of them
> would cost a ton of money which is not worth it. And not what I was
> after.

Always put your interfaces into groups.  Identify based upon the groups.

Yes it is terrible that we have driver names exposed!  We should just
have eth1-20 etc, but if one of your hardware devices fails, all the
subsequent ones will renumber, so their names change, and you have
precisely the same problem of exposed driver names.

We provide over FIVE ways to identify ports without using the hardware
driver names, but hey... this discussion is about the theory you can
check overall behaviour of a system by ignoring the important parts.

Re: pf.conf parser/lint

[Tommy Nevtelen]

On 04/09/2020 18.07, Brian Brombacher wrote:

Well, let’s say a Linter doesn’t exist and you can’t invest time to make one.  
Do you have a lower environment, mirror-exact ideally, to run tests on the 
pre-receive hook?

It’s an interesting issue you’re trying to solve ;)

I didn't say I can't invest time. I just wondered if somebody else knew 
of a solution before would try to dabble with it.. I do have a lab env 
where stuff could be run but it would be very un-efficient.. also 
openbsds interface names are based on the drivers so I can't try stuff 
out in virtual machines since the interface names would differ. I guess 
I could do some macros for those and change them but this would be 
overkill for what I want to achieve. Also I do have a lot of different 
setups and setting up test machines all of them would cost a ton of 
money which is not worth it. And not what I was after.


We do have a simple script in place that checks for some keywords now 
which I would like to expand that's all.


/T

Re: pf.conf parser/lint

[Brian Brombacher]

> On Sep 4, 2020, at 12:03 PM, Tommy Nevtelen  wrote:
> 
> On 04/09/2020 17.40, Brian Brombacher wrote:
 On Sep 4, 2020, at 11:28 AM, Brian Brombacher  wrote:
>>> 
>>> 
 On Sep 4, 2020, at 10:51 AM, Tommy Nevtelen  wrote:
 
 Hi there misc!
 
 Is there an external pfctl linter? we have bunch pf firwalls for which we 
 generate rules but also write some manual ones that get merged. Would be 
 nice if we could lint the rules before committed to vcs.. (yes we test 
 before they are applied on the machines as well but that is way too late 
 in a sane pipeline imho)
>> Sane pipeline... :)
>> 
>> Developer machine: can that securely run pfctl -n?  Linter is great... but 
>> there’s a ton more involved.
> 
> Don't get too caught up on my wording :)
> 
> What is the ton that would be involved?
> 
> It would be to catch the most stupid typo/syntax issues not to check if the 
> full config is valid on a specific machine.
> 
> My more exact use case would be a pre-recieve hook or a check before merging 
> to the production branch.
> 

Well, let’s say a Linter doesn’t exist and you can’t invest time to make one.  
Do you have a lower environment, mirror-exact ideally, to run tests on the 
pre-receive hook?

It’s an interesting issue you’re trying to solve ;)


> 
> /T
> 
> 

Re: pf.conf parser/lint

[Theo de Raadt]

Tommy Nevtelen  wrote:

> On 04/09/2020 17.24, Brian Brombacher wrote:
> >
> >> On Sep 4, 2020, at 10:51 AM, Tommy Nevtelen  wrote:
> >>
> >> Hi there misc!
> >>
> >> Is there an external pfctl linter? we have bunch pf firwalls for which we 
> >> generate rules but also write some manual ones that get merged. Would be 
> >> nice if we could lint the rules before committed to vcs.. (yes we test 
> >> before they are applied on the machines as well but that is way too late 
> >> in a sane pipeline imho)
> >>
> >> Problem is that pfctl expects that all interfaces and everything is 
> >> correct (which makes sense for pfctl before loading). BUT it is hard to 
> >> run on a build machine or my laptop to get a general idea on where I'm at 
> >> (unless I'm missing some tricks somewhere)
> >>
> > Can the build machine securely request each server run pfctl -n -f 
> > temp_config ?
> >
> > That would verify it’ll load for sure on said server.
> 
> This would not be practical for many reasons and is exactly what I
> want to avoid doing hence the original question.

As a test becomes more synthetic, predicting operation in reality becomes
quite poor.

I get a feeling that most pf configuration errors are related to
unexpected flows in/out of interfaces, and you suggest a grammer checker
which is ignorant of interface configuration.

It won't go well.

Re: pf.conf parser/lint

[Tommy Nevtelen]

On 04/09/2020 17.40, Brian Brombacher wrote:

On Sep 4, 2020, at 11:28 AM, Brian Brombacher  wrote:



On Sep 4, 2020, at 10:51 AM, Tommy Nevtelen  wrote:

Hi there misc!

Is there an external pfctl linter? we have bunch pf firwalls for which we 
generate rules but also write some manual ones that get merged. Would be nice 
if we could lint the rules before committed to vcs.. (yes we test before they 
are applied on the machines as well but that is way too late in a sane pipeline 
imho)

Sane pipeline... :)

Developer machine: can that securely run pfctl -n?  Linter is great... but 
there’s a ton more involved.


Don't get too caught up on my wording :)

What is the ton that would be involved?

It would be to catch the most stupid typo/syntax issues not to check if 
the full config is valid on a specific machine.


My more exact use case would be a pre-recieve hook or a check before 
merging to the production branch.



/T

Re: pf.conf parser/lint

[Tommy Nevtelen]

On 04/09/2020 17.24, Brian Brombacher wrote:



On Sep 4, 2020, at 10:51 AM, Tommy Nevtelen  wrote:

Hi there misc!

Is there an external pfctl linter? we have bunch pf firwalls for which we 
generate rules but also write some manual ones that get merged. Would be nice 
if we could lint the rules before committed to vcs.. (yes we test before they 
are applied on the machines as well but that is way too late in a sane pipeline 
imho)

Problem is that pfctl expects that all interfaces and everything is correct 
(which makes sense for pfctl before loading). BUT it is hard to run on a build 
machine or my laptop to get a general idea on where I'm at (unless I'm missing 
some tricks somewhere)


Can the build machine securely request each server run pfctl -n -f temp_config ?

That would verify it’ll load for sure on said server.


This would not be practical for many reasons and is exactly what I want 
to avoid doing hence the original question.


/T

Re: pf.conf parser/lint

[Brian Brombacher]

> On Sep 4, 2020, at 11:28 AM, Brian Brombacher  wrote:
> 
> 
> 
>> On Sep 4, 2020, at 10:51 AM, Tommy Nevtelen  wrote:
>> 
>> Hi there misc!
>> 
>> Is there an external pfctl linter? we have bunch pf firwalls for which we 
>> generate rules but also write some manual ones that get merged. Would be 
>> nice if we could lint the rules before committed to vcs.. (yes we test 
>> before they are applied on the machines as well but that is way too late in 
>> a sane pipeline imho)

Sane pipeline... :)

Developer machine: can that securely run pfctl -n?  Linter is great... but 
there’s a ton more involved.

>> 
>> Problem is that pfctl expects that all interfaces and everything is correct 
>> (which makes sense for pfctl before loading). BUT it is hard to run on a 
>> build machine or my laptop to get a general idea on where I'm at (unless I'm 
>> missing some tricks somewhere)
>> 
> 
> Can the build machine securely request each server run pfctl -n -f 
> temp_config ?
> 
> That would verify it’ll load for sure on said server.
> 
>> So I've been looking into parse.y in pfctl. It's been a long time since I've 
>> messed around with very simple yacc stuff so kind of lost.
>> 
>> Has anyone done anything like this? Would be good to know before I sink more 
>> time into this (and probably fail) :)
>> 
>> /T
>> 
> 

Re: pf.conf parser/lint

[Brian Brombacher]

> On Sep 4, 2020, at 10:51 AM, Tommy Nevtelen  wrote:
> 
> Hi there misc!
> 
> Is there an external pfctl linter? we have bunch pf firwalls for which we 
> generate rules but also write some manual ones that get merged. Would be nice 
> if we could lint the rules before committed to vcs.. (yes we test before they 
> are applied on the machines as well but that is way too late in a sane 
> pipeline imho)
> 
> Problem is that pfctl expects that all interfaces and everything is correct 
> (which makes sense for pfctl before loading). BUT it is hard to run on a 
> build machine or my laptop to get a general idea on where I'm at (unless I'm 
> missing some tricks somewhere)
> 

Can the build machine securely request each server run pfctl -n -f temp_config ?

That would verify it’ll load for sure on said server.

> So I've been looking into parse.y in pfctl. It's been a long time since I've 
> messed around with very simple yacc stuff so kind of lost.
> 
> Has anyone done anything like this? Would be good to know before I sink more 
> time into this (and probably fail) :)
> 
> /T
> 

Re: pf.conf parser/lint

[Sven F.]

On Fri, Sep 4, 2020 at 10:51 AM Tommy Nevtelen  wrote:
>
> Hi there misc!
>
> Is there an external pfctl linter? we have bunch pf firwalls for which
> we generate rules but also write some manual ones that get merged. Would
> be nice if we could lint the rules before committed to vcs.. (yes we
> test before they are applied on the machines as well but that is way too
> late in a sane pipeline imho)
>
> Problem is that pfctl expects that all interfaces and everything is
> correct (which makes sense for pfctl before loading). BUT it is hard to
> run on a build machine or my laptop to get a general idea on where I'm
> at (unless I'm missing some tricks somewhere)
>
> So I've been looking into parse.y in pfctl. It's been a long time since
> I've messed around with very simple yacc stuff so kind of lost.
>
> Has anyone done anything like this? Would be good to know before I sink
> more time into this (and probably fail) :)
>
> /T
>

I wonder if you plug the BNF at the end of the man to something like
https://github.com/josephwecker/autohighlight
if you can have a 'linter'

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

pf.conf parser/lint

[Tommy Nevtelen]

Hi there misc!

Is there an external pfctl linter? we have bunch pf firwalls for which 
we generate rules but also write some manual ones that get merged. Would 
be nice if we could lint the rules before committed to vcs.. (yes we 
test before they are applied on the machines as well but that is way too 
late in a sane pipeline imho)


Problem is that pfctl expects that all interfaces and everything is 
correct (which makes sense for pfctl before loading). BUT it is hard to 
run on a build machine or my laptop to get a general idea on where I'm 
at (unless I'm missing some tricks somewhere)


So I've been looking into parse.y in pfctl. It's been a long time since 
I've messed around with very simple yacc stuff so kind of lost.


Has anyone done anything like this? Would be good to know before I sink 
more time into this (and probably fail) :)


/T