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