Tom Eastep 2012 Thomas M. Eastep Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License.

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: Built-in Actions. These actions are known by the Shorewall code itself. They are listed in the comments at the top of the file /usr/share/shorewall/actions.std. Standard Actions. These actions are released as part of Shorewall. They are listed in the file /usr/share/shorewall/actions.std and are defined in the corresponding action.* files in /usr/share/shorewall. Each action.* file has a comment at the beginning of the file that describes what the action does. Here is an example: # Shorewall version 4 - Drop Action # # /usr/share/shorewall/action.Drop # # The default DROP common rules # # This action is invoked before a DROP policy is enforced. The purpose # of the action is: # # a) Avoid logging lots of useless cruft. # b) Ensure that 'auth' requests are rejected, even if the policy is # DROP. Otherwise, you may experience problems establishing # connections with servers that use auth. # c) Ensure that certain ICMP packets that are necessary for successful # internet operation are always ACCEPTed. # # The action accepts five optional parameters: # # 1 - 'audit' or '-'. Default is '-' which means don't audit in builtin # actions. # 2 - Action to take with Auth requests. Default is REJECT or A_REJECT, # depending on the setting of the first parameter. # 3 - Action to take with SMB requests. Default is DROP or A_DROP, # depending on the setting of the first parameter. # 4 - Action to take with required ICMP packets. Default is ACCEPT or # A_ACCEPT depending on the first parameter. # 5 - Action to take with late UDP replies (UDP source port 53). Default # is DROP or A_DROP depending on the first parameter. # # IF YOU ARE HAVING CONNECTION PROBLEMS, CHANGING THIS FILE WON'T HELP!!!!!!!!! # ############################################################################### FORMAT 2 # # The following magic provides different defaults for $2 thru $5, when $1 is # 'audit'. # ?BEGIN PERL; use Shorewall::Config; my ( $p1, $p2, $p3 , $p4, $p5 ) = get_action_params( 5 ); if ( defined $p1 ) { if ( $p1 eq 'audit' ) { set_action_param( 2, 'A_REJECT') unless supplied $p2; set_action_param( 3, 'A_DROP') unless supplied $p3; set_action_param( 4, 'A_ACCEPT' ) unless supplied $p4; set_action_param( 5, 'A_DROP' ) unless supplied $p5; } else { fatal_error "Invalid value ($p1) for first Drop parameter" if supplied $p1; } } 1; ?END PERL; DEFAULTS -,REJECT,DROP,ACCEPT,DROP #TARGET SOURCE DEST PROTO DPORT SPORT # # Count packets that come through here # COUNT # # Reject 'auth' # Auth($2) # # Don't log broadcasts # Broadcast(DROP,$1) # # ACCEPT critical ICMP types # AllowICMPs($4) - - icmp # # Drop packets that are in the INVALID state -- these are usually ICMP packets # and just confuse people when they appear in the log. # Invalid(DROP,$1) # # Drop Microsoft noise so that it doesn't clutter up the log. # SMB($3) DropUPnP($5) # # Drop 'newnotsyn' traffic so that it doesn't get logged. # NotSyn(DROP,$1) - - tcp # # Drop late-arriving DNS replies. These are just a nuisance and clutter up # the log. # DropDNSrep($5) Most of the standard actions use ?BEGIN PERL...?END PERL to perform special processing. See the Using Perl in Action files section for additional information. If you wish to modify one of the standard actions, do not modify the definition in /usr/share/shorewall. Rather, copy the file to /etc/shorewall (or somewhere else on your CONFIG_PATH) and modify the copy. User-defined Actions. These actions are created by end-users. They are listed in the file /etc/shorewall/actions and are defined in action.* files in /etc/shorewall or in another directory listed in your CONFIG_PATH (defined in /etc/shorewall/shorewall.conf).

Shorewall allows the association of a default action with policies. A separate default action may be associated with ACCEPT, DROP, REJECT, QUEUE and NFQUEUE policies. Default actions provide a way to invoke a set of common rules just before the policy is enforced. Default actions accomplish two goals: Relieve log congestion. Default actions typically include rules to silently drop or reject traffic that would otherwise be logged when the policy is enforced. Ensure correct operation. Default actions can also avoid common pitfalls like dropping connection requests on port TCP port 113. If these connections are dropped (rather than rejected) then you may encounter problems connecting to Internet services that utilize the AUTH protocol of client authentication AUTH is actually pretty silly on today's Internet but it's amazing how many servers still employ it. . Shorewall supports default actions for the ACCEPT, REJECT, DROP, QUEUE and NFQUEUE 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. Entries in the DROP and REJECT default actions ARE NOT THE CAUSE OF CONNECTION PROBLEMS. Remember — default actions are only invoked immediately before the packet is going to be dropped or rejected anyway!!! The standard Drop (see above) and Reject options are parameterized. Each has five parameters as follows: ACTION PARAMETER VALUE DEFAULT Drop 1 Either '-' or 'audit'. 'audit' causes auditing by the builtin actions invoked by Drop - Drop 2 Determines what to do with Auth requests REJECT or A_REJECT depending on the setting of parameter 1 Drop 3 Determines what to do with SMB DROP or A_DROP depending on the setting of parameter 1 Reject 1 Either '-' or 'audit'. 'audit' causes auditing by the builtin actions invoked by Drop - Reject 2 Determines what to do with Auth requests REJECT or A_REJECT depending on the setting of parameter 1 Reject 3 Determines what to do with SMB REJECT or A_REJECT depending on the setting of parameter 1 Both 4 Determines what to do with accepted critical ICMP packets. ACCEPT or A_ACCEPT depending on the setting of parameter 1 Both 5 Determines what to do with late-arriving DNS replies (source port 53) or UPnP (udp port 1900). DROP or A_DROP depending on the setting of parameter 1. 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 4.5.10, you may specify the inline option in /etc/shorewall/actions. As decribed above,