Re: Demand of PF CLI

pakrat_at_localhost.private.neotoma.org
Date: 03/02/05

  • Next message: Will: "Hardware RAID for OpenBSD" 
    Date: Wed, 02 Mar 2005 04:05:09 GMT

    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
  • Next message: Will: "Hardware RAID for OpenBSD"