Name

policy — Shorewall policy file

Synopsis

/etc/shorewall/policy

Description

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 /etc/shorewall/rules file . For each source/destination pair, the file is processed in order until a match is found ("all" will match any client or server).

Important

Intra-zone policies are pre-defined

For $FW and for all of the zones defined in /etc/shorewall/zones, 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, 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|all+

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.

DEST - zone|$FW|all|all+

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.

POLICY - {ACCEPT|DROP|REJECT|CONTINUE|QUEUE|NFQUEUE[(queuenumber1[:queuenumber2])]|NONE}[:{default-action-or-macro[: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(5) to be omitted for this policy.

  2. The name of an action. 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.

Possible actions are:

ACCEPT

Accept the connection.

DROP

Ignore the connection request.

REJECT

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

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".

LOG LEVEL (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 log levels, see http://www.shorewall.net/shorewall_logging.html.

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

BURST:LIMIT (limit) - [-|limit]

where limit is one of:

[-|[{s|d}:[[name]:]]]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 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

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

See ALSO

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

shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-mangle(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)

Documentation


Frequently Used Articles

- FAQs - IPv4 Manpages - IPv6 Manpages - Configuration File Basics - Beginner Documentation - Troubleshooting

Shorewall 4.0/4.2 Documentation


Current HOWTOs and Other Articles

- 6to4 and 6in4 Tunnels - Accounting - Actions - Aliased (virtual) Interfaces (e.g., eth0:0) - Anatomy of Shorewall - Anti-Spoofing Measures - AUDIT Target support - Bandwidth Control - Blacklisting/Whitelisting - Bridge/Firewall - Building Shorewall from GIT - Commands - Compiled Programs - Configuration File Basics - DHCP - DNAT - Dynamic Zones - ECN Disabling by host or subnet - Events - Extension Scripts - Fallback/Uninstall - FAQs - Features - Fool's Firewall - Forwarding Traffic on the Same Interface - FTP and Shorewall - Helpers/Helper Modules - Installation/Upgrade - IPP2P - IPSEC - Ipsets - IPv6 Support - ISO 3661 Country Codes - Kazaa Filtering - Kernel Configuration - KVM (Kernel-mode Virtual Machine) - Limiting Connection Rates - Linux Containers (LXC) - Linux-vserver - Logging - Macros - MAC Verification - Manpages (IPv4) (IPv6) - Manual Chains - Masquerading - Multiple Internet Connections from a Single Firewall - Multiple Zones Through One Interface - My Shorewall Configuration - Netfilter Overview - Network Mapping - No firewalling of traffic between bridge port - One-to-one NAT - Operating Shorewall - OpenVPN - OpenVZ - Packet Marking - Packet Processing in a Shorewall-based Firewall - 'Ping' Management - Port Forwarding - Port Information - Port Knocking (deprecated) - Port Knocking, Auto Blacklisting and Other Uses of the 'Recent Match' - PPTP - Proxy ARP - QuickStart Guides - Release Model - Requirements - Routing and Shorewall - Routing on One Interface - Samba - Shorewall Events - Shorewall Init - Shorewall Lite - Shorewall on a Laptop - Shorewall Perl - Shorewall Setup Guide - SMB - SNAT - Split DNS the Easy Way - Squid with Shorewall - Starting/stopping the Firewall - Static (one-to-one) NAT - Support - Tips and Hints - Traffic Shaping/QOS - Simple - Traffic Shaping/QOS - Complex - Transparent Proxy - UPnP - Upgrade Issues - Upgrading to Shorewall 4.4 (Upgrading Debian Lenny to Squeeze) - VPN - VPN Passthrough - White List Creation - Xen - Shorewall in a Bridged Xen DomU - Xen - Shorewall in Routed Xen Dom0

Top of Page