[TuxFrw-devel] Re: Firewall update and firewall install

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi,

yes you are right.

But ! it would be interesting that in the new version there would be a way
to insert user rules in the firewall.  We could for exemple call a user
function for each tf function.  For exemple the tf  create_DMZ2EXT_rules
could call a user defined fonction called create_user_DMZ2EXT_rules just
before we branch to to END_DMZ2EXT.  The tf could come with empty default
empty user function that would allow personnal configuration.  There would
be a user fonction for each tf function

What do you think ?.

If  have new code to propose to the team for the firewall assistant, how to
send you this code ? I also, like to propose new code for interface
ip/network/netmask detection that reside in the /etc/tuxfrw/tuxfrw.conf
file. How do i proceed ?

Bye !

Jean Jacques Gervais
----- Original Message -----
From: "Marcelo de Souza" <ma...@ac...>
To: "Jean Jacques Gervais" <jj...@in...>
Cc: "tuxfrw-development" <tux...@li...>
Sent: Friday, May 31, 2002 10:51 AM
Subject: Re: [TuxFrw-devel] Firewall update and firewall install

>
> Hi,
>
> certainly this is a great idea. In fact, some time ago I thought about the
> use of XML as a structural model for TF rules, but only in a "distant
future".
>
> Well, we really can think about some way of using XML to do this, but I
think
> it could be into 3.x versions only. Let's keep things simpler now, and
live
> the more "complex ideas" to future branches...
>
> Right now I think we should find a way to "finalize" 2.x series, creating
> a "stable" set of configuration files and rules. So, as soon as we finish
> this, we could lead towards our most desired features...
>
> This is my opinion. What do u think?
>
> > Hi,
> >
> > I am trying to figure out a  way that would allow us to upgrade tf.
Actualy
> >
> > there is no way to preserve users modifications.
> >
> > I think we should have a database of tf rules and a database of users
rules.
> >
> > This would allow us to install a new version of tf without disturbing
actual
> >
> > tf rules.  The new rules (that are coming with the upgrade) or modified
> > rules
> > could be validated with the user before they are apply to the main
database
> >
> > rules.
> >
> > We would have a user interface that would alllow us to manage these
rules.
> > We
> > could even think of a graphical user interface (web base like php) that
> > would
> > allow an administrator to manage multiple firewall database rules.
> >
> > The database rules could be a xml database.
> >
> > The format of the xml file, could be something like:
> >
> > <firewall modified"20020530" version="2.17">
> >   <module id="INT2EXT"
> >     enable="IsInterfaceEnabled(INT) &&
> >                     IsInterfaceEnabled(EXT) &&
> >                     IsModuleOn($ModuleName)"/>
> >       <rule id="1000"
> >            description="Create INT2EXT chain"
> >            order="AlwayFirst"
> >           dependencies=""
> >        />
> >       -N INT2EXT
> >       <rule/>
> >
> >       <rule id="2000"
> >         description="Accept http" order=""
> >         enable="yes"
> >         dependecies=""
> >       />
> >       -A INT2EXT -p tcp -m multiport --dport http,https -j ACCEPT
> >       <rule/>
> >
> >       <rule id="3000"
> >        description="Accept Mail"
> >        order=""
> >        enable="yes"
> >        dependecies=""
> >      />
> >       -A INT2EXT -p tcp -m multiport --dport smtp,pop-3 -j ACCEPT"
> >       <rule/>
> > ....
> >   </module>
> > </firewall>
> >
> > The information containt in the xml file would be:
> >
> >  - tux firewall  rules version
> > - modules rules and dependencies
> >  -the firewall rules group by module
> > - each rule would be identified by a unique idenfitier within a module
> > - for each rule, there could be
> >      --> a version number
> >     --> a revised date
> >    --> enable ...
> >    --> dependencies rules (this rule can be applied only if this other
rule
> > is
> > also applied, if this interface is enable, if this flag is  on or off,
base
> >
> > on the state of another rule ...)
> >   --> ordering rules:  always first, always last, must follow rule n,
before
> >
> > rule n...
> >   --> a comment
> >
> >
> > The tux modules would be genarated by taking the tf rules + user rules.
> >
> > On the first TF install, everything should be disable.  Then the user
could
> >
> > allow to open fonctionality.   The firewall assistant would allow to
enable
> >
> > or disable rules, add new rules, replace tf rules in the user rule
database
> >
> > and generate the new firewall scripts based on tf rules and user rules.
> >
> > What do you think ?
> >
> > Jean Jacques Gervais
> >
> >
> >
> >
> > _______________________________________________________________
> >
> > Don't miss the 2002 Sprint PCS Application Developer's Conference
> > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> >
> > _______________________________________________
> > TuxFrw-devel mailing list
> > Tux...@li...
> > https://lists.sourceforge.net/lists/listinfo/tuxfrw-devel
> >
>
>
> ------------------------------------------------------------
>    - MARCELO DE SOUZA -            <ma...@ac...>
>
>    Computer Science / UNESP - S. J. Rio Preto, SP, Brazil
>
>          -- ACME! Computer Security Research --
>
>             http://www.acme-ids.org/~marcelo
> ------------------------------------------------------------
>
>
> -------------------------------------------------
>        ACME! Computer Security Research
>            http://www.acme-ids.org
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> TuxFrw-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxfrw-devel
>