On 30 Dec 2000, at 20:06, Charles Steinkuehler wrote:
> 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>]
Not sure what you mean - though I understand the eval statement more
or less.
> Probably old-hat for you unix guru's, but I was pretty jazzed when I
> figured it out.
First time I REALLY understood it was when I looked at Dave Cinege's
code for /etc/init.d/network .... pretty sneaky stuff :-)
> > 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.
You misunderstand me. To respond to Ray, I know about -b, but that
doesn't allow for ! -y. What I'm talking about is this:
1) to define a TCP "path" you need TWO rules.... one outbound and one
inbound.
2) in examining the ipchains firewall rules, you only see ONE SIDE of
this TCP "path" when you are looking at the rules.
I'd like to see something like this:
Chain input (policy ACCEPT):
target prot opt source destination ports
ACCEPT tcp P----- 10.5.0.0/16 10.0.0.75 23
And this SINGLE rule would cover ENTIRE connections made from the
local network (10.5.0.0/16) to the remote destination 10.0.0.75 ...
Thus, you wouldn't have to keep reminding yourself to go look at that
OTHER rule, or to make sure that BOTH rules are good, et al.
In REALLY smart situations, such a rule would also be aware of
"unpriviledged ports" on the source end, and would also be able to
handle non-standard protocols like FTP or DNS...
> 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.
Sounds like it might perform the equivalent to what I mentioned
above. Anyone know if netfilters will be supported under Linux 2.2?
> The Building Internet Firewalls book expressly doesn't try to create a
> set of firewall rules for any particular application (DMZ network or
> otherwise).
Ah, but they do :-) Consider talk - rules are on page 271-272; IRC,
rules on page 274; DNS, rules on page 281, 293-294, 295-296; syslog,
rules on page 297; .... you get the idea :-)
> They try to cover overall firewall structure, and provide details
> for firewalling particular services.
But they don't say how to firewall a server located on a DMZ that I
can find... What do you allow from the Internet to a web server on a
DMZ for example? What do you allow between the web server on the DMZ
and an internal protected network?
> 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).
I think I see.... and I was hoping to do this. Then one could use a
boilerplate standard firewall, or configure it separately.
> 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...
Still not sure what you mean - how would you use function "pointers" ?
> 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.
ipfilter has a ipchains.o module which should make migration to
iptables completely invisible, right?
> I'm willing to help create this sort of firewall-builder, but
> cannot comit to doing it myself.
I'm hip-deep in it myself :-)
Here is my current firewall configuration. Charles, you might want
to note the line that says "reject-netbios" :-) This is an internal
network firewalled off from the rest of our internal net - a full
Linux server used to be at the IP now occupied by the firewall, and
is now mostly proxied behind the firewall. Consider this
configuration:
# This is a configuration file for /etc/init.d/firewall
#
# It is run by /etc/init.d/rc
# Remember that "outside" is considered the uncontrolled unprotected environment,
# and "inside" is considered the controlled, protected, environment.
# Firewall enabled (1) or disabled (0)
FIREWALL=1
# Debugging...
OPEN_FIREWALL=1
LOCALNET=172.21.0.0/16
LOCALHOST=172.21.3.59
# Internal Addresses
INTERNIF=eth0
INTERNIP=$LOCALHOST
# External Addresses
EXTERNIF=eth1
EXTERNIP=10.5.3.59
NAMESERVER=10.5.3.64
# The policy() function is run as part of the firewall configuration
policy () {
#----------------------------------------
# REJECTS
#----------------------------------------
# These zap things early, and also help in
# logging details
# std-rejects # Standard useful rejects: could change, but
currently
# includes the next four
reject-netbios # Windows *NOISE*
reject-spoof # reject local-looking traffic on external IF
# reject-reserved-ip # reject reserved IP addresses
reject-routed # reject routing protocol - RIP
# reject-localhost # reject all traffic originating from firewall
host
#----------------------------------------
# MASQUERADING
#----------------------------------------
# Controls are placed by input and output chains, and others. Masquerade does
# not need to have much in the way of controls, but can be used for that,
# and can be used for statistics as well.
masquerade-all # masquerade EVERYTHING
#----------------------------------------
# FIREWALL HOST TRAFFIC
#----------------------------------------
# This is traffic to and from the firewall host.
# Allow traffic to and from the firewall host
# allow-localhost # allow traffic from firewall host
# Allow traffic to a server located on the firewall from internal clients
# allow-internal-server ssh
# Allow connections to the firewall via ssh
firewall-server ssh
# firewall-server syslog udp
# Allow all traffic to and from the local network
allow-internal-traffic # allow all traffic to and from local network
#----------------------------------------
# TRAFFIC TO INSIDE SERVERS FROM OUTSIDE
#----------------------------------------
# For debugging and tracking purposes, you could allow protocols
# specifically even though a rule exists to allow ALL traffic.
# Doing this also permits you to lock out all but the permitted
# protocols at a moment's notice, if you don't want to do this
# on a standard basis.
# Set up a web proxy without having to change web browser configurations
# transparent-proxy # set up for transparent web proxy
# Redirect ports from firewall to internal server. Thus, we will "act like"
# a specified server, and the real server inside will do all the hard work.
# The firewall just sends packets to the real server and back, faking
# the client out.
redirect-to 172.21.3.60 ntp udp
redirect-to 172.21.3.60 ntp tcp
redirect-to 172.21.3.60 domain udp
redirect-to 172.21.3.60 domain tcp
redirect-to 172.21.3.60 syslog udp
ipmasqadm portfw -a -P udp -L 10.5.3.59 6222 -R 172.21.3.60 22
ipmasqadm portfw -a -P tcp -L 10.5.3.59 6222 -R 172.21.3.60 22
# ipmasqadm portfw -a -P udp -L 172.21.3.59 domain -R 10.5.3.64 domain
# ipmasqadm portfw -a -P tcp -L 172.21.3.59 domain -R 10.5.3.64 domain
# These two allow (partially) unrestricted access for a few hosts.
# These sorts of rules are *DANGEROUS* - they should *NEVER* *NEVER*
# be used on a system connected to the Internet. This configuration
# is walling off an internal private network from the rest of the
# corporate net.
# The first gives complete access to the network from the sysadmin's
# PC; the second and third give full access to one host for two
# other PCs.
unrestricted-access-inside 10.5.37.99 172.21.0.0/16
# unrestricted-access-inside 10.5.41.XX 172.21.3.73/32
# unrestricted-access-inside 10.5.41.YY 172.21.3.73/32
host-to-inside-server 10.5.8.4 172.21.3.73
#----------------------------------------
# TRAFFIC TO OUTSIDE SERVERS FROM INSIDE
#----------------------------------------
# -- Allow TCP connections... all at once for speed.... OR....
# allow-std-tcp telnet www smtp ntp
# -- Allow TCP connections... separate out for accounting
# allow-std-tcp telnet
# allow-std-tcp www
# allow-std-tcp smtp
# allow-std-tcp ntp
# allow-std-tcp telnet # separate for accounting
# allow-std-tcp ssh # separate for accounting
# -- Domain Name Services (DNS) - name lookups - you will NEED this!
# allow-named-to $NAMESERVER
dns-server
#----------------------------------------
# DEBUGGING RULES **** LEAVES FIREWALL WIDE-OPEN
#----------------------------------------
# Debugging OPENS THE FIREWALL ** WIDE OPEN ** ....
# But this is only for debugging; any packet not accepted or rejected
# by the firewall will be accepted by these rules. Thus the system
# remains operational, and you can see which rule is being matched by
# watching packet counts in the firewall status display, or looking
# in the system logs. NOTE that this might *FILL* your logs rapidly
# if there is a lot of traffic being logged instead of caught by
# firewall rules.
if [ "$OPEN_FIREWALL" = "1" ]; then
log-connects # log all connections made
fall-through # allows (and logs) all unhandled traffic from
# internal clients to external servers
allow-all # accept (and log) all remaining packets,
and
# set default policies to ACCEPT:
*WIDE OPEN*
else
reject-all # default rules
fi
}
> 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).
Most things I've seen fall into a couple of categories:
1) Seawall - variables and special configuration files - used
(actively) to create and configure a running firewall.
2) Other scripts - one-shot scripts used to create a firewall ruleset
which is then used at boot time. Want different rules? Re-run the
script and restart the firewall.
Many things also tend to use big monsters like Perl. I wanted to
create, as Charles rightly called it, a "firewall builder." Since
I'm comfortable with the shell, and also find a shell
program/function to much more flexible and configurable than
environment variables and special configuration files, this "firewall
builder" was a natural way for me to go.
Part of my problem seems to be the mixing of the three configurations
I want to support easily:
1) Exterior/Interior Router: Internet Firewall + DMZ
2) Exterior/Interior Router: Internet Firewall Only
3) Exterior/Interior Router: Internal Firewall Only
The first presents a problem of how to firewall the DMZ from the
outside, and how to firewall the DMZ from the inside.
The second is a standard configuration.
The third presents several problems: 1) now private IP addresses are
on both sides of the firewall; 2) unusual configurations may be
common - certain workstations may have FULL access, others limited
access, and other unusual configurations; 3) security rules can be
(SLIGHTLY!) more lax, since the "unprotected network" is actually
protected from the Big Bad Internet already.
This last is no excuse for good security, however....
Another thing I find terribly confusing is the "names" used for the
different networks - where is the "inside"? Where is the "outside"?
Where is "local"? Where is "remote"? I've started shifting to
thinking of the "unprotected" network and the "protected" network -
helps a lot.
--
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
