Attachment #49379 for bug #75422

View | Details | Raw Unified | Return to bug 75422
Collapse All | Expand All




    <para>There are two basic ways to create firewall rulesets:
      <quote>inclusive</quote> or <quote>exclusive</quote>.  An
      exclusive firewall allows all traffic through except for the
      traffic matching the rule set.  An inclusive firewall does the
      reverse.  It only allows traffic matching the rules through and
      blocks everything else.</para>


  <sect1 id="firewalls-apps">
    <title>Firewall Software Applications</title>

    <para>&os; has three different firewall software products built
      into the base system. They are IPFILTER (also known as IPF),
      IPFIREWALL (also known as IPFW) and PF (OpenBSD's PacketFilter).
      IPFIREWALL has the built in DUMMYNET traffic shaper facilities
      for controlling bandwidth usage. IPFILTER does not have a built
      in traffic shaper facility for controlling bandwidth usage, but
      the ALTQ framework can be used to accomplish the same
      function.  The DUMMYNET feature and <acronym>ALTQ</acronym> is
      generally useful only to large ISPs or commercial users.  IPF,
      IPFW and PF use rules to control the access of packets to and
      from your system, although they go about it different ways and
      have different rule syntaxes.</para>

    <para>The IPFW sample rule set (found in
      <filename>/etc/rc.firewall</filename>) delivered in the basic

      known as <acronym>PF</acronym> was ported to &os;&nbsp;5.3.
      <acronym>PF</acronym> is a complete, fully featured firewall
      that contains <acronym>ALTQ</acronym> for bandwidth usage
      management in a way similar to what DUMMYNET provides for
      <acronym>IPFW</acronym>.  The OpenBSD project does an
      outstanding job of maintaining the PF user's guide that it will
      not be made part of this handbook firewall section as that would
      just be duplicated effort.</para>


    <sect2>
      <title>Enabling PF</title>
      <para>PF is included in the basic &os; install for versions newer than
        5.3 as a separate run time loadable module. The system will
        dynamically load PF kernel loadable module when the rc.conf
        statement <literal>pf_enable="YES"</literal> is used. The
        loadable module was created with &man.pflog.4; logging
        enabled.</para>
    </sect2>

      <para><literal>device pfsync</literal> enables the optional
        &man.pfsync.4; pseudo network device that is used to monitor
        <quote>state changes</quote>. As this is not part of the loadable
        module a custom kernel is needed to use it.</para>

      <para>These settings will take affect only after you have built and
                installed a kernel with them set.</para>

    <title>The IPFILTER (IPF) Firewall</title>

    <para>The author of IPFILTER is Darren Reed. IPFILTER is not
      operating system dependent: is a open source application and has
      been ported to &os;, NetBSD, OpenBSD, SunOS, HP/UX, and Solaris
      operating systems. IPFILTER is actively being supported and
      maintained, with updated versions being released regularly.</para>
      regularly.</para>

    <para>IPFILTER is based on a kernel-side firewall and
      <acronym>NAT</acronym> mechanism that can be controlled and

      and also control the services which can originate from the
      public Internet accessing your private network. Everything else
      is blocked and logged by default design. Inclusive firewalls are
      much, much more secure than exclusive ones and only this rule
      set type is covered here.</para>

    <para>For a detailed explanation of the legacy rules processing
      method see: <ulink
      url="http://www.obfuscation.org/ipf/ipf-howto.html#TOC_1"></ulink>
      and <ulink

      url="http://www.phildev.net/ipf/index.html"></ulink>.</para>

    <sect2>
      <title>Enabling IPF</title> 
      <para>IPF is included in the basic &os; install as a separate
        run time loadable module. The system will dynamically load IPF
        kernel loadable module when the rc.conf statement <literal>
        ipfilter_enable="YES"</literal> is used. The loadable module
        was created with logging enabled and the <literal>default pass
        all</literal> option. You do not need to compile IPF into the
        &os; kernel just to change the default to <literal>block all
        </literal>, you can do that by just coding a <literal>block
        all</literal> rule at the end of your rule set.</para> 
    </sect2>

    <sect2>

options IPFILTER_LOG
options IPFILTER_DEFAULT_BLOCK</programlisting>

      <para><literal>options IPFILTER</literal> enables support for
      the <quote>IPFILTER</quote> firewall.</para>

      <para><literal>options IPFILTER_LOG</literal> enables the
        option to have IPF log traffic by writing to the ipl packet


     <programlisting><command>ipf -Fa -f /etc/ipf.rules</command></programlisting>

     <para><option>-Fa</option> means "flush all internal rules tables".</para>
     <para><option>-f</option> means "this is the file to read for the
     rules to load".</para>

     <para>This gives you the ability to make changes to a custom
       rules file. Run the above IPF command thus updating the running
       firewall with a fresh copy of all the rules without having to
       reboot the system. This method is very convenient for testing
       new rules as the procedure can be executed as many times as
       needed.  </para>
     <para>See the &man.ipf.8; manual page for details on the other flags
       available with this command.</para>

       standard text file. It will not accept a rules file written as a
       script with symbolic substitution.</para>

     <para>There is a way to build IPF rules that use the power of
       script symbolic substitution.  For more information, see <xref
       linkend="firewalls-ipfw-rules-script">.</para>
     </sect2>

     <sect2>
       <title>IPMON Logging</title>

       <para>Syslogd uses its own special method for aggregation of log
         data. It uses special grouping called <quote>facility</quote>
         and <quote>level.</quote> IPMON in <option>-Ds</option> mode uses Local0 as the
         <quote>facility</quote> name. All IPMON logged data goes to


       <programlisting><command>touch /var/log/ipfilter.log</command></programlisting>

       <para>The syslog function is controlled by definition
         statements in the <filename>/etc/syslog.conf</filename>
         file. The <filename>syslog.conf</filename> file offers
         considerable flexibility in how syslog will deal with system
         messages issued by software applications like IPF.</para>



       <programlisting>Local0.* /var/log/ipfilter.log</programlisting>

       <para>The <literal>Local0.*</literal> means to write all the
         logged messages to the coded file location.</para>

       <para>To activate the changes made to
         <filename>/etc/syslog.conf </filename> you can reboot or bump
         the syslog task into re-reading
         <filename>/etc/syslog.conf</filename> by
         <command>/etc/rc.d/syslogd restart</command> or <command>kill
         -HUP <literal>pid</literal></command> on &os; 4.X systems. You
         get the pid (i.e. process number) by listing the tasks with
         the <command>ps -ax</command> command. Find syslog in the
         display and the pid is the number in the left column.</para>

       <para>Do not forget to change <filename>/etc/newsyslog.conf
         </filename> to rotate the new log you just created above.

         </listitem>

         <listitem>
           <para>The addresses. This is actuactually three fields: the
             source address and port (separated by a comma), the ->
             symbol, and the destination address and port.
             209.53.17.22,80 -> 198.73.220.17,1722.</para>

<programlisting>############# Start of IPF rules script ########################

oif="dc0"            # name of the outbound interface
odns="192.0.2.11"    # ISP's DNS server IP address
myip="192.0.2.7"     # My Static IP address from ISP
ks="keep state"
fks="flags S keep state"

# after the EOF line to work correctly.
/sbin/ipf -Fa -f - &lt;&lt; EOF

# Allow out access to my ISP's Domain Name server.
pass out quick on &dollar;oif proto tcp from any to &dollar;odns port = 53 &dollar;fks
pass out quick on &dollar;oif proto udp from any to &dollar;odns port = 53 &dollar;ks


EOF
################## End of IPF rules script ########################</programlisting>

       <para>That is all there is to it. The rules are not important
         in this example, how the Symbolic substitution field are
         populated and used are. If the above example was in
         <filename>/etc/ipf.rules.script</filename> file, you could
         reload these rules by entering the following on the command
         line:</para>

       <programlisting><command>sh /etc/ipf.rules.script</command>


       <programlisting><command>chmod 700 /usr/local/etc/rc.d/ipf.loadrules.sh</command></programlisting>

       <para>Now when your system boots, your IPF rules will be loaded
         using the script.</para>

     </sect2>

         session conversation. The firewall rule set processes the
         packet 2 times, once on its arrival from the public Internet
         host and again as it leaves for its return trip back to the
         public Internet host. Each TCP/IP service (i.e. telnet, www,
         mail, etc.) is predefined by its protocol, source and
         destination IP address, or the source and destination port
         number. This is the basic selection criteria used to create

         rule wins</quote> logic. For the complete legacy rule syntax
         description see the &man.ipf.8; manual page.</para>

       <para><literal>#</literal> is used to mark the start of a
         comment and may appear at the end of a rule line or on its
         own lines. Blank lines are ignored.</para>

       <para>Rules contain keywords, These keywords have to be coded in
         a specific order from left to right on the line. Keywords are

           <title>ACTION</title>

           <para>The action indicates what to do with the packet if it
             matches the rest of the filter rule. Each rule
             <emphasis>must</emphasis> have a action. The following
             actions are recognized:</para>

           <para>block indicates that the packet should be dropped if
             the selection parameters match the packet.</para>

             other has to be coded or the rule will not pass syntax
             check.</para>

           <para>"in" means this rule is being applied against an inbound
             packet which has just been received on the interface
             facing the public Internet.</para>

           <para>"out" means this rule is being applied against an
             outbound packet destined for the interface facing the public
             Internet.</para>
         </sect3>

               </para>
           </note>

           <para>"log" indicates that the packet header will be written to
             the ipl log (as described in the LOGGING section below) if
             the selection parameters match the packet.</para>

           <para>"quick" indicates that if the selection parameters match
             the packet, this rule will be the last rule checked,
             allowing a "short-circuit" path to avoid processing any
             following rules for this packet. This option is a mandatory
             requirement for the modernized rules processing logic.
             </para>

           <para>"on" indicates the interface name to be incorporated into
             the selection parameters. Interface names are as displayed
             by ifconfig. Using this option, the rule will only match if
             the packet is going through that interface in the specified

             Immediately following the log keyword, the following
             qualifiers may be used (in this order):</para>

           <para>"body" indicates that the first 128 bytes of the packet
             contents will be logged after the headers.</para>

           <para>"first" If the 'log' keyword is being used in conjunction
             with a "keep state" option, it is recommended that this
             option is also applied so that only the triggering packet
             is logged and not every packet which there after matches

           <para>The 'all' keyword is essentially a synonym for "from
             any to any" with no other match parameters.</para>

           <para>"from src to dst" The from and to keywords are used to
             match against IP addresses. Rules must specify BOTH source
             and destination parameters. .any. is a special keyword that
             matches any IP address. As in 'from any to any' or 'from

          do not properly fit the session conversation template are
          automatically rejected as impostors.</para>

        <para>Keep state will also allow ICMP packets related to a
          <acronym>TCP</acronym> or UDP session through. So if you get
          ICMP type 3 code 4 in response to some web surfing allowed
          out by a keep state rule, they will be automatically allowed
          in. Any packet that IPF can be certain is part of a active
          session, even if it is a different protocol, will be let
          in.</para>

        <para>What happens is:</para>


        interfaces which have to have rules to allow the firewall to
        function.</para>

      <para>All &unix; flavored systems including &os; are designed to
        use interface lo0 and IP address 127.0.0.1 for internal
        communication with in the operating system. The firewall
        rules must contain rules to allow free unmolested movement of
        these special internally used packets.</para>

      <para>The interface which faces the public Internet, is the one
        which you code your rules to authorize and control access out
        to the public Internet and access requests arriving from the
        public Internet. This can be your 'user ppp' tun0 interface or
        your NIC card that is cabled to your DSL or cable modem.</para>

      <para>In cases where one or more than one NICs are cabled to

        interfaces must have a rule coded to allow free unmolested
        movement of packets originating from those LAN interfaces.</para>

      <para>The rule set should be first organized into three major
        sections, all the free unmolested interfaces, public interface
        outbound, and the public interface inbound.</para>


        create the legal evidence needed to prosecute the people who
        are attacking your system.</para>

      <para>There is another thing you should take note of: there is no
        response returned for any of the undesirable stuff, their
        packets just get dropped and vanish. This way the attackers
        has no knowledge if his packets have reached your system.  The
        less the attackers can learn about your system the more secure
        it is. The inbound 'nmap OS fingerprint' attempts rule I log
        the first occurrence because this is something an attacker
        would do.</para>

      <para>Any time you see log messages on a rule with .log first.

        <filename>/etc/ipf.rules</filename>:</para>

      <programlisting>#################################################################
# No restrictions on Inside LAN Interface for private network
# Not needed unless you have LAN
#################################################################

#pass out quick on xl0 all

#################################################################

# Allow out access to my ISP's Domain name server.
# xxx must be the IP address of your ISP's DNS.
# Dup these lines if your ISP has more than one DNS server
# Get the IP addresses from /etc/resolv.conf file
pass out quick on dc0 proto tcp from any to xxx port = 53 flags S keep state

# used in the outbound section.
pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state

# Allow in standard www function because I have Apache server
pass in quick on dc0 proto tcp from any to any port = 80 flags S keep state

# Allow in non-secure Telnet session from public Internet


# Block and log only first occurrence of all remaining traffic
# coming into the firewall. The logging of only the first
# occurrence stops a 'Denial of Service' attack targeted
# at filling up your log file space.
# This rule enforces the block all by default logic.
block in log first quick on dc0 all

        lines.</para>

      <para>With <acronym>NAT</acronym> you only need a single account
        with your ISP, then cable your other 4 PC's to a switch and
        the switch to the NIC in your &os; system which is going to
        service your LAN as a gateway. <acronym>NAT</acronym> will
        automatically translate the private LAN IP address for each

        for details.</para>

      <para>When changing the <acronym>NAT</acronym> rules after
        <acronym>NAT</acronym> has been started, make your changes to
        the file containing the nat rules, then run ipnat command with
        the <option>-CF</option> flags to delete the internal in use
        <acronym>NAT</acronym> rules and flush the contents of the
        translation table of all active entries.</para>

      <para>To reload the <acronym>NAT</acronym> rules, issue a command
        like this:</para>

      <programlisting>ipnat -CF -f /etc/ipnat.rules</programlisting>

      <sect3>
        <title>Assigning Ports to Use</title>

        <para></para>

        <programlisting>map dc0 192.168.1.0/24 -> 0.32</programlisting>



    <para>The IPFIREWALL (IPFW) is a &os; sponsored firewall software
      application authored and maintained by &os; volunteer staff
      members. It uses the legacy stateless rules and a legacy rule
      coding technique to achieve what is referred to as Simple
      Stateful logic.</para>



    <para>IPFW is composed of 7 components, the primary component is
      the kernel firewall filter rule processor and its integrated
      packet accounting facility, then come the logging facility, the
      'divert' rule which triggers the <acronym>NAT</acronym>
      facility, and the advanced special purpose facilities, the
      dummynet traffic shaper facilities, the 'fwd rule' forward
      facility, the bridge facility, and the ipstealth
      facility.</para>

    <sect2 id="firewalls-ipfw-enable">
      <title>Enabling IPFW</title>

      <para>IPFW is included in the basic &os; install as a separate
        run time loadable module. The system will dynamically load
        IPFW kernel module when the <filename>rc.conf</filename>
        statement <literal>firewall_enable="YES"</literal> is
        used. You do not need to compile IPFW into the &os; kernel
        unless you want <acronym>NAT</acronym> function
        enabled.</para>

      <para>After rebooting your system with
        <literal>firewall_enable="YES"</literal> in

        firewall rules with changes you made to the files content is
        the recommended method used here.</para>

      <para>The ipfw command is still very useful to display the
        running firewall rules to the console screen. The IPFW
        accounting facility dynamically creates a counter for each
        rule that counts each packet that matches the rule. During the


          <para>The from and to keywords are used to match against IP
            addresses. Rules must specify BOTH source and destination
            parameters. 'any' is a special keyword that matches any IP
            address. 'me' is a special keyword that matches any IP
            address configured on an interface in your &os; system to
            represent the PC the firewall is running on (i.e. this
            box). As in from me to any or from any to me or from
            0.0.0.0/0 to any or from any to 0.0.0.0/0 or from 0.0.0.0
            to any or from any to 0.0.0.0 or from me to 0.0.0.0. IP
            addresses are specified as a dotted IP address numeric

          <para>The script syntax used here is compatible with the 'sh',
            'csh', 'tcsh' shells. Symbolic substitution fields are
            prefixed with a dollar sign &dollar;. Symbolic fields do not have
            the &dollar; prefix. The value to populate the symbolic field must
            be enclosed to "double quotes".</para>

          <para>Start your rules file like this:</para>

ipfw -q -f flush       # Delete all rules
# Set defaults
oif="tun0"             # out interface
odns="192.0.2.11"      # ISP's DNS server IP address
cmd="ipfw -q add "     # build rule prefix
ks="keep-state"        # just too lazy to key this each time
&dollar;cmd 00500 check-state

################### End of example ipfw rules script ############</programlisting>

          <para>That is all there is to it. The rules are not important
            in this example, how the symbolic substitution field are
            populated and used are.</para>

          <para>If the above example was in


        </sect3>
        <sect3>
          <title>Stateful Rule Set</title>
          <para>The following non-<acronym>NAT</acronym>ed rule set is a example of how to
            code a very secure 'inclusive' type of firewall. An
            inclusive firewall only allows services matching pass rules

            allow the firewall to function.</para>

          <para>All &unix; flavored operating systems, &os; included, are designed to
            use interface lo0 and IP address
            <hostid role="ipaddr">127.0.0.1</hostid> for internal
            communication with in &os;. The firewall rules must contain
            rules to allow free unmolested movement of these special

          <para>The interface which faces the public Internet, is the
            one which you code your rules to authorize and control
            access out to the public Internet and access requests
            arriving from the public Internet. This can be your 'user
            ppp' tun0 interface or your NIC that is connected to your
            DSL or cable modem.</para>

          <para>In cases where one or more than one NIC are connected to
            a private LANs behind the firewall, those interfaces must

            .</para>
        </sect3>
        <sect3>
          <title>An Example Inclusive Rule Set</title>
          <para>The following non-<acronym>NAT</acronym>ed rule set is a complete inclusive
            type rule set. You can not go wrong using this rule set for
            you own.  Just comment out any pass rules for services you
            do not want.  If you see messages in your log that you want to
            stop seeing just add a deny rule in the inbound section. You

                        # facing the public Internet

#################################################################
# No restrictions on Inside LAN Interface for private network
# Not needed unless you have Lan.
# Change xl0 to your Lan Nic card interface name
#################################################################

        </sect3>

        <sect3>
          <title>An Example <acronym>NAT</acronym> and Stateful Rule
          Set</title> 

          <para>There are some additional configuration statements
            that need to be enabled to activate the
            <acronym>NAT</acronym> function of IPFW. The kernel
            needs 'option divert' statement added to the other
            IPFIREWALL statements compiled into a custom kernel.
            </para>

          <para>In addition to the normal IPFW options in
            <filename>/etc/rc.conf</filename>, the following are needed:
            </para>

          <programlisting>natd_enable="YES"                   # Enable <acronym>NAT</acronym>D function


          <para>The processing flow starts with the first rule from the
            top of the rule file and progress one rule at a time deeper
            into the file until the end is reached or the packet being
            tested to the selection criteria matches and the packet is
            released out of the firewall.  It is important to take notice
            of the location of rule numbers 100 101, 450, 500, and 510.
            These rules control the translation of the outbound and
            inbound packets so their entries in the keep-state dynamic
            table always register the private LAN IP address. Next
            notice that all the allow and deny rules specified the
            direction the packet is going (IE outbound or inbound) and
            the interface. Also notice that all the start outbound
            session requests all skipto rule 500 for the network address
            translation.</para>

          <para>Lets say a LAN user uses their web browser to get a
            web page. Web pages use port 80 to communicate over. So
            the packet enters the firewall. It does not match 100
            because it is headed out not in. It passes rule 101
            because this is the first packet so it has not been posted
            to the keep-state dynamic table yet. The packet finally
            comes to rule 125 a matches. It is outbound through the
            NIC facing the public Internet. The packet source IP
            address is still a private LAN IP address. On the match to
            this rule, two actions take place. The keep-state option
            will post this rule into the keep-state dynamic rules
            table and the specified action is executed. The action is
            part of the info posted to the dynamic table.  In this
            case it is "skipto rule 500".  Rule 500
            <acronym>NAT</acronym>s the packet IP address and out it
            goes. Remember this, this is very important. This packet
            makes its way to the destination and returns and enters
            the top of the rule set. This time it does match rule 100
            and has it destination IP address mapped back to it's
            corresponding Lan IP address.  Then it is processed by the
            check-state rule, it's found in the table as belonging to
            an existing session conversation and released to the
            LAN. It goes to the LAN PC that sent it and a new packet
            is sent requesting another segment of the data from the
            remote server. This time it gets checked by the
            check-state rule and, as its outbound entry is found, the
            associated action, 'skipto 500', is executed.  The packet
            jumps to rule 500 gets <acronym>NAT</acronym>ed and
            released on it's way out.  </para>

          <para>On the inbound side, everything coming in that is part
            of an existing session conversation is being automatically
            handled by the check-state rule and the properly placed
            divert natd rules. All we have to address is denying all
            the bad packets and only allowing in the authorized
            services.  Lets say there is a apache server running on
            the firewall box and we want people on the public Internet
            to be able to access the local web site. The new inbound
            start request packet matches rule 100 and its IP address
            is mapped to LAN IP for the firewall box. The packet is
            them matched against all the nasty things we want to check
            for and finally matches against rule 425. On a match two
            things occur. The packet rule is posted to the keep-state
            dynamic table but this time the number of new session
            requests originating from that source IP address is
            limited to 2. This defends against DoS attacks of service
            running on the specified port number. The action is allow
            so the packet is released to the LAN. On return the
            check-state rule recognizes the packet as belonging to an
            existing session conversation sends it to rule 500 for
            <acronym>NAT</acronym>ing and released to outbound
            interface.</para>
            is limited to 2. This defends against DoS attacks of service
            running on the specified port number. The action is allow so
            the packet is released to the LAN. On return the check-state
            rule recognizes the packet as belonging to an existing
            session conversation sends it to rule 500 for <acronym>NAT</acronym>ing and
            released to outbound interface.</para>

          <para>Example Rule Set #1:</para>

          <programlisting>#!/bin/sh
cmd="ipfw -q add"


ipfw -q -f flush

&dollar;cmd 002 allow all from any to any via xl0  # exclude LAN traffic
&dollar;cmd 003 allow all from any to any via lo0  # exclude loopback traffic

&dollar;cmd 100 divert natd ip from any to any in via &dollar;pif

            to help the inexperienced IPFW rule writer to better
            understand what the rules are doing.</para>

          <para>Example Rule Set #2:</para>

          <programlisting>
#!/bin/sh

Return to bug 75422