Web site udates

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2067 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2005-05-01 17:02:37 +00:00
parent 0a50339757
commit 0bfeb860a9
7 changed files with 910 additions and 799 deletions

View File

@ -18,11 +18,773 @@ Texts. A copy of the license is included in the section entitled “<span
class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free
Documentation License</a></span>”.<br>
</p>
<p>2005-02-01<br>
<p>2005-04-14<br>
</p>
<hr style="width: 100%; height: 2px;">
<p><span style="font-weight: bold;"><br>
</span><span style="font-weight: bold;">01/17/2005 -
</span><span style="font-weight: bold;">02/15/2005
Shorewall 2.2.1<br>
<br>
</span>This release rolls up the fixes for bugs found in the first 2-3
weeks of deployment of Shorewall 2.2.<br>
</p>
<ol>
<li>The /etc/shorewall/policy file contained a misleading comment and
both that file and the /etc/shorewall/zones file lacked examples.</li>
<li>Shorewall previously used root's default umask which could cause
files in /var/lib/shorewall to be world-readable. Shorewall now uses
umask 0177.</li>
<li>In log messages produced by logging a built-in action, the packet
disposition was displayed incorrectly.<br>
<br>
&nbsp;&nbsp; Example:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
rejNotSyn:ULOG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
all&nbsp;&nbsp;&nbsp;&nbsp;
all&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
tcp<br>
<br>
&nbsp;&nbsp; produces the log message:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Feb
12 23:57:08 server Shorewall:rejNotSyn:ULOG: ...<br>
<br>
&nbsp;&nbsp; rather than<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Feb
12 23:57:08 server Shorewall:rejNotSyn:REJECT: ...<br>
<br>
</li>
<li>The comments regarding built-in actions in
/usr/share/shorewall/actions.std have been corrected.</li>
<li>The /etc/shorewall/policy file in the LRP package was missing the
'all-&gt;all' policy.<br>
</li>
</ol>
<span style="font-weight: bold;">02/05/2005
End of Support for Shorewall 1.4<br>
<br>
</span>Effective today, support for Shorewall 1.4 has been
discontinued. See the link at the top of this article for&nbsp; upgrade
information.<br>
<br>
<span style="font-weight: bold;">02/01/2005
Shorewall 2.0.16<br>
</span><br>
This release back-ports the DROPINVALID shorewall.conf option from
2.2.0.<br>
<ol>
<li>Recent 2.6 kernels include code that evaluates TCP packets based
on TCP Window analysis. This can cause packets that were previously
classified as NEW or ESTABLISHED to be classified as INVALID.<br>
<br>
The new kernel code can be disabled by including this command in your
/etc/shorewall/init file:<br>
<br>
echo 1 &gt; /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal<br>
<br>
Additional kernel logging about INVALID TCP packets may be obtained by
adding this command to /etc/shorewall/init:<br>
<br>
echo 1 &gt; /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid<br>
<br>
Traditionally, Shorewall has dropped INVALID TCP packets early. The new
DROPINVALID option allows INVALID packets to be passed through the
normal rules chains by setting DROPINVALID=No.<br>
<br>
If not specified or if specified as empty (e.g., DROPINVALID="") then
DROPINVALID=Yes is assumed.</li>
</ol>
<p><span style="font-weight: bold;">02/01/2005
Shorewall 2.2.0<br>
<br>
</span>New Features:<br>
</p>
<ol>
<li>ICMP packets that are in the INVALID state are now dropped by the
Reject and Drop default actions. They do so using the new 'dropInvalid'
builtin action. An 'allowInvalid' builtin action is also provided which
accepts packets in that state.</li>
<li>The /etc/shorewall/masq file INTERFACE column now allows
additional options.<br>
<br>
Normally MASQUERADE/SNAT rules are evaluated after one-to-one NAT rules
defined in the /etc/shorewall/nat file. If you preceed the interface
name with a plus sign ("+") then the rule will be evaluated before
one-to-one NAT.<br>
<br>
Examples:<br>
<br>
+eth0<br>
+eth1:192.0.2.32/27<br>
<br>
Also, the effect of ADD_SNAT_ALIASES=Yes can be negated for an entry by
following the interface name by ":" but no digit. <br>
<br>
Examples:<br>
<br>
eth0:<br>
eth1::192.0.2.32/27<br>
+eth3:<br>
<br>
</li>
<li>Similar to 2), the /etc/shorewall/nat file INTERFACE column now
allows you to override the setting of ADD_IP_ALIASES=Yes by following
the interface name with ":" but no digit.</li>
<li>All configuration files in the Shorewall distribution with the
exception of shorewall.conf are now empty. In particular, the
/etc/shorewall/zones, /etc/shorewall/policy and /etc/shorewall/tos
files now have no active entries. Hopefully this will stop the
questions on the support and development lists regarding why the
default entries are the way they are.</li>
<li>Previously, including a log level (and optionally a log tag) on a
rule that specified a user-defined (or Shorewall-defined) action would
log all traffic passed to the action. Beginning with this release,
specifying a log level in a rule that specifies a user- or
Shorewall-defined action will cause each rule in the action to be
logged with the specified level (and tag).<br>
<br>
The extent to which logging of action rules occurs is goverend by the
following:</li>
<ul>
<li>When you invoke an action and specify a log level, only those
rules in the action that have no log level will be changed to log at
the level specified at the action invocation.<br>
<br>
Example:<br>
<br>
/etc/shorewall/action.foo:<br>
<br>
ACCEPT&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;
tcp&nbsp;&nbsp;&nbsp; 22<br>
bar:info<br>
<br>
/etc/shorewall/rules:<br>
<br>
foo:debug&nbsp;&nbsp;&nbsp; fw&nbsp;&nbsp;&nbsp; net<br>
<br>
Logging in the invoked 'foo' action will be:<br>
<br>
ACCEPT:debug&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;
tcp&nbsp;&nbsp;&nbsp; 22<br>
bar:info<br>
<br>
</li>
<li>If you follow the log level with "!" then logging will be at
that level for all rules recursively invoked by the action<br>
<br>
Example: /etc/shorewall/action.foo:<br>
<br>
<b>Update: </b>I've been
informed by Mandrake Development that this problem has been corrected
in Mandrake 10.0 Final (the problem still exists in the 10.0
Community release).<br>
ACCEPT&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;
tcp&nbsp;&nbsp;&nbsp; 22<br>
bar:info<br>
<br>
/etc/shorewall/rules:<br>
<br>
foo:debug!&nbsp;&nbsp;&nbsp; fw&nbsp;&nbsp;&nbsp; net<br>
<br>
Logging in the invoke 'foo' action will be:<br>
<br>
ACCEPT:debug&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;
tcp&nbsp;&nbsp;&nbsp; 22<br>
bar:debug!<br>
<br>
</li>
</ul>
</ol>
<div style="margin-left: 40px;">This change has an effect on extension
scripts used with user-defined actions. If you define an action 'acton'
and you have an /etc/shorewall/acton script then when that script is
invoked, the following three variables will be set for use by the
script:<br>
<br>
<div style="margin-left: 40px;">$CHAIN = the name of the chain where
your rules are to be placed. When logging is used on an action
invocation, Shorewall creates a chain with a slightly different name
from the action itself.<br>
$LEVEL = Log level. If empty, no logging was specified.<br>
$TAG&nbsp;&nbsp; = Log Tag.<br>
<br>
</div>
Example:<br>
<br>
/etc/shorewall/rules:<br>
&nbsp;&nbsp;&nbsp; <br>
acton:info:test<br>
<br>
Your /etc/shorewall/acton file will be run with:<br>
<br>
<div style="margin-left: 40px;">$CHAIN="%acton1<br>
$LEVEL="info"<br>
$TAG="test"<br>
</div>
</div>
<br>
<ol start="6">
<li>The /etc/shorewall/startup_disabled file is no longer created
when
Shorewall is first installed. Rather, the variable STARTUP_ENABLED is
set to 'No' in /etc/shorewall/shorewall.conf. In order to get Shorewall
to start, that variable's value must be set to 'Yes'. This change
accomplishes two things:</li>
<ul>
<li>It prevents Shorewall from being started prematurely by the
user's initialization scripts.</li>
<li>It causes /etc/shorewall/shorewall.conf to be modified so that
it won't be replaced by upgrades using RPM.<br>
<br>
</li>
</ul>
<li>Support has been added for the 2.6 Kernel IPSEC implementation.
To use this support, you must have installed the IPSEC policy match
patch and the four IPSEC/Netfilter patches from Patch-0-Matic-ng. The
policy match patch affects both your kernel and iptables. There are two
ways to specify that IPSEC is to be used when communicating with a set
of hosts; both methods involve the new /etc/shorewall/ipsec file:</li>
<ol style="list-style-type: lower-alpha;">
<li>If encrypted communication is used with all hosts in a zone,
then you can designate the zone as an "ipsec" zone by placing 'Yes" in
the IPSEC ONLY column in /etc/shorewall/ipsec:<br>
<br>
<span style="font-family: monospace;">#ZONE&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp; IPSEC&nbsp;&nbsp;&nbsp; OPTIONS ...</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">#&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; ONLY</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Yes</span><span
style="font-family: sans-serif;"></span><br>
<br>
The hosts in the zone (if any) must be specified in
/etc/shorewall/hosts but you do not need to specify the 'ipsec' option
on the entries in that file (see below). Dynamic zones involving IPSEC
must use that technique.<br>
<br>
Example:Under 2.4 Kernel FreeS/Wan:<br>
<br>
/etc/shorewall/zones:<br>
<br>
<span style="font-family: monospace;">net&nbsp;&nbsp;&nbsp;
Net&nbsp;&nbsp;&nbsp; The big bad Internet</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
VPN&nbsp;&nbsp;&nbsp; Remote Network</span><br>
<br>
/etc/shorewall/interfaces:<br>
<br>
<span style="font-family: monospace;">net&nbsp;&nbsp;&nbsp;
eth0&nbsp;&nbsp;&nbsp; ...</span><br style="font-family: monospace;">
<span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
ipsec0&nbsp;&nbsp;&nbsp; ...</span><br>
<br>
Under 2.6 Kernel with this new support:<br>
<br>
/etc/shorewall/zones:<br>
<br>
<span style="font-family: monospace;">net&nbsp;&nbsp;&nbsp;
Net&nbsp;&nbsp;&nbsp; The big bad Internet</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
VPN&nbsp;&nbsp;&nbsp; Remote Network</span><br>
<br>
/etc/shorewall/interfaces:<br>
<br>
<span style="font-family: monospace;">net&nbsp;&nbsp;&nbsp;
eth0&nbsp;&nbsp;&nbsp; ...</span><br>
<br>
/etc/shorewall/hosts:<br>
<br>
<span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
eth0:0.0.0.0/0</span><br>
<br>
/etc/shorewall/ipsec<br>
<br>
<span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp; Yes<br>
<br>
</span> </li>
<li>If only part of the hosts in a zone require encrypted
communication, you may use of the new 'ipsec' option in
/etc/shorewall/hosts to designate those hosts.<br>
<br>
Example:<br>
<br>
Under 2.4 Kernel FreeS/Wan:<br>
<br>
/etc/shorewall/zones:<br>
<pre>net&nbsp;&nbsp;&nbsp; Net&nbsp;&nbsp;&nbsp; The big bad Internet<br>loc&nbsp;&nbsp;&nbsp; Local&nbsp; Extended local zone</pre>
/etc/shorewall/interfaces:<br>
<br>
<span style="font-family: monospace;">net&nbsp;&nbsp;&nbsp;
eth0&nbsp;&nbsp;&nbsp; ...</span><br style="font-family: monospace;">
<span style="font-family: monospace;">loc&nbsp;&nbsp;&nbsp;
eth1&nbsp;&nbsp;&nbsp; ...</span><br style="font-family: monospace;">
<span style="font-family: monospace;">loc&nbsp;&nbsp;&nbsp;
ipsec0&nbsp;&nbsp;&nbsp; ...</span><br>
<br>
Under 2.6 Kernel with this new support:<br>
<br>
/etc/shorewall/zones:<br>
<br>
<span style="font-family: monospace;">net&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp; Net&nbsp;&nbsp;&nbsp; The big bad Internet</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; VPN&nbsp;&nbsp;&nbsp; Remote Network</span><br>
<br>
/etc/shorewall/interfaces:<br>
<br>
<span style="font-family: monospace;">net&nbsp;&nbsp;&nbsp;
eth0&nbsp;&nbsp;&nbsp; ...</span><br style="font-family: monospace;">
<span style="font-family: monospace;">loc&nbsp;&nbsp;&nbsp;
eth1&nbsp;&nbsp;&nbsp; ...</span><br>
<br>
/etc/shorewall/hosts:<br>
<br>
<span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
eth0:0.0.0.0/0&nbsp;&nbsp;&nbsp; ipsec,...</span></li>
</ol>
</ol>
<div style="margin-left: 40px;">Regardless of which technique you
choose, you can specify additional SA options for the zone in the
/etc/shorewall/ipsec entry.<br>
<br>
The OPTIONS, IN OPTIONS and OUT OPTIONS columns specify the
input-output, input and output characteristics of the security
associations to be used to decrypt (input) or encrypt (output) traffic
to/from the zone.<br>
<br>
The available options are:<br>
</div>
<ul>
<ul>
<li>reqid[!]=&lt;number&gt; where &lt;number&gt; is specified using
setkey(8) using the 'unique:&lt;number&gt;' option for the SPD level.</li>
<li>spi[!]=&lt;number&gt; where &lt;number&gt; is the SPI of the
SA. Since different SAs are used to encrypt and decrypt traffic, this
option should only be listed in the IN OPTIONS and OUT OPTIONS columns.</li>
<li>proto[!]=ah|esp|ipcomp</li>
<li>mss=&lt;number&gt; (sets the MSS value in TCP SYN packets and
is not related to policy matching)</li>
<li>mode[!]=transport|tunnel</li>
<li>tunnel-src[!]=&lt;address&gt;[/&lt;mask&gt;] (only available
with mode=tunnel)</li>
<li>tunnel-dst[!]=&lt;address&gt;[/&lt;mask&gt;] (only available
with mode=tunnel). Because tunnel source and destination are dependent
on the direction of the traffic, these options should only appear in
the IN OPTIONS and OUT OPTIONS columns.</li>
<li>strict&nbsp; (if specified, packets must match all policies;
policies are delimited by 'next').</li>
<li>next&nbsp;&nbsp;&nbsp; (only available with strict)</li>
</ul>
</ul>
<div style="margin-left: 40px;">Examples:<br>
<br>
<span style="font-family: monospace;">#ZONE&nbsp;&nbsp;&nbsp;
IPSEC&nbsp; OPTIONS&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
IN&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OUT</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ONLY&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;
OPTIONS&nbsp;&nbsp;&nbsp;&nbsp; OPTIONS</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Yes&nbsp;&nbsp;&nbsp; mode=tunnel,proto=esp&nbsp;&nbsp;&nbsp;
spi=1000&nbsp;&nbsp;&nbsp; spi=1001</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">loc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
No&nbsp;&nbsp;&nbsp;&nbsp; reqid=44,mode=transport</span><br>
<br>
The /etc/shorewall/masq file has a new IPSEC column added. If you
specify Yes or yes in that column then the unencrypted packets will
have their source address changed. Otherwise, the unencrypted packets
will not have their source addresses changed. This column may also
contain a comma-separated list of the options specified above in which
case only those packets that will be encrypted by an SA matching the
given options will have their source address changed.<br>
</div>
<ol start="8">
<li>To improve interoperability, tunnels of type 'ipsec' no longer
enforce the use of source port 500 for ISAKMP and OpenVPN tunnels no
longer enforce use of the specified port as both the source and
destination ports.</li>
<li>A new 'allowBcast' builtin action has been added -- it silently
allows broadcasts and multicasts.</li>
<li>The -c option in /sbin/shorewall commands is now deprecated. The
commands where -c was previously allowed now permit you to specify a
configuration directory after the command:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall check&nbsp;&nbsp; [
&lt;configuration-directory&gt; ]<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall restart [
&lt;configuration-directory&gt; ]<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall start&nbsp;&nbsp; [
&lt;configuration-directory&gt; ]<br>
<br>
</li>
<li>Normally, when SNAT or MASQUERADE is applied to a tcp or udp
connection, Netfilter attempts to retain the source port number. If it
has to change to port number to avoid&nbsp; &lt;source
address&gt;,&lt;source port&gt; conflicts, it tries to do so within
port ranges ( &lt; 512, 512-1023, and &gt; 1023). You may now specify
an explicit range of source ports to be used by following the address
or address range (if any) in the ADDRESS column with ":" and a port
range in the format &lt;low-port&gt;-&lt;high-port&gt;. You must
specify either "tcp" or "udp" in the PROTO column.<br>
<br>
Examples 1 -- MASQUERADE with tcp source ports 4000-5000:<br>
<br>
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp; #INTERFACE
SUBNET&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;
ADDRESS&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; PROTO</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
eth0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.0/24&nbsp;
:4000-5000&nbsp;&nbsp;&nbsp;&nbsp; tcp</span><br
style="font-family: monospace;">
<br>
Example 2 -- SNAT with udp source ports 7000-8000:<br>
<br>
&nbsp;&nbsp;&nbsp; <span style="font-family: monospace;">#INTERFACE
SUBNET&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;
ADDRESS&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
PROTO</span><br style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;
eth0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
10.0.0.0/8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
192.0.2.44:7000-8000&nbsp;&nbsp;&nbsp; udp<br>
<br>
</span></li>
<li>You may now account by user/group ID for outbound traffic from
the firewall itself with entries in /etc/shorewall/accounting. Such
accounting rules must be placed in the OUTPUT chain. See the comments
at the top of /etc/shorewall/accounting for details.</li>
<li>Shorewall now verifies that your kernel and iptables have physdev
match support if BRIDGING=Yes in shorewall.conf.</li>
<li>Beginning with this release, if your kernel and iptables have
iprange match support (see the output from "shorewall check"), then
with the exception of the /etc/shorewall/netmap file, anywhere that a
network address may appear an IP address range of the form &lt;low
address&gt;-&lt;high address&gt; may also appear.</li>
<li>Support has been added for the iptables CLASSIFY target. That
target allows you to classify packets for traffic shaping directly
rather than indirectly through fwmark. Simply enter the
&lt;major&gt;:&lt;minor&gt; classification in the first column of
/etc/shorewall/tcrules:<br>
<br>
Example:<br>
<br>
<span style="font-family: monospace;">#MARK/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SOURCE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
DEST&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROTO&nbsp;&nbsp;&nbsp;&nbsp; PORT(S)</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">#CLASSIFY</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">1:30&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp; eth0&nbsp;&nbsp;&nbsp; &nbsp; tcp&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; 25</span><br>
<br>
Note that when using this form of rule, it is acceptable to include the
name of an interface in the DEST column.<br>
<br>
Marking using the CLASSIFY target always occurs in the POSTROUTING
chain of the mangle table and is not affected by the setting of
MARK_IN_FORWARD_CHAIN in shorewall.conf.</li>
<li>During "shorewall start", IP addresses to be added as a
consequence of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes are quietly
deleted when /etc/shorewall/nat and /etc/shorewall/masq are processed
then they are re-added later. This is done to help ensure that the
addresses can be added with the specified labels but can have the
undesirable side effect of causing routes to be quietly deleted. A new
RETAIN_ALIASES option has been added to shorewall.conf; when this
option is set to Yes, existing addresses will not be deleted.
Regardless of the setting of RETAIN_ALIASES, addresses added during
"shorewall start" are still deleted at a subsequent "shorewall stop" or
"shorewall restart".</li>
<li>Users with a large black list (from /etc/shorewall/blacklist) may
want to set the new DELAYBLACKLISTLOAD option in shorewall.conf. When
DELAYBLACKLISTLOAD=Yes, Shorewall will enable new connections before
loading the blacklist rules. While this may allow connections from
blacklisted hosts to slip by during construction of the blacklist, it
can substantially reduce the time that all new connections are disabled
during "shorewall [re]start".</li>
<li>Using the default LOGFORMAT, chain names longer than 11
characters (such as in user-defined actions) may result in log prefix
truncation. A new shorewall.conf action&nbsp; LOGTAGONLY has been added
to deal with this problem. When LOGTAGONLY=Yes, logging rules that
specify a log tag will substitute the tag for the chain name in the log
prefix.<br>
<br>
Example -- file /etc/shorewall/action.thisisaverylogactionname:<br>
<br>
&nbsp;&nbsp;&nbsp; Rule:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span
style="font-family: monospace;">DROP:info:ftp&nbsp;&nbsp;&nbsp;
0.0.0.0/0&nbsp;&nbsp;&nbsp; 0.0.0.0/0&nbsp;&nbsp;&nbsp;
tcp&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 21</span><br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; Log prefix with LOGTAGONLY=No:<br>
<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; <span style="font-family: monospace;">Shorewall:thisisaverylongacti</span><br>
<br>
&nbsp;&nbsp;&nbsp; Log prefix with LOGTAGONLY=Yes:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span
style="font-family: monospace;">Shorewall:ftp:DROP</span><br>
<br>
</li>
<li>Shorewall now resets the 'accept_source_route' flag for all
interfaces. If you wish to accept source routing on an interface, you
must specify the new 'sourceroute' interface option in
/etc/shorewall/interfaces.</li>
<li>The default Drop and Reject actions now invoke the new standard
action 'AllowICMPs'. This new action accepts critical ICMP types:<br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; Type 3 code 4 (fragmentation needed)<br>
&nbsp;&nbsp;&nbsp; Type 11&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (TTL
exceeded)<br>
<br>
</li>
<li>Explicit control over the kernel's Martian logging is now
provided using the new 'logmartians' interface option. If you include
'logmartians' in the interface option list then logging of Martian
packets on will be enabled on the specified interface. If you wish to
globally enable martian logging, you can set LOG_MARTIANS=Yes in
shorewall.conf.</li>
<li>You may now cause Shorewall to use the '--set-mss' option of the
TCPMSS target. In other words, you can cause Shorewall to set the MSS
field of SYN packets passing through the firewall to the value you
specify. This feature extends the existing CLAMPMSS option in
/etc/shorewall/shorewall.conf by allowing that option to have a numeric
value as well as the values "Yes" and "No".<br>
<br>
Example:<br>
<br>
&nbsp;&nbsp;&nbsp; CLAMPMSS=1400<br>
<br>
</li>
<li>Shorewall now includes support for the ipp2p match facility. This
is a departure from my usual policy in that the ipp2p match facility is
included in Patch-O-Matic-NG and is unlikely to ever be included in the
kernel.org source tree. Questions about how to install the patch or how
to build your kernel and/or iptables should not be posted on the
Shorewall mailing lists.<br>
<br>
In the following files, the "PROTO" or "PROTOCOL" column may contain
"ipp2p":<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /etc/shorewall/rules<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /etc/shorewall/tcrules<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /etc/shorewall/accounting<br>
<br>
When the PROTO or PROTOCOL column contains "ipp2p" then the DEST
PORT(S) or PORT(S) column may contain a recognized ipp2p option; for a
list of the options and their meaning, at a root prompt:<br>
<br>
&nbsp;&nbsp;&nbsp; iptables -m ipp2p --help<br>
<br>
You must not include the leading "--" on the option; Shorewall will
supply those characters for you. If you do not include an option then
"ipp2p" is assumed (Shorewall will generate "-m ipp2p --ipp2p").</li>
<li>Shorewall now has support for the CONNMARK target from iptables.
See the /etc/shorewall/tcrules file for details.</li>
<li>A new debugging option LOGALLNEW has been added to
shorewall.conf. When set to a log level, this option causes Shorewall
to generaate a logging rule as the first rule in each builtin chain.<br>
<br>
&nbsp;&nbsp;&nbsp; - The table name is used as the chain name in the
log prefix.<br>
&nbsp;&nbsp;&nbsp; - The chain name is used as the target in the log
prefix.<br>
<br>
Example: Using the default LOGFORMAT, the log prefix for logging from
the nat table's PREROUTING chain is:<br>
<br>
&nbsp;&nbsp;&nbsp; &nbsp;<span style="font-family: monospace;">Shorewall:nat:PREROUTING</span><br>
<br>
IMPORTANT: There is no rate limiting on these logging rules so use
LOGALLNEW at your own risk; it may cause high CPU and disk utilization
and you may not be able to control your firewall after you enable this
option.<br>
<br>
DANGER: DO NOT USE THIS OPTION IF THE RESULTING LOG MESSAGES WILL BE
SENT TO ANOTHER SYSTEM.<br>
<br>
</li>
<li>The SUBNET column in /etc/shorewall/rfc1918 has been renamed
SUBNETS and it is now possible to specify a list of addresses in that
column.</li>
<li>The AllowNNTP action now also allows NNTP over SSL/TLS (NNTPS).</li>
<li>For consistency, the CLIENT PORT(S) column in the tcrules file
has been renamed SOURCE PORT(S).</li>
<li>The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is now
shown in the output of "shorewall status".</li>
<li>A new IPTABLES option has been added to shorewall.conf. IPTABLES
can be used to designate the iptables executable to be used by
Shorewall. If not specified, the iptables executable determined by the
PATH setting is used.</li>
<li>You can now use the "shorewall show zones" command to display the
current contents of the zones. This is particularly useful if you use
dynamic zones (DYNAMIC_ZONES=Yes in shorewall.conf).<br>
<br>
&nbsp;&nbsp;&nbsp; Example:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span style="font-family: monospace;">ursa:/etc/shorewall
# shorewall show zones</span><br style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
Shorewall-2.2.0-Beta7 Zones at ursa - Sat Nov 27 11:18:25 PST 2004</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp; loc</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; eth0:192.168.1.0/24</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; eth1:1.2.3.4</span><br style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
net&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; </span><br
style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; eth0:0.0.0.0/0</span><br style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp; WiFi</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; eth1:0.0.0.0/0</span><br style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp; sec</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; eth1:0.0.0.0/0</span><br style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
ursa:/etc/shorewall #</span><br>
<br>
</li>
<li>Variable expansion may now be used with the INCLUDE directive.<br>
<br>
&nbsp;&nbsp;&nbsp; Example:<br>
<br>
&nbsp;&nbsp;&nbsp; /etc/shorewall/params<br>
<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <span
style="font-family: monospace;">FILE=/etc/foo/bar</span><br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Any other config file:<br>
<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <span
style="font-family: monospace;">INCLUDE $FILE</span><br>
<br>
</li>
<li>The output of "shorewall status" now includes the results of "ip
-stat link ls". This helps diagnose performance problems caused by link
errors.</li>
<li>Previously, when rate-limiting was specified in
/etc/shorewall/policy (LIMIT:BURST column), any traffic which exceeded
the specified rate was silently dropped. Now, if a log level is given
in the entry (LEVEL column) then drops are logged at that level at a
rate of 5/min with a burst of 5.</li>
<li>Recent 2.6 kernels include code that evaluates TCP packets based
on TCP Window analysis. This can cause packets that were previously
classified as NEW or ESTABLISHED to be classified as INVALID.<br>
<br>
The new kernel code can be disabled by including this command in your
/etc/shorewall/init file:<br>
<br>
&nbsp;&nbsp;&nbsp; <span style="font-family: monospace;">echo 1 &gt;
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal</span><br>
<br>
Additional kernel logging about INVALID TCP packets may be obtained by
adding this command to /etc/shorewall/init:<br>
<br>
&nbsp;&nbsp;&nbsp; <span style="font-family: monospace;">echo 1 &gt;
/proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid</span><br>
<br>
Traditionally, Shorewall has dropped INVALID TCP packets early. The new
DROPINVALID option allows INVALID packets to be passed through the
normal rules chains by setting DROPINVALID=No.<br>
<br>
If not specified or if specified as empty (e.g., DROPINVALID="") then
DROPINVALID=Yes is assumed.<br>
<br>
</li>
<li>The "shorewall add" and "shorewall delete" commands now accept a
list of hosts to add or delete.<br>
<br>
Examples:<br>
<br>
&nbsp;&nbsp;&nbsp;<span style="font-family: monospace;"> shorewall add
eth1:1.2.3.4 eth1:2.3.4.5 z12</span><br style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp; shorewall delete
eth1:1.2.3.4 eth1:2.3.4.5 z12</span><br>
<br>
&nbsp;&nbsp;&nbsp; The above commands may also be written:<br>
<br>
&nbsp;&nbsp;&nbsp; <span style="font-family: monospace;">shorewall add
eth1:1.2.3.4,2.3.4.5 z12</span><br style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp; shorewall delete
eth1:1.2.3.4,2.3.4.5 z12</span><br>
&nbsp;&nbsp; <br>
</li>
<li>TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel
type. OpenVPN entries in /etc/shorewall/tunnels have this format:<br>
<br>
&nbsp;&nbsp;&nbsp; <span style="font-family: monospace;">openvpn[:{tcp|udp}][:&lt;port&gt;]&nbsp;&nbsp;&nbsp;
&lt;zone&gt;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;gateway&gt;</span><br>
<br>
Examples:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span style="font-family: monospace;">openvpn:tcp&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
1.2.3.4&nbsp;&nbsp;&nbsp; # TCP tunnel on port 1194</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
openvpn:3344&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
1.2.3.4&nbsp;&nbsp;&nbsp; # UDP on port 3344</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
openvpn:tcp:4455&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
1.2.3.4&nbsp;&nbsp;&nbsp; # TCP on port 4455</span><br>
<br>
</li>
<li>A new 'ipsecvpn' script is included in the tarball and in the
RPM. The RPM installs the file in the Documentation directory
(/usr/share/doc/packages/shorewall-2.2.0-0RC1).<br>
<br>
This script is intended for use on Roadwarrior laptops for establishing
an IPSEC SA to/from remote networks. The script has some limitations:</li>
</ol>
<ul>
<ul>
<li>Only one instance of the script may be used at a time.</li>
<li>Only the first SPD accessed will be instantiated at the remote
gateway. So while the script creates SPDs to/from the remote gateway
and each network listed in the NETWORKS setting at the front of the
script, only one of these may be used at a time.</li>
</ul>
</ul>
<ol start="39">
<li>The output of "shorewall status" now lists the loaded netfilter
kernel modules.</li>
<li>The range of UDP ports opened by the AllowTrcrt action has been
increased to 33434:33524.</li>
<li>The IANA has recently registered port 1194 for use by OpenVPN. In
previous versions of Shorewall (and OpenVPN), the default port was 5000
but has been changed to 1194 to conform to the new OpenVPN default.</li>
</ol>
<p><span style="font-weight: bold;">01/17/2005 -
Shorewall 2.2.0 RC5<br>
<br>
</span>Problems Corrected:<br>

View File

@ -38,10 +38,7 @@ Repository</font></a><font color="#ffffff"><br>
<a href="errata.htm"><font color="#ffffff">Errata</font></a><font
color="#ffffff"><br>
<a href="shorewall_features.htm"><font color="#ffffff">Features</font></a><font
color="#ffffff"> <br>
<a href="http://lists.shorewall.net"><font color="#ffffff">Mailing
Lists</font></a><font color="#ffffff"><a
href="http://lists.shorewall.net"> </a> <br>
color="#ffffff"> <font color="#ffffff"><br>
<a href="shorewall_mirrors.htm"><font color="#ffffff">Mirrors</font></a><font
color="#ffffff"> <br>
<a href="News.htm"><font color="#ffffff">News Archive</font></a><font

View File

@ -37,10 +37,7 @@ Repository</font></a><font color="#ffffff"><br>
<a href="errata.htm"><font color="#ffffff">Errata</font></a><font
color="#ffffff"><br>
<a href="shorewall_features.htm"><font color="#ffffff">Features</font></a><font
color="#ffffff"> <br>
<a href="http://lists.shorewall.net"><font color="#ffffff">Mailing
Lists</font></a><font color="#ffffff"><a
href="http://lists.shorewall.net"> </a> <br>
color="#ffffff"> <font color="#ffffff"><br>
<a href="shorewall_mirrors.htm"><font color="#ffffff">Mirrors</font></a><font
color="#ffffff"> <br>
<a href="News.htm"><font color="#ffffff">News Archive</font></a><font
@ -55,7 +52,7 @@ Issues</font></a><font color="#ffffff"><br>
color="#ffffff"><br>
<a href="Shorewall_Doesnt.html"><font color="#ffffff">What it
Cannot Do</font></a>
</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font>
</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font>
<ul>
</ul>
<p><font color="#ffffff"><font color="#ffffff"><font color="#ffffff"><font

View File

@ -22,7 +22,7 @@ Texts. A copy of the license is included in the section entitled “<span
class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free
Documentation License</a></span>”.<br>
</p>
<p>2005-03-16<br>
<p>2005-03-22<br>
</p>
<hr style="width: 100%; height: 2px;">
<p><b>I strongly urge you to read and print a copy of the <a
@ -64,7 +64,8 @@ his site</a>. <br>
</li>
<li>Jack Coates provides RPMs taylored for <span
style="font-weight: bold;">Mandrake.</span> You can <a
href="http://www.monkeynoodle.org/tmp">download them from his site</a>.</li>
href="http://www.monkeynoodle.org/comp/net/shorewall/">download them
from his site</a>.</li>
<li>Marc Zonzon provides a package for <span
style="font-weight: bold;">OpenWRT</span> (Open firmware for Linksys®
WRT54G). You can <a
@ -201,7 +202,7 @@ and <span style="font-weight: bold;">Fedora</span> RPMS provided by
Simon Matter: <a href="http://www.invoca.ch/pub/packages/shorewall/">http://www.invoca.ch/pub/packages/shorewall/</a><br>
<br>
<span style="font-weight: bold;">Mandrake</span> RPMS provided by Jack
Coates: <a href="http://www.monkeynoodle.org/tmp">http://www.monkeynoodle.org/tmp</a><br>
Coates: <a href="http://www.monkeynoodle.org/comp/net/shorewall/">http://www.monkeynoodle.org/comp/net/shorewall/</a><br>
<br>
<span style="font-weight: bold;">OpenWRT</span> package provided by
Marc Zonzon: <a

View File

@ -5,8 +5,10 @@ Frameset//EN""http://www.w3.org/TR/html4/frameset.dtd">
<title>Shoreline Firewall</title>
<LINK REL="SHORTCUT ICON" HREF="favicon.ico">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8"></head>
<frameset rows="110,*" cols="*" frameborder="yes"
charset=UTF-8">
<link href="/html.css" rel="stylesheet" type="text/css">
</head>
<frameset rows="114,*" cols="*" frameborder="yes"
border="1"framespacing="0"> <frame
src="Banner.html" name="topFrame"scrolling="NO"
noresize >

View File

@ -9,7 +9,15 @@
<meta name="CHANGED" content="20040920;15183300">
</head>
<body dir="ltr" lang="en-US">
<h1>Shorewall 2.x</h1>
<p style="text-align: right;"><a target="_top"
href="http://www.linuxfestnw.org/"><img
alt="(Linuxfest NW 2005 Banner)" src="images/LFNW2005-720x90.gif"
style="border: 0px solid ; width: 720px; height: 90px;" align="right"></a></p>
<p style="text-align: right;"><a target="_top"
href="http://www.linuxfestnw.org/"><br>
</a></p>
<h1>Shorewall 2.x<br>
</h1>
<p><b>Tom Eastep</b><br>
<br>
The information on this site applies only
@ -28,12 +36,12 @@ to 2.x releases of Shorewall. For older versions:</p>
target="_top">here</a>. </p>
</li>
</ul>
<p>The current 2.2 Stable Release is 2.2.2 -- Here are the <a
href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.2/releasenotes.txt">release
<p>The current 2.2 Stable Release is 2.2.3 -- Here are the <a
href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.3/releasenotes.txt">release
notes</a> and here are the <a
href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.2/known_problems.txt">known
href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.3/known_problems.txt">known
problems</a> and <a
href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.2/errata/">updates</a>.<br>
href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.3/errata/">updates</a>.<br>
</p>
<p><a
href="http://lists.shorewall.net/pipermail/shorewall-announce/2004-December/000451.html"><span
@ -48,8 +56,8 @@ 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 “<a href="GnuCopyright.htm" target="_self">GNU
Free Documentation License</a>”.</p>
<p>2005-03-12</p>
<hr>
<p>2005-04-29</p>
<hr style="width: 100%; height: 2px;">
<h3>Table of Contents</h3>
<p style="margin-left: 0.42in; margin-bottom: 0in;"><a href="#Intro">Introduction
to Shorewall</a></p>
@ -64,18 +72,17 @@ Shorewall on Mandrake® with a two-interface setup?</a><br>
<a href="#License">License</a></p>
<p style="margin-bottom: 0in; margin-left: 40px;"><a href="#2_0_10">News</a></p>
<p style="margin-left: 0.83in; margin-bottom: 0in;"><span
style="text-decoration: underline;"></span><a href="#2_2_2">Shorewall
style="text-decoration: underline;"></span><a href="#LinuxFest">Tom
will speak at LinuxFest NW 2005</a><br>
<a href="#2_2_3">Shorewall
2.2.3</a><br>
<a href="#2_0_17">Shorewall
2.0.17</a><br>
<a href="#2_2_2">Shorewall
2.2.2</a><br>
<a href="#2_2_1">Shorewall
2.2.1</a><a href="#End_of_Support"><br>
</a><a href="#End_of_Support">End of Support for Shorewall 1.4</a><br>
<a href="#2_0_16">Shorewall
2.0.16</a><br>
<a href="#2_2_0">Shorewall
2.2.0</a><br>
<br>
</p>
<div style="margin-left: 40px;"><a href="#Leaf">Leaf</a><br>
<div style="margin-left: 40px;"><br>
<a href="#Leaf">Leaf</a><br>
<br>
<a href="#OpenWRT">OpenWRT</a><br>
</div>
@ -120,7 +127,23 @@ Shorewall is <u>not</u> a
daemon. Once Shorewall has configured Netfilter, it's job is
complete. After that, there is no Shorewall code running although the
<a href="starting_and_stopping_shorewall.htm">/sbin/shorewall program
can be used at any time to monitor the Netfilter firewall</a>.</p>
can be used at any time to monitor the Netfilter firewall</a>.<br>
</p>
<p style="margin-left: 0.42in;">Shorewall is not the easiest to use of
the available iptables configuration tools but I believe that it is the
most flexible and powerful. So if you are looking for a simple
point-and-click set-and-forget Linux firewall solution that requires a
minimum of networking knowledge, I would encourage you to check out the
following alternatives:</p>
<ul style="margin-left: 40px;">
<li><a href="http://www.m0n0.ch/wall">http://www.m0n0.ch/wall</a></li>
<li><a href="http://www.fs-security.com/">http://www.fs-security.com/</a><br>
</li>
</ul>
<p style="margin-left: 0.42in;">On the other hand, if you are looking
for a Linux firewall solution that can handle complex and fast changing
network environments then Shorewall is a logical choice.<br>
</p>
<h3><a name="GettingStarted"></a>Getting Started with Shorewall</h3>
<p style="margin-left: 0.42in;">New to Shorewall? Start by selecting
the <a href="shorewall_quickstart_guide.htm">QuickStart Guide</a>
@ -129,7 +152,7 @@ step instructions.</p>
<h3><a name="Info"></a>Looking for Information?</h3>
<p style="margin-left: 0.42in;">The <a href="Documentation_Index.html">Documentation
Index</a> is a good place to start as is the Site Search in the
frame above. </p>
frame above. network</p>
<h3><a name="Mandrake"></a>Running Shorewall on Mandrake® with a
two-interface setup?</h3>
<p style="margin-left: 0.42in;">If so, the documentation on this site
@ -166,6 +189,96 @@ of the license is included in the section entitled "GNU Free
Documentation License". </p>
<hr>
<h2><a name="News"></a>News</h2>
<span style="font-weight: bold;"><a name="LinuxFest"></a>04/25/2005 Tom
will Speak at LinuxFest NW 2005 -- Bellingham Technical College,
Bellingham Washington<br>
</span><br>
Tom's presentation is entitled "Shorewall and Native IPSEC" and is
available for download <a href="LinuxFest.pdf">here (PDF Format)</a>.
The presentation will be given Saturday April 30 at 10:00 AM in Haskell
Hall, room 111.<br>
<br>
<span style="font-weight: bold;"><a name="2_2_3"></a>04/07/2005
Shorewall 2.2.3<br>
</span><br>
Problems Corrected:<br>
<ol>
<li>If a zone is defined in /etc/shorewall/hosts using
&lt;interface&gt;:!&lt;network&gt; in the HOSTS column then startup
errors occur on "shorewall [re]start".</li>
<li>Previously, if "shorewall status" was run on a system whose
kernel lacked advanced routing support
(CONFIG_IP_ADVANCED_ROUTER),&nbsp; then no routing information was
displayed.</li>
</ol>
New Features:<br>
<ol>
<li>A new extension script "continue" has been added. This script is
invoked after Shorewall has set the built-in filter chains policy to
DROP, deleted any existing Netfilter rules and user chains and has
enabled existing connections. It is useful for enabling certain
communication while Shorewall is being [re]started. Be sure to delete
any rules that you add here in your /etc/shorewall/start file.</li>
<li>There has been ongoing confusion about how the
/etc/shorewall/routestopped file works. People understand how it works
with the 'shorewall stop' command but when they read that 'shorewall
restart' is logically equivalent to 'shorewall stop' followed by
'shorewall start' then they erroneously conclude that
/etc/shorewall/routestopped can be used to enable new connections
during 'shorewall restart'. Up to now, it cannot -- that file is not
processed during either 'shorewall start' or 'shorewall restart'.<br>
<br>
Beginning with Shorewall version 2.2.3, /etc/shorewall/routestopped
will be processed TWICE during 'shorewall start' and during 'shorewall
restart'. It will be processed early in the command execution to add
rules allowing new connections while the command is running and it will
be processed again when the command is complete to remove the rules
added earlier.<br>
<br>
The result of this change will be that during most of [re]start, new
connections will be allowed in accordance with the contents of
/etc/shorewall/routestopped.</li>
<li>The performance of configurations with a large numbers of entries
in /etc/shorewall/maclist can be improved by setting the new
MACLIST_TTL variable in /etc/shorewall/shorewall.conf.<br>
<br>
If your iptables and kernel support the "Recent Match" (see the output
of "shorewall check" near the top), you can cache the results of a
'maclist' file lookup and thus reduce the overhead associated with MAC
Verification.<br>
<br>
When a new connection arrives from a 'maclist' interface, the packet
passes through then list of entries for that interface in
/etc/shorewall/maclist. If there is a match then the source IP address
is added to the 'Recent' set for that interface. Subsequent connection
attempts from that IP address occuring within $MACLIST_TTL seconds will
be accepted without having to scan all of the entries. After
$MACLIST_TTL from the first accepted connection request from an IP
address, the next connection request from that IP address will be
checked against the entire list.<br>
<br>
If MACLIST_TTL is not specified or is specified as empty (e.g,
MACLIST_TTL="" or is specified as zero then 'maclist' lookups will not
be cached.</li>
<li>You can now specify QUEUE as a policy and you can designate a
common action for QUEUE policies in /etc/shorewall/actions. This is
useful for sending packets to something like Snort Inline.<br>
</li>
</ol>
<span style="font-weight: bold;"><a name="2_0_17"></a>03/31/2005
Shorewall 2.0.17<br>
<br>
</span>Problems Corrected:<br>
<ol>
<li>Invoking the 'rejNotSyn' action results in an error at startup.</li>
<li>The UDP and TCP port numbers in
/usr/share/shorewall/action.AllowPCA were reversed.</li>
<li>If a zone is defined in /etc/shorewall/hosts using &lt;<span
style="font-style: italic;">interface</span>&gt;:!&lt;<span
style="font-style: italic;">network</span>&gt; in the HOSTS column
then startup errors occur on "shorewall [re]start".<br>
</li>
</ol>
<span style="font-weight: bold;"><a name="2_2_2"></a>03/12/2005
Shorewall 2.2.2<br>
</span><br>
@ -241,768 +354,7 @@ WARNING: RFC1918_STRICT=Yes requires that your kernel and iptables
support 'Connection Tracking' match.<br>
</li>
</ol>
<span style="font-weight: bold;"><a name="2_2_1"></a>02/15/2005
Shorewall 2.2.1<br>
<br>
</span>This release rolls up the fixes for bugs found in the first 2-3
weeks of deployment of Shorewall 2.2.<br>
<ol>
<li>The /etc/shorewall/policy file contained a misleading comment and
both that file and the /etc/shorewall/zones file lacked examples.</li>
<li>Shorewall previously used root's default umask which could cause
files in /var/lib/shorewall to be world-readable. Shorewall now uses
umask 0177.</li>
<li>In log messages produced by logging a built-in action, the packet
disposition was displayed incorrectly.<br>
<br>
&nbsp;&nbsp; Example:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
rejNotSyn:ULOG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
all&nbsp;&nbsp;&nbsp;&nbsp;
all&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
tcp<br>
<br>
&nbsp;&nbsp; produces the log message:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Feb
12 23:57:08 server Shorewall:rejNotSyn:ULOG: ...<br>
<br>
&nbsp;&nbsp; rather than<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Feb
12 23:57:08 server Shorewall:rejNotSyn:REJECT: ...<br>
<br>
</li>
<li>The comments regarding built-in actions in
/usr/share/shorewall/actions.std have been corrected.</li>
<li>The /etc/shorewall/policy file in the LRP package was missing the
'all-&gt;all' policy.<br>
</li>
</ol>
<a name="End_of_Support"><span style="font-weight: bold;">02/05/2005
End of Support for Shorewall 1.4<br>
<br>
</span>Effective today, support for Shorewall 1.4 has been
discontinued. See the link at the top of this article for&nbsp; upgrade
information.<br>
<br>
</a><span style="font-weight: bold;"><a name="2_0_16"></a>02/01/2005
Shorewall 2.0.16<br>
</span><br>
This release back-ports the DROPINVALID shorewall.conf option from
2.2.0.<br>
<ol>
<li>Recent 2.6 kernels include code that evaluates TCP packets based
on TCP Window analysis. This can cause packets that were previously
classified as NEW or ESTABLISHED to be classified as INVALID.<br>
<br>
The new kernel code can be disabled by including this command in your
/etc/shorewall/init file:<br>
<br>
echo 1 &gt; /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal<br>
<br>
Additional kernel logging about INVALID TCP packets may be obtained by
adding this command to /etc/shorewall/init:<br>
<br>
echo 1 &gt; /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid<br>
<br>
Traditionally, Shorewall has dropped INVALID TCP packets early. The new
DROPINVALID option allows INVALID packets to be passed through the
normal rules chains by setting DROPINVALID=No.<br>
<br>
If not specified or if specified as empty (e.g., DROPINVALID="") then
DROPINVALID=Yes is assumed.<br>
</li>
</ol>
<span style="font-weight: bold;"><a name="2_2_0"></a>02/01/2005
Shorewall 2.2.0<br>
<br>
</span>New Features:<br>
<ol>
<li>ICMP packets that are in the INVALID state are now dropped by the
Reject and Drop default actions. They do so using the new 'dropInvalid'
builtin action. An 'allowInvalid' builtin action is also provided which
accepts packets in that state.</li>
<li>The /etc/shorewall/masq file INTERFACE column now allows
additional options.<br>
<br>
Normally MASQUERADE/SNAT rules are evaluated after one-to-one NAT rules
defined in the /etc/shorewall/nat file. If you preceed the interface
name with a plus sign ("+") then the rule will be evaluated before
one-to-one NAT.<br>
<br>
Examples:<br>
<br>
+eth0<br>
+eth1:192.0.2.32/27<br>
<br>
Also, the effect of ADD_SNAT_ALIASES=Yes can be negated for an entry by
following the interface name by ":" but no digit. <br>
<br>
Examples:<br>
<br>
eth0:<br>
eth1::192.0.2.32/27<br>
+eth3:<br>
<br>
</li>
<li>Similar to 2), the /etc/shorewall/nat file INTERFACE column now
allows you to override the setting of ADD_IP_ALIASES=Yes by following
the interface name with ":" but no digit.</li>
<li>All configuration files in the Shorewall distribution with the
exception of shorewall.conf are now empty. In particular, the
/etc/shorewall/zones, /etc/shorewall/policy and /etc/shorewall/tos
files now have no active entries. Hopefully this will stop the
questions on the support and development lists regarding why the
default entries are the way they are.</li>
<li>Previously, including a log level (and optionally a log tag) on a
rule that specified a user-defined (or Shorewall-defined) action would
log all traffic passed to the action. Beginning with this release,
specifying a log level in a rule that specifies a user- or
Shorewall-defined action will cause each rule in the action to be
logged with the specified level (and tag).<br>
<br>
The extent to which logging of action rules occurs is goverend by the
following:</li>
<ul>
<li>When you invoke an action and specify a log level, only those
rules in the action that have no log level will be changed to log at
the level specified at the action invocation.<br>
<br>
Example:<br>
<br>
/etc/shorewall/action.foo:<br>
<br>
ACCEPT&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;
tcp&nbsp;&nbsp;&nbsp; 22<br>
bar:info<br>
<br>
/etc/shorewall/rules:<br>
<br>
foo:debug&nbsp;&nbsp;&nbsp; fw&nbsp;&nbsp;&nbsp; net<br>
<br>
Logging in the invoked 'foo' action will be:<br>
<br>
ACCEPT:debug&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;
tcp&nbsp;&nbsp;&nbsp; 22<br>
bar:info<br>
<br>
</li>
<li>If you follow the log level with "!" then logging will be at
that level for all rules recursively invoked by the action<br>
<br>
Example: /etc/shorewall/action.foo:<br>
<br>
<b>Update: </b>I've been
informed by Mandrake Development that this problem has been corrected
in Mandrake 10.0 Final (the problem still exists in the 10.0
Community release).<br>
ACCEPT&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;
tcp&nbsp;&nbsp;&nbsp; 22<br>
bar:info<br>
<br>
/etc/shorewall/rules:<br>
<br>
foo:debug!&nbsp;&nbsp;&nbsp; fw&nbsp;&nbsp;&nbsp; net<br>
<br>
Logging in the invoke 'foo' action will be:<br>
<br>
ACCEPT:debug&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;
tcp&nbsp;&nbsp;&nbsp; 22<br>
bar:debug!<br>
<br>
</li>
</ul>
</ol>
<div style="margin-left: 40px;">This change has an effect on extension
scripts used with user-defined actions. If you define an action 'acton'
and you have an /etc/shorewall/acton script then when that script is
invoked, the following three variables will be set for use by the
script:<br>
<br>
<div style="margin-left: 40px;">$CHAIN = the name of the chain where
your rules are to be placed. When logging is used on an action
invocation, Shorewall creates a chain with a slightly different name
from the action itself.<br>
$LEVEL = Log level. If empty, no logging was specified.<br>
$TAG&nbsp;&nbsp; = Log Tag.<br>
<br>
</div>
Example:<br>
<br>
/etc/shorewall/rules:<br>
&nbsp;&nbsp;&nbsp; <br>
acton:info:test<br>
<br>
Your /etc/shorewall/acton file will be run with:<br>
<br>
<div style="margin-left: 40px;">$CHAIN="%acton1<br>
$LEVEL="info"<br>
$TAG="test"<br>
</div>
</div>
<br>
<ol start="6">
<li>The /etc/shorewall/startup_disabled file is no longer created
when
Shorewall is first installed. Rather, the variable STARTUP_ENABLED is
set to 'No' in /etc/shorewall/shorewall.conf. In order to get Shorewall
to start, that variable's value must be set to 'Yes'. This change
accomplishes two things:</li>
<ul>
<li>It prevents Shorewall from being started prematurely by the
user's initialization scripts.</li>
<li>It causes /etc/shorewall/shorewall.conf to be modified so that
it won't be replaced by upgrades using RPM.<br>
<br>
</li>
</ul>
<li>Support has been added for the 2.6 Kernel IPSEC implementation.
To use this support, you must have installed the IPSEC policy match
patch and the four IPSEC/Netfilter patches from Patch-0-Matic-ng. The
policy match patch affects both your kernel and iptables. There are two
ways to specify that IPSEC is to be used when communicating with a set
of hosts; both methods involve the new /etc/shorewall/ipsec file:</li>
<ol style="list-style-type: lower-alpha;">
<li>If encrypted communication is used with all hosts in a zone,
then you can designate the zone as an "ipsec" zone by placing 'Yes" in
the IPSEC ONLY column in /etc/shorewall/ipsec:<br>
<br>
<span style="font-family: monospace;">#ZONE&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp; IPSEC&nbsp;&nbsp;&nbsp; OPTIONS ...</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">#&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; ONLY</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Yes</span><span
style="font-family: sans-serif;"></span><br>
<br>
The hosts in the zone (if any) must be specified in
/etc/shorewall/hosts but you do not need to specify the 'ipsec' option
on the entries in that file (see below). Dynamic zones involving IPSEC
must use that technique.<br>
<br>
Example:Under 2.4 Kernel FreeS/Wan:<br>
<br>
/etc/shorewall/zones:<br>
<br>
<span style="font-family: monospace;">net&nbsp;&nbsp;&nbsp;
Net&nbsp;&nbsp;&nbsp; The big bad Internet</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
VPN&nbsp;&nbsp;&nbsp; Remote Network</span><br>
<br>
/etc/shorewall/interfaces:<br>
<br>
<span style="font-family: monospace;">net&nbsp;&nbsp;&nbsp;
eth0&nbsp;&nbsp;&nbsp; ...</span><br style="font-family: monospace;">
<span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
ipsec0&nbsp;&nbsp;&nbsp; ...</span><br>
<br>
Under 2.6 Kernel with this new support:<br>
<br>
/etc/shorewall/zones:<br>
<br>
<span style="font-family: monospace;">net&nbsp;&nbsp;&nbsp;
Net&nbsp;&nbsp;&nbsp; The big bad Internet</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
VPN&nbsp;&nbsp;&nbsp; Remote Network</span><br>
<br>
/etc/shorewall/interfaces:<br>
<br>
<span style="font-family: monospace;">net&nbsp;&nbsp;&nbsp;
eth0&nbsp;&nbsp;&nbsp; ...</span><br>
<br>
/etc/shorewall/hosts:<br>
<br>
<span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
eth0:0.0.0.0/0</span><br>
<br>
/etc/shorewall/ipsec<br>
<br>
<span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp; Yes<br>
<br>
</span> </li>
<li>If only part of the hosts in a zone require encrypted
communication, you may use of the new 'ipsec' option in
/etc/shorewall/hosts to designate those hosts.<br>
<br>
Example:<br>
<br>
Under 2.4 Kernel FreeS/Wan:<br>
<br>
/etc/shorewall/zones:<br>
<pre>net&nbsp;&nbsp;&nbsp; Net&nbsp;&nbsp;&nbsp; The big bad Internet<br>loc&nbsp;&nbsp;&nbsp; Local&nbsp; Extended local zone</pre>
/etc/shorewall/interfaces:<br>
<br>
<span style="font-family: monospace;">net&nbsp;&nbsp;&nbsp;
eth0&nbsp;&nbsp;&nbsp; ...</span><br style="font-family: monospace;">
<span style="font-family: monospace;">loc&nbsp;&nbsp;&nbsp;
eth1&nbsp;&nbsp;&nbsp; ...</span><br style="font-family: monospace;">
<span style="font-family: monospace;">loc&nbsp;&nbsp;&nbsp;
ipsec0&nbsp;&nbsp;&nbsp; ...</span><br>
<br>
Under 2.6 Kernel with this new support:<br>
<br>
/etc/shorewall/zones:<br>
<br>
<span style="font-family: monospace;">net&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp; Net&nbsp;&nbsp;&nbsp; The big bad Internet</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp; VPN&nbsp;&nbsp;&nbsp; Remote Network</span><br>
<br>
/etc/shorewall/interfaces:<br>
<br>
<span style="font-family: monospace;">net&nbsp;&nbsp;&nbsp;
eth0&nbsp;&nbsp;&nbsp; ...</span><br style="font-family: monospace;">
<span style="font-family: monospace;">loc&nbsp;&nbsp;&nbsp;
eth1&nbsp;&nbsp;&nbsp; ...</span><br>
<br>
/etc/shorewall/hosts:<br>
<br>
<span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
eth0:0.0.0.0/0&nbsp;&nbsp;&nbsp; ipsec,...</span></li>
</ol>
</ol>
<div style="margin-left: 40px;">Regardless of which technique you
choose, you can specify additional SA options for the zone in the
/etc/shorewall/ipsec entry.<br>
<br>
The OPTIONS, IN OPTIONS and OUT OPTIONS columns specify the
input-output, input and output characteristics of the security
associations to be used to decrypt (input) or encrypt (output) traffic
to/from the zone.<br>
<br>
The available options are:<br>
</div>
<ul>
<ul>
<li>reqid[!]=&lt;number&gt; where &lt;number&gt; is specified using
setkey(8) using the 'unique:&lt;number&gt;' option for the SPD level.</li>
<li>spi[!]=&lt;number&gt; where &lt;number&gt; is the SPI of the
SA. Since different SAs are used to encrypt and decrypt traffic, this
option should only be listed in the IN OPTIONS and OUT OPTIONS columns.</li>
<li>proto[!]=ah|esp|ipcomp</li>
<li>mss=&lt;number&gt; (sets the MSS value in TCP SYN packets and
is not related to policy matching)</li>
<li>mode[!]=transport|tunnel</li>
<li>tunnel-src[!]=&lt;address&gt;[/&lt;mask&gt;] (only available
with mode=tunnel)</li>
<li>tunnel-dst[!]=&lt;address&gt;[/&lt;mask&gt;] (only available
with mode=tunnel). Because tunnel source and destination are dependent
on the direction of the traffic, these options should only appear in
the IN OPTIONS and OUT OPTIONS columns.</li>
<li>strict&nbsp; (if specified, packets must match all policies;
policies are delimited by 'next').</li>
<li>next&nbsp;&nbsp;&nbsp; (only available with strict)</li>
</ul>
</ul>
<div style="margin-left: 40px;">Examples:<br>
<br>
<span style="font-family: monospace;">#ZONE&nbsp;&nbsp;&nbsp;
IPSEC&nbsp; OPTIONS&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
IN&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OUT</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ONLY&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;
OPTIONS&nbsp;&nbsp;&nbsp;&nbsp; OPTIONS</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Yes&nbsp;&nbsp;&nbsp; mode=tunnel,proto=esp&nbsp;&nbsp;&nbsp;
spi=1000&nbsp;&nbsp;&nbsp; spi=1001</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">loc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
No&nbsp;&nbsp;&nbsp;&nbsp; reqid=44,mode=transport</span><br>
<br>
The /etc/shorewall/masq file has a new IPSEC column added. If you
specify Yes or yes in that column then the unencrypted packets will
have their source address changed. Otherwise, the unencrypted packets
will not have their source addresses changed. This column may also
contain a comma-separated list of the options specified above in which
case only those packets that will be encrypted by an SA matching the
given options will have their source address changed.<br>
</div>
<ol start="8">
<li>To improve interoperability, tunnels of type 'ipsec' no longer
enforce the use of source port 500 for ISAKMP and OpenVPN tunnels no
longer enforce use of the specified port as both the source and
destination ports.</li>
<li>A new 'allowBcast' builtin action has been added -- it silently
allows broadcasts and multicasts.</li>
<li>The -c option in /sbin/shorewall commands is now deprecated. The
commands where -c was previously allowed now permit you to specify a
configuration directory after the command:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall check&nbsp;&nbsp; [
&lt;configuration-directory&gt; ]<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall restart [
&lt;configuration-directory&gt; ]<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall start&nbsp;&nbsp; [
&lt;configuration-directory&gt; ]<br>
<br>
</li>
<li>Normally, when SNAT or MASQUERADE is applied to a tcp or udp
connection, Netfilter attempts to retain the source port number. If it
has to change to port number to avoid&nbsp; &lt;source
address&gt;,&lt;source port&gt; conflicts, it tries to do so within
port ranges ( &lt; 512, 512-1023, and &gt; 1023). You may now specify
an explicit range of source ports to be used by following the address
or address range (if any) in the ADDRESS column with ":" and a port
range in the format &lt;low-port&gt;-&lt;high-port&gt;. You must
specify either "tcp" or "udp" in the PROTO column.<br>
<br>
Examples 1 -- MASQUERADE with tcp source ports 4000-5000:<br>
<br>
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp; #INTERFACE
SUBNET&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;
ADDRESS&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; PROTO</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
eth0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.0/24&nbsp;
:4000-5000&nbsp;&nbsp;&nbsp;&nbsp; tcp</span><br
style="font-family: monospace;">
<br>
Example 2 -- SNAT with udp source ports 7000-8000:<br>
<br>
&nbsp;&nbsp;&nbsp; <span style="font-family: monospace;">#INTERFACE
SUBNET&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;
ADDRESS&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
PROTO</span><br style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;
eth0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
10.0.0.0/8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
192.0.2.44:7000-8000&nbsp;&nbsp;&nbsp; udp<br>
<br>
</span></li>
<li>You may now account by user/group ID for outbound traffic from
the firewall itself with entries in /etc/shorewall/accounting. Such
accounting rules must be placed in the OUTPUT chain. See the comments
at the top of /etc/shorewall/accounting for details.</li>
<li>Shorewall now verifies that your kernel and iptables have physdev
match support if BRIDGING=Yes in shorewall.conf.</li>
<li>Beginning with this release, if your kernel and iptables have
iprange match support (see the output from "shorewall check"), then
with the exception of the /etc/shorewall/netmap file, anywhere that a
network address may appear an IP address range of the form &lt;low
address&gt;-&lt;high address&gt; may also appear.</li>
<li>Support has been added for the iptables CLASSIFY target. That
target allows you to classify packets for traffic shaping directly
rather than indirectly through fwmark. Simply enter the
&lt;major&gt;:&lt;minor&gt; classification in the first column of
/etc/shorewall/tcrules:<br>
<br>
Example:<br>
<br>
<span style="font-family: monospace;">#MARK/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SOURCE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
DEST&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PROTO&nbsp;&nbsp;&nbsp;&nbsp; PORT(S)</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">#CLASSIFY</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">1:30&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp; eth0&nbsp;&nbsp;&nbsp; &nbsp; tcp&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; 25</span><br>
<br>
Note that when using this form of rule, it is acceptable to include the
name of an interface in the DEST column.<br>
<br>
Marking using the CLASSIFY target always occurs in the POSTROUTING
chain of the mangle table and is not affected by the setting of
MARK_IN_FORWARD_CHAIN in shorewall.conf.</li>
<li>During "shorewall start", IP addresses to be added as a
consequence of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes are quietly
deleted when /etc/shorewall/nat and /etc/shorewall/masq are processed
then they are re-added later. This is done to help ensure that the
addresses can be added with the specified labels but can have the
undesirable side effect of causing routes to be quietly deleted. A new
RETAIN_ALIASES option has been added to shorewall.conf; when this
option is set to Yes, existing addresses will not be deleted.
Regardless of the setting of RETAIN_ALIASES, addresses added during
"shorewall start" are still deleted at a subsequent "shorewall stop" or
"shorewall restart".</li>
<li>Users with a large black list (from /etc/shorewall/blacklist) may
want to set the new DELAYBLACKLISTLOAD option in shorewall.conf. When
DELAYBLACKLISTLOAD=Yes, Shorewall will enable new connections before
loading the blacklist rules. While this may allow connections from
blacklisted hosts to slip by during construction of the blacklist, it
can substantially reduce the time that all new connections are disabled
during "shorewall [re]start".</li>
<li>Using the default LOGFORMAT, chain names longer than 11
characters (such as in user-defined actions) may result in log prefix
truncation. A new shorewall.conf action&nbsp; LOGTAGONLY has been added
to deal with this problem. When LOGTAGONLY=Yes, logging rules that
specify a log tag will substitute the tag for the chain name in the log
prefix.<br>
<br>
Example -- file /etc/shorewall/action.thisisaverylogactionname:<br>
<br>
&nbsp;&nbsp;&nbsp; Rule:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span
style="font-family: monospace;">DROP:info:ftp&nbsp;&nbsp;&nbsp;
0.0.0.0/0&nbsp;&nbsp;&nbsp; 0.0.0.0/0&nbsp;&nbsp;&nbsp;
tcp&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 21</span><br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; Log prefix with LOGTAGONLY=No:<br>
<br>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; <span style="font-family: monospace;">Shorewall:thisisaverylongacti</span><br>
<br>
&nbsp;&nbsp;&nbsp; Log prefix with LOGTAGONLY=Yes:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span
style="font-family: monospace;">Shorewall:ftp:DROP</span><br>
<br>
</li>
<li>Shorewall now resets the 'accept_source_route' flag for all
interfaces. If you wish to accept source routing on an interface, you
must specify the new 'sourceroute' interface option in
/etc/shorewall/interfaces.</li>
<li>The default Drop and Reject actions now invoke the new standard
action 'AllowICMPs'. This new action accepts critical ICMP types:<br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; Type 3 code 4 (fragmentation needed)<br>
&nbsp;&nbsp;&nbsp; Type 11&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (TTL
exceeded)<br>
<br>
</li>
<li>Explicit control over the kernel's Martian logging is now
provided using the new 'logmartians' interface option. If you include
'logmartians' in the interface option list then logging of Martian
packets on will be enabled on the specified interface. If you wish to
globally enable martian logging, you can set LOG_MARTIANS=Yes in
shorewall.conf.</li>
<li>You may now cause Shorewall to use the '--set-mss' option of the
TCPMSS target. In other words, you can cause Shorewall to set the MSS
field of SYN packets passing through the firewall to the value you
specify. This feature extends the existing CLAMPMSS option in
/etc/shorewall/shorewall.conf by allowing that option to have a numeric
value as well as the values "Yes" and "No".<br>
<br>
Example:<br>
<br>
&nbsp;&nbsp;&nbsp; CLAMPMSS=1400<br>
<br>
</li>
<li>Shorewall now includes support for the ipp2p match facility. This
is a departure from my usual policy in that the ipp2p match facility is
included in Patch-O-Matic-NG and is unlikely to ever be included in the
kernel.org source tree. Questions about how to install the patch or how
to build your kernel and/or iptables should not be posted on the
Shorewall mailing lists.<br>
<br>
In the following files, the "PROTO" or "PROTOCOL" column may contain
"ipp2p":<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /etc/shorewall/rules<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /etc/shorewall/tcrules<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /etc/shorewall/accounting<br>
<br>
When the PROTO or PROTOCOL column contains "ipp2p" then the DEST
PORT(S) or PORT(S) column may contain a recognized ipp2p option; for a
list of the options and their meaning, at a root prompt:<br>
<br>
&nbsp;&nbsp;&nbsp; iptables -m ipp2p --help<br>
<br>
You must not include the leading "--" on the option; Shorewall will
supply those characters for you. If you do not include an option then
"ipp2p" is assumed (Shorewall will generate "-m ipp2p --ipp2p").</li>
<li>Shorewall now has support for the CONNMARK target from iptables.
See the /etc/shorewall/tcrules file for details.</li>
<li>A new debugging option LOGALLNEW has been added to
shorewall.conf. When set to a log level, this option causes Shorewall
to generaate a logging rule as the first rule in each builtin chain.<br>
<br>
&nbsp;&nbsp;&nbsp; - The table name is used as the chain name in the
log prefix.<br>
&nbsp;&nbsp;&nbsp; - The chain name is used as the target in the log
prefix.<br>
<br>
Example: Using the default LOGFORMAT, the log prefix for logging from
the nat table's PREROUTING chain is:<br>
<br>
&nbsp;&nbsp;&nbsp; &nbsp;<span style="font-family: monospace;">Shorewall:nat:PREROUTING</span><br>
<br>
IMPORTANT: There is no rate limiting on these logging rules so use
LOGALLNEW at your own risk; it may cause high CPU and disk utilization
and you may not be able to control your firewall after you enable this
option.<br>
<br>
DANGER: DO NOT USE THIS OPTION IF THE RESULTING LOG MESSAGES WILL BE
SENT TO ANOTHER SYSTEM.<br>
<br>
</li>
<li>The SUBNET column in /etc/shorewall/rfc1918 has been renamed
SUBNETS and it is now possible to specify a list of addresses in that
column.</li>
<li>The AllowNNTP action now also allows NNTP over SSL/TLS (NNTPS).</li>
<li>For consistency, the CLIENT PORT(S) column in the tcrules file
has been renamed SOURCE PORT(S).</li>
<li>The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is now
shown in the output of "shorewall status".</li>
<li>A new IPTABLES option has been added to shorewall.conf. IPTABLES
can be used to designate the iptables executable to be used by
Shorewall. If not specified, the iptables executable determined by the
PATH setting is used.</li>
<li>You can now use the "shorewall show zones" command to display the
current contents of the zones. This is particularly useful if you use
dynamic zones (DYNAMIC_ZONES=Yes in shorewall.conf).<br>
<br>
&nbsp;&nbsp;&nbsp; Example:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span style="font-family: monospace;">ursa:/etc/shorewall
# shorewall show zones</span><br style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
Shorewall-2.2.0-Beta7 Zones at ursa - Sat Nov 27 11:18:25 PST 2004</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp; loc</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; eth0:192.168.1.0/24</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; eth1:1.2.3.4</span><br style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
net&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; </span><br
style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; eth0:0.0.0.0/0</span><br style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp; WiFi</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; eth1:0.0.0.0/0</span><br style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp; sec</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; eth1:0.0.0.0/0</span><br style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
ursa:/etc/shorewall #</span><br>
<br>
</li>
<li>Variable expansion may now be used with the INCLUDE directive.<br>
<br>
&nbsp;&nbsp;&nbsp; Example:<br>
<br>
&nbsp;&nbsp;&nbsp; /etc/shorewall/params<br>
<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <span
style="font-family: monospace;">FILE=/etc/foo/bar</span><br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Any other config file:<br>
<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <span
style="font-family: monospace;">INCLUDE $FILE</span><br>
<br>
</li>
<li>The output of "shorewall status" now includes the results of "ip
-stat link ls". This helps diagnose performance problems caused by link
errors.</li>
<li>Previously, when rate-limiting was specified in
/etc/shorewall/policy (LIMIT:BURST column), any traffic which exceeded
the specified rate was silently dropped. Now, if a log level is given
in the entry (LEVEL column) then drops are logged at that level at a
rate of 5/min with a burst of 5.</li>
<li>Recent 2.6 kernels include code that evaluates TCP packets based
on TCP Window analysis. This can cause packets that were previously
classified as NEW or ESTABLISHED to be classified as INVALID.<br>
<br>
The new kernel code can be disabled by including this command in your
/etc/shorewall/init file:<br>
<br>
&nbsp;&nbsp;&nbsp; <span style="font-family: monospace;">echo 1 &gt;
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal</span><br>
<br>
Additional kernel logging about INVALID TCP packets may be obtained by
adding this command to /etc/shorewall/init:<br>
<br>
&nbsp;&nbsp;&nbsp; <span style="font-family: monospace;">echo 1 &gt;
/proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid</span><br>
<br>
Traditionally, Shorewall has dropped INVALID TCP packets early. The new
DROPINVALID option allows INVALID packets to be passed through the
normal rules chains by setting DROPINVALID=No.<br>
<br>
If not specified or if specified as empty (e.g., DROPINVALID="") then
DROPINVALID=Yes is assumed.<br>
<br>
</li>
<li>The "shorewall add" and "shorewall delete" commands now accept a
list of hosts to add or delete.<br>
<br>
Examples:<br>
<br>
&nbsp;&nbsp;&nbsp;<span style="font-family: monospace;"> shorewall add
eth1:1.2.3.4 eth1:2.3.4.5 z12</span><br style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp; shorewall delete
eth1:1.2.3.4 eth1:2.3.4.5 z12</span><br>
<br>
&nbsp;&nbsp;&nbsp; The above commands may also be written:<br>
<br>
&nbsp;&nbsp;&nbsp; <span style="font-family: monospace;">shorewall add
eth1:1.2.3.4,2.3.4.5 z12</span><br style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp; shorewall delete
eth1:1.2.3.4,2.3.4.5 z12</span><br>
&nbsp;&nbsp; <br>
</li>
<li>TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel
type. OpenVPN entries in /etc/shorewall/tunnels have this format:<br>
<br>
&nbsp;&nbsp;&nbsp; <span style="font-family: monospace;">openvpn[:{tcp|udp}][:&lt;port&gt;]&nbsp;&nbsp;&nbsp;
&lt;zone&gt;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &lt;gateway&gt;</span><br>
<br>
Examples:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span style="font-family: monospace;">openvpn:tcp&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
1.2.3.4&nbsp;&nbsp;&nbsp; # TCP tunnel on port 1194</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
openvpn:3344&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
1.2.3.4&nbsp;&nbsp;&nbsp; # UDP on port 3344</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
openvpn:tcp:4455&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
1.2.3.4&nbsp;&nbsp;&nbsp; # TCP on port 4455</span><br>
<br>
</li>
<li>A new 'ipsecvpn' script is included in the tarball and in the
RPM. The RPM installs the file in the Documentation directory
(/usr/share/doc/packages/shorewall-2.2.0-0RC1).<br>
<br>
This script is intended for use on Roadwarrior laptops for establishing
an IPSEC SA to/from remote networks. The script has some limitations:</li>
</ol>
<ul>
<ul>
<li>Only one instance of the script may be used at a time.</li>
<li>Only the first SPD accessed will be instantiated at the remote
gateway. So while the script creates SPDs to/from the remote gateway
and each network listed in the NETWORKS setting at the front of the
script, only one of these may be used at a time.</li>
</ul>
</ul>
<ol start="39">
<li>The output of "shorewall status" now lists the loaded netfilter
kernel modules.</li>
<li>The range of UDP ports opened by the AllowTrcrt action has been
increased to 33434:33524.</li>
<li>The IANA has recently registered port 1194 for use by OpenVPN. In
previous versions of Shorewall (and OpenVPN), the default port was 5000
but has been changed to 1194 to conform to the new OpenVPN default.<br>
</li>
</ol>
<span style="font-weight: bold;"></span><span style="font-weight: bold;"></span>
<p><a href="News.htm">More News</a></p>
<hr>
<h2><a name="Leaf"></a>Leaf</h2>

View File

@ -33,7 +33,7 @@ Documentation License</a></span>”.</p>
</div>
</div>
<div>
<p class="pubdate">2005-03-18</p>
<p class="pubdate">2005-03-22</p>
</div>
</div>
<hr></div>
@ -60,7 +60,7 @@ Traffic Control Howto: <a href="http://ds9a.nl/lartc" target="_top">http://ds9a.
</tr>
<tr valign="middle">
<td align="left" valign="middle">Iproute Downloads: <a
href="ftp://ftp.inr.ac.ru/ip-routing" target="_top">ftp://ftp.inr.ac.ru/ip-routing</a></td>
href="http://developer.osdl.org/dev/iproute2/download/" target="_top">http://developer.osdl.org/dev/iproute2/download/</a></td>
</tr>
<tr valign="middle">
<td align="left" valign="middle">LEAF Site: <a