Hi,
Reading the discussion about
> ..the implications of the GUI running on the firewall and what dangers it
> may represent...
I think that some information about the architecture of CheckPoint FireWall-1
(FW-1) is in place.
FW-1 is a distributed system comprised of a single ``control module''
(typically residing on the sys-admin station) and any number of
``packet filtering modules'' (in the simplest case, a single packet filter
module residing on the gateway to the Internet).
All Communication between the control module and the packet filtering
modules is done through an authenticated control link.
The control module can also drive cisco routers by generating and
downloading access lists to them.
So the picture can look something like this:
Internet
|
|
_
-------|X|-------- ---------------------
| - | Gateway | | Sys. Admin.
| PACKET FILTERING | | CONTROL MODULE | Station
| MODULE | | |
| _ | | |
-------|X|-------- --------------------
- |
| |
| |
--------------------------------------------------------
|
LocalNet |
_
_______|X|_______
| - |
| Cisco Router |
| _ |
-------|X|-------
OtherNet -
|
--------------------------------------------------------
Sometimes the control module (containing the GUI) may reside on the gateway
itself. This is entirely up to the local administrator's decision. In any case,
the GUI (as Chuck Yerkes already noted) is just an X *client*. Furthermore, the
gateway itself (as any other internal machine) should be protected by FW-1
against access to X from the internet.
The GUI is a relatively small application with the following functional
components:
o Network Objects & Services Managers: used to define new network objects
(hosts, networks, domains, groups etc.) and services (TCP, UDP, RPC or other).
o Rule Base Editor: used to create a set of security rules.
o System Status: reporting the status of all packet filter modules in the
system (number of packets passed/dropped/rejected/logged name of filter etc.).
o Log Viewer: allows to analyze all log events.
The work flow is something like this:
First, the security policy is molded into a rule-base (using the Object
Managers and Rule-Base Editor). Then, when instructed to apply this security
policy, the control module generate from the rule-base a filter-script, compiles
it and disseminates the filter code to the appropriate packet filter modules
(and cisco routers). Once this is done, all logs and alerts generated are
collected back to the control module. The control module generates real time
notifications (customizable) upon alert events and allows for online viewing of
log events. The control module monitors and displays the status of the packet
filtering modules using the System Status screen. Finally, the administrator
will use the Log Viewer in order to assess her security policy, produce reports,
etc.
Some concern has been raised about the "complexity = problems" equation. I
absolutely agree with Frederiko Avolio about this: complexity in the management
of security is bad for your security. More specifically, I personally feel that
there are three important *management* goals for a system such as FW-1:
o Easy implementation of a security policy to security rules.
o A tight feedback loop on communication attempts and system status.
o An Extensive mechanism for "post-mortem" analysis.
I believe that the FW-1's GUI provides an easy-to-use answer to these goals,
while not being too complex by itself.
---------------------------- F i r e W a l l - 1 -----------------------------
Shlomo Kramer, CheckPoint Software Technologies | Email: shlomo @
CheckPoint .
COM
437 Boylston Street | Voice: 1-800-429-4391
Boston MA 02116 | Fax: 617-859-9052
------------------------------------------------+-----------------------------
|
|
