tuxfrw-devel

[TuxFrw-devel] Firewall update and firewall install

[Jean J. G. <jj...@in...>]

Hi,=20

I am trying to figure out a  way that would allow us to upgrade tf.  Actu=
aly=20
there is no way to preserve users modifications. =20

I think we should have a database of tf rules and a database of users rul=
es. =20
This would allow us to install a new version of tf without disturbing act=
ual=20
tf rules.  The new rules (that are coming with the upgrade) or modified r=
ules=20
could be validated with the user before they are apply to the main databa=
se=20
rules.

We would have a user interface that would alllow us to manage these rules=
=2E  We=20
could even think of a graphical user interface (web base like php) that w=
ould=20
allow an administrator to manage multiple firewall database rules.

The database rules could be a xml database. =20

The format of the xml file, could be something like:

<firewall modified"20020530" version=3D"2.17">
  <module id=3D"INT2EXT"=20
    enable=3D"IsInterfaceEnabled(INT) &&=20
                    IsInterfaceEnabled(EXT) &&=20
                    IsModuleOn($ModuleName)"/>
      <rule id=3D"1000"=20
           description=3D"Create INT2EXT chain"=20
           order=3D"AlwayFirst"=20
          dependencies=3D""
       />
      -N INT2EXT
      <rule/>

      <rule id=3D"2000"=20
        description=3D"Accept http" order=3D""=20
        enable=3D"yes"=20
        dependecies=3D""
      />
      -A INT2EXT -p tcp -m multiport --dport http,https -j ACCEPT
      <rule/>

      <rule id=3D"3000"=20
       description=3D"Accept Mail"=20
       order=3D""=20
       enable=3D"yes"=20
       dependecies=3D""=20
     />
      -A INT2EXT -p tcp -m multiport --dport smtp,pop-3 -j ACCEPT"
      <rule/>
=2E...
  </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=20
     --> a version number
    --> a revised date
   --> enable ...
   --> dependencies rules (this rule can be applied only if this other ru=
le is=20
also applied, if this interface is enable, if this flag is  on or off, ba=
se=20
on the state of another rule ...)
  --> ordering rules:  always first, always last, must follow rule n, bef=
ore=20
rule n...
  --> a comment


The tux modules would be genarated by taking the tf rules + user rules. =20

On the first TF install, everything should be disable.  Then the user cou=
ld=20
allow to open fonctionality.   The firewall assistant would allow to enab=
le=20
or disable rules, add new rules, replace tf rules in the user rule databa=
se=20
and generate the new firewall scripts based on tf rules and user rules.

What do you think ?

Jean Jacques Gervais

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

[Marcelo de S. <ma...@ac...>]

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

[TuxFrw-devel] Welcome !!!

[Marcelo G. <go...@da...>]

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

Re: [TuxFrw-devel] Welcome !!!

[Marcelo de S. <ma...@ac...>]

Hi all,

I'm here to prove you that Mr. Gondim is right. Although he doesn't 
participate in this list too often, he knows everything that happens, cause I 
forward him additional info. Actually, we keep talking (by e-mails) 
constantly, and he's aware of all the info that happens here.

Don't worry Mr. Gondim. :-)

Regards,


> Dear Developers,
> 
> I would like to please all the people that have helped in TuxFrw project and
> to apologize not to be present in the list and one of the reasons is that I
> am performing my english and thus Sr. Marcelo de Souza have given me all
> that 
> happened in this list.
> I would like to say I will be even not to participate. 
> I thank you more time for the help that you have provided to this project.
> 
> Best Regards,
> 
> -- 
> Marcelo Gondim da Cunha


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

[TuxFrw-devel] Re: Welcome !!!

[<jj...@in...>]

Hello, Bonjour !

This is not a problem, i can understand that quite well.  I am in the sam=
e
situation.  It take a lot of effort from my part to write in english.  Si=
nce
my portuguese is probably equivalent to your french, i guess we will stil=
l
have to communicate in english.  English is the esperento of the new
millenium ...  So you do not have to apologize.

I think that tf is a great tool and i will be glad if i can help.

I am happy to hear from you.

Goodbye !

Jean Jacques Gervais
Les consultants INTERACTION
----- Original Message -----
From: "Marcelo Gondim" <go...@da...>
To: "tuxfrw-development" <tux...@li...>
Sent: Friday, May 31, 2002 4:02 PM
Subject: [TuxFrw-devel] Welcome !!!


> Dear Developers,
>
> I would like to please all the people that have helped in TuxFrw projec=
t
and
> to apologize not to be present in the list and one of the reasons is th=
at
I
> am performing my english and thus Sr. Marcelo de Souza have given me al=
l
that
> happened in this list.
> I would like to say I will be even not to participate.
> I thank you more time for the help that you have provided to this proje=
ct.
>
> Best Regards,
>
> --
> 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 abou=
t
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 n=
ow,
> > 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 use=
rs
> > > rules.
> > >
> > > This would allow us to install a new version of tf without disturbi=
ng
> > > 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=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 mod=
ule
> > > - for each rule, there could be
> > >      --> a version number
> > >     --> a revised date
> > >    --> enable ...
> > >    --> dependencies rules (this rule can be applied only if this ot=
her
> > > rule is
> > > also applied, if this interface is enable, if this flag is  on or o=
ff,
> > > 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 us=
er
> > > could
> > >
> > > allow to open fonctionality.   The firewall assistant would allow t=
o
> > > 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.cf=
m
> >
> > _______________________________________________
> > TuxFrw-devel mailing list
> > Tux...@li...
> > https://lists.sourceforge.net/lists/listinfo/tuxfrw-devel
>
>
>
> _______________________________________________________________
>
> 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
>

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

[<jj...@in...>]

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
>

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

[Marcelo de S. <ma...@ac...>]

> 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