Provided by: shorewall_5.2.3.4-1_all bug

NAME

       policy - Shorewall policy file

SYNOPSIS

       /etc/shorewall[6]/policy

DESCRIPTION

       This file defines the high-level policy for connections between zones defined in shorewall-zones[1](5).

           Important
           The order of entries in this file is important

           This file determines what to do with a new connection request if we don't get a match from the
           shorewall-blrules[2](5) or shorewall-rules[3](5) files. For each source/destination pair, the file is
           processed in order until a match is found ("all" will match any source or destination).

           Important
           Intra-zone policies are pre-defined

           For $FW and for all of the zones defined in shorewall-zones[1](5), the POLICY for connections from
           the zone to itself is ACCEPT (with no logging or TCP connection rate limiting) but may be overridden
           by an entry in this file. The overriding entry must be explicit (specifying the zone name in both
           SOURCE and DEST) or it must use "all+" (Shorewall 4.5.17 or later).

           Similarly, if you have IMPLICIT_CONTINUE=Yes in shorewall.conf[4](5), then the implicit policy
           to/from any sub-zone is CONTINUE. These implicit CONTINUE policies may also be overridden by an
           explicit entry in this file.

       The columns in the file are as follows (where the column name is followed by a different name in
       parentheses, the different name is used in the alternate specification syntax).

       SOURCE - zone[,...[+]]|$FW|all[+][!ezone[,...]]
           Source zone. Must be the name of a zone defined in shorewall-zones[1](5), $FW, "all" or "all+".

           Support for all+ was added in Shorewall 4.5.17.  all does not override the implicit intra-zone ACCEPT
           policy while all+ does.

           Beginning with Shorewall 5.0.12, multiple zones may be listed separated by commas. As above, if '+'
           is specified after two or more zone names, then the policy overrides the implicit intra-zone ACCEPT
           policy if the same zone appears in both the SOURCE and DEST columns.

           Beginning with Shorewall 5.2.3, a comma-separated list of excluded zones preceded by "!" may follow
           all or all+.

       DEST - zone[,...[+]]|$FW|all[+][!ezone[,...]]
           Destination zone. Must be the name of a zone defined in shorewall-zones[1](5), $FW, "all" or "all+".
           If the DEST is a bport zone, then the SOURCE must be "all", "all+", another bport zone associated
           with the same bridge, or it must be an ipv4 zone that is associated with only the same bridge.

           Support for "all+" was added in Shorewall 4.5.17. "all" does not override the implicit intra-zone
           ACCEPT policy while "all+" does.

           Beginning with Shorewall 5.0.12, multiple zones may be listed separated by commas. As above, if '+'
           is specified after two or more zone names, then the policy overrides the implicit intra-zone ACCEPT
           policy if the same zone appears in both the SOURCE and DEST columns.

           Beginning with Shorewall 5.2.3, a comma-separated list of excluded zones preceded by "!" may follow
           all or all+.

       POLICY -
       {ACCEPT|DROP|REJECT|BLACKLIST|CONTINUE|QUEUE|NFQUEUE[(queuenumber1[:queuenumber2])]|NONE}[:{[+]policy-action[:level][,...]|None}]
           Policy if no match from the rules file is found.

           If the policy is neither CONTINUE nor NONE then the policy may be followed by ":" and one of the
           following:

            1. The word "None" or "none". This causes any default action defined in shorewall.conf[4](5) to be
               omitted for this policy.

            2. The name of an action with optional parameters enclosed in parentheses. The action will be
               invoked before the policy is enforced.

           Actions can have parameters specified.

           Beginning with Shorewall 4.5.10, the action name can be followed optionally by a colon and a log
           level. The level will be applied to each rule in the action or body that does not already have a log
           level.

           Beginning with Shorewall 5.1.2, multiple action[:level] specification may be listeded, separated by
           commas. The actions are invoked in the order listed. Also beginning with Shorewall 5.1.2, the
           policy-action list can be prefixed with a plus sign ("+") indicating that the listed actions are in
           addition to those listed in the related _DEFAULT setting in shorewall.conf[4](5).

           Possible policies are:

           ACCEPT
               Accept the connection.

           DROP
               Ignore the connection request.

           REJECT
               For TCP, send RST. For all other, send an "unreachable" ICMP.

           BLACKLIST
               Added in Shorewall 5.1.1 and requires that the DYNAMIC_BLACKLIST setting in shorewall.conf[4](5)
               specifies ipset-based dynamic blacklisting. The SOURCE IP address is added to the blacklist ipset
               and the connection request is ignored.

           QUEUE
               Queue the request for a user-space application such as Snort-inline.

           NFQUEUE
               Queue the request for a user-space application using the nfnetlink_queue mechanism. If a
               queuenumber1 is not given, queue zero (0) is assumed. Beginning with Shorewall 4.6.10, a second
               queue number (queuenumber2) may be given. This specifies a range of queues to use. Packets are
               then balanced across the given queues. This is useful for multicore systems: start multiple
               instances of the userspace program on queues x, x+1, .. x+n and use "x:x+n". Packets belonging to
               the same connection are put into the same nfqueue.

           CONTINUE
               Pass the connection request past any other rules that it might also match (where the source or
               destination zone in those rules is a superset of the SOURCE or DEST in this policy). See
               shorewall-nesting[5](5) for additional information.

           NONE
               Assume that there will never be any packets from this SOURCE to this DEST. Shorewall will not
               create any infrastructure to handle such packets and you may not have any rules with this SOURCE
               and DEST in the /etc/shorewall/rules file. If such a packet is received, the result is undefined.
               NONE may not be used if the SOURCE or DEST columns contain the firewall zone ($FW) or "all".

       LOGLEVEL (loglevel) - [log-level|ULOG|NFLOG]
           Optional - if supplied, each connection handled under the default POLICY is logged at that level. If
           not supplied, no log message is generated. See syslog.conf(5) for a description of log levels.

           You may also specify ULOG or NFLOG (must be in upper case). This will log to the ULOG or NFLOG target
           and will send to a separate log through use of ulogd
           (http://www.netfilter.org/projects/ulogd/index.html).

           For a description of logging, see shorewall-logging(5)[6].

           If you don't want to log but need to specify the following column, place "-" here.

       RATE (rate) - [-|limit]
           where limit is one of:
               [-|[{s|d}[/vlsm]:[[name][(ht-buckets,ht-max)]:]]]rate/{sec|min|hour|day}[:burst]
               [name1:]rate1/{sec|min|hour|day}[:burst1],[name2:]rate2/{sec|min|hour|day}[:burst2]
           If passed, specifies the maximum TCP connection rate and the size of an acceptable burst. If not
           specified, TCP connections are not limited. If the burst parameter is omitted, a value of 5 is
           assumed.

           When s: or d: is specified, the rate applies per source IP address or per destination IP address
           respectively. The name may be chosen by the user and specifies a hash table to be used to count
           matching connections. If not give, the name shorewall is assumed. Where more than one POLICY or rule
           specifies the same name, the connections counts for the policies are aggregated and the individual
           rates apply to the aggregated count. Beginning with Shorewall 5.2.1, the s or d may be followed by a
           slash ("/") and an integer vlsm. When a vlsm is specified, all source or destination addresses
           encountered will be grouped according to the given prefix length and the so-created subnet will be
           subject to the rate limit.

           Beginning with Shorewall 4.6.5, two limits may be specified, separated by a comma. In this case, the
           first limit (name1, rate1, burst1) specifies the per-source IP limit and the second limit specifies
           the per-destination IP limit.

           Example: client:10/sec:20,:60/sec:100

           Beginning with Shorewall 5.2.1, the table name, if any, may be followed by two integers separated by
           commas and enclosed in parentheses. The first integer (ht-buckets) specifies the number of buckets in
           the generated hash table. The second integer (ht-max) specifies the maximum number of entries in the
           hash table.

           Example: s:client(1024,65536):10/sec

       CONNLIMIT - limit[:mask]
           May be used to limit the number of simultaneous connections from each individual host to limit
           connections. While the limit is only checked on connections to which this policy could apply, the
           number of current connections is calculated over all current connections from the SOURCE host. By
           default, the limit is applied to each host individually but can be made to apply to networks of hosts
           by specifying a mask. The mask specifies the width of a VLSM mask to be applied to the source
           address; the number of current connections is then taken over all hosts in the subnet
           source-address/mask.

EXAMPLE

        1. All connections from the local network to the internet are allowed

        2. All connections from the internet are ignored but logged at syslog level KERNEL.INFO.

        3. All other connection requests are rejected and logged at level KERNEL.INFO.

                   #SOURCE         DEST            POLICY          LOG           BURST:LIMIT
                   #                                               LEVEL
                   loc             net             ACCEPT
                   net             all             DROP            info
                   #
                   # THE FOLLOWING POLICY MUST BE LAST
                   #
                   all             all             REJECT          info

FILES

       /etc/shorewall/policy

       /etc/shorewall6/policy

SEE ALSO

       http://www.shorewall.net/configuration_file_basics.htm#Pairs[7]

       shorewall(8)

NOTES

        1. shorewall-zones
           http://www.shorewall.org/manpages/shorewall-zones.html

        2. shorewall-blrules
           http://www.shorewall.org/manpages/shorewall-blrules.html

        3. shorewall-rules
           http://www.shorewall.org/manpages/shorewall-rules.html

        4. shorewall.conf
           http://www.shorewall.org/manpages/shorewall.conf.html

        5. shorewall-nesting
           http://www.shorewall.org/manpages/shorewall-nesting.html

        6. shorewall-logging(5)
           http://www.shorewall.org/shorewall_logging.html

        7. http://www.shorewall.net/configuration_file_basics.htm#Pairs
           http://www.shorewall.org/configuration_file_basics.htm#Pairs