#
# Shorewall6 version 5 - Sample Policy File for one-interface configuration.
# Copyright (C) 2006-2015 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#-----------------------------------------------------------------------------
# For information about entries in this file, type "man shorewall6-policy"
#
##############################################################################
# 
# This file defines the high-level policy for connections between zones defined
# in shorewall-zones(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(5) or shorewall-rules(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(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(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(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(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[c]][,bypass]]|bypass)]|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:
# 
#      a. The word "None" or "none". This causes any default action defined in
#         shorewall.conf(5) to be omitted for this policy.
# 
#      b. 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
#     (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(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. Beginning with Shorewall
#         5.1.0, queuenumber2 may be followed by the letter 'c' to indicate that
#         the CPU ID will be used as an index to map packets to the queues. The
#         idea is that you can improve performance if there's a queue per CPU.
#         Requires the NFQUEUE CPU Fanout capability in your kernel and iptables.
# 
#         Beginning with Shorewall 4.6.10, the keyword bypass can be given. By
#         default, if no userspace program is listening on an NFQUEUE, then all
#         packets that are to be queued are dropped. When this option is used,
#         the NFQUEUE rule behaves like ACCEPT instead.
# 
#     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) 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).
# 
#     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
# 
#  a. All connections from the local network to the internet are allowed
# 
#  b. All connections from the internet are ignored but logged at syslog level
#     KERNEL.INFO.
# 
#  c. 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
# 
##############################################################################
#SOURCE	DEST		POLICY		LOGLEVEL	RATE	CONNLIMIT
$FW	net		ACCEPT
net	all		DROP		$LOG_LEVEL
# The FOLLOWING POLICY MUST BE LAST
all	all		REJECT		$LOG_LEVEL
