~ubuntu-branches/debian/sid/shorewall/sid

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

#     There is an implicit rule added at the end of this section that invokes the

#     RELATED_DISPOSITION (shorewall.conf(5)).

# 

# INVALID

# 

#     Added in Shorewall 4.5.13. Packets in the INVALID state are processed by

#     rules in this section.

# 

#     The only Actions allowed in this section are ACCEPT, DROP, REJECT, LOG and

#     QUEUE.

# 

#     There is an implicit rule added at the end of this section that invokes the

#     INVALID_DISPOSITION (shorewall.conf(5)).

# 

# UNTRACKED

# 

#     Added in Shorewall 4.5.13. Packets in the UNTRACKED state are processed by

#     rules in this section.

# 

#     The only Actions allowed in this section are ACCEPT, DROP, REJECT, LOG and

#     QUEUE.

# 

#     There is an implicit rule added at the end of this section that invokes the

#     UNTRACKED_DISPOSITION (shorewall.conf(5)).

#     action

# 

#         The name of an action declared in shorewall-actions(5) or in /usr/share

#         /shorewall/actions.std.

# 

#     ADD(ipset:flags)

# 

#         Added in Shorewall 4.4.12. Causes addresses and/or port numbers to be

#         added to the named ipset. The flags specify the address or tupple to be

#         added to the set and must match the type of ipset involved. For

#         example, for an iphash ipset, either the SOURCE or DESTINATION address

#         can be added using flags src or dst respectively (see the -A command in

#         ipset (8)).

# 

#         ADD is non-terminating. Even if a packet matches the rule, it is passed

#         on to the next rule.

# 

#     AUDIT[(accept|drop|reject)]

# 

#         Added in Shorewall 4.5.10. Audits the packet with the specified type;

#         if the type is omitted, then drop is assumed. Require AUDIT_TARGET

#         support in the kernel and iptables.

# 

#     [?]COMMENT

# 

#         the rest of the line will be attached as a comment to the Netfilter

#         rule(s) generated by the following entries. The comment will appear

#         delimited by "/* ... */" in the output of "shorewall show <chain>". To

#         stop the comment from being attached to further rules, simply include

#         COMMENT on a line by itself.

# 

#         Note

# 

#         Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT and

#         is preferred.

#     DEL(ipset:flags)

# 

#         Added in Shorewall 4.4.12. Causes an entry to be deleted from the named

#         ipset. The flags specify the address or tupple to be deleted from the

#         set and must match the type of ipset involved. For example, for an

#         iphash ipset, either the SOURCE or DESTINATION address can be deletec

#         using flags src or dst respectively (see the -D command in ipset (8)).

# 

#         DEL is non-terminating. Even if a packet matches the rule, it is passed

#         on to the next rule.

# 

#     DNAT

# 

#         Forward the request to another system (and optionally another port).

# 

#     DNAT-

# 

#         Advanced users only.

# 

#         Like DNAT but only generates the DNAT iptables rule and not the

#         companion ACCEPT rule.

# 

#     DROP

# 

#         Ignore the request.

# 

#     DROP!

# 

#         like DROP but exempts the rule from being suppressed by OPTIMIZE=1 in

#         shorewall.conf(5).

# 

#     HELPER

# 

#         Added in Shorewall 4.5.7. This action requires that the HELPER column

#         contains the name of the Netfilter helper to be associated with

#         connections matching this connection. May only be specified in the NEW

#         section and is useful for being able to specify a helper when the

#         applicable policy is ACCEPT. No destination zone should be specified in

#         HELPER rules.

# 

#     INLINE[(action)]

# 

#         Added in Shorewall 4.5.16. This action allows you to construct most of

#         the rule yourself using iptables syntax. The part that you specify must

#         follow a semicolon (';') and is completely free-form. If the target of

#         the rule (the part following 'j') is something that Shorewall supports

#         in the ACTION column, then you may enclose it in parentheses (e.g.,

#         INLINE(ACCEPT)). Otherwise, you can include it after the semicolon. In

#         this case, you must declare the target as a builtin action in

#         shorewall-actions(5).

# 

#         Some considerations when using INLINE:

# 

#           ● The p, s, d, i, o, policy, and state match (state or conntrack

#             --ctstate) matches will always appear in the front of the rule in

#             that order.

# 

#           ● When multiple matches are specified, the compiler will keep them in

#             the order in which they appear (excluding the above listed ones),

#             but they will not necessarily be at the end of the generated rule.

#             For example, if addresses are specified in the SOURCE and/or DEST

#             columns, their generated matches will appear after those specified

#             using ';'.

# 

#     LOG:level

# 

#         Simply log the packet and continue with the next rule.

#     NFLOG[(nflog-parameters)]

# 

#         Added in Shorewall 4.5.9.3. Queues matching packets to a backend

#         logging daemon via a netlink socket then continues to the next rule.

#         See http://www.shorewall.net/shorewall_logging.html.

# 

#         Similar to LOG:NFLOG[(nflog-parameters)], except that the log level is

#         not changed when this ACTION is used in an action or macro body and the

#         invocation of that action or macro specifies a log level.

# 

#     NFQUEUE[(queuenumber)]

# 

#         Queues the packet to a user-space application using the nfnetlink_queue

#         mechanism. If a queuenumber is not specified, queue zero (0) is

#         assumed.

# 

#     NFQUEUE![(queuenumber)]

# 

#         like NFQUEUE but exempts the rule from being suppressed by OPTIMIZE=1

#         in shorewall.conf(5).

# 

#     NONAT

# 

#         Excludes the connection from any subsequent DNAT[-] or REDIRECT[-]

#         rules but doesn't generate a rule to accept the traffic.

# 

#     QUEUE

# 

#         Queue the packet to a user-space application such as ftwall (http://

#         p2pwall.sf.net). The application may reinsert the packet for further

#         processing.

# 

#     QUEUE!

# 

#         like QUEUE but exempts the rule from being suppressed by OPTIMIZE=1 in

#         shorewall.conf(5).

# 

#     REJECT

# 

#         disallow the request and return an icmp-unreachable or an RST packet.

# 

#     REJECT!

# 

#         like REJECT but exempts the rule from being suppressed by OPTIMIZE=1 in

#         shorewall.conf(5).

# 

#     REDIRECT

# 

#         Redirect the request to a server running on the firewall.

# 

#     REDIRECT-

# 

#         Advanced users only.

# 

#         Like REDIRECT but only generates the REDIRECT iptables rule and not the

#         companion ACCEPT rule.

# 

#     ULOG[(ulog-parameters)]

# 

#         Added in Shorewall 4.5.10. Queues matching packets to a backend logging

#         daemon via a netlink socket then continues to the next rule. See http:/

#         /www.shorewall.net/shorewall_logging.html.

# 

#         Similar to LOG:ULOG[(ulog-parameters)], except that the log level is

#         not changed when this ACTION is used in an action or macro body and the

#         invocation of that action or macro specifies a log level.

#     Except when all[+]|[-] is specified, the server may be further restricted

#     to a particular network, host or interface by appending ":" and the

#     network, host or interface. See SOURCE above.

# 

#     You may exclude certain hosts from the set already defined through use of

#     an exclusion (see shorewall-exclusion(5)).

# 

#     Restriction: MAC addresses are not allowed (this is a Netfilter

#     restriction).

# 

#     Like in the SOURCE column, you may specify a range of IP addresses using

#     the syntax lowaddress-highaddress. When the ACTION is DNAT or DNAT-, the

#     connections will be assigned to addresses in the range in a round-robin

#     fashion.

# 

#     If you kernel and iptables have ipset match support then you may give the

#     name of an ipset prefaced by "+". The ipset name may be optionally followed

#     by a number from 1 to 6 enclosed in square brackets ([]) to indicate the

#     number of levels of destination bindings to be matched. Only one of the

#     SOURCE and DEST columns may specify an ipset name.

# 

#     Beginning with Shorewall 4.4.17, the primary IP address of a firewall

#     interface can be specified by an apersand ('&') followed by the logical

#     name of the interface as found in the INTERFACE column of

#     shorewall-interfaces (5).

# 

#     The port that the server is listening on may be included and separated from

#     the server's IP address by ":". If omitted, the firewall will not modifiy

#     the destination port. A destination port may only be included if the ACTION

#     is DNAT or REDIRECT.

# 

#     Example:

# 

#         loc:192.168.1.3:3128 specifies a local server at IP address 192.168.1.3

#         and listening on port 3128.

# 

#     The port may be specified as a service name. You may specify a port range

#     in the form lowport-highport to cause connections to be assigned to ports

#     in the range in round-robin fashion. When a port range is specified,

#     lowport and highport must be given as integers; service names are not

#     permitted. Additionally, the port range may be optionally followed by

#     :random which causes assignment to ports in the list to be random.

# 

#     If the ACTION is REDIRECT or REDIRECT-, this column needs only to contain

#     the port number on the firewall that the request should be redirected to.

#     That is equivalent to specifying $FW::port.

#     Beginning with Shorewall 4.5.15, you may place '=' in this column, provided

#     that the DEST PORT(S) column is non-empty. This causes the rule to match

#     when either the source port or the destination port in a packet matches one

#     of the ports specified in DEST PORTS(S). Use of '=' requires multiport

#     match in your iptables and kernel.

# 

#     If you don't want to restrict client ports but need to specify an ORIGINAL

#     DEST in the next column, then place "-" in this column.

# 

#     If your kernel contains multi-port match support, then only a single

#     Netfilter rule will be generated if in this list and the DEST PORT(S) list

#     above:

# 

#     1. There are 15 or less ports listed.

# 

#     2. No port ranges are included or your kernel and iptables contain extended

#     multiport match support.

# USER/GROUP (user) - [!][user-name-or-number][:group-name-or-number][,...]

#     Beginning with Shorewall 4.5.8, multiple user or group names/ids separated

#     by commas may be specified.

# 

#     2001-2099

# 

#         UIDs 2001 through 2099 (Shorewall 4.5.6 and later)

# SWITCH - [!]switch-name[={0|1}]

#     enabled if the file contains 0.

# 

#     Within the switch-name, '@0' and '@{0}' are replaced by the name of the

#     chain to which the rule is a added. The switch-name (after '@...'

#     expansion) must begin with a letter and be composed of letters, decimal

#     digits, underscores or hyphens. Switch names must be 30 characters or less

#     in length.

#     Beginning with Shoreawll 4.5.10, when the switch-name is followed by =0 or

#     =1, then the switch is initialized to off or on respectively by the start

#     command. Other commands do not affect the switch setting.

# 

# HELPER - [helper]

# 

#     Added in Shorewall 4.5.7.

# 

#     In the NEW section, causes the named conntrack helper to be associated with

#     this connection; the contents of this column are ignored unless ACTION is

#     ACCEPT*, DNAT* or REDIRECT*.

# 

#     In the RELATED section, will only match if the related connection has the

#     named helper associated with it.

# 

#     The helper may be one of:

# 

#     amanda

#     ftp

#     irc

#     netbios-ns

#     pptp

#     Q.931

#     RAS

#     sane

#     sip

#     snmp

#     tftp

# 

#     If the HELPERS option is specified in shorewall.conf(5), then any module

#     specified in this column must be listed in the HELPERS setting.

# 

#             DROP                          net:^A1,A2       fw             tcp         25

# 

# Example 14:

# 

#     You want to generate your own rule involving iptables targets and matches

#     not supported by Shorewall.

# 

#             #ACTION                       SOURCE           DEST           PROTO       DEST

#             #                                                                         PORT(S)

#             INLINE                        $FW              net ; -p 6 -m mickey-mouse --name test -m set --match-set set1 src -m mickey-mouse --name test2 -j SECCTX --name test3

# 

#     The above will generate the following iptables-restore input:

# 

#             -A fw2net -p 6 -m mickey-mouse --name test -m set --match-set set1 src -m mickey-mouse --name test2 -j SECCTX --name test3

# 

#     Note that SECCTX must be defined as a builtin action in shorewall-actions

#     (5):

# 

#             #ACTION            OPTIONS

#             SECCTX             builtin

# 

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

#ACTION         SOURCE          DEST            PROTO   DEST    SOURCE          ORIGINAL        RATE            USER/   MARK    CONNLIMIT       TIME            HEADERS         SWITCH          HELPER

#SECTION INVALID

#SECTION UNTRACKED

# Drop packets in the INVALID state

Invalid(DROP)  net              $FW             tcp