File: //usr/share/shorewall/configfiles/policy.annotated
#
# Shorewall -- /etc/shorewall/policy
#
# For information about entries in this file, type "man shorewall-policy"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall-policy.html
#
###############################################################################
#
# 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])]|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.
#
# 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