tuxfrw-devel — TuxFrw development-related discussion list

[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] TF 2.16-pre2

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

Hi all,

I've made my latest aditions available in the TF packet attached  (TF 2.16-
pre2). Take a look on them...

BTW, I think these will be my latest additions these month, as I'm really 
overloaded with my college tasks... Please be patient if you contact me and I 
don't answer quickly. I'll try to make myself available for TF questions by 
the end of June. I'm sure you can take on without me... :-)

Good bye, and good luck with TF!!!

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

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: 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] 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] 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] 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] Re: TuxFrw 2.16-pre1...

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

Hi again Jean, (and the other too!)

> Hi Mr. de Souza,
> 
> > Hello Jean! (excuse me to call you so...)
> >
> 
> Go ahead. It's my name ...

Thanks

> 
> > Your idea is great! You're certainly on the right track, going toward
> the
> > same point as we are. Undoubtedly Perl brings the power that we need to
> > make our scripts, and as we can see you manage the Perl language very
> well.
> >
> Great ! Well, I'am just starting in perl.  But i rely like this language. It
> 
> forces me to think differently.    When you do development in perl you have
> 
> to forget everything you know about programming.  All the pasted experiences
> 
> with software development has to be put away.  Your really have to think 
> differently.   That's is why I love perl.  
> 

Cool! I'd love to learn Perl too, but I have no time for this. Our 
University's library has just received some copies of a "Perl..." book from 
O'reilly, but I couldn't put my hands on them yet... :-(


> So i will go on with my tests.

Go ahead! You have all my support! But I hope they are not only tests, and 
become real stuff soon... just kidding! :-)

> 
> I would like to explore a way to diagnose the state of the machine that TF
> will run on.
> 
> Not only do we have the check for the linux version (2.4 and up), but we
> have 
> to check the state of the modules and the startup scripts/
> 
> - ipchains modules should not be loaded (lsmod ...)
> - the scripts  /etc/init.d/ipchains and  /etc/init.d/iptables should be 
> disabled (chkconfig ...)
> - we should ask the user if he wants to disabled these scripts before we go
> on 
> with the installation process

Yes, I agree with u.

> - we should ... i don know !

Nor do I!

> 
> > As you can see our intention is to create some sort of assistants that
> can
> > help creating the "tuxfrw.conf" files (and things like that). We should
> > focus on the development of that sort of scripts, not forgetting the
> base
> > TF rules, of course. This way, with a powerful configuration script we
> can
> > "fine tune" our "generic" set of rules into a customized one.
> >
> > Your contribution lead me to understand that you are really interested
> on
> > the "config" part of the software. This is great, and I think this could
> be
> > a "task" for you to take care of. To summarize, I'd really like to have
> > your help with this part of the work, as we'd be sending you the
> > "final/base" tuxfrw.conf file, and you could do the conf scripts to
> achieve
> > that file.
> >
> 
> Please do not think this is the only part i am interested in.  I do not
> realy 
> like installation script and user interface. For what i have seen so far, 
> your team has more experienced in firewall than i have.  You are more 
> qualified than i am to do this part of the job.  I just think this is the 
> part that i can be useful for.  The installation process and user interface
> just have to be done and i will be glad to help with these parts.  

Your affirmations are right. I don't like to spend my time with UIs 
too, 'cause they are really "boring" to code, and too much time consuming. But 
this works needs to be done, and that's the point where TF suffers (at this 
moment, at least).

All other developers/contributors have great skills in firewall design, so I 
think we are well served in this point. But as soon as the "missing parts" 
become ready (such as UI, config scripts), we can spend most part of our TF 
development time with "core netfiltering" .... Yeah, that's really cool!

> 
> What i realy like, is all the architecture related to the iptables.  So, I
> am 
> interested to help with all tasks related to the firewall.  I am facinated
> 
> with the iptables.   The guys that haved worked on this project (netfiler
> ..) 
> are very brillant.  I never seen anything like that.   Wow !

Me too!

> 
> Another thing that i am particulary interrested is dynamic firewall. 
> iptables 
> gives us the opportunity not only to build static firewall, but also dynamic
> 
> ones.  I would like to see a firewall capable of detecting an attach 
> (intrusion) and react to it in real time.  The log files could dynamically
> be 
> inspected and new rules added instantly.  If we are very ambitious and we 
> want to roll our sleeves up, iptables have some extentions that can be used
> 
> so packets can be inspected by user space ...

Well, I have some sort of experience with IDS systems myself, and I've been 
thinking about some sort of linking between IDS capabilities and iptables. 
Perhaps in the future we could make Snort work closer to TF. Isn't cool?

> 
> Another thin i am interested in is traffic control ...

Me too. And this is one of my "dreams" for TF future versions...

> 
> > Well... I know things are a little bit "dark" now, as we pass through a
> new
> > stage of development. This week I've been working heavily on TF to think
> > about a way to make users' life easier, and as you can see there it is
> (TF
> > 2.16-pre1 functionality). So, as I promised, I'll soon send some sort of
> > "road-map" to be followed by those who wanna help...
> 
> I'am there !
> 

Great!

> >
> > That's all.
> >
> > See you later...
> 
> See you ...

Good Bye!


------------------------------------------------------------ 
   - 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: TuxFrw 2.16-pre1...

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

Hi Mr. de Souza,

On Monday 27 May 2002 15:20, Marcelo de Souza wrote:
> Hello Jean! (excuse me to call you so...)
>

Go ahead. It's my name ...

> Your idea is great! You're certainly on the right track, going toward t=
he
> same point as we are. Undoubtedly Perl brings the power that we need to
> make our scripts, and as we can see you manage the Perl language very w=
ell.
>
Great ! Well, I'am just starting in perl.  But i rely like this language.=
 It=20
forces me to think differently.    When you do development in perl you ha=
ve=20
to forget everything you know about programming.  All the pasted experien=
ces=20
with software development has to be put away.  Your really have to think=20
differently.   That's is why I love perl. =20

So i will go on with my tests. =20

I would like to explore a way to diagnose the state of the machine that T=
F=20
will run on.

Not only do we have the check for the linux version (2.4 and up), but we =
have=20
to check the state of the modules and the startup scripts/

- ipchains modules should not be loaded (lsmod ...)
- the scripts  /etc/init.d/ipchains and  /etc/init.d/iptables should be=20
disabled (chkconfig ...)
- we should ask the user if he wants to disabled these scripts before we =
go on=20
with the installation process
- we should ... i don know !

> As you can see our intention is to create some sort of assistants that =
can
> help creating the "tuxfrw.conf" files (and things like that). We should
> focus on the development of that sort of scripts, not forgetting the ba=
se
> TF rules, of course. This way, with a powerful configuration script we =
can
> "fine tune" our "generic" set of rules into a customized one.
>
> Your contribution lead me to understand that you are really interested =
on
> the "config" part of the software. This is great, and I think this coul=
d be
> a "task" for you to take care of. To summarize, I'd really like to have
> your help with this part of the work, as we'd be sending you the
> "final/base" tuxfrw.conf file, and you could do the conf scripts to ach=
ieve
> that file.
>

Please do not think this is the only part i am interested in.  I do not r=
ealy=20
like installation script and user interface. For what i have seen so far,=
=20
your team has more experienced in firewall than i have.  You are more=20
qualified than i am to do this part of the job.  I just think this is the=
=20
part that i can be useful for.  The installation process and user interfa=
ce=20
just have to be done and i will be glad to help with these parts. =20

What i realy like, is all the architecture related to the iptables.  So, =
I am=20
interested to help with all tasks related to the firewall.  I am facinate=
d=20
with the iptables.   The guys that haved worked on this project (netfiler=
 ..)=20
are very brillant.  I never seen anything like that.   Wow !

Another thing that i am particulary interrested is dynamic firewall.  ipt=
ables=20
gives us the opportunity not only to build static firewall, but also dyna=
mic=20
ones.  I would like to see a firewall capable of detecting an attach=20
(intrusion) and react to it in real time.  The log files could dynamicall=
y be=20
inspected and new rules added instantly.  If we are very ambitious and we=
=20
want to roll our sleeves up, iptables have some extentions that can be us=
ed=20
so packets can be inspected by user space ...

Another thin i am interested in is traffic control ...

> Well... I know things are a little bit "dark" now, as we pass through a=
 new
> stage of development. This week I've been working heavily on TF to thin=
k
> about a way to make users' life easier, and as you can see there it is =
(TF
> 2.16-pre1 functionality). So, as I promised, I'll soon send some sort o=
f
> "road-map" to be followed by those who wanna help...

I'am there !

>
> That's all.
>
> See you later...

See you ...

Jean Jacques Gervais
>
> Quoting Jean Jacques Gervais <jj...@in...>:
> > Hi  all!
> >
> > I have looked  at install.sh and tuxfrw-config.sh and I think I can s=
ee
> > toward
> > what you are going.   I did some testing on my own, just to see what =
was
> > possible to do with perl.
> >
> > So I did a small perl script (test.pl) that is going in the same
> > direction as
> > tuxfrw-config.sh.  My test is more like a configuration assistant tha=
n an
> > installation assistant. My objective is just to see towards what we a=
re
> > heading  to and see what can be done with perl.
> >
> > In this test, i have:
> >
> > - reading tux configuration file to map tux variables to perl variabl=
es
> > - dig kernel information: am i root ?, kernel version,  release versi=
on,
> > host
> > name,  domain name ...
> > - interface detection
> > - a first menu structure
> > - showing actual tux configuration and kernel information
> >
> > I think it would be interresting that the installer and the assistant
> > would
> >
> > remember past answers from previous installation.   The assistant cou=
ld
> > read
> >
> > the tuxfrw.conf script, read in the actual values and give the user t=
he
> > opportunity to change the configuration.
> >
> > The assistant could verify the installation and help in TF upgrade.  =
The
> > installer could help in detecting and preventing configuration proble=
ms
> > (a
> >
> > ppp interface choosen as an the internal interface, the same interfac=
e
> > choosen twice ...).
> >
> > I my on the right track ?  What do we do now ?  Do you think it is
> > wortwhile
> >
> > to continue this test ?
> >
> > Jean Jacques Gervais
> >
> > p.s. Can you guys from Brazil send us some sun, it's cold in Montr=E9=
al.
> >
> > - On Friday 24 May 2002 16:29, Marcelo de Souza wrote:
> > > Hi all!
> > >
> > > I'd like to announce TF 2.16 pre release 1.
> > >
> > > There are lots of changes, specifically concerning TF structure. I
> >
> > haven't
> >
> > > made any changes to the iptables ruleset, only to the way TF is
> > > installed/configured/organized...
> > >
> > > I prefer to send u my developing notes later. By now u should try t=
o
> > > understand what I've done...
> > >
> > > This way I want to automate TF process even more, asking the user a=
bout
> >
> > the
> >
> > > profile of the network and its services.
> > >
> > > Well, that's all. I'll soon be sending some of my notes and a roadm=
ap
> >
> > for
> >
> > > the future...
> > >
> > > Bye!
>
> ------------------------------------------------------------
>    - 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] TuxFrw 2.x Development RoadMap

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

Hi all!

Finally I wrote down some of my ideas for the future of TF 2.x branch
(attachment). 

Please read them, and feel free to comment/suggest/disagree!!! 

I also would like to ask for those of you who wants to become real TF
developers (not just contributors), to sign up into our project space on
SourceForge (http://sourceforge.net/projects/tuxfrw/). As the project advances,
we should be more united, and have CVS as a tool too!

Well, that's all. Let me go back to TF development...

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

Re: [TuxFrw-devel] TuxFrw 2.16-pre1...

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

Hello Jean! (excuse me to call you so...)

Your idea is great! You're certainly on the right track, going toward the same
point as we are. Undoubtedly Perl brings the power that we need to make our
scripts, and as we can see you manage the Perl language very well.

As you can see our intention is to create some sort of assistants that can
help creating the "tuxfrw.conf" files (and things like that). We should focus
on the development of that sort of scripts, not forgetting the base TF rules,
of course. This way, with a powerful configuration script we can "fine tune"
our "generic" set of rules into a customized one.

Your contribution lead me to understand that you are really interested on the
"config" part of the software. This is great, and I think this could be a
"task" for you to take care of. To summarize, I'd really like to have your help
with this part of the work, as we'd be sending you the "final/base" tuxfrw.conf
file, and you could do the conf scripts to achieve that file.

Well... I know things are a little bit "dark" now, as we pass through a new
stage of development. This week I've been working heavily on TF to think about
a way to make users' life easier, and as you can see there it is (TF 2.16-pre1
functionality). So, as I promised, I'll soon send some sort of "road-map" to
be followed by those who wanna help...

That's all.

See you later...


Quoting Jean Jacques Gervais <jj...@in...>:

> Hi  all!
> 
> I have looked  at install.sh and tuxfrw-config.sh and I think I can see
> toward 
> what you are going.   I did some testing on my own, just to see what was 
> possible to do with perl.  
> 
> So I did a small perl script (test.pl) that is going in the same direction
> as 
> tuxfrw-config.sh.  My test is more like a configuration assistant than an 
> installation assistant. My objective is just to see towards what we are 
> heading  to and see what can be done with perl.
> 
> In this test, i have:
> 
> - reading tux configuration file to map tux variables to perl variables
> - dig kernel information: am i root ?, kernel version,  release version,
> host 
> name,  domain name ...
> - interface detection
> - a first menu structure
> - showing actual tux configuration and kernel information
> 
> I think it would be interresting that the installer and the assistant would
> 
> remember past answers from previous installation.   The assistant could read
> 
> the tuxfrw.conf script, read in the actual values and give the user the 
> opportunity to change the configuration.
> 
> The assistant could verify the installation and help in TF upgrade.  The 
> installer could help in detecting and preventing configuration problems (a
> 
> ppp interface choosen as an the internal interface, the same interface 
> choosen twice ...).
> 
> I my on the right track ?  What do we do now ?  Do you think it is wortwhile
> 
> to continue this test ?  
> 
> Jean Jacques Gervais
> 
> p.s. Can you guys from Brazil send us some sun, it's cold in Montréal.
> 
> - On Friday 24 May 2002 16:29, Marcelo de Souza wrote:
> > Hi all!
> >
> > I'd like to announce TF 2.16 pre release 1.
> >
> > There are lots of changes, specifically concerning TF structure. I
> haven't
> > made any changes to the iptables ruleset, only to the way TF is
> > installed/configured/organized...
> >
> > I prefer to send u my developing notes later. By now u should try to
> > understand what I've done...
> >
> > This way I want to automate TF process even more, asking the user about
> the
> > profile of the network and its services.
> >
> > Well, that's all. I'll soon be sending some of my notes and a roadmap
> for
> > the future...
> >
> > Bye!
> >

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

Re: [TuxFrw-devel] TuxFrw 2.16-pre1...

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

Hi  all!

I have looked  at install.sh and tuxfrw-config.sh and I think I can see t=
oward=20
what you are going.   I did some testing on my own, just to see what was=20
possible to do with perl. =20

So I did a small perl script (test.pl) that is going in the same directio=
n as=20
tuxfrw-config.sh.  My test is more like a configuration assistant than an=
=20
installation assistant. My objective is just to see towards what we are=20
heading  to and see what can be done with perl.

In this test, i have:

- reading tux configuration file to map tux variables to perl variables
- dig kernel information: am i root ?, kernel version,  release version, =
host=20
name,  domain name ...
- interface detection
- a first menu structure
- showing actual tux configuration and kernel information

I think it would be interresting that the installer and the assistant wou=
ld=20
remember past answers from previous installation.   The assistant could r=
ead=20
the tuxfrw.conf script, read in the actual values and give the user the=20
opportunity to change the configuration.

The assistant could verify the installation and help in TF upgrade.  The=20
installer could help in detecting and preventing configuration problems (=
a=20
ppp interface choosen as an the internal interface, the same interface=20
choosen twice ...).

I my on the right track ?  What do we do now ?  Do you think it is wortwh=
ile=20
to continue this test ? =20

Jean Jacques Gervais

p.s. Can you guys from Brazil send us some sun, it's cold in Montr=E9al.

- On Friday 24 May 2002 16:29, Marcelo de Souza wrote:
> Hi all!
>
> I'd like to announce TF 2.16 pre release 1.
>
> There are lots of changes, specifically concerning TF structure. I have=
n't
> made any changes to the iptables ruleset, only to the way TF is
> installed/configured/organized...
>
> I prefer to send u my developing notes later. By now u should try to
> understand what I've done...
>
> This way I want to automate TF process even more, asking the user about=
 the
> profile of the network and its services.
>
> Well, that's all. I'll soon be sending some of my notes and a roadmap f=
or
> the future...
>
> Bye!
>
> ------------------------------------------------------------
>    - 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] TuxFrw 2.16-pre1...

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

Hi all!

I'd like to announce TF 2.16 pre release 1.

There are lots of changes, specifically concerning TF structure. I haven't made
any changes to the iptables ruleset, only to the way TF is
installed/configured/organized...

I prefer to send u my developing notes later. By now u should try to understand
what I've done...

This way I want to automate TF process even more, asking the user about the
profile of the network and its services.

Well, that's all. I'll soon be sending some of my notes and a roadmap for the
future...

Bye!

------------------------------------------------------------ 
   - 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: Development branches...

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

----- Original Message -----
From: "Marcelo de Souza" <ma...@ac...>
To: <tux...@li...>
Sent: Saturday, May 18, 2002 10:08 AM
Subject: [TuxFrw-devel] Development branches...


>
> Hello all,
>
> well, I think I should make it clear that we should have two development
> branches for TF: 2.x and 3.x
>
> For 2.x, I'm thinking about some additions, creating a 'main script' that
would
> work as a 'wizard' for initial settings. Perhaps Jean could help me on
this... :-)
>

Yes, i will be glad to help.

> For 3.x, we could make our way towards a Ncurses UI. Attached to this mail
is
> some code I did some time ago. Note that its not finished (not even
> started...), and I stole the code from IPTraf... its cool and I think we
should
> follow that UI. Note that the menu labels have not been changed (yes, I
was
> really lazy....)
>
> Soon Ill be sending some of my ideas for menus/options, things like
that...
>
> Well, thats all. Ive made my contribs, now make yours!
>
> Hope to hear something soon...
>
> ------------------------------------------------------------
>    - 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: Let's restart TuxFrw development!!!

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

Thanks for your hospitality in TF development team.

 I will do my best to help.

 Here is my wish list for TF:

- A way to separate costum rules from the core TF rules
- A way to extend TF for specific needs (like object inheritance)
- A way to upgrade TF without disturbing custom rules
- Extenting the tuxfrw.conf to give more control to the user
- Separate the code in tuxfrw.conf from the configuration information
- Load balancing
- Bandwith management and traffic management
- High availibilty
- Service monitoring and so we can send request to alternate server for H=
A
- Amiliorate the integration of TF with different Linux flavors (Red Hat,
Suse) (chkconfig on redhat vs INIT INFO on suse)
 - Better integration in the init process. (There should be already some
rules between the time the network is  up and TF start,  since TF can be
used with dynamic ip, it should be started after the network)
- A repository of custum rules that are frequently used (Real audio, nts)
- Log, Log, Log
- Log reporting (i am now working on that), What is TF blocking ? What is
the firewall letting go through ?
- Dynamic log analysis tools (pattern recognition,ip that should get a
special attention, common attack detection)
- Dynamicly monitoring the log and building iptables rules dynamicly and
sending alert and being able to take special actions based on the sevirit=
y
of  the alert
- Central log monitoring on a central server
- Log consolidation even on sunday morning when redhat rotate the logs ...
- Intrusion detection and allow specific action to stop intrusion (Turnin=
g
off  the network adapter)
- Basic monitoring that will check the state of the machine (Interface th=
at
are in promiscuous mode, file change ,  files that are writebable by
all,files thar are hidden or SUID, integration with tripwire ???).  The
machine that host a firewall should monitor it's own state.
- Alert management
- Better loging facilities, i would like to be able to mark certain packe=
ts
and to be able to follow them as they flow through netfilter
- TF flavors: Firewall for a web server (The servers that are running beh=
ind
the main TF), Firewal for mail server,  Firewall for gateway server,
Firewall for user station ...
- Log compareason between the differrent TF of the same network (Between =
the
different flavors of TF, Firewall collaboration ?).
- Integration with snort.
- Remote firewall management and rules synchronisation, with ssh and
integration with RDist (I am not sure this is a good idea, it might even =
be
a very very very bad idea)
- a collection of small tools that are needed for system manager: script =
to
block one ip immediately and adding the rule to the firewall configuratio=
n,
script to open a port just for a short time period, ...
- Honey traps, so we can detect tentive of intrusion and we can log who i=
s
trying to infiltrate the system (Part of the intrusion detection system)
- Activity monitoring.  Is there something unusual appening on the networ=
k ?
SSH session starting at 4 am from a an unknow ip !!!
- Dynamic firewall rules based on time of day.
- Security scripting rules, like make files or based on BNF (like sudo or
rdist).  We would need an engine that would take these scripting rules an=
d
create shell script to implement the desire rules (writing the
/etc/tuxfrw/rules/tux*.mod files dynamicly)
-  ...

Well thats all what i can think of for the moment ...

Just in case you would like to know who i am.   I am a software developpe=
r.
I have been developping software for the past 15 years.   We, Les
consultants Interaction,  now do web development.  You can find informati=
on
about what we are doing at: www.consultantsinteraction.com.  We are locat=
ed
in Montr=E9al, Canada.  Montr=E9al is a french speaking community. I
,unfortunately ,now do more functional analysis than software development.

Well that is it for now !!!

Jean Jacques Gervais
Les consultants INTERACTION
----- Original Message -----
From: "Marcelo de Souza" <ma...@ac...>
To: "Jean Jacques Gervais" <jj...@in...>
Cc: <tux...@li...>
Sent: Saturday, May 18, 2002 9:41 AM
Subject: Re: [TuxFrw-devel] Re: Let's restart TuxFrw development!!!


> Well,
>
> first of all, welcome to tuxfrw-devel list Mr. Gervais.
>
> I agree with you, and we are happy to have another member in our
development
> team...
>
> We certainly need some help with 'script code', whatever the language i=
s
to be
> used.
>
> As u said, a GUI is not our main goal, cause firewalls generally run ov=
er
> =A8dumb=A8 systems, without those graphical =A8beauties=A8... That's wh=
y our
intention
> is to make some sort of CLI in NCurses. Another friend of us, Mr. Ajay
Kumar,
> said he would help developing a Ncurses based UI.
>
> Below is some of my ideas/outlines for TF (TuxFrw).
>
> Certainly we should keep TF as simple as it is, but my idea is to give =
it
some
> more functionality and greater automation level...
>
> Well, thats all...
>
> -----------------------------------------------------------------------=
---
-----
>
> TuxFrw is a set of scripts created to ease the way Linux IPTables rules
are
> configured.
> Using TuxFrw an user can configure his own Linux / Netfilter based netw=
ork
> firewall,
> simply passing some IP address numbers and other services utilization
policies.
>
> TuxFrw Development
> ------------------
>
> - List of features and changes for future versions
>
>
> Basic fucntions:
>
> - Netfilter/IPtables firewall builder.
> - automated Policy routing / Traffic control
> - firewall auditoring / traffic analyzer (???)
>
>
> What should TuxFrw be?
>
> User interface to Netfilter/IPtables and Linux policy routing or traffi=
c
> control, allowing you to edit firewall rules and configure the firewall=
 to
"mark"
> packets for policy routing or for class based queueing (CBQ). Also a
firewall
> auditor and traffic analyzer.
>
>
> Functionality:
>
> Lists the various possibilities in "menus" and "forms" that can be
> navigated through using the arrow and function keys (Ncurses version), =
GUI
(Qt) or
> web interface (CGI or similar) so that one doesn't have to memorize the
various
> configuration possibilities and options of command line or script or
script-based
> IPtables firewall setup.
>
>
> TuxFrw 2.x functionality
>
> New versions should keep the way 2.x did IPtables rules, but now the ma=
in
> TuxFrw interface is responsible for setting the rules and loading them
through the
> "SysV-like service".
>
> |-> creates/manages "/etc/tuxfrw/<conf_and_rules_files>"
>
> |
> TuxFrw -|
> |
>
> |-> setup "/etc/init.d/tuxfrw" service
>
>
> Full list of features:
>
> - Copy all other already existent features from TF 2.x
>
> - An wizard that can easily configure rules.
> - switch between simple or advanced firewall setup
> - choose Internet connected device (ethX, pppX, ...)
> - is DHCP?
> - enable/disable ICMP filtering (Echo, Unreachable, ...)
> - enable services by names
> - TOS configuration (DiffServ - Throughput, Reliability, Delay)
> - Masquerading (LAN)
> - select internal device (IP autodetection or manual)
> - setup port forwarding
>
>
> - Commands to Start/Stop firewall or Halt all network traffic
> - Option to explicitly block ports
> - Option to enable experimental options
>
> - Try to detect the location of system binaries
> - Setup preferred packet rejection method (DENY, REJECT)
>
> - Display firewall hit-list (enable/disable, clear, load, save) --> Log=
s?
>
> - Allow creation of Dynamic rules
> - deny all connections from...
> - allow all connection from...
> - allow (TCP/UDP) service (port) to (IP)...
> - allow (TCP/UDP) service (port) to anyone
>
> - Rules viewer : filter, nat and mangle (Packet filtering, masquerading
and
> mangling)
> - Load/Save configurations
> - Probe interfaces automatically. (get IPs )
> - Connection viewer (/proc/net/ip_conntrack) --> like connviewer by
Conectiva
>
> - Traffic Control (Class Based Queueing)
> - work together with Traffic Shaper, based on MARK targets (CBQ schedul=
er)

> - Traffic shapper monitor
>
> - tcpdump front-end
> - nmap frontend
> - Log analysis
>
>
> Our object should be based on the following :
>
> " The idea of a tool to configure the reliable firewall for either netw=
ork
> protection or host protection still has not found its right
implementation,
> particularly
> one to be used by people who do not understand the technical details of
packet
> filtering
> and its Linux implementation together with at least some of the iptable=
s
> internals. The
> best way to configure iptables still seems to be "iptables -N",
"iptables -A",
> "iptables -D", etc.
> In other words, if one can learn to successfully operate some of the
existent
> automation tools (including TuxFrw), one can just as easily learn to
configure
> iptables
> from the command line! This tools should have full support for iptables
> features and use
> plain simple well-documented configuration files.
> However, such tools must be implemented, as the need exists for the sim=
ple
firewall
> configuration support due to widespread use of Linux in an insecure
Internet
> environment."
>
> -- based on a SecurityFocus Article.
>
> -----------------------------------------------------------------------=
---
----
>
> > Bonjour !
> >
> > Yes, I am willing to help !
> >
> > I am a software developer.  I have been developping software  for the
past
> > 15
> > years.   On my job, I now do more management and  software analysis t=
han
> > software development.
> >
> > I am willing to help with CLI.  I am willing to participate in perl,
awk,
> > sed,
> > ruby (i never used it but this language seem promising), shell script
or
> > any
> > scripting language.
> >
> > I don't think that a GUI is a good idea for a firewall since most
machine
> > that
> > are running firewall do not have graphical interfaces.
> >
> > I think that one of the strength of Tux Firewall is his simplicity.  =
Tux
> > firewall is elegant.  Most people that are using this type of firewal=
l
> > already know about iptables (They should). For me Tux firewall is a
> > framework
> > that offers me a clear way to organize my iptables rules.
> >
> > Most others firewalls i have seen so far try's to simplify firewall
creation
> >
> > and maintenance, wich is good.  But these firewalls are trying to hid=
e
the
> >
> > fact that the objectives is to make iptables or ipchains rules, by do=
ing
so,
> >
> > they are building an architecture that is often more complex than the
> > problem
> > they are trying to solve.
> >
> > I think that, Tux firewall should help system administrator   with th=
e
> > creation and maintenance of iptables rules, but in no way hide these
rules
> >
> > from him.
> >
> > There is already plenty GUI firewall. Some of them have very nice
interface.
> >
> > (OpenWall)  I don't think, that Tux firewall should compete with thes=
e
> > firewalls.  They are design for fifferent market  (are they ?).
> >
> > The strength of Tux firewall is that it is in perfect harmony with
iptables.
> >
> > It is design the way it should be.
> >
> > How do you see the futur of Tux firewall ?
> >
> > Can we make a list of the things that we would like to see in Tux
firewall ?
> >
> >
> > Au revoir !
> >
> > Jean Jacques Gervais
> >
> > _______________________________________________________________
> > Hundreds of nodes, one monster rendering program.
> > Now that's a super model! Visit http://clustering.foundries.sf.net/
> >
> > _______________________________________________
> > 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] Development branches...

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

Hello all,

well, I think I should make it clear that we should have two development
branches for TF: 2.x and 3.x

For 2.x, I'm thinking about some additions, creating a 'main script' that would
work as a 'wizard' for initial settings. Perhaps Jean could help me on this... :-)

For 3.x, we could make our way towards a Ncurses UI. Attached to this mail is
some code I did some time ago. Note that its not finished (not even
started...), and I stole the code from IPTraf... its cool and I think we should
follow that UI. Note that the menu labels have not been changed (yes, I was
really lazy....)

Soon Ill be sending some of my ideas for menus/options, things like that...

Well, thats all. Ive made my contribs, now make yours!

Hope to hear something soon...

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

Re: [TuxFrw-devel] Re: Let's restart TuxFrw development!!!

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

Well,

first of all, welcome to tuxfrw-devel list Mr. Gervais.

I agree with you, and we are happy to have another member in our development
team...

We certainly need some help with 'script code', whatever the language is to be
used.

As u said, a GUI is not our main goal, cause firewalls generally run over
¨dumb¨ systems, without those graphical ¨beauties¨... That's why our intention
is to make some sort of CLI in NCurses. Another friend of us, Mr. Ajay Kumar,
said he would help developing a Ncurses based UI.

Below is some of my ideas/outlines for TF (TuxFrw).

Certainly we should keep TF as simple as it is, but my idea is to give it some
more functionality and greater automation level...

Well, thats all...

-------------------------------------------------------------------------------

TuxFrw is a set of scripts created to ease the way Linux IPTables rules are
configured.
Using TuxFrw an user can configure his own Linux / Netfilter based network
firewall,
simply passing some IP address numbers and other services utilization policies.

TuxFrw Development
------------------

- List of features and changes for future versions


Basic fucntions:

- Netfilter/IPtables firewall builder.
- automated Policy routing / Traffic control
- firewall auditoring / traffic analyzer (???)


What should TuxFrw be?

	User interface to Netfilter/IPtables and Linux policy routing or traffic
control, allowing you to edit firewall rules and configure the firewall to "mark"
packets for policy routing or for class based queueing (CBQ). Also a firewall
auditor and traffic analyzer.


Functionality:

	Lists the various possibilities in "menus" and "forms" that can be
navigated through using the arrow and function keys (Ncurses version), GUI (Qt) or
web interface (CGI or similar) so that one doesn't have to memorize the various
configuration possibilities and options of command line or script or script-based
IPtables firewall setup.


TuxFrw 2.x functionality

	New versions should keep the way 2.x did IPtables rules, but now the main
TuxFrw interface is responsible for setting the rules and loading them through the
"SysV-like service".

		|-> creates/manages "/etc/tuxfrw/<conf_and_rules_files>"
	
	|
	TuxFrw -|
		|
	
	|-> setup "/etc/init.d/tuxfrw" service


Full list of features:

- Copy all other already existent features from TF 2.x

- An wizard that can easily configure rules.
	- switch between simple or advanced firewall setup
	- choose Internet connected device (ethX, pppX, ...)
		- is DHCP?
	- enable/disable ICMP filtering (Echo, Unreachable, ...)
	- enable services by names
	- TOS configuration (DiffServ - Throughput, Reliability, Delay)
	- Masquerading (LAN)
		- select internal device (IP autodetection or manual)
		- setup port forwarding


- Commands to Start/Stop firewall or Halt all network traffic
- Option to explicitly block ports
- Option to enable experimental options

- Try to detect the location of system binaries
- Setup preferred packet rejection method (DENY, REJECT)

- Display firewall hit-list (enable/disable, clear, load, save) --> Logs?

- Allow creation of Dynamic rules
	- deny all connections from...
	- allow all connection from...
	- allow (TCP/UDP) service (port) to (IP)...
	- allow (TCP/UDP) service (port) to anyone

- Rules viewer : filter, nat and mangle (Packet filtering, masquerading and
mangling)
- Load/Save configurations
- Probe interfaces automatically. (get IPs )
- Connection viewer (/proc/net/ip_conntrack) --> like connviewer by Conectiva

- Traffic Control (Class Based Queueing)
- work together with Traffic Shaper, based on MARK targets (CBQ scheduler)
- Traffic shapper monitor

- tcpdump front-end
- nmap frontend
- Log analysis


Our object should be based on the following :

	" The idea of a tool to configure the reliable firewall for either network
protection or host protection still has not found its right implementation,
particularly
one to be used by people who do not understand the technical details of packet
filtering
and its Linux implementation together with at least some of the iptables
internals. The
best way to configure iptables still seems to be "iptables -N", "iptables -A",
"iptables -D", etc.
	In other words, if one can learn to successfully operate some of the existent
automation tools (including TuxFrw), one can just as easily learn to configure
iptables
from the command line! This tools should have full support for iptables
features and use
plain simple well-documented configuration files.
	However, such tools must be implemented, as the need exists for the simple firewall
configuration support due to widespread use of Linux in an insecure Internet
environment."

	-- based on a SecurityFocus Article.

------------------------------------------------------------------------------

> Bonjour !
> 
> Yes, I am willing to help !
> 
> I am a software developer.  I have been developping software  for the past
> 15 
> years.   On my job, I now do more management and  software analysis than 
> software development.  
> 
> I am willing to help with CLI.  I am willing to participate in perl, awk,
> sed, 
> ruby (i never used it but this language seem promising), shell script  or
> any 
> scripting language.  
> 
> I don't think that a GUI is a good idea for a firewall since most machine
> that 
> are running firewall do not have graphical interfaces. 
> 
> I think that one of the strength of Tux Firewall is his simplicity.  Tux 
> firewall is elegant.  Most people that are using this type of firewall 
> already know about iptables (They should). For me Tux firewall is a
> framework 
> that offers me a clear way to organize my iptables rules.  
> 
> Most others firewalls i have seen so far try's to simplify firewall creation
> 
> and maintenance, wich is good.  But these firewalls are trying to hide the
> 
> fact that the objectives is to make iptables or ipchains rules, by doing so,
> 
> they are building an architecture that is often more complex than the
> problem 
> they are trying to solve.  
> 
> I think that, Tux firewall should help system administrator   with the 
> creation and maintenance of iptables rules, but in no way hide these rules
> 
> from him.
> 
> There is already plenty GUI firewall. Some of them have very nice interface.
> 
> (OpenWall)  I don't think, that Tux firewall should compete with these 
> firewalls.  They are design for fifferent market  (are they ?).
> 
> The strength of Tux firewall is that it is in perfect harmony with iptables.
>  
> It is design the way it should be.  
> 
> How do you see the futur of Tux firewall ?  
> 
> Can we make a list of the things that we would like to see in Tux firewall ?
>   
> 
> Au revoir !
> 
> Jean Jacques Gervais
> 
> _______________________________________________________________
> Hundreds of nodes, one monster rendering program.
> Now that's a super model! Visit http://clustering.foundries.sf.net/
> 
> _______________________________________________
> 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] Re: Let's restart TuxFrw development!!!

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

Bonjour !

Yes, I am willing to help !

I am a software developer.  I have been developping software  for the pas=
t 15=20
years.   On my job, I now do more management and  software analysis than=20
software development. =20

I am willing to help with CLI.  I am willing to participate in perl, awk,=
 sed,=20
ruby (i never used it but this language seem promising), shell script  or=
 any=20
scripting language. =20

I don't think that a GUI is a good idea for a firewall since most machine=
 that=20
are running firewall do not have graphical interfaces.=20

I think that one of the strength of Tux Firewall is his simplicity.  Tux=20
firewall is elegant.  Most people that are using this type of firewall=20
already know about iptables (They should). For me Tux firewall is a frame=
work=20
that offers me a clear way to organize my iptables rules. =20

Most others firewalls i have seen so far try's to simplify firewall creat=
ion=20
and maintenance, wich is good.  But these firewalls are trying to hide th=
e=20
fact that the objectives is to make iptables or ipchains rules, by doing =
so,=20
they are building an architecture that is often more complex than the pro=
blem=20
they are trying to solve. =20

I think that, Tux firewall should help system administrator   with the=20
creation and maintenance of iptables rules, but in no way hide these rule=
s=20
from him.

There is already plenty GUI firewall. Some of them have very nice interfa=
ce.=20
(OpenWall)  I don't think, that Tux firewall should compete with these=20
firewalls.  They are design for fifferent market  (are they ?).

The strength of Tux firewall is that it is in perfect harmony with iptabl=
es. =20
It is design the way it should be. =20

How do you see the futur of Tux firewall ? =20

Can we make a list of the things that we would like to see in Tux firewal=
l ?  =20

Au revoir !

Jean Jacques Gervais

[TuxFrw-devel] Let's restart TuxFrw development!!!

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

Hi there people!

I think we need to take over the ground, don't u?

I really wanna know who is available to help me doing some work?

It would be great if all of u could list all of your programming skills, so 
that we can see what we can do.

CLI or GUI programmers, please manifest!!! We need some sort of UI for this 
app! 

I'm thinking about some sort of interface to automate the creation of firewall 
rules. Something like a wizard...

Hope to be hearing from u soon.

Cheers!


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

Re: [TuxFrw-devel] (no subject)

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

Ok. Sorry!  :)

Em Seg 06 Mai 2002 16:48, Marcelo de Souza escreveu:
> Dear TF developers (or anynone who is part of this list),
>
> It would be helpful if all of u members could post to this list in
> english!!!
>
> Portuguese: seria bom que vcs membros pudessem escrever em ingles nesta
> lista....
>
> Valeu Gondim e Isamp!!!! (=C9 pq tem gente de fora aqui...falou?)
>
> Thanx!
>
> > Bien venido,
> >
> > Sei l=E1 como se escreve isso em espanhol mas tamb=E9m n=E3o curto Ro=
berto
> > Carlos,
> >
> > prefiro TuxFrw com fundo musical do Capital Inicial.  :)
> >
> > Em Seg 06 Mai 2002 11:56, Isamp escreveu:
> > > Eu voltei ... agora para ficar .... por aqui ... aqui =E9 o meu lug=
ar ...
> > >
> > > blarg ... odeio Roberto Carlos !!!!
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________________________
> > >
> > > Have big pipes? SourceForge.net is looking for download mirrors. We
> >
> > supply
> >
> > > the hardware. You get the recognition. Email Us:
> >
> > ban...@so...
> >
> > > _______________________________________________
> > > TuxFrw-devel mailing list
> > > Tux...@li...
> > > https://lists.sourceforge.net/lists/listinfo/tuxfrw-devel
> >
> > --
> > Marcelo Gondim da Cunha
> > LinuxInfo
> > ICQ 114063253
> > Linux Counter User #56135
> >
> > _______________________________________________________________
> >
> > Have big pipes? SourceForge.net is looking for download mirrors. We
> > supply the hardware. You get the recognition. Email Us:
> > ban...@so... ___________________________________________=
____
> > 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
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We sup=
ply
> the hardware. You get the recognition. Email Us: bandwidth@sourceforge.=
net
> _______________________________________________
> TuxFrw-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxfrw-devel

--=20
Marcelo Gondim da Cunha
LinuxInfo
ICQ 114063253
Linux Counter User #56135

Re: [TuxFrw-devel] (no subject)

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

Dear TF developers (or anynone who is part of this list),

It would be helpful if all of u members could post to this list in english!!!

Portuguese: seria bom que vcs membros pudessem escrever em ingles nesta 
lista....

Valeu Gondim e Isamp!!!! (É pq tem gente de fora aqui...falou?)

Thanx!


> Bien venido,
> 
> Sei lá como se escreve isso em espanhol mas também não curto Roberto Carlos,
> 
> prefiro TuxFrw com fundo musical do Capital Inicial.  :)
> 
> Em Seg 06 Mai 2002 11:56, Isamp escreveu:
> > Eu voltei ... agora para ficar .... por aqui ... aqui é o meu lugar ...
> >
> > blarg ... odeio Roberto Carlos !!!!
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________________________
> >
> > Have big pipes? SourceForge.net is looking for download mirrors. We
> supply
> > the hardware. You get the recognition. Email Us:
> ban...@so...
> > _______________________________________________
> > TuxFrw-devel mailing list
> > Tux...@li...
> > https://lists.sourceforge.net/lists/listinfo/tuxfrw-devel
> 
> -- 
> Marcelo Gondim da Cunha
> LinuxInfo
> ICQ 114063253
> Linux Counter User #56135
> 
> _______________________________________________________________
> 
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us: ban...@so...
> _______________________________________________
> 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

Re: [TuxFrw-devel] (no subject)

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

Bien venido,

Sei l=E1 como se escreve isso em espanhol mas tamb=E9m n=E3o curto Robert=
o Carlos,=20
prefiro TuxFrw com fundo musical do Capital Inicial.  :)

Em Seg 06 Mai 2002 11:56, Isamp escreveu:
> Eu voltei ... agora para ficar .... por aqui ... aqui =E9 o meu lugar .=
=2E.
>
> blarg ... odeio Roberto Carlos !!!!
>
>
>
>
>
>
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We sup=
ply
> the hardware. You get the recognition. Email Us: bandwidth@sourceforge.=
net
> _______________________________________________
> TuxFrw-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxfrw-devel

--=20
Marcelo Gondim da Cunha
LinuxInfo
ICQ 114063253
Linux Counter User #56135

[TuxFrw-devel] (no subject)

[Isamp <is...@te...>]

Eu voltei ... agora para ficar .... por aqui ... aqui é o meu lugar ...

blarg ... odeio Roberto Carlos !!!!

[TuxFrw-devel] Home page do TF

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

Hi,

I've uploaded TuxFrw home page to SourceForge. It's now available at 
http://tuxfrw.sourceforge.net

Please take your time to review it, looking for errors. Report me.

Gonna take a look at TF 2.13p3 now...

Bye!

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