forked from extern/shorewall_code
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
parent
0a50339757
commit
0bfeb860a9
@ -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
|
class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free
|
||||||
Documentation License</a></span>”.<br>
|
Documentation License</a></span>”.<br>
|
||||||
</p>
|
</p>
|
||||||
<p>2005-02-01<br>
|
<p>2005-04-14<br>
|
||||||
</p>
|
</p>
|
||||||
<hr style="width: 100%; height: 2px;">
|
<hr style="width: 100%; height: 2px;">
|
||||||
<p><span style="font-weight: bold;"><br>
|
<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>
|
||||||
|
Example:<br>
|
||||||
|
<br>
|
||||||
|
|
||||||
|
rejNotSyn:ULOG
|
||||||
|
all
|
||||||
|
all
|
||||||
|
tcp<br>
|
||||||
|
<br>
|
||||||
|
produces the log message:<br>
|
||||||
|
<br>
|
||||||
|
Feb
|
||||||
|
12 23:57:08 server Shorewall:rejNotSyn:ULOG: ...<br>
|
||||||
|
<br>
|
||||||
|
rather than<br>
|
||||||
|
<br>
|
||||||
|
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->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 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 > /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 > /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 - -
|
||||||
|
tcp 22<br>
|
||||||
|
bar:info<br>
|
||||||
|
<br>
|
||||||
|
/etc/shorewall/rules:<br>
|
||||||
|
<br>
|
||||||
|
foo:debug fw net<br>
|
||||||
|
<br>
|
||||||
|
Logging in the invoked 'foo' action will be:<br>
|
||||||
|
<br>
|
||||||
|
ACCEPT:debug - -
|
||||||
|
tcp 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 - -
|
||||||
|
tcp 22<br>
|
||||||
|
bar:info<br>
|
||||||
|
<br>
|
||||||
|
/etc/shorewall/rules:<br>
|
||||||
|
<br>
|
||||||
|
foo:debug! fw net<br>
|
||||||
|
<br>
|
||||||
|
Logging in the invoke 'foo' action will be:<br>
|
||||||
|
<br>
|
||||||
|
ACCEPT:debug - -
|
||||||
|
tcp 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 = Log Tag.<br>
|
||||||
|
<br>
|
||||||
|
</div>
|
||||||
|
Example:<br>
|
||||||
|
<br>
|
||||||
|
/etc/shorewall/rules:<br>
|
||||||
|
<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
|
||||||
|
IPSEC OPTIONS ...</span><br
|
||||||
|
style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">#
|
||||||
|
ONLY</span><br
|
||||||
|
style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">vpn
|
||||||
|
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
|
||||||
|
Net The big bad Internet</span><br
|
||||||
|
style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">vpn
|
||||||
|
VPN Remote Network</span><br>
|
||||||
|
<br>
|
||||||
|
/etc/shorewall/interfaces:<br>
|
||||||
|
<br>
|
||||||
|
<span style="font-family: monospace;">net
|
||||||
|
eth0 ...</span><br style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">vpn
|
||||||
|
ipsec0 ...</span><br>
|
||||||
|
<br>
|
||||||
|
Under 2.6 Kernel with this new support:<br>
|
||||||
|
<br>
|
||||||
|
/etc/shorewall/zones:<br>
|
||||||
|
<br>
|
||||||
|
<span style="font-family: monospace;">net
|
||||||
|
Net The big bad Internet</span><br
|
||||||
|
style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">vpn
|
||||||
|
VPN Remote Network</span><br>
|
||||||
|
<br>
|
||||||
|
/etc/shorewall/interfaces:<br>
|
||||||
|
<br>
|
||||||
|
<span style="font-family: monospace;">net
|
||||||
|
eth0 ...</span><br>
|
||||||
|
<br>
|
||||||
|
/etc/shorewall/hosts:<br>
|
||||||
|
<br>
|
||||||
|
<span style="font-family: monospace;">vpn
|
||||||
|
eth0:0.0.0.0/0</span><br>
|
||||||
|
<br>
|
||||||
|
/etc/shorewall/ipsec<br>
|
||||||
|
<br>
|
||||||
|
<span style="font-family: monospace;">vpn 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 Net The big bad Internet<br>loc Local Extended local zone</pre>
|
||||||
|
/etc/shorewall/interfaces:<br>
|
||||||
|
<br>
|
||||||
|
<span style="font-family: monospace;">net
|
||||||
|
eth0 ...</span><br style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">loc
|
||||||
|
eth1 ...</span><br style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">loc
|
||||||
|
ipsec0 ...</span><br>
|
||||||
|
<br>
|
||||||
|
Under 2.6 Kernel with this new support:<br>
|
||||||
|
<br>
|
||||||
|
/etc/shorewall/zones:<br>
|
||||||
|
<br>
|
||||||
|
<span style="font-family: monospace;">net
|
||||||
|
Net The big bad Internet</span><br
|
||||||
|
style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">vpn
|
||||||
|
VPN Remote Network</span><br>
|
||||||
|
<br>
|
||||||
|
/etc/shorewall/interfaces:<br>
|
||||||
|
<br>
|
||||||
|
<span style="font-family: monospace;">net
|
||||||
|
eth0 ...</span><br style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">loc
|
||||||
|
eth1 ...</span><br>
|
||||||
|
<br>
|
||||||
|
/etc/shorewall/hosts:<br>
|
||||||
|
<br>
|
||||||
|
<span style="font-family: monospace;">vpn
|
||||||
|
eth0:0.0.0.0/0 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[!]=<number> where <number> is specified using
|
||||||
|
setkey(8) using the 'unique:<number>' option for the SPD level.</li>
|
||||||
|
<li>spi[!]=<number> where <number> 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=<number> (sets the MSS value in TCP SYN packets and
|
||||||
|
is not related to policy matching)</li>
|
||||||
|
<li>mode[!]=transport|tunnel</li>
|
||||||
|
<li>tunnel-src[!]=<address>[/<mask>] (only available
|
||||||
|
with mode=tunnel)</li>
|
||||||
|
<li>tunnel-dst[!]=<address>[/<mask>] (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 (if specified, packets must match all policies;
|
||||||
|
policies are delimited by 'next').</li>
|
||||||
|
<li>next (only available with strict)</li>
|
||||||
|
</ul>
|
||||||
|
</ul>
|
||||||
|
<div style="margin-left: 40px;">Examples:<br>
|
||||||
|
<br>
|
||||||
|
<span style="font-family: monospace;">#ZONE
|
||||||
|
IPSEC OPTIONS
|
||||||
|
|
||||||
|
IN
|
||||||
|
OUT</span><br
|
||||||
|
style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">#
|
||||||
|
ONLY
|
||||||
|
|
||||||
|
OPTIONS OPTIONS</span><br
|
||||||
|
style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">vpn
|
||||||
|
Yes mode=tunnel,proto=esp
|
||||||
|
spi=1000 spi=1001</span><br
|
||||||
|
style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">loc
|
||||||
|
No 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>
|
||||||
|
shorewall check [
|
||||||
|
<configuration-directory> ]<br>
|
||||||
|
shorewall restart [
|
||||||
|
<configuration-directory> ]<br>
|
||||||
|
shorewall start [
|
||||||
|
<configuration-directory> ]<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 <source
|
||||||
|
address>,<source port> conflicts, it tries to do so within
|
||||||
|
port ranges ( < 512, 512-1023, and > 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 <low-port>-<high-port>. 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;"> #INTERFACE
|
||||||
|
SUBNET
|
||||||
|
ADDRESS PROTO</span><br
|
||||||
|
style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">
|
||||||
|
eth0 192.168.1.0/24
|
||||||
|
:4000-5000 tcp</span><br
|
||||||
|
style="font-family: monospace;">
|
||||||
|
<br>
|
||||||
|
Example 2 -- SNAT with udp source ports 7000-8000:<br>
|
||||||
|
<br>
|
||||||
|
<span style="font-family: monospace;">#INTERFACE
|
||||||
|
SUBNET
|
||||||
|
ADDRESS
|
||||||
|
|
||||||
|
PROTO</span><br style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">
|
||||||
|
eth0
|
||||||
|
10.0.0.0/8
|
||||||
|
192.0.2.44:7000-8000 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 <low
|
||||||
|
address>-<high address> 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
|
||||||
|
<major>:<minor> classification in the first column of
|
||||||
|
/etc/shorewall/tcrules:<br>
|
||||||
|
<br>
|
||||||
|
Example:<br>
|
||||||
|
<br>
|
||||||
|
<span style="font-family: monospace;">#MARK/
|
||||||
|
SOURCE
|
||||||
|
DEST PROTO 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
|
||||||
|
-
|
||||||
|
eth0 tcp
|
||||||
|
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 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>
|
||||||
|
Rule:<br>
|
||||||
|
<br>
|
||||||
|
<span
|
||||||
|
style="font-family: monospace;">DROP:info:ftp
|
||||||
|
0.0.0.0/0 0.0.0.0/0
|
||||||
|
tcp 21</span><br>
|
||||||
|
<br>
|
||||||
|
Log prefix with LOGTAGONLY=No:<br>
|
||||||
|
<br>
|
||||||
|
<span style="font-family: monospace;">Shorewall:thisisaverylongacti</span><br>
|
||||||
|
<br>
|
||||||
|
Log prefix with LOGTAGONLY=Yes:<br>
|
||||||
|
<br>
|
||||||
|
<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>
|
||||||
|
<br>
|
||||||
|
Type 3 code 4 (fragmentation needed)<br>
|
||||||
|
Type 11 (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>
|
||||||
|
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>
|
||||||
|
/etc/shorewall/rules<br>
|
||||||
|
/etc/shorewall/tcrules<br>
|
||||||
|
/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>
|
||||||
|
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>
|
||||||
|
- The table name is used as the chain name in the
|
||||||
|
log prefix.<br>
|
||||||
|
- 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>
|
||||||
|
<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>
|
||||||
|
Example:<br>
|
||||||
|
<br>
|
||||||
|
<span style="font-family: monospace;">ursa:/etc/shorewall
|
||||||
|
# shorewall show zones</span><br style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">
|
||||||
|
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;"> </span><br
|
||||||
|
style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;"> loc</span><br
|
||||||
|
style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">
|
||||||
|
eth0:192.168.1.0/24</span><br
|
||||||
|
style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">
|
||||||
|
eth1:1.2.3.4</span><br style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">
|
||||||
|
net </span><br
|
||||||
|
style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">
|
||||||
|
eth0:0.0.0.0/0</span><br style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;"> WiFi</span><br
|
||||||
|
style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">
|
||||||
|
eth1:0.0.0.0/0</span><br style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;"> sec</span><br
|
||||||
|
style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">
|
||||||
|
eth1:0.0.0.0/0</span><br style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;"> </span><br
|
||||||
|
style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">
|
||||||
|
ursa:/etc/shorewall #</span><br>
|
||||||
|
<br>
|
||||||
|
</li>
|
||||||
|
<li>Variable expansion may now be used with the INCLUDE directive.<br>
|
||||||
|
<br>
|
||||||
|
Example:<br>
|
||||||
|
<br>
|
||||||
|
/etc/shorewall/params<br>
|
||||||
|
<br>
|
||||||
|
<span
|
||||||
|
style="font-family: monospace;">FILE=/etc/foo/bar</span><br>
|
||||||
|
<br>
|
||||||
|
Any other config file:<br>
|
||||||
|
<br>
|
||||||
|
<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>
|
||||||
|
<span style="font-family: monospace;">echo 1 >
|
||||||
|
/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>
|
||||||
|
<span style="font-family: monospace;">echo 1 >
|
||||||
|
/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>
|
||||||
|
<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;"> shorewall delete
|
||||||
|
eth1:1.2.3.4 eth1:2.3.4.5 z12</span><br>
|
||||||
|
<br>
|
||||||
|
The above commands may also be written:<br>
|
||||||
|
<br>
|
||||||
|
<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;"> shorewall delete
|
||||||
|
eth1:1.2.3.4,2.3.4.5 z12</span><br>
|
||||||
|
<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>
|
||||||
|
<span style="font-family: monospace;">openvpn[:{tcp|udp}][:<port>]
|
||||||
|
<zone> <gateway></span><br>
|
||||||
|
<br>
|
||||||
|
Examples:<br>
|
||||||
|
<br>
|
||||||
|
<span style="font-family: monospace;">openvpn:tcp
|
||||||
|
net
|
||||||
|
1.2.3.4 # TCP tunnel on port 1194</span><br
|
||||||
|
style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">
|
||||||
|
openvpn:3344 net
|
||||||
|
1.2.3.4 # UDP on port 3344</span><br
|
||||||
|
style="font-family: monospace;">
|
||||||
|
<span style="font-family: monospace;">
|
||||||
|
openvpn:tcp:4455 net
|
||||||
|
1.2.3.4 # 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>
|
Shorewall 2.2.0 RC5<br>
|
||||||
<br>
|
<br>
|
||||||
</span>Problems Corrected:<br>
|
</span>Problems Corrected:<br>
|
||||||
|
|||||||
@ -38,10 +38,7 @@ Repository</font></a><font color="#ffffff"><br>
|
|||||||
<a href="errata.htm"><font color="#ffffff">Errata</font></a><font
|
<a href="errata.htm"><font color="#ffffff">Errata</font></a><font
|
||||||
color="#ffffff"><br>
|
color="#ffffff"><br>
|
||||||
<a href="shorewall_features.htm"><font color="#ffffff">Features</font></a><font
|
<a href="shorewall_features.htm"><font color="#ffffff">Features</font></a><font
|
||||||
color="#ffffff"> <br>
|
color="#ffffff"> <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>
|
|
||||||
<a href="shorewall_mirrors.htm"><font color="#ffffff">Mirrors</font></a><font
|
<a href="shorewall_mirrors.htm"><font color="#ffffff">Mirrors</font></a><font
|
||||||
color="#ffffff"> <br>
|
color="#ffffff"> <br>
|
||||||
<a href="News.htm"><font color="#ffffff">News Archive</font></a><font
|
<a href="News.htm"><font color="#ffffff">News Archive</font></a><font
|
||||||
|
|||||||
@ -37,10 +37,7 @@ Repository</font></a><font color="#ffffff"><br>
|
|||||||
<a href="errata.htm"><font color="#ffffff">Errata</font></a><font
|
<a href="errata.htm"><font color="#ffffff">Errata</font></a><font
|
||||||
color="#ffffff"><br>
|
color="#ffffff"><br>
|
||||||
<a href="shorewall_features.htm"><font color="#ffffff">Features</font></a><font
|
<a href="shorewall_features.htm"><font color="#ffffff">Features</font></a><font
|
||||||
color="#ffffff"> <br>
|
color="#ffffff"> <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>
|
|
||||||
<a href="shorewall_mirrors.htm"><font color="#ffffff">Mirrors</font></a><font
|
<a href="shorewall_mirrors.htm"><font color="#ffffff">Mirrors</font></a><font
|
||||||
color="#ffffff"> <br>
|
color="#ffffff"> <br>
|
||||||
<a href="News.htm"><font color="#ffffff">News Archive</font></a><font
|
<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>
|
color="#ffffff"><br>
|
||||||
<a href="Shorewall_Doesnt.html"><font color="#ffffff">What it
|
<a href="Shorewall_Doesnt.html"><font color="#ffffff">What it
|
||||||
Cannot Do</font></a>
|
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>
|
||||||
</ul>
|
</ul>
|
||||||
<p><font color="#ffffff"><font color="#ffffff"><font color="#ffffff"><font
|
<p><font color="#ffffff"><font color="#ffffff"><font color="#ffffff"><font
|
||||||
|
|||||||
@ -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
|
class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free
|
||||||
Documentation License</a></span>”.<br>
|
Documentation License</a></span>”.<br>
|
||||||
</p>
|
</p>
|
||||||
<p>2005-03-16<br>
|
<p>2005-03-22<br>
|
||||||
</p>
|
</p>
|
||||||
<hr style="width: 100%; height: 2px;">
|
<hr style="width: 100%; height: 2px;">
|
||||||
<p><b>I strongly urge you to read and print a copy of the <a
|
<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>
|
||||||
<li>Jack Coates provides RPMs taylored for <span
|
<li>Jack Coates provides RPMs taylored for <span
|
||||||
style="font-weight: bold;">Mandrake.</span> You can <a
|
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
|
<li>Marc Zonzon provides a package for <span
|
||||||
style="font-weight: bold;">OpenWRT</span> (Open firmware for Linksys®
|
style="font-weight: bold;">OpenWRT</span> (Open firmware for Linksys®
|
||||||
WRT54G). You can <a
|
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>
|
Simon Matter: <a href="http://www.invoca.ch/pub/packages/shorewall/">http://www.invoca.ch/pub/packages/shorewall/</a><br>
|
||||||
<br>
|
<br>
|
||||||
<span style="font-weight: bold;">Mandrake</span> RPMS provided by Jack
|
<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>
|
<br>
|
||||||
<span style="font-weight: bold;">OpenWRT</span> package provided by
|
<span style="font-weight: bold;">OpenWRT</span> package provided by
|
||||||
Marc Zonzon: <a
|
Marc Zonzon: <a
|
||||||
|
|||||||
@ -5,8 +5,10 @@ Frameset//EN""http://www.w3.org/TR/html4/frameset.dtd">
|
|||||||
<title>Shoreline Firewall</title>
|
<title>Shoreline Firewall</title>
|
||||||
<LINK REL="SHORTCUT ICON" HREF="favicon.ico">
|
<LINK REL="SHORTCUT ICON" HREF="favicon.ico">
|
||||||
<meta http-equiv="Content-Type" content="text/html;
|
<meta http-equiv="Content-Type" content="text/html;
|
||||||
charset=UTF-8"></head>
|
charset=UTF-8">
|
||||||
<frameset rows="110,*" cols="*" frameborder="yes"
|
<link href="/html.css" rel="stylesheet" type="text/css">
|
||||||
|
</head>
|
||||||
|
<frameset rows="114,*" cols="*" frameborder="yes"
|
||||||
border="1"framespacing="0"> <frame
|
border="1"framespacing="0"> <frame
|
||||||
src="Banner.html" name="topFrame"scrolling="NO"
|
src="Banner.html" name="topFrame"scrolling="NO"
|
||||||
noresize >
|
noresize >
|
||||||
|
|||||||
@ -9,7 +9,15 @@
|
|||||||
<meta name="CHANGED" content="20040920;15183300">
|
<meta name="CHANGED" content="20040920;15183300">
|
||||||
</head>
|
</head>
|
||||||
<body dir="ltr" lang="en-US">
|
<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>
|
<p><b>Tom Eastep</b><br>
|
||||||
<br>
|
<br>
|
||||||
The information on this site applies only
|
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>
|
target="_top">here</a>. </p>
|
||||||
</li>
|
</li>
|
||||||
</ul>
|
</ul>
|
||||||
<p>The current 2.2 Stable Release is 2.2.2 -- Here are the <a
|
<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.2/releasenotes.txt">release
|
href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.3/releasenotes.txt">release
|
||||||
notes</a> and here are the <a
|
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
|
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>
|
||||||
<p><a
|
<p><a
|
||||||
href="http://lists.shorewall.net/pipermail/shorewall-announce/2004-December/000451.html"><span
|
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
|
no Back-Cover Texts. A copy of the license is included in the section
|
||||||
entitled “<a href="GnuCopyright.htm" target="_self">GNU
|
entitled “<a href="GnuCopyright.htm" target="_self">GNU
|
||||||
Free Documentation License</a>”.</p>
|
Free Documentation License</a>”.</p>
|
||||||
<p>2005-03-12</p>
|
<p>2005-04-29</p>
|
||||||
<hr>
|
<hr style="width: 100%; height: 2px;">
|
||||||
<h3>Table of Contents</h3>
|
<h3>Table of Contents</h3>
|
||||||
<p style="margin-left: 0.42in; margin-bottom: 0in;"><a href="#Intro">Introduction
|
<p style="margin-left: 0.42in; margin-bottom: 0in;"><a href="#Intro">Introduction
|
||||||
to Shorewall</a></p>
|
to Shorewall</a></p>
|
||||||
@ -64,18 +72,17 @@ Shorewall on Mandrake® with a two-interface setup?</a><br>
|
|||||||
<a href="#License">License</a></p>
|
<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-bottom: 0in; margin-left: 40px;"><a href="#2_0_10">News</a></p>
|
||||||
<p style="margin-left: 0.83in; margin-bottom: 0in;"><span
|
<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>
|
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>
|
</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>
|
<br>
|
||||||
<a href="#OpenWRT">OpenWRT</a><br>
|
<a href="#OpenWRT">OpenWRT</a><br>
|
||||||
</div>
|
</div>
|
||||||
@ -120,7 +127,23 @@ Shorewall is <u>not</u> a
|
|||||||
daemon. Once Shorewall has configured Netfilter, it's job is
|
daemon. Once Shorewall has configured Netfilter, it's job is
|
||||||
complete. After that, there is no Shorewall code running although the
|
complete. After that, there is no Shorewall code running although the
|
||||||
<a href="starting_and_stopping_shorewall.htm">/sbin/shorewall program
|
<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>
|
<h3><a name="GettingStarted"></a>Getting Started with Shorewall</h3>
|
||||||
<p style="margin-left: 0.42in;">New to Shorewall? Start by selecting
|
<p style="margin-left: 0.42in;">New to Shorewall? Start by selecting
|
||||||
the <a href="shorewall_quickstart_guide.htm">QuickStart Guide</a>
|
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>
|
<h3><a name="Info"></a>Looking for Information?</h3>
|
||||||
<p style="margin-left: 0.42in;">The <a href="Documentation_Index.html">Documentation
|
<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
|
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
|
<h3><a name="Mandrake"></a>Running Shorewall on Mandrake® with a
|
||||||
two-interface setup?</h3>
|
two-interface setup?</h3>
|
||||||
<p style="margin-left: 0.42in;">If so, the documentation on this site
|
<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>
|
Documentation License". </p>
|
||||||
<hr>
|
<hr>
|
||||||
<h2><a name="News"></a>News</h2>
|
<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
|
||||||
|
<interface>:!<network> 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), 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 <<span
|
||||||
|
style="font-style: italic;">interface</span>>:!<<span
|
||||||
|
style="font-style: italic;">network</span>> 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
|
<span style="font-weight: bold;"><a name="2_2_2"></a>03/12/2005
|
||||||
Shorewall 2.2.2<br>
|
Shorewall 2.2.2<br>
|
||||||
</span><br>
|
</span><br>
|
||||||
@ -241,768 +354,7 @@ WARNING: RFC1918_STRICT=Yes requires that your kernel and iptables
|
|||||||
support 'Connection Tracking' match.<br>
|
support 'Connection Tracking' match.<br>
|
||||||
</li>
|
</li>
|
||||||
</ol>
|
</ol>
|
||||||
<span style="font-weight: bold;"><a name="2_2_1"></a>02/15/2005
|
<span style="font-weight: bold;"></span><span style="font-weight: bold;"></span>
|
||||||
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>
|
|
||||||
Example:<br>
|
|
||||||
<br>
|
|
||||||
|
|
||||||
rejNotSyn:ULOG
|
|
||||||
all
|
|
||||||
all
|
|
||||||
tcp<br>
|
|
||||||
<br>
|
|
||||||
produces the log message:<br>
|
|
||||||
<br>
|
|
||||||
Feb
|
|
||||||
12 23:57:08 server Shorewall:rejNotSyn:ULOG: ...<br>
|
|
||||||
<br>
|
|
||||||
rather than<br>
|
|
||||||
<br>
|
|
||||||
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->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 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 > /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 > /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 - -
|
|
||||||
tcp 22<br>
|
|
||||||
bar:info<br>
|
|
||||||
<br>
|
|
||||||
/etc/shorewall/rules:<br>
|
|
||||||
<br>
|
|
||||||
foo:debug fw net<br>
|
|
||||||
<br>
|
|
||||||
Logging in the invoked 'foo' action will be:<br>
|
|
||||||
<br>
|
|
||||||
ACCEPT:debug - -
|
|
||||||
tcp 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 - -
|
|
||||||
tcp 22<br>
|
|
||||||
bar:info<br>
|
|
||||||
<br>
|
|
||||||
/etc/shorewall/rules:<br>
|
|
||||||
<br>
|
|
||||||
foo:debug! fw net<br>
|
|
||||||
<br>
|
|
||||||
Logging in the invoke 'foo' action will be:<br>
|
|
||||||
<br>
|
|
||||||
ACCEPT:debug - -
|
|
||||||
tcp 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 = Log Tag.<br>
|
|
||||||
<br>
|
|
||||||
</div>
|
|
||||||
Example:<br>
|
|
||||||
<br>
|
|
||||||
/etc/shorewall/rules:<br>
|
|
||||||
<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
|
|
||||||
IPSEC OPTIONS ...</span><br
|
|
||||||
style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">#
|
|
||||||
ONLY</span><br
|
|
||||||
style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">vpn
|
|
||||||
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
|
|
||||||
Net The big bad Internet</span><br
|
|
||||||
style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">vpn
|
|
||||||
VPN Remote Network</span><br>
|
|
||||||
<br>
|
|
||||||
/etc/shorewall/interfaces:<br>
|
|
||||||
<br>
|
|
||||||
<span style="font-family: monospace;">net
|
|
||||||
eth0 ...</span><br style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">vpn
|
|
||||||
ipsec0 ...</span><br>
|
|
||||||
<br>
|
|
||||||
Under 2.6 Kernel with this new support:<br>
|
|
||||||
<br>
|
|
||||||
/etc/shorewall/zones:<br>
|
|
||||||
<br>
|
|
||||||
<span style="font-family: monospace;">net
|
|
||||||
Net The big bad Internet</span><br
|
|
||||||
style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">vpn
|
|
||||||
VPN Remote Network</span><br>
|
|
||||||
<br>
|
|
||||||
/etc/shorewall/interfaces:<br>
|
|
||||||
<br>
|
|
||||||
<span style="font-family: monospace;">net
|
|
||||||
eth0 ...</span><br>
|
|
||||||
<br>
|
|
||||||
/etc/shorewall/hosts:<br>
|
|
||||||
<br>
|
|
||||||
<span style="font-family: monospace;">vpn
|
|
||||||
eth0:0.0.0.0/0</span><br>
|
|
||||||
<br>
|
|
||||||
/etc/shorewall/ipsec<br>
|
|
||||||
<br>
|
|
||||||
<span style="font-family: monospace;">vpn 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 Net The big bad Internet<br>loc Local Extended local zone</pre>
|
|
||||||
/etc/shorewall/interfaces:<br>
|
|
||||||
<br>
|
|
||||||
<span style="font-family: monospace;">net
|
|
||||||
eth0 ...</span><br style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">loc
|
|
||||||
eth1 ...</span><br style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">loc
|
|
||||||
ipsec0 ...</span><br>
|
|
||||||
<br>
|
|
||||||
Under 2.6 Kernel with this new support:<br>
|
|
||||||
<br>
|
|
||||||
/etc/shorewall/zones:<br>
|
|
||||||
<br>
|
|
||||||
<span style="font-family: monospace;">net
|
|
||||||
Net The big bad Internet</span><br
|
|
||||||
style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">vpn
|
|
||||||
VPN Remote Network</span><br>
|
|
||||||
<br>
|
|
||||||
/etc/shorewall/interfaces:<br>
|
|
||||||
<br>
|
|
||||||
<span style="font-family: monospace;">net
|
|
||||||
eth0 ...</span><br style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">loc
|
|
||||||
eth1 ...</span><br>
|
|
||||||
<br>
|
|
||||||
/etc/shorewall/hosts:<br>
|
|
||||||
<br>
|
|
||||||
<span style="font-family: monospace;">vpn
|
|
||||||
eth0:0.0.0.0/0 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[!]=<number> where <number> is specified using
|
|
||||||
setkey(8) using the 'unique:<number>' option for the SPD level.</li>
|
|
||||||
<li>spi[!]=<number> where <number> 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=<number> (sets the MSS value in TCP SYN packets and
|
|
||||||
is not related to policy matching)</li>
|
|
||||||
<li>mode[!]=transport|tunnel</li>
|
|
||||||
<li>tunnel-src[!]=<address>[/<mask>] (only available
|
|
||||||
with mode=tunnel)</li>
|
|
||||||
<li>tunnel-dst[!]=<address>[/<mask>] (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 (if specified, packets must match all policies;
|
|
||||||
policies are delimited by 'next').</li>
|
|
||||||
<li>next (only available with strict)</li>
|
|
||||||
</ul>
|
|
||||||
</ul>
|
|
||||||
<div style="margin-left: 40px;">Examples:<br>
|
|
||||||
<br>
|
|
||||||
<span style="font-family: monospace;">#ZONE
|
|
||||||
IPSEC OPTIONS
|
|
||||||
|
|
||||||
IN
|
|
||||||
OUT</span><br
|
|
||||||
style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">#
|
|
||||||
ONLY
|
|
||||||
|
|
||||||
OPTIONS OPTIONS</span><br
|
|
||||||
style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">vpn
|
|
||||||
Yes mode=tunnel,proto=esp
|
|
||||||
spi=1000 spi=1001</span><br
|
|
||||||
style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">loc
|
|
||||||
No 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>
|
|
||||||
shorewall check [
|
|
||||||
<configuration-directory> ]<br>
|
|
||||||
shorewall restart [
|
|
||||||
<configuration-directory> ]<br>
|
|
||||||
shorewall start [
|
|
||||||
<configuration-directory> ]<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 <source
|
|
||||||
address>,<source port> conflicts, it tries to do so within
|
|
||||||
port ranges ( < 512, 512-1023, and > 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 <low-port>-<high-port>. 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;"> #INTERFACE
|
|
||||||
SUBNET
|
|
||||||
ADDRESS PROTO</span><br
|
|
||||||
style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">
|
|
||||||
eth0 192.168.1.0/24
|
|
||||||
:4000-5000 tcp</span><br
|
|
||||||
style="font-family: monospace;">
|
|
||||||
<br>
|
|
||||||
Example 2 -- SNAT with udp source ports 7000-8000:<br>
|
|
||||||
<br>
|
|
||||||
<span style="font-family: monospace;">#INTERFACE
|
|
||||||
SUBNET
|
|
||||||
ADDRESS
|
|
||||||
|
|
||||||
PROTO</span><br style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">
|
|
||||||
eth0
|
|
||||||
10.0.0.0/8
|
|
||||||
192.0.2.44:7000-8000 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 <low
|
|
||||||
address>-<high address> 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
|
|
||||||
<major>:<minor> classification in the first column of
|
|
||||||
/etc/shorewall/tcrules:<br>
|
|
||||||
<br>
|
|
||||||
Example:<br>
|
|
||||||
<br>
|
|
||||||
<span style="font-family: monospace;">#MARK/
|
|
||||||
SOURCE
|
|
||||||
DEST PROTO 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
|
|
||||||
-
|
|
||||||
eth0 tcp
|
|
||||||
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 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>
|
|
||||||
Rule:<br>
|
|
||||||
<br>
|
|
||||||
<span
|
|
||||||
style="font-family: monospace;">DROP:info:ftp
|
|
||||||
0.0.0.0/0 0.0.0.0/0
|
|
||||||
tcp 21</span><br>
|
|
||||||
<br>
|
|
||||||
Log prefix with LOGTAGONLY=No:<br>
|
|
||||||
<br>
|
|
||||||
<span style="font-family: monospace;">Shorewall:thisisaverylongacti</span><br>
|
|
||||||
<br>
|
|
||||||
Log prefix with LOGTAGONLY=Yes:<br>
|
|
||||||
<br>
|
|
||||||
<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>
|
|
||||||
<br>
|
|
||||||
Type 3 code 4 (fragmentation needed)<br>
|
|
||||||
Type 11 (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>
|
|
||||||
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>
|
|
||||||
/etc/shorewall/rules<br>
|
|
||||||
/etc/shorewall/tcrules<br>
|
|
||||||
/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>
|
|
||||||
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>
|
|
||||||
- The table name is used as the chain name in the
|
|
||||||
log prefix.<br>
|
|
||||||
- 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>
|
|
||||||
<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>
|
|
||||||
Example:<br>
|
|
||||||
<br>
|
|
||||||
<span style="font-family: monospace;">ursa:/etc/shorewall
|
|
||||||
# shorewall show zones</span><br style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">
|
|
||||||
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;"> </span><br
|
|
||||||
style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;"> loc</span><br
|
|
||||||
style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">
|
|
||||||
eth0:192.168.1.0/24</span><br
|
|
||||||
style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">
|
|
||||||
eth1:1.2.3.4</span><br style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">
|
|
||||||
net </span><br
|
|
||||||
style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">
|
|
||||||
eth0:0.0.0.0/0</span><br style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;"> WiFi</span><br
|
|
||||||
style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">
|
|
||||||
eth1:0.0.0.0/0</span><br style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;"> sec</span><br
|
|
||||||
style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">
|
|
||||||
eth1:0.0.0.0/0</span><br style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;"> </span><br
|
|
||||||
style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">
|
|
||||||
ursa:/etc/shorewall #</span><br>
|
|
||||||
<br>
|
|
||||||
</li>
|
|
||||||
<li>Variable expansion may now be used with the INCLUDE directive.<br>
|
|
||||||
<br>
|
|
||||||
Example:<br>
|
|
||||||
<br>
|
|
||||||
/etc/shorewall/params<br>
|
|
||||||
<br>
|
|
||||||
<span
|
|
||||||
style="font-family: monospace;">FILE=/etc/foo/bar</span><br>
|
|
||||||
<br>
|
|
||||||
Any other config file:<br>
|
|
||||||
<br>
|
|
||||||
<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>
|
|
||||||
<span style="font-family: monospace;">echo 1 >
|
|
||||||
/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>
|
|
||||||
<span style="font-family: monospace;">echo 1 >
|
|
||||||
/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>
|
|
||||||
<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;"> shorewall delete
|
|
||||||
eth1:1.2.3.4 eth1:2.3.4.5 z12</span><br>
|
|
||||||
<br>
|
|
||||||
The above commands may also be written:<br>
|
|
||||||
<br>
|
|
||||||
<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;"> shorewall delete
|
|
||||||
eth1:1.2.3.4,2.3.4.5 z12</span><br>
|
|
||||||
<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>
|
|
||||||
<span style="font-family: monospace;">openvpn[:{tcp|udp}][:<port>]
|
|
||||||
<zone> <gateway></span><br>
|
|
||||||
<br>
|
|
||||||
Examples:<br>
|
|
||||||
<br>
|
|
||||||
<span style="font-family: monospace;">openvpn:tcp
|
|
||||||
net
|
|
||||||
1.2.3.4 # TCP tunnel on port 1194</span><br
|
|
||||||
style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">
|
|
||||||
openvpn:3344 net
|
|
||||||
1.2.3.4 # UDP on port 3344</span><br
|
|
||||||
style="font-family: monospace;">
|
|
||||||
<span style="font-family: monospace;">
|
|
||||||
openvpn:tcp:4455 net
|
|
||||||
1.2.3.4 # 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>
|
|
||||||
<p><a href="News.htm">More News</a></p>
|
<p><a href="News.htm">More News</a></p>
|
||||||
<hr>
|
<hr>
|
||||||
<h2><a name="Leaf"></a>Leaf</h2>
|
<h2><a name="Leaf"></a>Leaf</h2>
|
||||||
|
|||||||
@ -33,7 +33,7 @@ Documentation License</a></span>”.</p>
|
|||||||
</div>
|
</div>
|
||||||
</div>
|
</div>
|
||||||
<div>
|
<div>
|
||||||
<p class="pubdate">2005-03-18</p>
|
<p class="pubdate">2005-03-22</p>
|
||||||
</div>
|
</div>
|
||||||
</div>
|
</div>
|
||||||
<hr></div>
|
<hr></div>
|
||||||
@ -60,7 +60,7 @@ Traffic Control Howto: <a href="http://ds9a.nl/lartc" target="_top">http://ds9a.
|
|||||||
</tr>
|
</tr>
|
||||||
<tr valign="middle">
|
<tr valign="middle">
|
||||||
<td align="left" valign="middle">Iproute Downloads: <a
|
<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>
|
||||||
<tr valign="middle">
|
<tr valign="middle">
|
||||||
<td align="left" valign="middle">LEAF Site: <a
|
<td align="left" valign="middle">LEAF Site: <a
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user