Copyright © 2001-2005 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”.
2005-05-13
Extension scripts are user-provided scripts that are invoked at various points during firewall start, restart, stop and clear. The scripts are placed in /etc/shorewall and are processed using the Bourne shell “source” mechanism.
Be sure that you actually need to use an extension script to do what you want. Shorewall has a wide range of features that cover most requirements.
DO NOT SIMPLY COPY RULES THAT YOU FIND ON THE NET INTO AN EXTENSION SCRIPT AND EXPECT THEM TO WORK AND TO NOT BREAK SHOREWALL. TO USE SHOREWALL EXTENSION SCRIPTS YOU MUST KNOW WHAT YOU ARE DOING WITH RESPECT TO iptables/Netfilter AND SHOREWALL.
The following scripts can be supplied:
init -- invoked early in “shorewall start” and “shorewall restart”
initdone (added in Shorewall 2.0.2 RC1) -- invoked after Shorewall has flushed all existing rules but before any rules have been added to the builtin chains.
start -- invoked after the firewall has been started or restarted.
stop -- invoked as a first step when the firewall is being stopped.
stopped -- invoked after the firewall has been stopped.
clear -- invoked after the firewall has been cleared.
refresh -- invoked while the firewall is being refreshed but before the common and/or blacklst chains have been rebuilt.
newnotsyn (added in version 1.3.6) -- invoked after the “newnotsyn” chain has been created but before any rules have been added to it.
continue (added in version 2.2.3) -- invoked to allow you to insert special rules to allow traffic while Shorewall is [re]starting. Any rules added in this script should be deleted in your start script. This script is invoked earlier in the [re]start process than is the initdone script described above.
If your version of Shorewall doesn't have the file that you want to use from the above list, you can simply create the file yourself. You can also supply a script with the same name as any of the filter chains in the firewall and the script will be invoked after the /etc/shorewall/rules file has been processed but before the /etc/shorewall/policy file has been processed.
There are a couple of special considerations for commands in extension scripts:
When you want to run iptables, use the command
run_iptables instead. run_iptables
will run the iptables utility passing the arguments to
run_iptables and if the command fails, the firewall
will be stopped (Shorewall version < 2.0.2 Beta 1 or there is no
/var/lib/shorewall/restore
file) or restored
(Shorewall version >= 2.0.2 Beta 1 and
/var/lib/shorewall/restore
exists).
If you wish to generate a log message, use log_rule_limit. Parameters are:
Log Level
Chain to insert the rule into
Chain name to display in the message (this can be different from the preceding argument — see the Port Knocking article for an example of how to use this).
Disposition to report in the message (ACCEPT, DROP, etc)
Rate Limit (if passed as "" then $LOGLIMIT is assumed — see the LOGLIMIT option in /etc/shorewall/shorewall.conf)
Log Tag ("" if none)
Command (-A or -I for append or insert). This argument applies to Shorewall 2.2.0 and later only.
The remaining arguments are passed "as is" to iptables
With Shorewall 2.0.2 Beta 1 and later versions, if you run
commands other than iptables that must be re-run in
order to restore the firewall to its current state then you must save
the commands to the restore file. The restore
file is a temporary file in /var/lib/shorewall
that will be renamed
/var/lib/shorewall/restore-base
at the successful
completion of the Shorewall command. The shorewall
save command combines
/var/lib/shorewall/restore-base
with the output of
iptables-save to produce the
/var/lib/shorewall/restore
script.
Here are three functions that are useful when running commands other than iptables:
save_command() -- saves the passed command to the restore file.
Example:
save_command echo Operation Complete
That command would simply write "echo Operation Complete" to the restore file.
run_and_save_command() -- saves the passed command to the restore file then executes it. The return value is the exit status of the command. Example:
run_and_save_command "echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all"
Note that as in this example, when the command involves file redirection then the entire command must be enclosed in quotes. This applies to all of the functions described here.
ensure_and_save_command() -- runs the passed command. If the command fails, the firewall is restored to it's prior saved state and the operation is terminated. If the command succeeds, the command is written to the restore file
Beginning with Shorewall 2.0.0, you can also define a common action to be performed immediately before a policy of ACCEPT, DROP or REJECT is applied. Separate actions can be assigned to each policy type so for example you can have a different common action for DROP and REJECT policies. The most common usage of common actions is to silently drop traffic that you don't wish to have logged by the policy.
As released, Shorewall defines a number of actions which are cataloged
in the /usr/share/shorewall/actions.std
file. That file
is processed before /etc/shorewall/actions. Among the entries in
/usr/share/shorewall/actions.std
are:
Drop:DROP Reject:REJECT
So the action named “Drop” is performed immediately
before DROP policies are applied and the action called “Reject”
is performed before REJECT policies are applied. These actions are defined
in the files /usr/share/shorewall/action.Drop
and
/usr/share/shorewall/action.Reject
respectively.
You can override these defaults with entries in your /etc/shorewall/actions file. For example, if that file were to contain “MyDrop:DROP” then the common action for DROP policies would become “MyDrop”.
One final note. The chain created to perform an action has the same
name as the action. You can use an extension script by that name to add
rules to the action's chain in the same way as you can any other chain. So
if you create the new action “Dagger” and define it in
/etc/shorewall/action.Dagger
, you can also have an
extension script named /etc/shorewall/Dagger
that can
add rules to the “Dagger” chain that can't be created using
/etc/shorewall/action.Dagger
.