I'm thinking about this some... and there are some problems with
thinking about firewalls that I see:
- the point of view from a firewall is conceptually that of a Fence:
there is THIS side and THAT side and we see and allow and reject
things going between.
- Alternate conceptual views: that of a path. For example, if I
start FTP on my client, and I establish a connection to a FTP server
somewhere, that would establish a PATH between my FTP client and the
remote FTP server.
- Alternate conceptual views: that of a network. For example, this
network allows FTP sessions originating within it.
Thinking on this, the Fence idea makes all the problems we've seen:
you not only have to allow one way but also the other.
The Network Idea simplifies things slightly, but creates the problem
in that the "Network" does not include the concept of where the
transmission originates or ends. When a session arrives, wanting to
enter the network, some things must be known about it, and aren't
necessarily according to the conceptual idea of a network.
A Path (Session?) conceptual idea contains all these. A Path object
would have the following properties:
* Originator
- Port
- IP
- "Location"
* Receiver
- Port
- IP
- "Location"
"Location" would be something like "World" or "Protected Network" or
"Unprotected Network" and similar.
Then a firewall would be defined in terms of a set of paths. For
example, just whipping off some (permitting) rules here:
Protected-Network named -> World named
Protected-Network telnet -> World telnet
Protected-Network whois -> World whois
Protected-Network ftp -> World ftp
Protected-Network smtp -> OurMailServer smtp
As all of you are probably aware, FTP and DNS are much different
across the firewall than typical services like SMTP and Telnet and
Whois; but the idea here is that is ALL HIDDEN from the firewall
builder.
Thinking about this more, the "Location" would likely be another
object, like Charles said.... like so:
* Location
- ProtectionType = {Proxy-ARP, Masq, Route}
- Name = {Protected-Network, Unprotected-Network, World}
- Unexpected-IPs
Ideas? Perhaps sh isn't the way to go?
--
David Douthitt
UNIX Systems Administrator
HP-UX, Linux, Unixware
[EMAIL PROTECTED]
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/leaf-devel
