> I'm starting to lose my mind............... :-)
You've probably got a ways to go to catch up with the rest of us :)
> I'm trying to develop a simple firewall tool which at its core relies
> on shell functions rather than shell variables and specially-
> formatted configuration files. Trouble is, my head is starting to
> HURT with all these different possibilities. Here is some rambling
> problems and "hurts" and "what do I do NOW???" things:
>
> * DMZ - what connectivity do you give to it? What do you allow to
> the protected net? What do you allow to the unprotected net? Would
> it be easier to proxy-arp the DMZ to the outside world?
These are all things that should be configurable, as the answers vary based
on the specific requirements of each application environment. The use of
shell-functions for building the rules for a DMZ would be quite handy here,
as you could have a generic 'add this function to the DMZ rules', and a
'wrapper' shell function would call the appropriate lower-level functions
based on the type of DMZ (and any other variables that might matter). Note
that it's possible to use 'function pointers' in shell-code with the eval
command:
# 'Call' the procedure, passing the variable to process and any args
eval $PROCEDURE <argument> [<argument>]
Probably old-hat for you unix guru's, but I was pretty jazzed when I figured
it out. With a bit of fancy code resolving procedure names (think C++ or
Java type object encapsulation), all sorts of nifty things become possible
(like creating a default network type, with individual modules for externa,
DMZ, internal, and whatever else overloading the defualt firewall
rule-building functions as required).
> * Protected net: what about limiting internal users access to outside?
This is desireable in many instances, and should also be configurable. At a
minimum, the typical firewall rules should probably block MS networking
packets from 'leaking' out the public interface (see Materhorn/Eiger
firewall rules). This is one complaint I have with the seawall guys...they
didn't used to have a mechanism to block outbound traffic (may have changed
by now).
> * Internal firewall: what if the "external" unprotected net is
> actually an internal network behind a firewall? Now you have private
> IPs on BOTH sides of the firewall....
This is one of the big problems with Materhorn/Eiger scripts, which is seen
fairly frequently on the list. I'd like to see the 'blockMartians'
functionality done as a called IPChain, then you could do a compare to any
local IP ranges (private or otherwise) and return, while still denying any
IP's that are 'unexpected'.
> * Masquerading... what about masquerading in BOTH directions? Or
> just one?
I not sure masquerading works in both directions (test needed). It does
make sense to allow masquerading between internal networks, however (this
would allow 'unidirectional' connections between internal networks, which
may be desireable).
> * Servers on the firewall: this isn't as odd as it sounds. The first
> is ssh.
This should definately be supported. One very under-utilalized aspect of
LRP is it's use as a 'thin-server' OS.
> * Servers in the unprotected net....!
Um...isn't this the internet?
> The BIG question: how do you ACCOUNT for all these?
I'd use config files :)
> In particular, I'm implementing Oxygen as a firewall for an internal
> private network, so this really IS relevant. I also want to set it
> up at home, sooner or later, if I can get the modem and then PPP to
> work. I don't trust serial communications - it almost certainly
> never works the first time.
>
> Regarding firewalls, consider these problems/examples:
>
> * Internal firewall inside: now you can't reject all private IPs from
> the unprotected net.... since it also uses private IPs.
>
> * Masquerading: on a standard Internet firewall, you would masquerade
> the internal network - but what about a firewall INSIDE a
> firewall....?
>
> Another thing - which HURTS:
>
> * When I define a TCP transmission path, the two directions are
> defined in separate chains/rules whatever; you can't define a rule
> which says: "allow an outbound TCP connection on this port" - this is
> actually TWO steps - outgoing, and incoming.
That's why there are usually rules allowing inbound 'ack' packets (aka
non-syn, established connections, etc). You don't allow any TCP start of
connection packets in, just response data from previously established
connections. This is where 2.4 (netfilter) and stateful packet filtering
come into play. A stateful packet filter watches the low-level IP traffic,
and when you send an outbound start of connection packet for a permitted
service, a tiny hole is automatically opened in the firewall for the return
traffic from that server.
> All this is starting to make my head explode - does anyone have any
> ideas? I know this is vague - I'm keep banging my head into things
> and I'm getting lost in the forest :-)
Just try this one little mint....(think monty python :-)
> I have the Building Internet Firewalls book - and I found it
> interesting that they don't seem to have a description of firewall
> rules for a DMZ. I also found that there isn't very much description
> of a DMZ out there - even those places that talk about it probably
> refer to a perimeter network instead.
The Building Internet Firewalls book expressly doesn't try to create a set
of firewall rules for any particular application (DMZ network or otherwise).
They try to cover overall firewall structure, and provide details for
firewalling particular services. The conversion of this information into
something appropriate for any particular environment is 'left as an
excerscise for the reader'.
I do have some thoughts on overall structure of a ruleset, however:
I'd start by creating several 'classes' of network functionality (external,
internal, and DMZ at a minimum). There may be more than one of each type of
network (especially internal and DMZ).
DMZ networks could be of several types (proxy-arp, static-NAT, routed,
port-forwarded), as could the internal network (masqueraded or routed).
There should be some way of specifying what services are provided by the
DMZ, and only those services should be allowed by the firewall rules.
Here's where some layers of software indirection using function pointers
could be real handy in building the ruleset...
Internal networks could be masqueraded or routed, and would be protected
from both the external network and the DMZ networks (configurable rules
required).
By default, there would be no connection between any networks of the same
type, but this should be configurable (ie allow all packets between all
internal networks, or specific connection types between these two networks).
This is a long way from a usable set of ipchains rules, but it's the
direction I'd start off if I was rolling something from scratch. I envision
something that at the top-level would be as simple as specifying the
networks to firewall, and the network type. Lower-level functions could
then build appropriate rulesets based on the types of networks present, and
any local configuration information provided. Judicious use of ipchains (as
in creating many sub-chains) and generalized software interfaces should make
possible a 'clean' and expandable firewall rule builder. Proper forethought
about the structure of the ipchain 'tree' and the scripts that build it
should also allow a fairly easy migration to iptables when we migrate to
2.4.
I'm willing to help create this sort of firewall-builder, but cannot comit
to doing it myself. In addition to being a bit too busy, I have recently
committed to help Dave C. re-work the LRP packaging format (more news on
this when I have some real info).
P.S. Does anyone know if anything like this exists? It seems like someone
would have written this already (or at least something close enough to use
as a starting point).
Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/leaf-devel
