[Firedraw-devel] Splitting the project into modules

[Luc S. <ls...@fr...>]

The main problem on the other "firewall" projects is that they don't
have a global vision of what should be done. For example, most of
the existing projects require that the platform where the rules will be
applied IS the same as the one where you define the rules.

Most companies have SEVERAL firewalls, and most companies don't run
XWindow on their firewall.

There should be at least two daemons to achieve this:

1) A 'Final daemon':
	This daemon runs on each on the firewall instances (the final
	places where the rules are applied). This can be Linux, *BSD,
	a router, etc.
	Its action is to receive rules into its native format and to
	apply them, or change them. (to be discussed, where does the
	convertion need to be done ?)

2) A 'RuleManager daemon':
	This daemon runs on an intermediate machine. Its goal is to
	store the internal formatted maps of the network. Another of
	its goal is to convert that format to the native one where
	firewalls reside.
	You would ask: but why not store it on the machine where I'm
	designing the rules ?
	The answer is that in most places, you have several
	administrators who want to administer the rules. If each of 
	them have its own files, this would lead to a lot of conflicts.
	Another reason is that the machine where the user is designing
	his maps is not always secure. Having a RuleManager daemon on
	another machine increases security, as the user need some
	authentification method to get the map(s).
	The maps stored by the RuleManager will be XML. They are easily	
	parsed and GTK likes XML (me too :-)

The designing (graphical) part would be run on any machine. In some
cases the three daemons can be on the same machine.

Another goal is to completely separate the graphical part from the
'core' part of the firewall design. This would allow us to create
other front ends really easily (web, gtk, ncurses, qt, etc.).

Actually, we'll design only the GTK module to access the RuleManager
daemon.

I'm working on writing a document that will give more details and
some sort of API draft to see what should be done where.


About the graphical part, I'll suggest to implement layers, like in
Gimp, that would allow the user to choose what he want to see.

Luc
-- 
Luc Stepniewski <ls...@ad...> <http://lstep.free.fr/>
Adequat - Securite, Linux     Public key: <http://lstep.free.fr/pubkey.txt>
Key D93B2D2D fingerprint = 49 00 CC D1 69 03 E2 94  C8 78 ED 3C 75 89 A8 DE