Thread: [TuxFrw-devel] TuxFrw 2.16-pre1...
Brought to you by:
mgondim
Menu
▾
▴
tuxfrw-devel
|
From: Marcelo de S. <ma...@ac...> - 2002-05-24 20:29:47
Attachments:
tuxfrw-2.16-pre1.tar.gz
|
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
|
|
From: Jean J. G. <jj...@in...> - 2002-05-26 12:57:58
Attachments:
test.tar.gz
|
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 |
|
From: Marcelo de S. <ma...@ac...> - 2002-05-27 19:20:59
|
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
|
|
From: Jean J. G. <jj...@in...> - 2002-05-28 00:12:18
|
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 |
|
From: Marcelo de S. <ma...@ac...> - 2002-05-28 03:47:21
|
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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X