Copyright © 2002, 2003, 2004 Thomas M. Eastep
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.
2005/09/30
For a brief time, the 1.2 version of Shorewall supported an /etc/shorewall/whitelist file. This file was intended to contain a
list of IP addresses of hosts whose POLICY to all zones was ACCEPT. The whitelist file was implemented as a stop-gap measure until the
facilities necessary for implementing white lists using zones was in place. As of Version 1.3 RC1, those facilities were available.
White lists are most often used to give special privileges to a set of hosts within an organization. Let us suppose that we have the following environment:
A firewall with three interfaces -- one to the Internet, one to a local network and one to a DMZ.
The local network uses SNAT to the internet and is comprised of the Class B network 10.10.0.0/16 (Note: While this example uses an RFC 1918 local network, the technique described here in no way depends on that or on SNAT. It may be used with Proxy ARP, Subnet Routing, Static NAT, etc.).
The network operations staff have workstations with IP addresses in the Class C network 10.10.10.0/24.
We want the network operations staff to have full access to all other hosts.
We want the network operations staff to bypass the transparent HTTP proxy running on our firewall.
The basic approach will be that we will place the operations staff's class C in its own zone called ops. Here are the appropriate configuration files:
| ZONE | DISPLAY | COMMENTS |
|---|---|---|
net
| Net | Internet |
ops
| Operations | Operations Staff's Class C |
loc
| Local | Local Class B |
dmz
| DMZ | Demilitarized zone |
The ops zone has been added to the standard 3-zone zones
file -- since ops is a sub-zone of loc, we list it BEFORE
loc.
| ZONE | INTERFACE | BROADCAST | OPTIONS |
|---|---|---|---|
net
|
eth0
| <whatever> | <options> |
dmz
|
eth1
| <whatever> | |
-
|
eth2
|
10.10.255.255
|
Because eth2 interfaces to two zones (ops and loc), we don't specify a zone for it here.
| ZONE | HOST(S) | OPTIONS |
|---|---|---|
ops
|
eth2:10.10.10.0/24
| |
loc
|
eth2:0.0.0.0/0
|
Here we define the ops and loc zones. When Shorewall is stopped, only the hosts in the ops zone will be allowed to access the firewall and the DMZ. I use 0.0.0.0/0 to define the loc zone rather than 10.10.0.0/16 so that the limited broadcast address (255.255.255.255) falls into that zone. If I used 10.10.0.0/16 then I would have to have a separate entry for that special address.
| SOURCE | DEST | POLICY | LOG LEVEL | LIMIT BURST |
|---|---|---|---|---|
ops
|
all
|
ACCEPT
| ||
all
|
ops
|
CONTINUE
| ||
loc
|
net
|
ACCEPT
| ||
net
|
all
|
DROP
|
info
| |
all
|
all
|
REJECT
|
info
|
Two entries for ops (in bold) have been added to the standard 3-zone policy file.
| ACTION | SOURCE | DEST | PROTO | DEST PORT(S) | SOURCE PORT(S) | ORIGINAL DEST |
|---|---|---|---|---|---|---|
REDIRECT
|
loc!ops
|
3128
|
tcp
|
http
| ||
...
|
This is the rule that transparently redirects web traffic to the transparent proxy running on the firewall. The SOURCE column explicitly excludes the ops zone from the rule.
| INTERFACE | HOST(S)) |
|---|---|
eth1
| |
eth2
|
10.10.10.0/24
|