[TuxFrw-devel] Re: Welcome !!!
Brought to you by:
mgondim
From: <jj...@in...> - 2002-06-04 13:06:31
|
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 > |