forked from extern/shorewall_code
108 lines
5.8 KiB
HTML
108 lines
5.8 KiB
HTML
|
<html>
|
||
|
|
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Language" content="en-us">
|
||
|
|
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
||
|
|
<meta name="ProgId" content="FrontPage.Editor.Document">
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
|
||
|
|
<title>Shorewall Extension Scripts</title>
|
||
|
|
<meta name="Microsoft Theme" content="boldstri 011, default">
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<body>
|
||
|
|
|
||
|
|
<h1 align="center">Extension Scripts</h1>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
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. The following scripts can be
|
||
|
|
supplied:</p>
|
||
|
|
<ul>
|
||
|
|
<li>init -- invoked early in "shorewall start" and "shorewall restart"</li>
|
||
|
|
<li>start -- invoked after the firewall has been started or restarted.</li>
|
||
|
|
<li>stop -- invoked as a first step when the firewall is being stopped.</li>
|
||
|
|
<li>stopped -- invoked after the firewall has been stopped.</li>
|
||
|
|
<li>clear -- invoked after the firewall has been cleared.</li>
|
||
|
|
<li>refresh -- invoked while the firewall is being refreshed but before the
|
||
|
|
common and/or blacklst chains have been rebuilt.</li>
|
||
|
|
<li>newnotsyn (added in version 1.3.6) -- invoked after the 'newnotsyn' chain
|
||
|
|
has been created but before any rules have been added to it.</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
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.</p>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>The following two files receive
|
||
|
|
special treatment:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li>/etc/shorewall/common -- If this file is present, the rules that it
|
||
|
|
defines will totally replace the default rules in the common chain. These
|
||
|
|
default rules are contained in the file /etc/shorewall/common.def which
|
||
|
|
may be used as a starting point for making your own customized file.</li>
|
||
|
|
<li>/etc/shorewall/icmpdef -- If this file is present, the rules that it
|
||
|
|
defines will totally replace the default rules in the icmpdef chain.
|
||
|
|
These default rules are contained in the file /etc/shorewall/icmp.def
|
||
|
|
which may be used as a starting point for making your own customized
|
||
|
|
file.</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Rather than running iptables directly, you should run it using the function
|
||
|
|
run_iptables. Similarly, rather than running "ip" directly, you should
|
||
|
|
use run_ip. These functions accept the same arguments as the underlying
|
||
|
|
command but cause the firewall to be stopped if an error occurs during
|
||
|
|
processing of the command.</p>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
If you decide to create /etc/shorewall/common or /etc/shorewall/icmp.def, it
|
||
|
|
is a good idea to use the following technique (common file shown but the same
|
||
|
|
technique applies to icmpdef).</p>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
/etc/shorewall/common:</p>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<blockquote>
|
||
|
|
<pre>source /etc/shorewall/common.def
|
||
|
|
<add your rules here></pre>
|
||
|
|
</blockquote>
|
||
|
|
<p>If you need to supercede a rule in the released common.def file, you can add
|
||
|
|
the superceding rule before the 'source' command. Using this technique allows
|
||
|
|
you to add new rules while still getting the benefit of the latest common.def
|
||
|
|
file.</p>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>Remember that /etc/shorewall/common and /etc/shorewall/icmpdef define rules
|
||
|
|
that are only applied if the applicable policy is DROP or REJECT. These rules
|
||
|
|
are NOT applied if the policy is ACCEPT or CONTINUE.<br>
|
||
|
|
</p>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p align="left"><font size="2">Last updated
|
||
|
|
8/5/2002 - <a href="support.htm">Tom
|
||
|
|
Eastep</a></font></p>
|
||
|
|
|
||
|
|
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002 Thomas M. Eastep</font></a></p>
|
||
|
|
|
||
|
|
</body>
|
||
|
|
|
||
|
|
</html>
|