transparent firewall
Here is the article I found.
It answers my questions very nicely.
I'd like to see this combined with fipra or instructions comparing them.
Linux Journal Home > Articles > Miscellaneous #41
Wednesday, March 14, 2001 | Last Updated 02:51pm
Database Solutions since 1979 - FairCom Corp.
MISCELLANEOUS
Building a Bridging Firewall with Linux
by Henry Stilmack <hps@shangri-la.cx>
14-March-2001
The Joint Astronomy Center operates two telescopes on the 14,000-foot
summit of Mauna Kea on the island of Hawaii, as well offices and a
base facility in the city of Hilo. Our Internet connection is provided
by the University of Hawaii, and we are assigned three subnets within
the University's Class B address range. Until recently, our network
security needs have been satisfied by a combination of port and
address filtering at our border routers and host-based access controls
(tcpwrappers) on our Solaris and Linux hosts. A recent audit by our
parent funding body in the UK strongly recommended the installation of
a firewall for further protection. Upon examining several proprietary
and open-source solutions, we found a major drawback to many of them
was the requirement that our internal networks would need to be
renumbered into a private address range, as per RFC 1918. With over
200 systems on three different subnets, some of which are embedded
microprocessors that would require burning new EEPROMs, this was a
daunting task. So we began searching for a way to implement a
transparent firewall that would allow us to retain all of our current
addresses, yet still offer good protection.
The Linux kernels v2.2 and higher have support for Ethernet bridging.
In a bridge, all packets received by one interface are passed to the
other, without regard to source or destination IP address, by
examining the Ethernet MAC destination address of the packet. AC2I, a
French company, distributes a kernel patch that allows the ipchains
packet filter to work on the bridged interfaces. This configuration
allows you to set up a firewall system that is invisible to the
Internet, yet provides a high level of protection and access control
for your private network. The remainder of this article explains the
steps necessary to get a bridging firewall up and running.
Hardware Configuration
To perform as an effective firewall and network monitor, a CPU must be
sufficiently fast. The prototype system was built on a 500MHz Celeron
processor with 256MB of memory. Tests show the bridge can keep up with
a fully-saturated 10MB/s Ethernet, with no lost packets. Install two
additional Network Interface Cards (NICs), because you will need two
for the bridge and a third for administering the firewall.
Disk capacity is not particularly important, as all logging should be
to a secure syslog server. If you want to maintain some local logging
(useful for some of the configuration and monitoring tools), ensure an
abundance of free space--firewall and intrusion detection system (IDS)
logs can get very large, very quickly.
Installing Linux
The following sections are based on the Linux 2.2.16 kernel (Red Hat
7.0 distribution). When the 2.4 kernel is released, instead of
ipchains, the iptables package will be used for firewalling as the
kernel firewall code changes.
Perform a standard Linux installation, but deselect almost everything.
Do not even install inetd/xinetd--you are not going to run any
services on this system. Do not install any compilers/development
tools. If, however unlikely, someone does manage to gain access to the
firewall, you do not want them to be (easily) able to rebuild any
binaries. Do install Perl (for some of the reporting tools) and
OpenSSH (for remote administration). Make sure you install the
ipchains package--this is needed for the firewall setup. A web browser
can be useful, and NTP can't hurt as long as you only accept time
updates from inside the protected net. You will probably want your
favorite editor(s), and maybe some X11 applications (xterm, gtop,
etc.). Install network monitoring packages (whois, finger, tcpdump,
traceroute, nc) and tcpwrappers. Create a non-root administrator user
and use this account for all logins. Perform the installation with
either no network connection at all or with the primary NIC connected
to an otherwise empty hub or switch.
At installation, only configure the primary Ethernet interface--the
one that will be a part of the protected network--and give it a fixed
IP address. When the system reboots after installation, type linux 1
at the LILO boot: prompt to boot into single-user mode, and then put a
line into /etc/hosts.allow for sshd to allow access only from a
specified internal-network workstation. Then reboot into runlevel 3.
It is now safe to connect the primary Ethernet interface to the
internal network.
Building the Bridging Kernel
This step must be performed on some other system with the same kernel
version as is installed on the firewall. You will do a standard Linux
kernel configuration, disabling most features and enabling the
bridging code.
Change directory to /usr/src. Copy the kernel source tree to another
directory:
# mkdir linux-fw;cd linux-2.2.16;tar cf - . |
# (cd ../linux-fw;tar xpf -);<\\>
cd ..; rm linux;ln -s ./linux-fw linux
Apply the linux_brfw2 patch. This patch adds a new built-in bridgein
chain to ipchains. This is the chain you will use for the bridging
firewall. This patch can be obtained from
http://ac2i.tzo.com/bridge_filter/linux_brfw2.diff:
# patch -p0 <linux_brfw2.diff
Change directory to /usr/src/linux and configure the kernel. You
should definitely read the kernel how-to document at
http://www.redhat.com/mirrors/LDP/HOWTO/Kernel-HOWTO.html before
performing this step. The relevant configuration options are:
CONFIG_MODVERSIONS=N
CONFIG_FIREWALL=Y
CONFIG_FILTER=Y
CONFIG_IP_FIREWALL=Y
CONFIG_IP_FIREWALL_NETLINK=Y
CONFIG_IP_ROUTE_FWMARK=Y
CONFIG_BRIDGE=Y
Create a temporary directory somewhere to hold the new kernel and
system map, and uncomment the INSTALL_PATH= line in
/usr/src/linux/Makefile to reflect this location (you don't want to
overwrite your running kernel!). Also, edit /sbin/installkernel in the
same way.
# make dep;make clean;make bzImage install
Copy vmlinuz-2.2.xx-yy and System.map-2.2.xx-yy from your temporary
directory to /boot on the firewall, being sure to first move any
existing files by the same name. Login to the firewall, change
directory to /boot, and link vmlinuz and System.map to the new files.
Edit /etc/lilo.conf adding a new image section:
image=/boot/vmlinuz
label=firewall
read-only
root=/dev/hda1
Run LILO and lilo -D firewall make the new kernel the default, and
reboot the firewall system.
Set up the Bridge
Log in to the firewall system. Assuming you used eth0 as your primary
interface, ifconfig -a should show what you see in Listing 1 (of
course, the MAC addresses will be different).
Listing 1. Results of ifconfig -a
To get bridging to work, you need the brcfg application. The source
code for this application is available from Matthew Grant of the Linux
Router Project at http://lrp.plain.co.nz/tarballs/bridgex_0.30.tar.gz.
Compile the binary on a system with the same kernel version as the
firewall, and copy it to /usr/sbin/brcfg on the firewall system. The
following commands should then get the bridge up and running:
# ifconfig eth1 promisc up
# ifconfig eth2 promisc up
# brcfg start
# brcfg device eth1 enable
# brcfg device eth2 enable
After the few minutes it takes for the bridge to learn what addresses
are on either side, you should be able to pass packets across the
eth1<-&rt;eth2 bridge transparently.
Firewall Configuration
The firewall itself is implemented using the ipchains package. The
kernel patch above adds a new built-in chain (bridgein) to the
standard chains, which examines any packets seen on either of the
bridge interfaces. Since this is an input chain, each rule must
specify the interface--packets are matched according to which
interface they see first. The default policy for each chain is set to
ACCEPT, rules are added to the bridgein chain to implement the access
policy, and a final DENY rule is added to catch anything not
explicitly allowed.
The access policy for the firewall is designed around network topology
(see Figure 1).
Alternate Text
The salient features of this design are:
All public servers (HTTPD, FTP, SMTP, SSH) are located outside the
firewall.
All traffic from the Internet destined for internal machines must
pass through the firewall.
In general, traffic originating on the protected LAN and destined
for the public servers is unrestricted.
Traffic originating on the protected LAN and destined for the
Internet is generally allowed.
Traffic originating on the public servers and destined for the
protected LAN is restricted to those services which are actually
needed by the public servers (NFS exports to the LAN, SMTP from
the public SMTP server to an internal mail hub, SSH from the SSH
server to internal hosts).
Traffic originating from the Internet and destined for internal
systems is generally blocked. Packets are allowed if they are (a)
destined for an unprivileged port or a well-known server and (b)
not initiating a connection (TCP SYN flag not set).
Listing 2 is an annotated script to set up the bridging firewall in
accordance with these policies.
Listing 2. Annotated Script for Bridging Firewall Setup
For more information on ipchains and writing rules, see the man page
and/or the IPCHAINS HOWTO at
http://www.redhat.com/mirrors/LDP/HOWTO/IPCHAINS-HOWTO.html.
Other Tools
A useful addition to the firewall system is the snort intrusion
detection system (IDS) suite of programs. Snort is a set of packet
filtering rules designed to detect the majority of network intrusion
methods which are commonly seen. A large community of developers and
analysts is continually updating the rulesets as new attack methods
are discovered. Snort can be configured to send its alerts to a
logfile, syslog or via e-mail or pager to administrators. It can even
be configured to add ipchains blocking rules in response to a detected
intrusion attempt--although this feature should only be used if you
are sure you can weed out false-positive hits. Snort, along with
various contributed scripts for presenting the log output in readable
form, is available at http://www.snort.org.
Gfcc is a nice Gtk+-based GUI for viewing and modifying your firewall
rules. It can be found at http://icarus.autostock.co.kr/.
Boot Configuration
The bridge and firewall should be started immediately after
networking. The script in Listing 3 starts the firewall, sets up and
starts the bridge, then starts snort. It assumes the firewall script
is in /etc/firewall, and should be installed in
/etc/rc.d/init.d/bridge. After installing the script, run chkconfig
bridge on to install the proper runlevel links.
Listing 3. Script for Starting the Firewall
Uses
A filtering bridge is useful in a number of situations. It is a quick
and easy way to add a firewall to an existing LAN without having to
change any IP addresses or use NAT. It can also be used to create
protected or restricted subnets on a LAN. For example, if you have
frequent visitors who need Internet access, you can put them behind a
bridging firewall configured to allow them access to the Internet, but
not to any hosts on your LAN. It can be used to protect a DSL or cable
modem connection. Since the bridge interfaces do not run an IP
protocol stack, they are immune from many of the common intrusion and
denial-of-service attacks.
Henry Stilmack has been a UNIX system administrator for over 10 years.
He lives in Hawaii with a spouse, two dogs, four cats and uncountable
geckos. He can be contacted at hps@shangri-la.cx.
Copyright 2001 Specialized Systems Consultants, Inc.
_________________________________________________________________
Tell us what you think of this article ...
(_) Yes, more articles like this one! (_) No, do not cover this
topic.
(_) Too technical (_) Good balance (_) not technical enough
Comments:
_______________________________________________________
_______________________________________________________
_______________________________________________________
_______________________________________________________
E-mail address: ____________________ (Optional)
Submit comment Clear form and start over
Reply to: