pf.conf parser/lint

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

Re: pf.conf parser/lint

Sven F.
On Fri, Sep 4, 2020 at 10:51 AM Tommy Nevtelen <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: pf.conf parser/lint

Brian Brombacher
In reply to this post by Tommy Nevtelen


> On Sep 4, 2020, at 10:51 AM, Tommy Nevtelen <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: pf.conf parser/lint

Brian Brombacher
In reply to this post by Brian Brombacher


> On Sep 4, 2020, at 11:28 AM, Brian Brombacher <[hidden email]> wrote:
>
> 
>
>> On Sep 4, 2020, at 10:51 AM, Tommy Nevtelen <[hidden email]> 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
>>
>

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:
>>
>>
>>> On Sep 4, 2020, at 10:51 AM, Tommy Nevtelen <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: pf.conf parser/lint

Theo de Raadt-2
In reply to this post by Tommy Nevtelen
Tommy Nevtelen <[hidden email]> wrote:

> On 04/09/2020 17.24, Brian Brombacher wrote:
> >
> >> On Sep 4, 2020, at 10:51 AM, Tommy Nevtelen <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: pf.conf parser/lint

Brian Brombacher
In reply to this post by Tommy Nevtelen


> On Sep 4, 2020, at 12:03 PM, Tommy Nevtelen <[hidden email]> wrote:
>
> On 04/09/2020 17.40, Brian Brombacher wrote:
>>>> On Sep 4, 2020, at 11:28 AM, Brian Brombacher <[hidden email]> wrote:
>>>
>>>
>>>> On Sep 4, 2020, at 10:51 AM, Tommy Nevtelen <[hidden email]> 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
>
>

Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

Re: pf.conf parser/lint

Theo de Raadt-2
Tommy Nevtelen <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

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