forked from extern/shorewall_code
713617cf4e
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2105 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
8623 lines
370 KiB
HTML
8623 lines
370 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||
<html>
|
||
<head>
|
||
<meta name="generator" content="HTML Tidy, see www.w3.org">
|
||
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
<title>Shorewall News</title>
|
||
</head>
|
||
<body>
|
||
<h1 style="text-align: left;">Shorewall News and Announcements<br>
|
||
</h1>
|
||
<span style="font-weight: bold;">Tom Eastep<br>
|
||
<br>
|
||
</span>Copyright © 2001-2005 Thomas M. Eastep<br>
|
||
<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 “<span
|
||
class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free
|
||
Documentation License</a></span>”.<br>
|
||
</p>
|
||
<p>2005-05-09<br>
|
||
</p>
|
||
<hr style="width: 100%; height: 2px;">
|
||
<p><span style="font-weight: bold;">05/09/2005 I will not be reading
|
||
list posts for a while</span></p>
|
||
<p>I occasionally need a break from answering the same silly questions
|
||
over and over and over and ...<br>
|
||
</p>
|
||
<p>It is truly upbelivable that people can find the address of the
|
||
mailing list on the Shorewall web sites yet they cannot find anything
|
||
else including:<br>
|
||
</p>
|
||
<ul>
|
||
<li>The instructions for submitting a usable problem report
|
||
(http://shorewall.net/support.htm)</li>
|
||
<li>The FAQ (http://shorewall.net/FAQ.htm)</li>
|
||
</ul>
|
||
So rather than continuing to raise my blood pressure by calling these
|
||
people MISERABLE IDIOT (which they are), I'm going to just ignore all
|
||
list posts for a while. I've unsubscribed from the user's list in order
|
||
that I not be distracted by the bleating ...<br>
|
||
<p><span style="font-weight: bold;">05/02/2005 Shorewall 2.2.4<br>
|
||
</span></p>
|
||
<p>Problems Corrected:<br>
|
||
</p>
|
||
<ol>
|
||
<li>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></li>
|
||
<li>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></li>
|
||
</ol>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>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.</li>
|
||
</ol>
|
||
<div style="margin-left: 40px;"><span style="font-weight: bold;">WARNING</span>:<br>
|
||
<div style="margin-left: 40px;">From a security architecture viewpoint,
|
||
UPnP is a disaster. It assumes that:<br>
|
||
<ol style="list-style-type: lower-alpha;">
|
||
<li>All local systems and their users are completely trustworthy.</li>
|
||
<li>No local system is infected with any worm or trojan.</li>
|
||
</ol>
|
||
</div>
|
||
<div style="margin-left: 40px;">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: <span style="font-weight: bold;">USE UPnP AT YOUR OWN RISK</span>.<br>
|
||
</div>
|
||
<div style="margin-left: 40px;"><br>
|
||
</div>
|
||
</div>
|
||
<div style="margin-left: 40px;"><span style="font-weight: bold;">WARNING</span>:<br>
|
||
<div style="margin-left: 40px;">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).<br>
|
||
<br>
|
||
</div>
|
||
</div>
|
||
<div style="margin-left: 40px;">Configuring linux-igd:<br>
|
||
<div style="margin-left: 40px;">In /etc/upnpd.conf, you will want:<br>
|
||
<br>
|
||
|
||
insert_forward_rules = yes<br>
|
||
|
||
prerouting_chain_name = UPnP<br>
|
||
|
||
forward_chain_name = forwardUPnP<br>
|
||
<br>
|
||
</div>
|
||
</div>
|
||
<div style="margin-left: 40px;">Shorewall Configuration:<br>
|
||
<div style="margin-left: 40px;">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<br>
|
||
<br>
|
||
</div>
|
||
</div>
|
||
<div style="margin-left: 40px;"> You must also ensure that
|
||
you have a route to 224.0.0.0/4 on you internal (local) interface.<br>
|
||
</div>
|
||
<ol start="2" style="list-style-type: decimal;">
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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=""<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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:~#<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>The installer now detects that it is running on a Slackware
|
||
system and adjusts the DEST and INIT variables accordingly.<br>
|
||
</li>
|
||
</ol>
|
||
<p><span style="font-weight: bold;">05/01/2005 Tom
|
||
spoke at LinuxFest NW 2005 -- Bellingham Technical College,
|
||
Bellingham Washington<br>
|
||
</span><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>
|
||
<span style="font-weight: bold;">04/07/2005
|
||
Shorewall 2.2.3<br>
|
||
</span><br>
|
||
Problems Corrected:<br>
|
||
</p>
|
||
<ol>
|
||
<li>If a zone is defined in /etc/shorewall/hosts using
|
||
<interface>:!<network> in the HOSTS column then startup
|
||
errors occur on "shorewall [re]start".</li>
|
||
<li>Previously, if "shorewall status" was run on a system whose
|
||
kernel lacked advanced routing support
|
||
(CONFIG_IP_ADVANCED_ROUTER), then no routing information was
|
||
displayed.</li>
|
||
</ol>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>A new extension script "continue" has been added. This script is
|
||
invoked after Shorewall has set the built-in filter chains policy to
|
||
DROP, deleted any existing Netfilter rules and user chains and has
|
||
enabled existing connections. It is useful for enabling certain
|
||
communication while Shorewall is being [re]started. Be sure to delete
|
||
any rules that you add here in your /etc/shorewall/start file.</li>
|
||
<li>There has been ongoing confusion about how the
|
||
/etc/shorewall/routestopped file works. People understand how it works
|
||
with the 'shorewall stop' command but when they read that 'shorewall
|
||
restart' is logically equivalent to 'shorewall stop' followed by
|
||
'shorewall start' then they erroneously conclude that
|
||
/etc/shorewall/routestopped can be used to enable new connections
|
||
during 'shorewall restart'. Up to now, it cannot -- that file is not
|
||
processed during either 'shorewall start' or 'shorewall restart'.<br>
|
||
<br>
|
||
Beginning with Shorewall version 2.2.3, /etc/shorewall/routestopped
|
||
will be processed TWICE during 'shorewall start' and during 'shorewall
|
||
restart'. It will be processed early in the command execution to add
|
||
rules allowing new connections while the command is running and it will
|
||
be processed again when the command is complete to remove the rules
|
||
added earlier.<br>
|
||
<br>
|
||
The result of this change will be that during most of [re]start, new
|
||
connections will be allowed in accordance with the contents of
|
||
/etc/shorewall/routestopped.</li>
|
||
<li>The performance of configurations with a large numbers of entries
|
||
in /etc/shorewall/maclist can be improved by setting the new
|
||
MACLIST_TTL variable in /etc/shorewall/shorewall.conf.<br>
|
||
<br>
|
||
If your iptables and kernel support the "Recent Match" (see the output
|
||
of "shorewall check" near the top), you can cache the results of a
|
||
'maclist' file lookup and thus reduce the overhead associated with MAC
|
||
Verification.<br>
|
||
<br>
|
||
When a new connection arrives from a 'maclist' interface, the packet
|
||
passes through then list of entries for that interface in
|
||
/etc/shorewall/maclist. If there is a match then the source IP address
|
||
is added to the 'Recent' set for that interface. Subsequent connection
|
||
attempts from that IP address occuring within $MACLIST_TTL seconds will
|
||
be accepted without having to scan all of the entries. After
|
||
$MACLIST_TTL from the first accepted connection request from an IP
|
||
address, the next connection request from that IP address will be
|
||
checked against the entire list.<br>
|
||
<br>
|
||
If MACLIST_TTL is not specified or is specified as empty (e.g,
|
||
MACLIST_TTL="" or is specified as zero then 'maclist' lookups will not
|
||
be cached.</li>
|
||
<li>You can now specify QUEUE as a policy and you can designate a
|
||
common action for QUEUE policies in /etc/shorewall/actions. This is
|
||
useful for sending packets to something like Snort Inline.<br>
|
||
</li>
|
||
</ol>
|
||
<span style="font-weight: bold;">03/31/2005
|
||
Shorewall 2.0.17<br>
|
||
<br>
|
||
</span>Problems Corrected:<br>
|
||
<ol>
|
||
<li>Invoking the 'rejNotSyn' action results in an error at startup.</li>
|
||
<li>The UDP and TCP port numbers in
|
||
/usr/share/shorewall/action.AllowPCA were reversed.</li>
|
||
<li>If a zone is defined in /etc/shorewall/hosts using <<span
|
||
style="font-style: italic;">interface</span>>:!<<span
|
||
style="font-style: italic;">network</span>> in the HOSTS column
|
||
then startup errors occur on "shorewall [re]start".<br>
|
||
</li>
|
||
</ol>
|
||
<span style="font-weight: bold;">03/12/2005
|
||
Shorewall 2.2.2<br>
|
||
</span><br>
|
||
Problems Corrected:<br>
|
||
<ol>
|
||
<li>The SOURCE column in the /etc/shorewall/tcrules file now
|
||
correctly allows IP ranges (assuming that your iptables and kernel
|
||
support ranges).<br>
|
||
</li>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>The port numbers for UDP and TCP were previously reversed in the
|
||
/usr/share/shorewall/action.AllowPCA file.</li>
|
||
<li>Previously, the 'install.sh' script did not update the
|
||
/usr/share/shorewall/action.* files.</li>
|
||
<li>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.<br>
|
||
</li>
|
||
</ol>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>The output from 'arp -na' has been added to the 'shorewall
|
||
status' display.</li>
|
||
<li>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.</li>
|
||
<li>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>
|
||
<span style="font-family: monospace;">
|
||
SUBNETS TARGET</span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;">
|
||
192.168.1.0/24 RETURN</span><br>
|
||
<br>
|
||
then traffic from 192.168.1.4 to 10.0.3.9 will be accepted even though
|
||
you also have:<br>
|
||
<br>
|
||
<span style="font-family: monospace;">
|
||
SUBNETS TARGET</span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;">
|
||
10.0.0.0/8 logdrop</span><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.<br>
|
||
</li>
|
||
</ol>
|
||
<span style="font-weight: bold;"></span><span style="font-weight: bold;"></span>
|
||
<p><span style="font-weight: bold;">02/15/2005
|
||
Shorewall 2.2.1<br>
|
||
<br>
|
||
</span>This release rolls up the fixes for bugs found in the first 2-3
|
||
weeks of deployment of Shorewall 2.2.<br>
|
||
</p>
|
||
<ol>
|
||
<li>The /etc/shorewall/policy file contained a misleading comment and
|
||
both that file and the /etc/shorewall/zones file lacked examples.</li>
|
||
<li>Shorewall previously used root's default umask which could cause
|
||
files in /var/lib/shorewall to be world-readable. Shorewall now uses
|
||
umask 0177.</li>
|
||
<li>In log messages produced by logging a built-in action, the packet
|
||
disposition was displayed incorrectly.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
|
||
rejNotSyn:ULOG
|
||
all
|
||
all
|
||
tcp<br>
|
||
<br>
|
||
produces the log message:<br>
|
||
<br>
|
||
Feb
|
||
12 23:57:08 server Shorewall:rejNotSyn:ULOG: ...<br>
|
||
<br>
|
||
rather than<br>
|
||
<br>
|
||
Feb
|
||
12 23:57:08 server Shorewall:rejNotSyn:REJECT: ...<br>
|
||
<br>
|
||
</li>
|
||
<li>The comments regarding built-in actions in
|
||
/usr/share/shorewall/actions.std have been corrected.</li>
|
||
<li>The /etc/shorewall/policy file in the LRP package was missing the
|
||
'all->all' policy.<br>
|
||
</li>
|
||
</ol>
|
||
<span style="font-weight: bold;">02/05/2005
|
||
End of Support for Shorewall 1.4<br>
|
||
<br>
|
||
</span>Effective today, support for Shorewall 1.4 has been
|
||
discontinued. See the link at the top of this article for upgrade
|
||
information.<br>
|
||
<br>
|
||
<span style="font-weight: bold;">02/01/2005
|
||
Shorewall 2.0.16<br>
|
||
</span><br>
|
||
This release back-ports the DROPINVALID shorewall.conf option from
|
||
2.2.0.<br>
|
||
<ol>
|
||
<li>Recent 2.6 kernels include code that evaluates TCP packets based
|
||
on TCP Window analysis. This can cause packets that were previously
|
||
classified as NEW or ESTABLISHED to be classified as INVALID.<br>
|
||
<br>
|
||
The new kernel code can be disabled by including this command in your
|
||
/etc/shorewall/init file:<br>
|
||
<br>
|
||
echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal<br>
|
||
<br>
|
||
Additional kernel logging about INVALID TCP packets may be obtained by
|
||
adding this command to /etc/shorewall/init:<br>
|
||
<br>
|
||
echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid<br>
|
||
<br>
|
||
Traditionally, Shorewall has dropped INVALID TCP packets early. The new
|
||
DROPINVALID option allows INVALID packets to be passed through the
|
||
normal rules chains by setting DROPINVALID=No.<br>
|
||
<br>
|
||
If not specified or if specified as empty (e.g., DROPINVALID="") then
|
||
DROPINVALID=Yes is assumed.</li>
|
||
</ol>
|
||
<p><span style="font-weight: bold;">02/01/2005
|
||
Shorewall 2.2.0<br>
|
||
<br>
|
||
</span>New Features:<br>
|
||
</p>
|
||
<ol>
|
||
<li>ICMP packets that are in the INVALID state are now dropped by the
|
||
Reject and Drop default actions. They do so using the new 'dropInvalid'
|
||
builtin action. An 'allowInvalid' builtin action is also provided which
|
||
accepts packets in that state.</li>
|
||
<li>The /etc/shorewall/masq file INTERFACE column now allows
|
||
additional options.<br>
|
||
<br>
|
||
Normally MASQUERADE/SNAT rules are evaluated after one-to-one NAT rules
|
||
defined in the /etc/shorewall/nat file. If you preceed the interface
|
||
name with a plus sign ("+") then the rule will be evaluated before
|
||
one-to-one NAT.<br>
|
||
<br>
|
||
Examples:<br>
|
||
<br>
|
||
+eth0<br>
|
||
+eth1:192.0.2.32/27<br>
|
||
<br>
|
||
Also, the effect of ADD_SNAT_ALIASES=Yes can be negated for an entry by
|
||
following the interface name by ":" but no digit. <br>
|
||
<br>
|
||
Examples:<br>
|
||
<br>
|
||
eth0:<br>
|
||
eth1::192.0.2.32/27<br>
|
||
+eth3:<br>
|
||
<br>
|
||
</li>
|
||
<li>Similar to 2), the /etc/shorewall/nat file INTERFACE column now
|
||
allows you to override the setting of ADD_IP_ALIASES=Yes by following
|
||
the interface name with ":" but no digit.</li>
|
||
<li>All configuration files in the Shorewall distribution with the
|
||
exception of shorewall.conf are now empty. In particular, the
|
||
/etc/shorewall/zones, /etc/shorewall/policy and /etc/shorewall/tos
|
||
files now have no active entries. Hopefully this will stop the
|
||
questions on the support and development lists regarding why the
|
||
default entries are the way they are.</li>
|
||
<li>Previously, including a log level (and optionally a log tag) on a
|
||
rule that specified a user-defined (or Shorewall-defined) action would
|
||
log all traffic passed to the action. Beginning with this release,
|
||
specifying a log level in a rule that specifies a user- or
|
||
Shorewall-defined action will cause each rule in the action to be
|
||
logged with the specified level (and tag).<br>
|
||
<br>
|
||
The extent to which logging of action rules occurs is goverend by the
|
||
following:</li>
|
||
<ul>
|
||
<li>When you invoke an action and specify a log level, only those
|
||
rules in the action that have no log level will be changed to log at
|
||
the level specified at the action invocation.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
/etc/shorewall/action.foo:<br>
|
||
<br>
|
||
ACCEPT - -
|
||
tcp 22<br>
|
||
bar:info<br>
|
||
<br>
|
||
/etc/shorewall/rules:<br>
|
||
<br>
|
||
foo:debug fw net<br>
|
||
<br>
|
||
Logging in the invoked 'foo' action will be:<br>
|
||
<br>
|
||
ACCEPT:debug - -
|
||
tcp 22<br>
|
||
bar:info<br>
|
||
<br>
|
||
</li>
|
||
<li>If you follow the log level with "!" then logging will be at
|
||
that level for all rules recursively invoked by the action<br>
|
||
<br>
|
||
Example: /etc/shorewall/action.foo:<br>
|
||
<br>
|
||
<b>Update: </b>I've been
|
||
informed by Mandrake Development that this problem has been corrected
|
||
in Mandrake 10.0 Final (the problem still exists in the 10.0
|
||
Community release).<br>
|
||
ACCEPT - -
|
||
tcp 22<br>
|
||
bar:info<br>
|
||
<br>
|
||
/etc/shorewall/rules:<br>
|
||
<br>
|
||
foo:debug! fw net<br>
|
||
<br>
|
||
Logging in the invoke 'foo' action will be:<br>
|
||
<br>
|
||
ACCEPT:debug - -
|
||
tcp 22<br>
|
||
bar:debug!<br>
|
||
<br>
|
||
</li>
|
||
</ul>
|
||
</ol>
|
||
<div style="margin-left: 40px;">This change has an effect on extension
|
||
scripts used with user-defined actions. If you define an action 'acton'
|
||
and you have an /etc/shorewall/acton script then when that script is
|
||
invoked, the following three variables will be set for use by the
|
||
script:<br>
|
||
<br>
|
||
<div style="margin-left: 40px;">$CHAIN = the name of the chain where
|
||
your rules are to be placed. When logging is used on an action
|
||
invocation, Shorewall creates a chain with a slightly different name
|
||
from the action itself.<br>
|
||
$LEVEL = Log level. If empty, no logging was specified.<br>
|
||
$TAG = Log Tag.<br>
|
||
<br>
|
||
</div>
|
||
Example:<br>
|
||
<br>
|
||
/etc/shorewall/rules:<br>
|
||
<br>
|
||
acton:info:test<br>
|
||
<br>
|
||
Your /etc/shorewall/acton file will be run with:<br>
|
||
<br>
|
||
<div style="margin-left: 40px;">$CHAIN="%acton1<br>
|
||
$LEVEL="info"<br>
|
||
$TAG="test"<br>
|
||
</div>
|
||
</div>
|
||
<br>
|
||
<ol start="6">
|
||
<li>The /etc/shorewall/startup_disabled file is no longer created
|
||
when
|
||
Shorewall is first installed. Rather, the variable STARTUP_ENABLED is
|
||
set to 'No' in /etc/shorewall/shorewall.conf. In order to get Shorewall
|
||
to start, that variable's value must be set to 'Yes'. This change
|
||
accomplishes two things:</li>
|
||
<ul>
|
||
<li>It prevents Shorewall from being started prematurely by the
|
||
user's initialization scripts.</li>
|
||
<li>It causes /etc/shorewall/shorewall.conf to be modified so that
|
||
it won't be replaced by upgrades using RPM.<br>
|
||
<br>
|
||
</li>
|
||
</ul>
|
||
<li>Support has been added for the 2.6 Kernel IPSEC implementation.
|
||
To use this support, you must have installed the IPSEC policy match
|
||
patch and the four IPSEC/Netfilter patches from Patch-0-Matic-ng. The
|
||
policy match patch affects both your kernel and iptables. There are two
|
||
ways to specify that IPSEC is to be used when communicating with a set
|
||
of hosts; both methods involve the new /etc/shorewall/ipsec file:</li>
|
||
<ol style="list-style-type: lower-alpha;">
|
||
<li>If encrypted communication is used with all hosts in a zone,
|
||
then you can designate the zone as an "ipsec" zone by placing 'Yes" in
|
||
the IPSEC ONLY column in /etc/shorewall/ipsec:<br>
|
||
<br>
|
||
<span style="font-family: monospace;">#ZONE
|
||
IPSEC OPTIONS ...</span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;">#
|
||
ONLY</span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;">vpn
|
||
Yes</span><span
|
||
style="font-family: sans-serif;"></span><br>
|
||
<br>
|
||
The hosts in the zone (if any) must be specified in
|
||
/etc/shorewall/hosts but you do not need to specify the 'ipsec' option
|
||
on the entries in that file (see below). Dynamic zones involving IPSEC
|
||
must use that technique.<br>
|
||
<br>
|
||
Example:Under 2.4 Kernel FreeS/Wan:<br>
|
||
<br>
|
||
/etc/shorewall/zones:<br>
|
||
<br>
|
||
<span style="font-family: monospace;">net
|
||
Net The big bad Internet</span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;">vpn
|
||
VPN Remote Network</span><br>
|
||
<br>
|
||
/etc/shorewall/interfaces:<br>
|
||
<br>
|
||
<span style="font-family: monospace;">net
|
||
eth0 ...</span><br style="font-family: monospace;">
|
||
<span style="font-family: monospace;">vpn
|
||
ipsec0 ...</span><br>
|
||
<br>
|
||
Under 2.6 Kernel with this new support:<br>
|
||
<br>
|
||
/etc/shorewall/zones:<br>
|
||
<br>
|
||
<span style="font-family: monospace;">net
|
||
Net The big bad Internet</span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;">vpn
|
||
VPN Remote Network</span><br>
|
||
<br>
|
||
/etc/shorewall/interfaces:<br>
|
||
<br>
|
||
<span style="font-family: monospace;">net
|
||
eth0 ...</span><br>
|
||
<br>
|
||
/etc/shorewall/hosts:<br>
|
||
<br>
|
||
<span style="font-family: monospace;">vpn
|
||
eth0:0.0.0.0/0</span><br>
|
||
<br>
|
||
/etc/shorewall/ipsec<br>
|
||
<br>
|
||
<span style="font-family: monospace;">vpn Yes<br>
|
||
<br>
|
||
</span> </li>
|
||
<li>If only part of the hosts in a zone require encrypted
|
||
communication, you may use of the new 'ipsec' option in
|
||
/etc/shorewall/hosts to designate those hosts.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
Under 2.4 Kernel FreeS/Wan:<br>
|
||
<br>
|
||
/etc/shorewall/zones:<br>
|
||
<pre>net Net The big bad Internet<br>loc Local Extended local zone</pre>
|
||
/etc/shorewall/interfaces:<br>
|
||
<br>
|
||
<span style="font-family: monospace;">net
|
||
eth0 ...</span><br style="font-family: monospace;">
|
||
<span style="font-family: monospace;">loc
|
||
eth1 ...</span><br style="font-family: monospace;">
|
||
<span style="font-family: monospace;">loc
|
||
ipsec0 ...</span><br>
|
||
<br>
|
||
Under 2.6 Kernel with this new support:<br>
|
||
<br>
|
||
/etc/shorewall/zones:<br>
|
||
<br>
|
||
<span style="font-family: monospace;">net
|
||
Net The big bad Internet</span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;">vpn
|
||
VPN Remote Network</span><br>
|
||
<br>
|
||
/etc/shorewall/interfaces:<br>
|
||
<br>
|
||
<span style="font-family: monospace;">net
|
||
eth0 ...</span><br style="font-family: monospace;">
|
||
<span style="font-family: monospace;">loc
|
||
eth1 ...</span><br>
|
||
<br>
|
||
/etc/shorewall/hosts:<br>
|
||
<br>
|
||
<span style="font-family: monospace;">vpn
|
||
eth0:0.0.0.0/0 ipsec,...</span></li>
|
||
</ol>
|
||
</ol>
|
||
<div style="margin-left: 40px;">Regardless of which technique you
|
||
choose, you can specify additional SA options for the zone in the
|
||
/etc/shorewall/ipsec entry.<br>
|
||
<br>
|
||
The OPTIONS, IN OPTIONS and OUT OPTIONS columns specify the
|
||
input-output, input and output characteristics of the security
|
||
associations to be used to decrypt (input) or encrypt (output) traffic
|
||
to/from the zone.<br>
|
||
<br>
|
||
The available options are:<br>
|
||
</div>
|
||
<ul>
|
||
<ul>
|
||
<li>reqid[!]=<number> where <number> is specified using
|
||
setkey(8) using the 'unique:<number>' option for the SPD level.</li>
|
||
<li>spi[!]=<number> where <number> is the SPI of the
|
||
SA. Since different SAs are used to encrypt and decrypt traffic, this
|
||
option should only be listed in the IN OPTIONS and OUT OPTIONS columns.</li>
|
||
<li>proto[!]=ah|esp|ipcomp</li>
|
||
<li>mss=<number> (sets the MSS value in TCP SYN packets and
|
||
is not related to policy matching)</li>
|
||
<li>mode[!]=transport|tunnel</li>
|
||
<li>tunnel-src[!]=<address>[/<mask>] (only available
|
||
with mode=tunnel)</li>
|
||
<li>tunnel-dst[!]=<address>[/<mask>] (only available
|
||
with mode=tunnel). Because tunnel source and destination are dependent
|
||
on the direction of the traffic, these options should only appear in
|
||
the IN OPTIONS and OUT OPTIONS columns.</li>
|
||
<li>strict (if specified, packets must match all policies;
|
||
policies are delimited by 'next').</li>
|
||
<li>next (only available with strict)</li>
|
||
</ul>
|
||
</ul>
|
||
<div style="margin-left: 40px;">Examples:<br>
|
||
<br>
|
||
<span style="font-family: monospace;">#ZONE
|
||
IPSEC OPTIONS
|
||
|
||
IN
|
||
OUT</span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;">#
|
||
ONLY
|
||
|
||
OPTIONS OPTIONS</span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;">vpn
|
||
Yes mode=tunnel,proto=esp
|
||
spi=1000 spi=1001</span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;">loc
|
||
No reqid=44,mode=transport</span><br>
|
||
<br>
|
||
The /etc/shorewall/masq file has a new IPSEC column added. If you
|
||
specify Yes or yes in that column then the unencrypted packets will
|
||
have their source address changed. Otherwise, the unencrypted packets
|
||
will not have their source addresses changed. This column may also
|
||
contain a comma-separated list of the options specified above in which
|
||
case only those packets that will be encrypted by an SA matching the
|
||
given options will have their source address changed.<br>
|
||
</div>
|
||
<ol start="8">
|
||
<li>To improve interoperability, tunnels of type 'ipsec' no longer
|
||
enforce the use of source port 500 for ISAKMP and OpenVPN tunnels no
|
||
longer enforce use of the specified port as both the source and
|
||
destination ports.</li>
|
||
<li>A new 'allowBcast' builtin action has been added -- it silently
|
||
allows broadcasts and multicasts.</li>
|
||
<li>The -c option in /sbin/shorewall commands is now deprecated. The
|
||
commands where -c was previously allowed now permit you to specify a
|
||
configuration directory after the command:<br>
|
||
<br>
|
||
shorewall check [
|
||
<configuration-directory> ]<br>
|
||
shorewall restart [
|
||
<configuration-directory> ]<br>
|
||
shorewall start [
|
||
<configuration-directory> ]<br>
|
||
<br>
|
||
</li>
|
||
<li>Normally, when SNAT or MASQUERADE is applied to a tcp or udp
|
||
connection, Netfilter attempts to retain the source port number. If it
|
||
has to change to port number to avoid <source
|
||
address>,<source port> conflicts, it tries to do so within
|
||
port ranges ( < 512, 512-1023, and > 1023). You may now specify
|
||
an explicit range of source ports to be used by following the address
|
||
or address range (if any) in the ADDRESS column with ":" and a port
|
||
range in the format <low-port>-<high-port>. You must
|
||
specify either "tcp" or "udp" in the PROTO column.<br>
|
||
<br>
|
||
Examples 1 -- MASQUERADE with tcp source ports 4000-5000:<br>
|
||
<br>
|
||
<span style="font-family: monospace;"> #INTERFACE
|
||
SUBNET
|
||
ADDRESS PROTO</span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;">
|
||
eth0 192.168.1.0/24
|
||
:4000-5000 tcp</span><br
|
||
style="font-family: monospace;">
|
||
<br>
|
||
Example 2 -- SNAT with udp source ports 7000-8000:<br>
|
||
<br>
|
||
<span style="font-family: monospace;">#INTERFACE
|
||
SUBNET
|
||
ADDRESS
|
||
|
||
PROTO</span><br style="font-family: monospace;">
|
||
<span style="font-family: monospace;">
|
||
eth0
|
||
10.0.0.0/8
|
||
192.0.2.44:7000-8000 udp<br>
|
||
<br>
|
||
</span></li>
|
||
<li>You may now account by user/group ID for outbound traffic from
|
||
the firewall itself with entries in /etc/shorewall/accounting. Such
|
||
accounting rules must be placed in the OUTPUT chain. See the comments
|
||
at the top of /etc/shorewall/accounting for details.</li>
|
||
<li>Shorewall now verifies that your kernel and iptables have physdev
|
||
match support if BRIDGING=Yes in shorewall.conf.</li>
|
||
<li>Beginning with this release, if your kernel and iptables have
|
||
iprange match support (see the output from "shorewall check"), then
|
||
with the exception of the /etc/shorewall/netmap file, anywhere that a
|
||
network address may appear an IP address range of the form <low
|
||
address>-<high address> may also appear.</li>
|
||
<li>Support has been added for the iptables CLASSIFY target. That
|
||
target allows you to classify packets for traffic shaping directly
|
||
rather than indirectly through fwmark. Simply enter the
|
||
<major>:<minor> classification in the first column of
|
||
/etc/shorewall/tcrules:<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
<span style="font-family: monospace;">#MARK/
|
||
SOURCE
|
||
DEST PROTO PORT(S)</span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;">#CLASSIFY</span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;">1:30
|
||
-
|
||
eth0 tcp
|
||
25</span><br>
|
||
<br>
|
||
Note that when using this form of rule, it is acceptable to include the
|
||
name of an interface in the DEST column.<br>
|
||
<br>
|
||
Marking using the CLASSIFY target always occurs in the POSTROUTING
|
||
chain of the mangle table and is not affected by the setting of
|
||
MARK_IN_FORWARD_CHAIN in shorewall.conf.</li>
|
||
<li>During "shorewall start", IP addresses to be added as a
|
||
consequence of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes are quietly
|
||
deleted when /etc/shorewall/nat and /etc/shorewall/masq are processed
|
||
then they are re-added later. This is done to help ensure that the
|
||
addresses can be added with the specified labels but can have the
|
||
undesirable side effect of causing routes to be quietly deleted. A new
|
||
RETAIN_ALIASES option has been added to shorewall.conf; when this
|
||
option is set to Yes, existing addresses will not be deleted.
|
||
Regardless of the setting of RETAIN_ALIASES, addresses added during
|
||
"shorewall start" are still deleted at a subsequent "shorewall stop" or
|
||
"shorewall restart".</li>
|
||
<li>Users with a large black list (from /etc/shorewall/blacklist) may
|
||
want to set the new DELAYBLACKLISTLOAD option in shorewall.conf. When
|
||
DELAYBLACKLISTLOAD=Yes, Shorewall will enable new connections before
|
||
loading the blacklist rules. While this may allow connections from
|
||
blacklisted hosts to slip by during construction of the blacklist, it
|
||
can substantially reduce the time that all new connections are disabled
|
||
during "shorewall [re]start".</li>
|
||
<li>Using the default LOGFORMAT, chain names longer than 11
|
||
characters (such as in user-defined actions) may result in log prefix
|
||
truncation. A new shorewall.conf action LOGTAGONLY has been added
|
||
to deal with this problem. When LOGTAGONLY=Yes, logging rules that
|
||
specify a log tag will substitute the tag for the chain name in the log
|
||
prefix.<br>
|
||
<br>
|
||
Example -- file /etc/shorewall/action.thisisaverylogactionname:<br>
|
||
<br>
|
||
Rule:<br>
|
||
<br>
|
||
<span
|
||
style="font-family: monospace;">DROP:info:ftp
|
||
0.0.0.0/0 0.0.0.0/0
|
||
tcp 21</span><br>
|
||
<br>
|
||
Log prefix with LOGTAGONLY=No:<br>
|
||
<br>
|
||
<span style="font-family: monospace;">Shorewall:thisisaverylongacti</span><br>
|
||
<br>
|
||
Log prefix with LOGTAGONLY=Yes:<br>
|
||
<br>
|
||
<span
|
||
style="font-family: monospace;">Shorewall:ftp:DROP</span><br>
|
||
<br>
|
||
</li>
|
||
<li>Shorewall now resets the 'accept_source_route' flag for all
|
||
interfaces. If you wish to accept source routing on an interface, you
|
||
must specify the new 'sourceroute' interface option in
|
||
/etc/shorewall/interfaces.</li>
|
||
<li>The default Drop and Reject actions now invoke the new standard
|
||
action 'AllowICMPs'. This new action accepts critical ICMP types:<br>
|
||
<br>
|
||
Type 3 code 4 (fragmentation needed)<br>
|
||
Type 11 (TTL
|
||
exceeded)<br>
|
||
<br>
|
||
</li>
|
||
<li>Explicit control over the kernel's Martian logging is now
|
||
provided using the new 'logmartians' interface option. If you include
|
||
'logmartians' in the interface option list then logging of Martian
|
||
packets on will be enabled on the specified interface. If you wish to
|
||
globally enable martian logging, you can set LOG_MARTIANS=Yes in
|
||
shorewall.conf.</li>
|
||
<li>You may now cause Shorewall to use the '--set-mss' option of the
|
||
TCPMSS target. In other words, you can cause Shorewall to set the MSS
|
||
field of SYN packets passing through the firewall to the value you
|
||
specify. This feature extends the existing CLAMPMSS option in
|
||
/etc/shorewall/shorewall.conf by allowing that option to have a numeric
|
||
value as well as the values "Yes" and "No".<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
CLAMPMSS=1400<br>
|
||
<br>
|
||
</li>
|
||
<li>Shorewall now includes support for the ipp2p match facility. This
|
||
is a departure from my usual policy in that the ipp2p match facility is
|
||
included in Patch-O-Matic-NG and is unlikely to ever be included in the
|
||
kernel.org source tree. Questions about how to install the patch or how
|
||
to build your kernel and/or iptables should not be posted on the
|
||
Shorewall mailing lists.<br>
|
||
<br>
|
||
In the following files, the "PROTO" or "PROTOCOL" column may contain
|
||
"ipp2p":<br>
|
||
<br>
|
||
/etc/shorewall/rules<br>
|
||
/etc/shorewall/tcrules<br>
|
||
/etc/shorewall/accounting<br>
|
||
<br>
|
||
When the PROTO or PROTOCOL column contains "ipp2p" then the DEST
|
||
PORT(S) or PORT(S) column may contain a recognized ipp2p option; for a
|
||
list of the options and their meaning, at a root prompt:<br>
|
||
<br>
|
||
iptables -m ipp2p --help<br>
|
||
<br>
|
||
You must not include the leading "--" on the option; Shorewall will
|
||
supply those characters for you. If you do not include an option then
|
||
"ipp2p" is assumed (Shorewall will generate "-m ipp2p --ipp2p").</li>
|
||
<li>Shorewall now has support for the CONNMARK target from iptables.
|
||
See the /etc/shorewall/tcrules file for details.</li>
|
||
<li>A new debugging option LOGALLNEW has been added to
|
||
shorewall.conf. When set to a log level, this option causes Shorewall
|
||
to generaate a logging rule as the first rule in each builtin chain.<br>
|
||
<br>
|
||
- The table name is used as the chain name in the
|
||
log prefix.<br>
|
||
- The chain name is used as the target in the log
|
||
prefix.<br>
|
||
<br>
|
||
Example: Using the default LOGFORMAT, the log prefix for logging from
|
||
the nat table's PREROUTING chain is:<br>
|
||
<br>
|
||
<span style="font-family: monospace;">Shorewall:nat:PREROUTING</span><br>
|
||
<br>
|
||
IMPORTANT: There is no rate limiting on these logging rules so use
|
||
LOGALLNEW at your own risk; it may cause high CPU and disk utilization
|
||
and you may not be able to control your firewall after you enable this
|
||
option.<br>
|
||
<br>
|
||
DANGER: DO NOT USE THIS OPTION IF THE RESULTING LOG MESSAGES WILL BE
|
||
SENT TO ANOTHER SYSTEM.<br>
|
||
<br>
|
||
</li>
|
||
<li>The SUBNET column in /etc/shorewall/rfc1918 has been renamed
|
||
SUBNETS and it is now possible to specify a list of addresses in that
|
||
column.</li>
|
||
<li>The AllowNNTP action now also allows NNTP over SSL/TLS (NNTPS).</li>
|
||
<li>For consistency, the CLIENT PORT(S) column in the tcrules file
|
||
has been renamed SOURCE PORT(S).</li>
|
||
<li>The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is now
|
||
shown in the output of "shorewall status".</li>
|
||
<li>A new IPTABLES option has been added to shorewall.conf. IPTABLES
|
||
can be used to designate the iptables executable to be used by
|
||
Shorewall. If not specified, the iptables executable determined by the
|
||
PATH setting is used.</li>
|
||
<li>You can now use the "shorewall show zones" command to display the
|
||
current contents of the zones. This is particularly useful if you use
|
||
dynamic zones (DYNAMIC_ZONES=Yes in shorewall.conf).<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
<span style="font-family: monospace;">ursa:/etc/shorewall
|
||
# shorewall show zones</span><br style="font-family: monospace;">
|
||
<span style="font-family: monospace;">
|
||
Shorewall-2.2.0-Beta7 Zones at ursa - Sat Nov 27 11:18:25 PST 2004</span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;"> </span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;"> loc</span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;">
|
||
eth0:192.168.1.0/24</span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;">
|
||
eth1:1.2.3.4</span><br style="font-family: monospace;">
|
||
<span style="font-family: monospace;">
|
||
net </span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;">
|
||
eth0:0.0.0.0/0</span><br style="font-family: monospace;">
|
||
<span style="font-family: monospace;"> WiFi</span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;">
|
||
eth1:0.0.0.0/0</span><br style="font-family: monospace;">
|
||
<span style="font-family: monospace;"> sec</span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;">
|
||
eth1:0.0.0.0/0</span><br style="font-family: monospace;">
|
||
<span style="font-family: monospace;"> </span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;">
|
||
ursa:/etc/shorewall #</span><br>
|
||
<br>
|
||
</li>
|
||
<li>Variable expansion may now be used with the INCLUDE directive.<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
/etc/shorewall/params<br>
|
||
<br>
|
||
<span
|
||
style="font-family: monospace;">FILE=/etc/foo/bar</span><br>
|
||
<br>
|
||
Any other config file:<br>
|
||
<br>
|
||
<span
|
||
style="font-family: monospace;">INCLUDE $FILE</span><br>
|
||
<br>
|
||
</li>
|
||
<li>The output of "shorewall status" now includes the results of "ip
|
||
-stat link ls". This helps diagnose performance problems caused by link
|
||
errors.</li>
|
||
<li>Previously, when rate-limiting was specified in
|
||
/etc/shorewall/policy (LIMIT:BURST column), any traffic which exceeded
|
||
the specified rate was silently dropped. Now, if a log level is given
|
||
in the entry (LEVEL column) then drops are logged at that level at a
|
||
rate of 5/min with a burst of 5.</li>
|
||
<li>Recent 2.6 kernels include code that evaluates TCP packets based
|
||
on TCP Window analysis. This can cause packets that were previously
|
||
classified as NEW or ESTABLISHED to be classified as INVALID.<br>
|
||
<br>
|
||
The new kernel code can be disabled by including this command in your
|
||
/etc/shorewall/init file:<br>
|
||
<br>
|
||
<span style="font-family: monospace;">echo 1 >
|
||
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal</span><br>
|
||
<br>
|
||
Additional kernel logging about INVALID TCP packets may be obtained by
|
||
adding this command to /etc/shorewall/init:<br>
|
||
<br>
|
||
<span style="font-family: monospace;">echo 1 >
|
||
/proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid</span><br>
|
||
<br>
|
||
Traditionally, Shorewall has dropped INVALID TCP packets early. The new
|
||
DROPINVALID option allows INVALID packets to be passed through the
|
||
normal rules chains by setting DROPINVALID=No.<br>
|
||
<br>
|
||
If not specified or if specified as empty (e.g., DROPINVALID="") then
|
||
DROPINVALID=Yes is assumed.<br>
|
||
<br>
|
||
</li>
|
||
<li>The "shorewall add" and "shorewall delete" commands now accept a
|
||
list of hosts to add or delete.<br>
|
||
<br>
|
||
Examples:<br>
|
||
<br>
|
||
<span style="font-family: monospace;"> shorewall add
|
||
eth1:1.2.3.4 eth1:2.3.4.5 z12</span><br style="font-family: monospace;">
|
||
<span style="font-family: monospace;"> shorewall delete
|
||
eth1:1.2.3.4 eth1:2.3.4.5 z12</span><br>
|
||
<br>
|
||
The above commands may also be written:<br>
|
||
<br>
|
||
<span style="font-family: monospace;">shorewall add
|
||
eth1:1.2.3.4,2.3.4.5 z12</span><br style="font-family: monospace;">
|
||
<span style="font-family: monospace;"> shorewall delete
|
||
eth1:1.2.3.4,2.3.4.5 z12</span><br>
|
||
<br>
|
||
</li>
|
||
<li>TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel
|
||
type. OpenVPN entries in /etc/shorewall/tunnels have this format:<br>
|
||
<br>
|
||
<span style="font-family: monospace;">openvpn[:{tcp|udp}][:<port>]
|
||
<zone> <gateway></span><br>
|
||
<br>
|
||
Examples:<br>
|
||
<br>
|
||
<span style="font-family: monospace;">openvpn:tcp
|
||
net
|
||
1.2.3.4 # TCP tunnel on port 1194</span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;">
|
||
openvpn:3344 net
|
||
1.2.3.4 # UDP on port 3344</span><br
|
||
style="font-family: monospace;">
|
||
<span style="font-family: monospace;">
|
||
openvpn:tcp:4455 net
|
||
1.2.3.4 # TCP on port 4455</span><br>
|
||
<br>
|
||
</li>
|
||
<li>A new 'ipsecvpn' script is included in the tarball and in the
|
||
RPM. The RPM installs the file in the Documentation directory
|
||
(/usr/share/doc/packages/shorewall-2.2.0-0RC1).<br>
|
||
<br>
|
||
This script is intended for use on Roadwarrior laptops for establishing
|
||
an IPSEC SA to/from remote networks. The script has some limitations:</li>
|
||
</ol>
|
||
<ul>
|
||
<ul>
|
||
<li>Only one instance of the script may be used at a time.</li>
|
||
<li>Only the first SPD accessed will be instantiated at the remote
|
||
gateway. So while the script creates SPDs to/from the remote gateway
|
||
and each network listed in the NETWORKS setting at the front of the
|
||
script, only one of these may be used at a time.</li>
|
||
</ul>
|
||
</ul>
|
||
<ol start="39">
|
||
<li>The output of "shorewall status" now lists the loaded netfilter
|
||
kernel modules.</li>
|
||
<li>The range of UDP ports opened by the AllowTrcrt action has been
|
||
increased to 33434:33524.</li>
|
||
<li>The IANA has recently registered port 1194 for use by OpenVPN. In
|
||
previous versions of Shorewall (and OpenVPN), the default port was 5000
|
||
but has been changed to 1194 to conform to the new OpenVPN default.</li>
|
||
</ol>
|
||
<p><span style="font-weight: bold;">01/17/2005 -
|
||
Shorewall 2.2.0 RC5<br>
|
||
<br>
|
||
</span>Problems Corrected:<br>
|
||
</p>
|
||
<ol>
|
||
<li>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.<br>
|
||
</li>
|
||
<li>Using some lightweight shells, valid entries in
|
||
/etc/shorewall/ecn produce startup errors.</li>
|
||
</ol>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>A new AllowInvalid standard built-in action has been added. This
|
||
action accepts packets that are in the INVALID connection-tracking
|
||
state.</li>
|
||
</ol>
|
||
<span style="font-weight: bold;"><a name="Mirrors"></a>01/16/2005 - New
|
||
Shorewall Mirrors<br>
|
||
<br>
|
||
</span>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>
|
||
<span style="font-weight: bold;"><br>
|
||
<a name="2_0_15"></a>01/12/2005 -
|
||
Shorewall 2.0.15<br>
|
||
</span><br>
|
||
Problems Corrected:<br>
|
||
<ol>
|
||
<li>The range of ports opened by the AllowTrcrt action has been
|
||
expanded to 33434:33524 to allow for a maximum of 30 hops.</li>
|
||
<li>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.<br>
|
||
</li>
|
||
</ol>
|
||
<span style="font-weight: bold;"><a name="2_2_0_RC4"></a>01/06/2005 -
|
||
Shorewall 2.2.0 RC4<br>
|
||
</span><br>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>A listing of loaded iptables kernel modules is now included in
|
||
the output of "shorewall status".<br>
|
||
</li>
|
||
</ol>
|
||
Problems Corrected.<br>
|
||
<ol>
|
||
<li>Several problems associated with processing the IPSEC colummn in
|
||
/etc/shorewall/masq have been corrected.<br>
|
||
</li>
|
||
</ol>
|
||
<span style="font-weight: bold;"><a name="2_0_14"></a>01/03/2005 -
|
||
Shorewall 2.0.14<br>
|
||
</span><br>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>Previously, when rate-limiting was specified in
|
||
/etc/shorewall/policy (LIMIT:BURST column), any traffic which exceeded
|
||
the specified rate was silently dropped. Now, if a log level is given
|
||
in the entry (LEVEL column) then drops are logged at that level at a
|
||
rate of 5/min with a burst of 5.<br>
|
||
</li>
|
||
</ol>
|
||
Problems Corrected:<br>
|
||
<ol>
|
||
<li>A typo in the /etc/shorewall/interfaces file has been fixed.</li>
|
||
<li>"bad variable" error messages occurring during "shorewall stop"
|
||
and "shorewall clear" have been eliminated.</li>
|
||
<li>A misleading typo in /etc/shorewall/tunnels has been corrected.
|
||
The TYPE column for an IPIP tunnel should contain "ipip" rather than
|
||
"ip".<br>
|
||
</li>
|
||
</ol>
|
||
<span style="font-weight: bold;"><a name="MandrakeRPMS"></a>12/31/2004
|
||
- Mandrake-specific RPMs available<br>
|
||
<br>
|
||
</span>Jack Coates has generously volunteered to provide Shorewall RPMs
|
||
for use under Mandrake. You can download Jack's RPMs from <a
|
||
target="_top" href="http://www.monkeynoodle.org/tmp/">http://www.monkeynoodle.org/tmp/</a><br>
|
||
<br>
|
||
<span style="font-weight: bold;"><a name="Redhat_Fedora"></a>12/31/2004
|
||
- Redhat/Fedora-specific RPMs available<br>
|
||
</span><br>
|
||
Simon Matter has graciously volunteered to provide RPMs taylored for
|
||
Redhat and Fedora. You can download Simon's RPMs from <a target="_top"
|
||
href="http://www.invoca.ch/pub/packages/shorewall/">http://www.invoca.ch/pub/packages/shorewall/</a><br>
|
||
<br>
|
||
Thanks, Simon!<br>
|
||
<br>
|
||
<span style="font-weight: bold;"><a name="2_2_0_RC3"></a>12/30/2004 -
|
||
Shorewall 2.2.0 RC3<br>
|
||
</span><br>
|
||
Problems Corrected:<br>
|
||
<ol>
|
||
<li>The following error message could appear during "shorewall stop"
|
||
or "shorewall clear":<br>
|
||
|
||
<br>
|
||
|
||
local: lo:: bad variable name<br>
|
||
<br>
|
||
</li>
|
||
<li>The rate limiting example in /etc/shorewall/rules has been
|
||
changed to use the RATE LIMIT column.</li>
|
||
<li>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.</li>
|
||
<li>A misleading typo in /etc/shorewall/tunnels has been corrected.<br>
|
||
</li>
|
||
</ol>
|
||
<span style="font-weight: bold;"></span>
|
||
<p><br>
|
||
</p>
|
||
<p><span style="font-weight: bold;">12/24/2004 -
|
||
Shorewall 2.2.0 RC2<br>
|
||
<br>
|
||
</span>New Features:<br>
|
||
</p>
|
||
<ol>
|
||
<li>By popular demand, the default port for Open VPN tunnels is now
|
||
1194 (the IANA-reserved port number for Open VPN).</li>
|
||
</ol>
|
||
<span style="font-weight: bold;"><a name="2_2_0_RC1"></a>12/19/2004 -
|
||
Shorewall 2.2.0 RC1<br>
|
||
<br>
|
||
</span>Problems Corrected:<br>
|
||
<ol>
|
||
<li>The syntax of the add and delete command has been clarified in
|
||
the help summary produced by /sbin/shorewall.</li>
|
||
</ol>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>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:<br>
|
||
<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>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.<br>
|
||
</li>
|
||
</ol>
|
||
<span style="font-weight: bold;"><a name="2_2_0_Beta8"></a>12/11/2004 -
|
||
Shorewall 2.2.0 Beta 8<br>
|
||
<br>
|
||
</span>Problems Corrected:<br>
|
||
<ol>
|
||
<li>A typo in the /etc/shorewall/interfaces file has been corrected.</li>
|
||
<li>Previously, the "add" and "delete" commands were generating
|
||
incorrect policy matches when policy match support was available.</li>
|
||
</ol>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>Recent 2.6 kernels include code that evaluates TCP packets based
|
||
on TCP Window analysis. This can cause packets that were previously
|
||
classified as NEW or ESTABLISHED to be classified as INVALID.<br>
|
||
<br>
|
||
The new kernel code can be disabled by including this command in your
|
||
/etc/shorewall/init file:<br>
|
||
<br>
|
||
echo 1 >
|
||
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal<br>
|
||
<br>
|
||
Additional kernel logging about INVALID TCP packets may be obtained by
|
||
adding this command to /etc/shorewall/init:<br>
|
||
<br>
|
||
echo 1 >
|
||
/proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid<br>
|
||
<br>
|
||
Traditionally, Shorewall has dropped INVALID TCP packets early. The new
|
||
DROPINVALID option allows INVALID packets to be passed through the
|
||
normal rules chains by setting DROPINVALID=No.<br>
|
||
<br>
|
||
If not specified or if specified as empty (e.g., DROPINVALID="") then
|
||
DROPINVALID=Yes is assumed.<br>
|
||
<br>
|
||
</li>
|
||
<li>The "shorewall add" and "shorewall delete" commands now accept a
|
||
list of hosts to add or delete.<br>
|
||
<br>
|
||
Examples:<br>
|
||
<br>
|
||
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>
|
||
<br>
|
||
</li>
|
||
</ol>
|
||
<span style="font-weight: bold;"><a name="2_2_0_Beta7"></a>12/04/2004 -
|
||
Shorewall 2.2.0 Beta 7<br>
|
||
</span><br>
|
||
Problems Corrected:<br>
|
||
<ol>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
</ol>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>You can now use the "shorewall show zones" command to display the
|
||
current contents of the zones. This is particularly useful if you use
|
||
dynamic zones (DYNAMIC_ZONES=Yes in shorewall.conf).<br>
|
||
<br>
|
||
Example:<br>
|
||
<br>
|
||
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 #<br>
|
||
<br>
|
||
</li>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>The output of "shorewall status" now includes the results of "ip
|
||
-stat link ls". This helps diagnose performance problems caused by link
|
||
errors.</li>
|
||
<li>Previously, when rate-limiting was specified in
|
||
/etc/shorewall/policy (LIMIT:BURST column), any traffic which exceeded
|
||
the specified rate was silently dropped. Now, if a log<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.<br>
|
||
</li>
|
||
</ol>
|
||
<span style="font-weight: bold;"><a name="2_0_13"></a>12/02/2004 -
|
||
Shorewall 2.0.13<br>
|
||
<br>
|
||
</span>Problems Corrected:<br>
|
||
<ol>
|
||
<li>A typo in /usr/share/shorewall/firewall caused the "shorewall
|
||
add" to issue an error message:<br>
|
||
<pre class="programlisting">/usr/share/shorewall/firewall: line 1: match_destination_hosts: command not found</pre>
|
||
</li>
|
||
</ol>
|
||
<span style="font-weight: bold;"><a name="2_0_12"></a>12/01/2004 -
|
||
Shorewall 2.0.12<br>
|
||
</span><br>
|
||
Problems Corrected:<br>
|
||
<ol>
|
||
<li>A typo in shorewall.conf (NETNOTSYN) has been corrected.</li>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.</li>
|
||
</ol>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>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<br>
|
||
</li>
|
||
</ol>
|
||
<span style="font-weight: bold;"><a name="2_2_0_Beta6"></a>11/26/2004 -
|
||
Shorewall 2.2.0 Beta 6<br>
|
||
<br>
|
||
</span>Beta 5 was more or less DOA. Here's Beta 6.<br>
|
||
<br>
|
||
Problems Corrected:<br>
|
||
<ol>
|
||
<li>Fixed a number of problems associated with not having an IPTABLES
|
||
value assigned in shorewall.conf</li>
|
||
<li>Corrected a 'duplicate chain' error on "shorewall add" when the
|
||
'mss' option is present in /etc/shorewall/ipsec.<br>
|
||
</li>
|
||
</ol>
|
||
<span style="font-weight: bold;"><a name="2_2_0_Beta5"></a>11/26/2004 -
|
||
Shorewall 2.2.0 Beta 5<br>
|
||
</span><br>
|
||
Problems corrected:<br>
|
||
<ol>
|
||
<li>A typo in shorewall.conf (NETNOTSYN) has been corrected.</li>
|
||
</ol>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>For consistency, the CLIENT PORT(S) column in the tcrules file
|
||
has been renamed SOURCE PORT(S).</li>
|
||
<li>The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is now
|
||
shown in the output of "shorewall status".</li>
|
||
<li>A new IPTABLES option has been added to shorewall.conf. IPTABLES
|
||
can be used to designate the iptables executable to be used by
|
||
Shorewall. If not specified, the iptables executable determined by the
|
||
PATH setting is used.<br>
|
||
</li>
|
||
</ol>
|
||
<span style="font-weight: bold;"><a name="2_0_11"></a>11/23/2004 -
|
||
Shorewall 2.0.11<br>
|
||
</span><br>
|
||
Problems corrected:<br>
|
||
<ol>
|
||
<li>The INSTALL file now include special instructions for Slackware
|
||
users.</li>
|
||
<li>The bogons file has been updated.</li>
|
||
<li>Service names are replaced by port numbers in /etc/shorewall/tos.</li>
|
||
<li>A typo in the install.sh file that caused an error during a new
|
||
install has been corrected.</li>
|
||
</ol>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>The AllowNNTP action now allows NNTP over SSL/TLS (NTTPS).<br>
|
||
</li>
|
||
</ol>
|
||
<span style="font-weight: bold;"><a name="2_2_0_Beta4"></a>11/19/2004 -
|
||
Shorewall 2.2.0 Beta 4<br>
|
||
</span><br>
|
||
Problems Corrected:<br>
|
||
<ol>
|
||
<li>A cut and paste error resulted in some nonsense in the
|
||
description of the IPSEC column in /etc/shorewall/masq.</li>
|
||
<li>A typo in /etc/shorewall/rules has been corrected.</li>
|
||
<li>The bogons file has been updated.</li>
|
||
<li>The "shorewall add" command previously reported success but did
|
||
nothing -- now it works.</li>
|
||
</ol>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>The AllowNNTP action now allows NNTP over SSL/TLS (NNTPS).<br>
|
||
</li>
|
||
</ol>
|
||
<span style="font-weight: bold;"><a name="2_2_0_Beta3"></a>11/09/2004 -
|
||
Shorewall 2.2.0 Beta 3<br>
|
||
</span><br>
|
||
Problems Corrected:<br>
|
||
<ol>
|
||
<li>Missing '#' in the rfc1918 file has been corrected.</li>
|
||
<li>The INSTALL file now includes special instructions for Slackware
|
||
users.</li>
|
||
</ol>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>In CLASSIFY rules (/etc/shorewall/tcrules), an interface name may
|
||
now appear in the DEST column as in:<br>
|
||
<pre> #MARK/ SOURCE DEST PROTO PORT(S)<br> #CLASSIFY<br> 1:30 - eth0 tcp 25</pre>
|
||
</li>
|
||
</ol>
|
||
<span style="font-weight: bold;"><a name="2_2_0_Beta2"></a>11/02/2004 -
|
||
Shorewall 2.2.0 Beta 2<br>
|
||
<br>
|
||
</span>Problems Corrected:<br>
|
||
<ol>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>The AllowNTP standard action now allows outgoing responses to
|
||
broadcasts.</li>
|
||
<li>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.<span style="font-weight: bold;"></span></li>
|
||
</ol>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>The SUBNET column in /etc/shorewall/rfc1918 has been renamed
|
||
SUBNETS and it is now possible to specify a list of addresses in that
|
||
column.<br>
|
||
</li>
|
||
</ol>
|
||
<span style="font-weight: bold;"><a name="2_0_10"></a>10/25/2004 -
|
||
Shorewall 2.0.10<br>
|
||
</span><br>
|
||
Problems Corrected:<br>
|
||
<ol>
|
||
<li>The GATEWAY column was previously ignored in 'pptpserver' entries
|
||
in /etc/shorewall/tunnels.</li>
|
||
<li>When log rule numbers are included in the LOGFORMAT, duplicate
|
||
rule numbers could previously be generated.</li>
|
||
<li>The /etc/shorewall/tcrules file now includes a note to the effect
|
||
that rule evaluation continues after a match.</li>
|
||
<li>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.<br>
|
||
</li>
|
||
</ol>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>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<br>
|
||
</li>
|
||
</ol>
|
||
<br>
|
||
<span style="font-weight: bold;"><a name="2_2_0_Beta1"></a>10/24/2004 -
|
||
Shorewall 2.2.0 Beta1<br>
|
||
<br>
|
||
</span>The first beta in the 2.2 series is now available. Download
|
||
location is:<br>
|
||
<br>
|
||
<div style="margin-left: 40px;"><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 target="_top"
|
||
href="ftp://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1">ftp://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1</a><br>
|
||
</div>
|
||
<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:<br>
|
||
</p>
|
||
<ol>
|
||
<li>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.</li>
|
||
<li>Support for the 2.6 Kernel's native IPSEC implementation is now
|
||
available.</li>
|
||
<li>Support for ipp2p is included.</li>
|
||
<li>Support for the iptables CONNMARK facility is now included in
|
||
Shorewall.</li>
|
||
<li>A new LOGALLNEW option facilitates problem analysis.</li>
|
||
<li>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 <span style="font-weight: bold;">shorewall [re]start</span>.</li>
|
||
<li>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.</li>
|
||
<li>Accepting of source routing and martian logging may now be
|
||
enabled/disabled on each interface.</li>
|
||
<li>Shorewall now supports the CLASSIFY iptable target.</li>
|
||
</ol>
|
||
<p><span style="font-weight: bold;"><a name="2_0_9"></a>9/23/2004 -
|
||
Shorewall 2.0.9<br>
|
||
</span><br>
|
||
Problems Corrected:<br>
|
||
</p>
|
||
<ol>
|
||
<li>Previously, an empty PROTO column or a value of "all" in that
|
||
column would cause errors when processing the /etc/shorewall/tcrules
|
||
file.</li>
|
||
</ol>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>The "shorewall status" command now includes the output of "brctl
|
||
show" if the bridge tools are installed.<br>
|
||
</li>
|
||
</ol>
|
||
<p><a name="SupportChange"><b>9/20/2004 – Change in Shorewall Support</b></a></p>
|
||
<p style="">Friends,</p>
|
||
<p style="">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 style="">I will continue to be active on the
|
||
development list and will continue to develop Shorewall if at all
|
||
possible.</p>
|
||
<p style="">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 style="">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="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<br>
|
||
</b></p>
|
||
<p>Fixes one problem:<br>
|
||
</p>
|
||
<ol>
|
||
<li>Versions 2.0.2d and 2.0.2e fail to load kernel modules unless
|
||
MODULE_SUFFIX is set in shorewall.conf<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>6/2/2004 - Shorewall 2.0.2e<br>
|
||
</b></p>
|
||
<p>One problem corrected:<br>
|
||
</p>
|
||
<ol>
|
||
<li>LOG rules within an action generate two Netfilter logging rules.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>5/28/2004 - Shorewall 2.0.2d<br>
|
||
</b><br>
|
||
One problem corrected:<br>
|
||
</p>
|
||
<ol>
|
||
<li>Shorewall was checking capabilities before loading kernel
|
||
modules. Consequently, if kernel module autoloading was disabled, the
|
||
capabilities were mis-detected.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>5/21/2004 - Shorewall 2.0.2c</b></p>
|
||
One problem corrected:<br>
|
||
<ol>
|
||
<li> 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.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>5/18/2004 - Shorewall 2.0.2b</b><b> </b></p>
|
||
<p>Corrects two problems:</p>
|
||
<ol>
|
||
<li>Specifying a null common action in /etc/shorewall/actions
|
||
(e.g., :REJECT) results in a startup error.<br>
|
||
<br>
|
||
</li>
|
||
<li>If /var/lib/shorewall does not exist, shorewall start fails.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>5/15/2004 - Shorewall 2.0.2a</b><b> </b><br>
|
||
</p>
|
||
<p>Corrects two problems:<br>
|
||
</p>
|
||
<ol>
|
||
<li>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]* <br>
|
||
<br>
|
||
</li>
|
||
<li>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" </li>
|
||
</ol>
|
||
<p><b>5/13/2004 - Shorewall 2.0.2</b><b> </b></p>
|
||
<p>Problems Corrected since 2.0.1<br>
|
||
</p>
|
||
<ol>
|
||
<li>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.</li>
|
||
<li>A meaningless warning message out of the proxyarp file
|
||
processing has been eliminated.</li>
|
||
<li>The "shorewall delete" command now correctly removes all
|
||
dynamic rules pertaining to the host(s) being deleted. Thanks to Stefan
|
||
Engel for this correction.</li>
|
||
</ol>
|
||
Issues when migrating from Shorewall 2.0.1 to Shorewall 2.0.2:<br>
|
||
<ol>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.</li>
|
||
</ol>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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".<br>
|
||
<br>
|
||
</li>
|
||
<li>An updated bogons file is included in this release.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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).<br>
|
||
<br>
|
||
</li>
|
||
<li>Shorewall now uses 'modprobe' to load kernel modules if
|
||
that utility is available in the PATH; otherwise, 'insmod' is used.<br>
|
||
<br>
|
||
</li>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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).<br>
|
||
<br>
|
||
</li>
|
||
<li>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.</li>
|
||
</ol>
|
||
<p><b>4/17/2004 - Presentation at
|
||
LinuxFest NW</b><b><br>
|
||
</b></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><b> 4/5/2004 - Shorewall 2.0.1</b><br>
|
||
</p>
|
||
Problems Corrected since 2.0.0<br>
|
||
<br>
|
||
<ol>
|
||
<li>Using actions in the manner recommended in the
|
||
documentation results in a Warning that the rule is a policy.</li>
|
||
<li>When a zone on a single interface is defined using
|
||
/etc/shorewall/hosts, superfluous rules are generated in the
|
||
<zone>_frwd chain.</li>
|
||
<li>Thanks to Sean Mathews, a long-standing problem with Proxy
|
||
ARP and IPSEC has been corrected. Thanks Sean!!!</li>
|
||
<li>The "shorewall show log" and "shorewall logwatch" commands
|
||
incorrectly displayed type 3 ICMP packets.<br>
|
||
</li>
|
||
</ol>
|
||
Issues when migrating from Shorewall 2.0.0 to Shorewall 2.0.1:<br>
|
||
<br>
|
||
<ol>
|
||
<li>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.</li>
|
||
</ol>
|
||
New Features:<br>
|
||
<br>
|
||
<ol>
|
||
<li>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><br>
|
||
<br>
|
||
</li>
|
||
<li>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><br>
|
||
<br>
|
||
</li>
|
||
<li>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> ]<br>
|
||
<br>
|
||
</li>
|
||
<li>Shorewall now traps two common zone definition errors:<br>
|
||
<ul>
|
||
<li>Including the firewall zone in a /etc/shorewall/hosts
|
||
record.</li>
|
||
<li>Defining an interface for a zone in both
|
||
/etc/shorewall/interfaces and /etc/shorewall/hosts.<br>
|
||
<br>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>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</li>
|
||
</ol>
|
||
<p><b>3/14/2004 - Shorewall 2.0.0b </b></p>
|
||
Corrects two problems:<br>
|
||
<ol>
|
||
<li>Thanks to Sean Mathews, the long-standing problem with
|
||
Proxy ARP and IPSEC has been eliminated!</li>
|
||
<li>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.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>3/14/2004 - Shorewall 2.0.0a </b><b></b></p>
|
||
<p>Corrects one problem:<br>
|
||
</p>
|
||
<ul>
|
||
<li>Rules of the form:<br>
|
||
<br>
|
||
<action>
|
||
zone1 zone2<br>
|
||
<br>
|
||
generated a warning stating that the rule was a policy.<br>
|
||
</li>
|
||
</ul>
|
||
<p><b>3/14/2004 - Shorewall 2.0.0 </b><b><br>
|
||
</b></p>
|
||
<p>Dedicated to Agnes Van Slyke Eastep: March 14, 1910 - February
|
||
23, 2004<br>
|
||
</p>
|
||
<p>Problems Corrected since 1.4.10<br>
|
||
</p>
|
||
<ol>
|
||
<li>A blank USER/GROUP column in /etc/shorewall/tcrules no
|
||
longer causes a [re]start error.</li>
|
||
<li>The 'fgrep' utility is no longer required (caused startup
|
||
problems on LEAF/Bering).</li>
|
||
<li>The "shorewall add" command no longer inserts rules before
|
||
checking of the blacklist.</li>
|
||
<li>The 'detectnets' and 'routeback' options may now be used
|
||
together with the intended effect.</li>
|
||
<li>The following syntax previously produced an error:<br>
|
||
<br>
|
||
DNAT z1!z2,z3 z4...<br>
|
||
</li>
|
||
</ol>
|
||
<p>Problems Corrected since RC2<br>
|
||
<br>
|
||
</p>
|
||
<ol>
|
||
<li>CONTINUE rules now work again.</li>
|
||
<li>A comment in the rules file has been corrected.<br>
|
||
</li>
|
||
</ol>
|
||
<p>Issues when migrating from Shorewall 1.4.x to Shorewall 2.0.0:<br>
|
||
</p>
|
||
<ol>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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>
|
||
<br>
|
||
</li>
|
||
<li>It is no longer possible to specify rate limiting in the
|
||
ACTION column of /etc/shorewall/rules -- you must use the RATE LIMIT
|
||
column.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.</li>
|
||
</ol>
|
||
<p>New Features:<br>
|
||
</p>
|
||
<ol>
|
||
<li>The INCLUDE directive now allows absolute file names.</li>
|
||
<li>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).</li>
|
||
<li>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.</li>
|
||
<li>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".</li>
|
||
<li>"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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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).</li>
|
||
<li>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".</li>
|
||
<li>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.</li>
|
||
</ol>
|
||
<p><b>2/15/2004 - Shorewall 1.4.10c </b></p>
|
||
<p>Corrects one problem:<br>
|
||
</p>
|
||
Entries in /etc/shorewall/tcrules with an empty USER/GROUP column would
|
||
cause a startup error.
|
||
<p><b>2/12/2004 - Shorewall 1.4.10b </b><b></b></p>
|
||
<p>Corrects one problem:<br>
|
||
</p>
|
||
<ul>
|
||
<li>In the /etc/shorewall/masq entry “<span class="quote">eth0:!10.1.1.150
|
||
0.0.0.0/0!10.1.0.0/16 10.1.2.16</span>”, the
|
||
“<span class="quote">!10.1.0.0/16</span>” is ignored.</li>
|
||
</ul>
|
||
<p><b>2/8/2004 - Shorewall 1.4.10a </b><b></b></p>
|
||
<p>Corrects two problems:<br>
|
||
</p>
|
||
<ul>
|
||
<li>A problem which can cause [re]start to fail inexplicably
|
||
while processing /etc/shorewall/masq.</li>
|
||
<li>Interfaces using the Atheros WiFi card to use the 'maclist'
|
||
option.</li>
|
||
</ul>
|
||
<p><b>1/30/2004 - Shorewall 1.4.10</b></p>
|
||
<p>Problems Corrected since version 1.4.9</p>
|
||
<ol>
|
||
<li>The column descriptions in the action.template file did not
|
||
match the column headings. That has been corrected.</li>
|
||
<li>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.</li>
|
||
<li value="3">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.</li>
|
||
<li>Shorewall now tried to avoid sending an ICMP response to
|
||
broadcasts and smurfs.</li>
|
||
<li>Specifying "-" or "all" in the PROTO column of an action no
|
||
longer causes a startup error. </li>
|
||
</ol>
|
||
Migragion Issues:<br>
|
||
<br>
|
||
None.<br>
|
||
<br>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>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!
|
||
</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><br>
|
||
</p>
|
||
<p>Problems Corrected since version 1.4.9</p>
|
||
<ol>
|
||
<li>The column descriptions in the action.template file did not
|
||
match the column headings. That has been corrected.</li>
|
||
<li>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.</li>
|
||
<li value="3">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.</li>
|
||
<li>Shorewall now tried to avoid sending an ICMP response to
|
||
broadcasts and smurfs.<br>
|
||
</li>
|
||
</ol>
|
||
Migragion Issues:<br>
|
||
<br>
|
||
None.<br>
|
||
<br>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>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!
|
||
</li>
|
||
</ol>
|
||
<p><b>1/24/2004 - Shorewall 1.4.10 RC2</b><b> </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><br>
|
||
</p>
|
||
<p>Problems Corrected since version 1.4.9</p>
|
||
<ol>
|
||
<li>The column descriptions in the action.template file did not
|
||
match the column headings. That has been corrected.</li>
|
||
<li>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.</li>
|
||
</ol>
|
||
Migragion Issues:<br>
|
||
<br>
|
||
None.<br>
|
||
<br>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>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! </li>
|
||
</ol>
|
||
<p><b>1/22/2004 - Shorewall 1.4.10 RC1</b><b> </b></p>
|
||
<p>Problems Corrected since version 1.4.9</p>
|
||
<ol>
|
||
<li>The column descriptions in the action.template file did not match
|
||
the column headings. That has been corrected.</li>
|
||
<li>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.</li>
|
||
</ol>
|
||
Migragion Issues:<br>
|
||
<br>
|
||
None.<br>
|
||
<br>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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 <br>
|
||
</li>
|
||
</ol>
|
||
<p><b>1/13/2004 - Shorewall 1.4.9</b><b><br>
|
||
</b></p>
|
||
<p>Problems Corrected since version 1.4.8:<br>
|
||
</p>
|
||
<ol>
|
||
<li>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.</li>
|
||
<li>The description of NEWNOTSYN in shorewall.conf has been
|
||
reworded for clarity.</li>
|
||
<li>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.</li>
|
||
<li>DNAT rules that also specified SNAT now work reliably.
|
||
Previously,
|
||
there were cases where the SNAT specification was effectively ignored.</li>
|
||
</ol>
|
||
<p>Migration Issues:<br>
|
||
<br>
|
||
None.<br>
|
||
<br>
|
||
New Features:<br>
|
||
</p>
|
||
<ol>
|
||
<li>The documentation has been completely rebased to Docbook
|
||
XML. The
|
||
documentation is now released as separate HTML and XML packages.</li>
|
||
<li>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'.</li>
|
||
<li>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'.</li>
|
||
<li>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"</li>
|
||
<li>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</li>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
</ol>
|
||
<p><b>12/29/2003 - Shorewall 1.4.9 Beta 2</b><b> </b></p>
|
||
<div style="margin-left: 40px;"><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>
|
||
</div>
|
||
<p>Problems Corrected since version 1.4.8:</p>
|
||
<ol>
|
||
<li>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.</li>
|
||
<li>The description of NEWNOTSYN in shorewall.conf has been
|
||
reworded for clarity.</li>
|
||
<li>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.</li>
|
||
<li>DNAT rules that also specified SNAT now work reliably.
|
||
Previously, there were cases where the SNAT specification was
|
||
effectively ignored.<br>
|
||
</li>
|
||
</ol>
|
||
<p>Migration Issues:</p>
|
||
<p> None.<br>
|
||
<br>
|
||
New Features: </p>
|
||
<ol>
|
||
<li>The documentation has been completely rebased to Docbook
|
||
XML. The documentation is now released as separate HTML and XML
|
||
packages.<br>
|
||
</li>
|
||
<li>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'.</li>
|
||
<li>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'.</li>
|
||
<li>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"</li>
|
||
<li>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<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>12/28/2003 - www.shorewall.net/ftp.shorewall.net Back
|
||
On-line</b><b> <br>
|
||
</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><b> </b></p>
|
||
<div style="margin-left: 40px;"><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>
|
||
</div>
|
||
<p>Problems Corrected since version 1.4.8:</p>
|
||
<ol>
|
||
<li>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.</li>
|
||
<li>The description of NEWNOTSYN in shorewall.conf has been
|
||
reworded for clarity.</li>
|
||
<li>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.</li>
|
||
</ol>
|
||
<p>Migration Issues:</p>
|
||
<p> None.<br>
|
||
<br>
|
||
New Features: </p>
|
||
<ol>
|
||
<li>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'.</li>
|
||
<li>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'.</li>
|
||
<li>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"</li>
|
||
<li>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<br>
|
||
</li>
|
||
<li>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.</li>
|
||
</ol>
|
||
<p><b>12/03/2003 - Support Torch Passed</b></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><b>11/07/2003 - Shorewall 1.4.8<br>
|
||
<br>
|
||
</b>Problems Corrected since version 1.4.7:<br>
|
||
</p>
|
||
<ol>
|
||
<li>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.</li>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>Handling of the LOGUNCLEAN option in shorewall.conf has been
|
||
corrected.</li>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>An incorrect comment concerning Debian's use of the SUBSYSLOCK
|
||
option has been removed from shorewall.conf.</li>
|
||
<li>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.</li>
|
||
<li>If MAC verification was enabled on an interface with a /32
|
||
address and a broadcast address then an error would occur during
|
||
startup.</li>
|
||
<li>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.</li>
|
||
<li>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.<br>
|
||
</li>
|
||
</ol>
|
||
Migration Issues:<br>
|
||
<ol>
|
||
<li>The definition of the ROUTE_FILTER option in shorewall.conf has
|
||
changed as described in item 8) above.<br>
|
||
</li>
|
||
</ol>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>Chain names used in the /etc/shorewall/accounting file may now
|
||
begin with a digit ([0-9]) and may contain embedded dashes
|
||
("-").</li>
|
||
</ol>
|
||
<p><b>10/30/2003 - Shorewall 1.4.8 RC1<br>
|
||
</b></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.<br>
|
||
<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:<br>
|
||
</p>
|
||
<ol>
|
||
<li>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.</li>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>Handling of the LOGUNCLEAN option in shorewall.conf has been
|
||
corrected.</li>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>An incorrect comment concerning Debian's use of the SYBSYSLOCK
|
||
option has been removed from shorewall.conf.</li>
|
||
<li>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.</li>
|
||
</ol>
|
||
Migration Issues:<br>
|
||
<ol>
|
||
<li>The definition of the ROUTE_FILTER option in shorewall.conf has
|
||
changed as described in item 8) above.<br>
|
||
</li>
|
||
</ol>
|
||
New Features:<br>
|
||
<ol>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>Chain names used in the /etc/shorewall/accounting file may now
|
||
begin with a digit ([0-9]) and may contain embedded dashes
|
||
("-").<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>10/26/2003 - Shorewall 1.4.7a and 1.4.7b win brown paper bag
|
||
awards</b> <b><img
|
||
style="border: 0px solid ; width: 50px; height: 80px;"
|
||
src="images/j0233056.gif" title="" alt="" align="middle">Shorewall
|
||
1.4.7c released.</b></p>
|
||
<ol>
|
||
<li>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.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>10/24/2003 - Shorewall 1.4.7b</b></p>
|
||
This is a bugfx rollup of the 1.4.7a fixes plus:<br>
|
||
<ol>
|
||
<li>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.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>10/21/2003 - Shorewall 1.4.7a<br>
|
||
</b></p>
|
||
<p>This is a bugfix rollup of the following problem
|
||
corrections:<br>
|
||
</p>
|
||
<ol>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>Handling of the LOGUNCLEAN option in shorewall.conf has been
|
||
corrected.</li>
|
||
<li>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.</li>
|
||
<li>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.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>10/06/2003 - Shorewall 1.4.7</b><b><br>
|
||
</b></p>
|
||
<b>Problems Corrected since version 1.4.6 (Those in bold font were
|
||
corrected since 1.4.7 RC2).</b><br>
|
||
<ol>
|
||
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable
|
||
was being tested before it was set.</li>
|
||
<li>Corrected handling of MAC addresses in the SOURCE column of the
|
||
tcrules file. Previously, these addresses resulted in an invalid
|
||
iptables command.</li>
|
||
<li>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.</li>
|
||
<li>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</li>
|
||
<li>Interface-specific dynamic blacklisting chains are now
|
||
displayed by "shorewall monitor" on the "Dynamic Chains" page
|
||
(previously named "Dynamic Chain").</li>
|
||
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.</li>
|
||
<li value="7">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.</li>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>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).</li>
|
||
<li>Shorewall will now load module files that are formed from the
|
||
module name by appending ".o.gz".</li>
|
||
<li>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.</li>
|
||
<li>The rfc1918 file has been updated to reflect recent
|
||
allocations.</li>
|
||
<li>The documentation of the USER SET column in the rules file has
|
||
been corrected.</li>
|
||
<li>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><br>
|
||
<br>
|
||
</li>
|
||
<li>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.</li>
|
||
<li>The order of processing the various options has been changed
|
||
such that blacklist entries now take precedence over the 'dhcp' <span
|
||
style="font-weight: bold;">i</span>nterface setting.</li>
|
||
<li>The log message generated from the 'logunclean' interface
|
||
option has been changed to reflect a disposition of LOG rather than
|
||
DROP.</li>
|
||
<li><span style="font-weight: bold;">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:<br>
|
||
<br>
|
||
</span></li>
|
||
<li><span style="font-weight: bold;">The /etc/shorewall/masq file
|
||
has had the spurious "/" character at the front removed.<br>
|
||
<br>
|
||
</span></li>
|
||
</ol>
|
||
<b>Migration Issues:</b><br>
|
||
<ol>
|
||
<li>Shorewall IP Traffic Accounting has changed since snapshot
|
||
20030813 -- see the <a href="Accounting.html">Accounting Page</a>
|
||
for details.</li>
|
||
<li>The Uset Set capability introduced in SnapShot 20030821 has
|
||
changed -- see the <a href="UserSets.html">User Set page</a> for
|
||
details.</li>
|
||
<li>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.<br>
|
||
</li>
|
||
</ol>
|
||
<b>New Features:</b><br>
|
||
<ol>
|
||
<li>Thanks to Steve Herber, the 'help' command can now give
|
||
command-specific help (e.g., shorewall help <command>).</li>
|
||
<li>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!!!</li>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>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. \</li>
|
||
<li>An /etc/shorewall/accounting file has been added to allow for
|
||
traffic accounting. See the <a href="Accounting.html">accounting
|
||
documentation</a> for a description of
|
||
this facility.</li>
|
||
<li>Bridge interfaces (br[0-9]) may now be used in
|
||
/etc/shorewall/maclist.</li>
|
||
<li>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>
|
||
<span style="font-weight: bold;">Warning:</span> 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.<br>
|
||
</li>
|
||
<li>Multiple chains may now be displayed in one "shorewall show"
|
||
command (e.g., shorewall show INPUT FORWARD OUTPUT).</li>
|
||
<li>Output rules (those with $FW as the SOURCE) may now be limited
|
||
to a set of local users and/or groups. See <a href="UserSets.html">http://shorewall.net/UserSets.html</a>
|
||
for
|
||
details.</li>
|
||
</ol>
|
||
<p><b>10/02/2003 - Shorewall 1.4.7 RC2</b><b><br>
|
||
</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><br>
|
||
</b> <b></b></p>
|
||
<b>Problems Corrected since version 1.4.6 (Those in bold font were
|
||
corrected since 1.4.7 RC 1).</b><br>
|
||
<ol>
|
||
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable
|
||
was being tested before it was set.</li>
|
||
<li>Corrected handling of MAC addresses in the SOURCE column of the
|
||
tcrules file. Previously, these addresses resulted in an invalid
|
||
iptables command.</li>
|
||
<li>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.</li>
|
||
<li>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</li>
|
||
<li>Interface-specific dynamic blacklisting chains are now
|
||
displayed by "shorewall monitor" on the "Dynamic Chains" page
|
||
(previously named "Dynamic Chain").</li>
|
||
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.</li>
|
||
<li value="7">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.</li>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>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).</li>
|
||
<li>Shorewall will now load module files that are formed from the
|
||
module name by appending ".o.gz".</li>
|
||
<li>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.</li>
|
||
<li>The rfc1918 file has been updated to reflect recent
|
||
allocations.</li>
|
||
<li><span style="font-weight: bold;">The documentation of the USER
|
||
SET column in the rules file has been corrected.</span></li>
|
||
<li><span style="font-weight: bold;">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><br>
|
||
<br>
|
||
</span></li>
|
||
<li><span style="font-weight: bold;">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.</span></li>
|
||
<li><span style="font-weight: bold;">The order of processing the
|
||
various options has been changed such that blacklist entries now
|
||
take precedence over the 'dhcp' interface setting.</span></li>
|
||
<li><span style="font-weight: bold;">The log message generated from
|
||
the 'logunclean' interface option has been changed to reflect a
|
||
disposition of LOG rather than DROP.</span></li>
|
||
<li><span style="font-weight: bold;">The RFC1918 file has been
|
||
updated to reflect recent IANA allocations.<br>
|
||
</span></li>
|
||
</ol>
|
||
<b>Migration Issues:</b><br>
|
||
<ol>
|
||
<li>Shorewall IP Traffic Accounting has changed since snapshot
|
||
20030813 -- see the <a href="Accounting.html">Accounting Page</a>
|
||
for details.</li>
|
||
<li>The Uset Set capability introduced in SnapShot 20030821 has
|
||
changed -- see the <a href="UserSets.html">User Set page</a> for
|
||
details.</li>
|
||
<li>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.<br>
|
||
</li>
|
||
</ol>
|
||
<b>New Features:</b><br>
|
||
<ol>
|
||
<li>Thanks to Steve Herber, the 'help' command can now give
|
||
command-specific help (e.g., shorewall help <command>).</li>
|
||
<li>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!!!</li>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>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. \</li>
|
||
<li>An /etc/shorewall/accounting file has been added to allow for
|
||
traffic accounting. See the <a href="Accounting.html">accounting
|
||
documentation</a> for a description of
|
||
this facility.</li>
|
||
<li>Bridge interfaces (br[0-9]) may now be used in
|
||
/etc/shorewall/maclist.</li>
|
||
<li>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>
|
||
<span style="font-weight: bold;">Warning:</span> 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.<br>
|
||
</li>
|
||
<li>Multiple chains may now be displayed in one "shorewall show"
|
||
command (e.g., shorewall show INPUT FORWARD OUTPUT).</li>
|
||
<li>Output rules (those with $FW as the SOURCE) may now be limited
|
||
to a set of local users and/or groups. See <a href="UserSets.html">http://shorewall.net/UserSets.html</a>
|
||
for
|
||
details.</li>
|
||
</ol>
|
||
<p><b>9/18/2003 - Shorewall 1.4.7 RC 1</b><b><br>
|
||
</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><br>
|
||
</b> <b></b></p>
|
||
<b>Problems Corrected since version 1.4.6 (Those in bold font were
|
||
corrected since 1.4.7 Beta 1).</b><br>
|
||
<ol>
|
||
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable
|
||
was being tested before it was set.</li>
|
||
<li>Corrected handling of MAC addresses in the SOURCE column of the
|
||
tcrules file. Previously, these addresses resulted in an invalid
|
||
iptables command.</li>
|
||
<li>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.</li>
|
||
<li>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</li>
|
||
<li>Interface-specific dynamic blacklisting chains are now
|
||
displayed by "shorewall monitor" on the "Dynamic Chains" page
|
||
(previously named "Dynamic Chain").</li>
|
||
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.</li>
|
||
<li value="7">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.</li>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>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).</li>
|
||
<li>Shorewall will now load module files that are formed from the
|
||
module name by appending ".o.gz".</li>
|
||
<li style="font-weight: bold;">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.</li>
|
||
<li><span style="font-weight: bold;">The rfc1918 file has been
|
||
updated to reflect recent allocations.</span><br>
|
||
</li>
|
||
</ol>
|
||
<b>Migration Issues:</b><br>
|
||
<ol>
|
||
<li>Shorewall IP Traffic Accounting has changed since snapshot
|
||
20030813 -- see the <a href="Accounting.html">Accounting Page</a>
|
||
for details.</li>
|
||
<li>The Uset Set capability introduced in SnapShot 20030821 has
|
||
changed -- see the <a href="UserSets.html">User Set page</a> for
|
||
details.</li>
|
||
<li>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.<br>
|
||
</li>
|
||
</ol>
|
||
<b>New Features:</b><br>
|
||
<ol>
|
||
<li>Thanks to Steve Herber, the 'help' command can now give
|
||
command-specific help (e.g., shorewall help <command>).</li>
|
||
<li>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!!!</li>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>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. \</li>
|
||
<li>An /etc/shorewall/accounting file has been added to allow for
|
||
traffic accounting. See the <a href="Accounting.html">accounting
|
||
documentation</a> for a description of
|
||
this facility.</li>
|
||
<li>Bridge interfaces (br[0-9]) may now be used in
|
||
/etc/shorewall/maclist.</li>
|
||
<li>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>
|
||
<span style="font-weight: bold;">Warning:</span> 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.<br>
|
||
</li>
|
||
<li>Multiple chains may now be displayed in one "shorewall show"
|
||
command (e.g., shorewall show INPUT FORWARD OUTPUT).</li>
|
||
<li>Output rules (those with $FW as the SOURCE) may now be limited
|
||
to a set of local users and/or groups. See <a href="UserSets.html">http://shorewall.net/UserSets.html</a>
|
||
for
|
||
details.</li>
|
||
</ol>
|
||
<p><b>9/15/2003 - Shorewall 1.4.7 Beta 2</b> <b><br>
|
||
</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><br>
|
||
</b> <b></b></p>
|
||
<b>Problems Corrected since version 1.4.6 (Those in bold font were
|
||
corrected since 1.4.7 Beta 1).</b><br>
|
||
<ol>
|
||
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable
|
||
was being tested before it was set.</li>
|
||
<li>Corrected handling of MAC addresses in the SOURCE column of the
|
||
tcrules file. Previously, these addresses resulted in an invalid
|
||
iptables command.</li>
|
||
<li>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.</li>
|
||
<li>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</li>
|
||
<li>Interface-specific dynamic blacklisting chains are now
|
||
displayed by "shorewall monitor" on the "Dynamic Chains" page
|
||
(previously named "Dynamic Chain").</li>
|
||
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.</li>
|
||
<li value="7" style="font-weight: bold;">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.</li>
|
||
<li style="font-weight: bold;">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<br>
|
||
<br>
|
||
</li>
|
||
<li style="font-weight: bold;">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).</li>
|
||
<li><span style="font-weight: bold;">Shorewall will now load module
|
||
files that are formed from the module name by appending
|
||
".o.gz".</span><br>
|
||
</li>
|
||
</ol>
|
||
<b>Migration Issues:</b><br>
|
||
<ol>
|
||
<li>Shorewall IP Traffic Accounting has changed since snapshot
|
||
20030813 -- see the <a href="Accounting.html">Accounting Page</a>
|
||
for details.</li>
|
||
<li>The Uset Set capability introduced in SnapShot 20030821 has
|
||
changed -- see the <a href="UserSets.html">User Set page</a> for
|
||
details.</li>
|
||
<li>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.<br>
|
||
</li>
|
||
</ol>
|
||
<b>New Features:</b><br>
|
||
<ol>
|
||
<li>Thanks to Steve Herber, the 'help' command can now give
|
||
command-specific help (e.g., shorewall help <command>).</li>
|
||
<li>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!!!</li>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>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. \</li>
|
||
<li>An /etc/shorewall/accounting file has been added to allow for
|
||
traffic accounting. See the <a href="Accounting.html">accounting
|
||
documentation</a> for a description of
|
||
this facility.</li>
|
||
<li>Bridge interfaces (br[0-9]) may now be used in
|
||
/etc/shorewall/maclist.</li>
|
||
<li>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>
|
||
<span style="font-weight: bold;">Warning:</span> 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.<br>
|
||
</li>
|
||
<li>Multiple chains may now be displayed in one "shorewall show"
|
||
command (e.g., shorewall show INPUT FORWARD OUTPUT).</li>
|
||
<li>Output rules (those with $FW as the SOURCE) may now be limited
|
||
to a set of local users and/or groups. See <a href="UserSets.html">http://shorewall.net/UserSets.html</a>
|
||
for
|
||
details.</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"><font size="3">http://www.solutionsfirst.com.au</font></a>),
|
||
there is now a
|
||
Shorewall Mirror in Australia:</p>
|
||
<div style="margin-left: 40px;"><a href="http://www.shorewall.com.au"
|
||
target="_top"><font size="3">http://www.shorewall.com.au</font></a><br>
|
||
<a href="ftp://ftp.shorewall.com.au"><font size="3">ftp://ftp.shorewall.com.au</font></a></div>
|
||
<p><b>8/26/2003 - French Version of the Shorewall Setup
|
||
Guide </b></p>
|
||
Thanks to Fabien <font size="3">Demassieux, there is now a <a
|
||
href="shorewall_setup_guide_fr.htm">French translation of the
|
||
Shorewall
|
||
Setup Guide</a>. Merci Beacoup, Fabien!</font>
|
||
<p><b>8/25/2003 - Shorewall 1.4.7 Beta 1</b> <b><br>
|
||
</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><br>
|
||
</b> <b></b></p>
|
||
<b>Problems Corrected since version 1.4.6</b><br>
|
||
<ol>
|
||
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable
|
||
was being tested before it was set.</li>
|
||
<li>Corrected handling of MAC addresses in the SOURCE column of the
|
||
tcrules file. Previously, these addresses resulted in an invalid
|
||
iptables command.</li>
|
||
<li>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.</li>
|
||
<li>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</li>
|
||
<li>Interface-specific dynamic blacklisting chains are now
|
||
displayed by "shorewall monitor" on the "Dynamic Chains" page
|
||
(previously named "Dynamic Chain").</li>
|
||
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.<br>
|
||
<br>
|
||
</li>
|
||
</ol>
|
||
<b>Migration Issues:</b><br>
|
||
<ol>
|
||
<li>Shorewall IP Traffic Accounting has changed since snapshot
|
||
20030813 -- see the <a href="Accounting.html">Accounting Page</a>
|
||
for details.</li>
|
||
<li>The Uset Set capability introduced in SnapShot 20030821 has
|
||
changed -- see the <a href="UserSets.html">User Set page</a> for
|
||
details.</li>
|
||
<li>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.<br>
|
||
</li>
|
||
</ol>
|
||
<b>New Features:</b><br>
|
||
<ol>
|
||
<li>Thanks to Steve Herber, the 'help' command can now give
|
||
command-specific help (e.g., shorewall help <command>).</li>
|
||
<li>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!!!</li>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>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. \</li>
|
||
<li>An /etc/shorewall/accounting file has been added to allow for
|
||
traffic accounting. See the <a href="Accounting.html">accounting
|
||
documentation</a> for a description of
|
||
this facility.</li>
|
||
<li>Bridge interfaces (br[0-9]) may now be used in
|
||
/etc/shorewall/maclist.</li>
|
||
<li>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>
|
||
<span style="font-weight: bold;">Warning:</span> 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.<br>
|
||
</li>
|
||
<li>Multiple chains may now be displayed in one "shorewall show"
|
||
command (e.g., shorewall show INPUT FORWARD OUTPUT).</li>
|
||
<li>Output rules (those with $FW as the SOURCE) may now be limited
|
||
to a set of local users and/or groups. See <a href="UserSets.html">http://shorewall.net/UserSets.html</a>
|
||
for
|
||
details.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>8/23/2003 - Snapshot 1.4.6_2003082</b><span
|
||
style="font-weight: bold;">3</span> <b></b></p>
|
||
<blockquote>
|
||
<p><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></p>
|
||
</blockquote>
|
||
<b>Problems Corrected since version 1.4.6</b><br>
|
||
<ol>
|
||
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable
|
||
was being tested before it was set.</li>
|
||
<li>Corrected handling of MAC addresses in the SOURCE column of the
|
||
tcrules file. Previously, these addresses resulted in an invalid
|
||
iptables command.</li>
|
||
<li>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.</li>
|
||
<li>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</li>
|
||
<li>Interface-specific dynamic blacklisting chains are now
|
||
displayed by "shorewall monitor" on the "Dynamic Chains" page
|
||
(previously named "Dynamic Chain").</li>
|
||
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.<br>
|
||
<br>
|
||
</li>
|
||
</ol>
|
||
<b>Migration Issues:</b><br>
|
||
<ol>
|
||
<li>Once you have installed this version of Shorewall, you must
|
||
restart Shorewall before you may use the 'drop', 'reject', 'allow'
|
||
or 'save' commands.</li>
|
||
<li>To maintain strict compatibility with previous versions,
|
||
current uses of "shorewall drop" and "shorewall reject" should be
|
||
replaced with "shorewall dropall" and "shorewall rejectall"</li>
|
||
<li>Shorewall IP Traffic Accounting has changed since snapshot
|
||
20030813 -- see the <a href="Accounting.html">Accounting Page</a>
|
||
for details.</li>
|
||
<li>The Uset Set capability introduced in SnapShot 20030821 has
|
||
changed -- see the <a href="UserSets.html">User Set page</a> for
|
||
details.</li>
|
||
</ol>
|
||
<b>New Features:</b><br>
|
||
<ol>
|
||
<li>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.</li>
|
||
<li>Thanks to Steve Herber, the 'help' command can now give
|
||
command-specific help (e.g., shorewall help <command>).</li>
|
||
<li>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!!!</li>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>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. \</li>
|
||
<li>An /etc/shorewall/accounting file has been added to allow for
|
||
traffic accounting. See the <a href="Accounting.html">accounting
|
||
documentation</a> for a description of
|
||
this facility.</li>
|
||
<li>Bridge interfaces (br[0-9]) may now be used in
|
||
/etc/shorewall/maclist.</li>
|
||
<li>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>
|
||
<span style="font-weight: bold;">Warning:</span> 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.<br>
|
||
</li>
|
||
<li>Multiple chains may now be displayed in one "shorewall show"
|
||
command (e.g., shorewall show INPUT FORWARD OUTPUT).</li>
|
||
<li>Output rules (those with $FW as the SOURCE) may now be limited
|
||
to a set of local users and/or groups. See <a href="UserSets.html">http://shorewall.net/UserSets.html</a>
|
||
for
|
||
details.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>8/13/2003 - Snapshot 1.4.6_20030813</b><b> </b>
|
||
<b></b></p>
|
||
<blockquote>
|
||
<p><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></p>
|
||
</blockquote>
|
||
<b>Problems Corrected since version 1.4.6</b><br>
|
||
<ol>
|
||
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable
|
||
was being tested before it was set.</li>
|
||
<li>Corrected handling of MAC addresses in the SOURCE column of the
|
||
tcrules file. Previously, these addresses resulted in an invalid
|
||
iptables command.</li>
|
||
<li>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.</li>
|
||
<li>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</li>
|
||
<li> Interface-specific dynamic blacklisting chains are now
|
||
displayed by "shorewall monitor" on the "Dynamic Chains" page
|
||
(previously named "Dynamic Chain").<br>
|
||
<br>
|
||
</li>
|
||
</ol>
|
||
<b>Migration Issues:</b><br>
|
||
<ol>
|
||
<li>Once you have installed this version of Shorewall, you must
|
||
restart Shorewall before you may use the 'drop', 'reject', 'allow'
|
||
or 'save' commands.</li>
|
||
<li>To maintain strict compatibility with previous versions,
|
||
current uses of "shorewall drop" and "shorewall reject" should be
|
||
replaced with "shorewall dropall" and "shorewall rejectall"</li>
|
||
</ol>
|
||
<b>New Features:</b><br>
|
||
<ol>
|
||
<li>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.</li>
|
||
<li>Thanks to Steve Herber, the 'help' command can now give
|
||
command-specific help (e.g., shorewall help <command>).</li>
|
||
<li>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!!!</li>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>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. \</li>
|
||
<li>An /etc/shorewall/accounting file has been added to allow for
|
||
traffic accounting. See the <a href="Accounting.html">accounting
|
||
documentation</a> for a description of
|
||
this facility.</li>
|
||
<li>Bridge interfaces (br[0-9]) may now be used in
|
||
/etc/shorewall/maclist.</li>
|
||
<li>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>
|
||
<span style="font-weight: bold;">Warning:</span> 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.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>8/9/2003 - Snapshot 1.4.6_20030809</b><b> </b>
|
||
<b></b></p>
|
||
<blockquote>
|
||
<p><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></p>
|
||
</blockquote>
|
||
<b>Problems Corrected since version 1.4.6</b><br>
|
||
<ol>
|
||
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable
|
||
was being tested before it was set.</li>
|
||
<li>Corrected handling of MAC addresses in the SOURCE column of the
|
||
tcrules file. Previously, these addresses resulted in an invalid
|
||
iptables command.</li>
|
||
<li>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.</li>
|
||
<li>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<br>
|
||
</li>
|
||
</ol>
|
||
<b>Migration Issues:</b><br>
|
||
<ol>
|
||
<li>Once you have installed this version of Shorewall, you must
|
||
restart Shorewall before you may use the 'drop', 'reject', 'allow'
|
||
or 'save' commands.</li>
|
||
<li>To maintain strict compatibility with previous versions,
|
||
current uses of "shorewall drop" and "shorewall reject" should be
|
||
replaced with "shorewall dropall" and "shorewall rejectall"</li>
|
||
</ol>
|
||
<b>New Features:</b><br>
|
||
<ol>
|
||
<li>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.</li>
|
||
<li>Thanks to Steve Herber, the 'help' command can now give
|
||
command-specific help (e.g., shorewall help <command>).</li>
|
||
<li>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!!!</li>
|
||
<li>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.</li>
|
||
<li>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.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>8/5/2003 - Shorewall-1.4.6b</b><b> <br>
|
||
</b></p>
|
||
<b>Problems Corrected since version 1.4.6:</b><br>
|
||
<ol>
|
||
<li>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.</li>
|
||
<li>Corrected handling of MAC addresses in the SOURCE column of the
|
||
tcrules file. Previously, these addresses resulted in an invalid
|
||
iptables command.</li>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
</ol>
|
||
<p><b>8/5/2003 - Shorewall-1.4.6b</b> <b><br>
|
||
</b></p>
|
||
<b>Problems Corrected since version 1.4.6:</b><br>
|
||
<ol>
|
||
<li>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.</li>
|
||
<li>Corrected handling of MAC addresses in the SOURCE column of the
|
||
tcrules file. Previously, these addresses resulted in an invalid
|
||
iptables command.</li>
|
||
<li>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.</li>
|
||
<li>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.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>7/31/2003 - Snapshot 1.4.6_20030731</b> <b></b></p>
|
||
<blockquote>
|
||
<p><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></p>
|
||
</blockquote>
|
||
<p><b>Problems Corrected since version 1.4.6:</b><br>
|
||
</p>
|
||
<ol>
|
||
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable
|
||
was being tested before it was set.</li>
|
||
<li>Corrected handling of MAC addresses in the SOURCE column of the
|
||
tcrules file. Previously, these addresses resulted in an invalid
|
||
iptables command.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>Migration Issues:</b><br>
|
||
</p>
|
||
<ol>
|
||
<li>Once you have installed this version of Shorewall, you must
|
||
restart Shorewall before you may use the 'drop', 'reject', 'allow'
|
||
or 'save' commands.</li>
|
||
<li>To maintain strict compatibility with previous versions,
|
||
current uses of "shorewall drop" and "shorewall reject" should be
|
||
replaced with "shorewall dropall" and "shorewall rejectall"</li>
|
||
</ol>
|
||
<p><b>New Features:</b><br>
|
||
</p>
|
||
<ol>
|
||
<li>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.</li>
|
||
<li>Thanks to Steve Herber, the 'help' command can now give
|
||
command-specific help (e.g., shorewall help <command>).</li>
|
||
<li>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!!!</li>
|
||
</ol>
|
||
<p><b>7/27/2003 - Snapshot 1.4.6_20030727</b> <b></b></p>
|
||
<blockquote>
|
||
<p><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></p>
|
||
</blockquote>
|
||
<b>Problems Corrected since version 1.4.6</b><br>
|
||
<ol>
|
||
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable
|
||
was being tested before it was set.</li>
|
||
<li>Corrected handling of MAC addresses in the SOURCE column of the
|
||
tcrules file. Previously, these addresses resulted in an invalid
|
||
iptables command.<br>
|
||
</li>
|
||
</ol>
|
||
<b>Migration Issues:</b><br>
|
||
<ol>
|
||
<li>Once you have installed this version of Shorewall, you must
|
||
restart Shorewall before you may use the 'drop', 'reject', 'allow'
|
||
or 'save' commands.</li>
|
||
<li>To maintain strict compatibility with previous versions,
|
||
current uses of "shorewall drop" and "shorewall reject" should be
|
||
replaced with "shorewall dropall" and "shorewall rejectall"</li>
|
||
</ol>
|
||
<b>New Features:</b><br>
|
||
<ol>
|
||
<li>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.</li>
|
||
<li>Thanks to Steve Herber, the 'help' command can now give
|
||
command-specific help (e.g., shorewall help <command>).<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>7/26/2003 - Snapshot 1.4.6_20030726</b></p>
|
||
<blockquote>
|
||
<p><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></p>
|
||
</blockquote>
|
||
<p><b>Problems Corrected since version 1.4.6:</b><br>
|
||
</p>
|
||
<ol>
|
||
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable
|
||
was being tested before it was set.</li>
|
||
<li>Corrected handling of MAC addresses in the SOURCE column of the
|
||
tcrules file. Previously, these addresses resulted in an invalid
|
||
iptables command.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>Migration Issues:</b><br>
|
||
</p>
|
||
<ol>
|
||
<li>Once you have installed this version of Shorewall, you must
|
||
restart Shorewall before you may use the 'drop', 'reject', 'allow'
|
||
or 'save' commands.</li>
|
||
<li>To maintain strict compatibility with previous versions,
|
||
current uses of "shorewall drop" and "shorewall reject" should be
|
||
replaced with "shorewall dropall" and "shorewall rejectall"</li>
|
||
</ol>
|
||
<p><b>New Features:</b><br>
|
||
</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><b>7/22/2003 - Shorewall-1.4.6a</b> <b><br>
|
||
</b></p>
|
||
<b>Problems Corrected:</b><br>
|
||
<ol>
|
||
<li>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.</li>
|
||
</ol>
|
||
<p><b>7/20/2003 - Shorewall-1.4.6</b> <b><br>
|
||
</b></p>
|
||
<p><b>Problems Corrected:</b><br>
|
||
</p>
|
||
<ol>
|
||
<li>A problem seen on RH7.3 systems where Shorewall encountered
|
||
start errors when started using the "service" mechanism has been
|
||
worked around.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>Corrected a problem in Beta 1 where DNS names containing a "-"
|
||
were mis-handled when they appeared in the DEST column of a
|
||
rule.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>The message "Adding rules for DHCP" is now suppressed if there
|
||
are no DHCP rules to add.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>Migration Issues:</b><br>
|
||
</p>
|
||
<ol>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>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).<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>New Features:</b><br>
|
||
</p>
|
||
<ol>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>Shorewall can now add IP addresses to subnets other than the
|
||
first one on an interface.<br>
|
||
<br>
|
||
</li>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>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...<br>
|
||
<br>
|
||
</li>
|
||
<li>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:</li>
|
||
<li
|
||
style="list-style-type: none; list-style-position: outside; list-style-image: none;">
|
||
<ul>
|
||
<li>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).</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>The shell used to interpret the firewall script
|
||
(/usr/share/shorewall/firewall) may now be specified using the
|
||
SHOREWALL_SHELL parameter in shorewall.conf.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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]#<br>
|
||
<br>
|
||
</li>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>Support for the 2.6 Kernel series has been added.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>7/15/2003 - New Mirror in Brazil</b><b><br>
|
||
</b></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><b>7/15/2003 - Shorewall-1.4.6 RC 1</b> <b></b><b><br>
|
||
</b></p>
|
||
<p><b>Problems Corrected:</b><br>
|
||
</p>
|
||
<ol>
|
||
<li>A problem seen on RH7.3 systems where Shorewall encountered
|
||
start errors when started using the "service" mechanism has been
|
||
worked around.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>Corrected a problem in Beta 1 where DNS names containing a "-"
|
||
were mis-handled when they appeared in the DEST column of a
|
||
rule.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>Migration Issues:</b><br>
|
||
</p>
|
||
<ol>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>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).<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>New Features:</b><br>
|
||
</p>
|
||
<ol>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>Shorewall can now add IP addresses to subnets other than the
|
||
first one on an interface.<br>
|
||
<br>
|
||
</li>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>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...<br>
|
||
<br>
|
||
</li>
|
||
<li>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:</li>
|
||
<li
|
||
style="list-style-type: none; list-style-position: outside; list-style-image: none;">
|
||
<ul>
|
||
<li>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).</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>The shell used to interpret the firewall script
|
||
(/usr/share/shorewall/firewall) may now be specified using the
|
||
SHOREWALL_SHELL parameter in shorewall.conf.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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]#<br>
|
||
<br>
|
||
</li>
|
||
<li>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</li>
|
||
</ol>
|
||
<p><b>7/7/2003 - Shorewall-1.4.6 Beta 2</b></p>
|
||
<p><b>Problems Corrected:</b><br>
|
||
</p>
|
||
<ol>
|
||
<li>A problem seen on RH7.3 systems where Shorewall encountered
|
||
start errors when started using the "service" mechanism has been
|
||
worked around.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>Corrected a problem in Beta 1 where DNS names containing a "-"
|
||
were mis-handled when they appeared in the DEST column of a
|
||
rule.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>Migration Issues:</b><br>
|
||
</p>
|
||
<ol>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>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).<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>New Features:</b><br>
|
||
</p>
|
||
<ol>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>Shorewall can now add IP addresses to subnets other than the
|
||
first one on an interface.<br>
|
||
<br>
|
||
</li>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
<li>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...<br>
|
||
<br>
|
||
</li>
|
||
<li>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:</li>
|
||
<li
|
||
style="list-style-type: none; list-style-position: outside; list-style-image: none;">
|
||
<ul>
|
||
<li>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).</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>The shell used to interpret the firewall script
|
||
(/usr/share/shorewall/firewall) may now be specified using the
|
||
SHOREWALL_SHELL parameter in shorewall.conf.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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]#<br>
|
||
<br>
|
||
</li>
|
||
<li>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<br>
|
||
<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>7/4/2003 - Shorewall-1.4.6 Beta 1</b></p>
|
||
<p><b>Problems Corrected:</b><br>
|
||
</p>
|
||
<ol>
|
||
<li>A problem seen on RH7.3 systems where Shorewall encountered
|
||
start errors when started using the "service" mechanism has been
|
||
worked around.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>New Features:</b><br>
|
||
</p>
|
||
<ol>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>Shorewall can now add IP addresses to subnets other than the
|
||
first one on an interface.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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...<br>
|
||
<br>
|
||
</li>
|
||
<li>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:</li>
|
||
<li
|
||
style="list-style-type: none; list-style-position: outside; list-style-image: none;">
|
||
<ul>
|
||
<li>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).</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>The shell used to interpret the firewall script
|
||
(/usr/share/shorewall/firewall) may now be specified using the
|
||
SHOREWALL_SHELL parameter in shorewall.conf.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>6/17/2003 - Shorewall-1.4.5</b></p>
|
||
<p>Problems Corrected:<br>
|
||
</p>
|
||
<ol>
|
||
<li>The command "shorewall debug try <directory>" now
|
||
correctly traces the attempt.</li>
|
||
<li>The INCLUDE directive now works properly in the zones file;
|
||
previously, INCLUDE in that file was ignored.</li>
|
||
<li>/etc/shorewall/routestopped records with an empty second column
|
||
are no longer ignored.<br>
|
||
</li>
|
||
</ol>
|
||
<p>New Features:<br>
|
||
</p>
|
||
<ol>
|
||
<li>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.</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.<br>
|
||
</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.<br>
|
||
</p>
|
||
<p><b>5/27/2003 - Shorewall-1.4.4a</b></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'. <br>
|
||
<p><b>5/23/2003 - Shorewall-1.4.4</b></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><br>
|
||
<blockquote>None.<br>
|
||
</blockquote>
|
||
<b> New Features:<br>
|
||
</b>
|
||
<ol>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>5/20/2003 - Shorewall-1.4.3a</b> <b></b> <b></b><br>
|
||
</p>
|
||
This version primarily corrects the documentation included in the
|
||
.tgz and in the .rpm. In addition: <br>
|
||
<ol>
|
||
<li>(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</li>
|
||
<li>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.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>5/18/2003 - Shorewall 1.4.3</b> <b></b><br>
|
||
</p>
|
||
<b>Problems Corrected:<br>
|
||
</b>
|
||
<ol>
|
||
<li>There were several cases where Shorewall would fail to remove a
|
||
temporary directory from /tmp. These cases have been
|
||
corrected.</li>
|
||
<li>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.</li>
|
||
</ol>
|
||
<b>New Features:<br>
|
||
</b>
|
||
<ol>
|
||
<li> IPV6-IPV4 (6to4) tunnels are now supported in the
|
||
/etc/shorewall/tunnels file.</li>
|
||
<li value="2">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.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>5/10/2003 - Shorewall Mirror in Asia<br>
|
||
</b></p>
|
||
<p>Ed Greshko has established a mirror in Taiwan -- Thanks Ed!<br>
|
||
</p>
|
||
<p><b>5/8/2003 - Shorewall Mirror in Chile</b></p>
|
||
Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago
|
||
Chile.
|
||
<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><br>
|
||
</p>
|
||
<p><b> Problems Corrected:</b></p>
|
||
<blockquote>
|
||
<ol>
|
||
<li>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.</li>
|
||
<li>'traceroute -I' from behind the firewall previously timed out
|
||
on the first hop (e.g., to the firewall). This has been worked
|
||
around.</li>
|
||
</ol>
|
||
</blockquote>
|
||
<p><b> New Features:</b></p>
|
||
<ol>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>3/24/2003 - Shorewall 1.4.1</b> <b></b></p>
|
||
<b></b>
|
||
<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><br>
|
||
</p>
|
||
<ol>
|
||
<li>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.</li>
|
||
</ol>
|
||
<b>New Features:</b><br>
|
||
<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:<br>
|
||
<blockquote>eth0:0.0.0.0/0<br>
|
||
eth2:192.168.1.0/24<br>
|
||
eth3:192.0.2.123<br>
|
||
</blockquote>
|
||
You can use the "shorewall check" command to see the groups
|
||
associated with each of your zones.<br>
|
||
</blockquote>
|
||
<ol>
|
||
<li>Beginning with Shorewall 1.4.1, if a zone Z comprises more than
|
||
one group <i></i>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.</li>
|
||
<li>Beginning with Shorewall 1.4.1, Shorewall will never create
|
||
rules to handle traffic from a group to itself.</li>
|
||
<li>A NONE policy is introduced in 1.4.1. When a policy of NONE is
|
||
specified from Z1 to Z2:</li>
|
||
</ol>
|
||
<ul>
|
||
<li>There may be no rules created that govern connections from Z1
|
||
to Z2.</li>
|
||
<li>Shorewall will not create any infrastructure to handle traffic
|
||
from Z1 to Z2.</li>
|
||
</ul>
|
||
See the <a href="upgrade_issues.htm">upgrade issues</a> for a
|
||
discussion of how these changes may affect your configuration.
|
||
<p><b>3/17/2003 - Shorewall 1.4.0</b> <b></b></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:<br>
|
||
<ol>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>Interface names of the form <device>:<integer> in
|
||
/etc/shorewall/interfaces now generate an error.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no
|
||
longer accepted.<br>
|
||
<br>
|
||
</li>
|
||
<li>The ALLOWRELATED variable in shorewall.conf is no longer
|
||
supported. Shorewall 1.4 behavior is the same as 1.3 with
|
||
ALLOWRELATED=Yes.<br>
|
||
<br>
|
||
</li>
|
||
<li>The icmp.def file has been removed.<br>
|
||
</li>
|
||
</ol>
|
||
Changes for 1.4 include:<br>
|
||
<ol>
|
||
<li>The /etc/shorewall/shorewall.conf file has been completely
|
||
reorganized into logical sections.<br>
|
||
<br>
|
||
</li>
|
||
<li>LOG is now a valid action for a rule
|
||
(/etc/shorewall/rules).<br>
|
||
<br>
|
||
</li>
|
||
<li>The firewall script and version file are now installed in
|
||
/usr/share/shorewall.<br>
|
||
<br>
|
||
</li>
|
||
<li>Late arriving DNS replies are now silently dropped in the
|
||
common chain by default.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>CONTINUE is now a valid action for a rule
|
||
(/etc/shorewall/rules).<br>
|
||
<br>
|
||
</li>
|
||
<li>802.11b devices with names of the form wlan<n> now
|
||
support the 'maclist' option.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>The /etc/shorewall/params file is now processed first so that
|
||
variables may be used in the /etc/shorewall/shorewall.conf
|
||
file.<br>
|
||
<br>
|
||
</li>
|
||
<li value="10">Shorewall now gives a more helpful diagnostic when
|
||
the 'ipchains' compatibility kernel module is loaded and a
|
||
'shorewall start' command is issued.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>Shorewall now ignores 'default' routes when detecting masq'd
|
||
networks.</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>There is an updated rfc1918 file that reflects the resent
|
||
allocation of 222.0.0.0/8 and 223.0.0.0/8.</li>
|
||
</ul>
|
||
<ul>
|
||
<li>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.</li>
|
||
<li>Log messages produced by 'logunclean' and 'dropunclean' were
|
||
not rate-limited.</li>
|
||
<li>802.11b devices with names of the form <i>wlan</i><n>
|
||
don't support the 'maclist' interface option.</li>
|
||
<li>Log messages generated by RFC 1918 filtering are not rate
|
||
limited.</li>
|
||
<li>The firewall fails to start in the case where you have "eth0
|
||
eth1" in /etc/shorewall/masq and the default route is through
|
||
eth1</li>
|
||
</ul>
|
||
<p><b>2/8/2003 - Shoreawall 1.3.14</b></p>
|
||
<p>New features include</p>
|
||
<ol>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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>
|
||
</li>
|
||
<li>Support for OpenVPN Tunnels.<br>
|
||
<br>
|
||
</li>
|
||
<li>Support for VLAN devices with names of the form $DEV.$VID
|
||
(e.g., eth0.0)<br>
|
||
<br>
|
||
</li>
|
||
<li>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>.<br>
|
||
<br>
|
||
</li>
|
||
<li>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>
|
||
<br>
|
||
<pre> [root@gateway test]# cat /etc/shorewall/masq<br>
|
||
#INTERFACE SUBNET ADDRESS<br>
|
||
eth0 eth2 206.124.146.176<br>
|
||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
||
</pre>
|
||
<pre> [root@gateway test]# ip route show dev eth2<br>
|
||
192.168.1.0/24 scope link<br>
|
||
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
||
</pre>
|
||
<pre> [root@gateway test]# shorewall start<br>
|
||
...<br>
|
||
Masqueraded Subnets and Hosts:<br>
|
||
To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br>
|
||
To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br>
|
||
Processing /etc/shorewall/tos...
|
||
</pre>
|
||
<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>
|
||
<br>
|
||
<pre> [root@gateway test]# cat /etc/shorewall/masq<br>
|
||
#INTERFACE SUBNET ADDRESS<br>
|
||
eth0 eth2 206.124.146.176<br>
|
||
eth0 192.168.10.0/24 206.124.146.176<br>
|
||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
||
</pre>
|
||
<pre> [root@gateway test]# ip route show dev eth2<br>
|
||
192.168.1.0/24 scope link<br>
|
||
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
||
[root@gateway test]#
|
||
</pre>
|
||
<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>
|
||
<br>
|
||
<pre> [root@gateway test]# cat /etc/shorewall/masq<br>
|
||
#INTERFACE SUBNET ADDRESS<br>
|
||
eth0 eth2 206.124.146.176<br>
|
||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
||
</pre>
|
||
<pre> [root@gateway test]# ip route show dev eth2<br>
|
||
192.168.1.0/24 scope link<br>
|
||
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
||
[root@gateway test]#
|
||
</pre>
|
||
<br>
|
||
In this case, you would want to change the entry
|
||
in /etc/shorewall/masq to:<br>
|
||
<pre> #INTERFACE SUBNET ADDRESS<br>
|
||
eth0 192.168.1.0/24 206.124.146.176<br>
|
||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
||
</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><br>
|
||
</p>
|
||
<p>The Beta includes the following changes:<br>
|
||
</p>
|
||
<ol>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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>
|
||
</li>
|
||
<li>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>
|
||
<br>
|
||
<pre> [root@gateway test]# cat /etc/shorewall/masq<br>
|
||
#INTERFACE SUBNET ADDRESS<br>
|
||
eth0 eth2 206.124.146.176<br>
|
||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
||
</pre>
|
||
<pre> [root@gateway test]# ip route show dev eth2<br>
|
||
192.168.1.0/24 scope link<br>
|
||
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
||
</pre>
|
||
<pre> [root@gateway test]# shorewall start<br>
|
||
...<br>
|
||
Masqueraded Subnets and Hosts:<br>
|
||
To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br>
|
||
To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br>
|
||
Processing /etc/shorewall/tos...
|
||
</pre>
|
||
<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>
|
||
<br>
|
||
<pre> [root@gateway test]# cat /etc/shorewall/masq<br>
|
||
#INTERFACE SUBNET ADDRESS<br>
|
||
eth0 eth2 206.124.146.176<br>
|
||
eth0 192.168.10.0/24 206.124.146.176<br>
|
||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
||
</pre>
|
||
<pre> [root@gateway test]# ip route show dev eth2<br>
|
||
192.168.1.0/24 scope link<br>
|
||
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
||
[root@gateway test]#
|
||
</pre>
|
||
<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>
|
||
<br>
|
||
<pre> [root@gateway test]# cat /etc/shorewall/masq<br>
|
||
#INTERFACE SUBNET ADDRESS<br>
|
||
eth0 eth2 206.124.146.176<br>
|
||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
||
</pre>
|
||
<pre> [root@gateway test]# ip route show dev eth2<br>
|
||
192.168.1.0/24 scope link<br>
|
||
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
||
[root@gateway test]#
|
||
</pre>
|
||
<br>
|
||
In this case, you would want to change the entry
|
||
in /etc/shorewall/masq to:<br>
|
||
<pre> #INTERFACE SUBNET ADDRESS<br>
|
||
eth0 192.168.1.0/24 206.124.146.176<br>
|
||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
||
</pre>
|
||
<b></b></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>
|
||
<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><b>1/17/2003 - shorewall.net has MOVED</b><b> </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.<br>
|
||
</p>
|
||
<p><b>1/13/2003 - Shorewall 1.3.13<br>
|
||
</b></p>
|
||
<p>Just includes a few things that I had on the burner:<br>
|
||
</p>
|
||
<ol>
|
||
<li>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,....<br>
|
||
<br>
|
||
</li>
|
||
<li>The 'shorewall check' command now prints out the applicable
|
||
policy between each pair of zones.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
<br>
|
||
</li>
|
||
<li>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.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>1/6/2003 - <big><big><big>BURNOUT</big></big></big></b>
|
||
<b></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><br>
|
||
</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><br>
|
||
</p>
|
||
<p><b>12/27/2002 - Shorewall 1.3.12 Released</b></p>
|
||
<p>Features include:<br>
|
||
</p>
|
||
<ol>
|
||
<li>"shorewall refresh" now reloads the traffic shaping rules
|
||
(tcrules and tcstart).</li>
|
||
<li>"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.</li>
|
||
<li>"shorewall [re]start" has been speeded up by more than 40% with
|
||
my configuration. Your milage may vary.</li>
|
||
<li>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"</li>
|
||
<li>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>.</li>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>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.<br>
|
||
</li>
|
||
</ol>
|
||
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 3<br>
|
||
</b></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.<br>
|
||
<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).<br>
|
||
</p>
|
||
Features include:<br>
|
||
<ol>
|
||
<li>"shorewall refresh" now reloads the traffic shaping rules
|
||
(tcrules and tcstart).</li>
|
||
<li>"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.</li>
|
||
<li>"shorewall [re]start" has been speeded up by more than 40% with
|
||
my configuration. Your milage may vary.</li>
|
||
<li>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"</li>
|
||
<li>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>.</li>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
</ol>
|
||
You may download the Beta from:<br>
|
||
<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><br>
|
||
</blockquote>
|
||
<p><b>12/12/2002 - Mandrake Multi Network Firewall <a
|
||
href="http://www.mandrakesoft.com"><img src="images/logo2.png"
|
||
alt="Powered by Mandrake Linux" border="0" height="21" width="140">
|
||
</a></b></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>.<br>
|
||
<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<br>
|
||
</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>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.</li>
|
||
<li>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'.</li>
|
||
<li>Shorewall's use of the 'echo' command is now compatible with
|
||
bash clones such as ash and dash.</li>
|
||
<li>fw->fw policies now generate a startup error. fw->fw
|
||
rules generate a warning and are ignored</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><br>
|
||
</p>
|
||
<p><b>11/09/2002 - Shorewall is Back at SourceForge</b> <b></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>.<br>
|
||
</p>
|
||
<p><b>11/09/2002 - Shorewall 1.3.10</b></p>
|
||
<p>In this version:</p>
|
||
<ul>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>PPTP Servers and Clients running on the firewall system may now
|
||
be defined in the <a href="PPTP.htm">/etc/shorewall/tunnels</a>
|
||
file.</li>
|
||
<li>A new 'ipsecnat' tunnel type is supported for use when the <a
|
||
href="IPSEC.htm">remote IPSEC endpoint is behind a NAT
|
||
gateway</a>.</li>
|
||
<li>The PATH used by Shorewall may now be specified in <a
|
||
href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a></li>
|
||
<li>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</li>
|
||
</ul>
|
||
<p><b>10/24/2002 - Shorewall is now in Gentoo Linux</b> <b></b><a
|
||
href="http://www.gentoo.org"><br>
|
||
</a></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!<br>
|
||
<p><b>10/23/2002 - Shorewall 1.3.10 Beta 1</b> <b></b></p>
|
||
In this version:<br>
|
||
<ul>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>PPTP Servers and Clients running on the firewall system may now
|
||
be defined in the <a href="PPTP.htm">/etc/shorewall/tunnels</a>
|
||
file.</li>
|
||
<li>A new 'ipsecnat' tunnel type is supported for use when the <a
|
||
href="IPSEC.htm">remote IPSEC endpoint is behind a NAT
|
||
gateway</a>.</li>
|
||
<li>The PATH used by Shorewall may now be specified in <a
|
||
href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a></li>
|
||
<li>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.</li>
|
||
</ul>
|
||
You may download the Beta from:<br>
|
||
<ul>
|
||
<li><a href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a></li>
|
||
<li><a href="ftp://ftp.shorewall.net/pub/shorewall/Beta" target="_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a></li>
|
||
</ul>
|
||
<p><b>10/10/2002 - Debian 1.3.9b Packages Available<br>
|
||
</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>
|
||
This release rolls up fixes to the installer and to the firewall
|
||
script.<br>
|
||
<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>
|
||
Roles up the fix for broken tunnels.<br>
|
||
<p><b>9/30/2002 - TUNNELS Broken in 1.3.9!!!</b></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.<br>
|
||
<p><b>9/28/2002 - Shorewall 1.3.9</b></p>
|
||
<p>In this version:<br>
|
||
</p>
|
||
<ul>
|
||
<li><a href="configuration_file_basics.htm#dnsnames">DNS Names</a>
|
||
are now allowed in Shorewall config files (although I recommend
|
||
against using them).</li>
|
||
<li>The connection SOURCE may now be qualified by both interface
|
||
and IP address in a <a href="Documentation.htm#Rules">Shorewall
|
||
rule</a>.</li>
|
||
<li>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.</li>
|
||
<li>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.<br>
|
||
</li>
|
||
</ul>
|
||
<p><b>9/23/2002 - Full Shorewall Site/Mailing List Archive Search
|
||
Capability Restored</b><br>
|
||
</p>
|
||
<img src="images/j0233056.gif" alt="Brown Paper Bag" align="left"
|
||
height="86" width="50"> A couple of recent configuration changes
|
||
at www.shorewall.net broke the Search facility:<br>
|
||
<blockquote>
|
||
<ol>
|
||
<li>Mailing List Archive Search was not available.</li>
|
||
<li>The Site Search index was incomplete</li>
|
||
<li>Only one page of matches was presented.</li>
|
||
</ol>
|
||
</blockquote>
|
||
Hopefully these problems are now corrected.
|
||
<p><b>9/23/2002 - Full Shorewall Site/Mailing List Archive Search
|
||
Capability Restored<br>
|
||
</b></p>
|
||
A couple of recent configuration changes at www.shorewall.net had
|
||
the negative effect of breaking the Search facility:<br>
|
||
<ol>
|
||
<li>Mailing List Archive Search was not available.</li>
|
||
<li>The Site Search index was incomplete</li>
|
||
<li>Only one page of matches was presented.</li>
|
||
</ol>
|
||
Hopefully these problems are now corrected.<br>
|
||
<p><b>9/18/2002 - Debian 1.3.8 Packages Available<br>
|
||
</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:<br>
|
||
</p>
|
||
<ul>
|
||
<li>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).</li>
|
||
<li>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:</li>
|
||
<li
|
||
style="list-style-type: none; list-style-position: outside; list-style-image: none;">
|
||
<ul>
|
||
<li>There is a policy for za to zb; or</li>
|
||
<li>There is at least one rule for za to zb.</li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<ul>
|
||
<li>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.<br>
|
||
</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 target="_blank"
|
||
href="ftp://france.shorewall.net/pub/mirrors/shorewall">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 target="_top" href="http://france.shorewall.net">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"
|
||
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>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>.</li>
|
||
<li>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.</li>
|
||
<li>The loopback CLASS A Network (127.0.0.0/8) has been added to
|
||
the rfc1918 file.</li>
|
||
<li>Shorewall now works with iptables 1.2.7</li>
|
||
<li>The documentation and web site no longer uses FrontPage
|
||
themes.</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 target="_top"
|
||
href="http://www.shorewall.net/cgi-bin/cvs/cvsweb.cgi">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
|
||
target="_top" href="http://www.shorewall.net/cgi-bin/cvs/cvsweb.cgi">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="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>The latest <a href="shorewall_quickstart_guide.htm">QuickStart
|
||
Guides</a> including the <a href="shorewall_setup_guide.htm">Shorewall
|
||
Setup Guide.</a></li>
|
||
<li>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>.</li>
|
||
<li>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>.</li>
|
||
</ul>
|
||
<p><b>7/30/2002 - Shorewall 1.3.5b Released</b></p>
|
||
<p>This interim release:</p>
|
||
<ul>
|
||
<li>Causes the firewall script to remove the lock file if it is
|
||
killed.</li>
|
||
<li>Once again allows lists in the second column of the <a
|
||
href="Documentation.htm#Hosts">/etc/shorewall/hosts</a> file.</li>
|
||
<li>Includes the latest <a href="shorewall_quickstart_guide.htm">QuickStart
|
||
Guides</a>.</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><b> </b> In this version:</p>
|
||
<ul>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>The time that the counters were last reset is now displayed in
|
||
the heading of the 'status' and 'show' commands.</li>
|
||
<li>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.</li>
|
||
<li>The Samples have been updated to reflect the new capabilities
|
||
in this release.</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>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.</li>
|
||
<li>An /etc/shorewall/stopped <a href="Documentation.htm#Scripts">extension
|
||
script</a> has been added.
|
||
This script is invoked after Shorewall has stopped.</li>
|
||
<li>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.</li>
|
||
<li>The <a href="shorewall_quickstart_guide.htm">QuickStart
|
||
Guide</a> has been broken into three guides and has been almost
|
||
entirely rewritten.</li>
|
||
<li>The Samples have been updated to reflect the new capabilities
|
||
in this release.</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>Entries in /etc/shorewall/interface that use the wildcard
|
||
character ("+") now have the "multi" option assumed.</li>
|
||
<li>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.</li>
|
||
<li>Interface names appearing in the hosts file are now validated
|
||
against the interfaces file.</li>
|
||
<li>The TARGET column in the rfc1918 file is now checked for
|
||
correctness.</li>
|
||
<li>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</li>
|
||
<li>The "hits" command has been enhanced.</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="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>A <a href="Documentation.htm#Starting">logwatch command</a> has
|
||
been added to /sbin/shorewall.</li>
|
||
<li>A <a href="blacklisting_support.htm">dynamic blacklist
|
||
facility</a> has been added.</li>
|
||
<li>Support for the <a href="Documentation.htm#Conf">Netfilter
|
||
multiport match function</a> has been added.</li>
|
||
<li>The files <b>firewall, functions</b> and <b>version</b> have
|
||
been moved from /etc/shorewall to /var/lib/shorewall.</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>Ignore robot.txt files.</li>
|
||
<li>Recursively copy everything that they find.</li>
|
||
<li>Should be classified as weapons rather than tools.</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>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.</li>
|
||
<li>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>.</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>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.</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>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>.</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>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.</li>
|
||
<li><a href="Documentation.htm#Exclude">Sub-zones may now be
|
||
excluded from DNAT and REDIRECT rules.</a></li>
|
||
<li>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.</li>
|
||
<li>The sample configurations have been updated for 1.3.</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>Simplified rule syntax which makes the intent of each rule
|
||
clearer and hopefully makes Shorewall easier to learn.</li>
|
||
<li>Upward compatibility with 1.2 configuration files has been
|
||
maintained so that current users can migrate to the new syntax at
|
||
their convenience.</li>
|
||
<li><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></li>
|
||
</ul>
|
||
<p><b>5/4/2002 - Shorewall 1.2.13 is Available</b></p>
|
||
<p>In this version:</p>
|
||
<ul>
|
||
<li><a href="Documentation.htm#Whitelist">White-listing</a> is
|
||
supported.</li>
|
||
<li><a href="Documentation.htm#Policy">SYN-flood protection</a> is
|
||
added.</li>
|
||
<li>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.</li>
|
||
<li>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>.</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>The 'try' command works again</li>
|
||
<li>There is now a single RPM that also works with SuSE.</li>
|
||
</ul>
|
||
<p><b>4/17/2002 - Shorewall Debian News</b></p>
|
||
<p>Lorenzo Marignoni reports that:</p>
|
||
<ul>
|
||
<li>Shorewall 1.2.10 is in the <a
|
||
href="http://packages.debian.org/testing/net/shorewall.html">Debian
|
||
Testing Branch</a></li>
|
||
<li>Shorewall 1.2.11 is in the <a
|
||
href="http://packages.debian.org/unstable/net/shorewall.html">Debian
|
||
Unstable Branch</a></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>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.</li>
|
||
<li>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>.</li>
|
||
<li>Individual IP source addresses and/or subnets may now be
|
||
excluded from masquerading/SNAT.</li>
|
||
<li>Simple "Yes/No" and "On/Off" values are now case-insensitive in
|
||
/etc/shorewall/shorewall.conf.</li>
|
||
</ul>
|
||
<p><b>4/13/2002 - Hamburg Mirror now has FTP</b></p>
|
||
<p>Stefan now has an FTP mirror at <a target="_blank"
|
||
href="ftp://germany.shorewall.net/pub/shorewall">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
|
||
target="_top" href="http://germany.shorewall.net">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="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="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>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>.</li>
|
||
<li>Shorewall 1.2.9 is now in the <a
|
||
href="http://packages.debian.org/unstable/net/shorewall.html">Debian
|
||
Unstable Distribution</a>.</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="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>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).</li>
|
||
<li>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.</li>
|
||
<li>Copyright notices have been added to the documenation.</li>
|
||
</ul>
|
||
<p><b>3/11/2002 - Shorewall 1.2.9 Released</b></p>
|
||
<p>In this version:</p>
|
||
<ul>
|
||
<li>Filtering by <a href="Documentation.htm#MAC">MAC address</a>
|
||
has been added. MAC addresses may be used as the source address in:
|
||
<ul>
|
||
<li>Filtering rules (<a href="Documentation.htm#Rules">/etc/shorewall/rules</a>)</li>
|
||
<li>Traffic Control Classification Rules (<a
|
||
href="traffic_shaping.htm#tcrules">/etc/shorewall/tcrules</a>)</li>
|
||
<li>TOS Rules (<a href="Documentation.htm#TOS">/etc/shorewall/tos</a>)</li>
|
||
<li>Blacklist (<a href="Documentation.htm#Blacklist">/etc/shorewall/blacklist</a>)</li>
|
||
</ul>
|
||
</li>
|
||
<li>Several bugs have been fixed</li>
|
||
<li>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>.</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>UPnP probes (UDP destination port 1900) are now silently
|
||
dropped in the <i>common</i> chain</li>
|
||
<li>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.</li>
|
||
<li>A 'shorewall check' command has been added that does a cursory
|
||
validation of the zones, interfaces, hosts, rules and policy
|
||
files.</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>$-variables may now be used anywhere in the configuration files
|
||
except /etc/shorewall/zones.</li>
|
||
<li>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.</li>
|
||
<li>A problem occurring when BLACKLIST_LOGLEVEL was not set has
|
||
been corrected.</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>The installation problems have been corrected.</li>
|
||
<li><a href="Documentation.htm#Masq">SNAT</a> is now
|
||
supported.</li>
|
||
<li>A "shorewall version" command has been added</li>
|
||
<li>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.</li>
|
||
</ul>
|
||
<p><b>1/28/2002 - Shorewall 1.2.4 Released</b></p>
|
||
<ul>
|
||
<li>The "fw" zone <a href="Documentation.htm#FW">may now be given a
|
||
different name</a>.</li>
|
||
<li>You may now place end-of-line comments (preceded by '#') in any
|
||
of the configuration files</li>
|
||
<li>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".</li>
|
||
<li>"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.</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="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>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.</li>
|
||
</ul>
|
||
<p>The following problems were corrected:</p>
|
||
<ul>
|
||
<li>The "shorewall status" command no longer hangs.</li>
|
||
<li>The "shorewall monitor" command now displays the icmpdef
|
||
chain</li>
|
||
<li>The CLIENT PORT(S) column in tcrules is no longer ignored</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="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>Support for IP blacklisting has been added
|
||
<ul>
|
||
<li>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</li>
|
||
<li>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</li>
|
||
<li>You list the IP addresses/subnets that you wish to blacklist
|
||
in <a href="Documentation.htm#Blacklist">/etc/shorewall/blacklist</a></li>
|
||
<li>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.</li>
|
||
<li>The black list is refreshed from /etc/shorewall/blacklist by
|
||
the "shorewall refresh" command.</li>
|
||
</ul>
|
||
</li>
|
||
<li>Use of TCP RST replies has been expanded
|
||
<ul>
|
||
<li>TCP connection requests rejected because of a REJECT policy
|
||
are
|
||
now replied with a TCP RST packet.</li>
|
||
<li>TCP connection requests rejected because of a protocol=all
|
||
rule
|
||
in /etc/shorewall/rules are now replied with a TCP RST packet.</li>
|
||
</ul>
|
||
</li>
|
||
<li>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.</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>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.</li>
|
||
<li>Orphan DNS replies are now silently dropped.</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><a href="Documentation.htm#LogUncleanOption">Logging of
|
||
Mangled/Invalid Packets</a> is added. </li>
|
||
<li>The <a href="IPIP.htm">tunnel script</a> has been
|
||
corrected.</li>
|
||
<li>'shorewall show tc' now correctly handles tunnels.</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>Support for <a href="traffic_shaping.htm">Traffic
|
||
Control/Shaping</a></li>
|
||
<li>Support for <a href="Documentation.htm#Unclean">Filtering of
|
||
Mangled/Invalid Packets</a></li>
|
||
<li>Support for <a href="IPIP.htm">GRE Tunnels</a></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>
|
||
<p>rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm</p>
|
||
</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>.<b>
|
||
</b></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>Ping is now allowed between the zones.</li>
|
||
<li>In the three-interface configuration, it is now possible to
|
||
configure the internet services that are to be available to servers
|
||
in the DMZ. </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>The spelling of ADD_IP_ALIASES has been corrected in the
|
||
shorewall.conf file</li>
|
||
<li>The logic for deleting user-defined chains has been simplified
|
||
so that it avoids a bug in the LRP version of the 'cut'
|
||
utility.</li>
|
||
<li>The /var/lib/lrpkg/shorwall.conf file has been corrected to
|
||
properly display the NAT entry in that file.</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>One Interface -- for a standalone system.</li>
|
||
<li>Two Interfaces -- A masquerading firewall.</li>
|
||
<li>Three Interfaces -- A masquerading firewall with DMZ.</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>The handling of <a href="Documentation.htm#Aliases">ADD_IP_ALIASES</a>
|
||
has been
|
||
corrected. </li>
|
||
</ul>
|
||
<p><b>10/22/2001 - The current version of Shorewall is 1.1.16</b>.
|
||
In this version:</p>
|
||
<ul>
|
||
<li>A new "shorewall show connections" command has been added.</li>
|
||
<li>In the "shorewall monitor" output, the currently tracked
|
||
connections are now shown on a separate page.</li>
|
||
<li>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. </li>
|
||
</ul>
|
||
<p><b>10/15/2001 - The current version of Shorewall is 1.1.15.</b>
|
||
In this version:</p>
|
||
<ul>
|
||
<li>Support for nested zones has been improved. See <a
|
||
href="Documentation.htm#Nested">the documentation</a> for details</li>
|
||
<li>Shorewall now correctly checks the alternate configuration
|
||
directory for the 'zones' file.</li>
|
||
</ul>
|
||
<p><b>10/4/2001 - The current version of Shorewall is 1.1.14.</b>
|
||
In this version</p>
|
||
<ul>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>Rules that specify multiple client ip addresses or subnets no
|
||
longer cause startup failures.</li>
|
||
<li>Zone names in the policy file are now validated against the
|
||
zones file.</li>
|
||
<li>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.</li>
|
||
</ul>
|
||
<p><b>9/12/2001 - The current version of Shorewall is 1.1.13</b>.
|
||
In this version</p>
|
||
<ul>
|
||
<li>Shell variables can now be used to parameterize Shorewall
|
||
rules.</li>
|
||
<li>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</li>
|
||
<li>Handling of multi-zone interfaces has been improved. See the <a
|
||
href="Documentation.htm#Interfaces">documentation for the
|
||
/etc/shorewall/interfaces file</a>.</li>
|
||
</ul>
|
||
<p><b>8/28/2001 - The current version of Shorewall is 1.1.12</b>.
|
||
In this version</p>
|
||
<ul>
|
||
<li>Several columns in the rules file may now contain
|
||
comma-separated lists.</li>
|
||
<li>Shorewall is now more rigorous in parsing the options in
|
||
/etc/shorewall/interfaces.</li>
|
||
<li>Complementation using "!" is now supported in rules.</li>
|
||
</ul>
|
||
<p><b>7/28/2001 - The current version of Shorewall is 1.1.11</b>.
|
||
In this version</p>
|
||
<ul>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>The "dhcp" interface option is now applicable to firewall
|
||
interfaces used by a DHCP server running on the firewall.</li>
|
||
<li>The RPM can now be built from the .tgz file using "rpm
|
||
-tb" </li>
|
||
</ul>
|
||
<p><b>7/6/2001 - The current version of Shorewall is 1.1.10.</b> In
|
||
this version</p>
|
||
<ul>
|
||
<li>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.</li>
|
||
<li>The "shorewall hits" command no longer lists extraneous service
|
||
names in its last report.</li>
|
||
<li>Erroneous instructions in the comments at the head of the
|
||
firewall script have been corrected.</li>
|
||
</ul>
|
||
<p><b>6/23/2001 - The current version of Shorewall is 1.1.9.</b> In
|
||
this version</p>
|
||
<ul>
|
||
<li>The "tunnels" file <u>really</u> is in the RPM now.</li>
|
||
<li>SNAT can now be applied to port-forwarded connections.</li>
|
||
<li>A bug which would cause firewall start failures in some dhcp
|
||
configurations has been fixed.</li>
|
||
<li>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.</li>
|
||
<li>You can now configure Shorewall so that it <a
|
||
href="Documentation.htm#NatEnabled">doesn't require the NAT and/or
|
||
mangle netfilter modules</a>.</li>
|
||
<li>Thanks to Alex Polishchuk, the "hits" command from
|
||
seawall is now in shorewall.</li>
|
||
<li>Support for <a href="IPIP.htm">IPIP tunnels</a> has been
|
||
added.</li>
|
||
</ul>
|
||
<p><b>6/18/2001 - The current version of Shorewall is 1.1.8</b>. In
|
||
this version</p>
|
||
<ul>
|
||
<li>A typo in the sample rules file has been corrected.</li>
|
||
<li>It is now possible to restrict masquerading by <a
|
||
href="Documentation.htm#Masq">destination host or subnet.</a></li>
|
||
<li>It is now possible to have static <a href="NAT.htm#LocalPackets">NAT
|
||
rules applied to packets originating on
|
||
the firewall itself</a>.</li>
|
||
</ul>
|
||
<p><b>6/2/2001 - The current version of Shorewall is 1.1.7.</b> In
|
||
this version</p>
|
||
<ul>
|
||
<li>The TOS rules are now deleted when the firewall is
|
||
stopped.</li>
|
||
<li>The .rpm will now install regardless of which version of
|
||
iptables is installed.</li>
|
||
<li>The .rpm will now install without iproute2 being
|
||
installed.</li>
|
||
<li>The documentation has been cleaned up.</li>
|
||
<li>The sample configuration files included in Shorewall have been
|
||
formatted to 80 columns for ease of editing on a VGA console.</li>
|
||
</ul>
|
||
<p><b>5/25/2001 - The current version of Shorewall is 1.1.6</b>. In
|
||
this version</p>
|
||
<ul>
|
||
<li><a href="Documentation.htm#lograte">You may now rate-limit the
|
||
packet log.</a></li>
|
||
<li>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. </li>
|
||
<li>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. </li>
|
||
</ul>
|
||
<p><b>5/20/2001 - The current version of Shorewall is 1.1.5.</b> In
|
||
this version</p>
|
||
<ul>
|
||
<li><a href="Documentation.htm#modules">You may now pass parameters
|
||
when loading netfilter modules and you can specify the modules to
|
||
load.</a></li>
|
||
<li>Compressed modules are now loaded. This requires that you
|
||
modutils support loading compressed modules.</li>
|
||
<li><a href="Documentation.htm#TOS">You may now set the Type of
|
||
Service (TOS) field in packets.</a></li>
|
||
<li>Corrected rules generated for port redirection (again).</li>
|
||
</ul>
|
||
<p><b>5/10/2001 - The current version of Shorewall is 1.1.4.</b> In
|
||
this version</p>
|
||
<ul>
|
||
<li><a href="Documentation.htm#Conf">Accepting RELATED connections
|
||
is now optional.</a></li>
|
||
<li>Corrected problem where if "shorewall start" aborted early (due
|
||
to kernel configuration errors for example), superfluous 'sed'
|
||
error messages were reported.</li>
|
||
<li>Corrected rules generated for port redirection.</li>
|
||
<li>The order in which iptables kernel modules are loaded has been
|
||
corrected (Thanks to Mark Pavlidis). </li>
|
||
</ul>
|
||
<p><b>4/28/2001 - The current version of Shorewall is 1.1.3.</b> In
|
||
this version</p>
|
||
<ul>
|
||
<li>Correct message issued when Proxy ARP address added (Thanks to
|
||
Jason Kirtland).</li>
|
||
<li>/tmp/shorewallpolicy-$$ is now removed if there is an error
|
||
while starting the firewall.</li>
|
||
<li>/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.</li>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>Previously, placing "-" in the PORT(S) column in
|
||
/etc/shorewall/rules resulted in an error message during start.
|
||
This has been corrected.</li>
|
||
<li>The first line of "install.sh" has been corrected -- I had
|
||
inadvertently deleted the initial "#".</li>
|
||
</ul>
|
||
<p><b>4/12/2001 - The current version of Shorewall is 1.1.2.</b> In
|
||
this version</p>
|
||
<ul>
|
||
<li>Port redirection now works again.</li>
|
||
<li>The icmpdef and common chains <a href="Documentation.htm#Icmpdef">may
|
||
now be user-defined</a>.</li>
|
||
<li>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.</li>
|
||
<li>The LRP Version is renamed "shorwall" for 8,3 MSDOS file system
|
||
compatibility.</li>
|
||
<li>A couple of LRP-specific problems were corrected.</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"
|
||
alt="Leaf Logo" 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>The common chain is traversed from INPUT, OUTPUT and FORWARD
|
||
before logging occurs</li>
|
||
<li>The source has been cleaned up dramatically</li>
|
||
<li>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. </li>
|
||
</ul>
|
||
<p><b>3/25/2001 - The current version of Shorewall is 1.1.0. In
|
||
this version:</b></p>
|
||
<ul>
|
||
<li>Log messages now indicate the packet disposition.</li>
|
||
<li>Error messages have been improved.</li>
|
||
<li>The ability to define zones consisting of an enumerated set of
|
||
hosts and/or subnetworks has been added.</li>
|
||
<li>The zone-to-zone chain matrix is now sparse so that only those
|
||
chains that contain meaningful rules are defined.</li>
|
||
<li>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.</li>
|
||
<li>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.</li>
|
||
<li>The Linux kernel's route filtering facility can now be
|
||
specified selectively on network interfaces.</li>
|
||
</ul>
|
||
<p><b>3/19/2001 - The current version of Shorewall is 1.0.4. This
|
||
version:</b></p>
|
||
<ul>
|
||
<li>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. </li>
|
||
<li>Adds the ability to specify logging in entries in the
|
||
/etc/shorewall/rules file.</li>
|
||
<li>Correct handling of the icmp-def chain so that only ICMP
|
||
packets are sent through the chain.</li>
|
||
<li>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).</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>The PATH variable in the firewall script now includes
|
||
/usr/local/bin and /usr/local/sbin.</li>
|
||
<li>DMZ-related chains are now correctly deleted if the DMZ is
|
||
deleted.</li>
|
||
<li>The interface OPTIONS for "gw" interfaces are no longer
|
||
ignored.</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>
|