[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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. 
                  Building a Bridging Firewall with Linux
                   by Henry Stilmack <hps@shangri-la.cx>
   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
   # 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
  # 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:
   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:

   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
       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
  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
   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
   (_) Too technical    (_) Good balance    (_) not technical enough
   E-mail address: ____________________   (Optional)
   Submit comment   Clear form and start over

Reply to: