shorewall_code/docs/whitelisting_under_shorewall.xml

<?xml version="1.0" encoding="UTF-8"?>


<!-- $Id$ -->
<article id="whitelisting_under_shorewall">
  <articleinfo>
    <title>Whitelisting Under Shorewall</title>

    <author>
      <firstname>Tom</firstname>

      <surname>Eastep</surname>
    </author>

    <pubdate><?dbtimestamp format="Y/m/d"?></pubdate>

    <copyright>
      <year>2002-2005</year>

      <holder>Thomas M. Eastep</holder>
    </copyright>

    <legalnotice>
      <para>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
      <quote><ulink type="" url="copyright.htm">GNU Free Documentation
      License</ulink></quote>.</para>
    </legalnotice>
  </articleinfo>

  <para>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:</para>

  <itemizedlist mark="bullet" spacing="compact">
    <listitem>
      <para>A firewall with three interfaces -- one to the Internet, one to a
      local network and one to a <acronym>DMZ</acronym>.</para>
    </listitem>

    <listitem>
      <para>The local network uses <acronym>SNAT</acronym> to the internet and
      is comprised of the Class B network <literal>10.10.0.0/16</literal>
      (Note: While this example uses an RFC 1918 local network, the technique
      described here in no way depends on that or on <acronym>SNAT</acronym>.
      It may be used with Proxy <acronym>ARP</acronym>, Subnet Routing, Static
      NAT, etc.).</para>
    </listitem>

    <listitem>
      <para>The network operations staff have workstations with IP addresses
      in the Class C network <literal>10.10.10.0/24</literal>.</para>
    </listitem>

    <listitem>
      <para>We want the network operations staff to have full access to all
      other hosts.</para>
    </listitem>

    <listitem>
      <para>We want the network operations staff to bypass the transparent
      <acronym>HTTP</acronym> proxy running on our firewall.</para>
    </listitem>
  </itemizedlist>

  <para>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:</para>

  <!-- Zone File -->

  <bridgehead renderas="sect4">Zone File</bridgehead>

  <programlisting>#ZONE      TYPE          OPTIONS
fw         firewall
net        ipv4
ops        ipv4
loc        ipv4
dmz        ipv4</programlisting>

  <para>The <literal>ops</literal> zone has been added to the standard 3-zone
  zones file -- since <literal>ops</literal> is a sub-zone of
  <literal>loc</literal>, we list it <emphasis>BEFORE</emphasis>
  <literal>loc</literal>.</para>

  <!-- Interfaces File -->

  <bridgehead renderas="sect4">Interfaces File</bridgehead>

  <programlisting>#ZONE      INTERFACE        BROACAST        OPTIONS
net        eth0             &lt;whatever&gt;      ...
dmz        eth1             &lt;whatever&gt;      ...
-          eth2             10.10.255.255</programlisting>

  <para>Because <literal>eth2</literal> interfaces to two zones
  (<literal>ops</literal> and <literal>loc</literal>), we don't specify a zone
  for it here.</para>

  <!-- Hosts File -->

  <bridgehead renderas="sect4">Hosts File</bridgehead>

  <programlisting>#ZONE      HOST(S)                OPTIONS
ops        eth2:10.10.10.0/24
loc        eth2:0.0.0.0/0</programlisting>

  <para>Here we define the <literal>ops</literal> and <literal>loc</literal>
  zones. When Shorewall is stopped, only the hosts in the
  <literal>ops</literal> zone will be allowed to access the firewall and the
  <acronym>DMZ</acronym>. I use <literal>0.0.0.0/0</literal> to define the
  <literal>loc</literal> zone rather than <literal>10.10.0.0/16</literal> so
  that the limited broadcast address (<literal>255.255.255.255</literal>)
  falls into that zone. If I used <literal>10.10.0.0/16</literal> then I would
  have to have a separate entry for that special address.</para>

  <!-- Policy File -->

  <bridgehead renderas="sect4">Policy File</bridgehead>

  <programlisting>#SOURCE          DEST         POLICY         LOG LEVEL
<emphasis role="bold">ops              all          ACCEPT
all              ops          CONTINUE</emphasis>
loc              net          ACCEPT
net              all          DROP           info
all              all          REJECT         info</programlisting>

  <para>Two entries for <literal>ops</literal> (in bold) have been added to
  the standard 3-zone policy file.</para>

  <!-- Rules File -->

  <bridgehead renderas="sect4">Rules File</bridgehead>

  <programlisting>#ACTION   SOURCE      DEST        PROTO        DEST PORT(S)     SOURCE PORTS(S)    ORIGINAL DEST
REDIRECT  loc!ops     3128        tcp          http</programlisting>

  <para>This is the rule that transparently redirects web traffic to the
  transparent proxy running on the firewall. The <emphasis
  role="bold">SOURCE</emphasis> column explicitly excludes the
  <literal>ops</literal> zone from the rule.</para>

  <!-- Routestopped File -->

  <bridgehead renderas="sect4">Routestopped File</bridgehead>

  <programlisting>#INTERFACE          HOST(S)           OPTIONS
eth1
eth2                10.10.10.0/24</programlisting>
</article>