shorewall_code/docs/Introduction.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
<article id="usefull_links">
  <!--$Id$-->

  <articleinfo>
    <title>Introduction</title>

    <author>
      <firstname>Tom</firstname>

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

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

    <copyright>
      <year>2003-2020</year>

      <year>2019</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>

  <section id="Intro">
    <title>Introduction</title>

    <para>The information in this document applies only to 4.3 and later
    releases of Shorewall.</para>

    <section id="Glossary">
      <title>Glossary</title>

      <itemizedlist>
        <listitem>
          <para><ulink url="http://www.netfilter.org">Netfilter</ulink> - the
          packet filter facility built into the 2.4 and later Linux
          kernels.</para>
        </listitem>

        <listitem>
          <para>ipchains - the packet filter facility built into the 2.2 Linux
          kernels. Also the name of the utility program used to configure and
          control that facility. Netfilter can be used in ipchains
          compatibility mode.</para>
        </listitem>

        <listitem>
          <para>iptables - the utility program used to configure and control
          Netfilter. The term <quote>iptables</quote> is often used to refer
          to the combination of iptables+Netfilter (with Netfilter not in
          ipchains compatibility mode).</para>
        </listitem>

        <listitem>
          <para>iptables-restore - a program included with iptables that
          allows for atomic installation of a set of Netfilter rules. This is
          a much more efficient way to install a rule set than running the
          iptables utility once for each rule in the rule set.</para>
        </listitem>

        <listitem>
          <para>ifconfig - An obsolete program included in the net-utils
          package. ifconfig was used to configure network interfaces.</para>
        </listitem>

        <listitem>
          <para>route - An obsolete program included in the net-utils package.
          route was used to configure routing.</para>
        </listitem>

        <listitem>
          <para>ip - A program included in the iproute2 package. ip replaces
          ifconfig and route in modern Linux systems.</para>
        </listitem>

        <listitem>
          <para>tc - A program included in the iproute2 package. tc is used to
          configure QOS/Traffic Shaping on Linux systems.</para>
        </listitem>
      </itemizedlist>
    </section>

    <section id="Shorewall">
      <title>What is Shorewall?</title>

      <para>The Shoreline Firewall, more commonly known as
      <quote>Shorewall</quote>, is high-level tool for configuring Netfilter.
      You describe your firewall/gateway requirements using entries in a set
      of configuration files. Shorewall reads those configuration files and
      with the help of the iptables, iptables-restore, ip and tc utilities,
      Shorewall configures Netfilter and the Linux networking subsystem to
      match your requirements. Shorewall can be used on a dedicated firewall
      system, a multi-function gateway/router/server or on a standalone
      GNU/Linux system. Shorewall does not use Netfilter's ipchains
      compatibility mode and can thus take advantage of Netfilter's connection
      state tracking capabilities.</para>

      <para>Shorewall is not a daemon. Once Shorewall has configured the Linux
      networking subsystem, its job is complete and there is no
      <quote>Shorewall process</quote> left running in your system. The <ulink
      url="starting_and_stopping_shorewall.htm">/sbin/shorewall program can be
      used at any time to monitor the Netfilter firewall</ulink>.</para>

      <para>Shorewall is not the easiest to use of the available iptables
      configuration tools but I believe that it is the most flexible and
      powerful. So if you are looking for a simple point-and-click
      set-and-forget Linux firewall solution that requires a minimum of
      networking knowledge, I would encourage you to check out the following
      alternatives:</para>

      <itemizedlist>
        <listitem>
          <para><ulink url="https://help.ubuntu.com/community/UFW">UFW
          (Uncomplicated Firewall)</ulink></para>
        </listitem>

        <listitem>
          <para><ulink url="https://comparite.ch/free-firewall">Other free
          firewalls</ulink></para>
        </listitem>
      </itemizedlist>

      <para>If you are looking for a Linux firewall solution that can handle
      complex and fast changing network environments then Shorewall is a
      logical choice.</para>
    </section>
  </section>

  <section id="Concepts">
    <title>Shorewall Concepts</title>

    <para>The configuration files for Shorewall are contained in the directory
    <filename class="directory">/etc/shorewall</filename> -- for simple
    setups, you will only need to deal with a few of them.</para>

    <para>Shorewall views the network where it is running as being composed of
    a set of <firstterm>zones</firstterm>. Zones are declared and given a type
    in the <ulink url="manpages/shorewall-zones.html"><filename
    class="directory">/etc/shorewall/</filename><filename>zones</filename></ulink>
    file.Here is the <ulink url="manpages/shorewall-zones.html"><filename
    class="directory">/etc/shorewall/</filename><filename>zones</filename></ulink>
    file from the three-interface sample:</para>

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

    <para>Note that Shorewall recognizes the firewall system as its own zone.
    The name of the zone designating the firewall itself (usually 'fw' as
    shown in the above file) is stored in the shell variable
    $<firstterm>FW</firstterm> which may be used throughout the Shorewall
    configuration to refer to the firewall zone.</para>

    <para>The simplest way to define the hosts in a zone is to associate the
    zone with a network interface using the <ulink
    url="manpages/shorewall-interfaces.html"><filename>/etc/shorewall/interfaces</filename></ulink>
    file. In the three-interface sample, the three zones are defined using
    that file as follows:</para>

    <programlisting>#ZONE   INTERFACE       OPTIONS
net     NET_IF          tcpflags,dhcp,nosmurfs,routefilter,logmartians,sourceroute=0,physical=eth0
loc     LOC_IF          tcpflags,nosmurfs,routefilter,logmartians,physical=eth1
dmz     DMZ_IF          tcpflags,nosmurfs,routefilter,logmartians,physical=eth2</programlisting>

    <para>The above file defines the <emphasis>net</emphasis> zone as all IPv4
    hosts interfacing to the firewall through NET_IF, the
    <emphasis>loc</emphasis> zone as all IPv4 hosts interfacing through LOC_IF
    and the <emphasis>dmz</emphasis> as all IPv4 hosts interfacing through
    eth2. The interface names shown in the INTERFACE column are <emphasis>
    logical</emphasis> names which are used throughout the configuration to
    refer to the individual interfaces. The actual interface names are
    specified using the <emphasis role="bold">physical</emphasis> option. It
    is important to note that the composition of a zone is defined in terms of
    a combination of addresses <emphasis role="bold">and</emphasis>
    interfaces. When using the <ulink
    url="manpages/shorewall-interfaces.html"><filename>/etc/shorewall/interfaces</filename></ulink>
    file to define a zone, all addresses are included; when you want to define
    a zone that contains a limited subset of the IPv4 address space, you use
    the <ulink
    url="manpages/shorewall-hosts.html"><filename>/etc/shorewall/hosts</filename></ulink>
    file or you may use the nets= option in
    <filename>/etc/shorewall/interfaces</filename>:</para>

    <programlisting>#ZONE   INTERFACE       OPTIONS
net     NET_IF          tcpflags,dhcp,nosmurfs,routefilter,logmartians,sourceroute=0,physical=eth0
loc     LOC_IF          tcpflags,nosmurfs,routefilter,logmartians,physical=eth1,<emphasis
        role="bold">nets=172.20.1.0/24</emphasis>
dmz     DMZ_IF          tcpflags,nosmurfs,routefilter,logmartians,physical=eth2
</programlisting>

    <para>The above file defines the <emphasis>net</emphasis> zone as all IPv4
    hosts interfacing to the firewall through eth0 <emphasis>except</emphasis>
    for 192.168.0.0/23, the <emphasis>loc</emphasis> zone as IPv4 hosts
    192.168.0.0/24 interfacing through eth1 and the <emphasis>dmz</emphasis>
    as IPv4 hosts 192.168.1.0/24 interfacing through eth2 (Note that
    192.168.0.0/24 together with 192.168.1.0/24 comprises
    192.168.0.0/23).</para>

    <para>Note that the names NET_IF, LOC_IF and DMZ_IF are <emphasis>logical
    interface names</emphasis> which are mapped to actual physical network
    interfaces using the <emphasis role="bold">physical=</emphasis> option in
    each interface file entry.</para>

    <para>Rules about what traffic to allow and what traffic to deny are
    expressed in terms of zones. <itemizedlist spacing="compact">
        <listitem>
          <para>You express your default policy for connections from one zone
          to another zone in the <ulink
          url="manpages/shorewall-policy.html"><filename
          class="directory">/etc/shorewall/</filename><filename>policy</filename></ulink>
          file. The basic choices for policy are:</para>

          <itemizedlist>
            <listitem>
              <para>ACCEPT - Accept the connection.</para>
            </listitem>

            <listitem>
              <para>DROP - Ignore the connection request.</para>
            </listitem>

            <listitem>
              <para>REJECT - Return an appropriate error to the connection
              request.</para>
            </listitem>
          </itemizedlist>

          <para>Connection request logging may be specified as part of a
          policy and it is conventional (and highly recommended) to log DROP
          and REJECT policies.</para>
        </listitem>

        <listitem>
          <para>You define exceptions to these default policies in the <ulink
          url="manpages/shorewall-rules.html"><filename
          class="directory">/etc/shorewall/</filename><filename>rules</filename></ulink>
          file.</para>
        </listitem>

        <listitem>
          <para>You only need concern yourself with connection requests. You
          don't need to define rules for handling traffic that is part of an
          established connection and in most cases you don't have to worry
          about how related connections are handled (ICMP error packets and
          <ulink url="FTP.html">related TCP connection requests such as used
          by FTP</ulink>).</para>
        </listitem>
      </itemizedlist>For each connection request entering the firewall, the
    request is first checked against the <filename
    class="directory">/etc/shorewall/</filename><filename>rules</filename>
    file. If no rule in that file matches the connection request then the
    first policy in <filename
    class="directory">/etc/shorewall/</filename><filename>policy</filename>
    that matches the request is applied. If there is a default action defined
    for the policy in<filename> <ulink
    url="manpages/shorewall.conf.html">/etc/shorewall/shorewall.conf</ulink></filename>
    then that action is invoked before the policy is enforced. In the standard
    Shorewall distribution, the DROP policy has a default action called
    <emphasis role="bold">Drop</emphasis> and the REJECT policy has a default
    action called <emphasis role="bold">Reject</emphasis>. Default actions are
    used primarily to discard certain packets silently so that they don't
    clutter up your log.</para>

    <para>The <filename
    class="directory">/etc/shorewall/</filename><filename>policy</filename>
    file included with the three-interface sample has the following policies:
    <programlisting>#SOURCE    DEST        POLICY      LOGLEVEL    LIMIT
loc        net         ACCEPT
net        all         DROP        info
all        all         REJECT      info</programlisting>In the three-interface
    sample, the line below is included but commented out. If you want your
    firewall system to have full access to servers on the Internet, uncomment
    that line. <programlisting>#SOURCE    DEST        POLICY      LOGLEVEL    LIMIT
$FW        net         ACCEPT</programlisting> The above policies will:
    <itemizedlist>
        <listitem>
          <para>Allow all connection requests from your local network to the
          Internet</para>
        </listitem>

        <listitem>
          <para>Drop (ignore) all connection requests from the Internet to
          your firewall or local networks; these ignored connection requests
          will be logged using the <emphasis>info</emphasis> syslog priority
          (log level).</para>
        </listitem>

        <listitem>
          <para>Optionally accept all connection requests from the firewall to
          the Internet (if you uncomment the additional policy)</para>
        </listitem>

        <listitem>
          <para>reject all other connection requests; these rejected
          connection requests will be logged using the
          <emphasis>info</emphasis> syslog priority (log level).</para>
        </listitem>
      </itemizedlist></para>

    <para>A word about Shorewall logging is in order. Shorewall does not have
    direct control over where its messages are logged; that is determined by
    the configuration of the logging daemon (syslog, rsyslog, syslog-ng,
    ulogd, etc.). The LOGFILE setting in <ulink
    url="manpages/shorewall.conf.html">/etc/shorewall/shorewall.conf</ulink>
    tells Shorewall <emphasis>where to find the log</emphasis>; it doesn't
    determine where messages are logged. See the <ulink
    url="shorewall_logging.html">Shorewall logging article</ulink> for more
    information.</para>

    <para>To illustrate how rules provide exceptions to policies, suppose that
    you have the polices listed above but you want to be able to connect to
    your firewall from the Internet using Secure Shell (SSH). Recall that SSH
    connects using TCP port 22. You would add the following rule to <ulink
    url="manpages/shorewall-rules.html"><filename
    class="directory">/etc/shorewall/</filename><filename>rules</filename>:</ulink></para>

    <programlisting>#ACTION    SOURCE        DEST      PROTO      DPORT
ACCEPT     net           $FW       tcp        22</programlisting>

    <para>So although you have a policy of ignoring all connection attempts
    from the net zone (from the Internet), the above exception to that policy
    allows you to connect to the SSH server running on your firewall.</para>

    <para>Because Shorewall makes no assumptions about what traffic you want
    accepted, there are certain rules (exceptions) that need to be added to
    almost any configuration.</para>

    <itemizedlist>
      <listitem>
        <para>The <ulink url="shorewall_quickstart_guide.htm">QuickStart
        guides</ulink> point to pre-populated files for use in common setups
        and the <ulink url="shorewall_setup_guide.htm">Shorewall Setup
        Guide</ulink> shows you examples for use with other more complex
        setups.</para>
      </listitem>

      <listitem>
        <para>Again, to keep your <ulink url="shorewall_logging.html">firewall
        log</ulink> from filling up with useless noise, Shorewall provides
        <ulink url="Actions.html">common actions</ulink> that silently discard
        or reject such noise before it can be logged. As with everything in
        Shorewall, you can alter the behavior of these common actions (or do
        away with them entirely) as you see fit.</para>
      </listitem>
    </itemizedlist>
  </section>

  <section id="Compile">
    <title>Compile then Execute</title>

    <para>Shorewall uses a "compile" then "execute" approach. The Shorewall
    configuration compiler reads the configuration files and generates a shell
    script. Errors in the compilation step cause the script to be discarded
    and the command to be aborted. If the compilation step doesn't find any
    errors then the shell script is executed.</para>

    <para>The 'compiled' scripts are placed by default in the directory
    <filename class="directory">/var/lib/shorewall</filename> and are named to
    correspond to the command being executed. For example, the command
    <command>/sbin/shorewall start</command> will generate a script named
    <filename>/var/lib/shorewall/.start</filename> and, if the compilation is
    error free, that script will then be executed. If the script executes
    successfully, it then copies itself to
    <filename>/var/lib/shorewall/firewall</filename>. When an
    <command>/sbin/shorewall stop</command> or <command>/sbin/shorewall
    clear</command> command is subsequently executed,
    <filename>/var/lib/shorewall/firewall</filename> is run to perform the
    requested operation.</para>

    <para>The AUTOMAKE option in /etc/shorewall/shorewall.conf may be set to
    automatically generate a new script when one of the configuration files is
    changed. When no file has changed since the last compilation, the
    <command>/sbin/shorewall start</command>, <command>/sbin/shorewall
    reload</command> and <command>/sbin/shorewall restart</command> commands
    will simply execute the current
    <filename>/var/lib/shorewall/firewall</filename> script.</para>
  </section>

  <section id="Packages">
    <title>Shorewall Packages</title>

    <para>Shorewall 4.5 and later consists of six packages.</para>

    <orderedlist>
      <listitem>
        <para><emphasis role="bold">Shorewall-core</emphasis>. All of the
        other packages depend on this one.</para>
      </listitem>

      <listitem>
        <para><emphasis role="bold">Shorewall</emphasis>. This package must be
        installed on at least one system in your network. It contains
        everything needed to create an IPv4 firewall.</para>
      </listitem>

      <listitem>
        <para><emphasis role="bold">Shorewall6</emphasis>. This package
        requires the Shorewall package and adds those components needed to
        create an IPv6 firewall.</para>
      </listitem>

      <listitem>
        <para><emphasis role="bold">Shorewall-lite</emphasis>. Shorewall
        allows for central administration of multiple IPv4 firewalls through
        use of Shorewall lite. The full Shorewall product is installed on a
        central administrative system where compiled Shorewall scripts are
        generated. These scripts are copied to the firewall systems where they
        run under the control of Shorewall-lite.</para>
      </listitem>

      <listitem>
        <para><emphasis role="bold">Shorewall6-lite</emphasis>. Shorewall
        allows for central administration of multiple IPv6 firewalls through
        use of Shorewall6 lite. The full Shorewall and Shorewall6 products are
        installed on a central administrative system where compiled Shorewall
        scripts are generated. These scripts are copied to the firewall
        systems where they run under the control of Shorewall6-lite.</para>
      </listitem>

      <listitem>
        <para><emphasis role="bold">Shorewall-init</emphasis>. May be
        installed with any of the other firewall packages. Allows the firewall
        to be closed prior to bringing up network interfaces. It can also
        react to interface up/down events.</para>
      </listitem>
    </orderedlist>
  </section>

  <section id="License">
    <title>License</title>

    <para>This program is free software; you can redistribute it and/or modify
    it under the terms of <ulink
    url="http://www.gnu.org/licenses/gpl.html">Version 2 of the GNU General
    Public License</ulink> as published by the Free Software
    Foundation.</para>

    <para>This program is distributed in the hope that it will be useful, but
    WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
    or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
    for more detail.</para>

    <para>You should have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software Foundation,
    Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.</para>
  </section>
</article>