Shorewall actions allow a symbolic name to be associated with a series of one or more iptables rules. The symbolic name may appear in the ACTION column of an /etc/shorewall/rules entry, in a macro body and within another action, in which case the traffic matching that rules file entry will be passed to the series of iptables rules named by the action.

Actions can be thought of as templates. When an action is invoked in an /etc/shorewall/rules entry, it may be qualified by a logging specification (log level and optionally a log tag). The presence of the log level/tag causes a modified series of rules to be generated in which each packet/rule match within the action causes a log message to be generated.

For readers familiar with iptables, actions are the way in which you can create your own filter-table chains.

There are three types of Shorewall actions:

Shorewall allows the association of a policy action with policies. A separate policy action may be associated with ACCEPT, DROP, REJECT, QUEUE, NFQUEUE and BLACKLIST policies. Policy actions provide a way to invoke a set of common rules just before the policy is enforced. Policy actions accomplish two goals:

Shorewall supports policy actions for the ACCEPT, REJECT, DROP, QUEUE, NFQUEUE and BLACKLIST policies. These default actions are specified in the /etc/shorewall/shorewall.conf file using the ACCEPT_DEFAULT, REJECT_DEFAULT, DROP_DEFAULT, QUEUE_DEFAULT and NFQUEUE_DEFAULT options respectively. Policies whose default is set to a value of “none” have no default action.

In addition, the default specified in /etc/shorewall/shorewall.conf may be overridden by specifying a different action in the POLICY column of /etc/shorewall/policy.

Prior to Shorewall 5.1.2, the Drop and Reject actions were the default policy actions for DROP and REJECT policies respectively. Those actions are parameterized; each has five parameters as follows:

The parameters may be specified in either shorewall.conf (e.g., DROP_DEFAULT=Drop(-,DROP) or in the POLICY column of shorewall-policy(5) (e.g., DROP:Drop(audit):audit).

Beginning with Shorewall 5.1.2, Drop and Reject are deprecated. In 5.1.2, a list of policy actions is accepted in both shorewall.conf and the policy file. This allows logging to be specified on some actions and not on others and eliminates the need for a large number of policy-action parameters.

Actions commonly included in policy-action lists are:

The recommended settings for the 6 policy actions for IPv4 are:

        ACCEPT_DEFAULT=none
        BLACKLIST_DEFAULT="Broadcast(DROP),Multicast(DROP),dropNotSyn:$LOG_LEVEL,dropInvalid:$LOG_LEVEL,DropDNSrep:$LOG_LEVEL"
        DROP_DEFAULT="Broadcast(DROP),Multicast(DROP)"
        NFQUEUE_DEFAULT=none
        QUEUE_DEFAULT=none
        REJECT_DEFAULT="Broadcast(DROP),Multicast(DROP)"

The recommended settings for IPv6 are:

        ACCEPT_DEFAULT=none
        BLACKLIST_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP),dropNotSyn:$LOG_LEVEL,dropInvalid:$LOG_LEVEL,DropDNSrep:$LOG_LEVEL"
        DROP_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)"
        NFQUEUE_DEFAULT=none
        QUEUE_DEFAULT=none
        REJECT_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)"

Note that in both cases, logging occurs based on the setting of LOG_LEVEL in shorewall[6].conf.

Before defining a new action, you should evaluate whether your goal can be best accomplished using an action or a macro. See this article for details.

To define a new action:

#TARGET        SOURCE  DEST    PROTO   Dport   SPORT   ORIGDEST
$1             -       -       tcp     80      -       1.2.3.4

#TARGET        SOURCE  DEST    PROTO   DPORT   SPORT   ORIGDEST

A(REDIRECT)    net     fw

#TARGET        SOURCE  DEST    PROTO   DPORT   SPORT   ORIGDEST
REDIRECT       net     -       tcp     80      -       1.2.3.4

DEFAULTS def1,def2,...

Specifying a log level in a rule that specifies a user-defined or Shorewall-defined action will cause each rule in the action to be logged with the specified level (and tag), unless the nolog option is specified in the action's entry in /etc/shorewall/actions.

The extent to which logging of action rules occur is governed by the following:

There may be cases where you wish to create a chain with rules that can't be constructed using the tools defined in the action.template. Such rules can be constructed using Embedded Perl. For those who are comfortable using Perl, embedded Perl is more efficient that using complicated conditional entries. The Perl compiler is invoked only once for a BEGIN PERL...END PERL block; it is invoked most times that an expression is evaluated in an ?IF, ?ELSEIF or ?SET directive.

The Shorewall compiler provides a set of services that are available to Perl code embedded in an action file. These services are not available in in-line actions when running Shorewall 4.5.12 or earlier.

For examples of using these services, look at the standard actions in /usr/share/shorewall/action.*.

There may be cases where you wish to create a chain with rules that can't be constructed using the tools defined in the action.template. In that case, you can use an extension script. Beginning with Shorewall 4.5.16, such scripts require CHAIN_SCRIPTS=Yes in shorewall.conf (5)

DropBcasts

# This file is empty

use Shorewall::Chains;

if ( $level ne '' ) {
    log_rule_limit $level, $chainref, 'dropBcast' , 'DROP', '', $tag, 'add', ' -m addrtype --dst-type BROADCAST ';
    log_rule_limit $level, $chainref, 'dropBcast' , 'DROP', '', $tag, 'add', ' -d 224.0.0.0/4 ';
}

add_rule $chainref, '-m addrtype --dst-type BROADCAST -j DROP';
add_rule $chainref, '-d 224.0.0.0/4 -j DROP';

1;

For a richer example, see the next section.

Shorewall supports a “Limit” built-in action. Prior to Shorewall 4.4.16, Limit is invoked with a comma-separated list in place of a logging tag. Beginning in Shorewall 4.4.16, it may also be invoked with a list of three parameters enclosed in parentheses. The list has three elements:

Connections that exceed the specified rate are dropped.

For example, to use a recent list name of SSHA, and to limit SSH connections to 3 per minute, use this entry in /etc/shorewall/rules:

#ACTION                SOURCE            DEST           PROTO       DPORT
Limit:none:SSHA,3,60   net               $FW            tcp         22

Using Shorewall 4.4.16 or later, you can also invoke the action this way:

#ACTION                SOURCE            DEST           PROTO       DPORT
Limit(SSHA,3,60):none  net               $FW            tcp         22

If you want dropped connections to be logged at the info level, use this rule instead:

#ACTION                SOURCE            DEST           PROTO       DPORT
Limit:info:SSHA,3,60   net               $FW            tcp         22

Shorewall 4.4.16 and later:

#ACTION                SOURCE            DEST           PROTO       DPORT
Limit(SSH,3,60):info   net               $FW            tcp         22

To summarize, you pass four pieces of information to the Limit action:

use Shorewall::Chains;

@params = split( /,/, $tag ), $tag='' unless @params;

fatal_error 'Limit rules must include <list name>,<max connections>,<interval> as the log tag or params' unless @params == 3;

my $list = $params[0];

for ( @params[1,2] ) {
    fatal_error 'Max connections and interval in Limit rules must be numeric (' . $_ . ')' unless /^\d+$/
}

my $count = $params[1] + 1;

add_rule $chainref, "-m recent --name $list --set";

if ( $level ) {
    my $xchainref = new_chain 'filter' , "$chainref->{name}%";
    log_rule_limit $level, $xchainref, $params[0], 'DROP', $tag, '', 'add', '';
    add_rule $xchainref, '-j DROP';
    add_rule $chainref,  "-m recent --name $list --update --seconds $params[2] --hitcount $count -j $xchainref->{name}";
} else {
    add_rule $chainref, "-m recent --update --name $list --seconds $params[2] --hitcount $count -j DROP";
}

add_rule $chainref, '-j ACCEPT';

1; 

Beginning with Shorewall 5.0.7, actions are supported in shorewall-mangle(5). Like actions used out of shorewall-rules(5), they must be declared in shorewall-actions(5). These mangle actions must have the mangle option specified on shorewall-actions(5). Like the actions described in the preceding sections, mangle actions are defined in a files with names of the form action.action. Rules in those files have the same format as those in shorewall-mangle(5) with the restriction that chain designators (:P, :F, etc.) are not permitted in the ACTION column. Both regular and inline actions are supported.

Inline Example

/etc/shorewall/actions:

#ACTION     OPTIONS
Divert	     inline,mangle      # TProxy Rules

/etc/shorewall/action.Divert:

#ACTION         SOURCE          DEST            PROTO   DPORT   SPORT
DIVERT          COMB_IF         -               tcp     -       80
DIVERT          COMC_IF         -               tcp     -       80
DIVERT          DMZ_IF          172.20.1.0/24   tcp     -       80

/etc/shorewall/mangle:

#ACTION         SOURCE          DEST            PROTO   DPORT   SPORT
Divert

More efficient way to do this:

/etc/shorewall/actions:

#ACTION     OPTIONS
Divert	     inline             # TProxy Rules

/etc/shorewall/action.Divert:

#ACTION         SOURCE          DEST            PROTO   DPORT   SPORT
DIVERT          COMB_IF         -               
DIVERT          COMC_IF         -               
DIVERT          DMZ_IF          172.20.1.0/24

/etc/shorewall/mangle:

#ACTION         SOURCE          DEST            PROTO   DPORT   SPORT
Divert          -               -               tcp     -       80

Beginning with Shorewall 5.0.14, actions are supported in shorewall-snat(5); that file supercedes shorewall-masq(5) which is still supported. The shorewall update command will convert a masq file into the equivalent snat file. Like actions used out of shorewall-rules(5), SNAT actions must be declared in shorewall-actions(5). These mangle actions must have the nat option specified on shorewall-actions(5). Like the actions described in the preceding sections, SNAT actions are defined in a files with names of the form action.action. Rules in those files have the same format as those in shorewall-snat(5) with two restrictions:

Both regular and inline actions are supported.

Example:

/etc/shorewall/actions:

#ACTION     OPTIONS
custEPTs    nat,inline

/etc/shorewall/action.custEPTs:

#ACTION         SOURCE          DEST            PROTO   PORT
SNAT($GW_IP)    { proto=udp port=1146 }
SNAT($GW_IP)    { proto=tcp port=1156,7221,21000 }

/etc/shorewall/snat:

ACTION          SOURCE          DEST            PROTO   PORT
custEPTs  { source=$EPT_LIST dest=$IF_NET:$EPT_SERVERS }

More effeciently:

/etc/shorewall/actions:

#ACTION     OPTIONS
custEPTs    nat

/etc/shorewall/action.custEPTs:

#ACTION         SOURCE          DEST            PROTO   PORT
SNAT($GW_IP)    { proto=udp port=1146 }
SNAT($GW_IP)    { proto=tcp port=1156,7221,21000 }

/etc/shorewall/snat:

ACTION          SOURCE          DEST            PROTO   PORT
custEPT  { source=$EPT_LIST dest=$IF_NET:$EPT_SERVERS }