forked from extern/shorewall_code
4183092612
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2133 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
9652 lines
390 KiB
HTML
9652 lines
390 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
||
<html>
|
||
<head>
|
||
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8">
|
||
<title>Shorewall News</title>
|
||
<meta name="GENERATOR" content="OpenOffice.org 2.0-pre (Linux)">
|
||
<meta name="CREATED" content="20050511;11123200">
|
||
<meta name="CHANGED" content="20050511;11154300">
|
||
</head>
|
||
<body dir="ltr" lang="en-US">
|
||
<h1 align="left">Shorewall News and Announcements</h1>
|
||
<p><b>Tom Eastep<br>
|
||
<br>
|
||
</b>Copyright © 2001-2005 Thomas M.
|
||
Eastep</p>
|
||
<p>Permission is granted to copy, distribute and/or modify this
|
||
document under the terms of the GNU Free Documentation License,
|
||
Version 1.2 or any later version published by the Free Software
|
||
Foundation; with no Invariant Sections, with no Front-Cover, and with
|
||
no Back-Cover Texts. A copy of the license is included in the section
|
||
entitled “<a href="http://GnuCopyright.htm/" target="_self">GNU
|
||
Free Documentation License</a>”.</p>
|
||
<p>2005-05-15</p>
|
||
<hr>
|
||
<p><b>05/02/2005 Shorewall 2.2.4</b></p>
|
||
<p>Problems Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The error message:<br>
|
||
<br>
|
||
Error: No appropriate chain for
|
||
zone <z1> to zone <z2><br>
|
||
<br>
|
||
has been changed to one that is more self-explanatory:<br>
|
||
<br>
|
||
Error: No policy defined for zone
|
||
<z1> to zone <z2> </p>
|
||
</li>
|
||
<li>
|
||
<p>When only an interface name appeared in the HOST(S) column of an
|
||
/etc/shorewall/hosts file entry, a misleading iptables error message
|
||
resulted. Now the following message is generated:<br>
|
||
<br>
|
||
Error: Invalid HOST(S) column
|
||
contents: <column contents> </p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>Support has been added for UPnP using linux-igd (<a
|
||
href="http://linux-idg.sourceforge.net/">http://linux-idg.sourceforge.net</a>).
|
||
UPnP is required by a number of popular applications including MSN IM. </p>
|
||
</li>
|
||
</ol>
|
||
<p style="margin-left: 0.42in; margin-bottom: 0in;"><b>WARNING</b>:</p>
|
||
<p style="margin-left: 0.83in;">From a security architecture
|
||
viewpoint, UPnP is a disaster. It assumes that:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">All local systems and their users
|
||
are completely trustworthy. </p>
|
||
</li>
|
||
<li>
|
||
<p>No local system is infected with any worm or trojan. </p>
|
||
</li>
|
||
</ol>
|
||
<p style="margin-left: 0.83in; margin-bottom: 0in;">If either of these
|
||
assumptions are not true then UPnP can be used to totally defeat your
|
||
firewall and to allow incoming connections to arbitrary local systems
|
||
on any port whatsoever.<br>
|
||
In short: <b>USE UPnP AT YOUR OWN RISK</b>.</p>
|
||
<p style="margin-left: 0.83in; margin-bottom: 0in;"><br>
|
||
</p>
|
||
<p style="margin-left: 0.42in; margin-bottom: 0in;"><b>WARNING</b>:</p>
|
||
<p style="margin-left: 0.83in;">The linux-igd project appears to be
|
||
inactive and the web site does not display correctly on any open
|
||
source browser that I've tried.<br>
|
||
<br>
|
||
Building and installing
|
||
linux-igd is not for the faint of heart. You must download the source
|
||
from CVS and be prepared to do quite a bit of fiddling with the
|
||
include files from libupnp (which is required to build and/or run
|
||
linux-igd).</p>
|
||
<p style="margin-left: 0.42in; margin-bottom: 0in;">Configuring
|
||
linux-igd:</p>
|
||
<p style="margin-left: 0.83in;">In /etc/upnpd.conf, you will
|
||
want:<br>
|
||
<br>
|
||
|
||
insert_forward_rules = yes<br>
|
||
|
||
prerouting_chain_name = UPnP<br>
|
||
|
||
forward_chain_name = forwardUPnP</p>
|
||
<p style="margin-left: 0.42in; margin-bottom: 0in;">Shorewall
|
||
Configuration:</p>
|
||
<p style="margin-left: 0.83in;">In /etc/shorewall/interfaces, you need
|
||
the 'upnp' option on your external interface.<br>
|
||
<br>
|
||
If your fw->loc
|
||
policy is not ACCEPT then you need this rule:<br>
|
||
<br>
|
||
|
||
allowoutUPnP
|
||
fw
|
||
loc<br>
|
||
<br>
|
||
Note: To use 'allowoutUPnP', your iptables and kernel must
|
||
support the 'owner match' feature (see the output of "shorewall
|
||
check").<br>
|
||
<br>
|
||
If your loc->fw policy is not ACCEPT then you
|
||
need this rule:<br>
|
||
<br>
|
||
|
||
allowinUPnP
|
||
loc
|
||
fw<br>
|
||
<br>
|
||
You MUST have this rule:<br>
|
||
<br>
|
||
|
||
forwardUPnP
|
||
net
|
||
loc</p>
|
||
<p style="margin-left: 0.42in;"> You must also ensure that
|
||
you have a route to 224.0.0.0/4 on you internal (local) interface.</p>
|
||
<ol start="2">
|
||
<li>
|
||
<p>A new 'started' extension script has been added. The
|
||
difference between this extension script and /etc/shorewall/start is
|
||
that this one is invoked after delayed loading of the blacklist
|
||
(DELAYBLACKLISTLOAD=Yes) and after the 'shorewall' chain has been
|
||
created (thus signaling that the firewall is completely up.<br>
|
||
<br>
|
||
/etc/shorewall/started should not change the firewall configuration
|
||
directly but may do so indirectly by running /sbin/shorewall with the
|
||
'nolock' option.</p>
|
||
</li>
|
||
<li>
|
||
<p>By default, shorewall is started with the "-f" (fast) option
|
||
when your system boots. You can override that setting by setting the
|
||
OPTIONS variable in /etc/sysconfig/shorewall (SuSE/Redhat) or
|
||
/etc/default/shorewall (Debian/Bering). If neither file exists, feel
|
||
free to create one or the other.<br>
|
||
<br>
|
||
Example: If you want Shorewall to always use the config files even if
|
||
there is a saved configuration, then specify:<br>
|
||
<br>
|
||
OPTIONS=""</p>
|
||
</li>
|
||
<li>
|
||
<p>Shorewall now has support for the SAME target. This change
|
||
affects the /etc/shorewall/masq and /etc/shorewall/rules file.<br>
|
||
<br>
|
||
SAME is useful when you specify multiple target IP addresses (in the
|
||
ADDRESSES column of /etc/shorewall/masq or in the DEST column of
|
||
/etc/shorewall/rules).<br>
|
||
<br>
|
||
If you use normal SNAT then multiple connections from a given local
|
||
host to hosts on the internet can be assigned different source IP
|
||
addresses. This confuses some applications that use multiple
|
||
connections. To correct this problem, prefix the list of address ranges
|
||
in the ADDRESS column with "SAME:"<br>
|
||
<br>
|
||
|
||
Example: SAME:206.124.146.176-206.124.146.180<br>
|
||
<br>
|
||
If you want each internal system to use the same IP address from the
|
||
list regardless of which internet host it is talking to then prefix the
|
||
ranges with "SAME:nodst:".<br>
|
||
<br>
|
||
|
||
Example: SAME:nodst:206.124.146.176-206.124.146.180<br>
|
||
<br>
|
||
Note that it is not possible to map port numbers when using SAME.<br>
|
||
<br>
|
||
In the rules file, when multiple connections from an internet host
|
||
match a SAME rule then all of the connections will be sent to the same
|
||
internal server. SAME rules are very similar to DNAT rules with the
|
||
keyword SAME replacing DNAT. As in the masq file, changing the port
|
||
number is not supported.</p>
|
||
</li>
|
||
<li>
|
||
<p>A "shorewall show capabilities" command has been added to report
|
||
the capabilities of your kernel and iptables.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
gateway:~# shorewall show capabilities<br>
|
||
Loading /usr/share/shorewall/functions...<br>
|
||
Processing /etc/shorewall/params ...<br>
|
||
Processing
|
||
/etc/shorewall/shorewall.conf...<br>
|
||
Loading Modules...<br>
|
||
Shorewall has detected the following
|
||
iptables/netfilter capabilities:<br>
|
||
|
||
NAT: Available<br>
|
||
|
||
Packet Mangling: Available<br>
|
||
|
||
Multi-port Match: Available<br>
|
||
|
||
Extended Multi-port Match: Available<br>
|
||
|
||
Connection Tracking Match: Available<br>
|
||
|
||
Packet Type Match: Not available<br>
|
||
|
||
Policy Match: Available<br>
|
||
|
||
Physdev Match: Available<br>
|
||
|
||
IP range Match: Available<br>
|
||
|
||
Recent Match: Available<br>
|
||
|
||
Owner Match: Available<br>
|
||
gateway:~#</p>
|
||
</li>
|
||
<li>
|
||
<p>A "-v" option has been added to /sbin/shorewall. Currently, this
|
||
option only affects the "show log" command (e.g., "shorewall -v show
|
||
log") and the "monitor" command. In these commands, it causes the MAC
|
||
address in the log message (if any) to be displayed. As previously,
|
||
when "-v" is omitted, the MAC address is suppressed.</p>
|
||
</li>
|
||
<li>
|
||
<p>In /etc/shorewall/rules, a value of 'none' in either the SOURCE
|
||
or DEST columns now causes the rule to be ignored. This is most useful
|
||
when used with shell variables:<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
/etc/shorewall/rules:<br>
|
||
<br>
|
||
|
||
AllowFTP
|
||
$FTP_CLIENTS fw<br>
|
||
<br>
|
||
When FTP_CLIENTS is set to
|
||
'none', the above rule is ignored. Otherwise, the rule is
|
||
evaluated and generates Netfilter rules.</p>
|
||
</li>
|
||
<li>
|
||
<p>The installer now detects that it is running on a Slackware
|
||
system and adjusts the DEST and INIT variables accordingly.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>05/01/2005 Tom spoke at LinuxFest NW 2005 -- Bellingham
|
||
Technical College, Bellingham Washington<br>
|
||
</b><br>
|
||
Tom's
|
||
presentation was entitled "Shorewall and Native IPSEC" and
|
||
is available for download <a href="http://shorewall.net/LinuxFest.pdf">here
|
||
(PDF Format)</a>. <br>
|
||
<br>
|
||
<b>04/07/2005 Shorewall 2.2.3<br>
|
||
</b><br>
|
||
Problems
|
||
Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">If a zone is defined in
|
||
/etc/shorewall/hosts using <interface>:!<network> in the
|
||
HOSTS column then startup errors occur on "shorewall [re]start". </p>
|
||
</li>
|
||
<li>
|
||
<p>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. </p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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. </p>
|
||
</li>
|
||
<li>
|
||
<p>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.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>03/31/2005 Shorewall 2.0.17<br>
|
||
<br>
|
||
</b>Problems Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Invoking the 'rejNotSyn' action
|
||
results in an error at startup. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The UDP and TCP port numbers in
|
||
/usr/share/shorewall/action.AllowPCA were reversed. </p>
|
||
</li>
|
||
<li>
|
||
<p>If a zone is defined in /etc/shorewall/hosts using <<i>interface</i>>:!<<i>network</i>>
|
||
in the HOSTS column then startup errors occur on "shorewall [re]start".</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>03/12/2005 Shorewall 2.2.2<br>
|
||
</b><br>
|
||
Problems Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The SOURCE column in the
|
||
/etc/shorewall/tcrules file now correctly allows IP ranges (assuming
|
||
that your iptables and kernel support ranges).</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">If A is a user-defined action and
|
||
you have file /etc/shorewall/A then when that file is invoked by
|
||
Shorewall during [re]start, the $TAG value may be incorrect. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Previously, if an iptables command
|
||
generating a logging rule failed, the Shorewall [re]start was still
|
||
successful. This error is now considered fatal and Shorewall will be
|
||
either restored from the last save (if any) or it will be stopped. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The port numbers for UDP and TCP
|
||
were previously reversed in the /usr/share/shorewall/action.AllowPCA
|
||
file. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Previously, the 'install.sh' script
|
||
did not update the /usr/share/shorewall/action.* files. </p>
|
||
</li>
|
||
<li>
|
||
<p>Previously, when an interface name appeared in the DEST column
|
||
of /etc/shorewall/tcrules, the name was not validated against the set
|
||
of defined interfaces and bridge ports.</p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The SOURCE column in the
|
||
/etc/shorewall/tcrules file now allows $FW to be optionally followed by
|
||
":" and a host/network address or address range. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall now clears the output
|
||
device only if it is a terminal. This avoids ugly control sequences
|
||
being placed in files when /sbin/shorewall output is redirected. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The output from 'arp -na' has been
|
||
added to the 'shorewall status' display. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The 2.6.11 Linux kernel and iptables
|
||
1.3.0 now allow port ranges to appear in port lists handled by
|
||
"multiport match". If Shorewall detects this capability, it will use
|
||
"multiport match" for port lists containing port ranges. Be cautioned
|
||
that each port range counts for TWO ports and a port list handled with
|
||
"multiport match" can still specify a maximum of 15 ports.<br>
|
||
<br>
|
||
As always, if a port list in /etc/shorewall/rules is incompatible with
|
||
"multiport match", a separate iptables rule will be generated for each
|
||
element in the list. </p>
|
||
</li>
|
||
<li>
|
||
<p>Traditionally, the RETURN target in the 'rfc1918' file has
|
||
caused 'norfc1918' processing to cease for a packet if the packet's
|
||
source IP address matches the rule. Thus, if you have:<br>
|
||
<br>
|
||
<font face="monospace">SUBNETS
|
||
TARGET</font><br>
|
||
<font face="monospace">192.168.1.0/24 RETURN</font><br>
|
||
<br>
|
||
then traffic from 192.168.1.4 to 10.0.3.9 will be accepted even though
|
||
you also have:<br>
|
||
<br>
|
||
<font face="monospace">SUBNETS
|
||
TARGET</font><br>
|
||
<font face="monospace">10.0.0.0/8
|
||
logdrop</font><br>
|
||
<br>
|
||
Setting RFC1918_STRICT=Yes in shorewall.conf will cause such traffic to
|
||
be logged and dropped since while the packet's source matches the
|
||
RETURN rule, the packet's destination matches the 'logdrop' rule.<br>
|
||
<br>
|
||
If not specified or specified as empty (e.g., RFC1918_STRICT="") then
|
||
RFC1918_STRICT=No is assumed.<br>
|
||
<br>
|
||
WARNING: RFC1918_STRICT=Yes requires that your kernel and iptables
|
||
support 'Connection Tracking' match.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>02/15/2005 Shorewall 2.2.1<br>
|
||
<br>
|
||
</b>This release rolls up the
|
||
fixes for bugs found in the first 2-3 weeks of deployment of
|
||
Shorewall 2.2.</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The /etc/shorewall/policy file
|
||
contained a misleading comment and both that file and the
|
||
/etc/shorewall/zones file lacked examples. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall previously used root's
|
||
default umask which could cause files in /var/lib/shorewall to be
|
||
world-readable. Shorewall now uses umask 0177. </p>
|
||
</li>
|
||
<li>
|
||
<p>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: ...</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The comments regarding built-in
|
||
actions in /usr/share/shorewall/actions.std have been corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p>The /etc/shorewall/policy file in the LRP package was missing
|
||
the 'all->all' policy.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>02/05/2005 End of Support for Shorewall 1.4<br>
|
||
<br>
|
||
</b>Effective
|
||
today, support for Shorewall 1.4 has been discontinued. See the link
|
||
at the top of this article for upgrade information.<br>
|
||
<br>
|
||
<b>02/01/2005
|
||
Shorewall 2.0.16<br>
|
||
</b><br>
|
||
This release back-ports the DROPINVALID
|
||
shorewall.conf option from 2.2.0.</p>
|
||
<ol>
|
||
<li>
|
||
<p>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. </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>02/01/2005 Shorewall 2.2.0<br>
|
||
<br>
|
||
</b>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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. </p>
|
||
</li>
|
||
<li>
|
||
<p>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:</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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: </p>
|
||
<ul>
|
||
<li>
|
||
<p>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</p>
|
||
</li>
|
||
<li>
|
||
<p>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!</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
</ol>
|
||
<p style="margin-left: 0.42in;">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:</p>
|
||
<p style="margin-left: 0.83in;">$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.</p>
|
||
<p>Example:<br>
|
||
<br>
|
||
/etc/shorewall/rules:<br>
|
||
|
||
<br>
|
||
acton:info:test<br>
|
||
<br>
|
||
Your /etc/shorewall/acton file will be run
|
||
with:</p>
|
||
<p style="margin-left: 0.83in; margin-bottom: 0in;">$CHAIN="%acton1<br>
|
||
$LEVEL="info"<br>
|
||
$TAG="test"</p>
|
||
<p><br>
|
||
<br>
|
||
</p>
|
||
<ol start="6">
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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: </p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">It prevents Shorewall from being
|
||
started prematurely by the user's initialization scripts. </p>
|
||
</li>
|
||
<li>
|
||
<p>It causes /etc/shorewall/shorewall.conf to be modified so
|
||
that it won't be replaced by upgrades using RPM.</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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: </p>
|
||
<ul>
|
||
<li>
|
||
<p>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>
|
||
<font face="monospace">#ZONE
|
||
IPSEC OPTIONS ...</font><br>
|
||
<font face="monospace">#
|
||
ONLY</font><br>
|
||
<font face="monospace">vpn
|
||
Yes</font><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>
|
||
<font face="monospace">net
|
||
Net The big bad Internet</font><br>
|
||
<font face="monospace">vpn
|
||
VPN Remote Network</font><br>
|
||
<br>
|
||
/etc/shorewall/interfaces:<br>
|
||
<br>
|
||
<font face="monospace">net
|
||
eth0 ...</font><br>
|
||
<font face="monospace">vpn
|
||
ipsec0 ...</font><br>
|
||
<br>
|
||
Under 2.6 Kernel with this new support:<br>
|
||
<br>
|
||
/etc/shorewall/zones:<br>
|
||
<br>
|
||
<font face="monospace">net
|
||
Net The big bad Internet</font><br>
|
||
<font face="monospace">vpn
|
||
VPN Remote Network</font><br>
|
||
<br>
|
||
/etc/shorewall/interfaces:<br>
|
||
<br>
|
||
<font face="monospace">net
|
||
eth0 ...</font><br>
|
||
<br>
|
||
/etc/shorewall/hosts:<br>
|
||
<br>
|
||
<font face="monospace">vpn eth0:0.0.0.0/0</font><br>
|
||
<br>
|
||
/etc/shorewall/ipsec<br>
|
||
<br>
|
||
<font face="monospace">vpn Yes</font></p>
|
||
</li>
|
||
<li>
|
||
<p>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:</p>
|
||
<pre>net Net The big bad Internet<br>loc Local Extended local zone</pre>
|
||
<p> /etc/shorewall/interfaces:<br>
|
||
<br>
|
||
<font face="monospace">net
|
||
eth0 ...</font><br>
|
||
<font face="monospace">loc
|
||
eth1 ...</font><br>
|
||
<font face="monospace">loc
|
||
ipsec0 ...</font><br>
|
||
<br>
|
||
Under 2.6 Kernel with this new support:<br>
|
||
<br>
|
||
/etc/shorewall/zones:<br>
|
||
<br>
|
||
<font face="monospace">net
|
||
Net The big bad Internet</font><br>
|
||
<font face="monospace">vpn
|
||
VPN Remote Network</font><br>
|
||
<br>
|
||
/etc/shorewall/interfaces:<br>
|
||
<br>
|
||
<font face="monospace">net
|
||
eth0 ...</font><br>
|
||
<font face="monospace">loc
|
||
eth1 ...</font><br>
|
||
<br>
|
||
/etc/shorewall/hosts:<br>
|
||
<br>
|
||
<font face="monospace">vpn
|
||
eth0:0.0.0.0/0 ipsec,...</font> </p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
</ol>
|
||
<p style="margin-left: 0.42in;">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:</p>
|
||
<ul>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">reqid[!]=<number> where
|
||
<number> is specified using setkey(8) using the
|
||
'unique:<number>' option for the SPD level. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">proto[!]=ah|esp|ipcomp </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">mss=<number> (sets the MSS
|
||
value in TCP SYN packets and is not related to policy matching) </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">mode[!]=transport|tunnel </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">tunnel-src[!]=<address>[/<mask>]
|
||
(only available with mode=tunnel) </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">strict (if specified,
|
||
packets must match all policies; policies are delimited by 'next'). </p>
|
||
</li>
|
||
<li>
|
||
<p>next (only available with strict) </p>
|
||
</li>
|
||
</ul>
|
||
</ul>
|
||
<p style="margin-left: 0.42in;">Examples:<br>
|
||
<br>
|
||
<font face="monospace">#ZONE
|
||
IPSEC OPTIONS
|
||
|
||
IN OUT</font><br>
|
||
<font face="monospace">#
|
||
ONLY
|
||
|
||
|
||
OPTIONS
|
||
OPTIONS</font><br>
|
||
<font face="monospace">vpn
|
||
Yes mode=tunnel,proto=esp
|
||
spi=1000 spi=1001</font><br>
|
||
<font face="monospace">loc
|
||
No reqid=44,mode=transport</font><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.</p>
|
||
<ol start="8">
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A new 'allowBcast' builtin action
|
||
has been added -- it silently allows broadcasts and multicasts. </p>
|
||
</li>
|
||
<li>
|
||
<p>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> ]</p>
|
||
</li>
|
||
<li>
|
||
<p>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>
|
||
<font face="monospace">#INTERFACE
|
||
SUBNET
|
||
ADDRESS PROTO</font><br>
|
||
<font face="monospace">eth0
|
||
192.168.1.0/24 :4000-5000 tcp</font><br>
|
||
<br>
|
||
Example 2 -- SNAT with udp source ports 7000-8000:<br>
|
||
<br>
|
||
<font face="monospace">#INTERFACE
|
||
SUBNET
|
||
ADDRESS
|
||
|
||
PROTO</font><br>
|
||
<font face="monospace">eth0
|
||
10.0.0.0/8
|
||
192.0.2.44:7000-8000 udp</font></p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall now verifies that your
|
||
kernel and iptables have physdev match support if BRIDGING=Yes in
|
||
shorewall.conf. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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>
|
||
<font face="monospace">#MARK/
|
||
SOURCE
|
||
DEST PROTO PORT(S)</font><br>
|
||
<font face="monospace">#CLASSIFY</font><br>
|
||
<font face="monospace">1:30
|
||
-
|
||
eth0 tcp 25</font><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. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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". </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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". </p>
|
||
</li>
|
||
<li>
|
||
<p>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>
|
||
<font face="monospace">DROP:info:ftp
|
||
0.0.0.0/0 0.0.0.0/0
|
||
tcp 21</font><br>
|
||
<br>
|
||
Log prefix with LOGTAGONLY=No:<br>
|
||
<br>
|
||
<font face="monospace">Shorewall:thisisaverylongacti</font><br>
|
||
<br>
|
||
Log prefix with LOGTAGONLY=Yes:<br>
|
||
<br>
|
||
<font face="monospace">Shorewall:ftp:DROP</font></p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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. </p>
|
||
</li>
|
||
<li>
|
||
<p>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)</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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. </p>
|
||
</li>
|
||
<li>
|
||
<p>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</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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"). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall now has support for the
|
||
CONNMARK target from iptables. See the /etc/shorewall/tcrules file for
|
||
details. </p>
|
||
</li>
|
||
<li>
|
||
<p>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>
|
||
<font face="monospace">Shorewall:nat:PREROUTING</font><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.</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The AllowNNTP action now also allows
|
||
NNTP over SSL/TLS (NNTPS). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">For consistency, the CLIENT PORT(S)
|
||
column in the tcrules file has been renamed SOURCE PORT(S). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The contents of
|
||
/proc/sys/net/ip4/icmp_echo_ignore_all is now shown in the output of
|
||
"shorewall status". </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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. </p>
|
||
</li>
|
||
<li>
|
||
<p>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>
|
||
<font face="monospace">ursa:/etc/shorewall
|
||
# shorewall show zones</font><br>
|
||
<font face="monospace">Shorewall-2.2.0-Beta7 Zones
|
||
at ursa - Sat Nov 27 11:18:25 PST 2004</font><br>
|
||
<br>
|
||
<font face="monospace">loc</font><br>
|
||
<font face="monospace">eth0:192.168.1.0/24</font><br>
|
||
<font face="monospace">eth1:1.2.3.4</font><br>
|
||
<font face="monospace">net
|
||
</font><br>
|
||
<font face="monospace">eth0:0.0.0.0/0</font><br>
|
||
<font face="monospace">WiFi</font><br>
|
||
<font face="monospace">eth1:0.0.0.0/0</font><br>
|
||
<font face="monospace">sec</font><br>
|
||
<font face="monospace">eth1:0.0.0.0/0</font><br>
|
||
<br>
|
||
<font face="monospace">ursa:/etc/shorewall #</font></p>
|
||
</li>
|
||
<li>
|
||
<p>Variable expansion may now be used with the INCLUDE directive.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
/etc/shorewall/params<br>
|
||
<br>
|
||
<font face="monospace">FILE=/etc/foo/bar</font><br>
|
||
<br>
|
||
Any other config file:<br>
|
||
<br>
|
||
<font face="monospace">INCLUDE
|
||
$FILE</font></p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The output of "shorewall status" now
|
||
includes the results of "ip -stat link ls". This helps diagnose
|
||
performance problems caused by link errors. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">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. </p>
|
||
</li>
|
||
<li>
|
||
<p>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>
|
||
<font face="monospace">echo 1 >
|
||
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal</font><br>
|
||
<br>
|
||
Additional kernel logging about INVALID TCP packets may be obtained by
|
||
adding this command to /etc/shorewall/init:<br>
|
||
<br>
|
||
<font face="monospace">echo 1 >
|
||
/proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid</font><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.</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The "shorewall add" and "shorewall
|
||
delete" commands now accept a list of hosts to add or delete.<br>
|
||
<br>
|
||
Examples:<br>
|
||
<br>
|
||
<font face="monospace">shorewall add eth1:1.2.3.4
|
||
eth1:2.3.4.5 z12</font><br>
|
||
<font face="monospace">shorewall delete eth1:1.2.3.4
|
||
eth1:2.3.4.5 z12</font><br>
|
||
<br>
|
||
The above commands may also be written:<br>
|
||
<br>
|
||
<font face="monospace">shorewall add
|
||
eth1:1.2.3.4,2.3.4.5 z12</font><br>
|
||
<font face="monospace">shorewall delete
|
||
eth1:1.2.3.4,2.3.4.5 z12</font><br>
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel
|
||
type. OpenVPN entries in /etc/shorewall/tunnels have this format:<br>
|
||
<br>
|
||
<font face="monospace">openvpn[:{tcp|udp}][:<port>]
|
||
<zone> <gateway></font><br>
|
||
<br>
|
||
Examples:<br>
|
||
<br>
|
||
<font face="monospace">openvpn:tcp
|
||
net
|
||
1.2.3.4 # TCP tunnel on port 1194</font><br>
|
||
<font face="monospace">openvpn:3344
|
||
net 1.2.3.4 #
|
||
UDP on port 3344</font><br>
|
||
<font face="monospace">openvpn:tcp:4455
|
||
net 1.2.3.4 # TCP on port 4455</font></p>
|
||
</li>
|
||
<li>
|
||
<p>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: </p>
|
||
</li>
|
||
</ol>
|
||
<ul>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Only one instance of the script
|
||
may be used at a time. </p>
|
||
</li>
|
||
<li>
|
||
<p>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. </p>
|
||
</li>
|
||
</ul>
|
||
</ul>
|
||
<ol start="39">
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The output of "shorewall status" now
|
||
lists the loaded netfilter kernel modules. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The range of UDP ports opened by the
|
||
AllowTrcrt action has been increased to 33434:33524. </p>
|
||
</li>
|
||
<li>
|
||
<p>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. </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>01/17/2005 - Shorewall 2.2.0 RC5<br>
|
||
<br>
|
||
</b>Problems Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The AllowTrcrt action has been
|
||
changed to allow up to 30 hops (same as default for 'traceroute').
|
||
Previously, the action was documented as allowing 20 hops but actually
|
||
only allowed for 6 hops.</p>
|
||
</li>
|
||
<li>
|
||
<p>Using some lightweight shells, valid entries in
|
||
/etc/shorewall/ecn produce startup errors. </p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>A new AllowInvalid standard built-in action has been added. This
|
||
action accepts packets that are in the INVALID connection-tracking
|
||
state. </p>
|
||
</li>
|
||
</ol>
|
||
<p><a name="Mirrors"></a><a name="2_0_15"></a><b>01/16/2005 - New
|
||
Shorewall Mirrors<br>
|
||
<br>
|
||
</b>Thanks to Lorenzo Martignoni and Nick
|
||
Slikey, there are now Shorewall <a href="shorewall_mirrors.htm">mirrors</a>
|
||
in Milan Italy and in Austin Texas. Thanks Lorenzo and
|
||
Nick!<br>
|
||
<b><br>
|
||
01/12/2005 - Shorewall 2.0.15<br>
|
||
</b><br>
|
||
Problems
|
||
Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The range of ports opened by the
|
||
AllowTrcrt action has been expanded to 33434:33524 to allow for a
|
||
maximum of 30 hops. </p>
|
||
</li>
|
||
<li>
|
||
<p>Code mis-ported from 2.2.0 in release 2.0.14 caused the
|
||
following error during "shorewall start" where SYN rate-limiting is
|
||
present in /etc/shorewall/policy:<br>
|
||
<br>
|
||
Bad argument `DROP'<br>
|
||
Try `iptables -h' or 'iptables --help'
|
||
for more information.</p>
|
||
</li>
|
||
</ol>
|
||
<p><a name="2_2_0_RC4"></a><b>01/06/2005 - Shorewall 2.2.0 RC4<br>
|
||
</b><br>
|
||
New
|
||
Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>A listing of loaded iptables kernel modules is now included in
|
||
the output of "shorewall status".</p>
|
||
</li>
|
||
</ol>
|
||
<p>Problems Corrected.</p>
|
||
<ol>
|
||
<li>
|
||
<p>Several problems associated with processing the IPSEC colummn in
|
||
/etc/shorewall/masq have been corrected.</p>
|
||
</li>
|
||
</ol>
|
||
<p><a name="2_0_14"></a><b>01/03/2005 - Shorewall 2.0.14<br>
|
||
</b><br>
|
||
New
|
||
Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>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.</p>
|
||
</li>
|
||
</ol>
|
||
<p>Problems Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A typo in the
|
||
/etc/shorewall/interfaces file has been fixed. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">"bad variable" error messages
|
||
occurring during "shorewall stop" and "shorewall clear" have been
|
||
eliminated. </p>
|
||
</li>
|
||
<li>
|
||
<p>A misleading typo in /etc/shorewall/tunnels has been corrected.
|
||
The TYPE column for an IPIP tunnel should contain "ipip" rather than
|
||
"ip".</p>
|
||
</li>
|
||
</ol>
|
||
<p><a name="MandrakeRPMS"></a><a name="Redhat_Fedora"></a><a
|
||
name="2_2_0_RC3"></a>
|
||
<b>12/31/2004 - Mandrake-specific RPMs available<br>
|
||
<br>
|
||
</b>Jack
|
||
Coates has generously volunteered to provide Shorewall RPMs for use
|
||
under Mandrake. You can download Jack's RPMs from
|
||
<a href="http://www.monkeynoodle.org/tmp/" target="_top">http://www.monkeynoodle.org/tmp/</a><br>
|
||
<br>
|
||
<b>12/31/2004
|
||
- Redhat/Fedora-specific RPMs available<br>
|
||
</b><br>
|
||
Simon Matter has
|
||
graciously volunteered to provide RPMs taylored for Redhat and
|
||
Fedora. You can download Simon's RPMs from
|
||
<a href="http://www.invoca.ch/pub/packages/shorewall/" target="_top">http://www.invoca.ch/pub/packages/shorewall/</a><br>
|
||
<br>
|
||
Thanks,
|
||
Simon!<br>
|
||
<br>
|
||
<b>12/30/2004 - Shorewall 2.2.0 RC3<br>
|
||
</b><br>
|
||
Problems
|
||
Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p>The following error message could appear during "shorewall stop"
|
||
or "shorewall clear":<br>
|
||
|
||
<br>
|
||
|
||
local: lo:: bad variable name</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The rate limiting example in
|
||
/etc/shorewall/rules has been changed to use the RATE LIMIT column. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Entries in /etc/shorewall/masq with
|
||
the INTERFACE column containing <ifname>:: (e.g., "eth0::") would
|
||
generate a progress message but would not generate an iptables rule. </p>
|
||
</li>
|
||
<li>
|
||
<p>A misleading typo in /etc/shorewall/tunnels has been corrected.</p>
|
||
</li>
|
||
</ol>
|
||
<p><br>
|
||
<br>
|
||
</p>
|
||
<p><b>12/24/2004 - Shorewall 2.2.0 RC2<br>
|
||
<br>
|
||
</b>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>By popular demand, the default port for Open VPN tunnels is now
|
||
1194 (the IANA-reserved port number for Open VPN). </p>
|
||
</li>
|
||
</ol>
|
||
<p><a name="2_2_0_RC1"></a><b>12/19/2004 - Shorewall 2.2.0
|
||
RC1<br>
|
||
<br>
|
||
</b>Problems Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p>The syntax of the add and delete command has been clarified in
|
||
the help summary produced by /sbin/shorewall. </p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel
|
||
type. OpenVPN entries in /etc/shorewall/tunnels have this format:<br>
|
||
<br>
|
||
openvpn[:{tcp|udp}][:<port>]
|
||
<zone> <gateway><br>
|
||
<br>
|
||
Examples:</p>
|
||
<pre> openvpn:tcp net 1.2.3.4 # TCP tunnel on port 5000<br> openvpn:3344 net 1.2.3.4 # UDP on port 3344<br> openvpn:tcp:4455 net 1.2.3.4 # TCP on port 4455</pre>
|
||
</li>
|
||
<li>
|
||
<p>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:<br>
|
||
<br>
|
||
- Only one instance of the script may be used at a
|
||
time.<br>
|
||
- 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.</p>
|
||
</li>
|
||
</ol>
|
||
<p><a name="2_2_0_Beta8"></a><b>12/11/2004 - Shorewall 2.2.0 Beta
|
||
8<br>
|
||
<br>
|
||
</b>Problems Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A typo in the
|
||
/etc/shorewall/interfaces file has been corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p>Previously, the "add" and "delete" commands were generating
|
||
incorrect policy matches when policy match support was available. </p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>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.</p>
|
||
</li>
|
||
<li>
|
||
<p>The "shorewall add" and "shorewall delete" commands now accept a
|
||
list of hosts to add or delete.<br>
|
||
<br>
|
||
Examples:<br>
|
||
<br>
|
||
shorewall add eth1:1.2.3.4 eth1:2.3.4.5 z12<br>
|
||
shorewall delete eth1:1.2.3.4 eth1:2.3.4.5 z12<br>
|
||
<br>
|
||
The above commands may also be written:<br>
|
||
<br>
|
||
shorewall add eth1:1.2.3.4,2.3.4.5 z12<br>
|
||
shorewall delete eth1:1.2.3.4,2.3.4.5 z12<br>
|
||
</p>
|
||
</li>
|
||
</ol>
|
||
<p><a name="2_2_0_Beta7"></a><b>12/04/2004 - Shorewall 2.2.0 Beta
|
||
7<br>
|
||
</b><br>
|
||
Problems Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p>The "shorewall add" and "shorewall delete" commands now work in
|
||
a bridged environment. The syntax is:<br>
|
||
<br>
|
||
shorewall
|
||
add <interface>[:<port>]:<address> <zone><br>
|
||
shorewall
|
||
delete <interface>[:<port>]:<address> <zone><br>
|
||
<br>
|
||
Examples:<br>
|
||
<br>
|
||
shorewall
|
||
add br0:eth2:192.168.1.3 OK<br>
|
||
shorewall
|
||
delete br0:eth2:192.168.1.3 OK</p>
|
||
</li>
|
||
<li>
|
||
<p>Previously, "shorewall save" created an out-of-sequence restore
|
||
script. The commands saved in the user's /etc/shorewall/start script
|
||
were executed prior to the Netfilter configuration being restored. This
|
||
has been corrected so that "shorewall save" now places those commands
|
||
at the end of the script.<br>
|
||
<br>
|
||
To accomplish this change, the "restore base" file
|
||
(/var/lib/shorewall/restore-base) has been split into two files:<br>
|
||
<br>
|
||
/var/lib/shorewall/restore-base -- commands to be executed before
|
||
Netfilter the configuration is restored.<br>
|
||
<br>
|
||
/var/lib/shorewall/restore-tail -- commands to be executed after the
|
||
Netfilter configuration is restored.</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Previously, traffic from the
|
||
firewall to a dynamic zone member host did not need to match the
|
||
interface specified when the host was added to the zone. For example,
|
||
if eth0:1.2.3.4 is added to dynamic zone Z then traffic out of any
|
||
firewall interface to 1.2.3.4 will obey the fw->Z policies and
|
||
rules. This has been corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p>Shorewall uses the temporary chain 'fooX1234' to probe iptables
|
||
for detrmining which features are supported. Previously, if that chain
|
||
happened to exist when Shorewall was run, capabilities were
|
||
mis-detected. </p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>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>
|
||
ursa:/etc/shorewall #
|
||
shorewall show zones<br>
|
||
Shorewall-2.2.0-Beta7 Zones
|
||
at ursa - Sat Nov 27 11:18:25 PST 2004<br>
|
||
<br>
|
||
loc<br>
|
||
|
||
eth0:192.168.1.0/24<br>
|
||
|
||
eth1:1.2.3.4<br>
|
||
net<br>
|
||
|
||
eth0:0.0.0.0/0<br>
|
||
WiFi<br>
|
||
|
||
eth1:0.0.0.0/0<br>
|
||
sec<br>
|
||
|
||
eth1:0.0.0.0/0<br>
|
||
<br>
|
||
ursa:/etc/shorewall #</p>
|
||
</li>
|
||
<li>
|
||
<p>Variable expansion may now be used with the INCLUDE directive.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
/etc/shorewall/params<br>
|
||
<br>
|
||
|
||
FILE=/etc/foo/bar<br>
|
||
<br>
|
||
Any other config file:<br>
|
||
<br>
|
||
|
||
INCLUDE $FILE</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The output of "shorewall status" now
|
||
includes the results of "ip -stat link ls". This helps diagnose
|
||
performance problems caused by link errors. </p>
|
||
</li>
|
||
<li>
|
||
<p>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<br>
|
||
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.</p>
|
||
</li>
|
||
</ol>
|
||
<p><a name="2_0_13"></a><b>12/02/2004 - Shorewall 2.0.13<br>
|
||
<br>
|
||
</b>Problems
|
||
Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p>A typo in /usr/share/shorewall/firewall caused the "shorewall
|
||
add" to issue an error message:</p>
|
||
<pre style="margin-bottom: 0.2in;">/usr/share/shorewall/firewall: line 1: match_destination_hosts: command not found</pre>
|
||
</li>
|
||
</ol>
|
||
<p><a name="2_0_12"></a><b>12/01/2004 - Shorewall 2.0.12<br>
|
||
</b><br>
|
||
Problems
|
||
Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A typo in shorewall.conf (NETNOTSYN)
|
||
has been corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p>The "shorewall add" and "shorewall delete" commands now work in
|
||
a bridged environment. The syntax is:<br>
|
||
<br>
|
||
shorewall add
|
||
<interface>[:<bridge port>][:<address>] <zone><br>
|
||
shorewall delete
|
||
<interface>[:<bridge port>][:<address>] <zone><br>
|
||
<br>
|
||
Examples:<br>
|
||
<br>
|
||
shorewall add br0:eth2:192.168.1.3 OK<br>
|
||
shorewall delete br0:eth2:192.168.1.3 OK</p>
|
||
</li>
|
||
<li>
|
||
<p>Previously, "shorewall save" created an out-of-sequence restore
|
||
script. The commands saved in the user's /etc/shorewall/start script
|
||
were executed prior to the Netfilter configuration being restored. This
|
||
has been corrected so that "shorewall save" now places those commands
|
||
at the end of the script.<br>
|
||
<br>
|
||
To accomplish this change, the "restore base" file
|
||
(/var/lib/shorewall/restore-base) has been split into two files:<br>
|
||
<br>
|
||
/var/lib/shorewall/restore-base -- commands to be executed
|
||
before the Netfilter configuration is restored.<br>
|
||
<br>
|
||
/var/lib/shorewall/restore-tail -- commands to be executed
|
||
after the Netfilter configuration is restored.</p>
|
||
</li>
|
||
<li>
|
||
<p>Previously, traffic from the firewall to a dynamic zone member
|
||
host did not need to match the interface specified when the host was
|
||
added to the zone. For example, if eth0:1.2.3.4 is added to dynamic
|
||
zone Z then traffic out of any firewall interface to 1.2.3.4 will obey
|
||
the fw->Z policies and rules. This has been corrected. </p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>Variable expansion may now be used with the INCLUDE directive.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
/etc/shorewall/params<br>
|
||
<br>
|
||
|
||
FILE=/etc/foo/bar<br>
|
||
<br>
|
||
Any other config file:<br>
|
||
<br>
|
||
|
||
INCLUDE $FILE</p>
|
||
</li>
|
||
</ol>
|
||
<p><a name="2_2_0_Beta6"></a><b>11/26/2004 - Shorewall 2.2.0 Beta
|
||
6<br>
|
||
<br>
|
||
</b>Beta 5 was more or less DOA. Here's Beta 6.<br>
|
||
<br>
|
||
Problems
|
||
Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Fixed a number of problems
|
||
associated with not having an IPTABLES value assigned in shorewall.conf
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>Corrected a 'duplicate chain' error on "shorewall add" when the
|
||
'mss' option is present in /etc/shorewall/ipsec.</p>
|
||
</li>
|
||
</ol>
|
||
<p><a name="2_2_0_Beta5"></a><b>11/26/2004 - Shorewall 2.2.0 Beta
|
||
5<br>
|
||
</b><br>
|
||
Problems corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p>A typo in shorewall.conf (NETNOTSYN) has been corrected. </p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">For consistency, the CLIENT PORT(S)
|
||
column in the tcrules file has been renamed SOURCE PORT(S). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The contents of
|
||
/proc/sys/net/ip4/icmp_echo_ignore_all is now shown in the output of
|
||
"shorewall status". </p>
|
||
</li>
|
||
<li>
|
||
<p>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.</p>
|
||
</li>
|
||
</ol>
|
||
<p><a name="2_0_11"></a><b>11/23/2004 - Shorewall 2.0.11<br>
|
||
</b><br>
|
||
Problems
|
||
corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The INSTALL file now include special
|
||
instructions for Slackware users. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The bogons file has been updated. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Service names are replaced by port
|
||
numbers in /etc/shorewall/tos. </p>
|
||
</li>
|
||
<li>
|
||
<p>A typo in the install.sh file that caused an error during a new
|
||
install has been corrected. </p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>The AllowNNTP action now allows NNTP over SSL/TLS (NTTPS).</p>
|
||
</li>
|
||
</ol>
|
||
<p><a name="2_2_0_Beta4"></a><b>11/19/2004 - Shorewall 2.2.0 Beta
|
||
4<br>
|
||
</b><br>
|
||
Problems Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A cut and paste error resulted in
|
||
some nonsense in the description of the IPSEC column in
|
||
/etc/shorewall/masq. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A typo in /etc/shorewall/rules has
|
||
been corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The bogons file has been updated. </p>
|
||
</li>
|
||
<li>
|
||
<p>The "shorewall add" command previously reported success but did
|
||
nothing -- now it works. </p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>The AllowNNTP action now allows NNTP over SSL/TLS (NNTPS).</p>
|
||
</li>
|
||
</ol>
|
||
<p><a name="2_2_0_Beta3"></a><b>11/09/2004 - Shorewall 2.2.0 Beta
|
||
3<br>
|
||
</b><br>
|
||
Problems Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Missing '#' in the rfc1918 file has
|
||
been corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p>The INSTALL file now includes special instructions for Slackware
|
||
users. </p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>In CLASSIFY rules (/etc/shorewall/tcrules), an interface name
|
||
may now appear in the DEST column as in:</p>
|
||
<pre> #MARK/ SOURCE DEST PROTO PORT(S)<br> #CLASSIFY<br> 1:30 - eth0 tcp 25</pre>
|
||
</li>
|
||
</ol>
|
||
<p><a name="2_2_0_Beta2"></a><b>11/02/2004 - Shorewall 2.2.0 Beta
|
||
2<br>
|
||
<br>
|
||
</b>Problems Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p>The "shorewall check" command results in the (harmless) error
|
||
message:<br>
|
||
<br>
|
||
|
||
/usr/share/shorewall/firewall: line 2753:<br>
|
||
|
||
check_dupliate_zones: command not found</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The AllowNTP standard action now
|
||
allows outgoing responses to broadcasts. </p>
|
||
</li>
|
||
<li>
|
||
<p>A clarification has been added to the hosts file's description
|
||
of the 'ipsec' option pointing out that the option is redundent if the
|
||
zone named in the ZONE column has been designated an IPSEC zone in the
|
||
/etc/shorewall/ipsec file. </p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>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.</p>
|
||
</li>
|
||
</ol>
|
||
<p><a name="2_0_10"></a><b>10/25/2004 - Shorewall 2.0.10<br>
|
||
</b><br>
|
||
Problems
|
||
Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The GATEWAY column was previously
|
||
ignored in 'pptpserver' entries in /etc/shorewall/tunnels. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">When log rule numbers are included
|
||
in the LOGFORMAT, duplicate rule numbers could previously be generated.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The /etc/shorewall/tcrules file now
|
||
includes a note to the effect that rule evaluation continues after a
|
||
match. </p>
|
||
</li>
|
||
<li>
|
||
<p>The error message produced if Shorewall couldn't obtain the
|
||
routes through an interface named in the SUBNET column of
|
||
/etc/shorewall/masq was less than helpful since it didn't include the
|
||
interface name.</p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>The "shorewall status" command has been enhanced to include the
|
||
values of key /proc settings:<br>
|
||
<br>
|
||
Example from a two-interface firewall:<br>
|
||
<br>
|
||
/proc<br>
|
||
<br>
|
||
/proc/sys/net/ipv4/ip_forward = 1<br>
|
||
/proc/sys/net/ipv4/conf/all/proxy_arp = 0<br>
|
||
/proc/sys/net/ipv4/conf/all/arp_filter = 0<br>
|
||
/proc/sys/net/ipv4/conf/all/rp_filter = 0<br>
|
||
/proc/sys/net/ipv4/conf/default/proxy_arp = 0<br>
|
||
/proc/sys/net/ipv4/conf/default/arp_filter = 0<br>
|
||
/proc/sys/net/ipv4/conf/default/rp_filter = 0<br>
|
||
/proc/sys/net/ipv4/conf/eth0/proxy_arp = 0<br>
|
||
/proc/sys/net/ipv4/conf/eth0/arp_filter = 0<br>
|
||
/proc/sys/net/ipv4/conf/eth0/rp_filter = 0<br>
|
||
/proc/sys/net/ipv4/conf/eth1/proxy_arp = 0<br>
|
||
/proc/sys/net/ipv4/conf/eth1/arp_filter = 0<br>
|
||
/proc/sys/net/ipv4/conf/eth1/rp_filter = 0<br>
|
||
/proc/sys/net/ipv4/conf/lo/proxy_arp = 0<br>
|
||
/proc/sys/net/ipv4/conf/lo/arp_filter = 0<br>
|
||
/proc/sys/net/ipv4/conf/lo/rp_filter = 0</p>
|
||
</li>
|
||
</ol>
|
||
<p><a name="2_2_0_Beta1"></a><br>
|
||
<b>10/24/2004 - Shorewall 2.2.0
|
||
Beta1<br>
|
||
<br>
|
||
</b>The first beta in the 2.2 series is now available.
|
||
Download location is:</p>
|
||
<p style="margin-left: 0.42in;"><a
|
||
href="http://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1">http://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1</a><br>
|
||
<a
|
||
href="ftp://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1"
|
||
target="_top">ftp://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1</a></p>
|
||
<p>The features available in this release and the migration
|
||
considerations are covered in the <a
|
||
href="http://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1/releasenotes.txt">release
|
||
notes</a>. Highlights include:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The behavior produced by specifying
|
||
a log level in an action invocation is now much more rational.
|
||
Previously, all packets sent to the action were logged; now each rule
|
||
within the invoked action behaves as if logging had been specified on
|
||
it. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Support for the 2.6 Kernel's native
|
||
IPSEC implementation is now available. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Support for ipp2p is included. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Support for the iptables CONNMARK
|
||
facility is now included in Shorewall. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A new LOGALLNEW option facilitates
|
||
problem analysis. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Users with a large static blacklist
|
||
can now defer loading the blacklist until after the rest of the ruleset
|
||
has been enabled. Doing so can decrease substantially the amount of
|
||
time that connections are disabled during <b>shorewall [re]start</b>. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Support for the iptables 'iprange
|
||
match' feature has been enabled. Users whose kernel and iptables
|
||
contain this feature can use ip address ranges in most places in their
|
||
Shorewall configuration where a CIDR netowrk can be used. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Accepting of source routing and
|
||
martian logging may now be enabled/disabled on each interface. </p>
|
||
</li>
|
||
<li>
|
||
<p>Shorewall now supports the CLASSIFY iptable target. </p>
|
||
</li>
|
||
</ol>
|
||
<p><a name="2_0_9"></a><b>9/23/2004 - Shorewall 2.0.9<br>
|
||
</b><br>
|
||
Problems
|
||
Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p>Previously, an empty PROTO column or a value of "all" in that
|
||
column would cause errors when processing the /etc/shorewall/tcrules
|
||
file. </p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>The "shorewall status" command now includes the output of "brctl
|
||
show" if the bridge tools are installed.</p>
|
||
</li>
|
||
</ol>
|
||
<p><a name="SupportChange"></a><b>9/20/2004 – Change in Shorewall
|
||
Support</b></p>
|
||
<p>Friends,</p>
|
||
<p>The demands that my job and my personal life are currently placing
|
||
on me are such that supporing Shorewall to the extent that I have
|
||
been doing is just not possible any more.</p>
|
||
<p>I will continue to be active on the development list and will
|
||
continue to develop Shorewall if at all possible.</p>
|
||
<p>I will also continue to read the user's list and will help with
|
||
problems that interest me. But I am no longer going to hop on every
|
||
problem as soon as I see it.</p>
|
||
<p>This change means that I'm going to have to depend on you folks to
|
||
help each other; I'm confident that we can make this work.</p>
|
||
<p><a name="2_0_8"></a><b>8/22/2004 - Shorewall 2.0.8<br>
|
||
</b><br>
|
||
Problems
|
||
Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p>Entries in the USER/GROUP column of an action file (made from
|
||
action.template) may be ignored or cause odd errors. </p>
|
||
</li>
|
||
</ol>
|
||
<p><a name="2_0_7"></a><b>7/29/2004 - Shorewall 2.0.7<br>
|
||
<br>
|
||
</b>Problems
|
||
Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The PKTTYPE option introduced in
|
||
version 2.0.6 is now used when generating rules to REJECT packets.
|
||
Broadcast packets are silently dropped rather than being rejected with
|
||
an ICMP (which is a protocol violation) and users whose kernels have
|
||
broken packet type match support are likely to see messages reporting
|
||
this violation. Setting PKTTYPE=No should cause these messages to
|
||
cease. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Multiple interfaces with the
|
||
'blacklist' option no longer result in an error message at startup. </p>
|
||
</li>
|
||
<li>
|
||
<p>The following has been added to /etc/shorewall/bogons:<br>
|
||
<br>
|
||
0.0.0.0 RETURN<br>
|
||
<br>
|
||
This prevents the 'nobogons' option from logging DHCP 'DISCOVER'
|
||
broadcasts.</p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>To improve supportability, the "shorewall status" command now
|
||
includes IP and Route configuration information.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
<font face="monospace">IP Configuration</font><br>
|
||
<br>
|
||
<font face="monospace">1: lo: <LOOPBACK,UP> mtu
|
||
16436 qdisc noqueue</font><br>
|
||
<font face="monospace">link/loopback
|
||
00:00:00:00:00:00 brd 00:00:00:00:00:00</font><br>
|
||
<font face="monospace">inet 127.0.0.1/8
|
||
brd 127.255.255.255 scope host lo</font><br>
|
||
<font face="monospace">inet6 ::1/128
|
||
scope host</font><br>
|
||
<font face="monospace">2: eth0:
|
||
<BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen
|
||
1000</font><br>
|
||
<font face="monospace">link/ether
|
||
00:a0:c9:15:39:78 brd ff:ff:ff:ff:ff:ff</font><br>
|
||
<font face="monospace">inet6
|
||
fe80::2a0:c9ff:fe15:3978/64 scope link</font><br>
|
||
<font face="monospace">3: eth1:
|
||
<BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen
|
||
1000</font><br>
|
||
<font face="monospace">link/ether
|
||
00:a0:c9:a7:d7:bf brd ff:ff:ff:ff:ff:ff</font><br>
|
||
<font face="monospace">inet6
|
||
fe80::2a0:c9ff:fea7:d7bf/64 scope link</font><br>
|
||
<font face="monospace">5: sit0@NONE: <NOARP> mtu
|
||
1480 qdisc noop</font><br>
|
||
<font face="monospace">link/sit 0.0.0.0
|
||
brd 0.0.0.0</font><br>
|
||
<font face="monospace">6: eth2:
|
||
<BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen
|
||
1000</font><br>
|
||
<font face="monospace">link/ether
|
||
00:40:d0:07:3a:1b brd ff:ff:ff:ff:ff:ff</font><br>
|
||
<font face="monospace">inet6
|
||
fe80::240:d0ff:fe07:3a1b/64 scope link</font><br>
|
||
<font face="monospace">7: br0:
|
||
<BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc noqueue</font><br>
|
||
<font face="monospace">link/ether
|
||
00:40:d0:07:3a:1b brd ff:ff:ff:ff:ff:ff</font><br>
|
||
<font face="monospace">inet
|
||
192.168.1.3/24 brd 192.168.1.255 scope global br0</font><br>
|
||
<font face="monospace">inet6
|
||
fe80::240:d0ff:fe07:3a1b/64 scope link</font><br>
|
||
<br>
|
||
<font face="monospace">Routing Rules</font><br>
|
||
<br>
|
||
<font face="monospace">0:
|
||
from all lookup local</font><br>
|
||
<font face="monospace">32765: from all
|
||
fwmark ca lookup www.out</font><br>
|
||
<font face="monospace">32766: from all lookup main</font><br>
|
||
<font face="monospace">32767: from all lookup
|
||
default</font><br>
|
||
<br>
|
||
<font face="monospace">Table local:</font><br>
|
||
<br>
|
||
<font face="monospace">broadcast 192.168.1.0 dev
|
||
br0 proto kernel scope link src 192.168.1.3</font><br>
|
||
<font face="monospace">broadcast 127.255.255.255 dev
|
||
lo proto kernel scope link src 127.0.0.1</font><br>
|
||
<font face="monospace">local 192.168.1.3 dev br0
|
||
proto kernel scope host src 192.168.1.3</font><br>
|
||
<font face="monospace">broadcast 192.168.1.255 dev
|
||
br0 proto kernel scope link src 192.168.1.3</font><br>
|
||
<font face="monospace">broadcast 127.0.0.0 dev lo
|
||
proto kernel scope link src 127.0.0.1</font><br>
|
||
<font face="monospace">local 127.0.0.1 dev lo proto
|
||
kernel scope host src 127.0.0.1</font><br>
|
||
<font face="monospace">local 127.0.0.0/8 dev lo
|
||
proto kernel scope host src 127.0.0.1</font><br>
|
||
<br>
|
||
<font face="monospace">Table www.out:</font><br>
|
||
<br>
|
||
<font face="monospace">default via 192.168.1.3 dev br0</font><br>
|
||
<br>
|
||
<font face="monospace">Table main:</font><br>
|
||
<br>
|
||
<font face="monospace">192.168.1.0/24 dev br0 proto
|
||
kernel scope link src 192.168.1.3</font><br>
|
||
<font face="monospace">default via 192.168.1.254 dev br0</font><br>
|
||
<br>
|
||
<font face="monospace">Table default:</font></p>
|
||
</li>
|
||
</ol>
|
||
<p><a name="2_0_6"></a><b>7/16/2004 - Shorewall 2.0.6<br>
|
||
<br>
|
||
</b>Problems
|
||
Corrected:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Some users have reported the packet
|
||
type match option in iptables/Netfilter failing to match certain
|
||
broadcast packets. The result is that the firewall log shows a lot of
|
||
broadcast packets.<br>
|
||
<br>
|
||
Other users have complained of the following message when starting
|
||
Shorewall:<br>
|
||
<br>
|
||
|
||
modprobe: cant locate module ipt_pkttype<br>
|
||
<br>
|
||
Users experiencing either of these problems can use PKTTYPE=No in
|
||
shorewall.conf to cause Shorewall to use IP address filtering of
|
||
broadcasts rather than packet type. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The shorewall.conf and zones file
|
||
are no longer given execute permission by the installer script. </p>
|
||
</li>
|
||
<li>
|
||
<p>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.</p>
|
||
</li>
|
||
</ul>
|
||
<p><a name="2_0_5"></a><b>7/10/2004 - Shorewall 2.0.5<br>
|
||
</b><br>
|
||
Problems
|
||
Corrected:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">If DISABLE_IPV6=Yes in
|
||
shorewall.conf then harmless error messages referring to $RESTOREBASE
|
||
are generated during <b>shorewall stop</b>. </p>
|
||
</li>
|
||
<li>
|
||
<p>An anachronistic comment concerning a mangle option has been
|
||
removed from shorewall.conf.</p>
|
||
</li>
|
||
</ul>
|
||
<p><a name="2_0_4"></a><b>7/06/2004 - Shorewall 2.0.4<br>
|
||
</b><br>
|
||
Problems
|
||
Corrected:</p>
|
||
<ul>
|
||
<li>
|
||
<p>Rules with $FW as the source zone and that specify logging can
|
||
cause "shorewall start" to fail.</p>
|
||
</li>
|
||
</ul>
|
||
<p><a name="Release_Model"></a><b>7/03/2004 - New Shorewall Release
|
||
Model<br>
|
||
<br>
|
||
</b>Effective today, Shorewall is adopting a new release
|
||
model which takes ideas from the one used in the Linux Kernel and
|
||
from the release model for Postfix.</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Releases continue to have a
|
||
three-level identification <i>x.y.z</i> (e.g., 2.0.3).</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The first two levels (<i>x.y)</i>
|
||
designate the <i>Major Release Number</i> (e.g., 2.0) </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The third level (<i>z</i>)
|
||
designates the <i>Minor Release Number</i>. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Even numbered major releases (e.g., <i>1.4,
|
||
2.0, 2.2, ...)</i> are <i>Stable Releases</i>. No new features are
|
||
added to stable releases and new minor releases of a stable release
|
||
will only contain bug fixes. Installing a new minor release for the
|
||
major release that you are currently running involves no migration
|
||
issues (for example, if you are running 1.4.10 and I release 1.4.11,
|
||
your current configuration is 100% compatible with the new release). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Support is available through the <a
|
||
href="http://lists.shorewall.net/">Mailing List </a>for the two most
|
||
recent Stable Releases.</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Odd numbered major releases (e.g.,
|
||
2.1, 2.3, ...) are <i>Development Releases</i>. Development releases
|
||
are where new functionality is introduced. Documentation for new
|
||
features will be available but it may not be up to the standards of the
|
||
stable release documentation. Sites running Development Releases should
|
||
be prepared to play an active role in testing new features. Bug fixes
|
||
and problem resolution for the development release take a back seat to
|
||
support of the stable releases. Problem reports for the current
|
||
development release should be sent to the <a
|
||
href="mailto:shorewall-devel@lists.shorewall.net">Shorewall
|
||
Development Mailing List</a>.</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">When the level of functionality of
|
||
the current development release is judged adaquate, the Beta period for
|
||
a new Stable release will begin. Beta releases have identifications of
|
||
the form <i>x.y.0-BetaN</i> where <i>x.y</i> is the number of the
|
||
next Stable Release and <i>N</i>=1,2,3... . Betas are expected to
|
||
occur rougly once per year. Beta releases may contain new functionality
|
||
not present in the previous beta release (e.g., 2.2.0-Beta4 may contain
|
||
functionality not present in 2.2.0-Beta3). When I'm confident that the
|
||
current Beta release is stable, I will release the first <i>Release
|
||
Candidate. </i>Release candidates have identifications of the form <i>x.y.0-RCn
|
||
</i>where <i>x.y </i>is the number of the next Stable Release and
|
||
<i>n</i>=1,2,3... . Release candidates contain no new functionailty
|
||
-- they only contain bug fixes. When the stability of the current
|
||
release candidate is judged to be sufficient then that release
|
||
candidate will be released as the new stable release (e.g., 2.2.0). At
|
||
that time, the new stable release and the prior stable release are
|
||
those that are supported. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">What does it mean for a major
|
||
release to be <i>supported?</i> It means that I will answer questions
|
||
about the release and that if a bug is found, I will fix the bug and
|
||
include the fix in the next minor release. </p>
|
||
</li>
|
||
<li>
|
||
<p>Between minor releases, bug fixes will continue to be made
|
||
available through the Errata page for each major release.</p>
|
||
</li>
|
||
</ol>
|
||
<p>The immediate implications of this change are as follows:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The functionality of the 2.0 major
|
||
release is frozen at the level of minor release 2.0.3. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The two major releases currently
|
||
supported are 1.4 and 2.0. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">I will be opening the 2.1
|
||
development release shortly with the release of 2.1.0. </p>
|
||
</li>
|
||
<li>
|
||
<p>Bug-fix releases with identifications of the form <i>x.y.zX </i>where
|
||
X=a,b,c,... (e.g., 2.0.3c) will not be seen in the future.</p>
|
||
</li>
|
||
</ol>
|
||
<p><a name="2_0_3c"></a><b>7/02/2004 - Shorewall 2.0.3c<br>
|
||
<br>
|
||
</b>Problems
|
||
Corrected<b>:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Error messages regarding
|
||
$RESTOREBASE occur during <b>shorewall stop</b> </p>
|
||
</li>
|
||
<li>
|
||
<p>If CLEAR_TC=Yes in <tt>shorewall.conf</tt>, <b>shorewall stop</b>
|
||
fails without removing the lock file. </p>
|
||
</li>
|
||
</ol>
|
||
<p><a name="2_0_3b"></a><b><br>
|
||
6/30/2004 - Shorewall 2.0.3b and
|
||
Shorewall 1.4.10g<br>
|
||
<br>
|
||
</b>Problems Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The security vulnerability fix
|
||
released in Shorewall 2.0.3a failed under Slackware 9.1. </p>
|
||
</li>
|
||
<li>
|
||
<p>The security vulnerability fix released in Shorewall 2.0.3a
|
||
failed if mktemp was not installed.</p>
|
||
</li>
|
||
</ol>
|
||
<p><a name="2_0_3a"></a><b>6/28/2004 - Shorewall 2.0.3a and Shorewall
|
||
1.4.10f<br>
|
||
<br>
|
||
</b>Problems Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Javier Fernández-Sanguino Peña has
|
||
discovered an exploitable vulnerability in the way that Shorewall
|
||
handles temporary files and directories. The vulnerability can allow a
|
||
non-root user to cause arbitrary files on the system to be overwritten.
|
||
LEAF Bering and Bering uClibc users are generally not at risk due to
|
||
the fact that LEAF boxes do not typically allow logins by non-root
|
||
users. </p>
|
||
</li>
|
||
<li>
|
||
<p>(2.0.3a only) A non-empty DEST entry in /etc/shorewall/tcrules
|
||
will generate an error and Shorewall fails to start. </p>
|
||
</li>
|
||
</ol>
|
||
<p style="margin-left: 0.42in;">Note:: Slackware users may need the
|
||
'functions' file from CVS (STABLE/ project for 1.4.10f and STABLE2/
|
||
project for 2.0.3a) to prevent startup errors with these versions
|
||
installed. These updatged files are also available from the Errata
|
||
(<a href="http://errata.htm/">2.0,</a> <a href="1.4/errata.htm">1.4</a>).</p>
|
||
<p><a name="2_0_3"></a><b>6/23/2004 - Shorewall 2.0.3<br>
|
||
<br>
|
||
</b>Problems
|
||
Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The 'firewall' script is not purging
|
||
temporary restore files in /var/lib/shorewall. These files have names
|
||
of the form "restore-nnnnn". </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The /var/lib/shorewall/restore
|
||
script did not load the kernel modules specified in
|
||
/etc/shorewall/modules. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Specifying a null common action in
|
||
/etc/shorewall/actions (e.g., :REJECT) results in a startup error. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">If /var/lib/shorewall does not
|
||
exist, shorewall start fails. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">DNAT rules with a dynamic source
|
||
zone don't work properly. When used, these rules cause the rule to be
|
||
checked against ALL input, not just input from the designated zone. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The install.sh script reported
|
||
installing some files in /etc/shorewall when the files were actually
|
||
installed in /usr/share/shorewall. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall checks netfilter
|
||
capabilities before loading kernel modules. Hence if kernel module
|
||
autoloading isn't enabled, the capabilities will be misdetected. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The 'newnotsyn' option in
|
||
/etc/shorewall/hosts has no effect. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The file /etc/init.d/shorewall now
|
||
gets proper ownership when the RPM is built by a non-root user. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Rules that specify bridge ports in
|
||
both the SOURCE and DEST columns no longer cause "shorewall start" to
|
||
fail. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Comments in the rules file have been
|
||
added to advise users that "all" in the SOURCE or DEST column does not
|
||
affect intra-zone traffic. </p>
|
||
</li>
|
||
<li>
|
||
<p>With BLACKLISTNEWONLY=Yes, ICMP packets with state INVALID are
|
||
now passed through the blacklisting chains. Without this change, it is
|
||
not possible to blacklist hosts that are mounting certain types of
|
||
ICMP-based DOS attacks. </p>
|
||
</li>
|
||
</ol>
|
||
<p>Issues when migrating from Shorewall 2.0.2 to Shorewall 2.0.3:</p>
|
||
<ol>
|
||
<li>
|
||
<p>The 'dropNonSyn' standard builtin action has been replaced with
|
||
the 'dropNotSyn' standard builtin action. The old name can still be
|
||
used but will generate a warning. </p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall now supports multiple
|
||
saved configurations. </p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The default saved configuration
|
||
(restore script) in /var/lib/shorewall is now specified using the
|
||
RESTOREFILE option in shorewall.conf. If this variable isn't set then
|
||
to maintain backward compatibility, 'restore' is assumed.<br>
|
||
<br>
|
||
The value of RESTOREFILE must be a simple file name; no slashes ("/")
|
||
may be included.</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The "save" command has been
|
||
extended to be able to specify the name of a saved configuration.<br>
|
||
<br>
|
||
shorewall
|
||
save [ <file name> ]<br>
|
||
<br>
|
||
The current state is saved to /var/lib/shorewall/<file name>. If
|
||
no <file name> is given, the configuration is saved to the file
|
||
determined by the RESTOREFILE setting. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The "restore" command has been
|
||
extended to be able to specify the name of a saved configuration:<br>
|
||
<br>
|
||
shorewall
|
||
restore [ <file name> ]<br>
|
||
<br>
|
||
The firewall state is restored from /var/lib/shorewall/<file
|
||
name>. If no <file name> is given, the firewall state is
|
||
restored from the file determined by the RESTOREFILE setting. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The "forget" command has
|
||
changed. Previously, the command unconditionally removed the
|
||
/var/lib/shorewall/save file which records the current dynamic
|
||
blacklist. The "forget" command now leaves that file alone.<br>
|
||
<br>
|
||
Also, the "forget" command has been extended to be able to specify the
|
||
name of a saved configuration:<br>
|
||
<br>
|
||
|
||
shorewall forget [ <file name> ]<br>
|
||
<br>
|
||
The file /var/lib/shorewall/<file name> is removed. If no
|
||
<file name> is given, the file determined by the RESTOREFILE
|
||
setting is removed. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The "shorewall -f start" command
|
||
restores the state from the file determined by the RESTOREFILE setting.
|
||
</p>
|
||
</li>
|
||
</ol>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">"!" is now allowed in accounting
|
||
rules. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Interface names appearing within the
|
||
configuration are now verified. Interface names must match the name of
|
||
an entry in /etc/shorewall/interfaces (or if bridging is enabled, they
|
||
must match the name of an entry in /etc/shorewall/interfaces or the
|
||
name of a bridge port appearing in /etc/shorewall/hosts). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A new 'rejNotSyn' built-in standard
|
||
action has been added. This action responds to "New not SYN" packets
|
||
with an RST.<br>
|
||
<br>
|
||
The 'dropNonSyn' action has been superceded by the new 'dropNotSyn'
|
||
action. The old name will be accepted until the next major release of
|
||
Shorewall but will generate a warning.<br>
|
||
<br>
|
||
Several new logging actions involving "New not SYN" packets have been
|
||
added:<br>
|
||
<br>
|
||
logNewNotSyn -- logs
|
||
the packet with disposition = LOG<br>
|
||
dLogNewNotSyn -- logs the
|
||
packet with disposition = DROP<br>
|
||
rLogNewNotSyn -- logs the
|
||
packet with disposition = REJECT<br>
|
||
<br>
|
||
The packets are logged at the log level specified in the LOGNEWNOTSYN
|
||
option in shorewall.conf. If than option is empty or not specified,
|
||
then 'info' is assumed.<br>
|
||
<br>
|
||
Examples (In all cases, set NEWNOTSYN=Yes in shorewall.conf): </p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">To simulate the behavior of
|
||
NEWNOTSYN=No: </p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Add 'NoNewNotSyn' to
|
||
/etc/shorewall/actions. </p>
|
||
</li>
|
||
<li>
|
||
<p>Create /etc/shorewall/action.NoNewNotSyn containing:<br>
|
||
<br>
|
||
|
||
dLogNotSyn<br>
|
||
|
||
dropNotSyn</p>
|
||
</li>
|
||
<li>
|
||
<p>Early in your rules file, place:<br>
|
||
<br>
|
||
|
||
NoNewNotSyn all all tcp</p>
|
||
</li>
|
||
</ol>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Drop 'New not SYN' packets from
|
||
the net only. Don't log them: </p>
|
||
<ol>
|
||
<li>
|
||
<p>Early in your rules file, place:<br>
|
||
<br>
|
||
|
||
dropNotSyn
|
||
net all tcp</p>
|
||
</li>
|
||
</ol>
|
||
</li>
|
||
</ol>
|
||
</li>
|
||
<li>
|
||
<p>Slackware users no longer have to modify the install.sh script
|
||
before installation. Tuomo Soini has provided a change that allows the
|
||
INIT and FIREWALL variables to be specified outside the script as in:<br>
|
||
<br>
|
||
DEST=/etc/rc.d INIT=rc.firewall
|
||
./install.sh</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>6/3/2004 - Shorewall 2.0.2f</b></p>
|
||
<p>Fixes one problem:</p>
|
||
<ol>
|
||
<li>
|
||
<p>Versions 2.0.2d and 2.0.2e fail to load kernel modules unless
|
||
MODULE_SUFFIX is set in shorewall.conf</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>6/2/2004 - Shorewall 2.0.2e</b></p>
|
||
<p>One problem corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p>LOG rules within an action generate two Netfilter logging rules.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>5/28/2004 - Shorewall 2.0.2d<br>
|
||
</b><br>
|
||
One problem corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p>Shorewall was checking capabilities before loading kernel
|
||
modules. Consequently, if kernel module autoloading was disabled, the
|
||
capabilities were mis-detected.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>5/21/2004 - Shorewall 2.0.2c</b></p>
|
||
<p>One problem corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p> DNAT rules with a dynamic source zone don't work properly.
|
||
When used, these rules cause the rule to be checked against ALL
|
||
input, not just input from the designated zone.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>5/18/2004 - Shorewall 2.0.2b</b> </p>
|
||
<p>Corrects two problems:</p>
|
||
<ol>
|
||
<li>
|
||
<p>Specifying a null common action in /etc/shorewall/actions (e.g.,
|
||
:REJECT) results in a startup error.</p>
|
||
</li>
|
||
<li>
|
||
<p>If /var/lib/shorewall does not exist, shorewall start fails.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>5/15/2004 - Shorewall 2.0.2a</b> </p>
|
||
<p>Corrects two problems:</p>
|
||
<ol>
|
||
<li>
|
||
<p>Temporary restore files were not being removed from
|
||
/var/lib/shorewall. These files have names of the form
|
||
'restore-nnnnn'. You can remove files that have accumulated with
|
||
the command: <br>
|
||
<br>
|
||
rm -f /var/lib/shorewall/restore-[0-9]* </p>
|
||
</li>
|
||
<li>
|
||
<p>The restore script did not load kernel modules. The result was
|
||
that after a cold load, applications like FTP and IRC DCC didn't work. <br>
|
||
<br>
|
||
To correct: <br>
|
||
<br>
|
||
1) Install 2.0.2a <br>
|
||
2) "shorewall restart" <br>
|
||
3) "shorewall save" </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>5/13/2004 - Shorewall 2.0.2</b> </p>
|
||
<p>Problems Corrected since 2.0.1</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The /etc/init.d/shorewall script
|
||
installed on Debian by install.sh failed silently due to a missing file
|
||
(/usr/share/shorewall/wait4ifup). That file is not part of the normal
|
||
Shorewall distribution and is provided by the Debian maintainer. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A meaningless warning message out of
|
||
the proxyarp file processing has been eliminated. </p>
|
||
</li>
|
||
<li>
|
||
<p>The "shorewall delete" command now correctly removes all dynamic
|
||
rules pertaining to the host(s) being deleted. Thanks to Stefan Engel
|
||
for this correction. </p>
|
||
</li>
|
||
</ol>
|
||
<p>Issues when migrating from Shorewall 2.0.1 to Shorewall 2.0.2:</p>
|
||
<ol>
|
||
<li>
|
||
<p>Extension Scripts -- In order for extension scripts to work
|
||
properly with the new iptables-save/restore integration (see New
|
||
Feature 1 below), some change may be required to your extension
|
||
scripts. If your extension scripts are executing commands other than
|
||
iptables then those commands must also be written to the restore file
|
||
(a temporary file in /var/lib/shorewall that is renamed
|
||
/var/lib/shorewall/restore-base at the end of the operation).<br>
|
||
<br>
|
||
The following functions should be of help:<br>
|
||
<br>
|
||
A. save_command() -- saves the passed command to the restore file.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
save_command echo Operation
|
||
Complete<br>
|
||
<br>
|
||
That command would simply write "echo Operation Complete"
|
||
to the restore file.<br>
|
||
<br>
|
||
B. run_and_save_command() -- saves the passed command to the restore
|
||
file then executes it. The return value is the exit status of the
|
||
command.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
run_and_save_command "echo 1 >
|
||
/proc/sys/net/ipv4/icmp_echo_ignore_all"<br>
|
||
<br>
|
||
Note that as in this example, when the command
|
||
involves file redirection then the entire command must be enclosed in
|
||
quotes. This applies to all of the functions described here.<br>
|
||
<br>
|
||
C. ensure_and_save_command() -- runs the passed command. If the command
|
||
fails, the firewall is restored to it's prior saved state and the
|
||
operation is terminated. If the command succeeds, the command is
|
||
written to the restore file.</p>
|
||
</li>
|
||
<li>
|
||
<p>Dynamic Zone support -- If you don't need to use the "shorewall
|
||
add" and "shorewall delete commands, you should set DYNAMIC_ZONES=No in
|
||
/etc/shorewall/shorewall.conf. </p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>Shorewall has now been integrated with
|
||
iptables-save/iptables-restore to provide very fast start and restart.
|
||
The elements of this integration are as follows:<br>
|
||
<br>
|
||
a) The 'shorewall save' command now saves the current configuration in
|
||
addition to the current dynamic blacklist. If you have dynamic zones,
|
||
you will want to issue 'shorewall save' when the zones are empty or the
|
||
current contents of the zones will be restored by the 'shorewall
|
||
restore' and 'shorewall -f start' commands.<br>
|
||
<br>
|
||
b) The 'shorewall restore' command has been added. This command
|
||
restores the configuration at the time of the last 'save'.<br>
|
||
<br>
|
||
c) The -f (fast) option has been added to 'shorewall start'. When
|
||
specified (e.g. 'shorewall -f start'), shorewall will perform a
|
||
'shorewall restore' if there is a saved configuration. If there is no
|
||
saved configuration, a normal 'shorewall start' is performed.<br>
|
||
<br>
|
||
d) The /etc/init.d/shorewall script now translates the 'start' command
|
||
into 'shorewall -f start' so that fast restart is possible.<br>
|
||
<br>
|
||
e) When a state-changing command encounters an error and there is
|
||
current saved configuration, that configuration will be restored
|
||
(currently, the firewall is placed in the 'stopped' state).<br>
|
||
<br>
|
||
f) If you have previously saved the running configuration and want
|
||
Shorewall to discard it, use the 'shorewall forget' command. WARNING:
|
||
iptables 1.2.9 is broken with respect to iptables-save; if your kernel
|
||
has connection tracking match support, you must patch iptables 1.2.9
|
||
with the iptables patch availale from the Shorewall errata page.</p>
|
||
</li>
|
||
<li>
|
||
<p>The previous implementation of dynamic zones was difficult to
|
||
maintain. I have changed the code to make dynamic zones optional under
|
||
the control of the DYNAMIC_ZONES option in
|
||
/etc/shorewall/shorewall.conf.</p>
|
||
</li>
|
||
<li>
|
||
<p>In earlier Shorewall 2.0 releases, Shorewall searches in order
|
||
the following directories for configuration files.<br>
|
||
<br>
|
||
a) The directory specified in a 'try' command or specified using the -c
|
||
option.<br>
|
||
b) /etc/shorewall<br>
|
||
c) /usr/share/shorewall<br>
|
||
<br>
|
||
In this release, the CONFIG_PATH option is added to shorewall.conf.
|
||
CONFIG_PATH contains a list of directory names separated by colons
|
||
(":"). If not set or set to a null value (e.g., CONFIG_PATH="") then
|
||
"CONFIG_PATH=/etc/shorewall:/usr/share/shorewall" is assumed. Now
|
||
Shorewall searches for shorewall.conf according to the old rules and
|
||
for other configuration files as follows:<br>
|
||
<br>
|
||
a) The directory specified in a 'try' command or specified using the -c
|
||
option.<br>
|
||
b) Each directory in $CONFIG_PATH is searched in sequence.<br>
|
||
<br>
|
||
In case it is not obvious, your CONFIG_PATH should include
|
||
/usr/share/shorewall and your shorewall.conf file must be in the
|
||
directory specified via -c or in a try command, in /etc/shorewall or in
|
||
/usr/share/shorewall.<br>
|
||
<br>
|
||
For distribution packagers, the default CONFIG_PATH is set in
|
||
/usr/share/shorewall/configpath. You can customize this file to have a
|
||
default that differs from mine.</p>
|
||
</li>
|
||
<li>
|
||
<p>Previously, in /etc/shorewall/nat a Yes (or yes) in the LOCAL
|
||
column would only take effect if the ALL INTERFACES column also
|
||
contained Yes or yes. Now, the LOCAL columns contents are treated
|
||
independently of the contents of the ALL INTERFACES column.</p>
|
||
</li>
|
||
<li>
|
||
<p>The folks at Mandrake have created yet another kernel module
|
||
naming convention (module names end in "ko.gz"). As a consequence,
|
||
beginning with this release, if MODULE_SUFFIX isn't specified in
|
||
shorewall.conf, then the default value is "o gz ko o.gz ko.gz".</p>
|
||
</li>
|
||
<li>
|
||
<p>An updated bogons file is included in this release.</p>
|
||
</li>
|
||
<li>
|
||
<p>In /etc/shorewall/rules and in action files generated from
|
||
/usr/share/shorewall/action.template, rules that perform logging can
|
||
specify an optional "log tag". A log tag is a string of alphanumeric
|
||
characters and is specified by following the log level with ":" and the
|
||
log tag.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
ACCEPT:info:ftp
|
||
net dmz
|
||
tcp 21<br>
|
||
<br>
|
||
The log tag is appended to the log prefix generated by the LOGPREFIX
|
||
variable in /etc/shorewall/conf. If "ACCEPT:info" generates the log
|
||
prefix "Shorewall:net2dmz:ACCEPT:" then "ACCEPT:info:ftp" will generate
|
||
"Shorewall:net2dmz:ACCEPT:ftp " (note the trailing blank). The maximum
|
||
length of a log prefix supported by iptables is 29 characters; if a
|
||
larger prefix is generated, Shorewall will issue a warning message and
|
||
will truncate the prefix to 29 characters.</p>
|
||
</li>
|
||
<li>
|
||
<p>A new "-q" option has been added to /sbin/shorewall commands. It
|
||
causes the start, restart, check and refresh commands to produce much
|
||
less output so that warning messages are more visible (when testing
|
||
this change, I discovered a bug where a bogus warning message was being
|
||
generated).</p>
|
||
</li>
|
||
<li>
|
||
<p>Shorewall now uses 'modprobe' to load kernel modules if that
|
||
utility is available in the PATH; otherwise, 'insmod' is used.</p>
|
||
</li>
|
||
<li>
|
||
<p>It is now possible to restrict entries in the
|
||
/etc/shorewall/masq file to particular protocols and destination
|
||
port(s). Two new columns (PROTO and PORT(S)) have been added to the
|
||
file.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
You want all outgoing SMTP traffic entering the firewall on eth1 to be
|
||
sent from eth0 with source IP address 206.124.146.177. You want all
|
||
other outgoing traffic from eth1 to be sent from eth0 with source IP
|
||
address 206.124.146.176.<br>
|
||
<br>
|
||
eth0
|
||
eth1 206.124.146.177 tcp 25<br>
|
||
eth0
|
||
eth1 206.124.146.176<br>
|
||
<br>
|
||
THE ORDER OF THE ABOVE TWO RULES IS SIGNIFICANT!!!!!<br>
|
||
<br>
|
||
Assuming that 10.0.0.0/8 is the only host/network connected to eth1,
|
||
the progress message at "shorewall start" would be:<br>
|
||
<br>
|
||
Masqueraded Networks and Hosts:<br>
|
||
To 0.0.0.0/0 (tcp 25) from
|
||
10.0.0.0/8 through eth0 using 206.124.146.177<br>
|
||
To 0.0.0.0/0 (all) from 10.0.0.0/8
|
||
through eth0 using 206.124.146.176</p>
|
||
</li>
|
||
<li>
|
||
<p>Two new actions are available in the /etc/shorewall/rules file.<br>
|
||
<br>
|
||
ACCEPT+ -- Behaves like ACCEPT
|
||
with the exception that it exempts matching connections from subsequent
|
||
DNAT[-] and REDIRECT[-] rules.<br>
|
||
NONAT -- Exempts
|
||
matching connections from subsequent DNAT[-] and REDIRECT[-] rules.</p>
|
||
</li>
|
||
<li>
|
||
<p>A new extension script 'initdone' has been added. This script is
|
||
invoked at the same point as the 'common' script was previously and is
|
||
useful for users who mis-used that script under Shorewall 1.x (the
|
||
script was intended for adding rules to the 'common' chain but many
|
||
users treated it as a script for adding rules before Shorewall's).</p>
|
||
</li>
|
||
<li>
|
||
<p>Installing/Upgrading Shorewall on Slackware has been improved.
|
||
Slackware users must use the tarball and must modify settings in the
|
||
install.sh script before running it as follows:<br>
|
||
<br>
|
||
DEST="/etc/rc.d"<br>
|
||
INIT="rc.firewall"<br>
|
||
<br>
|
||
Thanks to Alex Wilms for helping with this change. </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>4/17/2004 - Presentation at LinuxFest NW</b></p>
|
||
<p>Today I gave a presentation at LinuxFest NW in Bellingham. The
|
||
presentation was entitled "<a
|
||
href="http://lists.shorewall.net/Shorewall_and_the_Enterprise.htm"
|
||
target="_blank">Shorewall
|
||
and the Enterprise</a>" and described the history of Shorewall
|
||
and gave an overview of its features. </p>
|
||
<p><b>4/5/2004 - Shorewall 2.0.1</b></p>
|
||
<p>Problems Corrected since 2.0.0</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Using actions in the manner
|
||
recommended in the documentation results in a Warning that the rule is
|
||
a policy. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">When a zone on a single interface is
|
||
defined using /etc/shorewall/hosts, superfluous rules are generated in
|
||
the <zone>_frwd chain. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Thanks to Sean Mathews, a
|
||
long-standing problem with Proxy ARP and IPSEC has been corrected.
|
||
Thanks Sean!!! </p>
|
||
</li>
|
||
<li>
|
||
<p>The "shorewall show log" and "shorewall logwatch" commands
|
||
incorrectly displayed type 3 ICMP packets.</p>
|
||
</li>
|
||
</ol>
|
||
<p>Issues when migrating from Shorewall 2.0.0 to Shorewall 2.0.1:</p>
|
||
<ol>
|
||
<li>
|
||
<p>The function of 'norfc1918' is now split between that option and
|
||
a new 'nobogons' option.<br>
|
||
<br>
|
||
The rfc1918 file released with Shorewall now contains entries for only
|
||
those three address ranges reserved by RFC 1918. A 'nobogons' interface
|
||
option has been added which handles bogon source addresses (those which
|
||
are reserved by the IANA, those reserved for DHCP auto-configuration
|
||
and the class C test-net reserved for testing and documentation
|
||
examples). This will allow users to perform RFC 1918 filtering without
|
||
having to deal with out of date data from IANA. Those who are willing
|
||
to update their /usr/share/shorewall/bogons file regularly can specify
|
||
the 'nobogons' option in addition to 'norfc1918'.<br>
|
||
<br>
|
||
The level at which bogon packets are logged is specified in the new
|
||
BOGON_LOG_LEVEL variable in shorewall.conf. If that option is not
|
||
specified or is specified as empty (e.g, BOGON_LOG_LEVEL="") then bogon
|
||
packets whose TARGET is 'logdrop' in /usr/share/shorewall/bogons are
|
||
logged at the 'info' level. </p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>Support for Bridging Firewalls has been added. For details, see<br>
|
||
<br>
|
||
<a href="http://shorewall.net/bridge.html">http://shorewall.net/bridge.html</a></p>
|
||
</li>
|
||
<li>
|
||
<p>Support for NETMAP has been added. NETMAP allows NAT to be
|
||
defined between two network:<br>
|
||
<br>
|
||
|
||
a.b.c.1 -> x.y.z.1<br>
|
||
|
||
a.b.c.2 -> x.y.z.2<br>
|
||
|
||
a.b.c.3 -> x.y.z.3<br>
|
||
...<br>
|
||
<br>
|
||
<a href="http://shorewall.net/netmap.htm">http://shorewall.net/netmap.htm</a></p>
|
||
</li>
|
||
<li>
|
||
<p>The /sbin/shorewall program now accepts a "-x" option to cause
|
||
iptables to print out the actual packet and byte counts rather than
|
||
abbreviated counts such as "13MB".<br>
|
||
<br>
|
||
Commands affected by this are:<br>
|
||
<br>
|
||
|
||
shorewall -x show [ <chain>[ <chain> ...] ]<br>
|
||
|
||
shorewall -x show tos|mangle<br>
|
||
|
||
shorewall -x show nat<br>
|
||
|
||
shorewall -x status<br>
|
||
|
||
shorewall -x monitor [ <interval> ]</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall now traps two common zone
|
||
definition errors:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Including the firewall zone in a
|
||
/etc/shorewall/hosts record. </p>
|
||
</li>
|
||
<li>
|
||
<p>Defining an interface for a zone in both
|
||
/etc/shorewall/interfaces and /etc/shorewall/hosts.</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p>In the second case, the following will appear during "shorewall
|
||
[re]start" or "shorewall check":<br>
|
||
<br>
|
||
Determining Hosts in Zones...<br>
|
||
...<br>
|
||
Error: Invalid zone definition for zone
|
||
<name of zone><br>
|
||
Terminated</p>
|
||
</li>
|
||
<li>
|
||
<p>To support bridging, the following options have been added to
|
||
entries in /etc/shorewall/hosts:<br>
|
||
<br>
|
||
norfc1918<br>
|
||
nobogons<br>
|
||
blacklist<br>
|
||
tcpflags<br>
|
||
nosmurfs<br>
|
||
newnotsyn<br>
|
||
<br>
|
||
With the exception of 'newnotsyn', these options are only useful when
|
||
the entry refers to a bridge port.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
#ZONE HOST(S)
|
||
OPTIONS<br>
|
||
net
|
||
br0:eth0
|
||
norfc1918,nobogons,blacklist,tcpflags,nosmurfs </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>3/14/2004 - Shorewall 2.0.0b </b></p>
|
||
<p>Corrects two problems:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Thanks to Sean Mathews, the
|
||
long-standing problem with Proxy ARP and IPSEC has been eliminated! </p>
|
||
</li>
|
||
<li>
|
||
<p>The default value of the ALL INTERFACES column in
|
||
/etc/shorewall/nat is documented as 'No' but the default continued to
|
||
be 'Yes' as it was in Shorewall 1.4.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>3/14/2004 - Shorewall 2.0.0a </b></p>
|
||
<p>Corrects one problem:</p>
|
||
<ul>
|
||
<li>
|
||
<p>Rules of the form:<br>
|
||
<br>
|
||
<action>
|
||
zone1 zone2<br>
|
||
<br>
|
||
generated a warning stating that the rule was a policy.</p>
|
||
</li>
|
||
</ul>
|
||
<p><b>3/14/2004 - Shorewall 2.0.0 </b>
|
||
</p>
|
||
<p>Dedicated to Agnes Van Slyke Eastep: March 14, 1910 - February 23,
|
||
2004</p>
|
||
<p>Problems Corrected since 1.4.10</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A blank USER/GROUP column in
|
||
/etc/shorewall/tcrules no longer causes a [re]start error. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The 'fgrep' utility is no longer
|
||
required (caused startup problems on LEAF/Bering). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The "shorewall add" command no
|
||
longer inserts rules before checking of the blacklist. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The 'detectnets' and 'routeback'
|
||
options may now be used together with the intended effect. </p>
|
||
</li>
|
||
<li>
|
||
<p>The following syntax previously produced an error:<br>
|
||
<br>
|
||
DNAT z1!z2,z3 z4...</p>
|
||
</li>
|
||
</ol>
|
||
<p>Problems Corrected since RC2</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">CONTINUE rules now work again. </p>
|
||
</li>
|
||
<li>
|
||
<p>A comment in the rules file has been corrected.</p>
|
||
</li>
|
||
</ol>
|
||
<p>Issues when migrating from Shorewall 1.4.x to Shorewall 2.0.0:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The 'dropunclean' and 'logunclean'
|
||
interface options are no longer supported. If either option is
|
||
specified in /etc/shorewall/interfaces, an threatening message will be
|
||
generated. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The NAT_BEFORE_RULES option has been
|
||
removed from shorewall.conf. The behavior of Shorewall is as if
|
||
NAT_BEFORE_RULES=No had been specified. In other words, DNAT rules now
|
||
always take precidence over one-to-one NAT specifications. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The default value for the ALL
|
||
INTERFACES column in /etc/shorewall/nat has changed. In Shorewall 1.*,
|
||
if the column was left empty, a value of "Yes" was assumed. This has
|
||
been changed so that a value of "No" is now assumed. </p>
|
||
</li>
|
||
<li>
|
||
<p>The following files don't exist in Shorewall 2.0:<br>
|
||
/etc/shorewall/common.def<br>
|
||
/etc/shorewall/common<br>
|
||
/etc/shorewall/icmpdef<br>
|
||
/etc/shorewall/action.template (Moved to /usr/share/shorewall)<br>
|
||
/etc/shorewall/rfc1918 (Moved to /usr/share/shorewall).<br>
|
||
<br>
|
||
The /etc/shorewall/action file now allows an action to be designated as
|
||
the "common" action for a particular policy type by following the
|
||
action name with ":" and the policy (DROP, REJECT or ACCEPT).<br>
|
||
<br>
|
||
The file /usr/share/shorewall/actions.std has been added to define
|
||
those actions that are released as part of Shorewall. In that file are
|
||
two actions as follows:<br>
|
||
<br>
|
||
Drop:DROP<br>
|
||
Reject:REJECT<br>
|
||
<br>
|
||
The "Drop" action is the common action for DROP policies while the
|
||
"Reject" action is the default action for "REJECT" policies. These
|
||
actions will be performed on packets prior to applying the DROP or
|
||
REJECT policy respectively. In the first release, the difference
|
||
between "Reject" and "Drop" is that "Reject" REJECTs SMB traffic while
|
||
"Drop" silently drops such traffic.<br>
|
||
<br>
|
||
As described above, Shorewall allows a common action for ACCEPT
|
||
policies but does not specify such an action in the default
|
||
configuration.<br>
|
||
<br>
|
||
If for some reason, you don't wish to have a common DROP or REJECT
|
||
action, just include :DROP or :REJECT respectively in your
|
||
/etc/shorewall/actions file.<br>
|
||
<br>
|
||
The file /usr/share/shorewall/actions.std catalogs the standard actions
|
||
and is processed prior to /etc/shorewall/actions. This causes a large
|
||
number of actions to be defined. The files which define these aactions
|
||
are also located in /usr/share/shorewall as is the he action template
|
||
file (action.template).<br>
|
||
<br>
|
||
These actions may be used in the ACTION column of the rules column. So
|
||
for example, to allow FTP from your loc zone to your firewall, you
|
||
would place this rule in /etc/shorewall/rules:<br>
|
||
<br>
|
||
#ACTION
|
||
SOURCE DEST<br>
|
||
AllowFTP
|
||
loc
|
||
fw<br>
|
||
<br>
|
||
If you want to redefine any of the Shorewall-defined actions, simply
|
||
copy the appropriate action file from /usr/share/shorewall to
|
||
/etc/shorewall and modify the copy as desired. Your modified copy will
|
||
be used rather than the original one in /usr/share/shorewall.<br>
|
||
<br>
|
||
Note: The 'dropBcast' and 'dropNonSyn' actions are built into Shorewall
|
||
and may not be changed.<br>
|
||
<br>
|
||
Beginning with version 2.0.0-Beta2, Shorewall will only create a chain
|
||
for those actions that are actually used.</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The /etc/shorewall directory no
|
||
longer contains a 'users' file or a 'usersets' file. Similar
|
||
functionality is now available using user-defined actions.<br>
|
||
<br>
|
||
Now, action files created by copying
|
||
/usr/share/shorewall/action.template may specify a USER and or GROUP
|
||
name/id in the final column just like in the rules file (see below). It
|
||
is thus possible to create actions that control traffic from a list of
|
||
users and/or groups.<br>
|
||
<br>
|
||
The last column in /etc/shorewall/rules is now labeled USER/GROUP and
|
||
may contain:<br>
|
||
<br>
|
||
[!]<user number>[:]<br>
|
||
[!]<user name>[:]<br>
|
||
[!]:<group number><br>
|
||
[!]:<group name><br>
|
||
[!]<user number>:<group number><br>
|
||
[!]<user number>:<group name><br>
|
||
[!]<user name>:<group number><br>
|
||
[!]<user name>:<group name><br>
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>It is no longer possible to specify rate limiting in the ACTION
|
||
column of /etc/shorewall/rules -- you must use the RATE LIMIT column.</p>
|
||
</li>
|
||
<li>
|
||
<p>Depending on which method you use to upgrade, if you have your
|
||
own version of /etc/shorewall/rfc1918, you may have to take special
|
||
action to restore it after the upgrade. Look for
|
||
/etc/shorewall/rfc1918*, locate the proper file and rename it back to
|
||
/etc/shorewall/rfc1918. The contents of that file will supercede the
|
||
contents of /usr/share/shorewall/rfc1918. </p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The INCLUDE directive now allows
|
||
absolute file names. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A 'nosmurfs' interface option has
|
||
been added to /etc/shorewall/interfaces. When specified for an
|
||
interface, this option causes smurfs (packets with a broadcast address
|
||
as their source) to be dropped and optionally logged (based on the
|
||
setting of a new SMURF_LOG_LEVEL option in shorewall.conf). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">fw->fw traffic may now be
|
||
controlled by Shorewall. There is no need to define the loopback
|
||
interface in /etc/shorewall/interfaces; you simply add a fw->fw
|
||
policy and fw->fw rules. If you have neither a fw->fw policy nor
|
||
fw->fw rules, all fw->fw traffic is allowed. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">There is a new PERSISTENT column in
|
||
the proxyarp file. A value of "Yes" in this column means that the route
|
||
added by Shorewall for this host will remain after a "shorewall stop"
|
||
or "shorewall clear". </p>
|
||
</li>
|
||
<li>
|
||
<p>"trace" is now a synonym for "debug" in /sbin/shorewall
|
||
commands. So to trace the "start" command, you could enter:<br>
|
||
<br>
|
||
shorewall trace start 2> /tmp/trace<br>
|
||
<br>
|
||
The trace information would be written to the file /tmp/trace.</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">When defining an ipsec tunnel in
|
||
/etc/shorewall/tunnels, if you follow the tunnel type ("ipsec" or
|
||
"ipsecnet") with ":noah" (e.g., "ipsec:noah"), then Shorewall will only
|
||
create rules for ESP (protocol 50) and will not create rules for AH
|
||
(protocol 51). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A new DISABLE_IPV6 option has been
|
||
added to shorewall.conf. When this option is set to "Yes", Shorewall
|
||
will set the policy for the IPv6 INPUT, OUTPUT and FORWARD chains to
|
||
DROP during "shorewall [re]start" and "shorewall stop". Regardless of
|
||
the setting of this variable, "shorewall clear" will silently attempt
|
||
to set these policies to ACCEPT.<br>
|
||
<br>
|
||
If this option is not set in your existing shorewall.conf then a
|
||
setting of DISABLE_IPV6=No is assumed in which case, Shorewall will not
|
||
touch any IPv6 settings except during "shorewall clear". </p>
|
||
</li>
|
||
<li>
|
||
<p>The CONTINUE target is now available in action definitions.
|
||
CONTINUE terminates processing of the current action and returns to the
|
||
point where that action was invoked. </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>2/15/2004 - Shorewall 1.4.10c </b></p>
|
||
<p>Corrects one problem:</p>
|
||
<p>Entries in /etc/shorewall/tcrules with an empty USER/GROUP column
|
||
would cause a startup error. </p>
|
||
<p><b>2/12/2004 - Shorewall 1.4.10b </b></p>
|
||
<p>Corrects one problem:</p>
|
||
<ul>
|
||
<li>
|
||
<p>In the /etc/shorewall/masq entry “eth0:!10.1.1.150
|
||
0.0.0.0/0!10.1.0.0/16 10.1.2.16”, the
|
||
“!10.1.0.0/16” is ignored. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>2/8/2004 - Shorewall 1.4.10a </b></p>
|
||
<p>Corrects two problems:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A problem which can cause [re]start
|
||
to fail inexplicably while processing /etc/shorewall/masq. </p>
|
||
</li>
|
||
<li>
|
||
<p>Interfaces using the Atheros WiFi card to use the 'maclist'
|
||
option. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>1/30/2004 - Shorewall 1.4.10</b></p>
|
||
<p>Problems Corrected since version 1.4.9</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The column descriptions in the
|
||
action.template file did not match the column headings. That has been
|
||
corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The presence of IPV6 addresses on
|
||
devices generated error messages during [re]start if ADD_IP_ALIASES=Yes
|
||
or ADD_SNAT_ALIASES=Yes are specified in /etc/shorewall/shorewall.conf.
|
||
These messages have been eliminated. </p>
|
||
</li>
|
||
<li value="3">
|
||
<p style="margin-bottom: 0in;">The CONTINUE action in
|
||
/etc/shorewall/rules now works correctly. A couple of problems
|
||
involving rate limiting have been corrected. These bug fixes courtesy
|
||
of Steven Jan Springl. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall now tried to avoid sending
|
||
an ICMP response to broadcasts and smurfs. </p>
|
||
</li>
|
||
<li>
|
||
<p>Specifying "-" or "all" in the PROTO column of an action no
|
||
longer causes a startup error. </p>
|
||
</li>
|
||
</ol>
|
||
<p>Migragion Issues:<br>
|
||
<br>
|
||
None.<br>
|
||
<br>
|
||
New
|
||
Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>The INTERFACE column in the /etc/shorewall/masq file may now
|
||
specify a destination list. <br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
#INTERFACE
|
||
SUBNET ADDRESS<br>
|
||
eth0:192.0.2.3,192.0.2.16/28 eth1<br>
|
||
<br>
|
||
If the list begins with "!" then SNAT will occur only if the
|
||
destination IP address is NOT included in the list.</p>
|
||
</li>
|
||
<li>
|
||
<p>Output traffic control rules (those with the firewall as the
|
||
source) may now be qualified by the effective userid and/or effective
|
||
group id of the program generating the output. This feature is courtesy
|
||
of Frédéric LESPEZ.<br>
|
||
<br>
|
||
A new USER column has been added to /etc/shorewall/tcrules. It may
|
||
contain :<br>
|
||
<br>
|
||
[<user name or number>]:[<group
|
||
name or number>]<br>
|
||
<br>
|
||
The colon is optionnal when specifying only a user.<br>
|
||
<br>
|
||
Examples : john: / john / :users /
|
||
john:users</p>
|
||
</li>
|
||
<li>
|
||
<p>A "detectnets" interface option has been added for entries in
|
||
/etc/shorewall/interfaces. This option automatically taylors the
|
||
definition of the zone named in the ZONE column to include just
|
||
those hosts that have routes through the interface named in the
|
||
INTERFACE column. The named interface must be UP when Shorewall is
|
||
[re]started.<br>
|
||
<br>
|
||
WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET INTERFACE!
|
||
</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>1/27/2004 - Shorewall 1.4.10 RC3</b></p>
|
||
<p><a href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
||
<a href="ftp://shorewall.net/pub/shorewall/Beta" target="_top">ftp://shorewall.net/pub/shorewall/Beta</a></p>
|
||
<p>Problems Corrected since version 1.4.9</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The column descriptions in the
|
||
action.template file did not match the column headings. That has been
|
||
corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The presence of IPV6 addresses on
|
||
devices generated error messages during [re]start if ADD_IP_ALIASES=Yes
|
||
or ADD_SNAT_ALIASES=Yes are specified in /etc/shorewall/shorewall.conf.
|
||
These messages have been eliminated. </p>
|
||
</li>
|
||
<li value="3">
|
||
<p style="margin-bottom: 0in;">The CONTINUE action in
|
||
/etc/shorewall/rules now works correctly. A couple of problems
|
||
involving rate limiting have been corrected. These bug fixes courtesy
|
||
of Steven Jan Springl. </p>
|
||
</li>
|
||
<li>
|
||
<p>Shorewall now tried to avoid sending an ICMP response to
|
||
broadcasts and smurfs.</p>
|
||
</li>
|
||
</ol>
|
||
<p>Migragion Issues:<br>
|
||
<br>
|
||
None.<br>
|
||
<br>
|
||
New
|
||
Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>The INTERFACE column in the /etc/shorewall/masq file may now
|
||
specify a destination list. <br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
#INTERFACE
|
||
SUBNET ADDRESS<br>
|
||
eth0:192.0.2.3,192.0.2.16/28 eth1<br>
|
||
<br>
|
||
If the list begins with "!" then SNAT will occur only if the
|
||
destination IP address is NOT included in the list.</p>
|
||
</li>
|
||
<li>
|
||
<p>Output traffic control rules (those with the firewall as the
|
||
source) may now be qualified by the effective userid and/or effective
|
||
group id of the program generating the output. This feature is courtesy
|
||
of Frédéric LESPEZ.<br>
|
||
<br>
|
||
A new USER column has been added to /etc/shorewall/tcrules. It may
|
||
contain :<br>
|
||
<br>
|
||
[<user name or number>]:[<group
|
||
name or number>]<br>
|
||
<br>
|
||
The colon is optionnal when specifying only a user.<br>
|
||
<br>
|
||
Examples : john: / john / :users /
|
||
john:users</p>
|
||
</li>
|
||
<li>
|
||
<p>A "detectnets" interface option has been added for entries in
|
||
/etc/shorewall/interfaces. This option automatically taylors the
|
||
definition of the zone named in the ZONE column to include just
|
||
those hosts that have routes through the interface named in the
|
||
INTERFACE column. The named interface must be UP when Shorewall is
|
||
[re]started.<br>
|
||
<br>
|
||
WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET INTERFACE!
|
||
</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>1/24/2004 - Shorewall 1.4.10 RC2</b> </p>
|
||
<p><a href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
||
<a href="ftp://shorewall.net/pub/shorewall/Beta" target="_top">ftp://shorewall.net/pub/shorewall/Beta</a></p>
|
||
<p>Problems Corrected since version 1.4.9</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The column descriptions in the
|
||
action.template file did not match the column headings. That has been
|
||
corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p>The presence of IPV6 addresses on devices generated error
|
||
messages during [re]start if ADD_IP_ALIASES=Yes or ADD_SNAT_ALIASES=Yes
|
||
are specified in /etc/shorewall/shorewall.conf. These messages have
|
||
been eliminated. </p>
|
||
</li>
|
||
</ol>
|
||
<p>Migragion Issues:<br>
|
||
<br>
|
||
None.<br>
|
||
<br>
|
||
New
|
||
Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>The INTERFACE column in the /etc/shorewall/masq file may now
|
||
specify a destination list. <br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
#INTERFACE
|
||
SUBNET ADDRESS<br>
|
||
eth0:192.0.2.3,192.0.2.16/28 eth1<br>
|
||
<br>
|
||
If the list begins with "!" then SNAT will occur only if the
|
||
destination IP address is NOT included in the list.</p>
|
||
</li>
|
||
<li>
|
||
<p>Output traffic control rules (those with the firewall as the
|
||
source) may now be qualified by the effective userid and/or effective
|
||
group id of the program generating the output. This feature is courtesy
|
||
of Frédéric LESPEZ.<br>
|
||
<br>
|
||
A new USER column has been added to /etc/shorewall/tcrules. It may
|
||
contain :<br>
|
||
<br>
|
||
[<user name or number>]:[<group
|
||
name or number>]<br>
|
||
<br>
|
||
The colon is optionnal when specifying only a user.<br>
|
||
<br>
|
||
Examples : john: / john / :users /
|
||
john:users</p>
|
||
</li>
|
||
<li>
|
||
<p>A "detectnets" interface option has been added for entries in
|
||
/etc/shorewall/interfaces. This option automatically taylors the
|
||
definition of the zone named in the ZONE column to include just
|
||
those hosts that have routes through the interface named in the
|
||
INTERFACE column. The named interface must be UP when Shorewall is
|
||
[re]started.<br>
|
||
<br>
|
||
WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET INTERFACE! </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>1/22/2004 - Shorewall 1.4.10 RC1</b> </p>
|
||
<p>Problems Corrected since version 1.4.9</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The column descriptions in the
|
||
action.template file did not match the column headings. That has been
|
||
corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p>The presence of IPV6 addresses on devices generated error
|
||
messages during [re]start if ADD_IP_ALIASES=Yes or ADD_SNAT_ALIASES=Yes
|
||
are specified in /etc/shorewall/shorewall.conf. These messages have
|
||
been eliminated. </p>
|
||
</li>
|
||
</ol>
|
||
<p>Migragion Issues:<br>
|
||
<br>
|
||
None.<br>
|
||
<br>
|
||
New
|
||
Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>The INTERFACE column in the /etc/shorewall/masq file may now
|
||
specify a destination list. <br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
#INTERFACE
|
||
SUBNET ADDRESS<br>
|
||
eth0:192.0.2.3,192.0.2.16/28 eth1<br>
|
||
<br>
|
||
If the list begins with "!" then SNAT will occur only if the
|
||
destination IP address is NOT included in the list.</p>
|
||
</li>
|
||
<li>
|
||
<p>Output traffic control rules (those with the firewall as the
|
||
source) may now be qualified by the effective userid and/or effective
|
||
group id of the program generating the output. This feature is courtesy
|
||
of Frédéric LESPEZ.<br>
|
||
<br>
|
||
A new USER column has been added to /etc/shorewall/tcrules. It may
|
||
contain :<br>
|
||
<br>
|
||
[<user name or number>]:[<group
|
||
name or number>]<br>
|
||
<br>
|
||
The colon is optionnal when specifying only a user.<br>
|
||
<br>
|
||
Examples : john: / john / :users /
|
||
john:users </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>1/13/2004 - Shorewall 1.4.9</b></p>
|
||
<p>Problems Corrected since version 1.4.8:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">There has been a low continuing
|
||
level of confusion over the terms "Source NAT" (SNAT) and "Static NAT".
|
||
To avoid future confusion, all instances of "Static NAT" have been
|
||
replaced with "One-to-one NAT" in the documentation and configuration
|
||
files. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The description of NEWNOTSYN in
|
||
shorewall.conf has been reworded for clarity. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Wild-card rules (those involving
|
||
"all" as SOURCE or DEST) will no longer produce an error if they
|
||
attempt to add a rule that would override a NONE policy. The logic for
|
||
expanding these wild-card rules now simply skips those (SOURCE,DEST)
|
||
pairs that have a NONE policy. </p>
|
||
</li>
|
||
<li>
|
||
<p>DNAT rules that also specified SNAT now work reliably.
|
||
Previously, there were cases where the SNAT specification was
|
||
effectively ignored. </p>
|
||
</li>
|
||
</ol>
|
||
<p>Migration Issues:<br>
|
||
<br>
|
||
None.<br>
|
||
<br>
|
||
New
|
||
Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The documentation has been
|
||
completely rebased to Docbook XML. The documentation is now released as
|
||
separate HTML and XML packages. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">To cut down on the number of "Why
|
||
are these ports closed rather than stealthed?" questions, the
|
||
SMB-related rules in /etc/shorewall/common.def have been changed from
|
||
'reject' to 'DROP'. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">For easier identification, packets
|
||
logged under the 'norfc1918' interface option are now logged out of
|
||
chains named 'rfc1918'. Previously, such packets were logged under
|
||
chains named 'logdrop'. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Distributors and developers seem to
|
||
be regularly inventing new naming conventions for kernel modules. To
|
||
avoid the need to change Shorewall code for each new convention, the
|
||
MODULE_SUFFIX option has been added to shorewall.conf. MODULE_SUFFIX
|
||
may be set to the suffix for module names in your particular
|
||
distribution. If MODULE_SUFFIX is not set in shorewall.conf, Shorewall
|
||
will use the list "o gz ko o.gz".<br>
|
||
<br>
|
||
To see what suffix is used by your distribution:<br>
|
||
<br>
|
||
ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter<br>
|
||
<br>
|
||
All of the files listed should have the same suffix (extension). Set
|
||
MODULE_SUFFIX to that suffix.<br>
|
||
<br>
|
||
Examples:<br>
|
||
<br>
|
||
If all files end in ".kzo" then set
|
||
MODULE_SUFFIX="kzo"<br>
|
||
If all files end in ".kz.o" then set
|
||
MODULE_SUFFIX="kz.o" </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Support for user defined rule
|
||
ACTIONS has been implemented through two new files:<br>
|
||
<br>
|
||
/etc/shorewall/actions - used to list the user-defined ACTIONS.<br>
|
||
/etc/shorewall/action.template - For each user defined <action>,
|
||
copy this file to /etc/shorewall/action.<action> and add the
|
||
appropriate rules for that <action>. Once an <action> has
|
||
been defined, it may be used like any of the builtin ACTIONS (ACCEPT,
|
||
DROP, etc.) in /etc/shorewall/rules.<br>
|
||
<br>
|
||
Example: You want an action that logs a packet at the 'info' level and
|
||
accepts the connection.<br>
|
||
<br>
|
||
In /etc/shorewall/actions, you would add:<br>
|
||
<br>
|
||
LogAndAccept<br>
|
||
<br>
|
||
You would then copy /etc/shorewall/action.template to
|
||
/etc/shorewall/action.LogAndAccept and in that file, you would add the
|
||
two rules:<br>
|
||
LOG:info<br>
|
||
ACCEPT </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The default value for NEWNOTSYN in
|
||
shorewall.conf is now "Yes" (non-syn TCP packets that are not part of
|
||
an existing connection are filtered according to the rules and policies
|
||
rather than being dropped). I have made this change for two reasons:<br>
|
||
<br>
|
||
a) NEWNOTSYN=No tends to result in lots of "stuck" connections since
|
||
any timeout during TCP session tear down results in the firewall
|
||
dropping all of the retries.<br>
|
||
<br>
|
||
b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in
|
||
lots of confusing messages when a connection got "stuck". While I could
|
||
have changed the default value of LOGNEWNOTSYN to suppress logging, I
|
||
dislike defaults that silently throw away packets. </p>
|
||
</li>
|
||
<li>
|
||
<p>The common.def file now contains an entry that silently drops
|
||
ICMP packets with a null source address. Ad Koster reported a case
|
||
where these were occuring frequently as a result of a broken system on
|
||
his external network. </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>12/29/2003 - Shorewall 1.4.9 Beta 2</b> </p>
|
||
<p style="margin-left: 0.42in;"><a
|
||
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
||
<a href="ftp://shorewall.net/pub/shorewall/Beta" target="_top">ftp://shorewall.net/pub/shorewall/Beta</a>
|
||
</p>
|
||
<p>Problems Corrected since version 1.4.8:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">There has been a low continuing
|
||
level of confusion over the terms "Source NAT" (SNAT) and "Static NAT".
|
||
To avoid future confusion, all instances of "Static NAT" have been
|
||
replaced with "One-to-one NAT" in the documentation and configuration
|
||
files. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The description of NEWNOTSYN in
|
||
shorewall.conf has been reworded for clarity. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Wild-card rules (those involving
|
||
"all" as SOURCE or DEST) will no longer produce an error if they
|
||
attempt to add a rule that would override a NONE policy. The logic for
|
||
expanding these wild-card rules now simply skips those (SOURCE,DEST)
|
||
pairs that have a NONE policy. </p>
|
||
</li>
|
||
<li>
|
||
<p>DNAT rules that also specified SNAT now work reliably.
|
||
Previously, there were cases where the SNAT specification was
|
||
effectively ignored.</p>
|
||
</li>
|
||
</ol>
|
||
<p>Migration Issues:</p>
|
||
<p> None.<br>
|
||
<br>
|
||
New Features: </p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The documentation has been
|
||
completely rebased to Docbook XML. The documentation is now released as
|
||
separate HTML and XML packages.</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">To cut down on the number of "Why
|
||
are these ports closed rather than stealthed?" questions, the
|
||
SMB-related rules in /etc/shorewall/common.def have been changed from
|
||
'reject' to 'DROP'. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">For easier identification, packets
|
||
logged under the 'norfc1918' interface option are now logged out of
|
||
chains named 'rfc1918'. Previously, such packets were logged under
|
||
chains named 'logdrop'. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Distributors and developers seem to
|
||
be regularly inventing new naming conventions for kernel modules. To
|
||
avoid the need to change Shorewall code for each new convention, the
|
||
MODULE_SUFFIX option has been added to shorewall.conf. MODULE_SUFFIX
|
||
may be set to the suffix for module names in your particular
|
||
distribution. If MODULE_SUFFIX is not set in shorewall.conf, Shorewall
|
||
will use the list "o gz ko o.gz".<br>
|
||
<br>
|
||
To see what suffix is used by your distribution:<br>
|
||
<br>
|
||
ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter<br>
|
||
<br>
|
||
All of the files listed should have the same suffix (extension). Set
|
||
MODULE_SUFFIX to that suffix.<br>
|
||
<br>
|
||
Examples:<br>
|
||
<br>
|
||
If all files end in ".kzo" then set
|
||
MODULE_SUFFIX="kzo"<br>
|
||
If all files end in ".kz.o" then set
|
||
MODULE_SUFFIX="kz.o" </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Support for user defined rule
|
||
ACTIONS has been implemented through two new files:<br>
|
||
<br>
|
||
/etc/shorewall/actions - used to list the user-defined ACTIONS.<br>
|
||
/etc/shorewall/action.template - For each user defined <action>,
|
||
copy this file to /etc/shorewall/action.<action> and add the
|
||
appropriate rules for that <action>. Once an <action> has
|
||
been defined, it may be used like any of the builtin ACTIONS (ACCEPT,
|
||
DROP, etc.) in /etc/shorewall/rules.<br>
|
||
<br>
|
||
Example: You want an action that logs a packet at the 'info' level and
|
||
accepts the connection.<br>
|
||
<br>
|
||
In /etc/shorewall/actions, you would add:<br>
|
||
<br>
|
||
LogAndAccept<br>
|
||
<br>
|
||
You would then copy /etc/shorewall/action.template to
|
||
/etc/shorewall/action.LogAndAccept and in that file, you would add the
|
||
two rules:<br>
|
||
LOG:info<br>
|
||
ACCEPT</p>
|
||
</li>
|
||
<li>
|
||
<p>The default value for NEWNOTSYN in shorewall.conf is now "Yes"
|
||
(non-syn TCP packets that are not part of an existing connection are
|
||
filtered according to the rules and policies rather than being
|
||
dropped). I have made this change for two reasons:<br>
|
||
<br>
|
||
a) NEWNOTSYN=No tends to result in lots of "stuck" connections since
|
||
any timeout during TCP session tear down results in the firewall
|
||
dropping all of the retries.<br>
|
||
<br>
|
||
b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in
|
||
lots of confusing messages when a connection got "stuck". While I could
|
||
have changed the default value of LOGNEWNOTSYN to suppress logging, I
|
||
dislike defaults that silently throw away packets.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>12/28/2003 - www.shorewall.net/ftp.shorewall.net Back On-line</b>
|
||
</p>
|
||
<p>Our high-capacity server has been restored to service -- please
|
||
let <a href="mailto:webmaster@shorewall.net">us</a> know if you find
|
||
any problems.</p>
|
||
<p><b>12/29/2003 - Shorewall 1.4.9 Beta 1</b> </p>
|
||
<p style="margin-left: 0.42in;"><a
|
||
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
||
<a href="ftp://shorewall.net/pub/shorewall/Beta" target="_top">ftp://shorewall.net/pub/shorewall/Beta</a>
|
||
</p>
|
||
<p>Problems Corrected since version 1.4.8:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">There has been a low continuing
|
||
level of confusion over the terms "Source NAT" (SNAT) and "Static NAT".
|
||
To avoid future confusion, all instances of "Static NAT" have been
|
||
replaced with "One-to-one NAT" in the documentation and configuration
|
||
files. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The description of NEWNOTSYN in
|
||
shorewall.conf has been reworded for clarity. </p>
|
||
</li>
|
||
<li>
|
||
<p>Wild-card rules (those involving "all" as SOURCE or DEST) will
|
||
no longer produce an error if they attempt to add a rule that would
|
||
override a NONE policy. The logic for expanding these wild-card rules
|
||
now simply skips those (SOURCE,DEST) pairs that have a NONE policy. </p>
|
||
</li>
|
||
</ol>
|
||
<p>Migration Issues:</p>
|
||
<p> None.<br>
|
||
<br>
|
||
New Features: </p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">To cut down on the number of "Why
|
||
are these ports closed rather than stealthed?" questions, the
|
||
SMB-related rules in /etc/shorewall/common.def have been changed from
|
||
'reject' to 'DROP'. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">For easier identification, packets
|
||
logged under the 'norfc1918' interface option are now logged out of
|
||
chains named 'rfc1918'. Previously, such packets were logged under
|
||
chains named 'logdrop'. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Distributors and developers seem to
|
||
be regularly inventing new naming conventions for kernel modules. To
|
||
avoid the need to change Shorewall code for each new convention, the
|
||
MODULE_SUFFIX option has been added to shorewall.conf. MODULE_SUFFIX
|
||
may be set to the suffix for module names in your particular
|
||
distribution. If MODULE_SUFFIX is not set in shorewall.conf, Shorewall
|
||
will use the list "o gz ko o.gz".<br>
|
||
<br>
|
||
To see what suffix is used by your distribution:<br>
|
||
<br>
|
||
ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter<br>
|
||
<br>
|
||
All of the files listed should have the same suffix (extension). Set
|
||
MODULE_SUFFIX to that suffix.<br>
|
||
<br>
|
||
Examples:<br>
|
||
<br>
|
||
If all files end in ".kzo" then set
|
||
MODULE_SUFFIX="kzo"<br>
|
||
If all files end in ".kz.o" then set
|
||
MODULE_SUFFIX="kz.o" </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Support for user defined rule
|
||
ACTIONS has been implemented through two new files:<br>
|
||
<br>
|
||
/etc/shorewall/actions - used to list the user-defined ACTIONS.<br>
|
||
/etc/shorewall/action.template - For each user defined <action>,
|
||
copy this file to /etc/shorewall/action.<action> and add the
|
||
appropriate rules for that <action>. Once an <action> has
|
||
been defined, it may be used like any of the builtin ACTIONS (ACCEPT,
|
||
DROP, etc.) in /etc/shorewall/rules.<br>
|
||
<br>
|
||
Example: You want an action that logs a packet at the 'info' level and
|
||
accepts the connection.<br>
|
||
<br>
|
||
In /etc/shorewall/actions, you would add:<br>
|
||
<br>
|
||
LogAndAccept<br>
|
||
<br>
|
||
You would then copy /etc/shorewall/action.template to
|
||
/etc/shorewall/action.LogAndAccept and in that file, you would add the
|
||
two rules:<br>
|
||
LOG:info<br>
|
||
ACCEPT</p>
|
||
</li>
|
||
<li>
|
||
<p>The default value for NEWNOTSYN in shorewall.conf is now "Yes"
|
||
(non-syn TCP packets that are not part of an existing connection are
|
||
filtered according to the rules and policies rather than being
|
||
dropped). I have made this change for two reasons:<br>
|
||
<br>
|
||
a) NEWNOTSYN=No tends to result in lots of "stuck" connections since
|
||
any timeout during TCP session tear down results in the firewall
|
||
dropping all of the retries.<br>
|
||
<br>
|
||
b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in
|
||
lots of confusing messages when a connection got "stuck". While I could
|
||
have changed the default value of LOGNEWNOTSYN to suppress logging, I
|
||
dislike defaults that silently throw away packets. </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>12/03/2003 - Support Torch Passed</b></p>
|
||
<p>Effective today, I am reducing my participation in the day-to-day
|
||
support of Shorewall. As part of this shift to community-based
|
||
Shorewall support a new <a
|
||
href="https://lists.shorewall.net/mailman/listinfo/shorewall-newbies">Shorewall
|
||
Newbies mailing list</a> has been established to field questions and
|
||
problems from new users. I will not monitor that list personally. I
|
||
will continue my active development of Shorewall and will be
|
||
available via the development list to handle development issues --
|
||
Tom. </p>
|
||
<p><b>11/07/2003 - Shorewall 1.4.8<br>
|
||
<br>
|
||
</b>Problems Corrected
|
||
since version 1.4.7:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Tuomo Soini has supplied a
|
||
correction to a problem that occurs using some versions of 'ash'. The
|
||
symptom is that "shorewall start" fails with:<br>
|
||
<br>
|
||
local: --limit: bad variable name<br>
|
||
iptables v1.2.8: Couldn't load match
|
||
`-j':/lib/iptables/libipt_-j.so:<br>
|
||
cannot open shared object file: No such file or directory<br>
|
||
Try `iptables -h' or 'iptables --help' for more
|
||
information. </p>
|
||
</li>
|
||
<li>
|
||
<p>Andres Zhoglo has supplied a correction that avoids trying to
|
||
use the multiport match iptables facility on ICMP rules.<br>
|
||
<br>
|
||
Example of rule that previously caused "shorewall start"
|
||
to fail:<br>
|
||
<br>
|
||
|
||
ACCEPT loc $FW
|
||
icmp 0,8,11,12</p>
|
||
</li>
|
||
<li>
|
||
<p>Previously, if the following error message was issued, Shorewall
|
||
was left in an inconsistent state.<br>
|
||
<br>
|
||
Error: Unable to determine the routes through interface xxx</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Handling of the LOGUNCLEAN option in
|
||
shorewall.conf has been corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">In Shorewall 1.4.2, an optimization
|
||
was added. This optimization involved creating a chain named
|
||
"<zone>_frwd" for most zones defined using the
|
||
/etc/shorewall/hosts file. It has since been discovered that in many
|
||
cases these new chains contain redundant rules and that the
|
||
"optimization" turns out to be less than optimal. The implementation
|
||
has now been corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">When the MARK value in a tcrules
|
||
entry is followed by ":F" or ":P", the ":F" or ":P" was previously only
|
||
applied to the first Netfilter rule generated by the entry. It is now
|
||
applied to all entries. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">An incorrect comment concerning
|
||
Debian's use of the SUBSYSLOCK option has been removed from
|
||
shorewall.conf. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Previously, neither the
|
||
'routefilter' interface option nor the ROUTE_FILTER parameter were
|
||
working properly. This has been corrected (thanks to Eric Bowles for
|
||
his analysis and patch). The definition of the ROUTE_FILTER option has
|
||
changed however. Previously, ROUTE_FILTER=Yes was documented as
|
||
enabling route filtering on all interfaces (which didn't work).
|
||
Beginning with this release, setting ROUTE_FILTER=Yes will enable route
|
||
filtering of all interfaces brought up while Shorewall is started. As a
|
||
consequence, ROUTE_FILTER=Yes can coexist with the use of the
|
||
'routefilter' option in the interfaces file. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">If MAC verification was enabled on
|
||
an interface with a /32 address and a broadcast address then an error
|
||
would occur during startup. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The NONE policy's intended use is to
|
||
suppress the generating of rules that can't possibly be traversed. This
|
||
means that a policy of NONE is inappropriate where the source or
|
||
destination zone is $FW or "all". Shorewall now generates an error
|
||
message if such a policy is given in /etc/shorewall/policy. Previously
|
||
such a policy caused "shorewall start" to fail. </p>
|
||
</li>
|
||
<li>
|
||
<p>The 'routeback' option was broken for wildcard interfaces (e.g.,
|
||
"tun+"). This has been corrected so that 'routeback' now works as
|
||
expected in this case.</p>
|
||
</li>
|
||
</ol>
|
||
<p>Migration Issues:</p>
|
||
<ol>
|
||
<li>
|
||
<p>The definition of the ROUTE_FILTER option in shorewall.conf has
|
||
changed as described in item 8) above.</p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A new QUEUE action has been
|
||
introduced for rules. QUEUE allows you to pass connection requests to a
|
||
user-space filter such as ftwall (http://p2pwall.sourceforge.net). The
|
||
ftwall program allows for effective filtering of p2p applications such
|
||
as Kazaa. For example, to use ftwall to filter P2P clients in the 'loc'
|
||
zone, you would add the following rules:<br>
|
||
<br>
|
||
QUEUE loc
|
||
net tcp<br>
|
||
QUEUE loc
|
||
net udp<br>
|
||
QUEUE loc
|
||
fw udp<br>
|
||
<br>
|
||
You would normally want to place those three rules BEFORE any ACCEPT
|
||
rules for loc->net udp or tcp.<br>
|
||
<br>
|
||
Note: When the protocol specified is TCP ("tcp", "TCP" or "6"),
|
||
Shorewall will only pass connection requests (SYN packets) to user
|
||
space. This is for compatibility with ftwall. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A BLACKLISTNEWNONLY option has been
|
||
added to shorewall.conf. When this option is set to "Yes", the
|
||
blacklists (dynamic and static) are only consulted for new connection
|
||
requests. When set to "No" (the default if the variable is not set),
|
||
the blacklists are consulted on every packet.<br>
|
||
<br>
|
||
Setting this option to "No" allows blacklisting to stop existing
|
||
connections from a newly blacklisted host but is more expensive in
|
||
terms of packet processing time. This is especially true if the
|
||
blacklists contain a large number of entries. </p>
|
||
</li>
|
||
<li>
|
||
<p>Chain names used in the /etc/shorewall/accounting file may now
|
||
begin with a digit ([0-9]) and may contain embedded dashes ("-"). </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>10/30/2003 - Shorewall 1.4.8 RC1</b></p>
|
||
<p>Given the small number of new features and the relatively few
|
||
lines of code that were changed, there will be no Beta for 1.4.8.</p>
|
||
<p><b><a href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
||
<a href="ftp://shorewall.net/pub/shorewall/Beta" target="_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
|
||
<br>
|
||
</b>Problems
|
||
Corrected since version 1.4.7:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Tuomo Soini has supplied a
|
||
correction to a problem that occurs using some versions of 'ash'. The
|
||
symptom is that "shorewall start" fails with:<br>
|
||
<br>
|
||
local: --limit: bad variable name<br>
|
||
iptables v1.2.8: Couldn't load match
|
||
`-j':/lib/iptables/libipt_-j.so:<br>
|
||
cannot open shared object file: No such file or directory<br>
|
||
Try `iptables -h' or 'iptables --help' for more
|
||
information. </p>
|
||
</li>
|
||
<li>
|
||
<p>Andres Zhoglo has supplied a correction that avoids trying to
|
||
use the multiport match iptables facility on ICMP rules.<br>
|
||
<br>
|
||
Example of rule that previously caused "shorewall start"
|
||
to fail:<br>
|
||
<br>
|
||
|
||
ACCEPT loc $FW
|
||
icmp 0,8,11,12</p>
|
||
</li>
|
||
<li>
|
||
<p>Previously, if the following error message was issued, Shorewall
|
||
was left in an inconsistent state.<br>
|
||
<br>
|
||
Error: Unable to determine the routes through interface xxx</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Handling of the LOGUNCLEAN option in
|
||
shorewall.conf has been corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">In Shorewall 1.4.2, an optimization
|
||
was added. This optimization involved creating a chain named
|
||
"<zone>_frwd" for most zones defined using the
|
||
/etc/shorewall/hosts file. It has since been discovered that in many
|
||
cases these new chains contain redundant rules and that the
|
||
"optimization" turns out to be less than optimal. The implementation
|
||
has now been corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">When the MARK value in a tcrules
|
||
entry is followed by ":F" or ":P", the ":F" or ":P" was previously only
|
||
applied to the first Netfilter rule generated by the entry. It is now
|
||
applied to all entries. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">An incorrect comment concerning
|
||
Debian's use of the SYBSYSLOCK option has been removed from
|
||
shorewall.conf. </p>
|
||
</li>
|
||
<li>
|
||
<p>Previously, neither the 'routefilter' interface option nor the
|
||
ROUTE_FILTER parameter were working properly. This has been corrected
|
||
(thanks to Eric Bowles for his analysis and patch). The definition of
|
||
the ROUTE_FILTER option has changed however. Previously,
|
||
ROUTE_FILTER=Yes was documented as enabling route filtering on all
|
||
interfaces (which didn't work). Beginning with this release, setting
|
||
ROUTE_FILTER=Yes will enable route filtering of all interfaces brought
|
||
up while Shorewall is started. As a consequence, ROUTE_FILTER=Yes can
|
||
coexist with the use of the 'routefilter' option in the interfaces
|
||
file. </p>
|
||
</li>
|
||
</ol>
|
||
<p>Migration Issues:</p>
|
||
<ol>
|
||
<li>
|
||
<p>The definition of the ROUTE_FILTER option in shorewall.conf has
|
||
changed as described in item 8) above.</p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A new QUEUE action has been
|
||
introduced for rules. QUEUE allows you to pass connection requests to a
|
||
user-space filter such as ftwall (http://p2pwall.sourceforge.net). The
|
||
ftwall program allows for effective filtering of p2p applications such
|
||
as Kazaa. For example, to use ftwall to filter P2P clients in the 'loc'
|
||
zone, you would add the following rules:<br>
|
||
<br>
|
||
QUEUE loc
|
||
net tcp<br>
|
||
QUEUE loc
|
||
net udp<br>
|
||
QUEUE loc
|
||
fw udp<br>
|
||
<br>
|
||
You would normally want to place those three rules BEFORE any ACCEPT
|
||
rules for loc->net udp or tcp.<br>
|
||
<br>
|
||
Note: When the protocol specified is TCP ("tcp", "TCP" or "6"),
|
||
Shorewall will only pass connection requests (SYN packets) to user
|
||
space. This is for compatibility with ftwall. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A BLACKLISTNEWNONLY option has been
|
||
added to shorewall.conf. When this option is set to "Yes", the
|
||
blacklists (dynamic and static) are only consulted for new connection
|
||
requests. When set to "No" (the default if the variable is not set),
|
||
the blacklists are consulted on every packet.<br>
|
||
<br>
|
||
Setting this option to "No" allows blacklisting to stop existing
|
||
connections from a newly blacklisted host but is more expensive in
|
||
terms of packet processing time. This is especially true if the
|
||
blacklists contain a large number of entries. </p>
|
||
</li>
|
||
<li>
|
||
<p>Chain names used in the /etc/shorewall/accounting file may now
|
||
begin with a digit ([0-9]) and may contain embedded dashes ("-").</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>10/26/2003 - Shorewall 1.4.7a and 1.4.7b win brown paper bag
|
||
awards</b> <font color="#000000"><img src="images/j0233056.gif"
|
||
name="graphics1" align="middle" border="1" height="80" width="50"></font><b>Shorewall
|
||
1.4.7c released.</b></p>
|
||
<ol>
|
||
<li>
|
||
<p>The saga with "<zone>_frwd" chains continues. The 1.4.7c
|
||
script produces a ruleset that should work for everyone even if it is
|
||
not quite optimal. My apologies for this ongoing mess.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>10/24/2003 - Shorewall 1.4.7b</b></p>
|
||
<p>This is a bugfx rollup of the 1.4.7a fixes plus:</p>
|
||
<ol>
|
||
<li>
|
||
<p>The fix for problem 5 in 1.4.7a was wrong with the result that
|
||
"<zone>_frwd" chains might contain too few rules. That wrong code
|
||
is corrected in this release.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>10/21/2003 - Shorewall 1.4.7a</b></p>
|
||
<p>This is a bugfix rollup of the following problem corrections:</p>
|
||
<ol>
|
||
<li>
|
||
<p>Tuomo Soini has supplied a correction to a problem that occurs
|
||
using some versions of 'ash'. The symptom is that "shorewall start"
|
||
fails with:<br>
|
||
<br>
|
||
local: --limit: bad variable name<br>
|
||
iptables v1.2.8: Couldn't load match
|
||
`-j':/lib/iptables/libipt_-j.so:<br>
|
||
cannot open shared object file: No such file or directory<br>
|
||
Try `iptables -h' or 'iptables --help' for more
|
||
information.</p>
|
||
</li>
|
||
<li>
|
||
<p>Andres Zhoglo has supplied a correction that avoids trying to
|
||
use the multiport match iptables facility on ICMP rules.<br>
|
||
<br>
|
||
Example of rule that previously caused "shorewall start"
|
||
to fail:<br>
|
||
<br>
|
||
|
||
ACCEPT loc $FW
|
||
icmp 0,8,11,12</p>
|
||
</li>
|
||
<li>
|
||
<p>Previously, if the following error message was issued, Shorewall
|
||
was left in an inconsistent state.<br>
|
||
<br>
|
||
Error: Unable to determine the routes through interface xxx</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Handling of the LOGUNCLEAN option in
|
||
shorewall.conf has been corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">In Shorewall 1.4.2, an optimization
|
||
was added. This optimization involved creating a chain named
|
||
"<zone>_frwd" for most zones defined using the
|
||
/etc/shorewall/hosts file. It has since been discovered that in many
|
||
cases these new chains contain redundant rules and that the
|
||
"optimization" turns out to be less than optimal. The implementation
|
||
has now been corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p>When the MARK value in a tcrules entry is followed by ":F" or
|
||
":P", the ":F" or ":P" was previously only applied to the first
|
||
Netfilter rule generated by the entry. It is now applied to all entries.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>10/06/2003 - Shorewall 1.4.7</b></p>
|
||
<p><b>Problems Corrected since version 1.4.6 (Those in bold font were
|
||
corrected since 1.4.7 RC2).</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected problem in 1.4.6 where the
|
||
MANGLE_ENABLED variable was being tested before it was set. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected handling of MAC addresses
|
||
in the SOURCE column of the tcrules file. Previously, these addresses
|
||
resulted in an invalid iptables command. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The "shorewall stop" command is now
|
||
disabled when /etc/shorewall/startup_disabled exists. This prevents
|
||
people from shooting themselves in the foot prior to having configured
|
||
Shorewall. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A change introduced in version 1.4.6
|
||
caused error messages during "shorewall [re]start" when
|
||
ADD_IP_ALIASES=Yes and ip addresses were being added to a PPP
|
||
interface; the addresses were successfully added in spite of the
|
||
messages.<br>
|
||
<br>
|
||
The firewall script has been modified to eliminate the error messages </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Interface-specific dynamic
|
||
blacklisting chains are now displayed by "shorewall monitor" on the
|
||
"Dynamic Chains" page (previously named "Dynamic Chain"). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Thanks to Henry Yang, LOGRATE and
|
||
LOGBURST now work again. </p>
|
||
</li>
|
||
<li value="7">
|
||
<p style="margin-bottom: 0in;">The 'shorewall reject' and
|
||
'shorewall drop' commands now delete any existing rules for the subject
|
||
IP address before adding a new DROP or REJECT rule. Previously, there
|
||
could be many rules for the same IP address in the dynamic chain so
|
||
that multiple 'allow' commands were required to re-enable traffic
|
||
to/from the address. </p>
|
||
</li>
|
||
<li>
|
||
<p>When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following entry
|
||
in /etc/shorewall/masq resulted in a startup error:<br>
|
||
<br>
|
||
eth0 eth1
|
||
206.124.146.20-206.124.146.24</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall previously choked over
|
||
IPV6 addresses configured on interfaces in contexts where Shorewall
|
||
needed to detect something about the interface (such as when "detect"
|
||
appears in the BROADCAST column of the /etc/shorewall/interfaces file).
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall will now load module files
|
||
that are formed from the module name by appending ".o.gz". </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">When Shorewall adds a route to a
|
||
proxy ARP host and such a route already exists, two routes resulted
|
||
previously. This has been corrected so that the existing route is
|
||
replaced if it already exists. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The rfc1918 file has been updated to
|
||
reflect recent allocations. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The documentation of the USER SET
|
||
column in the rules file has been corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p>If there is no policy defined for the zones specified in a rule,
|
||
the firewall script previously encountered a shell syntax error:<br>
|
||
<br>
|
||
[: NONE: unexpected operator<br>
|
||
<br>
|
||
Now, the absence of a policy generates an error message and the
|
||
firewall is stopped:<br>
|
||
<br>
|
||
No policy defined from zone
|
||
<source> to zone <dest></p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Previously, if neither
|
||
/etc/shorewall/common nor /etc/shorewall/common.def existed, Shorewall
|
||
would fail to start and would not remove the lock file. Failure to
|
||
remove the lock file resulted in the following during subsequent
|
||
attempts to start:<br>
|
||
<br>
|
||
Loading /usr/share/shorewall/functions...<br>
|
||
Processing /etc/shorewall/params ...<br>
|
||
Processing /etc/shorewall/shorewall.conf...<br>
|
||
Giving up on lock file /var/lib/shorewall/lock<br>
|
||
Shorewall Not Started<br>
|
||
<br>
|
||
Shorewall now reports a fatal error if neither of these two files exist
|
||
and correctly removes the lock fille. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The order of processing the various
|
||
options has been changed such that blacklist entries now take
|
||
precedence over the 'dhcp' <b>i</b>nterface setting. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The log message generated from the
|
||
'logunclean' interface option has been changed to reflect a disposition
|
||
of LOG rather than DROP. </p>
|
||
</li>
|
||
<li>
|
||
<p><b>When a user name and/or a group name was specified in the
|
||
USER SET column and the destination zone was qualified with a IP
|
||
address, the user and/or group name was not being used to qualify the
|
||
rule.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
ACCEPT fw net:192.0.2.12 tcp 23 - - - vladimir:</b></p>
|
||
</li>
|
||
<li>
|
||
<p><b>The /etc/shorewall/masq file has had the spurious "/"
|
||
character at the front removed.</b></p>
|
||
</li>
|
||
</ol>
|
||
<p><b>Migration Issues:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall IP Traffic Accounting has
|
||
changed since snapshot 20030813 -- see the <a
|
||
href="http://Accounting.html/">Accounting Page</a> for details. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The Uset Set capability introduced
|
||
in SnapShot 20030821 has changed -- see the <a
|
||
href="http://UserSets.html/">User Set page</a> for details. </p>
|
||
</li>
|
||
<li>
|
||
<p>The per-interface Dynamic Blacklisting facility introduced in
|
||
the first post-1.4.6 Snapshot has been removed. The facility had too
|
||
many idiosyncrasies for dial-up users to be a viable part of Shorewall.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>New Features:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Thanks to Steve Herber, the 'help'
|
||
command can now give command-specific help (e.g., shorewall help
|
||
<command>). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A new option "ADMINISABSENTMINDED"
|
||
has been added to /etc/shorewall/shorewall.conf. This option has a
|
||
default value of "No" for existing users which causes Shorewall's
|
||
'stopped' state to continue as it has been; namely, in the
|
||
stopped state only traffic to/from hosts listed in
|
||
/etc/shorewall/routestopped is accepted.<br>
|
||
<br>
|
||
With ADMINISABSENTMINDED=Yes (the default for new installs), in
|
||
addition to traffic to/from the hosts listed in
|
||
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
||
<br>
|
||
a) All traffic originating from the firewall itself; and<br>
|
||
b) All traffic that is part of or related to an
|
||
already-existing connection.<br>
|
||
<br>
|
||
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
|
||
entered through an ssh session will not kill the session.<br>
|
||
<br>
|
||
Note though that even with ADMINISABSENTMINDED=Yes, it is still
|
||
possible for people to shoot themselves in the foot.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
/etc/shorewall/nat:<br>
|
||
<br>
|
||
206.124.146.178
|
||
eth0:0 192.168.1.5 <br>
|
||
<br>
|
||
/etc/shorewall/rules:<br>
|
||
<br>
|
||
ACCEPT net
|
||
loc:192.168.1.5 tcp 22<br>
|
||
ACCEPT loc
|
||
fw tcp 22<br>
|
||
<br>
|
||
From a remote system, I ssh to 206.124.146.178 which establishes an SSH
|
||
connection with local system 192.168.1.5. I then create a second SSH
|
||
connection from that computer to the firewall and confidently type
|
||
"shorewall stop". As part of its stop processing, Shorewall removes
|
||
eth0:0 which kills my SSH connection to 192.168.1.5!!! </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Given the wide range of VPN
|
||
software, I can never hope to add specific support for all of it. I
|
||
have therefore decided to add "generic" tunnel support.<br>
|
||
<br>
|
||
Generic tunnels work pretty much like any of the other tunnel types.
|
||
You usually add a zone to represent the systems at the other end of the
|
||
tunnel and you add the appropriate rules/policies to<br>
|
||
implement your security policy regarding traffic to/from those systems.<br>
|
||
<br>
|
||
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
|
||
<br>
|
||
generic:<protocol>[:<port>] <zone> <ip
|
||
address> <gateway zones><br>
|
||
<br>
|
||
where:<br>
|
||
<br>
|
||
<protocol> is the protocol
|
||
used by the tunnel<br>
|
||
<port> if the protocol
|
||
is 'udp' or 'tcp' then this is the destination port number used by the
|
||
tunnel.<br>
|
||
<zone> is the zone of
|
||
the remote tunnel gateway<br>
|
||
<ip address> is the IP
|
||
address of the remote tunnel gateway.<br>
|
||
<gateway zone>
|
||
Optional. A comma-separated list of zone names. If specified, the
|
||
remote gateway is to be considered part of these zones. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">An 'arp_filter' option has been
|
||
added to the /etc/shorewall/interfaces file. This option causes
|
||
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
|
||
result that this interface will only answer ARP 'who-has' requests from
|
||
hosts that are routed out through that interface. Setting this option
|
||
facilitates testing of your firewall where multiple firewall interfaces
|
||
are connected to the same HUB/Switch (all interfaces connected to the
|
||
single HUB/Switch should have this option specified). Note that using
|
||
such a configuration in a production environment is strongly
|
||
recommended against. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The ADDRESS column in
|
||
/etc/shorewall/masq may now include a comma-separated list of addresses
|
||
and/or address ranges. Netfilter will use all listed addresses/ranges
|
||
in round-robin fashion. \ </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">An /etc/shorewall/accounting file
|
||
has been added to allow for traffic accounting. See the <a
|
||
href="http://Accounting.html/">accounting documentation</a> for a
|
||
description of this facility. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Bridge interfaces (br[0-9]) may now
|
||
be used in /etc/shorewall/maclist. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">ACCEPT, DNAT[-], REDIRECT[-] and LOG
|
||
rules defined in /etc/shorewall/rules may now be rate-limited. For DNAT
|
||
and REDIRECT rules, rate limiting occurs in the nat table DNAT rule;
|
||
the corresponding ACCEPT rule in the filter table is not rate limited.
|
||
If you want to limit the filter table rule, you will need o create two
|
||
rules; a DNAT- rule and an ACCEPT rule which can be rate-limited
|
||
separately.<br>
|
||
<br>
|
||
<b>Warning:</b> When rate limiting is specified on a rule with
|
||
"all" in the SOURCE or DEST fields, the limit will apply to each pair
|
||
of zones individually rather than as a single limit for all pairs of
|
||
covered by the rule.<br>
|
||
<br>
|
||
To specify a rate limit,<br>
|
||
<br>
|
||
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
||
<br>
|
||
<
|
||
<rate>/<interval>[:<burst>] ><br>
|
||
<br>
|
||
where<br>
|
||
<br>
|
||
<rate> is the sustained rate per
|
||
<interval><br>
|
||
<interval> is "sec" or "min"<br>
|
||
<burst> is the largest burst
|
||
accepted within an <interval>. If not given, the default of 5 is
|
||
assumed.<br>
|
||
<br>
|
||
There may be no white space between the ACTION and "<" nor there may
|
||
be any white space within the burst specification. If you want to
|
||
specify logging of a rate-limited rule, the ":" and log level comes
|
||
after the ">" (e.g., ACCEPT<2/sec:4>:info ).<br>
|
||
<br>
|
||
b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
|
||
file. You may specify the rate limit there in the format:<br>
|
||
<br>
|
||
|
||
<rate>/<interval>[:<burst>]<br>
|
||
<br>
|
||
Let's take an example:<br>
|
||
<br>
|
||
|
||
ACCEPT<2/sec:4>
|
||
net dmz
|
||
tcp 80<br>
|
||
<br>
|
||
The first time this rule is reached, the packet will be accepted; in
|
||
fact, since the burst is 4, the first four packets will be accepted.
|
||
After this, it will be 500ms (1 second divided by the rate<br>
|
||
of 2) before a packet will be accepted from this rule, regardless of
|
||
how many packets reach it. Also, every 500ms which passes without
|
||
matching a packet, one of the bursts will be regained; if no packets
|
||
hit the rule for 2 second, the burst will be fully recharged; back
|
||
where we started.</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Multiple chains may now be displayed
|
||
in one "shorewall show" command (e.g., shorewall show INPUT FORWARD
|
||
OUTPUT). </p>
|
||
</li>
|
||
<li>
|
||
<p>Output rules (those with $FW as the SOURCE) may now be limited
|
||
to a set of local users and/or groups. See <a
|
||
href="http://UserSets.html/">http://shorewall.net/UserSets.html</a>
|
||
for details. </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>10/02/2003 - Shorewall 1.4.7 RC2</b></p>
|
||
<p><b><a href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
||
<a href="ftp://shorewall.net/pub/shorewall/Beta" target="_top">ftp://shorewall.net/pub/shorewall/Beta</a></b></p>
|
||
<p><b>Problems Corrected since version 1.4.6 (Those in bold font were
|
||
corrected since 1.4.7 RC 1).</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected problem in 1.4.6 where the
|
||
MANGLE_ENABLED variable was being tested before it was set. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected handling of MAC addresses
|
||
in the SOURCE column of the tcrules file. Previously, these addresses
|
||
resulted in an invalid iptables command. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The "shorewall stop" command is now
|
||
disabled when /etc/shorewall/startup_disabled exists. This prevents
|
||
people from shooting themselves in the foot prior to having configured
|
||
Shorewall. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A change introduced in version 1.4.6
|
||
caused error messages during "shorewall [re]start" when
|
||
ADD_IP_ALIASES=Yes and ip addresses were being added to a PPP
|
||
interface; the addresses were successfully added in spite of the
|
||
messages.<br>
|
||
<br>
|
||
The firewall script has been modified to eliminate the error messages </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Interface-specific dynamic
|
||
blacklisting chains are now displayed by "shorewall monitor" on the
|
||
"Dynamic Chains" page (previously named "Dynamic Chain"). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Thanks to Henry Yang, LOGRATE and
|
||
LOGBURST now work again. </p>
|
||
</li>
|
||
<li value="7">
|
||
<p style="margin-bottom: 0in;">The 'shorewall reject' and
|
||
'shorewall drop' commands now delete any existing rules for the subject
|
||
IP address before adding a new DROP or REJECT rule. Previously, there
|
||
could be many rules for the same IP address in the dynamic chain so
|
||
that multiple 'allow' commands were required to re-enable traffic
|
||
to/from the address. </p>
|
||
</li>
|
||
<li>
|
||
<p>When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following entry
|
||
in /etc/shorewall/masq resulted in a startup error:<br>
|
||
<br>
|
||
eth0 eth1
|
||
206.124.146.20-206.124.146.24</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall previously choked over
|
||
IPV6 addresses configured on interfaces in contexts where Shorewall
|
||
needed to detect something about the interface (such as when "detect"
|
||
appears in the BROADCAST column of the /etc/shorewall/interfaces file).
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall will now load module files
|
||
that are formed from the module name by appending ".o.gz". </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">When Shorewall adds a route to a
|
||
proxy ARP host and such a route already exists, two routes resulted
|
||
previously. This has been corrected so that the existing route is
|
||
replaced if it already exists. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The rfc1918 file has been updated to
|
||
reflect recent allocations. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;"><b>The documentation of the USER SET
|
||
column in the rules file has been corrected.</b> </p>
|
||
</li>
|
||
<li>
|
||
<p><b>If there is no policy defined for the zones specified in a
|
||
rule, the firewall script previously encountered a shell syntax error:<br>
|
||
<br>
|
||
[: NONE: unexpected operator<br>
|
||
<br>
|
||
Now, the absence of a policy generates an error message and the
|
||
firewall is stopped:<br>
|
||
<br>
|
||
No policy defined from zone
|
||
<source> to zone <dest></b></p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;"><b>Previously, if neither
|
||
/etc/shorewall/common nor /etc/shorewall/common.def existed, Shorewall
|
||
would fail to start and would not remove the lock file. Failure to
|
||
remove the lock file resulted in the following during subsequent
|
||
attempts to start:<br>
|
||
<br>
|
||
Loading /usr/share/shorewall/functions...<br>
|
||
Processing /etc/shorewall/params ...<br>
|
||
Processing /etc/shorewall/shorewall.conf...<br>
|
||
Giving up on lock file /var/lib/shorewall/lock<br>
|
||
Shorewall Not Started<br>
|
||
<br>
|
||
Shorewall now reports a fatal error if neither of these two files exist
|
||
and correctly removes the lock fille.</b> </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;"><b>The order of processing the
|
||
various options has been changed such that blacklist entries now take
|
||
precedence over the 'dhcp' interface setting.</b> </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;"><b>The log message generated from
|
||
the 'logunclean' interface option has been changed to reflect a
|
||
disposition of LOG rather than DROP.</b> </p>
|
||
</li>
|
||
<li>
|
||
<p><b>The RFC1918 file has been updated to reflect recent IANA
|
||
allocations.</b></p>
|
||
</li>
|
||
</ol>
|
||
<p><b>Migration Issues:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall IP Traffic Accounting has
|
||
changed since snapshot 20030813 -- see the <a
|
||
href="http://Accounting.html/">Accounting Page</a> for details. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The Uset Set capability introduced
|
||
in SnapShot 20030821 has changed -- see the <a
|
||
href="http://UserSets.html/">User Set page</a> for details. </p>
|
||
</li>
|
||
<li>
|
||
<p>The per-interface Dynamic Blacklisting facility introduced in
|
||
the first post-1.4.6 Snapshot has been removed. The facility had too
|
||
many idiosyncrasies for dial-up users to be a viable part of Shorewall.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>New Features:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Thanks to Steve Herber, the 'help'
|
||
command can now give command-specific help (e.g., shorewall help
|
||
<command>). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A new option "ADMINISABSENTMINDED"
|
||
has been added to /etc/shorewall/shorewall.conf. This option has a
|
||
default value of "No" for existing users which causes Shorewall's
|
||
'stopped' state to continue as it has been; namely, in the
|
||
stopped state only traffic to/from hosts listed in
|
||
/etc/shorewall/routestopped is accepted.<br>
|
||
<br>
|
||
With ADMINISABSENTMINDED=Yes (the default for new installs), in
|
||
addition to traffic to/from the hosts listed in
|
||
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
||
<br>
|
||
a) All traffic originating from the firewall itself; and<br>
|
||
b) All traffic that is part of or related to an
|
||
already-existing connection.<br>
|
||
<br>
|
||
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
|
||
entered through an ssh session will not kill the session.<br>
|
||
<br>
|
||
Note though that even with ADMINISABSENTMINDED=Yes, it is still
|
||
possible for people to shoot themselves in the foot.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
/etc/shorewall/nat:<br>
|
||
<br>
|
||
206.124.146.178
|
||
eth0:0 192.168.1.5 <br>
|
||
<br>
|
||
/etc/shorewall/rules:<br>
|
||
<br>
|
||
ACCEPT net
|
||
loc:192.168.1.5 tcp 22<br>
|
||
ACCEPT loc
|
||
fw tcp 22<br>
|
||
<br>
|
||
From a remote system, I ssh to 206.124.146.178 which establishes an SSH
|
||
connection with local system 192.168.1.5. I then create a second SSH
|
||
connection from that computer to the firewall and confidently type
|
||
"shorewall stop". As part of its stop processing, Shorewall removes
|
||
eth0:0 which kills my SSH connection to 192.168.1.5!!! </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Given the wide range of VPN
|
||
software, I can never hope to add specific support for all of it. I
|
||
have therefore decided to add "generic" tunnel support.<br>
|
||
<br>
|
||
Generic tunnels work pretty much like any of the other tunnel types.
|
||
You usually add a zone to represent the systems at the other end of the
|
||
tunnel and you add the appropriate rules/policies to<br>
|
||
implement your security policy regarding traffic to/from those systems.<br>
|
||
<br>
|
||
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
|
||
<br>
|
||
generic:<protocol>[:<port>] <zone> <ip
|
||
address> <gateway zones><br>
|
||
<br>
|
||
where:<br>
|
||
<br>
|
||
<protocol> is the protocol
|
||
used by the tunnel<br>
|
||
<port> if the protocol
|
||
is 'udp' or 'tcp' then this is the destination port number used by the
|
||
tunnel.<br>
|
||
<zone> is the zone of
|
||
the remote tunnel gateway<br>
|
||
<ip address> is the IP
|
||
address of the remote tunnel gateway.<br>
|
||
<gateway zone>
|
||
Optional. A comma-separated list of zone names. If specified, the
|
||
remote gateway is to be considered part of these zones. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">An 'arp_filter' option has been
|
||
added to the /etc/shorewall/interfaces file. This option causes
|
||
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
|
||
result that this interface will only answer ARP 'who-has' requests from
|
||
hosts that are routed out through that interface. Setting this option
|
||
facilitates testing of your firewall where multiple firewall interfaces
|
||
are connected to the same HUB/Switch (all interfaces connected to the
|
||
single HUB/Switch should have this option specified). Note that using
|
||
such a configuration in a production environment is strongly
|
||
recommended against. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The ADDRESS column in
|
||
/etc/shorewall/masq may now include a comma-separated list of addresses
|
||
and/or address ranges. Netfilter will use all listed addresses/ranges
|
||
in round-robin fashion. \ </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">An /etc/shorewall/accounting file
|
||
has been added to allow for traffic accounting. See the <a
|
||
href="http://Accounting.html/">accounting documentation</a> for a
|
||
description of this facility. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Bridge interfaces (br[0-9]) may now
|
||
be used in /etc/shorewall/maclist. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">ACCEPT, DNAT[-], REDIRECT[-] and LOG
|
||
rules defined in /etc/shorewall/rules may now be rate-limited. For DNAT
|
||
and REDIRECT rules, rate limiting occurs in the nat table DNAT rule;
|
||
the corresponding ACCEPT rule in the filter table is not rate limited.
|
||
If you want to limit the filter table rule, you will need o create two
|
||
rules; a DNAT- rule and an ACCEPT rule which can be rate-limited
|
||
separately.<br>
|
||
<br>
|
||
<b>Warning:</b> When rate limiting is specified on a rule with
|
||
"all" in the SOURCE or DEST fields, the limit will apply to each pair
|
||
of zones individually rather than as a single limit for all pairs of
|
||
covered by the rule.<br>
|
||
<br>
|
||
To specify a rate limit,<br>
|
||
<br>
|
||
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
||
<br>
|
||
<
|
||
<rate>/<interval>[:<burst>] ><br>
|
||
<br>
|
||
where<br>
|
||
<br>
|
||
<rate> is the sustained rate per
|
||
<interval><br>
|
||
<interval> is "sec" or "min"<br>
|
||
<burst> is the largest burst
|
||
accepted within an <interval>. If not given, the default of 5 is
|
||
assumed.<br>
|
||
<br>
|
||
There may be no white space between the ACTION and "<" nor there may
|
||
be any white space within the burst specification. If you want to
|
||
specify logging of a rate-limited rule, the ":" and log level comes
|
||
after the ">" (e.g., ACCEPT<2/sec:4>:info ).<br>
|
||
<br>
|
||
b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
|
||
file. You may specify the rate limit there in the format:<br>
|
||
<br>
|
||
|
||
<rate>/<interval>[:<burst>]<br>
|
||
<br>
|
||
Let's take an example:<br>
|
||
<br>
|
||
|
||
ACCEPT<2/sec:4>
|
||
net dmz
|
||
tcp 80<br>
|
||
<br>
|
||
The first time this rule is reached, the packet will be accepted; in
|
||
fact, since the burst is 4, the first four packets will be accepted.
|
||
After this, it will be 500ms (1 second divided by the rate<br>
|
||
of 2) before a packet will be accepted from this rule, regardless of
|
||
how many packets reach it. Also, every 500ms which passes without
|
||
matching a packet, one of the bursts will be regained; if no packets
|
||
hit the rule for 2 second, the burst will be fully recharged; back
|
||
where we started.</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Multiple chains may now be displayed
|
||
in one "shorewall show" command (e.g., shorewall show INPUT FORWARD
|
||
OUTPUT). </p>
|
||
</li>
|
||
<li>
|
||
<p>Output rules (those with $FW as the SOURCE) may now be limited
|
||
to a set of local users and/or groups. See <a
|
||
href="http://UserSets.html/">http://shorewall.net/UserSets.html</a>
|
||
for details. </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>9/18/2003 - Shorewall 1.4.7 RC 1</b></p>
|
||
<p><b><a href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
||
<a href="ftp://shorewall.net/pub/shorewall/Beta" target="_top">ftp://shorewall.net/pub/shorewall/Beta</a></b></p>
|
||
<p><b>Problems Corrected since version 1.4.6 (Those in bold font were
|
||
corrected since 1.4.7 Beta 1).</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected problem in 1.4.6 where the
|
||
MANGLE_ENABLED variable was being tested before it was set. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected handling of MAC addresses
|
||
in the SOURCE column of the tcrules file. Previously, these addresses
|
||
resulted in an invalid iptables command. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The "shorewall stop" command is now
|
||
disabled when /etc/shorewall/startup_disabled exists. This prevents
|
||
people from shooting themselves in the foot prior to having configured
|
||
Shorewall. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A change introduced in version 1.4.6
|
||
caused error messages during "shorewall [re]start" when
|
||
ADD_IP_ALIASES=Yes and ip addresses were being added to a PPP
|
||
interface; the addresses were successfully added in spite of the
|
||
messages.<br>
|
||
<br>
|
||
The firewall script has been modified to eliminate the error messages </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Interface-specific dynamic
|
||
blacklisting chains are now displayed by "shorewall monitor" on the
|
||
"Dynamic Chains" page (previously named "Dynamic Chain"). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Thanks to Henry Yang, LOGRATE and
|
||
LOGBURST now work again. </p>
|
||
</li>
|
||
<li value="7">
|
||
<p style="margin-bottom: 0in;">The 'shorewall reject' and
|
||
'shorewall drop' commands now delete any existing rules for the subject
|
||
IP address before adding a new DROP or REJECT rule. Previously, there
|
||
could be many rules for the same IP address in the dynamic chain so
|
||
that multiple 'allow' commands were required to re-enable traffic
|
||
to/from the address. </p>
|
||
</li>
|
||
<li>
|
||
<p>When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following entry
|
||
in /etc/shorewall/masq resulted in a startup error:<br>
|
||
<br>
|
||
eth0 eth1
|
||
206.124.146.20-206.124.146.24</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall previously choked over
|
||
IPV6 addresses configured on interfaces in contexts where Shorewall
|
||
needed to detect something about the interface (such as when "detect"
|
||
appears in the BROADCAST column of the /etc/shorewall/interfaces file).
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall will now load module files
|
||
that are formed from the module name by appending ".o.gz". </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;"><b>When Shorewall adds a route to a
|
||
proxy ARP host and such a route already exists, two routes resulted
|
||
previously. This has been corrected so that the existing route is
|
||
replaced if it already exists.</b> </p>
|
||
</li>
|
||
<li>
|
||
<p><b>The rfc1918 file has been updated to reflect recent
|
||
allocations.</b></p>
|
||
</li>
|
||
</ol>
|
||
<p><b>Migration Issues:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall IP Traffic Accounting has
|
||
changed since snapshot 20030813 -- see the <a
|
||
href="http://Accounting.html/">Accounting Page</a> for details. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The Uset Set capability introduced
|
||
in SnapShot 20030821 has changed -- see the <a
|
||
href="http://UserSets.html/">User Set page</a> for details. </p>
|
||
</li>
|
||
<li>
|
||
<p>The per-interface Dynamic Blacklisting facility introduced in
|
||
the first post-1.4.6 Snapshot has been removed. The facility had too
|
||
many idiosyncrasies for dial-up users to be a viable part of Shorewall.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>New Features:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Thanks to Steve Herber, the 'help'
|
||
command can now give command-specific help (e.g., shorewall help
|
||
<command>). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A new option "ADMINISABSENTMINDED"
|
||
has been added to /etc/shorewall/shorewall.conf. This option has a
|
||
default value of "No" for existing users which causes Shorewall's
|
||
'stopped' state to continue as it has been; namely, in the
|
||
stopped state only traffic to/from hosts listed in
|
||
/etc/shorewall/routestopped is accepted.<br>
|
||
<br>
|
||
With ADMINISABSENTMINDED=Yes (the default for new installs), in
|
||
addition to traffic to/from the hosts listed in
|
||
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
||
<br>
|
||
a) All traffic originating from the firewall itself; and<br>
|
||
b) All traffic that is part of or related to an
|
||
already-existing connection.<br>
|
||
<br>
|
||
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
|
||
entered through an ssh session will not kill the session.<br>
|
||
<br>
|
||
Note though that even with ADMINISABSENTMINDED=Yes, it is still
|
||
possible for people to shoot themselves in the foot.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
/etc/shorewall/nat:<br>
|
||
<br>
|
||
206.124.146.178
|
||
eth0:0 192.168.1.5 <br>
|
||
<br>
|
||
/etc/shorewall/rules:<br>
|
||
<br>
|
||
ACCEPT net
|
||
loc:192.168.1.5 tcp 22<br>
|
||
ACCEPT loc
|
||
fw tcp 22<br>
|
||
<br>
|
||
From a remote system, I ssh to 206.124.146.178 which establishes an SSH
|
||
connection with local system 192.168.1.5. I then create a second SSH
|
||
connection from that computer to the firewall and confidently type
|
||
"shorewall stop". As part of its stop processing, Shorewall removes
|
||
eth0:0 which kills my SSH connection to 192.168.1.5!!! </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Given the wide range of VPN
|
||
software, I can never hope to add specific support for all of it. I
|
||
have therefore decided to add "generic" tunnel support.<br>
|
||
<br>
|
||
Generic tunnels work pretty much like any of the other tunnel types.
|
||
You usually add a zone to represent the systems at the other end of the
|
||
tunnel and you add the appropriate rules/policies to<br>
|
||
implement your security policy regarding traffic to/from those systems.<br>
|
||
<br>
|
||
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
|
||
<br>
|
||
generic:<protocol>[:<port>] <zone> <ip
|
||
address> <gateway zones><br>
|
||
<br>
|
||
where:<br>
|
||
<br>
|
||
<protocol> is the protocol
|
||
used by the tunnel<br>
|
||
<port> if the protocol
|
||
is 'udp' or 'tcp' then this is the destination port number used by the
|
||
tunnel.<br>
|
||
<zone> is the zone of
|
||
the remote tunnel gateway<br>
|
||
<ip address> is the IP
|
||
address of the remote tunnel gateway.<br>
|
||
<gateway zone>
|
||
Optional. A comma-separated list of zone names. If specified, the
|
||
remote gateway is to be considered part of these zones. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">An 'arp_filter' option has been
|
||
added to the /etc/shorewall/interfaces file. This option causes
|
||
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
|
||
result that this interface will only answer ARP 'who-has' requests from
|
||
hosts that are routed out through that interface. Setting this option
|
||
facilitates testing of your firewall where multiple firewall interfaces
|
||
are connected to the same HUB/Switch (all interfaces connected to the
|
||
single HUB/Switch should have this option specified). Note that using
|
||
such a configuration in a production environment is strongly
|
||
recommended against. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The ADDRESS column in
|
||
/etc/shorewall/masq may now include a comma-separated list of addresses
|
||
and/or address ranges. Netfilter will use all listed addresses/ranges
|
||
in round-robin fashion. \ </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">An /etc/shorewall/accounting file
|
||
has been added to allow for traffic accounting. See the <a
|
||
href="http://Accounting.html/">accounting documentation</a> for a
|
||
description of this facility. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Bridge interfaces (br[0-9]) may now
|
||
be used in /etc/shorewall/maclist. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">ACCEPT, DNAT[-], REDIRECT[-] and LOG
|
||
rules defined in /etc/shorewall/rules may now be rate-limited. For DNAT
|
||
and REDIRECT rules, rate limiting occurs in the nat table DNAT rule;
|
||
the corresponding ACCEPT rule in the filter table is not rate limited.
|
||
If you want to limit the filter table rule, you will need o create two
|
||
rules; a DNAT- rule and an ACCEPT rule which can be rate-limited
|
||
separately.<br>
|
||
<br>
|
||
<b>Warning:</b> When rate limiting is specified on a rule with
|
||
"all" in the SOURCE or DEST fields, the limit will apply to each pair
|
||
of zones individually rather than as a single limit for all pairs of
|
||
covered by the rule.<br>
|
||
<br>
|
||
To specify a rate limit,<br>
|
||
<br>
|
||
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
||
<br>
|
||
<
|
||
<rate>/<interval>[:<burst>] ><br>
|
||
<br>
|
||
where<br>
|
||
<br>
|
||
<rate> is the sustained rate per
|
||
<interval><br>
|
||
<interval> is "sec" or "min"<br>
|
||
<burst> is the largest burst
|
||
accepted within an <interval>. If not given, the default of 5 is
|
||
assumed.<br>
|
||
<br>
|
||
There may be no white space between the ACTION and "<" nor there may
|
||
be any white space within the burst specification. If you want to
|
||
specify logging of a rate-limited rule, the ":" and log level comes
|
||
after the ">" (e.g., ACCEPT<2/sec:4>:info ).<br>
|
||
<br>
|
||
b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
|
||
file. You may specify the rate limit there in the format:<br>
|
||
<br>
|
||
|
||
<rate>/<interval>[:<burst>]<br>
|
||
<br>
|
||
Let's take an example:<br>
|
||
<br>
|
||
|
||
ACCEPT<2/sec:4>
|
||
net dmz
|
||
tcp 80<br>
|
||
<br>
|
||
The first time this rule is reached, the packet will be accepted; in
|
||
fact, since the burst is 4, the first four packets will be accepted.
|
||
After this, it will be 500ms (1 second divided by the rate<br>
|
||
of 2) before a packet will be accepted from this rule, regardless of
|
||
how many packets reach it. Also, every 500ms which passes without
|
||
matching a packet, one of the bursts will be regained; if no packets
|
||
hit the rule for 2 second, the burst will be fully recharged; back
|
||
where we started.</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Multiple chains may now be displayed
|
||
in one "shorewall show" command (e.g., shorewall show INPUT FORWARD
|
||
OUTPUT). </p>
|
||
</li>
|
||
<li>
|
||
<p>Output rules (those with $FW as the SOURCE) may now be limited
|
||
to a set of local users and/or groups. See <a
|
||
href="http://UserSets.html/">http://shorewall.net/UserSets.html</a>
|
||
for details. </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>9/15/2003 - Shorewall 1.4.7 Beta 2</b> </p>
|
||
<p><b><a href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
||
<a href="ftp://shorewall.net/pub/shorewall/Beta" target="_top">ftp://shorewall.net/pub/shorewall/Beta</a></b></p>
|
||
<p><b>Problems Corrected since version 1.4.6 (Those in bold font were
|
||
corrected since 1.4.7 Beta 1).</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected problem in 1.4.6 where the
|
||
MANGLE_ENABLED variable was being tested before it was set. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected handling of MAC addresses
|
||
in the SOURCE column of the tcrules file. Previously, these addresses
|
||
resulted in an invalid iptables command. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The "shorewall stop" command is now
|
||
disabled when /etc/shorewall/startup_disabled exists. This prevents
|
||
people from shooting themselves in the foot prior to having configured
|
||
Shorewall. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A change introduced in version 1.4.6
|
||
caused error messages during "shorewall [re]start" when
|
||
ADD_IP_ALIASES=Yes and ip addresses were being added to a PPP
|
||
interface; the addresses were successfully added in spite of the
|
||
messages.<br>
|
||
<br>
|
||
The firewall script has been modified to eliminate the error messages </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Interface-specific dynamic
|
||
blacklisting chains are now displayed by "shorewall monitor" on the
|
||
"Dynamic Chains" page (previously named "Dynamic Chain"). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Thanks to Henry Yang, LOGRATE and
|
||
LOGBURST now work again. </p>
|
||
</li>
|
||
<li value="7">
|
||
<p style="margin-bottom: 0in;"><b>The 'shorewall reject' and
|
||
'shorewall drop' commands now delete any existing rules for the subject
|
||
IP address before adding a new DROP or REJECT rule. Previously, there
|
||
could be many rules for the same IP address in the dynamic chain so
|
||
that multiple 'allow' commands were required to re-enable traffic
|
||
to/from the address.</b> </p>
|
||
</li>
|
||
<li>
|
||
<p><b>When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following
|
||
entry in /etc/shorewall/masq resulted in a startup error:<br>
|
||
<br>
|
||
eth0 eth1
|
||
206.124.146.20-206.124.146.24</b></p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;"><b>Shorewall previously choked over
|
||
IPV6 addresses configured on interfaces in contexts where Shorewall
|
||
needed to detect something about the interface (such as when "detect"
|
||
appears in the BROADCAST column of the /etc/shorewall/interfaces file).</b>
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p><b>Shorewall will now load module files that are formed from the
|
||
module name by appending ".o.gz".</b></p>
|
||
</li>
|
||
</ol>
|
||
<p><b>Migration Issues:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall IP Traffic Accounting has
|
||
changed since snapshot 20030813 -- see the <a
|
||
href="http://Accounting.html/">Accounting Page</a> for details. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The Uset Set capability introduced
|
||
in SnapShot 20030821 has changed -- see the <a
|
||
href="http://UserSets.html/">User Set page</a> for details. </p>
|
||
</li>
|
||
<li>
|
||
<p>The per-interface Dynamic Blacklisting facility introduced in
|
||
the first post-1.4.6 Snapshot has been removed. The facility had too
|
||
many idiosyncrasies for dial-up users to be a viable part of Shorewall.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>New Features:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Thanks to Steve Herber, the 'help'
|
||
command can now give command-specific help (e.g., shorewall help
|
||
<command>). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A new option "ADMINISABSENTMINDED"
|
||
has been added to /etc/shorewall/shorewall.conf. This option has a
|
||
default value of "No" for existing users which causes Shorewall's
|
||
'stopped' state to continue as it has been; namely, in the
|
||
stopped state only traffic to/from hosts listed in
|
||
/etc/shorewall/routestopped is accepted.<br>
|
||
<br>
|
||
With ADMINISABSENTMINDED=Yes (the default for new installs), in
|
||
addition to traffic to/from the hosts listed in
|
||
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
||
<br>
|
||
a) All traffic originating from the firewall itself; and<br>
|
||
b) All traffic that is part of or related to an
|
||
already-existing connection.<br>
|
||
<br>
|
||
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
|
||
entered through an ssh session will not kill the session.<br>
|
||
<br>
|
||
Note though that even with ADMINISABSENTMINDED=Yes, it is still
|
||
possible for people to shoot themselves in the foot.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
/etc/shorewall/nat:<br>
|
||
<br>
|
||
206.124.146.178
|
||
eth0:0 192.168.1.5 <br>
|
||
<br>
|
||
/etc/shorewall/rules:<br>
|
||
<br>
|
||
ACCEPT net
|
||
loc:192.168.1.5 tcp 22<br>
|
||
ACCEPT loc
|
||
fw tcp 22<br>
|
||
<br>
|
||
From a remote system, I ssh to 206.124.146.178 which establishes an SSH
|
||
connection with local system 192.168.1.5. I then create a second SSH
|
||
connection from that computer to the firewall and confidently type
|
||
"shorewall stop". As part of its stop processing, Shorewall removes
|
||
eth0:0 which kills my SSH connection to 192.168.1.5!!! </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Given the wide range of VPN
|
||
software, I can never hope to add specific support for all of it. I
|
||
have therefore decided to add "generic" tunnel support.<br>
|
||
<br>
|
||
Generic tunnels work pretty much like any of the other tunnel types.
|
||
You usually add a zone to represent the systems at the other end of the
|
||
tunnel and you add the appropriate rules/policies to<br>
|
||
implement your security policy regarding traffic to/from those systems.<br>
|
||
<br>
|
||
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
|
||
<br>
|
||
generic:<protocol>[:<port>] <zone> <ip
|
||
address> <gateway zones><br>
|
||
<br>
|
||
where:<br>
|
||
<br>
|
||
<protocol> is the protocol
|
||
used by the tunnel<br>
|
||
<port> if the protocol
|
||
is 'udp' or 'tcp' then this is the destination port number used by the
|
||
tunnel.<br>
|
||
<zone> is the zone of
|
||
the remote tunnel gateway<br>
|
||
<ip address> is the IP
|
||
address of the remote tunnel gateway.<br>
|
||
<gateway zone>
|
||
Optional. A comma-separated list of zone names. If specified, the
|
||
remote gateway is to be considered part of these zones. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">An 'arp_filter' option has been
|
||
added to the /etc/shorewall/interfaces file. This option causes
|
||
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
|
||
result that this interface will only answer ARP 'who-has' requests from
|
||
hosts that are routed out through that interface. Setting this option
|
||
facilitates testing of your firewall where multiple firewall interfaces
|
||
are connected to the same HUB/Switch (all interfaces connected to the
|
||
single HUB/Switch should have this option specified). Note that using
|
||
such a configuration in a production environment is strongly
|
||
recommended against. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The ADDRESS column in
|
||
/etc/shorewall/masq may now include a comma-separated list of addresses
|
||
and/or address ranges. Netfilter will use all listed addresses/ranges
|
||
in round-robin fashion. \ </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">An /etc/shorewall/accounting file
|
||
has been added to allow for traffic accounting. See the <a
|
||
href="http://Accounting.html/">accounting documentation</a> for a
|
||
description of this facility. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Bridge interfaces (br[0-9]) may now
|
||
be used in /etc/shorewall/maclist. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">ACCEPT, DNAT[-], REDIRECT[-] and LOG
|
||
rules defined in /etc/shorewall/rules may now be rate-limited. For DNAT
|
||
and REDIRECT rules, rate limiting occurs in the nat table DNAT rule;
|
||
the corresponding ACCEPT rule in the filter table is not rate limited.
|
||
If you want to limit the filter table rule, you will need o create two
|
||
rules; a DNAT- rule and an ACCEPT rule which can be rate-limited
|
||
separately.<br>
|
||
<br>
|
||
<b>Warning:</b> When rate limiting is specified on a rule with
|
||
"all" in the SOURCE or DEST fields, the limit will apply to each pair
|
||
of zones individually rather than as a single limit for all pairs of
|
||
covered by the rule.<br>
|
||
<br>
|
||
To specify a rate limit,<br>
|
||
<br>
|
||
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
||
<br>
|
||
<
|
||
<rate>/<interval>[:<burst>] ><br>
|
||
<br>
|
||
where<br>
|
||
<br>
|
||
<rate> is the sustained rate per
|
||
<interval><br>
|
||
<interval> is "sec" or "min"<br>
|
||
<burst> is the largest burst
|
||
accepted within an <interval>. If not given, the default of 5 is
|
||
assumed.<br>
|
||
<br>
|
||
There may be no white space between the ACTION and "<" nor there may
|
||
be any white space within the burst specification. If you want to
|
||
specify logging of a rate-limited rule, the ":" and log level comes
|
||
after the ">" (e.g., ACCEPT<2/sec:4>:info ).<br>
|
||
<br>
|
||
b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
|
||
file. You may specify the rate limit there in the format:<br>
|
||
<br>
|
||
|
||
<rate>/<interval>[:<burst>]<br>
|
||
<br>
|
||
Let's take an example:<br>
|
||
<br>
|
||
|
||
ACCEPT<2/sec:4>
|
||
net dmz
|
||
tcp 80<br>
|
||
<br>
|
||
The first time this rule is reached, the packet will be accepted; in
|
||
fact, since the burst is 4, the first four packets will be accepted.
|
||
After this, it will be 500ms (1 second divided by the rate<br>
|
||
of 2) before a packet will be accepted from this rule, regardless of
|
||
how many packets reach it. Also, every 500ms which passes without
|
||
matching a packet, one of the bursts will be regained; if no packets
|
||
hit the rule for 2 second, the burst will be fully recharged; back
|
||
where we started.</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Multiple chains may now be displayed
|
||
in one "shorewall show" command (e.g., shorewall show INPUT FORWARD
|
||
OUTPUT). </p>
|
||
</li>
|
||
<li>
|
||
<p>Output rules (those with $FW as the SOURCE) may now be limited
|
||
to a set of local users and/or groups. See <a
|
||
href="http://UserSets.html/">http://shorewall.net/UserSets.html</a>
|
||
for details. </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>8/27/2003 - Shorewall Mirror in Australia</b></p>
|
||
<p>Thanks to Dave Kempe and Solutions First
|
||
(<a href="http://www.solutionsfirst.com.au/">http://www.solutionsfirst.com.au</a>),
|
||
there is now a Shorewall Mirror in Australia:</p>
|
||
<p style="margin-left: 0.42in;"><a href="http://www.shorewall.com.au/"
|
||
target="_top">http://www.shorewall.com.au</a><br>
|
||
<a href="ftp://ftp.shorewall.com.au/">ftp://ftp.shorewall.com.au</a></p>
|
||
<p><b>8/26/2003 - French Version of the Shorewall Setup Guide </b></p>
|
||
<p>Thanks to Fabien Demassieux, there is now a <a
|
||
href="shorewall_setup_guide_fr.htm">French
|
||
translation of the Shorewall Setup Guide</a>. Merci Beacoup, Fabien! </p>
|
||
<p><b>8/25/2003 - Shorewall 1.4.7 Beta 1</b> </p>
|
||
<p><b><a href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
||
<a href="ftp://shorewall.net/pub/shorewall/Beta" target="_top">ftp://shorewall.net/pub/shorewall/Beta</a></b></p>
|
||
<p><b>Problems Corrected since version 1.4.6</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected problem in 1.4.6 where the
|
||
MANGLE_ENABLED variable was being tested before it was set. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected handling of MAC addresses
|
||
in the SOURCE column of the tcrules file. Previously, these addresses
|
||
resulted in an invalid iptables command. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The "shorewall stop" command is now
|
||
disabled when /etc/shorewall/startup_disabled exists. This prevents
|
||
people from shooting themselves in the foot prior to having configured
|
||
Shorewall. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A change introduced in version 1.4.6
|
||
caused error messages during "shorewall [re]start" when
|
||
ADD_IP_ALIASES=Yes and ip addresses were being added to a PPP
|
||
interface; the addresses were successfully added in spite of the
|
||
messages.<br>
|
||
<br>
|
||
The firewall script has been modified to eliminate the error messages </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Interface-specific dynamic
|
||
blacklisting chains are now displayed by "shorewall monitor" on the
|
||
"Dynamic Chains" page (previously named "Dynamic Chain"). </p>
|
||
</li>
|
||
<li>
|
||
<p>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>Migration Issues:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall IP Traffic Accounting has
|
||
changed since snapshot 20030813 -- see the <a
|
||
href="http://Accounting.html/">Accounting Page</a> for details. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The Uset Set capability introduced
|
||
in SnapShot 20030821 has changed -- see the <a
|
||
href="http://UserSets.html/">User Set page</a> for details. </p>
|
||
</li>
|
||
<li>
|
||
<p>The per-interface Dynamic Blacklisting facility introduced in
|
||
the first post-1.4.6 Snapshot has been removed. The facility had too
|
||
many idiosyncrasies for dial-up users to be a viable part of Shorewall.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>New Features:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Thanks to Steve Herber, the 'help'
|
||
command can now give command-specific help (e.g., shorewall help
|
||
<command>). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A new option "ADMINISABSENTMINDED"
|
||
has been added to /etc/shorewall/shorewall.conf. This option has a
|
||
default value of "No" for existing users which causes Shorewall's
|
||
'stopped' state to continue as it has been; namely, in the
|
||
stopped state only traffic to/from hosts listed in
|
||
/etc/shorewall/routestopped is accepted.<br>
|
||
<br>
|
||
With ADMINISABSENTMINDED=Yes (the default for new installs), in
|
||
addition to traffic to/from the hosts listed in
|
||
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
||
<br>
|
||
a) All traffic originating from the firewall itself; and<br>
|
||
b) All traffic that is part of or related to an
|
||
already-existing connection.<br>
|
||
<br>
|
||
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
|
||
entered through an ssh session will not kill the session.<br>
|
||
<br>
|
||
Note though that even with ADMINISABSENTMINDED=Yes, it is still
|
||
possible for people to shoot themselves in the foot.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
/etc/shorewall/nat:<br>
|
||
<br>
|
||
206.124.146.178
|
||
eth0:0 192.168.1.5 <br>
|
||
<br>
|
||
/etc/shorewall/rules:<br>
|
||
<br>
|
||
ACCEPT net
|
||
loc:192.168.1.5 tcp 22<br>
|
||
ACCEPT loc
|
||
fw tcp 22<br>
|
||
<br>
|
||
From a remote system, I ssh to 206.124.146.178 which establishes an SSH
|
||
connection with local system 192.168.1.5. I then create a second SSH
|
||
connection from that computer to the firewall and confidently type
|
||
"shorewall stop". As part of its stop processing, Shorewall removes
|
||
eth0:0 which kills my SSH connection to 192.168.1.5!!! </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Given the wide range of VPN
|
||
software, I can never hope to add specific support for all of it. I
|
||
have therefore decided to add "generic" tunnel support.<br>
|
||
<br>
|
||
Generic tunnels work pretty much like any of the other tunnel types.
|
||
You usually add a zone to represent the systems at the other end of the
|
||
tunnel and you add the appropriate rules/policies to<br>
|
||
implement your security policy regarding traffic to/from those systems.<br>
|
||
<br>
|
||
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
|
||
<br>
|
||
generic:<protocol>[:<port>] <zone> <ip
|
||
address> <gateway zones><br>
|
||
<br>
|
||
where:<br>
|
||
<br>
|
||
<protocol> is the protocol
|
||
used by the tunnel<br>
|
||
<port> if the protocol
|
||
is 'udp' or 'tcp' then this is the destination port number used by the
|
||
tunnel.<br>
|
||
<zone> is the zone of
|
||
the remote tunnel gateway<br>
|
||
<ip address> is the IP
|
||
address of the remote tunnel gateway.<br>
|
||
<gateway zone>
|
||
Optional. A comma-separated list of zone names. If specified, the
|
||
remote gateway is to be considered part of these zones. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">An 'arp_filter' option has been
|
||
added to the /etc/shorewall/interfaces file. This option causes
|
||
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
|
||
result that this interface will only answer ARP 'who-has' requests from
|
||
hosts that are routed out through that interface. Setting this option
|
||
facilitates testing of your firewall where multiple firewall interfaces
|
||
are connected to the same HUB/Switch (all interfaces connected to the
|
||
single HUB/Switch should have this option specified). Note that using
|
||
such a configuration in a production environment is strongly
|
||
recommended against. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The ADDRESS column in
|
||
/etc/shorewall/masq may now include a comma-separated list of addresses
|
||
and/or address ranges. Netfilter will use all listed addresses/ranges
|
||
in round-robin fashion. \ </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">An /etc/shorewall/accounting file
|
||
has been added to allow for traffic accounting. See the <a
|
||
href="http://Accounting.html/">accounting documentation</a> for a
|
||
description of this facility. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Bridge interfaces (br[0-9]) may now
|
||
be used in /etc/shorewall/maclist. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">ACCEPT, DNAT[-], REDIRECT[-] and LOG
|
||
rules defined in /etc/shorewall/rules may now be rate-limited. For DNAT
|
||
and REDIRECT rules, rate limiting occurs in the nat table DNAT rule;
|
||
the corresponding ACCEPT rule in the filter table is not rate limited.
|
||
If you want to limit the filter table rule, you will need o create two
|
||
rules; a DNAT- rule and an ACCEPT rule which can be rate-limited
|
||
separately.<br>
|
||
<br>
|
||
<b>Warning:</b> When rate limiting is specified on a rule with
|
||
"all" in the SOURCE or DEST fields, the limit will apply to each pair
|
||
of zones individually rather than as a single limit for all pairs of
|
||
covered by the rule.<br>
|
||
<br>
|
||
To specify a rate limit,<br>
|
||
<br>
|
||
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
||
<br>
|
||
<
|
||
<rate>/<interval>[:<burst>] ><br>
|
||
<br>
|
||
where<br>
|
||
<br>
|
||
<rate> is the sustained rate per
|
||
<interval><br>
|
||
<interval> is "sec" or "min"<br>
|
||
<burst> is the largest burst
|
||
accepted within an <interval>. If not given, the default of 5 is
|
||
assumed.<br>
|
||
<br>
|
||
There may be no white space between the ACTION and "<" nor there may
|
||
be any white space within the burst specification. If you want to
|
||
specify logging of a rate-limited rule, the ":" and log level comes
|
||
after the ">" (e.g., ACCEPT<2/sec:4>:info ).<br>
|
||
<br>
|
||
b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
|
||
file. You may specify the rate limit there in the format:<br>
|
||
<br>
|
||
|
||
<rate>/<interval>[:<burst>]<br>
|
||
<br>
|
||
Let's take an example:<br>
|
||
<br>
|
||
|
||
ACCEPT<2/sec:4>
|
||
net dmz
|
||
tcp 80<br>
|
||
<br>
|
||
The first time this rule is reached, the packet will be accepted; in
|
||
fact, since the burst is 4, the first four packets will be accepted.
|
||
After this, it will be 500ms (1 second divided by the rate<br>
|
||
of 2) before a packet will be accepted from this rule, regardless of
|
||
how many packets reach it. Also, every 500ms which passes without
|
||
matching a packet, one of the bursts will be regained; if no packets
|
||
hit the rule for 2 second, the burst will be fully recharged; back
|
||
where we started.</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Multiple chains may now be displayed
|
||
in one "shorewall show" command (e.g., shorewall show INPUT FORWARD
|
||
OUTPUT). </p>
|
||
</li>
|
||
<li>
|
||
<p>Output rules (those with $FW as the SOURCE) may now be limited
|
||
to a set of local users and/or groups. See <a
|
||
href="http://UserSets.html/">http://shorewall.net/UserSets.html</a>
|
||
for details.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>8/23/2003 - Snapshot 1.4.6_20030823</b> </p>
|
||
<blockquote><a href="http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
|
||
<a href="ftp://shorewall.net/pub/shorewall/Snapshots/" target="_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></blockquote>
|
||
<p><b>Problems Corrected since version 1.4.6</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected problem in 1.4.6 where the
|
||
MANGLE_ENABLED variable was being tested before it was set. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected handling of MAC addresses
|
||
in the SOURCE column of the tcrules file. Previously, these addresses
|
||
resulted in an invalid iptables command. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The "shorewall stop" command is now
|
||
disabled when /etc/shorewall/startup_disabled exists. This prevents
|
||
people from shooting themselves in the foot prior to having configured
|
||
Shorewall. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A change introduced in version 1.4.6
|
||
caused error messages during "shorewall [re]start" when
|
||
ADD_IP_ALIASES=Yes and ip addresses were being added to a PPP
|
||
interface; the addresses were successfully added in spite of the
|
||
messages.<br>
|
||
<br>
|
||
The firewall script has been modified to eliminate the error messages </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Interface-specific dynamic
|
||
blacklisting chains are now displayed by "shorewall monitor" on the
|
||
"Dynamic Chains" page (previously named "Dynamic Chain"). </p>
|
||
</li>
|
||
<li>
|
||
<p>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>Migration Issues:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Once you have installed this version
|
||
of Shorewall, you must restart Shorewall before you may use the 'drop',
|
||
'reject', 'allow' or 'save' commands. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">To maintain strict compatibility
|
||
with previous versions, current uses of "shorewall drop" and "shorewall
|
||
reject" should be replaced with "shorewall dropall" and "shorewall
|
||
rejectall" </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall IP Traffic Accounting has
|
||
changed since snapshot 20030813 -- see the <a
|
||
href="http://Accounting.html/">Accounting Page</a> for details. </p>
|
||
</li>
|
||
<li>
|
||
<p>The Uset Set capability introduced in SnapShot 20030821 has
|
||
changed -- see the <a href="http://UserSets.html/">User Set page</a>
|
||
for details. </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>New Features:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall now creates a dynamic
|
||
blacklisting chain for each interface defined in
|
||
/etc/shorewall/interfaces. The 'drop' and 'reject' commands use the
|
||
routing table to determine which of these chains is to be used for
|
||
blacklisting the specified IP address(es).<br>
|
||
<br>
|
||
Two new commands ('dropall' and 'rejectall') have been introduced that
|
||
do what 'drop' and 'reject' used to do; namely, when an address is
|
||
blacklisted using these new commands, it will be blacklisted on all of
|
||
your firewall's interfaces. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Thanks to Steve Herber, the 'help'
|
||
command can now give command-specific help (e.g., shorewall help
|
||
<command>). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A new option "ADMINISABSENTMINDED"
|
||
has been added to /etc/shorewall/shorewall.conf. This option has a
|
||
default value of "No" for existing users which causes Shorewall's
|
||
'stopped' state to continue as it has been; namely, in the
|
||
stopped state only traffic to/from hosts listed in
|
||
/etc/shorewall/routestopped is accepted.<br>
|
||
<br>
|
||
With ADMINISABSENTMINDED=Yes (the default for new installs), in
|
||
addition to traffic to/from the hosts listed in
|
||
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
||
<br>
|
||
a) All traffic originating from the firewall itself; and<br>
|
||
b) All traffic that is part of or related to an
|
||
already-existing connection.<br>
|
||
<br>
|
||
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
|
||
entered through an ssh session will not kill the session.<br>
|
||
<br>
|
||
Note though that even with ADMINISABSENTMINDED=Yes, it is still
|
||
possible for people to shoot themselves in the foot.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
/etc/shorewall/nat:<br>
|
||
<br>
|
||
206.124.146.178
|
||
eth0:0 192.168.1.5 <br>
|
||
<br>
|
||
/etc/shorewall/rules:<br>
|
||
<br>
|
||
ACCEPT net
|
||
loc:192.168.1.5 tcp 22<br>
|
||
ACCEPT loc
|
||
fw tcp 22<br>
|
||
<br>
|
||
From a remote system, I ssh to 206.124.146.178 which establishes an SSH
|
||
connection with local system 192.168.1.5. I then create a second SSH
|
||
connection from that computer to the firewall and confidently type
|
||
"shorewall stop". As part of its stop processing, Shorewall removes
|
||
eth0:0 which kills my SSH connection to 192.168.1.5!!! </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Given the wide range of VPN
|
||
software, I can never hope to add specific support for all of it. I
|
||
have therefore decided to add "generic" tunnel support.<br>
|
||
<br>
|
||
Generic tunnels work pretty much like any of the other tunnel types.
|
||
You usually add a zone to represent the systems at the other end of the
|
||
tunnel and you add the appropriate rules/policies to<br>
|
||
implement your security policy regarding traffic to/from those systems.<br>
|
||
<br>
|
||
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
|
||
<br>
|
||
generic:<protocol>[:<port>] <zone> <ip
|
||
address> <gateway zones><br>
|
||
<br>
|
||
where:<br>
|
||
<br>
|
||
<protocol> is the protocol
|
||
used by the tunnel<br>
|
||
<port> if the protocol
|
||
is 'udp' or 'tcp' then this is the destination port number used by the
|
||
tunnel.<br>
|
||
<zone> is the zone of
|
||
the remote tunnel gateway<br>
|
||
<ip address> is the IP
|
||
address of the remote tunnel gateway.<br>
|
||
<gateway zone>
|
||
Optional. A comma-separated list of zone names. If specified, the
|
||
remote gateway is to be considered part of these zones. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">An 'arp_filter' option has been
|
||
added to the /etc/shorewall/interfaces file. This option causes
|
||
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
|
||
result that this interface will only answer ARP 'who-has' requests from
|
||
hosts that are routed out through that interface. Setting this option
|
||
facilitates testing of your firewall where multiple firewall interfaces
|
||
are connected to the same HUB/Switch (all interfaces connected to the
|
||
single HUB/Switch should have this option specified). Note that using
|
||
such a configuration in a production environment is strongly
|
||
recommended against. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The ADDRESS column in
|
||
/etc/shorewall/masq may now include a comma-separated list of addresses
|
||
and/or address ranges. Netfilter will use all listed addresses/ranges
|
||
in round-robin fashion. \ </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">An /etc/shorewall/accounting file
|
||
has been added to allow for traffic accounting. See the <a
|
||
href="http://Accounting.html/">accounting documentation</a> for a
|
||
description of this facility. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Bridge interfaces (br[0-9]) may now
|
||
be used in /etc/shorewall/maclist. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">ACCEPT, DNAT[-], REDIRECT[-] and LOG
|
||
rules defined in /etc/shorewall/rules may now be rate-limited. For DNAT
|
||
and REDIRECT rules, rate limiting occurs in the nat table DNAT rule;
|
||
the corresponding ACCEPT rule in the filter table is not rate limited.
|
||
If you want to limit the filter table rule, you will need o create two
|
||
rules; a DNAT- rule and an ACCEPT rule which can be rate-limited
|
||
separately.<br>
|
||
<br>
|
||
<b>Warning:</b> When rate limiting is specified on a rule with
|
||
"all" in the SOURCE or DEST fields, the limit will apply to each pair
|
||
of zones individually rather than as a single limit for all pairs of
|
||
covered by the rule.<br>
|
||
<br>
|
||
To specify a rate limit,<br>
|
||
<br>
|
||
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
||
<br>
|
||
<
|
||
<rate>/<interval>[:<burst>] ><br>
|
||
<br>
|
||
where<br>
|
||
<br>
|
||
<rate> is the sustained rate per
|
||
<interval><br>
|
||
<interval> is "sec" or "min"<br>
|
||
<burst> is the largest burst
|
||
accepted within an <interval>. If not given, the default of 5 is
|
||
assumed.<br>
|
||
<br>
|
||
There may be no white space between the ACTION and "<" nor there may
|
||
be any white space within the burst specification. If you want to
|
||
specify logging of a rate-limited rule, the ":" and log level comes
|
||
after the ">" (e.g., ACCEPT<2/sec:4>:info ).<br>
|
||
<br>
|
||
b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
|
||
file. You may specify the rate limit there in the format:<br>
|
||
<br>
|
||
|
||
<rate>/<interval>[:<burst>]<br>
|
||
<br>
|
||
Let's take an example:<br>
|
||
<br>
|
||
|
||
ACCEPT<2/sec:4>
|
||
net dmz
|
||
tcp 80<br>
|
||
<br>
|
||
The first time this rule is reached, the packet will be accepted; in
|
||
fact, since the burst is 4, the first four packets will be accepted.
|
||
After this, it will be 500ms (1 second divided by the rate<br>
|
||
of 2) before a packet will be accepted from this rule, regardless of
|
||
how many packets reach it. Also, every 500ms which passes without
|
||
matching a packet, one of the bursts will be regained; if no packets
|
||
hit the rule for 2 second, the burst will be fully recharged; back
|
||
where we started.</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Multiple chains may now be displayed
|
||
in one "shorewall show" command (e.g., shorewall show INPUT FORWARD
|
||
OUTPUT). </p>
|
||
</li>
|
||
<li>
|
||
<p>Output rules (those with $FW as the SOURCE) may now be limited
|
||
to a set of local users and/or groups. See <a
|
||
href="http://UserSets.html/">http://shorewall.net/UserSets.html</a>
|
||
for details.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>8/13/2003 - Snapshot 1.4.6_20030813</b> </p>
|
||
<blockquote><a href="http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
|
||
<a href="ftp://shorewall.net/pub/shorewall/Snapshots/" target="_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></blockquote>
|
||
<p><b>Problems Corrected since version 1.4.6</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected problem in 1.4.6 where the
|
||
MANGLE_ENABLED variable was being tested before it was set. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected handling of MAC addresses
|
||
in the SOURCE column of the tcrules file. Previously, these addresses
|
||
resulted in an invalid iptables command. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The "shorewall stop" command is now
|
||
disabled when /etc/shorewall/startup_disabled exists. This prevents
|
||
people from shooting themselves in the foot prior to having configured
|
||
Shorewall. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A change introduced in version 1.4.6
|
||
caused error messages during "shorewall [re]start" when
|
||
ADD_IP_ALIASES=Yes and ip addresses were being added to a PPP
|
||
interface; the addresses were successfully added in spite of the
|
||
messages.<br>
|
||
<br>
|
||
The firewall script has been modified to eliminate the error messages </p>
|
||
</li>
|
||
<li>
|
||
<p> Interface-specific dynamic blacklisting chains are now
|
||
displayed by "shorewall monitor" on the "Dynamic Chains" page
|
||
(previously named "Dynamic Chain").</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>Migration Issues:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Once you have installed this version
|
||
of Shorewall, you must restart Shorewall before you may use the 'drop',
|
||
'reject', 'allow' or 'save' commands. </p>
|
||
</li>
|
||
<li>
|
||
<p>To maintain strict compatibility with previous versions, current
|
||
uses of "shorewall drop" and "shorewall reject" should be replaced with
|
||
"shorewall dropall" and "shorewall rejectall" </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>New Features:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall now creates a dynamic
|
||
blacklisting chain for each interface defined in
|
||
/etc/shorewall/interfaces. The 'drop' and 'reject' commands use the
|
||
routing table to determine which of these chains is to be used for
|
||
blacklisting the specified IP address(es).<br>
|
||
<br>
|
||
Two new commands ('dropall' and 'rejectall') have been introduced that
|
||
do what 'drop' and 'reject' used to do; namely, when an address is
|
||
blacklisted using these new commands, it will be blacklisted on all of
|
||
your firewall's interfaces. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Thanks to Steve Herber, the 'help'
|
||
command can now give command-specific help (e.g., shorewall help
|
||
<command>). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A new option "ADMINISABSENTMINDED"
|
||
has been added to /etc/shorewall/shorewall.conf. This option has a
|
||
default value of "No" for existing users which causes Shorewall's
|
||
'stopped' state to continue as it has been; namely, in the
|
||
stopped state only traffic to/from hosts listed in
|
||
/etc/shorewall/routestopped is accepted.<br>
|
||
<br>
|
||
With ADMINISABSENTMINDED=Yes (the default for new installs), in
|
||
addition to traffic to/from the hosts listed in
|
||
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
||
<br>
|
||
a) All traffic originating from the firewall itself; and<br>
|
||
b) All traffic that is part of or related to an
|
||
already-existing connection.<br>
|
||
<br>
|
||
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
|
||
entered through an ssh session will not kill the session.<br>
|
||
<br>
|
||
Note though that even with ADMINISABSENTMINDED=Yes, it is still
|
||
possible for people to shoot themselves in the foot.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
/etc/shorewall/nat:<br>
|
||
<br>
|
||
206.124.146.178
|
||
eth0:0 192.168.1.5 <br>
|
||
<br>
|
||
/etc/shorewall/rules:<br>
|
||
<br>
|
||
ACCEPT net
|
||
loc:192.168.1.5 tcp 22<br>
|
||
ACCEPT loc
|
||
fw tcp 22<br>
|
||
<br>
|
||
From a remote system, I ssh to 206.124.146.178 which establishes an SSH
|
||
connection with local system 192.168.1.5. I then create a second SSH
|
||
connection from that computer to the firewall and confidently type
|
||
"shorewall stop". As part of its stop processing, Shorewall removes
|
||
eth0:0 which kills my SSH connection to 192.168.1.5!!! </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Given the wide range of VPN
|
||
software, I can never hope to add specific support for all of it. I
|
||
have therefore decided to add "generic" tunnel support.<br>
|
||
<br>
|
||
Generic tunnels work pretty much like any of the other tunnel types.
|
||
You usually add a zone to represent the systems at the other end of the
|
||
tunnel and you add the appropriate rules/policies to<br>
|
||
implement your security policy regarding traffic to/from those systems.<br>
|
||
<br>
|
||
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
|
||
<br>
|
||
generic:<protocol>[:<port>] <zone> <ip
|
||
address> <gateway zones><br>
|
||
<br>
|
||
where:<br>
|
||
<br>
|
||
<protocol> is the protocol
|
||
used by the tunnel<br>
|
||
<port> if the protocol
|
||
is 'udp' or 'tcp' then this is the destination port number used by the
|
||
tunnel.<br>
|
||
<zone> is the zone of
|
||
the remote tunnel gateway<br>
|
||
<ip address> is the IP
|
||
address of the remote tunnel gateway.<br>
|
||
<gateway zone>
|
||
Optional. A comma-separated list of zone names. If specified, the
|
||
remote gateway is to be considered part of these zones. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">An 'arp_filter' option has been
|
||
added to the /etc/shorewall/interfaces file. This option causes
|
||
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
|
||
result that this interface will only answer ARP 'who-has' requests from
|
||
hosts that are routed out through that interface. Setting this option
|
||
facilitates testing of your firewall where multiple firewall interfaces
|
||
are connected to the same HUB/Switch (all interfaces connected to the
|
||
single HUB/Switch should have this option specified). Note that using
|
||
such a configuration in a production environment is strongly
|
||
recommended against. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The ADDRESS column in
|
||
/etc/shorewall/masq may now include a comma-separated list of addresses
|
||
and/or address ranges. Netfilter will use all listed addresses/ranges
|
||
in round-robin fashion. \ </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">An /etc/shorewall/accounting file
|
||
has been added to allow for traffic accounting. See the <a
|
||
href="http://Accounting.html/">accounting documentation</a> for a
|
||
description of this facility. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Bridge interfaces (br[0-9]) may now
|
||
be used in /etc/shorewall/maclist. </p>
|
||
</li>
|
||
<li>
|
||
<p>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
|
||
/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
|
||
rules, rate limiting occurs in the nat table DNAT rule; the
|
||
corresponding ACCEPT rule in the filter table is not rate limited. If
|
||
you want to limit the filter table rule, you will need o create two
|
||
rules; a DNAT- rule and an ACCEPT rule which can be rate-limited
|
||
separately.<br>
|
||
<br>
|
||
<b>Warning:</b> When rate limiting is specified on a rule with
|
||
"all" in the SOURCE or DEST fields, the limit will apply to each pair
|
||
of zones individually rather than as a single limit for all pairs of
|
||
covered by the rule.<br>
|
||
<br>
|
||
To specify a rate limit, follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
||
<br>
|
||
<
|
||
<rate>/<interval>[:<burst>] ><br>
|
||
<br>
|
||
where<br>
|
||
<br>
|
||
<rate> is the sustained rate per
|
||
<interval><br>
|
||
<interval> is "sec" or "min"<br>
|
||
<burst> is the largest burst
|
||
accepted within an <interval>. If not given, the default of 5 is
|
||
assumed.<br>
|
||
<br>
|
||
There may be no white space between the ACTION and "<" nor there may
|
||
be any white space within the burst specification. If you want to
|
||
specify logging of a rate-limited rule, the ":" and log level comes
|
||
after the ">" (e.g., ACCEPT<2/sec:4>:info ).<br>
|
||
<br>
|
||
Let's take an example:<br>
|
||
<br>
|
||
|
||
ACCEPT<2/sec:4>
|
||
net dmz
|
||
tcp 80<br>
|
||
<br>
|
||
The first time this rule is reached, the packet will be accepted; in
|
||
fact, since the burst is 4, the first four packets will be accepted.
|
||
After this, it will be 500ms (1 second divided by the rate<br>
|
||
of 2) before a packet will be accepted from this rule, regardless of
|
||
how many packets reach it. Also, every 500ms which passes without
|
||
matching a packet, one of the bursts will be regained; if no packets
|
||
hit the rule for 2 second, the burst will be fully recharged; back
|
||
where we started.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>8/9/2003 - Snapshot 1.4.6_20030809</b> </p>
|
||
<blockquote><a href="http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
|
||
<a href="ftp://shorewall.net/pub/shorewall/Snapshots/" target="_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></blockquote>
|
||
<p><b>Problems Corrected since version 1.4.6</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected problem in 1.4.6 where the
|
||
MANGLE_ENABLED variable was being tested before it was set. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected handling of MAC addresses
|
||
in the SOURCE column of the tcrules file. Previously, these addresses
|
||
resulted in an invalid iptables command. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The "shorewall stop" command is now
|
||
disabled when /etc/shorewall/startup_disabled exists. This prevents
|
||
people from shooting themselves in the foot prior to having configured
|
||
Shorewall. </p>
|
||
</li>
|
||
<li>
|
||
<p>A change introduced in version 1.4.6 caused error messages
|
||
during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses
|
||
were being added to a PPP interface; the addresses were successfully
|
||
added in spite of the messages.<br>
|
||
<br>
|
||
The firewall script has been modified to eliminate the error messages</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>Migration Issues:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Once you have installed this version
|
||
of Shorewall, you must restart Shorewall before you may use the 'drop',
|
||
'reject', 'allow' or 'save' commands. </p>
|
||
</li>
|
||
<li>
|
||
<p>To maintain strict compatibility with previous versions, current
|
||
uses of "shorewall drop" and "shorewall reject" should be replaced with
|
||
"shorewall dropall" and "shorewall rejectall" </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>New Features:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall now creates a dynamic
|
||
blacklisting chain for each interface defined in
|
||
/etc/shorewall/interfaces. The 'drop' and 'reject' commands use the
|
||
routing table to determine which of these chains is to be used for
|
||
blacklisting the specified IP address(es).<br>
|
||
<br>
|
||
Two new commands ('dropall' and 'rejectall') have been introduced that
|
||
do what 'drop' and 'reject' used to do; namely, when an address is
|
||
blacklisted using these new commands, it will be blacklisted on all of
|
||
your firewall's interfaces. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Thanks to Steve Herber, the 'help'
|
||
command can now give command-specific help (e.g., shorewall help
|
||
<command>). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A new option "ADMINISABSENTMINDED"
|
||
has been added to /etc/shorewall/shorewall.conf. This option has a
|
||
default value of "No" for existing users which causes Shorewall's
|
||
'stopped' state to continue as it has been; namely, in the
|
||
stopped state only traffic to/from hosts listed in
|
||
/etc/shorewall/routestopped is accepted.<br>
|
||
<br>
|
||
With ADMINISABSENTMINDED=Yes (the default for new installs), in
|
||
addition to traffic to/from the hosts listed in
|
||
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
||
<br>
|
||
a) All traffic originating from the firewall itself; and<br>
|
||
b) All traffic that is part of or related to an
|
||
already-existing connection.<br>
|
||
<br>
|
||
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
|
||
entered through an ssh session will not kill the session.<br>
|
||
<br>
|
||
Note though that even with ADMINISABSENTMINDED=Yes, it is still
|
||
possible for people to shoot themselves in the foot.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
/etc/shorewall/nat:<br>
|
||
<br>
|
||
206.124.146.178
|
||
eth0:0 192.168.1.5 <br>
|
||
<br>
|
||
/etc/shorewall/rules:<br>
|
||
<br>
|
||
ACCEPT net
|
||
loc:192.168.1.5 tcp 22<br>
|
||
ACCEPT loc
|
||
fw tcp 22<br>
|
||
<br>
|
||
From a remote system, I ssh to 206.124.146.178 which establishes an SSH
|
||
connection with local system 192.168.1.5. I then create a second SSH
|
||
connection from that computer to the firewall and confidently type
|
||
"shorewall stop". As part of its stop processing, Shorewall removes
|
||
eth0:0 which kills my SSH connection to 192.168.1.5!!! </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Given the wide range of VPN
|
||
software, I can never hope to add specific support for all of it. I
|
||
have therefore decided to add "generic" tunnel support.<br>
|
||
<br>
|
||
Generic tunnels work pretty much like any of the other tunnel types.
|
||
You usually add a zone to represent the systems at the other end of the
|
||
tunnel and you add the appropriate rules/policies to<br>
|
||
implement your security policy regarding traffic to/from those systems.<br>
|
||
<br>
|
||
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
|
||
<br>
|
||
generic:<protocol>[:<port>] <zone> <ip
|
||
address> <gateway zones><br>
|
||
<br>
|
||
where:<br>
|
||
<br>
|
||
<protocol> is the protocol
|
||
used by the tunnel<br>
|
||
<port> if the protocol
|
||
is 'udp' or 'tcp' then this is the destination port number used by the
|
||
tunnel.<br>
|
||
<zone> is the zone of
|
||
the remote tunnel gateway<br>
|
||
<ip address> is the IP
|
||
address of the remote tunnel gateway.<br>
|
||
<gateway zone>
|
||
Optional. A comma-separated list of zone names. If specified, the
|
||
remote gateway is to be considered part of these zones. </p>
|
||
</li>
|
||
<li>
|
||
<p>An 'arp_filter' option has been added to the
|
||
/etc/shorewall/interfaces file. This option causes
|
||
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
|
||
result that this interface will only answer ARP 'who-has' requests from
|
||
hosts that are routed out through that interface. Setting this option
|
||
facilitates testing of your firewall where multiple firewall interfaces
|
||
are connected to the same HUB/Switch (all interfaces connected to the
|
||
single HUB/Switch should have this option specified). Note that using
|
||
such a configuration in a production environment is strongly
|
||
recommended against.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>8/5/2003 - Shorewall-1.4.6b</b> </p>
|
||
<p><b>Problems Corrected since version 1.4.6:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Previously, if TC_ENABLED is set to
|
||
yes in shorewall.conf then Shorewall would fail to start with the error
|
||
"ERROR: Traffic Control requires Mangle"; that problem has been
|
||
corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected handling of MAC addresses
|
||
in the SOURCE column of the tcrules file. Previously, these addresses
|
||
resulted in an invalid iptables command. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The "shorewall stop" command is now
|
||
disabled when /etc/shorewall/startup_disabled exists. This prevents
|
||
people from shooting themselves in the foot prior to having configured
|
||
Shorewall. </p>
|
||
</li>
|
||
<li>
|
||
<p>A change introduced in version 1.4.6 caused error messages
|
||
during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses
|
||
were being added to a PPP interface; the addresses were successfully
|
||
added in spite of the messages.<br>
|
||
<br>
|
||
The firewall script has been modified to eliminate the error messages. </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>8/5/2003 - Shorewall-1.4.6b</b> </p>
|
||
<p><b>Problems Corrected since version 1.4.6:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Previously, if TC_ENABLED is set to
|
||
yes in shorewall.conf then Shorewall would fail to start with the error
|
||
"ERROR: Traffic Control requires Mangle"; that problem has been
|
||
corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected handling of MAC addresses
|
||
in the SOURCE column of the tcrules file. Previously, these addresses
|
||
resulted in an invalid iptables command. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The "shorewall stop" command is now
|
||
disabled when /etc/shorewall/startup_disabled exists. This prevents
|
||
people from shooting themselves in the foot prior to having configured
|
||
Shorewall. </p>
|
||
</li>
|
||
<li>
|
||
<p>A change introduced in version 1.4.6 caused error messages
|
||
during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses
|
||
were being added to a PPP interface; the addresses were successfully
|
||
added in spite of the messages.<br>
|
||
<br>
|
||
The firewall script has been modified to eliminate the error messages.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>7/31/2003 - Snapshot 1.4.6_20030731</b> </p>
|
||
<blockquote><a href="http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
|
||
<a href="ftp://shorewall.net/pub/shorewall/Snapshots/" target="_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></blockquote>
|
||
<p><b>Problems Corrected since version 1.4.6:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected problem in 1.4.6 where the
|
||
MANGLE_ENABLED variable was being tested before it was set. </p>
|
||
</li>
|
||
<li>
|
||
<p>Corrected handling of MAC addresses in the SOURCE column of the
|
||
tcrules file. Previously, these addresses resulted in an invalid
|
||
iptables command.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>Migration Issues:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Once you have installed this version
|
||
of Shorewall, you must restart Shorewall before you may use the 'drop',
|
||
'reject', 'allow' or 'save' commands. </p>
|
||
</li>
|
||
<li>
|
||
<p>To maintain strict compatibility with previous versions, current
|
||
uses of "shorewall drop" and "shorewall reject" should be replaced with
|
||
"shorewall dropall" and "shorewall rejectall" </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>New Features:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall now creates a dynamic
|
||
blacklisting chain for each interface defined in
|
||
/etc/shorewall/interfaces. The 'drop' and 'reject' commands use the
|
||
routing table to determine which of these chains is to be used for
|
||
blacklisting the specified IP address(es).<br>
|
||
<br>
|
||
Two new commands ('dropall' and 'rejectall') have been introduced that
|
||
do what 'drop' and 'reject' used to do; namely, when an address is
|
||
blacklisted using these new commands, it will be blacklisted on all of
|
||
your firewall's interfaces. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Thanks to Steve Herber, the 'help'
|
||
command can now give command-specific help (e.g., shorewall help
|
||
<command>). </p>
|
||
</li>
|
||
<li>
|
||
<p>A new option "ADMINISABSENTMINDED" has been added to
|
||
/etc/shorewall/shorewall.conf. This option has a default value of "No"
|
||
for existing users which causes Shorewall's 'stopped' state to
|
||
continue as it has been; namely, in the stopped state only traffic
|
||
to/from hosts listed in /etc/shorewall/routestopped is accepted.<br>
|
||
<br>
|
||
With ADMINISABSENTMINDED=Yes (the default for new installs), in
|
||
addition to traffic to/from the hosts listed in
|
||
/etc/shorewall/routestopped, Shorewall will allow:<br>
|
||
<br>
|
||
a) All traffic originating from the firewall itself; and<br>
|
||
b) All traffic that is part of or related to an
|
||
already-existing connection.<br>
|
||
<br>
|
||
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
|
||
entered through an ssh session will not kill the session.<br>
|
||
<br>
|
||
Note though that even with ADMINISABSENTMINDED=Yes, it is still
|
||
possible for people to shoot themselves in the foot.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
/etc/shorewall/nat:<br>
|
||
<br>
|
||
206.124.146.178
|
||
eth0:0 192.168.1.5 <br>
|
||
<br>
|
||
/etc/shorewall/rules:<br>
|
||
<br>
|
||
ACCEPT net
|
||
loc:192.168.1.5 tcp 22<br>
|
||
ACCEPT loc
|
||
fw tcp 22<br>
|
||
<br>
|
||
From a remote system, I ssh to 206.124.146.178 which establishes an SSH
|
||
connection with local system 192.168.1.5. I then create a second SSH
|
||
connection from that computer to the firewall and confidently type
|
||
"shorewall stop". As part of its stop processing, Shorewall removes
|
||
eth0:0 which kills my SSH connection to 192.168.1.5!!! </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>7/27/2003 - Snapshot 1.4.6_20030727</b> </p>
|
||
<blockquote><a href="http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
|
||
<a href="ftp://shorewall.net/pub/shorewall/Snapshots/" target="_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></blockquote>
|
||
<p><b>Problems Corrected since version 1.4.6</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected problem in 1.4.6 where the
|
||
MANGLE_ENABLED variable was being tested before it was set. </p>
|
||
</li>
|
||
<li>
|
||
<p>Corrected handling of MAC addresses in the SOURCE column of the
|
||
tcrules file. Previously, these addresses resulted in an invalid
|
||
iptables command.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>Migration Issues:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Once you have installed this version
|
||
of Shorewall, you must restart Shorewall before you may use the 'drop',
|
||
'reject', 'allow' or 'save' commands. </p>
|
||
</li>
|
||
<li>
|
||
<p>To maintain strict compatibility with previous versions, current
|
||
uses of "shorewall drop" and "shorewall reject" should be replaced with
|
||
"shorewall dropall" and "shorewall rejectall" </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>New Features:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall now creates a dynamic
|
||
blacklisting chain for each interface defined in
|
||
/etc/shorewall/interfaces. The 'drop' and 'reject' commands use the
|
||
routing table to determine which of these chains is to be used for
|
||
blacklisting the specified IP address(es).<br>
|
||
<br>
|
||
Two new commands ('dropall' and 'rejectall') have been introduced that
|
||
do what 'drop' and 'reject' used to do; namely, when an address is
|
||
blacklisted using these new commands, it will be blacklisted on all of
|
||
your firewall's interfaces. </p>
|
||
</li>
|
||
<li>
|
||
<p>Thanks to Steve Herber, the 'help' command can now give
|
||
command-specific help (e.g., shorewall help <command>).</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>7/26/2003 - Snapshot 1.4.6_20030726</b></p>
|
||
<blockquote><a href="http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
|
||
<a href="ftp://shorewall.net/pub/shorewall/Snapshots/" target="_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></blockquote>
|
||
<p><b>Problems Corrected since version 1.4.6:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected problem in 1.4.6 where the
|
||
MANGLE_ENABLED variable was being tested before it was set. </p>
|
||
</li>
|
||
<li>
|
||
<p>Corrected handling of MAC addresses in the SOURCE column of the
|
||
tcrules file. Previously, these addresses resulted in an invalid
|
||
iptables command.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>Migration Issues:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Once you have installed this version
|
||
of Shorewall, you must restart Shorewall before you may use the 'drop',
|
||
'reject', 'allow' or 'save' commands. </p>
|
||
</li>
|
||
<li>
|
||
<p>To maintain strict compatibility with previous versions, current
|
||
uses of "shorewall drop" and "shorewall reject" should be replaced with
|
||
"shorewall dropall" and "shorewall rejectall" </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>New Features:</b></p>
|
||
<p>Shorewall now creates a dynamic blacklisting chain for each
|
||
interface defined in /etc/shorewall/interfaces. The 'drop' and
|
||
'reject' commands use the routing table to determine which of these
|
||
chains is to be used for blacklisting the specified IP
|
||
address(es).<br>
|
||
<br>
|
||
Two new commands ('dropall' and 'rejectall') have
|
||
been introduced that do what 'drop' and 'reject' used to do; namely,
|
||
when an address is blacklisted using these new commands, it will be
|
||
blacklisted on all of your firewall's interfaces. </p>
|
||
<p><b>7/22/2003 - Shorewall-1.4.6a</b> </p>
|
||
<p><b>Problems Corrected:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p>Previously, if TC_ENABLED is set to yes in shorewall.conf then
|
||
Shorewall would fail to start with the error "ERROR: Traffic
|
||
Control requires Mangle"; that problem has been corrected. </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>7/20/2003 - Shorewall-1.4.6</b> </p>
|
||
<p><b>Problems Corrected:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p>A problem seen on RH7.3 systems where Shorewall encountered
|
||
start errors when started using the "service" mechanism has been worked
|
||
around.</p>
|
||
</li>
|
||
<li>
|
||
<p>Where a list of IP addresses appears in the DEST column of a
|
||
DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the
|
||
nat table (one for each element in the list). Shorewall now correctly
|
||
creates a single DNAT rule with multiple "--to-destination" clauses.</p>
|
||
</li>
|
||
<li>
|
||
<p>Corrected a problem in Beta 1 where DNS names containing a "-"
|
||
were mis-handled when they appeared in the DEST column of a rule.</p>
|
||
</li>
|
||
<li>
|
||
<p>A number of problems with rule parsing have been corrected.
|
||
Corrections involve the handling of "z1!z2" in the SOURCE column as
|
||
well as lists in the ORIGINAL DESTINATION column.</p>
|
||
</li>
|
||
<li>
|
||
<p>The message "Adding rules for DHCP" is now suppressed if there
|
||
are no DHCP rules to add.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>Migration Issues:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p>In earlier versions, an undocumented feature allowed entries in
|
||
the host file as follows:<br>
|
||
<br>
|
||
z
|
||
eth1:192.168.1.0/24,eth2:192.168.2.0/24<br>
|
||
<br>
|
||
This capability was never documented and has been removed in 1.4.6 to
|
||
allow entries of the following format:<br>
|
||
<br>
|
||
z eth1:192.168.1.0/24,192.168.2.0/24</p>
|
||
</li>
|
||
<li>
|
||
<p>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been
|
||
removed from /etc/shorewall/shorewall.conf. These capabilities are now
|
||
automatically detected by Shorewall (see below).</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>New Features:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p>A 'newnotsyn' interface option has been added. This option may
|
||
be specified in /etc/shorewall/interfaces and overrides the setting
|
||
NEWNOTSYN=No for packets arriving on the associated interface.</p>
|
||
</li>
|
||
<li>
|
||
<p>The means for specifying a range of IP addresses in
|
||
/etc/shorewall/masq to use for SNAT is now documented.
|
||
ADD_SNAT_ALIASES=Yes is enabled for address ranges.</p>
|
||
</li>
|
||
<li>
|
||
<p>Shorewall can now add IP addresses to subnets other than the
|
||
first one on an interface.</p>
|
||
</li>
|
||
<li>
|
||
<p>DNAT[-] rules may now be used to load balance (round-robin) over
|
||
a set of servers. Servers may be specified in a range of addresses
|
||
given as <first address>-<last address>.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
DNAT net loc:192.168.10.2-192.168.10.5 tcp 80</p>
|
||
</li>
|
||
<li>
|
||
<p>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration
|
||
options have been removed and have been replaced by code that detects
|
||
whether these capabilities are present in the current kernel. The
|
||
output of the start, restart and check commands have been enhanced to
|
||
report the outcome:<br>
|
||
<br>
|
||
Shorewall has detected the following iptables/netfilter capabilities:<br>
|
||
NAT: Available<br>
|
||
Packet Mangling: Available<br>
|
||
Multi-port Match: Available<br>
|
||
Verifying Configuration...</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Support for the Connection Tracking
|
||
Match Extension has been added. This extension is available in recent
|
||
kernel/iptables releases and allows for rules which match against
|
||
elements in netfilter's connection tracking table. Shorewall
|
||
automatically detects the availability of this extension and reports
|
||
its availability in the output of the start, restart and check commands.<br>
|
||
<br>
|
||
Shorewall has detected the following iptables/netfilter capabilities:<br>
|
||
NAT: Available<br>
|
||
Packet Mangling: Available<br>
|
||
Multi-port Match: Available<br>
|
||
Connection Tracking Match: Available<br>
|
||
Verifying Configuration...<br>
|
||
<br>
|
||
If this extension is available, the ruleset generated by Shorewall is
|
||
changed in the following ways: </p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">To handle 'norfc1918' filtering,
|
||
Shorewall will not create chains in the mangle table but will rather do
|
||
all 'norfc1918' filtering in the filter table (rfc1918 chain). </p>
|
||
</li>
|
||
<li>
|
||
<p>Recall that Shorewall DNAT rules generate two netfilter
|
||
rules; one in the nat table and one in the filter table. If the
|
||
Connection Tracking Match Extension is available, the rule in the
|
||
filter table is extended to check that the original destination address
|
||
was the same as specified (or defaulted to) in the DNAT rule.</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p>The shell used to interpret the firewall script
|
||
(/usr/share/shorewall/firewall) may now be specified using the
|
||
SHOREWALL_SHELL parameter in shorewall.conf.</p>
|
||
</li>
|
||
<li>
|
||
<p>An 'ipcalc' command has been added to /sbin/shorewall.<br>
|
||
<br>
|
||
ipcalc [ <address> <netmask>
|
||
| <address>/<vlsm> ]<br>
|
||
<br>
|
||
Examples:<br>
|
||
<br>
|
||
[root@wookie root]# shorewall ipcalc
|
||
192.168.1.0/24<br>
|
||
CIDR=192.168.1.0/24<br>
|
||
NETMASK=255.255.255.0<br>
|
||
NETWORK=192.168.1.0<br>
|
||
BROADCAST=192.168.1.255<br>
|
||
[root@wookie root]#<br>
|
||
<br>
|
||
[root@wookie root]# shorewall ipcalc
|
||
192.168.1.0 255.255.255.0<br>
|
||
CIDR=192.168.1.0/24<br>
|
||
NETMASK=255.255.255.0<br>
|
||
NETWORK=192.168.1.0<br>
|
||
BROADCAST=192.168.1.255<br>
|
||
[root@wookie root]#<br>
|
||
<br>
|
||
Warning:<br>
|
||
<br>
|
||
If your shell only supports 32-bit signed arithmatic (ash or dash),
|
||
then the ipcalc command produces incorrect information for IP addresses
|
||
128.0.0.0-1 and for /1 networks. Bash should produce correct
|
||
information for all valid IP addresses.</p>
|
||
</li>
|
||
<li>
|
||
<p>An 'iprange' command has been added to /sbin/shorewall.<br>
|
||
<br>
|
||
iprange <address>-<address><br>
|
||
<br>
|
||
This command decomposes a range of IP addressses into a list of network
|
||
and host addresses. The command can be useful if you need to construct
|
||
an efficient set of rules that accept connections from a range of
|
||
network addresses.<br>
|
||
<br>
|
||
Note: If your shell only supports 32-bit signed arithmetic (ash or
|
||
dash) then the range may not span 128.0.0.0.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
[root@gateway root]# shorewall iprange
|
||
192.168.1.4-192.168.12.9<br>
|
||
192.168.1.4/30<br>
|
||
192.168.1.8/29<br>
|
||
192.168.1.16/28<br>
|
||
192.168.1.32/27<br>
|
||
192.168.1.64/26<br>
|
||
192.168.1.128/25<br>
|
||
192.168.2.0/23<br>
|
||
192.168.4.0/22<br>
|
||
192.168.8.0/22<br>
|
||
192.168.12.0/29<br>
|
||
192.168.12.8/31<br>
|
||
[root@gateway root]#</p>
|
||
</li>
|
||
<li>
|
||
<p>A list of host/net addresses is now allowed in an entry in
|
||
/etc/shorewall/hosts.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
foo
|
||
eth1:192.168.1.0/24,192.168.2.0/24</p>
|
||
</li>
|
||
<li>
|
||
<p>The "shorewall check" command now includes the chain name when
|
||
printing the applicable policy for each pair of zones.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
Policy for dmz to net is
|
||
REJECT using chain all2all<br>
|
||
<br>
|
||
This means that the policy for connections from the dmz to the internet
|
||
is REJECT and the applicable entry in the /etc/shorewall/policy was the
|
||
all->all policy.</p>
|
||
</li>
|
||
<li>
|
||
<p>Support for the 2.6 Kernel series has been added.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>7/15/2003 - New Mirror in Brazil</b></p>
|
||
<p>Thanks to the folks at securityopensource.org.br, there is now a
|
||
<a href="http://shorewall.securityopensource.org.br/" target="_top">Shorewall
|
||
mirror in Brazil</a>. </p>
|
||
<p><b>7/15/2003 - Shorewall-1.4.6 RC 1</b> </p>
|
||
<p><b>Problems Corrected:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p>A problem seen on RH7.3 systems where Shorewall encountered
|
||
start errors when started using the "service" mechanism has been worked
|
||
around.</p>
|
||
</li>
|
||
<li>
|
||
<p>Where a list of IP addresses appears in the DEST column of a
|
||
DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the
|
||
nat table (one for each element in the list). Shorewall now correctly
|
||
creates a single DNAT rule with multiple "--to-destination" clauses.</p>
|
||
</li>
|
||
<li>
|
||
<p>Corrected a problem in Beta 1 where DNS names containing a "-"
|
||
were mis-handled when they appeared in the DEST column of a rule.</p>
|
||
</li>
|
||
<li>
|
||
<p>A number of problems with rule parsing have been corrected.
|
||
Corrections involve the handling of "z1!z2" in the SOURCE column as
|
||
well as lists in the ORIGINAL DESTINATION column.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>Migration Issues:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p>In earlier versions, an undocumented feature allowed entries in
|
||
the host file as follows:<br>
|
||
<br>
|
||
z
|
||
eth1:192.168.1.0/24,eth2:192.168.2.0/24<br>
|
||
<br>
|
||
This capability was never documented and has been removed in 1.4.6 to
|
||
allow entries of the following format:<br>
|
||
<br>
|
||
z eth1:192.168.1.0/24,192.168.2.0/24</p>
|
||
</li>
|
||
<li>
|
||
<p>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been
|
||
removed from /etc/shorewall/shorewall.conf. These capabilities are now
|
||
automatically detected by Shorewall (see below).</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>New Features:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p>A 'newnotsyn' interface option has been added. This option may
|
||
be specified in /etc/shorewall/interfaces and overrides the setting
|
||
NEWNOTSYN=No for packets arriving on the associated interface.</p>
|
||
</li>
|
||
<li>
|
||
<p>The means for specifying a range of IP addresses in
|
||
/etc/shorewall/masq to use for SNAT is now documented.
|
||
ADD_SNAT_ALIASES=Yes is enabled for address ranges.</p>
|
||
</li>
|
||
<li>
|
||
<p>Shorewall can now add IP addresses to subnets other than the
|
||
first one on an interface.</p>
|
||
</li>
|
||
<li>
|
||
<p>DNAT[-] rules may now be used to load balance (round-robin) over
|
||
a set of servers. Servers may be specified in a range of addresses
|
||
given as <first address>-<last address>.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
DNAT net loc:192.168.10.2-192.168.10.5 tcp 80</p>
|
||
</li>
|
||
<li>
|
||
<p>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration
|
||
options have been removed and have been replaced by code that detects
|
||
whether these capabilities are present in the current kernel. The
|
||
output of the start, restart and check commands have been enhanced to
|
||
report the outcome:<br>
|
||
<br>
|
||
Shorewall has detected the following iptables/netfilter capabilities:<br>
|
||
NAT: Available<br>
|
||
Packet Mangling: Available<br>
|
||
Multi-port Match: Available<br>
|
||
Verifying Configuration...</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Support for the Connection Tracking
|
||
Match Extension has been added. This extension is available in recent
|
||
kernel/iptables releases and allows for rules which match against
|
||
elements in netfilter's connection tracking table. Shorewall
|
||
automatically detects the availability of this extension and reports
|
||
its availability in the output of the start, restart and check commands.<br>
|
||
<br>
|
||
Shorewall has detected the following iptables/netfilter capabilities:<br>
|
||
NAT: Available<br>
|
||
Packet Mangling: Available<br>
|
||
Multi-port Match: Available<br>
|
||
Connection Tracking Match: Available<br>
|
||
Verifying Configuration...<br>
|
||
<br>
|
||
If this extension is available, the ruleset generated by Shorewall is
|
||
changed in the following ways: </p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">To handle 'norfc1918' filtering,
|
||
Shorewall will not create chains in the mangle table but will rather do
|
||
all 'norfc1918' filtering in the filter table (rfc1918 chain). </p>
|
||
</li>
|
||
<li>
|
||
<p>Recall that Shorewall DNAT rules generate two netfilter
|
||
rules; one in the nat table and one in the filter table. If the
|
||
Connection Tracking Match Extension is available, the rule in the
|
||
filter table is extended to check that the original destination address
|
||
was the same as specified (or defaulted to) in the DNAT rule.</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p>The shell used to interpret the firewall script
|
||
(/usr/share/shorewall/firewall) may now be specified using the
|
||
SHOREWALL_SHELL parameter in shorewall.conf.</p>
|
||
</li>
|
||
<li>
|
||
<p>An 'ipcalc' command has been added to /sbin/shorewall.<br>
|
||
<br>
|
||
ipcalc [ <address> <netmask>
|
||
| <address>/<vlsm> ]<br>
|
||
<br>
|
||
Examples:<br>
|
||
<br>
|
||
[root@wookie root]# shorewall ipcalc
|
||
192.168.1.0/24<br>
|
||
CIDR=192.168.1.0/24<br>
|
||
NETMASK=255.255.255.0<br>
|
||
NETWORK=192.168.1.0<br>
|
||
BROADCAST=192.168.1.255<br>
|
||
[root@wookie root]#<br>
|
||
<br>
|
||
[root@wookie root]# shorewall ipcalc
|
||
192.168.1.0 255.255.255.0<br>
|
||
CIDR=192.168.1.0/24<br>
|
||
NETMASK=255.255.255.0<br>
|
||
NETWORK=192.168.1.0<br>
|
||
BROADCAST=192.168.1.255<br>
|
||
[root@wookie root]#<br>
|
||
<br>
|
||
Warning:<br>
|
||
<br>
|
||
If your shell only supports 32-bit signed arithmatic (ash or dash),
|
||
then the ipcalc command produces incorrect information for IP addresses
|
||
128.0.0.0-1 and for /1 networks. Bash should produce correct
|
||
information for all valid IP addresses.</p>
|
||
</li>
|
||
<li>
|
||
<p>An 'iprange' command has been added to /sbin/shorewall.<br>
|
||
<br>
|
||
iprange <address>-<address><br>
|
||
<br>
|
||
This command decomposes a range of IP addressses into a list of network
|
||
and host addresses. The command can be useful if you need to construct
|
||
an efficient set of rules that accept connections from a range of
|
||
network addresses.<br>
|
||
<br>
|
||
Note: If your shell only supports 32-bit signed arithmetic (ash or
|
||
dash) then the range may not span 128.0.0.0.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
[root@gateway root]# shorewall iprange
|
||
192.168.1.4-192.168.12.9<br>
|
||
192.168.1.4/30<br>
|
||
192.168.1.8/29<br>
|
||
192.168.1.16/28<br>
|
||
192.168.1.32/27<br>
|
||
192.168.1.64/26<br>
|
||
192.168.1.128/25<br>
|
||
192.168.2.0/23<br>
|
||
192.168.4.0/22<br>
|
||
192.168.8.0/22<br>
|
||
192.168.12.0/29<br>
|
||
192.168.12.8/31<br>
|
||
[root@gateway root]#</p>
|
||
</li>
|
||
<li>
|
||
<p>A list of host/net addresses is now allowed in an entry in
|
||
/etc/shorewall/hosts.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
foo
|
||
eth1:192.168.1.0/24,192.168.2.0/24 </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>7/7/2003 - Shorewall-1.4.6 Beta 2</b></p>
|
||
<p><b>Problems Corrected:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p>A problem seen on RH7.3 systems where Shorewall encountered
|
||
start errors when started using the "service" mechanism has been worked
|
||
around.</p>
|
||
</li>
|
||
<li>
|
||
<p>Where a list of IP addresses appears in the DEST column of a
|
||
DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the
|
||
nat table (one for each element in the list). Shorewall now correctly
|
||
creates a single DNAT rule with multiple "--to-destination" clauses.</p>
|
||
</li>
|
||
<li>
|
||
<p>Corrected a problem in Beta 1 where DNS names containing a "-"
|
||
were mis-handled when they appeared in the DEST column of a rule.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>Migration Issues:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p>In earlier versions, an undocumented feature allowed entries in
|
||
the host file as follows:<br>
|
||
<br>
|
||
z
|
||
eth1:192.168.1.0/24,eth2:192.168.2.0/24<br>
|
||
<br>
|
||
This capability was never documented and has been removed in 1.4.6 to
|
||
allow entries of the following format:<br>
|
||
<br>
|
||
z eth1:192.168.1.0/24,192.168.2.0/24</p>
|
||
</li>
|
||
<li>
|
||
<p>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been
|
||
removed from /etc/shorewall/shorewall.conf. These capabilities are now
|
||
automatically detected by Shorewall (see below).</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>New Features:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p>A 'newnotsyn' interface option has been added. This option may
|
||
be specified in /etc/shorewall/interfaces and overrides the setting
|
||
NEWNOTSYN=No for packets arriving on the associated interface.</p>
|
||
</li>
|
||
<li>
|
||
<p>The means for specifying a range of IP addresses in
|
||
/etc/shorewall/masq to use for SNAT is now documented.
|
||
ADD_SNAT_ALIASES=Yes is enabled for address ranges.</p>
|
||
</li>
|
||
<li>
|
||
<p>Shorewall can now add IP addresses to subnets other than the
|
||
first one on an interface.</p>
|
||
</li>
|
||
<li>
|
||
<p>DNAT[-] rules may now be used to load balance (round-robin) over
|
||
a set of servers. Servers may be specified in a range of addresses
|
||
given as <first address>-<last address>.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
DNAT net loc:192.168.10.2-192.168.10.5 tcp 80</p>
|
||
</li>
|
||
<li>
|
||
<p>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration
|
||
options have been removed and have been replaced by code that detects
|
||
whether these capabilities are present in the current kernel. The
|
||
output of the start, restart and check commands have been enhanced to
|
||
report the outcome:<br>
|
||
<br>
|
||
Shorewall has detected the following iptables/netfilter capabilities:<br>
|
||
NAT: Available<br>
|
||
Packet Mangling: Available<br>
|
||
Multi-port Match: Available<br>
|
||
Verifying Configuration...</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Support for the Connection Tracking
|
||
Match Extension has been added. This extension is available in recent
|
||
kernel/iptables releases and allows for rules which match against
|
||
elements in netfilter's connection tracking table. Shorewall
|
||
automatically detects the availability of this extension and reports
|
||
its availability in the output of the start, restart and check commands.<br>
|
||
<br>
|
||
Shorewall has detected the following iptables/netfilter capabilities:<br>
|
||
NAT: Available<br>
|
||
Packet Mangling: Available<br>
|
||
Multi-port Match: Available<br>
|
||
Connection Tracking Match: Available<br>
|
||
Verifying Configuration...<br>
|
||
<br>
|
||
If this extension is available, the ruleset generated by Shorewall is
|
||
changed in the following ways: </p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">To handle 'norfc1918' filtering,
|
||
Shorewall will not create chains in the mangle table but will rather do
|
||
all 'norfc1918' filtering in the filter table (rfc1918 chain). </p>
|
||
</li>
|
||
<li>
|
||
<p>Recall that Shorewall DNAT rules generate two netfilter
|
||
rules; one in the nat table and one in the filter table. If the
|
||
Connection Tracking Match Extension is available, the rule in the
|
||
filter table is extended to check that the original destination address
|
||
was the same as specified (or defaulted to) in the DNAT rule.</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p>The shell used to interpret the firewall script
|
||
(/usr/share/shorewall/firewall) may now be specified using the
|
||
SHOREWALL_SHELL parameter in shorewall.conf.</p>
|
||
</li>
|
||
<li>
|
||
<p>An 'ipcalc' command has been added to /sbin/shorewall.<br>
|
||
<br>
|
||
ipcalc [ <address> <netmask>
|
||
| <address>/<vlsm> ]<br>
|
||
<br>
|
||
Examples:<br>
|
||
<br>
|
||
[root@wookie root]# shorewall ipcalc
|
||
192.168.1.0/24<br>
|
||
CIDR=192.168.1.0/24<br>
|
||
NETMASK=255.255.255.0<br>
|
||
NETWORK=192.168.1.0<br>
|
||
BROADCAST=192.168.1.255<br>
|
||
[root@wookie root]#<br>
|
||
<br>
|
||
[root@wookie root]# shorewall ipcalc
|
||
192.168.1.0 255.255.255.0<br>
|
||
CIDR=192.168.1.0/24<br>
|
||
NETMASK=255.255.255.0<br>
|
||
NETWORK=192.168.1.0<br>
|
||
BROADCAST=192.168.1.255<br>
|
||
[root@wookie root]#<br>
|
||
<br>
|
||
Warning:<br>
|
||
<br>
|
||
If your shell only supports 32-bit signed arithmatic (ash or dash),
|
||
then the ipcalc command produces incorrect information for IP addresses
|
||
128.0.0.0-1 and for /1 networks. Bash should produce correct
|
||
information for all valid IP addresses.</p>
|
||
</li>
|
||
<li>
|
||
<p>An 'iprange' command has been added to /sbin/shorewall.<br>
|
||
<br>
|
||
iprange <address>-<address><br>
|
||
<br>
|
||
This command decomposes a range of IP addressses into a list of network
|
||
and host addresses. The command can be useful if you need to construct
|
||
an efficient set of rules that accept connections from a range of
|
||
network addresses.<br>
|
||
<br>
|
||
Note: If your shell only supports 32-bit signed arithmetic (ash or
|
||
dash) then the range may not span 128.0.0.0.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
[root@gateway root]# shorewall iprange
|
||
192.168.1.4-192.168.12.9<br>
|
||
192.168.1.4/30<br>
|
||
192.168.1.8/29<br>
|
||
192.168.1.16/28<br>
|
||
192.168.1.32/27<br>
|
||
192.168.1.64/26<br>
|
||
192.168.1.128/25<br>
|
||
192.168.2.0/23<br>
|
||
192.168.4.0/22<br>
|
||
192.168.8.0/22<br>
|
||
192.168.12.0/29<br>
|
||
192.168.12.8/31<br>
|
||
[root@gateway root]#</p>
|
||
</li>
|
||
<li>
|
||
<p>A list of host/net addresses is now allowed in an entry in
|
||
/etc/shorewall/hosts.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
foo
|
||
eth1:192.168.1.0/24,192.168.2.0/24</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>7/4/2003 - Shorewall-1.4.6 Beta 1</b></p>
|
||
<p><b>Problems Corrected:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p>A problem seen on RH7.3 systems where Shorewall encountered
|
||
start errors when started using the "service" mechanism has been worked
|
||
around.</p>
|
||
</li>
|
||
<li>
|
||
<p>Where a list of IP addresses appears in the DEST column of a
|
||
DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the
|
||
nat table (one for each element in the list). Shorewall now correctly
|
||
creates a single DNAT rule with multiple "--to-destination" clauses.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>New Features:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p>A 'newnotsyn' interface option has been added. This option may
|
||
be specified in /etc/shorewall/interfaces and overrides the setting
|
||
NEWNOTSYN=No for packets arriving on the associated interface.</p>
|
||
</li>
|
||
<li>
|
||
<p>The means for specifying a range of IP addresses in
|
||
/etc/shorewall/masq to use for SNAT is now documented.
|
||
ADD_SNAT_ALIASES=Yes is enabled for address ranges.</p>
|
||
</li>
|
||
<li>
|
||
<p>Shorewall can now add IP addresses to subnets other than the
|
||
first one on an interface.</p>
|
||
</li>
|
||
<li>
|
||
<p>DNAT[-] rules may now be used to load balance (round-robin) over
|
||
a set of servers. Up to 256 servers may be specified in a range of
|
||
addresses given as <first address>-<last address>.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
DNAT net loc:192.168.10.2-192.168.10.5 tcp 80<br>
|
||
<br>
|
||
Note that this capability has previously been available using a
|
||
combination of a DNAT- rule and one or more ACCEPT rules. That
|
||
technique is still preferable for load-balancing over a large number of
|
||
servers (> 16) since specifying a range in the DNAT rule causes one
|
||
filter table ACCEPT rule to be generated for each IP address in the
|
||
range.</p>
|
||
</li>
|
||
<li>
|
||
<p>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration
|
||
options have been removed and have been replaced by code that detects
|
||
whether these capabilities are present in the current kernel. The
|
||
output of the start, restart and check commands have been enhanced to
|
||
report the outcome:<br>
|
||
<br>
|
||
Shorewall has detected the following iptables/netfilter capabilities:<br>
|
||
NAT: Available<br>
|
||
Packet Mangling: Available<br>
|
||
Multi-port Match: Available<br>
|
||
Verifying Configuration...</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Support for the Connection Tracking
|
||
Match Extension has been added. This extension is available in recent
|
||
kernel/iptables releases and allows for rules which match against
|
||
elements in netfilter's connection tracking table. Shorewall
|
||
automatically detects the availability of this extension and reports
|
||
its availability in the output of the start, restart and check commands.<br>
|
||
<br>
|
||
Shorewall has detected the following iptables/netfilter capabilities:<br>
|
||
NAT: Available<br>
|
||
Packet Mangling: Available<br>
|
||
Multi-port Match: Available<br>
|
||
Connection Tracking Match: Available<br>
|
||
Verifying Configuration...<br>
|
||
<br>
|
||
If this extension is available, the ruleset generated by Shorewall is
|
||
changed in the following ways: </p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">To handle 'norfc1918' filtering,
|
||
Shorewall will not create chains in the mangle table but will rather do
|
||
all 'norfc1918' filtering in the filter table (rfc1918 chain). </p>
|
||
</li>
|
||
<li>
|
||
<p>Recall that Shorewall DNAT rules generate two netfilter
|
||
rules; one in the nat table and one in the filter table. If the
|
||
Connection Tracking Match Extension is available, the rule in the
|
||
filter table is extended to check that the original destination address
|
||
was the same as specified (or defaulted to) in the DNAT rule.</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p>The shell used to interpret the firewall script
|
||
(/usr/share/shorewall/firewall) may now be specified using the
|
||
SHOREWALL_SHELL parameter in shorewall.conf.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>6/17/2003 - Shorewall-1.4.5</b></p>
|
||
<p>Problems Corrected:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The command "shorewall debug try
|
||
<directory>" now correctly traces the attempt. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The INCLUDE directive now works
|
||
properly in the zones file; previously, INCLUDE in that file was
|
||
ignored. </p>
|
||
</li>
|
||
<li>
|
||
<p>/etc/shorewall/routestopped records with an empty second column
|
||
are no longer ignored.</p>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:</p>
|
||
<ol>
|
||
<li>
|
||
<p>The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may
|
||
now contain a list of addresses. If the list begins with "!' then the
|
||
rule will take effect only if the original destination address in the
|
||
connection request does not match any of the addresses listed. </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8</b></p>
|
||
<p>The firewall at shorewall.net has been upgraded to the 2.4.21
|
||
kernel and iptables 1.2.8 (using the "official" RPM from
|
||
netfilter.org). No problems have been encountered with this set of
|
||
software. The Shorewall version is 1.4.4b plus the accumulated
|
||
changes for 1.4.5.</p>
|
||
<p><b>6/8/2003 - Updated Samples</b></p>
|
||
<p>Thanks to Francesca Smith, the samples have been updated to
|
||
Shorewall version 1.4.4.</p>
|
||
<p><b>5/29/2003 - Shorewall-1.4.4b</b></p>
|
||
<p>Groan -- This version corrects a problem whereby the --log-level
|
||
was not being set when logging via syslog. The most commonly reported
|
||
symptom was that Shorewall messages were being written to the console
|
||
even though console logging was correctly configured per FAQ 16.</p>
|
||
<p><b>5/27/2003 - Shorewall-1.4.4a</b></p>
|
||
<p>The Fireparse --log-prefix fiasco continues. Tuomo Soini has
|
||
pointed out that the code in 1.4.4 restricts the length of short zone
|
||
names to 4 characters. I've produced version 1.4.4a that restores the
|
||
previous 5-character limit by conditionally omitting the log rule
|
||
number when the LOGFORMAT doesn't contain '%d'. </p>
|
||
<p><b>5/23/2003 - Shorewall-1.4.4</b></p>
|
||
<p>I apologize for the rapid-fire releases but since there is a
|
||
potential configuration change required to go from 1.4.3a to 1.4.4, I
|
||
decided to make it a full release rather than just a bug-fix release.
|
||
<br>
|
||
<br>
|
||
<b>Problems corrected:</b></p>
|
||
<blockquote>None.</blockquote>
|
||
<p> <b>New Features:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p>A REDIRECT- rule target has been added. This target behaves for
|
||
REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter
|
||
nat table REDIRECT rule is added but not the companion filter table
|
||
ACCEPT rule.</p>
|
||
</li>
|
||
<li>
|
||
<p>The LOGMARKER variable has been renamed LOGFORMAT and has been
|
||
changed to a 'printf' formatting template which accepts three arguments
|
||
(the chain name, logging rule number and the disposition). To use
|
||
LOGFORMAT with fireparse (<a href="http://www.fireparse.com/">http://www.fireparse.com</a>),
|
||
set it as:<br>
|
||
<br>
|
||
LOGFORMAT="fp=%s:%d a=%s "<br>
|
||
<br>
|
||
<b>CAUTION:</b> /sbin/shorewall uses the leading part of the
|
||
LOGFORMAT string (up to but not including the first '%') to find log
|
||
messages in the 'show log', 'status' and 'hits' commands. This part
|
||
should not be omitted (the LOGFORMAT should not begin with "%") and the
|
||
leading part should be sufficiently unique for /sbin/shorewall to
|
||
identify Shorewall messages.</p>
|
||
</li>
|
||
<li>
|
||
<p>When logging is specified on a DNAT[-] or REDIRECT[-] rule, the
|
||
logging now takes place in the nat table rather than in the filter
|
||
table. This way, only those connections that actually undergo DNAT or
|
||
redirection will be logged.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>5/20/2003 - Shorewall-1.4.3a</b> </p>
|
||
<p>This version primarily corrects the documentation included in the
|
||
.tgz and in the .rpm. In addition: </p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">(This change is in 1.4.3 but is not
|
||
documented) If you are running iptables 1.2.7a and kernel 2.4.20, then
|
||
Shorewall will return reject replies as follows:<br>
|
||
a) tcp - RST<br>
|
||
b) udp - ICMP port unreachable<br>
|
||
c) icmp - ICMP host unreachable<br>
|
||
d) Otherwise - ICMP host prohibited<br>
|
||
If you are running earlier software, Shorewall will follow it's
|
||
traditional convention:<br>
|
||
a) tcp - RST<br>
|
||
b) Otherwise - ICMP port unreachable </p>
|
||
</li>
|
||
<li>
|
||
<p>UDP port 135 is now silently dropped in the common.def chain.
|
||
Remember that this chain is traversed just before a DROP or REJECT
|
||
policy is enforced.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>5/18/2003 - Shorewall 1.4.3</b> </p>
|
||
<p> <b>Problems Corrected:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">There were several cases where
|
||
Shorewall would fail to remove a temporary directory from /tmp. These
|
||
cases have been corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p>The rules for allowing all traffic via the loopback interface
|
||
have been moved to before the rule that drops status=INVALID packets.
|
||
This insures that all loopback traffic is allowed even if Netfilter
|
||
connection tracking is confused. </p>
|
||
</li>
|
||
</ol>
|
||
<p> <b>New Features:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;"> IPV6-IPV4 (6to4) tunnels are
|
||
now supported in the /etc/shorewall/tunnels file. </p>
|
||
</li>
|
||
<li value="2">
|
||
<p>You may now change the leading portion of the --log-prefix used
|
||
by Shorewall using the LOGMARKER variable in shorewall.conf. By
|
||
default, "Shorewall:" is used.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>5/10/2003 - Shorewall Mirror in Asia</b></p>
|
||
<p>Ed Greshko has established a mirror in Taiwan -- Thanks Ed!</p>
|
||
<p><b>5/8/2003 - Shorewall Mirror in Chile</b></p>
|
||
<p>Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago
|
||
Chile. </p>
|
||
<p><b>4/21/2003 - Samples updated for Shorewall version 1.4.2</b></p>
|
||
<p>Thanks to Francesca Smith, the sample configurations are now
|
||
upgraded to Shorewall version 1.4.2.</p>
|
||
<p><b>4/9/2003 - Shorewall 1.4.2</b></p>
|
||
<p> <b>Problems Corrected:</b></p>
|
||
<ol>
|
||
<li>
|
||
<blockquote style="margin-bottom: 0in;">TCP connection requests
|
||
rejected out of the <b>common</b> chain are now properly rejected with
|
||
TCP RST; previously, some of these requests were rejected with an ICMP
|
||
port-unreachable response. </blockquote>
|
||
</li>
|
||
<li>
|
||
<blockquote>'traceroute -I' from behind the firewall previously
|
||
timed out on the first hop (e.g., to the firewall). This has been
|
||
worked around. </blockquote>
|
||
</li>
|
||
</ol>
|
||
<p> <b>New Features:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p>Where an entry in the/etc/shorewall/hosts file specifies a
|
||
particular host or network, Shorewall now creates an intermediate chain
|
||
for handling input from the related zone. This can substantially reduce
|
||
the number of rules traversed by connections requests from such zones.</p>
|
||
</li>
|
||
<li>
|
||
<p>Any file may include an INCLUDE directive. An INCLUDE directive
|
||
consists of the word INCLUDE followed by a file name and causes the
|
||
contents of the named file to be logically included into the file
|
||
containing the INCLUDE. File names given in an INCLUDE directive are
|
||
assumed to reside in /etc/shorewall or in an alternate configuration
|
||
directory if one has been specified for the command.<br>
|
||
<br>
|
||
Examples:<br>
|
||
shorewall/params.mgmt:<br>
|
||
MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3<br>
|
||
TIME_SERVERS=4.4.4.4<br>
|
||
BACKUP_SERVERS=5.5.5.5<br>
|
||
----- end params.mgmt -----<br>
|
||
<br>
|
||
<br>
|
||
shorewall/params:<br>
|
||
# Shorewall 1.3 /etc/shorewall/params<br>
|
||
[..]<br>
|
||
#######################################<br>
|
||
<br>
|
||
INCLUDE params.mgmt <br>
|
||
<br>
|
||
# params unique to this host here<br>
|
||
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT
|
||
REMOVE<br>
|
||
----- end params -----<br>
|
||
<br>
|
||
<br>
|
||
shorewall/rules.mgmt:<br>
|
||
ACCEPT
|
||
net:$MGMT_SERVERS
|
||
$FW tcp 22<br>
|
||
ACCEPT
|
||
$FW
|
||
net:$TIME_SERVERS udp 123<br>
|
||
ACCEPT
|
||
$FW
|
||
net:$BACKUP_SERVERS tcp 22<br>
|
||
----- end rules.mgmt -----<br>
|
||
<br>
|
||
shorewall/rules:<br>
|
||
# Shorewall version 1.3 - Rules File<br>
|
||
[..]<br>
|
||
#######################################<br>
|
||
<br>
|
||
INCLUDE rules.mgmt <br>
|
||
<br>
|
||
# rules unique to this host here<br>
|
||
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT
|
||
REMOVE<br>
|
||
----- end rules -----<br>
|
||
<br>
|
||
INCLUDE's may be nested to a level of 3 -- further nested INCLUDE
|
||
directives are ignored with a warning message.</p>
|
||
</li>
|
||
<li>
|
||
<p>Routing traffic from an interface back out that interface
|
||
continues to be a problem. While I firmly believe that this should
|
||
never happen, people continue to want to do it. To limit the damage
|
||
that such nonsense produces, I have added a new 'routeback' option in
|
||
/etc/shorewall/interfaces and /etc/shorewall/hosts. When used in
|
||
/etc/shorewall/interfaces, the 'ZONE' column may not contain '-'; in
|
||
other words, 'routeback' can't be used as an option for a multi-zone
|
||
interface. The 'routeback' option CAN be specified however on
|
||
individual group entries in /etc/shorewall/hosts.<br>
|
||
<br>
|
||
The 'routeback' option is similar to the old 'multi' option with two
|
||
exceptions:<br>
|
||
<br>
|
||
a) The option pertains to a particular
|
||
zone,interface,address tuple.<br>
|
||
<br>
|
||
b) The option only created infrastructure to pass traffic
|
||
from (zone,interface,address) tuples back to themselves (the 'multi'
|
||
option affected all (zone,interface,address) tuples associated with the
|
||
given 'interface').<br>
|
||
<br>
|
||
See the '<a href="upgrade_issues.htm">Upgrade Issues</a>' for
|
||
information about how this new option may affect your configuration.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>3/24/2003 - Shorewall 1.4.1</b> </p>
|
||
<p>This release follows up on 1.4.0. It corrects a problem introduced
|
||
in 1.4.0 and removes additional warts.<br>
|
||
<br>
|
||
<b>Problems Corrected:</b></p>
|
||
<ol>
|
||
<li>
|
||
<p>When Shorewall 1.4.0 is run under the ash shell (such as on
|
||
Bering/LEAF), it can attempt to add ECN disabling rules even if the
|
||
/etc/shorewall/ecn file is empty. That problem has been corrected so
|
||
that ECN disabling rules are only added if there are entries in
|
||
/etc/shorewall/ecn. </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>New Features:</b></p>
|
||
<blockquote>Note: In the list that follows, the term <i>group</i>
|
||
refers to a particular network or subnetwork (which may be 0.0.0.0/0
|
||
or it may be a host address) accessed through a particular interface.
|
||
Examples:</blockquote>
|
||
<blockquote style="margin-left: 0.79in; margin-right: 0.79in;">eth0:0.0.0.0/0<br>
|
||
eth2:192.168.1.0/24<br>
|
||
eth3:192.0.2.123</blockquote>
|
||
<blockquote>You can use the "shorewall check" command to
|
||
see the groups associated with each of your zones.</blockquote>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Beginning with Shorewall 1.4.1, if a
|
||
zone Z comprises more than one group then if there is no explicit Z to
|
||
Z policy and there are no rules governing traffic from Z to Z then
|
||
Shorewall will permit all traffic between the groups in the zone. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Beginning with Shorewall 1.4.1,
|
||
Shorewall will never create rules to handle traffic from a group to
|
||
itself. </p>
|
||
</li>
|
||
<li>
|
||
<p>A NONE policy is introduced in 1.4.1. When a policy of NONE is
|
||
specified from Z1 to Z2: </p>
|
||
</li>
|
||
</ol>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">There may be no rules created that
|
||
govern connections from Z1 to Z2. </p>
|
||
</li>
|
||
<li>
|
||
<p>Shorewall will not create any infrastructure to handle traffic
|
||
from Z1 to Z2. </p>
|
||
</li>
|
||
</ul>
|
||
<p>See the <a href="upgrade_issues.htm">upgrade issues</a> for a
|
||
discussion of how these changes may affect your configuration. </p>
|
||
<p><b>3/17/2003 - Shorewall 1.4.0</b> </p>
|
||
<p>Shorewall 1.4 represents the next step in the evolution of
|
||
Shorewall. The main thrust of the initial release is simply to remove
|
||
the cruft that has accumulated in Shorewall over time. <br>
|
||
<br>
|
||
<b>IMPORTANT:
|
||
Shorewall 1.4.0 requires</b> <b>the iproute package ('ip'
|
||
utility).</b><br>
|
||
<br>
|
||
Function from 1.3 that has been omitted from
|
||
this version include:</p>
|
||
<ol>
|
||
<li>
|
||
<p>The MERGE_HOSTS variable in shorewall.conf is no longer
|
||
supported. Shorewall 1.4 behavior is the same as 1.3 with
|
||
MERGE_HOSTS=Yes.</p>
|
||
</li>
|
||
<li>
|
||
<p>Interface names of the form <device>:<integer> in
|
||
/etc/shorewall/interfaces now generate an error.</p>
|
||
</li>
|
||
<li>
|
||
<p>Shorewall 1.4 implements behavior consistent with
|
||
OLD_PING_HANDLING=No. OLD_PING_HANDLING=Yes will generate an error at
|
||
startup as will specification of the 'noping' or 'filterping' interface
|
||
options.</p>
|
||
</li>
|
||
<li>
|
||
<p>The 'routestopped' option in the /etc/shorewall/interfaces and
|
||
/etc/shorewall/hosts files is no longer supported and will generate an
|
||
error at startup if specified.</p>
|
||
</li>
|
||
<li>
|
||
<p>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no
|
||
longer accepted.</p>
|
||
</li>
|
||
<li>
|
||
<p>The ALLOWRELATED variable in shorewall.conf is no longer
|
||
supported. Shorewall 1.4 behavior is the same as 1.3 with
|
||
ALLOWRELATED=Yes.</p>
|
||
</li>
|
||
<li>
|
||
<p>The icmp.def file has been removed.</p>
|
||
</li>
|
||
</ol>
|
||
<p>Changes for 1.4 include:</p>
|
||
<ol>
|
||
<li>
|
||
<p>The /etc/shorewall/shorewall.conf file has been completely
|
||
reorganized into logical sections.</p>
|
||
</li>
|
||
<li>
|
||
<p>LOG is now a valid action for a rule (/etc/shorewall/rules).</p>
|
||
</li>
|
||
<li>
|
||
<p>The firewall script and version file are now installed in
|
||
/usr/share/shorewall.</p>
|
||
</li>
|
||
<li>
|
||
<p>Late arriving DNS replies are now silently dropped in the common
|
||
chain by default.</p>
|
||
</li>
|
||
<li>
|
||
<p>In addition to behaving like OLD_PING_HANDLING=No, Shorewall 1.4
|
||
no longer unconditionally accepts outbound ICMP packets. So if you want
|
||
to 'ping' from the firewall, you will need the appropriate rule or
|
||
policy.</p>
|
||
</li>
|
||
<li>
|
||
<p>CONTINUE is now a valid action for a rule (/etc/shorewall/rules).</p>
|
||
</li>
|
||
<li>
|
||
<p>802.11b devices with names of the form wlan<n> now support
|
||
the 'maclist' option.</p>
|
||
</li>
|
||
<li>
|
||
<p>Explicit Congestion Notification (ECN - RFC 3168) may now be
|
||
turned off on a host or network basis using the new /etc/shorewall/ecn
|
||
file. To use this facility:<br>
|
||
<br>
|
||
a) You must be running kernel 2.4.20<br>
|
||
b) You must have applied the patch in<br>
|
||
http://www.shorewall/net/pub/shorewall/ecn/patch.<br>
|
||
c) You must have iptables 1.2.7a installed.</p>
|
||
</li>
|
||
<li>
|
||
<p>The /etc/shorewall/params file is now processed first so that
|
||
variables may be used in the /etc/shorewall/shorewall.conf file.</p>
|
||
</li>
|
||
<li value="10">
|
||
<p>Shorewall now gives a more helpful diagnostic when the
|
||
'ipchains' compatibility kernel module is loaded and a 'shorewall
|
||
start' command is issued.</p>
|
||
</li>
|
||
<li>
|
||
<p>The SHARED_DIR variable has been removed from shorewall.conf.
|
||
This variable was for use by package maintainers and was not documented
|
||
for general use.</p>
|
||
</li>
|
||
<li>
|
||
<p>Shorewall now ignores 'default' routes when detecting masq'd
|
||
networks. </p>
|
||
</li>
|
||
</ol>
|
||
<p><b>3/10/2003 - Shoreall 1.3.14a</b></p>
|
||
<p>A roleup of the following bug fixes and other updates:</p>
|
||
<ul>
|
||
<li>
|
||
<p>There is an updated rfc1918 file that reflects the resent
|
||
allocation of 222.0.0.0/8 and 223.0.0.0/8. </p>
|
||
</li>
|
||
</ul>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The documentation for the
|
||
routestopped file claimed that a comma-separated list could appear in
|
||
the second column while the code only supported a single host or
|
||
network address. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Log messages produced by
|
||
'logunclean' and 'dropunclean' were not rate-limited. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">802.11b devices with names of the
|
||
form <i>wlan</i><n> don't support the 'maclist' interface
|
||
option. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Log messages generated by RFC 1918
|
||
filtering are not rate limited. </p>
|
||
</li>
|
||
<li>
|
||
<p>The firewall fails to start in the case where you have "eth0
|
||
eth1" in /etc/shorewall/masq and the default route is through eth1 </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>2/8/2003 - Shoreawall 1.3.14</b></p>
|
||
<p>New features include</p>
|
||
<ol>
|
||
<li>
|
||
<p>An OLD_PING_HANDLING option has been added to shorewall.conf.
|
||
When set to Yes, Shorewall ping handling is as it has always been (see
|
||
http://www.shorewall.net/ping.html).<br>
|
||
<br>
|
||
When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules and
|
||
policies just like any other connection request. The FORWARDPING=Yes
|
||
option in shorewall.conf and the 'noping' and 'filterping' options in
|
||
/etc/shorewall/interfaces will all generate an error.</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">It is now possible to direct
|
||
Shorewall to create a "label" such as "eth0:0" for IP addresses
|
||
that it creates under ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This
|
||
is done by specifying the label instead of just the interface name:<br>
|
||
<br>
|
||
a) In the INTERFACE column of /etc/shorewall/masq<br>
|
||
b) In the INTERFACE column of /etc/shorewall/nat<br>
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>Support for OpenVPN Tunnels.</p>
|
||
</li>
|
||
<li>
|
||
<p>Support for VLAN devices with names of the form $DEV.$VID (e.g.,
|
||
eth0.0)</p>
|
||
</li>
|
||
<li>
|
||
<p>In /etc/shorewall/tcrules, the MARK value may be optionally
|
||
followed by ":" and either 'F' or 'P' to designate that the marking
|
||
will occur in the FORWARD or PREROUTING chains respectively. If this
|
||
additional specification is omitted, the chain used to mark packets
|
||
will be determined by the setting of the MARK_IN_FORWARD_CHAIN option
|
||
in <a href="Documentation.htm#Conf">shorewall.conf</a>.</p>
|
||
</li>
|
||
<li>
|
||
<p>When an interface name is entered in the SUBNET column of the
|
||
/etc/shorewall/masq file, Shorewall previously masqueraded traffic from
|
||
only the first subnet defined on that interface. It did not masquerade
|
||
traffic from:<br>
|
||
<br>
|
||
a) The subnets associated with other addresses on the
|
||
interface.<br>
|
||
b) Subnets accessed through local routers.<br>
|
||
<br>
|
||
Beginning with Shorewall 1.3.14, if you enter an interface name in the
|
||
SUBNET column, shorewall will use the firewall's routing table to
|
||
construct the masquerading/SNAT rules.<br>
|
||
<br>
|
||
Example 1 -- This is how it works in 1.3.14.<br>
|
||
</p>
|
||
<pre> [root@gateway test]# cat /etc/shorewall/masq<br><br> #INTERFACE SUBNET ADDRESS<br><br> eth0 eth2 206.124.146.176<br><br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE<br> <br> [root@gateway test]# ip route show dev eth2<br><br> 192.168.1.0/24 scope link<br><br> 192.168.10.0/24 proto kernel scope link src 192.168.10.254<br><br> <br> [root@gateway test]# shorewall start<br><br> ...<br><br> Masqueraded Subnets and Hosts:<br><br> To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br><br> To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br><br> Processing /etc/shorewall/tos...<br> </pre>
|
||
<p> <br>
|
||
When upgrading to Shorewall 1.3.14, if you have multiple local subnets
|
||
connected to an interface that is specified in the SUBNET column of an
|
||
/etc/shorewall/masq entry, your /etc/shorewall/masq file will need
|
||
changing. In most cases, you will simply be able to remove redundant
|
||
entries. In some cases though, you might want to change from using the
|
||
interface name to listing specific subnetworks if the change described
|
||
above will cause masquerading to occur on subnetworks that you don't
|
||
wish to masquerade.<br>
|
||
<br>
|
||
Example 2 -- Suppose that your current config is as follows:<br>
|
||
</p>
|
||
<pre> [root@gateway test]# cat /etc/shorewall/masq<br><br> #INTERFACE SUBNET ADDRESS<br><br> eth0 eth2 206.124.146.176<br><br> eth0 192.168.10.0/24 206.124.146.176<br><br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE<br> <br> [root@gateway test]# ip route show dev eth2<br><br> 192.168.1.0/24 scope link<br><br> 192.168.10.0/24 proto kernel scope link src 192.168.10.254<br><br> [root@gateway test]#<br> </pre>
|
||
<p> <br>
|
||
In this case, the second entry in /etc/shorewall/masq is
|
||
no longer required.<br>
|
||
<br>
|
||
Example 3 -- What if your current configuration is like this?<br>
|
||
</p>
|
||
<pre> [root@gateway test]# cat /etc/shorewall/masq<br><br> #INTERFACE SUBNET ADDRESS<br><br> eth0 eth2 206.124.146.176<br><br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE<br> <br> [root@gateway test]# ip route show dev eth2<br><br> 192.168.1.0/24 scope link<br><br> 192.168.10.0/24 proto kernel scope link src 192.168.10.254<br><br> [root@gateway test]#<br> </pre>
|
||
<p> <br>
|
||
In this case, you would want to change the entry in
|
||
/etc/shorewall/masq to:</p>
|
||
<pre> #INTERFACE SUBNET ADDRESS<br><br> eth0 192.168.1.0/24 206.124.146.176<br><br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE<br> </pre>
|
||
</li>
|
||
</ol>
|
||
<p><br>
|
||
<b>2/5/2003 - Shorewall Support included in Webmin 1.060</b></p>
|
||
<p>Webmin version 1.060 now has Shorewall support included as
|
||
standard. See <a href="http://www.webmin.com/">http://www.webmin.com</a>.<br>
|
||
<b><br>
|
||
2/4/2003
|
||
- Shorewall 1.3.14-RC1</b></p>
|
||
<p>Includes the Beta 2 content plus support for OpenVPN tunnels.</p>
|
||
<p><b>1/28/2003 - Shorewall 1.3.14-Beta2</b></p>
|
||
<p>Includes the Beta 1 content plus restores VLAN device names of the
|
||
form $dev.$vid (e.g., eth0.1)</p>
|
||
<p><b>1/25/2003 - Shorewall 1.3.14-Beta1</b></p>
|
||
<p>The Beta includes the following changes:</p>
|
||
<ol>
|
||
<li>
|
||
<p>An OLD_PING_HANDLING option has been added to shorewall.conf.
|
||
When set to Yes, Shorewall ping handling is as it has always been (see
|
||
http://www.shorewall.net/ping.html).<br>
|
||
<br>
|
||
When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules and
|
||
policies just like any other connection request. The FORWARDPING=Yes
|
||
option in shorewall.conf and the 'noping' and 'filterping' options in
|
||
/etc/shorewall/interfaces will all generate an error.</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">It is now possible to direct
|
||
Shorewall to create a "label" such as "eth0:0" for IP addresses
|
||
that it creates under ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This
|
||
is done by specifying the label instead of just the interface name:<br>
|
||
<br>
|
||
a) In the INTERFACE column of /etc/shorewall/masq<br>
|
||
b) In the INTERFACE column of /etc/shorewall/nat<br>
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>When an interface name is entered in the SUBNET column of the
|
||
/etc/shorewall/masq file, Shorewall previously masqueraded traffic from
|
||
only the first subnet defined on that interface. It did not masquerade
|
||
traffic from:<br>
|
||
<br>
|
||
a) The subnets associated with other addresses on the
|
||
interface.<br>
|
||
b) Subnets accessed through local routers.<br>
|
||
<br>
|
||
Beginning with Shorewall 1.3.14, if you enter an interface name in the
|
||
SUBNET column, shorewall will use the firewall's routing table to
|
||
construct the masquerading/SNAT rules.<br>
|
||
<br>
|
||
Example 1 -- This is how it works in 1.3.14.<br>
|
||
</p>
|
||
<pre> [root@gateway test]# cat /etc/shorewall/masq<br><br> #INTERFACE SUBNET ADDRESS<br><br> eth0 eth2 206.124.146.176<br><br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE<br> <br> [root@gateway test]# ip route show dev eth2<br><br> 192.168.1.0/24 scope link<br><br> 192.168.10.0/24 proto kernel scope link src 192.168.10.254<br><br> <br> [root@gateway test]# shorewall start<br><br> ...<br><br> Masqueraded Subnets and Hosts:<br><br> To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br><br> To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br><br> Processing /etc/shorewall/tos...<br> </pre>
|
||
<p> <br>
|
||
When upgrading to Shorewall 1.3.14, if you have multiple local subnets
|
||
connected to an interface that is specified in the SUBNET column of an
|
||
/etc/shorewall/masq entry, your /etc/shorewall/masq file will need
|
||
changing. In most cases, you will simply be able to remove redundant
|
||
entries. In some cases though, you might want to change from using the
|
||
interface name to listing specific subnetworks if the change described
|
||
above will cause masquerading to occur on subnetworks that you don't
|
||
wish to masquerade.<br>
|
||
<br>
|
||
Example 2 -- Suppose that your current config is as follows:<br>
|
||
</p>
|
||
<pre> [root@gateway test]# cat /etc/shorewall/masq<br><br> #INTERFACE SUBNET ADDRESS<br><br> eth0 eth2 206.124.146.176<br><br> eth0 192.168.10.0/24 206.124.146.176<br><br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE<br> <br> [root@gateway test]# ip route show dev eth2<br><br> 192.168.1.0/24 scope link<br><br> 192.168.10.0/24 proto kernel scope link src 192.168.10.254<br><br> [root@gateway test]#<br> </pre>
|
||
<p> <br>
|
||
In this case, the second entry in /etc/shorewall/masq is
|
||
no longer required.<br>
|
||
<br>
|
||
Example 3 -- What if your current configuration is like this?<br>
|
||
</p>
|
||
<pre> [root@gateway test]# cat /etc/shorewall/masq<br><br> #INTERFACE SUBNET ADDRESS<br><br> eth0 eth2 206.124.146.176<br><br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE<br> <br> [root@gateway test]# ip route show dev eth2<br><br> 192.168.1.0/24 scope link<br><br> 192.168.10.0/24 proto kernel scope link src 192.168.10.254<br><br> [root@gateway test]#<br> </pre>
|
||
<p> <br>
|
||
In this case, you would want to change the entry in
|
||
/etc/shorewall/masq to:</p>
|
||
<pre> #INTERFACE SUBNET ADDRESS<br><br> eth0 192.168.1.0/24 206.124.146.176<br><br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE<br> </pre>
|
||
</li>
|
||
</ol>
|
||
<p><b>1/18/2003 - Shorewall 1.3.13 Documentation in PDF Format</b></p>
|
||
<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.13
|
||
documenation. the PDF may be downloaded from</p>
|
||
<p>
|
||
<a href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/"
|
||
target="_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
|
||
|
||
<a href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a>
|
||
</p>
|
||
<p><b>1/17/2003 - shorewall.net has MOVED</b> </p>
|
||
<p>Thanks to the generosity of Alex Martin and <a
|
||
href="http://www.rettc.com/">Rett
|
||
Consulting</a>, www.shorewall.net and ftp.shorewall.net are now
|
||
hosted on a system in Bellevue, Washington. A big thanks to Alex for
|
||
making this happen.</p>
|
||
<p><b>1/13/2003 - Shorewall 1.3.13</b></p>
|
||
<p>Just includes a few things that I had on the burner:</p>
|
||
<ol>
|
||
<li>
|
||
<p>A new 'DNAT-' action has been added for entries in the
|
||
/etc/shorewall/rules file. DNAT- is intended for advanced users who
|
||
wish to minimize the number of rules that connection requests must
|
||
traverse.<br>
|
||
<br>
|
||
A Shorewall DNAT rule actually generates two iptables rules: a header
|
||
rewriting rule in the 'nat' table and an ACCEPT rule in the 'filter'
|
||
table. A DNAT- rule only generates the first of these rules. This is
|
||
handy when you have several DNAT rules that would generate the same
|
||
ACCEPT rule.<br>
|
||
<br>
|
||
Here are three rules from my previous rules file:<br>
|
||
<br>
|
||
DNAT net
|
||
dmz:206.124.146.177 tcp smtp - 206.124.146.178<br>
|
||
DNAT net
|
||
dmz:206.124.146.177 tcp smtp - 206.124.146.179<br>
|
||
ACCEPT net
|
||
dmz:206.124.146.177 tcp www,smtp,ftp,...<br>
|
||
<br>
|
||
These three rules ended up generating _three_ copies of<br>
|
||
<br>
|
||
ACCEPT net
|
||
dmz:206.124.146.177 tcp smtp<br>
|
||
<br>
|
||
By writing the rules this way, I end up with only one copy
|
||
of the ACCEPT rule.<br>
|
||
<br>
|
||
DNAT- net
|
||
dmz:206.124.146.177 tcp smtp - 206.124.146.178<br>
|
||
DNAT- net
|
||
dmz:206.124.146.177 tcp smtp - 206.124.146.179<br>
|
||
ACCEPT net
|
||
dmz:206.124.146.177 tcp www,smtp,ftp,....</p>
|
||
</li>
|
||
<li>
|
||
<p>The 'shorewall check' command now prints out the applicable
|
||
policy between each pair of zones.</p>
|
||
</li>
|
||
<li>
|
||
<p>A new CLEAR_TC option has been added to shorewall.conf. If this
|
||
option is set to 'No' then Shorewall won't clear the current traffic
|
||
control rules during [re]start. This setting is intended for use by
|
||
people that prefer to configure traffic shaping when the network
|
||
interfaces come up rather than when the firewall is started. If that is
|
||
what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not
|
||
supply an /etc/shorewall/tcstart file. That way, your traffic shaping
|
||
rules can still use the 'fwmark' classifier based on packet marking
|
||
defined in /etc/shorewall/tcrules.</p>
|
||
</li>
|
||
<li>
|
||
<p>A new SHARED_DIR variable has been added that allows
|
||
distribution packagers to easily move the shared directory (default
|
||
/usr/lib/shorewall). Users should never have a need to change the value
|
||
of this shorewall.conf setting.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>1/6/2003 - <font size="6">BURNOUT</font></b> </p>
|
||
<p><b>Until further notice, I will not be involved in either
|
||
Shorewall Development or Shorewall Support</b></p>
|
||
<p><b>-Tom Eastep</b></p>
|
||
<p><b>12/30/2002 - Shorewall Documentation in PDF Format</b></p>
|
||
<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.12
|
||
documenation. the PDF may be downloaded from</p>
|
||
<p>
|
||
<a href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/"
|
||
target="_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
|
||
|
||
<a href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a></p>
|
||
<p><b>12/27/2002 - Shorewall 1.3.12 Released</b></p>
|
||
<p>Features include:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">"shorewall refresh" now reloads the
|
||
traffic shaping rules (tcrules and tcstart). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">"shorewall debug [re]start" now
|
||
turns off debugging after an error occurs. This places the point of the
|
||
failure near the end of the trace rather than up in the middle of it. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">"shorewall [re]start" has been
|
||
speeded up by more than 40% with my configuration. Your milage may
|
||
vary. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A "shorewall show classifiers"
|
||
command has been added which shows the current packet classification
|
||
filters. The output from this command is also added as a separate page
|
||
in "shorewall monitor" </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">ULOG (must be all caps) is now
|
||
accepted as a valid syslog level and causes the subject packets to be
|
||
logged using the ULOG target rather than the LOG target. This allows
|
||
you to run ulogd (available from <a
|
||
href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
|
||
and log all Shorewall messages <a href="shorewall_logging.html">to a
|
||
separate log file</a>. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">If you are running a kernel that has
|
||
a FORWARD chain in the mangle table ("shorewall show mangle" will show
|
||
you the chains in the mangle table), you can set
|
||
MARK_IN_FORWARD_CHAIN=Yes in <a href="Documentation.htm#Conf">shorewall.conf</a>.
|
||
This allows for marking input packets based on their destination even
|
||
when you are using Masquerading or SNAT. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">I have cluttered up the
|
||
/etc/shorewall directory with empty 'init', 'start', 'stop' and
|
||
'stopped' files. If you already have a file with one of these names,
|
||
don't worry -- the upgrade process won't overwrite your file. </p>
|
||
</li>
|
||
<li>
|
||
<p>I have added a new RFC1918_LOG_LEVEL variable to <a
|
||
href="Documentation.htm#Conf">shorewall.conf</a>. This variable
|
||
specifies the syslog level at which packets are logged as a result of
|
||
entries in the /etc/shorewall/rfc1918 file. Previously, these packets
|
||
were always logged at the 'info' level.</p>
|
||
</li>
|
||
</ol>
|
||
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 3</b></p>
|
||
<p>This version corrects a problem with Blacklist logging. In Beta 2,
|
||
if BLACKLIST_LOG_LEVEL was set to anything but ULOG, the firewall
|
||
would fail to start and "shorewall refresh" would also
|
||
fail.</p>
|
||
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 2</b></p>
|
||
<p>The first public Beta version of Shorewall 1.3.12 is now available
|
||
(Beta 1 was made available only to a limited audience).</p>
|
||
<p>Features include:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">"shorewall refresh" now reloads the
|
||
traffic shaping rules (tcrules and tcstart). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">"shorewall debug [re]start" now
|
||
turns off debugging after an error occurs. This places the point of the
|
||
failure near the end of the trace rather than up in the middle of it. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">"shorewall [re]start" has been
|
||
speeded up by more than 40% with my configuration. Your milage may
|
||
vary. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A "shorewall show classifiers"
|
||
command has been added which shows the current packet classification
|
||
filters. The output from this command is also added as a separate page
|
||
in "shorewall monitor" </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">ULOG (must be all caps) is now
|
||
accepted as a valid syslog level and causes the subject packets to be
|
||
logged using the ULOG target rather than the LOG target. This allows
|
||
you to run ulogd (available from <a
|
||
href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
|
||
and log all Shorewall messages <a href="shorewall_logging.html">to a
|
||
separate log file</a>. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">If you are running a kernel that has
|
||
a FORWARD chain in the mangle table ("shorewall show mangle" will show
|
||
you the chains in the mangle table), you can set
|
||
MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This allows for marking
|
||
input packets based on their destination even when you are using
|
||
Masquerading or SNAT. </p>
|
||
</li>
|
||
<li>
|
||
<p>I have cluttered up the /etc/shorewall directory with empty
|
||
'init', 'start', 'stop' and 'stopped' files. If you already have a file
|
||
with one of these names, don't worry -- the upgrade process won't
|
||
overwrite your file. </p>
|
||
</li>
|
||
</ol>
|
||
<p>You may download the Beta from:</p>
|
||
<blockquote><a href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><br>
|
||
<a href="ftp://ftp.shorewall.net/pub/shorewall/Beta" target="_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a></blockquote>
|
||
<p><b>12/12/2002 - Mandrake Multi Network Firewall <a
|
||
href="http://www.mandrakesoft.com/"><img src="images/logo2.png"
|
||
name="graphics2" alt="Powered by Mandrake Linux" align="bottom"
|
||
border="0" height="21" width="140"></a><a
|
||
href="http://www.mandrakesoft.com/">
|
||
</a></b></p>
|
||
<p>Shorewall is at the center of MandrakeSoft's recently-announced
|
||
<a
|
||
href="http://www.mandrakestore.com/mdkinc/index.php?PAGE=tab_0/menu_0.php&id_art=250&LANG_=en#GOTO_250">Multi
|
||
Network Firewall (MNF)</a> product. Here is the <a
|
||
href="http://www.mandrakesoft.com/company/press/pr?n=/pr/products/2403">press
|
||
release</a>.</p>
|
||
<p><b>12/7/2002 - Shorewall Support for Mandrake 9.0</b></p>
|
||
<p>Two months and 3 days after I ordered Mandrake 9.0, it was finally
|
||
delivered. I have installed 9.0 on one of my systems and I am now in
|
||
a position to support Shorewall users who run Mandrake 9.0.</p>
|
||
<p><b>12/6/2002 - Debian 1.3.11a Packages Available</b></p>
|
||
<p>Apt-get sources listed at
|
||
<a href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html.</a></p>
|
||
<p><b>12/3/2002 - Shorewall 1.3.11a</b></p>
|
||
<p>This is a bug-fix roll up which includes Roger Aich's fix for DNAT
|
||
with excluded subnets (e.g., "DNAT foo!bar ..."). Current
|
||
1.3.11 users who don't need rules of this type need not upgrade to
|
||
1.3.11.</p>
|
||
<p><b>11/24/2002 - Shorewall 1.3.11</b></p>
|
||
<p>In this version:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A 'tcpflags' option has been added
|
||
to entries in <a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.
|
||
This option causes Shorewall to make a set of sanity check on TCP
|
||
packet header flags. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">It is now allowed to use 'all' in
|
||
the SOURCE or DEST column in a <a href="Documentation.htm#Rules">rule</a>.
|
||
When used, 'all' must appear by itself (in may not be qualified) and it
|
||
does not enable intra-zone traffic. For example, the rule<br>
|
||
<br>
|
||
ACCEPT loc all tcp 80<br>
|
||
<br>
|
||
does not enable http traffic from 'loc' to 'loc'. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall's use of the 'echo'
|
||
command is now compatible with bash clones such as ash and dash. </p>
|
||
</li>
|
||
<li>
|
||
<p>fw->fw policies now generate a startup error. fw->fw rules
|
||
generate a warning and are ignored </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>11/14/2002 - Shorewall Documentation in PDF Format</b></p>
|
||
<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.10
|
||
documenation. the PDF may be downloaded from</p>
|
||
<p>
|
||
<a href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/"
|
||
target="_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
|
||
|
||
<a href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a></p>
|
||
<p><b>11/09/2002 - Shorewall is Back at SourceForge</b> </p>
|
||
<p>The main Shorewall 1.3 web site is now back at SourceForge at
|
||
<a href="http://shorewall.sf.net/" target="_top">http://shorewall.sf.net</a>.</p>
|
||
<p><b>11/09/2002 - Shorewall 1.3.10</b></p>
|
||
<p>In this version:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">You may now <a
|
||
href="IPSEC.htm#Dynamic">define the contents of a zone dynamically</a>
|
||
with the <a href="starting_and_stopping_shorewall.htm">"shorewall add"
|
||
and "shorewall delete" commands</a>. These commands are expected to be
|
||
used primarily within <a href="http://www.xs4all.nl/%7Efreeswan/">FreeS/Wan</a>
|
||
updown scripts. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall can now do <a
|
||
href="MAC_Validation.html">MAC verification</a> on ethernet segments.
|
||
You can specify the set of allowed MAC addresses on the segment and you
|
||
can optionally tie each MAC address to one or more IP addresses. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">PPTP Servers and Clients running on
|
||
the firewall system may now be defined in the <a
|
||
href="http://PPTP.htm/">/etc/shorewall/tunnels</a> file. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A new 'ipsecnat' tunnel type is
|
||
supported for use when the <a href="http://IPSEC.htm/">remote IPSEC
|
||
endpoint is behind a NAT gateway</a>. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The PATH used by Shorewall may now
|
||
be specified in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a>
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>The main firewall script is now /usr/lib/shorewall/firewall. The
|
||
script in /etc/init.d/shorewall is very small and uses /sbin/shorewall
|
||
to do the real work. This change makes custom distributions such as for
|
||
Debian and for Gentoo easier to manage since it is
|
||
/etc/init.d/shorewall that tends to have distribution-dependent code </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>10/24/2002 - Shorewall is now in Gentoo Linux</b> </p>
|
||
<p>Alexandru Hartmann reports that his Shorewall package is now a
|
||
part of <a href="http://www.gentoo.org/">the Gentoo Linux
|
||
distribution</a>. Thanks Alex!</p>
|
||
<p><b>10/23/2002 - Shorewall 1.3.10 Beta 1</b> </p>
|
||
<p>In this version:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">You may now <a
|
||
href="IPSEC.htm#Dynamic">define the contents of a zone dynamically</a>
|
||
with the <a href="starting_and_stopping_shorewall.htm">"shorewall add"
|
||
and "shorewall delete" commands</a>. These commands are expected to be
|
||
used primarily within <a href="http://www.xs4all.nl/%7Efreeswan/">FreeS/Wan</a>
|
||
updown scripts. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall can now do <a
|
||
href="MAC_Validation.html">MAC verification</a> on ethernet segments.
|
||
You can specify the set of allowed MAC addresses on the segment and you
|
||
can optionally tie each MAC address to one or more IP addresses. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">PPTP Servers and Clients running on
|
||
the firewall system may now be defined in the <a
|
||
href="http://PPTP.htm/">/etc/shorewall/tunnels</a> file. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A new 'ipsecnat' tunnel type is
|
||
supported for use when the <a href="http://IPSEC.htm/">remote IPSEC
|
||
endpoint is behind a NAT gateway</a>. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The PATH used by Shorewall may now
|
||
be specified in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a>
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>The main firewall script is now /usr/lib/shorewall/firewall. The
|
||
script in /etc/init.d/shorewall is very small and uses /sbin/shorewall
|
||
to do the real work. This change makes custom distributions such as for
|
||
Debian and for Gentoo easier to manage since it is
|
||
/etc/init.d/shorewall that tends to have distribution-dependent code. </p>
|
||
</li>
|
||
</ul>
|
||
<p>You may download the Beta from:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;"><a
|
||
href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a>
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p><a href="ftp://ftp.shorewall.net/pub/shorewall/Beta"
|
||
target="_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a> </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>10/10/2002 - Debian 1.3.9b Packages Available</b></p>
|
||
<p>Apt-get sources listed at
|
||
<a href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html.</a></p>
|
||
<p><b>10/9/2002 - Shorewall 1.3.9b</b></p>
|
||
<p>This release rolls up fixes to the installer and to the firewall
|
||
script.</p>
|
||
<p><b>10/6/2002 - Shorewall.net now running on RH8.0<br>
|
||
</b><br>
|
||
The
|
||
firewall and server here at shorewall.net are now running RedHat
|
||
release 8.0.<br>
|
||
<b><br>
|
||
9/30/2002 - Shorewall 1.3.9a</b></p>
|
||
<p>Roles up the fix for broken tunnels.</p>
|
||
<p><b>9/30/2002 - TUNNELS Broken in 1.3.9!!!</b></p>
|
||
<p>There is an updated firewall script at
|
||
<a href="ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall"
|
||
target="_top">ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall</a>
|
||
-- copy that file to /usr/lib/shorewall/firewall.</p>
|
||
<p><b>9/28/2002 - Shorewall 1.3.9</b></p>
|
||
<p>In this version:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;"><a
|
||
href="configuration_file_basics.htm#dnsnames">DNS Names</a> are now
|
||
allowed in Shorewall config files (although I recommend against using
|
||
them). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The connection SOURCE may now be
|
||
qualified by both interface and IP address in a <a
|
||
href="Documentation.htm#Rules">Shorewall rule</a>. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall startup is now disabled
|
||
after initial installation until the file
|
||
/etc/shorewall/startup_disabled is removed. This avoids nasty surprises
|
||
during reboot for users who install Shorewall but don't configure it. </p>
|
||
</li>
|
||
<li>
|
||
<p>The 'functions' and 'version' files and the 'firewall' symbolic
|
||
link have been moved from /var/lib/shorewall to /usr/lib/shorewall to
|
||
appease the LFS police at Debian.</p>
|
||
</li>
|
||
</ul>
|
||
<p><b>9/23/2002 - Full Shorewall Site/Mailing List Archive Search
|
||
Capability Restored</b></p>
|
||
<p><img src="images/j0233056.gif" name="graphics3" alt="Brown Paper Bag"
|
||
align="left" border="0" height="86" width="50">A
|
||
couple of recent configuration changes at www.shorewall.net broke the
|
||
Search facility:</p>
|
||
<ol>
|
||
<li>
|
||
<blockquote style="margin-bottom: 0in;">Mailing List Archive Search
|
||
was not available. </blockquote>
|
||
</li>
|
||
<li>
|
||
<blockquote style="margin-bottom: 0in;">The Site Search index was
|
||
incomplete </blockquote>
|
||
</li>
|
||
<li>
|
||
<blockquote>Only one page of matches was presented. </blockquote>
|
||
</li>
|
||
</ol>
|
||
<p>Hopefully these problems are now corrected. </p>
|
||
<p><b>9/23/2002 - Full Shorewall Site/Mailing List Archive Search
|
||
Capability Restored</b></p>
|
||
<p>A couple of recent configuration changes at www.shorewall.net had
|
||
the negative effect of breaking the Search facility:</p>
|
||
<ol>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Mailing List Archive Search was not
|
||
available. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The Site Search index was incomplete
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>Only one page of matches was presented. </p>
|
||
</li>
|
||
</ol>
|
||
<p>Hopefully these problems are now corrected.</p>
|
||
<p><b>9/18/2002 - Debian 1.3.8 Packages Available</b></p>
|
||
<p>Apt-get sources listed at
|
||
<a href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html.</a></p>
|
||
<p><b>9/16/2002 - Shorewall 1.3.8</b></p>
|
||
<p>In this version:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A <a href="Documentation.htm#Conf">NEWNOTSYN</a>
|
||
option has been added to shorewall.conf. This option determines whether
|
||
Shorewall accepts TCP packets which are not part of an established
|
||
connection and that are not 'SYN' packets (SYN flag on and ACK flag
|
||
off). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The need for the 'multi' option to
|
||
communicate between zones za and zb on the same interface is removed in
|
||
the case where the chain 'za2zb' and/or 'zb2za' exists. 'za2zb' will
|
||
exist if: </p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">There is a policy for za to zb;
|
||
or </p>
|
||
</li>
|
||
<li>
|
||
<p>There is at least one rule for za to zb. </p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<ul>
|
||
<li>
|
||
<p>The /etc/shorewall/blacklist file now contains three columns. In
|
||
addition to the SUBNET/ADDRESS column, there are optional PROTOCOL and
|
||
PORT columns to block only certain applications from the blacklisted
|
||
addresses.</p>
|
||
</li>
|
||
</ul>
|
||
<p><b>9/11/2002 - Debian 1.3.7c Packages Available</b></p>
|
||
<p>Apt-get sources listed at
|
||
<a href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
||
<p><b>9/2/2002 - Shorewall 1.3.7c</b></p>
|
||
<p>This is a role up of a fix for "DNAT" rules where the
|
||
source zone is $FW (fw).</p>
|
||
<p><b>8/31/2002 - I'm not available</b></p>
|
||
<p>I'm currently on vacation -- please respect my need for a
|
||
couple of weeks free of Shorewall problem reports.</p>
|
||
<p>-Tom</p>
|
||
<p><b>8/26/2002 - Shorewall 1.3.7b</b></p>
|
||
<p>This is a role up of the "shorewall refresh" bug fix and
|
||
the change which reverses the order of "dhcp" and
|
||
"norfc1918" checking.</p>
|
||
<p><b>8/26/2002 - French FTP Mirror is Operational</b></p>
|
||
<p><a href="ftp://france.shorewall.net/pub/mirrors/shorewall"
|
||
target="_blank">ftp://france.shorewall.net/pub/mirrors/shorewall</a>
|
||
is now available.</p>
|
||
<p><b>8/25/2002 - Shorewall Mirror in France</b></p>
|
||
<p>Thanks to a Shorewall user in Paris, the Shorewall web site is now
|
||
mirrored at <a href="http://france.shorewall.net/" target="_top">http://france.shorewall.net</a>.</p>
|
||
<p><b>8/25/2002 - Shorewall 1.3.7a Debian Packages Available</b></p>
|
||
<p>Lorenzo Martignoni reports that the packages for version 1.3.7a
|
||
are available at <a
|
||
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
||
<p><b>8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for
|
||
its Author -- Shorewall 1.3.7a released<img src="images/j0233056.gif"
|
||
name="graphics4" alt="Brown Paper Bag Graphic" align="middle"
|
||
border="0" height="80" width="50"></b></p>
|
||
<p>1.3.7a corrects problems occurring in rules file processing when
|
||
starting Shorewall 1.3.7.</p>
|
||
<p><b>8/22/2002 - Shorewall 1.3.7 Released 8/13/2002</b></p>
|
||
<p>Features in this release include:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The 'icmp.def' file is now empty!
|
||
The rules in that file were required in ipchains firewalls but are not
|
||
required in Shorewall. Users who have ALLOWRELATED=No in <a
|
||
href="Documentation.htm#Conf">shorewall.conf</a> should see the <a
|
||
href="errata.htm#Upgrade">Upgrade Issues</a>. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A 'FORWARDPING' option has been
|
||
added to <a href="Documentation.htm#Conf">shorewall.conf</a>. The
|
||
effect of setting this variable to Yes is the same as the effect of
|
||
adding an ACCEPT rule for ICMP echo-request in <a
|
||
href="shorewall_extension_scripts.htm">/etc/shorewall/icmpdef</a>.
|
||
Users who have such a rule in icmpdef are encouraged to switch to
|
||
FORWARDPING=Yes. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The loopback CLASS A Network
|
||
(127.0.0.0/8) has been added to the rfc1918 file. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall now works with iptables
|
||
1.2.7 </p>
|
||
</li>
|
||
<li>
|
||
<p>The documentation and web site no longer uses FrontPage themes. </p>
|
||
</li>
|
||
</ul>
|
||
<p>I would like to thank John Distler for his valuable input
|
||
regarding TCP SYN and ICMP treatment in Shorewall. That input has led
|
||
to marked improvement in Shorewall in the last two releases.</p>
|
||
<p><b>8/13/2002 - Documentation in the <a
|
||
href="http://www.shorewall.net/cgi-bin/cvs/cvsweb.cgi" target="_top">CVS
|
||
Repository</a></b></p>
|
||
<p>The Shorewall-docs project now contains just the HTML and image
|
||
files - the Frontpage files have been removed.</p>
|
||
<p><b>8/7/2002 - <i>STABLE</i></b> <b>branch added to <a
|
||
href="http://www.shorewall.net/cgi-bin/cvs/cvsweb.cgi" target="_top">CVS
|
||
Repository</a></b></p>
|
||
<p>This branch will only be updated after I release a new version of
|
||
Shorewall so you can always update from this branch to get the latest
|
||
stable tree.</p>
|
||
<p><b>8/7/2002 - <a href="errata.htm#Upgrade">Upgrade Issues</a>
|
||
section added to the <a href="http://errata.htm/">Errata Page</a></b></p>
|
||
<p>Now there is one place to go to look for issues involved with
|
||
upgrading to recent versions of Shorewall.</p>
|
||
<p><b>8/7/2002 - Shorewall 1.3.6</b></p>
|
||
<p>This is primarily a bug-fix rollup with a couple of new features:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The latest <a
|
||
href="shorewall_quickstart_guide.htm">QuickStart Guides</a> including
|
||
the <a href="shorewall_setup_guide.htm">Shorewall Setup Guide.</a> </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall will now DROP TCP packets
|
||
that are not part of or related to an existing connection and that are
|
||
not SYN packets. These "New not SYN" packets may be optionally logged
|
||
by setting the LOGNEWNOTSYN option in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>The processing of "New not SYN" packets may be extended by
|
||
commands in the new <a href="shorewall_extension_scripts.htm">newnotsyn
|
||
extension script</a>. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>7/30/2002 - Shorewall 1.3.5b Released</b></p>
|
||
<p>This interim release:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Causes the firewall script to remove
|
||
the lock file if it is killed. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Once again allows lists in the
|
||
second column of the <a href="Documentation.htm#Hosts">/etc/shorewall/hosts</a>
|
||
file. </p>
|
||
</li>
|
||
<li>
|
||
<p>Includes the latest <a href="shorewall_quickstart_guide.htm">QuickStart
|
||
Guides</a>. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>7/29/2002 - New Shorewall Setup Guide Available</b></p>
|
||
<p>The first draft of this guide is available at
|
||
<a href="http://www.shorewall.net/shorewall_setup_guide.htm">http://www.shorewall.net/shorewall_setup_guide.htm</a>.
|
||
The guide is intended for use by people who are setting up Shorewall
|
||
to manage multiple public IP addresses and by people who want to
|
||
learn more about Shorewall than is described in the single-address
|
||
guides. Feedback on the new guide is welcome.</p>
|
||
<p><b>7/28/2002 - Shorewall 1.3.5 Debian Package Available</b></p>
|
||
<p>Lorenzo Martignoni reports that the packages are version 1.3.5a
|
||
and are available at
|
||
<a href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
||
<p><b>7/27/2002 - Shorewall 1.3.5a Released</b></p>
|
||
<p>This interim release restores correct handling of REDIRECT rules.</p>
|
||
<p><b>7/26/2002 - Shorewall 1.3.5 Released</b></p>
|
||
<p>This will be the last Shorewall release for a while. I'm going to
|
||
be focusing on rewriting a lot of the documentation.</p>
|
||
<p> In this version:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Empty and invalid source and
|
||
destination qualifiers are now detected in the rules file. It is a good
|
||
idea to use the 'shorewall check' command before you issue a 'shorewall
|
||
restart' command be be sure that you don't have any configuration
|
||
problems that will prevent a successful restart. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Added <b>MERGE_HOSTS</b> variable
|
||
in <a href="Documentation.htm#Conf">shorewall.conf</a> to provide
|
||
saner behavior of the /etc/shorewall/hosts file. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The time that the counters were last
|
||
reset is now displayed in the heading of the 'status' and 'show'
|
||
commands. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A <b>proxyarp</b> option has been
|
||
added for entries in <a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.
|
||
This option facilitates Proxy ARP sub-netting as described in the Proxy
|
||
ARP subnetting mini-HOWTO (<a
|
||
href="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/">http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/</a>).
|
||
Specifying the proxyarp option for an interface causes Shorewall to set
|
||
/proc/sys/net/ipv4/conf/<interface>/proxy_arp. </p>
|
||
</li>
|
||
<li>
|
||
<p>The Samples have been updated to reflect the new capabilities in
|
||
this release. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>7/16/2002 - New Mirror in Argentina</b></p>
|
||
<p>Thanks to Arturo "Buanzo" Busleiman, there is now a
|
||
Shorewall mirror in Argentina. Thanks Buanzo!!!</p>
|
||
<p><b>7/16/2002 - Shorewall 1.3.4 Released</b></p>
|
||
<p>In this version:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A new <a
|
||
href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>
|
||
file has been added. This file is intended to eventually replace the <b>routestopped</b>
|
||
option in the /etc/shorewall/interface and /etc/shorewall/hosts files.
|
||
This new file makes remote firewall administration easier by allowing
|
||
any IP or subnet to be enabled while Shorewall is stopped. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">An /etc/shorewall/stopped <a
|
||
href="Documentation.htm#Scripts">extension script</a> has been added.
|
||
This script is invoked after Shorewall has stopped. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A <b>DETECT_DNAT_ADDRS</b> option
|
||
has been added to <a href="Documentation.htm#Conf">/etc/shoreall/shorewall.conf</a>.
|
||
When this option is selected, DNAT rules only apply when the
|
||
destination address is the external interface's primary IP address. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The <a
|
||
href="shorewall_quickstart_guide.htm">QuickStart Guide</a> has been
|
||
broken into three guides and has been almost entirely rewritten. </p>
|
||
</li>
|
||
<li>
|
||
<p>The Samples have been updated to reflect the new capabilities in
|
||
this release. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>7/8/2002 - Shorewall 1.3.3 Debian Package Available</b></p>
|
||
<p>Lorenzo Marignoni reports that the packages are available at
|
||
<a href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
||
<p><b>7/6/2002 - Shorewall 1.3.3 Released</b></p>
|
||
<p>In this version:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Entries in /etc/shorewall/interface
|
||
that use the wildcard character ("+") now have the "multi" option
|
||
assumed. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The 'rfc1918' chain in the mangle
|
||
table has been renamed 'man1918' to make log messages generated from
|
||
that chain distinguishable from those generated by the 'rfc1918' chain
|
||
in the filter table. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Interface names appearing in the
|
||
hosts file are now validated against the interfaces file. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The TARGET column in the rfc1918
|
||
file is now checked for correctness. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The chain structure in the nat table
|
||
has been changed to reduce the number of rules that a packet must
|
||
traverse and to correct problems with NAT_BEFORE_RULES=No </p>
|
||
</li>
|
||
<li>
|
||
<p>The "hits" command has been enhanced. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>6/25/2002 - Samples Updated for 1.3.2</b></p>
|
||
<p>The comments in the sample configuration files have been updated
|
||
to reflect new features introduced in Shorewall 1.3.2.</p>
|
||
<p><b>6/25/2002 - Shorewall 1.3.1 Debian Package Available</b></p>
|
||
<p>Lorenzo Marignoni reports that the package is available at
|
||
<a href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
||
<p><b>6/19/2002 - Documentation Available in PDF Format</b></p>
|
||
<p>Thanks to Mike Martinez, the Shorewall Documentation is now
|
||
available for <a href="http://download.htm/">download</a> in <a
|
||
href="http://www.adobe.com/">Adobe</a>
|
||
PDF format.</p>
|
||
<p><b>6/16/2002 - Shorewall 1.3.2 Released</b></p>
|
||
<p>In this version:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A <a
|
||
href="Documentation.htm#Starting">logwatch command</a> has been added
|
||
to /sbin/shorewall. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A <a href="blacklisting_support.htm">dynamic
|
||
blacklist facility</a> has been added. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Support for the <a
|
||
href="Documentation.htm#Conf">Netfilter multiport match function</a>
|
||
has been added. </p>
|
||
</li>
|
||
<li>
|
||
<p>The files <b>firewall, functions</b> and <b>version</b> have
|
||
been moved from /etc/shorewall to /var/lib/shorewall. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>6/6/2002 - Why CVS Web access is Password Protected</b></p>
|
||
<p>Last weekend, I installed the CVS Web package to provide
|
||
brower-based access to the Shorewall CVS repository. Since then, I
|
||
have had several instances where my server was almost unusable due to
|
||
the high load generated by website copying tools like HTTrack and
|
||
WebStripper. These mindless tools:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Ignore robot.txt files. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Recursively copy everything that
|
||
they find. </p>
|
||
</li>
|
||
<li>
|
||
<p>Should be classified as weapons rather than tools. </p>
|
||
</li>
|
||
</ul>
|
||
<p>These tools/weapons are particularly damaging when combined with
|
||
CVS Web because they doggedly follow every link in the cgi-generated
|
||
HTML resulting in 1000s of executions of the cvsweb.cgi script.
|
||
Yesterday, I spend several hours implementing measures to block these
|
||
tools but unfortunately, these measures resulted in my server OOM-ing
|
||
under even moderate load.</p>
|
||
<p>Until I have the time to understand the cause of the OOM (or until
|
||
I buy more RAM if that is what is required), CVS Web access will
|
||
remain Password Protected.</p>
|
||
<p><b>6/5/2002 - Shorewall 1.3.1 Debian Package Available</b></p>
|
||
<p>Lorenzo Marignoni reports that the package is available at
|
||
<a href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
||
<p><b>6/2/2002 - Samples Corrected</b></p>
|
||
<p>The 1.3.0 samples configurations had several serious problems that
|
||
prevented DNS and SSH from working properly. These problems have been
|
||
corrected in the <a href="/pub/shorewall/samples-1.3.1">1.3.1
|
||
samples.</a></p>
|
||
<p><b>6/1/2002 - Shorewall 1.3.1 Released</b></p>
|
||
<p>Hot on the heels of 1.3.0, this release:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrects a serious problem with "all
|
||
<i><zone></i> CONTINUE" policies. This problem is present in
|
||
all versions of Shorewall that support the CONTINUE policy. These
|
||
previous versions optimized away the "all2<i><zone></i>" chain
|
||
and replaced it with the "all2all" chain with the usual result that a
|
||
policy of REJECT was enforced rather than the intended CONTINUE policy.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>Adds an <a href="Documentation.htm#rfc1918">/etc/shorewall/rfc1918</a>
|
||
file for defining the exact behavior of the <a
|
||
href="Documentation.htm#Interfaces">'norfc1918' interface option</a>. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>5/29/2002 - Shorewall 1.3.0 Released</b></p>
|
||
<p>In addition to the changes in Beta 1, Beta 2 and RC1, Shorewall
|
||
1.3.0 includes:</p>
|
||
<ul>
|
||
<li>
|
||
<p>A 'filterping' interface option that allows ICMP echo-request
|
||
(ping) requests addressed to the firewall to be handled by entries in
|
||
/etc/shorewall/rules and /etc/shorewall/policy. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>5/23/2002 - Shorewall 1.3 RC1 Available</b></p>
|
||
<p>In addition to the changes in Beta 1 and Beta 2, RC1 (Version
|
||
1.2.92) incorporates the following:</p>
|
||
<ul>
|
||
<li>
|
||
<p>Support for the /etc/shorewall/whitelist file has been
|
||
withdrawn. If you need whitelisting, see <a
|
||
href="/1.3/whitelisting_under_shorewall.htm">these instructions</a>. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>5/19/2002 - Shorewall 1.3 Beta 2 Available</b></p>
|
||
<p>In addition to the changes in Beta 1, this release which carries
|
||
the designation 1.2.91 adds:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The structure of the firewall is
|
||
changed markedly. There is now an INPUT and a FORWARD chain for each
|
||
interface; this reduces the number of rules that a packet must
|
||
traverse, especially in complicated setups. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;"><a href="Documentation.htm#Exclude">Sub-zones
|
||
may now be excluded from DNAT and REDIRECT rules.</a> </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The names of the columns in a number
|
||
of the configuration files have been changed to be more consistent and
|
||
self-explanatory and the documentation has been updated accordingly. </p>
|
||
</li>
|
||
<li>
|
||
<p>The sample configurations have been updated for 1.3. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>5/17/2002 - Shorewall 1.3 Beta 1 Available</b></p>
|
||
<p>Beta 1 carries the version designation 1.2.90 and implements the
|
||
following features:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Simplified rule syntax which makes
|
||
the intent of each rule clearer and hopefully makes Shorewall easier to
|
||
learn. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Upward compatibility with 1.2
|
||
configuration files has been maintained so that current users can
|
||
migrate to the new syntax at their convenience. </p>
|
||
</li>
|
||
<li>
|
||
<p><b><font color="#cc6666">WARNING: Compatibility with the
|
||
old parameterized sample configurations has NOT been maintained. Users
|
||
still running those configurations should migrate to the new sample
|
||
configurations before upgrading to 1.3 Beta 1.</font></b> </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>5/4/2002 - Shorewall 1.2.13 is Available</b></p>
|
||
<p>In this version:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;"><a href="Documentation.htm#Whitelist">White-listing</a>
|
||
is supported. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;"><a href="Documentation.htm#Policy">SYN-flood
|
||
protection</a> is added. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">IP addresses added under <a
|
||
href="Documentation.htm#Conf">ADD_IP_ALIASES and ADD_SNAT_ALIASES</a>
|
||
now inherit the VLSM and Broadcast Address of the interface's primary
|
||
IP address. </p>
|
||
</li>
|
||
<li>
|
||
<p>The order in which port forwarding DNAT and Static DNAT <a
|
||
href="Documentation.htm#Conf">can now be reversed</a> so that port
|
||
forwarding rules can override the contents of <a
|
||
href="Documentation.htm#NAT">/etc/shorewall/nat</a>. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>4/30/2002 - Shorewall Debian News</b></p>
|
||
<p>Lorenzo Marignoni reports that Shorewall 1.2.12 is now in both the
|
||
<a href="http://packages.debian.org/testing/net/shorewall.html">Debian
|
||
Testing Branch</a> and the <a
|
||
href="http://packages.debian.org/unstable/net/shorewall.html">Debian
|
||
Unstable Branch</a>.</p>
|
||
<p><b>4/20/2002 - Shorewall 1.2.12 is Available</b></p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The 'try' command works again </p>
|
||
</li>
|
||
<li>
|
||
<p>There is now a single RPM that also works with SuSE. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>4/17/2002 - Shorewall Debian News</b></p>
|
||
<p>Lorenzo Marignoni reports that:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall 1.2.10 is in the <a
|
||
href="http://packages.debian.org/testing/net/shorewall.html">Debian
|
||
Testing Branch</a> </p>
|
||
</li>
|
||
<li>
|
||
<p>Shorewall 1.2.11 is in the <a
|
||
href="http://packages.debian.org/unstable/net/shorewall.html">Debian
|
||
Unstable Branch</a> </p>
|
||
</li>
|
||
</ul>
|
||
<p>Thanks, Lorenzo!</p>
|
||
<p><b>4/16/2002 - Shorewall 1.2.11 RPM Available for SuSE</b></p>
|
||
<p>Thanks to <a href="mailto:s.mohr@familie-mohr.com">Stefan Mohr</a>,
|
||
there is now a Shorewall 1.2.11 <a
|
||
href="http://www.shorewall.net/pub/shorewall/shorewall-1.2-11.i686.suse73.rpm">SuSE
|
||
RPM</a> available.</p>
|
||
<p><b>4/13/2002 - Shorewall 1.2.11 Available</b></p>
|
||
<p>In this version:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The 'try' command now accepts an
|
||
optional timeout. If the timeout is given in the command, the standard
|
||
configuration will automatically be restarted after the new
|
||
configuration has been running for that length of time. This prevents a
|
||
remote admin from being locked out of the firewall in the case where
|
||
the new configuration starts but prevents access. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Kernel route filtering may now be
|
||
enabled globally using the new ROUTE_FILTER parameter in <a
|
||
href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Individual IP source addresses
|
||
and/or subnets may now be excluded from masquerading/SNAT. </p>
|
||
</li>
|
||
<li>
|
||
<p>Simple "Yes/No" and "On/Off" values are now case-insensitive in
|
||
/etc/shorewall/shorewall.conf. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>4/13/2002 - Hamburg Mirror now has FTP</b></p>
|
||
<p>Stefan now has an FTP mirror at
|
||
<a href="ftp://germany.shorewall.net/pub/shorewall" target="_blank">ftp://germany.shorewall.net/pub/shorewall</a>.
|
||
Thanks Stefan!</p>
|
||
<p><b>4/12/2002 - New Mirror in Hamburg</b></p>
|
||
<p>Thanks to <a href="mailto:s.mohr@familie-mohr.com">Stefan Mohr</a>,
|
||
there is now a mirror of the Shorewall website at
|
||
<a href="http://germany.shorewall.net/" target="_top">http://germany.shorewall.net</a>.</p>
|
||
<p><b>4/10/2002 - Shorewall QuickStart Guide Version 1.1 Available</b></p>
|
||
<p><a href="shorewall_quickstart_guide.htm">Version 1.1 of the
|
||
QuickStart Guide</a> is now available. Thanks to those who have read
|
||
version 1.0 and offered their suggestions. Corrections have also been
|
||
made to the sample scripts.</p>
|
||
<p><b>4/9/2002 - Shorewall QuickStart Guide Version 1.0 Available</b></p>
|
||
<p><a href="shorewall_quickstart_guide.htm">Version 1.0 of the
|
||
QuickStart Guide</a> is now available. This Guide and its
|
||
accompanying sample configurations are expected to provide a
|
||
replacement for the recently withdrawn parameterized samples.</p>
|
||
<p><b>4/8/2002 - Parameterized Samples Withdrawn</b></p>
|
||
<p>Although the <a
|
||
href="http://www.shorewall.net/pub/shorewall/samples-1.2.1/">parameterized
|
||
samples</a> have allowed people to get a firewall up and running
|
||
quickly, they have unfortunately set the wrong level of expectation
|
||
among those who have used them. I am therefore withdrawing support
|
||
for the samples and I am recommending that they not be used in new
|
||
Shorewall installations.</p>
|
||
<p><b>4/2/2002 - Updated Log Parser</b></p>
|
||
<p><a href="mailto:JML@redwoodtech.com">John Lodge</a> has provided
|
||
an updated version of his <a href="http://pub/shorewall/parsefw/">CGI-based
|
||
log parser</a> with corrected date handling.</p>
|
||
<p><b>3/30/2002 - Shorewall Website Search Improvements</b></p>
|
||
<p>The quick search on the home page now excludes the mailing list
|
||
archives. The <a href="http://htdig/search.html">Extended Search</a>
|
||
allows excluding the archives or restricting the search to just the
|
||
archives. An archive search form is also available on the <a
|
||
href="http://lists.shorewall.net/mailing_list.htm">mailing
|
||
list information page</a>.</p>
|
||
<p><b>3/28/2002 - Debian Shorewall News (From Lorenzo Martignoni)</b></p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The 1.2.10 Debian Package is
|
||
available at <a
|
||
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>Shorewall 1.2.9 is now in the <a
|
||
href="http://packages.debian.org/unstable/net/shorewall.html">Debian
|
||
Unstable Distribution</a>. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>3/25/2002 - Log Parser Available</b></p>
|
||
<p><a href="mailto:JML@redwoodtech.com">John Lodge</a> has provided a
|
||
<a href="http://pub/shorewall/parsefw/">CGI-based log parser</a> for
|
||
Shorewall. Thanks John.</p>
|
||
<p><b>3/20/2002 - Shorewall 1.2.10 Released</b></p>
|
||
<p>In this version:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A "shorewall try" command has been
|
||
added (syntax: shorewall try <i><configuration directory></i>).
|
||
This command attempts "shorewall -c <i><configuration directory></i>
|
||
start" and if that results in the firewall being stopped due to an
|
||
error, a "shorewall start" command is executed. The 'try' command
|
||
allows you to create a new <a href="Documentation.htm#Configs">configuration</a>
|
||
and attempt to start it; if there is an error that leaves your firewall
|
||
in the stopped state, it will automatically be restarted using the
|
||
default configuration (in /etc/shorewall). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A new variable ADD_SNAT_ALIASES has
|
||
been added to <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.
|
||
If this variable is set to "Yes", Shorewall will automatically add IP
|
||
addresses listed in the third column of the <a
|
||
href="Documentation.htm#Masq">/etc/shorewall/masq</a> file. </p>
|
||
</li>
|
||
<li>
|
||
<p>Copyright notices have been added to the documenation. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>3/11/2002 - Shorewall 1.2.9 Released</b></p>
|
||
<p>In this version:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Filtering by <a
|
||
href="Documentation.htm#MAC">MAC address</a> has been added. MAC
|
||
addresses may be used as the source address in: </p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Filtering rules (<a
|
||
href="Documentation.htm#Rules">/etc/shorewall/rules</a>) </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Traffic Control Classification
|
||
Rules (<a href="traffic_shaping.htm#tcrules">/etc/shorewall/tcrules</a>)
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">TOS Rules (<a
|
||
href="Documentation.htm#TOS">/etc/shorewall/tos</a>) </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Blacklist (<a
|
||
href="Documentation.htm#Blacklist">/etc/shorewall/blacklist</a>) </p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Several bugs have been fixed </p>
|
||
</li>
|
||
<li>
|
||
<p>The 1.2.9 Debian Package is also available at <a
|
||
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.
|
||
</p>
|
||
</li>
|
||
</ul>
|
||
<p><b>3/1/2002 - 1.2.8 Debian Package is Available</b></p>
|
||
<p>See <a href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>
|
||
<p><b>2/25/2002 - New Two-interface Sample</b></p>
|
||
<p>I've enhanced the two interface sample to allow access from the
|
||
firewall to servers in the local zone -
|
||
<a
|
||
href="http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz">http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz</a></p>
|
||
<p><b>2/23/2002 - Shorewall 1.2.8 Released</b></p>
|
||
<p>Do to a serious problem with 1.2.7, I am releasing 1.2.8. It
|
||
corrects problems associated with the lock file used to prevent
|
||
multiple state-changing operations from occuring simultaneously. My
|
||
apologies for any inconvenience my carelessness may have caused.</p>
|
||
<p><b>2/22/2002 - Shorewall 1.2.7 Released</b></p>
|
||
<p>In this version:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">UPnP probes (UDP destination port
|
||
1900) are now silently dropped in the <i>common</i> chain </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">RFC 1918 checking in the mangle
|
||
table has been streamlined to no longer require packet marking. RFC
|
||
1918 checking in the filter table has been changed to require half as
|
||
many rules as previously. </p>
|
||
</li>
|
||
<li>
|
||
<p>A 'shorewall check' command has been added that does a cursory
|
||
validation of the zones, interfaces, hosts, rules and policy files. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>2/18/2002 - 1.2.6 Debian Package is Available</b></p>
|
||
<p>See <a href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>
|
||
<p><b>2/8/2002 - Shorewall 1.2.6 Released</b></p>
|
||
<p>In this version:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">$-variables may now be used anywhere
|
||
in the configuration files except /etc/shorewall/zones. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The interfaces and hosts files now
|
||
have their contents validated before any changes are made to the
|
||
existing Netfilter configuration. The appearance of a zone name that
|
||
isn't defined in /etc/shorewall/zones causes "shorewall start" and
|
||
"shorewall restart" to abort without changing the Shorewall state.
|
||
Unknown options in either file cause a warning to be issued. </p>
|
||
</li>
|
||
<li>
|
||
<p>A problem occurring when BLACKLIST_LOGLEVEL was not set has been
|
||
corrected. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>2/4/2002 - Shorewall 1.2.5 Debian Package Available</b></p>
|
||
<p>see <a href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>
|
||
<p><b>2/1/2002 - Shorewall 1.2.5 Released</b></p>
|
||
<p>Due to installation problems with Shorewall 1.2.4, I have released
|
||
Shorewall 1.2.5. Sorry for the rapid-fire development.</p>
|
||
<p>In version 1.2.5:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The installation problems have been
|
||
corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;"><a href="Documentation.htm#Masq">SNAT</a>
|
||
is now supported. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A "shorewall version" command has
|
||
been added </p>
|
||
</li>
|
||
<li>
|
||
<p>The default value of the STATEDIR variable in
|
||
/etc/shorewall/shorewall.conf has been changed to /var/lib/shorewall in
|
||
order to conform to the GNU/Linux File Hierarchy Standard, Version 2.2.
|
||
</p>
|
||
</li>
|
||
</ul>
|
||
<p><b>1/28/2002 - Shorewall 1.2.4 Released</b></p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The "fw" zone <a
|
||
href="Documentation.htm#FW">may now be given a different name</a>. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">You may now place end-of-line
|
||
comments (preceded by '#') in any of the configuration files </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">There is now protection against
|
||
against two state changing operations occuring concurrently. This is
|
||
implemented using the 'lockfile' utility if it is available (lockfile
|
||
is part of procmail); otherwise, a less robust technique is used. The
|
||
lockfile is created in the STATEDIR defined in
|
||
/etc/shorewall/shorewall.conf and has the name "lock". </p>
|
||
</li>
|
||
<li>
|
||
<p>"shorewall start" no longer fails if "detect" is specified in <a
|
||
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a> for
|
||
an interface with subnet mask 255.255.255.255. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>1/27/2002 - Shorewall 1.2.3 Debian Package Available</b> -- see
|
||
<a href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>
|
||
<p><b>1/20/2002 - Corrected firewall script available </b></p>
|
||
<p>Corrects a problem with BLACKLIST_LOGLEVEL. See <a
|
||
href="http://errata.htm/">the
|
||
errata</a> for details.</p>
|
||
<p><b>1/19/2002 - Shorewall 1.2.3 Released</b></p>
|
||
<p>This is a minor feature and bugfix release. The single new feature
|
||
is:</p>
|
||
<ul>
|
||
<li>
|
||
<p>Support for TCP MSS Clamp to PMTU -- This support is usually
|
||
required when the internet connection is via PPPoE or PPTP and may be
|
||
enabled using the <a href="Documentation.htm#ClampMSS">CLAMPMSS</a>
|
||
option in /etc/shorewall/shorewall.conf. </p>
|
||
</li>
|
||
</ul>
|
||
<p>The following problems were corrected:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The "shorewall status" command no
|
||
longer hangs. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The "shorewall monitor" command now
|
||
displays the icmpdef chain </p>
|
||
</li>
|
||
<li>
|
||
<p>The CLIENT PORT(S) column in tcrules is no longer ignored </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>1/18/2002 - Shorewall 1.2.2 packaged with new</b> <a
|
||
href="http://leaf.sourceforge.net/">LEAF</a>
|
||
<b>release</b></p>
|
||
<p>Jacques Nilo and Eric Wolzak have released a kernel 2.4.16 LEAF
|
||
distribution that includes Shorewall 1.2.2. See
|
||
<a href="http://leaf.sourceforge.net/devel/jnilo">http://leaf.sourceforge.net/devel/jnilo</a>
|
||
for details.</p>
|
||
<p><b>1/11/2002 - Debian Package (.deb) Now Available -</b> Thanks to
|
||
<a href="mailto:lorenzo.martignoni@milug.org">Lorenzo Martignoni</a>,
|
||
a 1.2.2 Shorewall Debian package is now available. There is a link to
|
||
Lorenzo's site from the <a href="http://download.htm/">Shorewall
|
||
download page</a>.</p>
|
||
<p><b>1/9/2002 - Updated 1.2.2 /sbin/shorewall available -</b> <a
|
||
href="/pub/shorewall/errata/1.2.2/shorewall">This
|
||
corrected version</a> restores the "shorewall status"
|
||
command to health.</p>
|
||
<p><b>1/8/2002 - Shorewall 1.2.2 Released</b></p>
|
||
<p>In version 1.2.2</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Support for IP blacklisting has been
|
||
added </p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">You specify whether you want
|
||
packets from blacklisted hosts dropped or rejected using the <a
|
||
href="Documentation.htm#BLDisposition">BLACKLIST_DISPOSITION</a>
|
||
setting in /etc/shorewall/shorewall.conf </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">You specify whether you want
|
||
packets from blacklisted hosts logged and at what syslog level using
|
||
the <a href="Documentation.htm#BLLoglevel">BLACKLIST_LOGLEVEL</a>
|
||
setting in /etc/shorewall/shorewall.conf </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">You list the IP
|
||
addresses/subnets that you wish to blacklist in <a
|
||
href="Documentation.htm#Blacklist">/etc/shorewall/blacklist</a> </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">You specify the interfaces you
|
||
want checked against the blacklist using the new "<a
|
||
href="Documentation.htm#BLInterface">blacklist</a>" option in
|
||
/etc/shorewall/interfaces. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The black list is refreshed from
|
||
/etc/shorewall/blacklist by the "shorewall refresh" command. </p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Use of TCP RST replies has been
|
||
expanded </p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">TCP connection requests rejected
|
||
because of a REJECT policy are now replied with a TCP RST packet. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">TCP connection requests rejected
|
||
because of a protocol=all rule in /etc/shorewall/rules are now replied
|
||
with a TCP RST packet. </p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p>A <a href="Documentation.htm#Logfile">LOGFILE</a> specification
|
||
has been added to /etc/shorewall/shorewall.conf. LOGFILE is used to
|
||
tell the /sbin/shorewall program where to look for Shorewall messages. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>1/5/2002 - New Parameterized Samples (<a
|
||
href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.2.0/"
|
||
target="_blank">version
|
||
1.2.0</a>) released.</b> These are minor updates to the
|
||
previously-released samples. There are two new rules added:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Unless you have explicitly enabled
|
||
Auth connections (tcp port 113) to your firewall, these connections
|
||
will be REJECTED rather than DROPPED. This speeds up connection
|
||
establishment to some servers. </p>
|
||
</li>
|
||
<li>
|
||
<p>Orphan DNS replies are now silently dropped. </p>
|
||
</li>
|
||
</ul>
|
||
<p>See the README file for upgrade instructions.</p>
|
||
<p><b>1/1/2002 - <u><font color="#ff6633">Shorewall Mailing List
|
||
Moving</font></u></b></p>
|
||
<p>The Shorewall mailing list hosted at <a
|
||
href="http://sourceforge.net/">Sourceforge</a>
|
||
is moving to Shorewall.net. If you are a current subscriber to the
|
||
list at Sourceforge, please <a
|
||
href="shorewall_mailing_list_migration.htm">see
|
||
these instructions</a>. If you would like to subscribe to the new
|
||
list, visit
|
||
<a href="http://www.shorewall.net/mailman/listinfo/shorewall-users">http://www.shorewall.net/mailman/listinfo/shorewall-users</a>.</p>
|
||
<p><b>12/31/2001 - Shorewall 1.2.1 Released</b></p>
|
||
<p>In version 1.2.1:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;"><a
|
||
href="Documentation.htm#LogUncleanOption">Logging of Mangled/Invalid
|
||
Packets</a> is added. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The <a href="http://IPIP.htm/">tunnel
|
||
script</a> has been corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p>'shorewall show tc' now correctly handles tunnels. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>12/21/2001 - Shorewall 1.2.0 Released!</b> - <b>I couldn't
|
||
resist releasing 1.2 on 12/21/2001</b></p>
|
||
<p>Version 1.2 contains the following new features:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Support for <a
|
||
href="traffic_shaping.htm">Traffic Control/Shaping</a> </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Support for <a
|
||
href="Documentation.htm#Unclean">Filtering of Mangled/Invalid Packets</a>
|
||
</p>
|
||
</li>
|
||
<li>
|
||
<p>Support for <a href="http://IPIP.htm/">GRE Tunnels</a> </p>
|
||
</li>
|
||
</ul>
|
||
<p>For the next month or so, I will continue to provide corrections
|
||
to version 1.1.18 as necessary so that current version 1.1.x users
|
||
will not be forced into a quick upgrade to 1.2.0 just to have access
|
||
to bug fixes.</p>
|
||
<p>For those of you who have installed one of the Beta RPMS, you will
|
||
need to use the "--oldpackage" option when upgrading to
|
||
1.2.0:</p>
|
||
<blockquote>rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm</blockquote>
|
||
<p><b>12/19/2001 - Thanks to <a href="mailto:scowles@infohiiway.com">Steve
|
||
Cowles</a>, there is now a Shorewall mirror in Texas.</b> This web
|
||
site is mirrored at <a href="http://www.infohiiway.com/shorewall"
|
||
target="_top">http://www.infohiiway.com/shorewall</a>
|
||
and the ftp site is at
|
||
<a href="ftp://ftp.infohiiway.com/pub/mirrors/shorewall">ftp://ftp.infohiiway.com/pub/mirrors/shorewall</a>.
|
||
</p>
|
||
<p><b>11/30/2001 - A new set of the parameterized <a
|
||
href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.18">Sample
|
||
Configurations</a> has been released</b>. In this version:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Ping is now allowed between the
|
||
zones. </p>
|
||
</li>
|
||
<li>
|
||
<p>In the three-interface configuration, it is now possible to
|
||
configure the internet services that are to be available to servers in
|
||
the DMZ. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>11/20/2001 - The current version of Shorewall is 1.1.18. </b></p>
|
||
<p>In this version:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The spelling of ADD_IP_ALIASES has
|
||
been corrected in the shorewall.conf file </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The logic for deleting user-defined
|
||
chains has been simplified so that it avoids a bug in the LRP version
|
||
of the 'cut' utility. </p>
|
||
</li>
|
||
<li>
|
||
<p>The /var/lib/lrpkg/shorwall.conf file has been corrected to
|
||
properly display the NAT entry in that file. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>11/19/2001 - Thanks to <a href="mailto:shorewall@timelord.sk">Juraj
|
||
Ontkanin</a>, there is now a Shorewall mirror in the Slovak Republic</b>.
|
||
The website is now mirrored at <a
|
||
href="http://www.nrg.sk/mirror/shorewall" target="_top">http://www.nrg.sk/mirror/shorewall</a>
|
||
and the FTP site is mirrored at <a
|
||
href="ftp://ftp.nrg.sk/mirror/shorewall">ftp://ftp.nrg.sk/mirror/shorewall</a>.</p>
|
||
<p><b>11/2/2001 - Announcing Shorewall Parameter-driven Sample
|
||
Configurations.</b> There are three sample configurations:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">One Interface -- for a standalone
|
||
system. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Two Interfaces -- A masquerading
|
||
firewall. </p>
|
||
</li>
|
||
<li>
|
||
<p>Three Interfaces -- A masquerading firewall with DMZ. </p>
|
||
</li>
|
||
</ul>
|
||
<p>Samples may be downloaded from
|
||
<a href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17">ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17</a>
|
||
. See the README file for instructions.</p>
|
||
<p><b>11/1/2001 - The current version of Shorewall is 1.1.17</b>.
|
||
I intend this to be the last of the 1.1 Shorewall releases.</p>
|
||
<p>In this version:</p>
|
||
<ul>
|
||
<li>
|
||
<p>The handling of <a href="Documentation.htm#Aliases">ADD_IP_ALIASES</a>
|
||
has been corrected. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>10/22/2001 - The current version of Shorewall is 1.1.16</b>. In
|
||
this version:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A new "shorewall show connections"
|
||
command has been added. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">In the "shorewall monitor" output,
|
||
the currently tracked connections are now shown on a separate page. </p>
|
||
</li>
|
||
<li>
|
||
<p>Prior to this release, Shorewall unconditionally added the
|
||
external IP adddress(es) specified in /etc/shorewall/nat. Beginning
|
||
with version 1.1.16, a new parameter (<a
|
||
href="Documentation.htm#Aliases">ADD_IP_ALIASES</a>) may be set to
|
||
"no" (or "No") to inhibit this behavior. This allows IP aliases created
|
||
using your distribution's network configuration tools to be used in
|
||
static NAT. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>10/15/2001 - The current version of Shorewall is 1.1.15.</b> In
|
||
this version:</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Support for nested zones has been
|
||
improved. See <a href="Documentation.htm#Nested">the documentation</a>
|
||
for details </p>
|
||
</li>
|
||
<li>
|
||
<p>Shorewall now correctly checks the alternate configuration
|
||
directory for the 'zones' file. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>10/4/2001 - The current version of Shorewall is 1.1.14.</b> In
|
||
this version</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall now supports alternate
|
||
configuration directories. When an alternate directory is specified
|
||
when starting or restarting Shorewall (e.g., "shorewall -c
|
||
/etc/testconf restart"), Shorewall will first look for configuration
|
||
files in the alternate directory then in /etc/shorewall. To create an
|
||
alternate configuration simply:<br>
|
||
1. Create a New Directory<br>
|
||
2. Copy to that directory any of your configuration files that you want
|
||
to change.<br>
|
||
3. Modify the copied files as needed.<br>
|
||
4. Restart Shorewall specifying the new directory. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The rules for allowing/disallowing
|
||
icmp echo-requests (pings) are now moved after rules created when
|
||
processing the rules file. This allows you to add rules that
|
||
selectively allow/deny ping based on source or destination address. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Rules that specify multiple client
|
||
ip addresses or subnets no longer cause startup failures. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Zone names in the policy file are
|
||
now validated against the zones file. </p>
|
||
</li>
|
||
<li>
|
||
<p>If you have <a href="Documentation.htm#MangleEnabled">packet
|
||
mangling</a> support enabled, the "<a
|
||
href="Documentation.htm#Interfaces">norfc1918</a>" interface option
|
||
now logs and drops any incoming packets on the interface that have an
|
||
RFC 1918 destination address. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>9/12/2001 - The current version of Shorewall is 1.1.13</b>. In
|
||
this version</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shell variables can now be used to
|
||
parameterize Shorewall rules. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The second column in the hosts file
|
||
may now contain a comma-separated list.<br>
|
||
<br>
|
||
Example:<br>
|
||
sea
|
||
eth0:130.252.100.0/24,206.191.149.0/24 </p>
|
||
</li>
|
||
<li>
|
||
<p>Handling of multi-zone interfaces has been improved. See the <a
|
||
href="Documentation.htm#Interfaces">documentation for the
|
||
/etc/shorewall/interfaces file</a>. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>8/28/2001 - The current version of Shorewall is 1.1.12</b>. In
|
||
this version</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Several columns in the rules file
|
||
may now contain comma-separated lists. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall is now more rigorous in
|
||
parsing the options in /etc/shorewall/interfaces. </p>
|
||
</li>
|
||
<li>
|
||
<p>Complementation using "!" is now supported in rules. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>7/28/2001 - The current version of Shorewall is 1.1.11</b>. In
|
||
this version</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A "shorewall refresh" command has
|
||
been added to allow for refreshing the rules associated with the
|
||
broadcast address on a dynamic interface. This command should be used
|
||
in place of "shorewall restart" when the internet interface's IP
|
||
address changes. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The /etc/shorewall/start file (if
|
||
any) is now processed after all temporary rules have been deleted. This
|
||
change prevents the accidental removal of rules added during the
|
||
processing of that file. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The "dhcp" interface option is now
|
||
applicable to firewall interfaces used by a DHCP server running on the
|
||
firewall. </p>
|
||
</li>
|
||
<li>
|
||
<p>The RPM can now be built from the .tgz file using "rpm
|
||
-tb" </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>7/6/2001 - The current version of Shorewall is 1.1.10.</b> In
|
||
this version</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Shorewall now enables Ipv4 Packet
|
||
Forwarding by default. Packet forwarding may be disabled by specifying
|
||
IP_FORWARD=Off in /etc/shorewall/shorewall.conf. If you don't want
|
||
Shorewall to enable or disable packet forwarding, add
|
||
IP_FORWARDING=Keep to your /etc/shorewall/shorewall.conf file. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The "shorewall hits" command no
|
||
longer lists extraneous service names in its last report. </p>
|
||
</li>
|
||
<li>
|
||
<p>Erroneous instructions in the comments at the head of the
|
||
firewall script have been corrected. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>6/23/2001 - The current version of Shorewall is 1.1.9.</b> In
|
||
this version</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The "tunnels" file <u>really</u> is
|
||
in the RPM now. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">SNAT can now be applied to
|
||
port-forwarded connections. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A bug which would cause firewall
|
||
start failures in some dhcp configurations has been fixed. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The firewall script now issues a
|
||
message if you have the name of an interface in the second column in an
|
||
entry in /etc/shorewall/masq and that interface is not up. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">You can now configure Shorewall so
|
||
that it <a href="Documentation.htm#NatEnabled">doesn't require the NAT
|
||
and/or mangle netfilter modules</a>. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Thanks to Alex Polishchuk, the
|
||
"hits" command from seawall is now in shorewall. </p>
|
||
</li>
|
||
<li>
|
||
<p>Support for <a href="http://IPIP.htm/">IPIP tunnels</a> has
|
||
been added. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>6/18/2001 - The current version of Shorewall is 1.1.8</b>. In
|
||
this version</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A typo in the sample rules file has
|
||
been corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">It is now possible to restrict
|
||
masquerading by <a href="Documentation.htm#Masq">destination host or
|
||
subnet.</a> </p>
|
||
</li>
|
||
<li>
|
||
<p>It is now possible to have static <a href="NAT.htm#LocalPackets">NAT
|
||
rules applied to packets originating on the firewall itself</a>. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>6/2/2001 - The current version of Shorewall is 1.1.7.</b> In
|
||
this version</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The TOS rules are now deleted when
|
||
the firewall is stopped. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The .rpm will now install regardless
|
||
of which version of iptables is installed. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The .rpm will now install without
|
||
iproute2 being installed. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The documentation has been cleaned
|
||
up. </p>
|
||
</li>
|
||
<li>
|
||
<p>The sample configuration files included in Shorewall have been
|
||
formatted to 80 columns for ease of editing on a VGA console. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>5/25/2001 - The current version of Shorewall is 1.1.6</b>. In
|
||
this version</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;"><a href="Documentation.htm#lograte">You
|
||
may now rate-limit the packet log.</a> </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Previous versions of Shorewall have
|
||
an implementation of Static NAT which violates the principle of least
|
||
surprise. NAT only occurs for packets arriving at (DNAT) or send
|
||
from (SNAT) the interface named in the INTERFACE column of
|
||
/etc/shorewall/nat. Beginning with version 1.1.6, NAT effective
|
||
regardless of which interface packets come from or are destined to. To
|
||
get compatibility with prior versions, I have added a new "ALL <a
|
||
href="NAT.htm#AllInterFaces">"ALL INTERFACES" column to
|
||
/etc/shorewall/nat</a>. By placing "no" or "No" in the new column, the
|
||
NAT behavior of prior versions may be retained. </p>
|
||
</li>
|
||
<li>
|
||
<p>The treatment of <a href="IPSEC.htm#RoadWarrior">IPSEC Tunnels
|
||
where the remote gateway is a standalone system has been improved</a>.
|
||
Previously, it was necessary to include an additional rule allowing UDP
|
||
port 500 traffic to pass through the tunnel. Shorewall will now create
|
||
this rule automatically when you place the name of the remote peer's
|
||
zone in a new GATEWAY ZONE column in /etc/shorewall/tunnels. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>5/20/2001 - The current version of Shorewall is 1.1.5.</b> In
|
||
this version</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;"><a href="Documentation.htm#modules">You
|
||
may now pass parameters when loading netfilter modules and you can
|
||
specify the modules to load.</a> </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Compressed modules are now loaded.
|
||
This requires that you modutils support loading compressed modules. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;"><a href="Documentation.htm#TOS">You
|
||
may now set the Type of Service (TOS) field in packets.</a> </p>
|
||
</li>
|
||
<li>
|
||
<p>Corrected rules generated for port redirection (again). </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>5/10/2001 - The current version of Shorewall is 1.1.4.</b> In
|
||
this version</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;"><a href="Documentation.htm#Conf">Accepting
|
||
RELATED connections is now optional.</a> </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected problem where if
|
||
"shorewall start" aborted early (due to kernel configuration errors for
|
||
example), superfluous 'sed' error messages were reported. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Corrected rules generated for port
|
||
redirection. </p>
|
||
</li>
|
||
<li>
|
||
<p>The order in which iptables kernel modules are loaded has been
|
||
corrected (Thanks to Mark Pavlidis). </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>4/28/2001 - The current version of Shorewall is 1.1.3.</b> In
|
||
this version</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Correct message issued when Proxy
|
||
ARP address added (Thanks to Jason Kirtland). </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">/tmp/shorewallpolicy-$$ is now
|
||
removed if there is an error while starting the firewall. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">/etc/shorewall/icmp.def and
|
||
/etc/shorewall/common.def are now used to define the icmpdef and common
|
||
chains unless overridden by the presence of /etc/shorewall/icmpdef or
|
||
/etc/shorewall/common. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">In the .lrp, the file
|
||
/var/lib/lrpkg/shorwall.conf has been corrected. An extra space after
|
||
"/etc/shorwall/policy" has been removed and "/etc/shorwall/rules" has
|
||
been added. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">When a sub-shell encounters a fatal
|
||
error and has stopped the firewall, it now kills the main shell so that
|
||
the main shell will not continue. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">A problem has been corrected where a
|
||
sub-shell stopped the firewall and main shell continued resulting in a
|
||
perplexing error message referring to "common.so" resulted. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Previously, placing "-" in the
|
||
PORT(S) column in /etc/shorewall/rules resulted in an error message
|
||
during start. This has been corrected. </p>
|
||
</li>
|
||
<li>
|
||
<p>The first line of "install.sh" has been corrected -- I had
|
||
inadvertently deleted the initial "#". </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>4/12/2001 - The current version of Shorewall is 1.1.2.</b> In
|
||
this version</p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Port redirection now works again. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The icmpdef and common chains <a
|
||
href="Documentation.htm#Icmpdef">may now be user-defined</a>. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The firewall no longer fails to
|
||
start if "routefilter" is specified for an interface that isn't
|
||
started. A warning message is now issued in this case. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The LRP Version is renamed
|
||
"shorwall" for 8,3 MSDOS file system compatibility. </p>
|
||
</li>
|
||
<li>
|
||
<p>A couple of LRP-specific problems were corrected. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>4/8/2001 - Shorewall is now affiliated with the <a
|
||
href="http://leaf.sourceforge.net/">Leaf
|
||
Project</a></b> <a href="http://leaf.sourceforge.net/"><img
|
||
src="images/leaflogo.gif" name="graphics5" alt="Leaf Logo"
|
||
align="bottom" border="0" height="36" width="49"></a></p>
|
||
<p><b>4/5/2001 - The current version of Shorewall is 1.1.1. In this
|
||
version:</b></p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The common chain is traversed from
|
||
INPUT, OUTPUT and FORWARD before logging occurs </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The source has been cleaned up
|
||
dramatically </p>
|
||
</li>
|
||
<li>
|
||
<p>DHCP DISCOVER packets with RFC1918 source addresses no longer
|
||
generate log messages. Linux DHCP clients generate such packets and
|
||
it's annoying to see them logged. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>3/25/2001 - The current version of Shorewall is 1.1.0. In this
|
||
version:</b></p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Log messages now indicate the packet
|
||
disposition. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Error messages have been improved. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The ability to define zones
|
||
consisting of an enumerated set of hosts and/or subnetworks has been
|
||
added. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The zone-to-zone chain matrix is now
|
||
sparse so that only those chains that contain meaningful rules are
|
||
defined. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">240.0.0.0/4 and 169.254.0.0/16 have
|
||
been added to the source subnetworks whose packets are dropped under
|
||
the <i>norfc1918</i> interface option. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Exits are now provided for executing
|
||
an user-defined script when a chain is defined, when the firewall is
|
||
initialized, when the firewall is started, when the firewall is stopped
|
||
and when the firewall is cleared. </p>
|
||
</li>
|
||
<li>
|
||
<p>The Linux kernel's route filtering facility can now be specified
|
||
selectively on network interfaces. </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>3/19/2001 - The current version of Shorewall is 1.0.4. This
|
||
version:</b></p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Allows user-defined zones. Shorewall
|
||
now has only one pre-defined zone (fw) with the remaining zones being
|
||
defined in the new configuration file /etc/shorewall/zones. The
|
||
/etc/shorewall/zones file released in this version provides behavior
|
||
that is compatible with Shorewall 1.0.3. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Adds the ability to specify logging
|
||
in entries in the /etc/shorewall/rules file. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">Correct handling of the icmp-def
|
||
chain so that only ICMP packets are sent through the chain. </p>
|
||
</li>
|
||
<li>
|
||
<p>Compresses the output of "shorewall monitor" if awk is
|
||
installed. Allows the command to work if awk isn't installed (although
|
||
it's not pretty). </p>
|
||
</li>
|
||
</ul>
|
||
<p><b>3/13/2001 - The current version of Shorewall is 1.0.3. This is
|
||
a bug-fix release with no new features.</b></p>
|
||
<ul>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">The PATH variable in the firewall
|
||
script now includes /usr/local/bin and /usr/local/sbin. </p>
|
||
</li>
|
||
<li>
|
||
<p style="margin-bottom: 0in;">DMZ-related chains are now correctly
|
||
deleted if the DMZ is deleted. </p>
|
||
</li>
|
||
<li>
|
||
<p>The interface OPTIONS for "gw" interfaces are no longer ignored.
|
||
</p>
|
||
</li>
|
||
</ul>
|
||
<p><b>3/8/2001 - The current version of Shorewall is 1.0.2. It
|
||
supports an additional "gw" (gateway) zone for tunnels and
|
||
it supports IPSEC tunnels with end-points on the firewall. There is
|
||
also a .lrp available now.</b></p>
|
||
</body>
|
||
</html>
|