SEO

Hi,

I would like to hear demand from needing a PF CLI, this is going to be
much more powerful than pfctl. It will be using OO Command Pattern with
direct access pf's ioctl API to implement the idea. If anyone of you see
the usefulness of this idea, please drop me a line. This is going to be
an open source with BSD license for PF.

Thanks
Sam

On 22/02/2005 6:46 AM, sam wrote:

> I would like to hear demand from needing a PF CLI, this is going to be
> much more powerful than pfctl. It will be using OO Command Pattern with
> direct access pf's ioctl API to implement the idea. If anyone of you see
> the usefulness of this idea, please drop me a line. This is going to be
> an open source with BSD license for PF.
>

Interesting. I have no idea what I would do with such a thing, myself.
I see PF as sort of a "fire and forget" thing. Only the occasional
tweak is ever required on my node. Obviously, pfctl fills this need
quite well.

What problem would this solve for you or others? I'm curious.

On Tue, 22 Feb 2005 12:08:01 -0500 in <RFJSd.91884$vO1.574283@nnrp1.uunet.ca> clvrmnky <clvrmnky-uunet@coldmail.com.invalid> wrote:
>
> Interesting. I have no idea what I would do with such a thing, myself.
> I see PF as sort of a "fire and forget" thing. Only the occasional
> tweak is ever required on my node. Obviously, pfctl fills this need
> quite well.
>
> What problem would this solve for you or others? I'm curious.

Sniffer/IDS driven pf rulesets.

What I don't understand is why a command line tool as opposed to
using the PF APIs directly, or providing such access in perl, python,
or lisp bindings.
The latter would seem to be more useful, especially if a DBD/DBI
style approach was taken to embrace other firewall solutions.
--
Chris Dukes
Suspicion breeds confidance -- Brazil

pakrat@localhost.private.neotoma.org wrote:
> [..]
> What I don't understand is why a command line tool as opposed to
> using the PF APIs directly, or providing such access in perl, python,
> or lisp bindings.

After the PyOpenBSD was posted on undeadly.org I thought the same,
specially after a person remarked in a comment that it'd be more useful if
it were written in Perl since Perl is in the base system while Python is
not. I read a little bit about Perl modules but had to give up to write an
pf Perl module since I don't really have any experience in Perl.

Regards,
j.

pakrat@localhost.private.neotoma.org wrote:

> On Tue, 22 Feb 2005 12:08:01 -0500 in <RFJSd.91884$vO1.574283@nnrp1.uunet.ca> clvrmnky <clvrmnky-uunet@coldmail.com.invalid> wrote:
>
>>Interesting. I have no idea what I would do with such a thing, myself.
>> I see PF as sort of a "fire and forget" thing. Only the occasional
>>tweak is ever required on my node. Obviously, pfctl fills this need
>>quite well.
>>
>>What problem would this solve for you or others? I'm curious.
>
The very basic feature of this pf cli is that it can take care of most
of the filtering rule syntax, eg. put nat/rdr before all filtering
rules, add flags S/SA keep state for all tcp, default to block all first
before all "pass" rules, default to block finger printing scan, build
classification of rules and each classification/table is written to a
seperate rule file, etc...
Another feature is to build an easy interface for configuring CARP,
pfsyn as well.


Sam
>
> Sniffer/IDS driven pf rulesets.
>
> What I don't understand is why a command line tool as opposed to
> using the PF APIs directly, or providing such access in perl, python,
> or lisp bindings.
> The latter would seem to be more useful, especially if a DBD/DBI
> style approach was taken to embrace other firewall solutions.

On Wed, 23 Feb 2005 10:51:24 +0800 in <cvgsi9$2pst$1@news.hgc.com.hk> sam <sam.wun@authtec.com> wrote:
> pakrat@localhost.private.neotoma.org wrote:
>>
> The very basic feature of this pf cli is that it can take care of most
> of the filtering rule syntax, eg. put nat/rdr before all filtering
> rules, add flags S/SA keep state for all tcp, default to block all first
> before all "pass" rules, default to block finger printing scan, build
> classification of rules and each classification/table is written to a
> seperate rule file, etc...

Sounds point and grunt to me.

> Another feature is to build an easy interface for configuring CARP,
> pfsyn as well.

Sounds point and grunt to me.
And if it's point and grunt, wouldn't be a bad idea to make it easy
to slap a GUI on it and an insane policy management system (So
financial institutions can create monstrosities with it).

It's been my experience that such programmers can sometimes grasp a
documented library (or object class). They'll botch generating command lines.


--
Chris Dukes
Suspicion breeds confidance -- Brazil

On Wed, 23 Feb 2005 17:54:22 GMT, pakrat@localhost.private.neotoma.org
wrote:


>
>Sounds point and grunt to me.

Quite.

>
>> Another feature is to build an easy interface for configuring CARP,
>> pfsyn as well.
>
>Sounds point and grunt to me.
>And if it's point and grunt,

Noting how one can configure/examine VRRP under IPSO from both voyager and
& iclid may be intuitive.


> wouldn't be a bad idea to make it easy
>to slap a GUI on it and an insane policy management system (So
>financial institutions can create monstrosities with it).

The joys of living with changement management policies from hell.

>It's been my experience that such programmers can sometimes grasp a
>documented library (or object class). They'll botch generating command lines.

You've been using IPTables again, havent you.
--
Yeah - straight from the top of my dome
As I rock, rock, rock, rock, rock the microphone

On 2005-02-22, pakrat@localhost.private.neotoma.org <pakrat@localhost.private.neotoma.org> wrote:
> What I don't understand is why a command line tool as opposed to
> using the PF APIs directly, or providing such access in perl, python,
> or lisp bindings.
> The latter would seem to be more useful, especially if a DBD/DBI
> style approach was taken to embrace other firewall solutions.

A Perl module that encapsulates all the ioctl calls would be quite
useful indeed, and allow admins to quickly and easily make powerful
custom CLI programs, or some daemon that manipulates firewall rules
dynamically...

Not sure exactly what you mean about the DBD/DBI model though. Unless
you mean this module could work for Linux iptables too. But there
already exist Perl modules for that on CPAN. It could be done, but
there's a major downside: Linux is constantly changing their firewall
implementation every stable release. It'd be a real pain to track
that. One reason I moved to obsd was I got tired of the rug always
getting pulled from under my feet...

On Tue, 01 Mar 2005 20:45:27 GMT in <Hv4Vd.20429$Q47.4362@bignews5.bellsouth.net> gargoyle <gargoyle@no.spam> wrote:
> On 2005-02-22, pakrat@localhost.private.neotoma.org <pakrat@localhost.private.neotoma.org> wrote:
>> What I don't understand is why a command line tool as opposed to
>> using the PF APIs directly, or providing such access in perl, python,
>> or lisp bindings.
>> The latter would seem to be more useful, especially if a DBD/DBI
>> style approach was taken to embrace other firewall solutions.
>
> A Perl module that encapsulates all the ioctl calls would be quite
> useful indeed, and allow admins to quickly and easily make powerful
> custom CLI programs, or some daemon that manipulates firewall rules
> dynamically...
>
> Not sure exactly what you mean about the DBD/DBI model though. Unless
> you mean this module could work for Linux iptables too. But there
> already exist Perl modules for that on CPAN. It could be done, but
> there's a major downside: Linux is constantly changing their firewall
> implementation every stable release. It'd be a real pain to track
> that. One reason I moved to obsd was I got tired of the rug always
> getting pulled from under my feet...


I'm going to pretend for the moment that you aren't an OS bigot that's
busy talking out of his ass.[1]

DBI provides a database independent interface to several SQL servers,
flat files, and a host of disgusting weird things. The glue to a
specific backend is through DBD.

Like it or not, OpenBSD's PF is not the only game in town.
There is Linux's iptables, ipf on NetBSD and Solaris,
PIX, check point... There are also proxies and content filters.

And like it or not, some organizations do unholy mixtures of all
of the above.

Providing just a tool to turn pf into a point and grunt
ipchains, is probably the wrong approach.

Providing a first stab at a platform neutral (But first backend
implementation for OpenBSD) way to apply and modify firewall
policy including redundant configurations would be a good next step.

A platform neutral way to evaluate firewall policy and analyze
for implementation specific coverage gaps would be an excellent
extension of the concept.

[1] Because you seem to have forgotten about the ipf/pf incident as well
as the matter that iptables has persisted from linux 2.4 to linux 2.6.
As well as utterly lack clue as to the point of DBI/DBD.

--
Chris Dukes
Suspicion breeds confidence -- Brazil