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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

> Hi,

Hello,

> 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 ?.

Sure thing! This is great! It's a good way to separate customized rules from 
TF default ones. That can certainly  be implemented. 

> 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 ?

Uhm, try to follow the same way we code, and post your changes to the mail 
list itself. Don't worry about this, but certainly we need to use some other 
kind of distributed/cooperated development system. CVS!!!

> Bye !

Good 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
> >
> 

------------------------------------------------------------ 
   - 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