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
|
||||
Documentation License</a></span>”.<br>
|
||||
</p>
|
||||
<p>2005-02-01<br>
|
||||
<p>2005-04-14<br>
|
||||
</p>
|
||||
<hr style="width: 100%; height: 2px;">
|
||||
<p><span style="font-weight: bold;"><br>
|
||||
</span><span style="font-weight: bold;">01/17/2005 -
|
||||
</span><span style="font-weight: bold;">02/15/2005
|
||||
Shorewall 2.2.1<br>
|
||||
<br>
|
||||
</span>This release rolls up the fixes for bugs found in the first 2-3
|
||||
weeks of deployment of Shorewall 2.2.<br>
|
||||
</p>
|
||||
<ol>
|
||||
<li>The /etc/shorewall/policy file contained a misleading comment and
|
||||
both that file and the /etc/shorewall/zones file lacked examples.</li>
|
||||
<li>Shorewall previously used root's default umask which could cause
|
||||
files in /var/lib/shorewall to be world-readable. Shorewall now uses
|
||||
umask 0177.</li>
|
||||
<li>In log messages produced by logging a built-in action, the packet
|
||||
disposition was displayed incorrectly.<br>
|
||||
<br>
|
||||
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>
|
||||
<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
|
||||
color="#ffffff"><br>
|
||||
<a href="shorewall_features.htm"><font color="#ffffff">Features</font></a><font
|
||||
color="#ffffff"> <br>
|
||||
<a href="http://lists.shorewall.net"><font color="#ffffff">Mailing
|
||||
Lists</font></a><font color="#ffffff"><a
|
||||
href="http://lists.shorewall.net"> </a> <br>
|
||||
color="#ffffff"> <font color="#ffffff"><br>
|
||||
<a href="shorewall_mirrors.htm"><font color="#ffffff">Mirrors</font></a><font
|
||||
color="#ffffff"> <br>
|
||||
<a href="News.htm"><font color="#ffffff">News Archive</font></a><font
|
||||
|
||||
@ -37,10 +37,7 @@ Repository</font></a><font color="#ffffff"><br>
|
||||
<a href="errata.htm"><font color="#ffffff">Errata</font></a><font
|
||||
color="#ffffff"><br>
|
||||
<a href="shorewall_features.htm"><font color="#ffffff">Features</font></a><font
|
||||
color="#ffffff"> <br>
|
||||
<a href="http://lists.shorewall.net"><font color="#ffffff">Mailing
|
||||
Lists</font></a><font color="#ffffff"><a
|
||||
href="http://lists.shorewall.net"> </a> <br>
|
||||
color="#ffffff"> <font color="#ffffff"><br>
|
||||
<a href="shorewall_mirrors.htm"><font color="#ffffff">Mirrors</font></a><font
|
||||
color="#ffffff"> <br>
|
||||
<a href="News.htm"><font color="#ffffff">News Archive</font></a><font
|
||||
@ -55,7 +52,7 @@ Issues</font></a><font color="#ffffff"><br>
|
||||
color="#ffffff"><br>
|
||||
<a href="Shorewall_Doesnt.html"><font color="#ffffff">What it
|
||||
Cannot Do</font></a>
|
||||
</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font>
|
||||
</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font>
|
||||
<ul>
|
||||
</ul>
|
||||
<p><font color="#ffffff"><font color="#ffffff"><font color="#ffffff"><font
|
||||
|
||||
@ -22,7 +22,7 @@ Texts. A copy of the license is included in the section entitled “<span
|
||||
class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free
|
||||
Documentation License</a></span>”.<br>
|
||||
</p>
|
||||
<p>2005-03-16<br>
|
||||
<p>2005-03-22<br>
|
||||
</p>
|
||||
<hr style="width: 100%; height: 2px;">
|
||||
<p><b>I strongly urge you to read and print a copy of the <a
|
||||
@ -64,7 +64,8 @@ his site</a>. <br>
|
||||
</li>
|
||||
<li>Jack Coates provides RPMs taylored for <span
|
||||
style="font-weight: bold;">Mandrake.</span> You can <a
|
||||
href="http://www.monkeynoodle.org/tmp">download them from his site</a>.</li>
|
||||
href="http://www.monkeynoodle.org/comp/net/shorewall/">download them
|
||||
from his site</a>.</li>
|
||||
<li>Marc Zonzon provides a package for <span
|
||||
style="font-weight: bold;">OpenWRT</span> (Open firmware for Linksys®
|
||||
WRT54G). You can <a
|
||||
@ -201,7 +202,7 @@ and <span style="font-weight: bold;">Fedora</span> RPMS provided by
|
||||
Simon Matter: <a href="http://www.invoca.ch/pub/packages/shorewall/">http://www.invoca.ch/pub/packages/shorewall/</a><br>
|
||||
<br>
|
||||
<span style="font-weight: bold;">Mandrake</span> RPMS provided by Jack
|
||||
Coates: <a href="http://www.monkeynoodle.org/tmp">http://www.monkeynoodle.org/tmp</a><br>
|
||||
Coates: <a href="http://www.monkeynoodle.org/comp/net/shorewall/">http://www.monkeynoodle.org/comp/net/shorewall/</a><br>
|
||||
<br>
|
||||
<span style="font-weight: bold;">OpenWRT</span> package provided by
|
||||
Marc Zonzon: <a
|
||||
|
||||
@ -5,8 +5,10 @@ Frameset//EN""http://www.w3.org/TR/html4/frameset.dtd">
|
||||
<title>Shoreline Firewall</title>
|
||||
<LINK REL="SHORTCUT ICON" HREF="favicon.ico">
|
||||
<meta http-equiv="Content-Type" content="text/html;
|
||||
charset=UTF-8"></head>
|
||||
<frameset rows="110,*" cols="*" frameborder="yes"
|
||||
charset=UTF-8">
|
||||
<link href="/html.css" rel="stylesheet" type="text/css">
|
||||
</head>
|
||||
<frameset rows="114,*" cols="*" frameborder="yes"
|
||||
border="1"framespacing="0"> <frame
|
||||
src="Banner.html" name="topFrame"scrolling="NO"
|
||||
noresize >
|
||||
|
||||
@ -9,7 +9,15 @@
|
||||
<meta name="CHANGED" content="20040920;15183300">
|
||||
</head>
|
||||
<body dir="ltr" lang="en-US">
|
||||
<h1>Shorewall 2.x</h1>
|
||||
<p style="text-align: right;"><a target="_top"
|
||||
href="http://www.linuxfestnw.org/"><img
|
||||
alt="(Linuxfest NW 2005 Banner)" src="images/LFNW2005-720x90.gif"
|
||||
style="border: 0px solid ; width: 720px; height: 90px;" align="right"></a></p>
|
||||
<p style="text-align: right;"><a target="_top"
|
||||
href="http://www.linuxfestnw.org/"><br>
|
||||
</a></p>
|
||||
<h1>Shorewall 2.x<br>
|
||||
</h1>
|
||||
<p><b>Tom Eastep</b><br>
|
||||
<br>
|
||||
The information on this site applies only
|
||||
@ -28,12 +36,12 @@ to 2.x releases of Shorewall. For older versions:</p>
|
||||
target="_top">here</a>. </p>
|
||||
</li>
|
||||
</ul>
|
||||
<p>The current 2.2 Stable Release is 2.2.2 -- Here are the <a
|
||||
href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.2/releasenotes.txt">release
|
||||
<p>The current 2.2 Stable Release is 2.2.3 -- Here are the <a
|
||||
href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.3/releasenotes.txt">release
|
||||
notes</a> and here are the <a
|
||||
href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.2/known_problems.txt">known
|
||||
href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.3/known_problems.txt">known
|
||||
problems</a> and <a
|
||||
href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.2/errata/">updates</a>.<br>
|
||||
href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.3/errata/">updates</a>.<br>
|
||||
</p>
|
||||
<p><a
|
||||
href="http://lists.shorewall.net/pipermail/shorewall-announce/2004-December/000451.html"><span
|
||||
@ -48,8 +56,8 @@ Foundation; with no Invariant Sections, with no Front-Cover, and with
|
||||
no Back-Cover Texts. A copy of the license is included in the section
|
||||
entitled “<a href="GnuCopyright.htm" target="_self">GNU
|
||||
Free Documentation License</a>”.</p>
|
||||
<p>2005-03-12</p>
|
||||
<hr>
|
||||
<p>2005-04-29</p>
|
||||
<hr style="width: 100%; height: 2px;">
|
||||
<h3>Table of Contents</h3>
|
||||
<p style="margin-left: 0.42in; margin-bottom: 0in;"><a href="#Intro">Introduction
|
||||
to Shorewall</a></p>
|
||||
@ -64,18 +72,17 @@ Shorewall on Mandrake® with a two-interface setup?</a><br>
|
||||
<a href="#License">License</a></p>
|
||||
<p style="margin-bottom: 0in; margin-left: 40px;"><a href="#2_0_10">News</a></p>
|
||||
<p style="margin-left: 0.83in; margin-bottom: 0in;"><span
|
||||
style="text-decoration: underline;"></span><a href="#2_2_2">Shorewall
|
||||
style="text-decoration: underline;"></span><a href="#LinuxFest">Tom
|
||||
will speak at LinuxFest NW 2005</a><br>
|
||||
<a href="#2_2_3">Shorewall
|
||||
2.2.3</a><br>
|
||||
<a href="#2_0_17">Shorewall
|
||||
2.0.17</a><br>
|
||||
<a href="#2_2_2">Shorewall
|
||||
2.2.2</a><br>
|
||||
<a href="#2_2_1">Shorewall
|
||||
2.2.1</a><a href="#End_of_Support"><br>
|
||||
</a><a href="#End_of_Support">End of Support for Shorewall 1.4</a><br>
|
||||
<a href="#2_0_16">Shorewall
|
||||
2.0.16</a><br>
|
||||
<a href="#2_2_0">Shorewall
|
||||
2.2.0</a><br>
|
||||
<br>
|
||||
</p>
|
||||
<div style="margin-left: 40px;"><a href="#Leaf">Leaf</a><br>
|
||||
<div style="margin-left: 40px;"><br>
|
||||
<a href="#Leaf">Leaf</a><br>
|
||||
<br>
|
||||
<a href="#OpenWRT">OpenWRT</a><br>
|
||||
</div>
|
||||
@ -120,7 +127,23 @@ Shorewall is <u>not</u> a
|
||||
daemon. Once Shorewall has configured Netfilter, it's job is
|
||||
complete. After that, there is no Shorewall code running although the
|
||||
<a href="starting_and_stopping_shorewall.htm">/sbin/shorewall program
|
||||
can be used at any time to monitor the Netfilter firewall</a>.</p>
|
||||
can be used at any time to monitor the Netfilter firewall</a>.<br>
|
||||
</p>
|
||||
<p style="margin-left: 0.42in;">Shorewall is not the easiest to use of
|
||||
the available iptables configuration tools but I believe that it is the
|
||||
most flexible and powerful. So if you are looking for a simple
|
||||
point-and-click set-and-forget Linux firewall solution that requires a
|
||||
minimum of networking knowledge, I would encourage you to check out the
|
||||
following alternatives:</p>
|
||||
<ul style="margin-left: 40px;">
|
||||
<li><a href="http://www.m0n0.ch/wall">http://www.m0n0.ch/wall</a></li>
|
||||
<li><a href="http://www.fs-security.com/">http://www.fs-security.com/</a><br>
|
||||
</li>
|
||||
</ul>
|
||||
<p style="margin-left: 0.42in;">On the other hand, if you are looking
|
||||
for a Linux firewall solution that can handle complex and fast changing
|
||||
network environments then Shorewall is a logical choice.<br>
|
||||
</p>
|
||||
<h3><a name="GettingStarted"></a>Getting Started with Shorewall</h3>
|
||||
<p style="margin-left: 0.42in;">New to Shorewall? Start by selecting
|
||||
the <a href="shorewall_quickstart_guide.htm">QuickStart Guide</a>
|
||||
@ -129,7 +152,7 @@ step instructions.</p>
|
||||
<h3><a name="Info"></a>Looking for Information?</h3>
|
||||
<p style="margin-left: 0.42in;">The <a href="Documentation_Index.html">Documentation
|
||||
Index</a> is a good place to start as is the Site Search in the
|
||||
frame above. </p>
|
||||
frame above. network</p>
|
||||
<h3><a name="Mandrake"></a>Running Shorewall on Mandrake® with a
|
||||
two-interface setup?</h3>
|
||||
<p style="margin-left: 0.42in;">If so, the documentation on this site
|
||||
@ -166,6 +189,96 @@ of the license is included in the section entitled "GNU Free
|
||||
Documentation License". </p>
|
||||
<hr>
|
||||
<h2><a name="News"></a>News</h2>
|
||||
<span style="font-weight: bold;"><a name="LinuxFest"></a>04/25/2005 Tom
|
||||
will Speak at LinuxFest NW 2005 -- Bellingham Technical College,
|
||||
Bellingham Washington<br>
|
||||
</span><br>
|
||||
Tom's presentation is entitled "Shorewall and Native IPSEC" and is
|
||||
available for download <a href="LinuxFest.pdf">here (PDF Format)</a>.
|
||||
The presentation will be given Saturday April 30 at 10:00 AM in Haskell
|
||||
Hall, room 111.<br>
|
||||
<br>
|
||||
<span style="font-weight: bold;"><a name="2_2_3"></a>04/07/2005
|
||||
Shorewall 2.2.3<br>
|
||||
</span><br>
|
||||
Problems Corrected:<br>
|
||||
<ol>
|
||||
<li>If a zone is defined in /etc/shorewall/hosts using
|
||||
<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
|
||||
Shorewall 2.2.2<br>
|
||||
</span><br>
|
||||
@ -241,768 +354,7 @@ WARNING: RFC1918_STRICT=Yes requires that your kernel and iptables
|
||||
support 'Connection Tracking' match.<br>
|
||||
</li>
|
||||
</ol>
|
||||
<span style="font-weight: bold;"><a name="2_2_1"></a>02/15/2005
|
||||
Shorewall 2.2.1<br>
|
||||
<br>
|
||||
</span>This release rolls up the fixes for bugs found in the first 2-3
|
||||
weeks of deployment of Shorewall 2.2.<br>
|
||||
<ol>
|
||||
<li>The /etc/shorewall/policy file contained a misleading comment and
|
||||
both that file and the /etc/shorewall/zones file lacked examples.</li>
|
||||
<li>Shorewall previously used root's default umask which could cause
|
||||
files in /var/lib/shorewall to be world-readable. Shorewall now uses
|
||||
umask 0177.</li>
|
||||
<li>In log messages produced by logging a built-in action, the packet
|
||||
disposition was displayed incorrectly.<br>
|
||||
<br>
|
||||
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>
|
||||
<span style="font-weight: bold;"></span><span style="font-weight: bold;"></span>
|
||||
<p><a href="News.htm">More News</a></p>
|
||||
<hr>
|
||||
<h2><a name="Leaf"></a>Leaf</h2>
|
||||
|
||||
@ -33,7 +33,7 @@ Documentation License</a></span>”.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div>
|
||||
<p class="pubdate">2005-03-18</p>
|
||||
<p class="pubdate">2005-03-22</p>
|
||||
</div>
|
||||
</div>
|
||||
<hr></div>
|
||||
@ -60,7 +60,7 @@ Traffic Control Howto: <a href="http://ds9a.nl/lartc" target="_top">http://ds9a.
|
||||
</tr>
|
||||
<tr valign="middle">
|
||||
<td align="left" valign="middle">Iproute Downloads: <a
|
||||
href="ftp://ftp.inr.ac.ru/ip-routing" target="_top">ftp://ftp.inr.ac.ru/ip-routing</a></td>
|
||||
href="http://developer.osdl.org/dev/iproute2/download/" target="_top">http://developer.osdl.org/dev/iproute2/download/</a></td>
|
||||
</tr>
|
||||
<tr valign="middle">
|
||||
<td align="left" valign="middle">LEAF Site: <a
|
||||
|
||||
Loading…
Reference in New Issue
Block a user