From: Charles S. <ch...@st...> - 2000-12-30 20:05:31
|
> 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) |