[TuxFrw-devel] Welcome !!!

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

Dear Developers,

I would like to please all the people that have helped in TuxFrw project =
and=20
to apologize not to be present in the list and one of the reasons is that=
 I=20
am performing my english and thus Sr. Marcelo de Souza have given me all =
that=20
happened in this list.
I would like to say I will be even not to participate.=20
I thank you more time for the help that you have provided to this project=
=2E

Best Regards,

--=20
Marcelo Gondim da Cunha
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Databras Inform=E1tica
Ger=EAncia - Manager
ICQ 114063253
Linux Counter User #56135

Em Sex 31 Mai 2002 11:51, Marcelo de Souza escreveu:
> 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, creati=
ng
> a "stable" set of configuration files and rules. So, as soon as we fini=
sh
> 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.=20
> > 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 modifi=
ed
> > 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) th=
at
> > 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=3D"2.17">
> >   <module id=3D"INT2EXT"
> >     enable=3D"IsInterfaceEnabled(INT) &&
> >                     IsInterfaceEnabled(EXT) &&
> >                     IsModuleOn($ModuleName)"/>
> >       <rule id=3D"1000"
> >            description=3D"Create INT2EXT chain"
> >            order=3D"AlwayFirst"
> >           dependencies=3D""
> >        />
> >       -N INT2EXT
> >       <rule/>
> >
> >       <rule id=3D"2000"
> >         description=3D"Accept http" order=3D""
> >         enable=3D"yes"
> >         dependecies=3D""
> >       />
> >       -A INT2EXT -p tcp -m multiport --dport http,https -j ACCEPT
> >       <rule/>
> >
> >       <rule id=3D"3000"
> >        description=3D"Accept Mail"
> >        order=3D""
> >        enable=3D"yes"
> >        dependecies=3D""
> >      />
> >       -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 modul=
e
> > - for each rule, there could be
> >      --> a version number
> >     --> a revised date
> >    --> enable ...
> >    --> dependencies rules (this rule can be applied only if this othe=
r
> > 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 rule=
s.
> >
> > 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 rule=
s.
> >
> > 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.cf=
m
> >
> > _______________________________________________
> > 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