shorewall_code/Shorewall-Website/News.htm

143 lines
21 KiB
HTML
Raw Normal View History

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta name="generator"
content="HTML Tidy for Linux (vers 1st April 2002), see www.w3.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Shorewall News</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Kate, the KDE Advanced Text Editor">
</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-12-01 </p>
<hr style="width: 100%; height: 2px;"> <span style="font-weight: bold;">2005-12-01
End of Support for Shorewall versions 2.0 and 2.2<br>
<br>
</span>Effective today, versions 2.0 and 2.2 are no longer supported.
This means that if you find a bug in one of these releases, we won't
fix it and if you ask for help with one of these releases, we will not
spend much time trying to solve your issue.<br>
<span style="font-weight: bold;"><br>
2005-11-25
Shorewall 3.0.2<br>
</span>
<pre>Problems Corrected in 3.0.2<br><br>1) A couple of typos in the one-interface sample configuration have<br> been corrected.<br><br>2) The 3.0.1 version of Shorewall was incompatible with old versions of<br> the Linux kernel (2.4.7 for example). The new code ignores errors<br> produced when Shorewall 3.x is run on these ancient kernels.<br><br>3) Arch Linux installation routines has been improved.<br><br>New Features in 3.0.2<br><br>1) A new Webmin macro has been added. This macro assumes that Webmin is<br> running on its default port (10000).<br></pre>
<span style="font-weight: bold;">2005-11-18
Shorewall 3.0.1</span><br>
<pre>Problems Corrected in 3.0.1 <br>
1) If the previous firewall configuration included a policy other than
ACCEPT in the nat, mangle or raw tables then Shorewall would not set
the policy to ACCEPT. This could result in a ruleset that rejected or
dropped all traffic.
2) The Makefile was broken such that 'make' didn't always work correctly.
3) If the SOURCE or DEST column in a macro body was non-empty and a dash
("-") appeared in the corresponding column of an invocation of that
macro, then an invalid rule was generated.
4) The comments in the /etc/shorewall/blacklist file have been updated to
clarify that the PORTS column refers to destination port number/service
names.
5) When CLAMPMSS is set to a value other than "No" and FASTACCEPT=Yes, the
order of the rules generated was incorrect causing RELATED TCP connections
to not have CLAMPMSS applied.
New Features in 3.0.1
1) To make the macro facility more flexible, Shorewall now examines the
contents of the SOURCE and DEST columns in both the macro body and in
the invocation and tries to create the intended rule. If the value in
the invocation appears to be an address (IP or MAC) or the name of an
ipset, then it is placed after the value in the macro body. Otherwise,
it is placed before the value in the macro body.
Example 1:
/etc/shorewall/macro.foo:
PARAM - 192.168.1.5 tcp http
/etc/shorewallrules:
foo/ACCEPT net loc
Effective rule:
ACCEPT net loc:192.168.1.5 tcp http
Example 2:
/etc/shorewall/macro.bar:
PARAM net loc tcp http
/etc/shorewall/rules:
bar/ACCEPT - 192.168.1.5
Effective rule:
ACCEPT net loc:192.168.1.5 tcp http
</pre>
<p></p>
<hr style="width: 100%; height: 2px;"> <span style="font-weight: bold;">11/11/2005
Shorewall 3.0.0</span><br>
<pre>New Features in Shorewall 3.0.0<br><br>1) Error and warning messages are made easier to spot by using<br> capitalization (e.g., ERROR: and WARNING:).<br><br>2) A new option 'critical' has been added to<br> /etc/shorewall/routestopped. This option can be used to enable<br> communication with a host or set of hosts during the entire<br> "shorewall [re]start/stop" process. Listing a host with this option<br> differs from listing it without the option in several ways:<br><br> a) The option only affect traffic between the listed host(s) and the<br> firewall itself.<br><br> b) If there are any entries with 'critical', the firewall<br> will be completely opened briefly during start, restart and stop but<br> there will be no chance of any packets to/from the listed host(s)<br> being dropped or rejected.<br><br> Possible uses for this option are:<br><br> a) Root file system is NFS mounted. You will want to list the NFS server<br> in the 'critical' option.<br><br> b) You are running Shorewall in a Crossbeam environment<br> (www.crossbeam.com). You will want to list the Crossbeam interface<br> in this option<br><br>3) A new 'macro' feature has been added.<br><br> Macros are very similar to actions and can be used in similar<br> ways. The differences between actions and macros are as follows:<br><br> a) An action creates a separate chain with the same name as the<br> action (when logging is specified on the invocation of an action,<br> a chain beginning with "%" followed by the name of the action and<br> possibly followed by a number is created). When a macro is<br> invoked, it is expanded in-line and no new chain is created.<br><br> b) An action may be specified as the default action for a policy;<br> macros cannot be specified this way.<br><br> c) Actions must be listed in either /usr/share/shorewall/actions.std<br> or in /etc/shorewall/actions. Macros are defined simply by<br> placing their definition file in the CONFIG_PATH.<br><br> d) Actions are defined in a file with a name beginning with<br> "action." and followed by the name of the action. Macro files are<br> defined in a file with a name beginning with "macro.".<br><br> e) Actions may invoke other actions. Macros may not directly invoke<br> other macros although they may invoke other macros indirectly<br> through an action.<br><br> f) DNAT[-] and REDIRECT[-] rules may not appear in an action. They<br> are allowed in a macro with the restriction that the a macro<br> containing one of these rules may not be invoked from an action.<br><br> g) The values specified in the various columns when you invoke a<br> macro are substituted in the corresponding column in each rule in<br> the macro. The first three columns get special treatment:<br><br> ACTION If you code PARAM as the action in a macro then<br> when you invoke the macro, you can include the<br> name of the macro followed by a slash ("/") and<br> an ACTION (either built-in or user-defined. All<br> instances of PARAM in the body of the macro will be<br> replaced with the ACTION.<br><br> Any logging applied when the macro is invoked is<br> applied following the same rules as for actions.<br><br> SOURCE and<br> DEST If the rule in the macro file specifies a value and<br> the invocation of the rule also specifies a value then<br> the value in the invocation is appended to the value<br> in the rule using ":" as a separator.<br><br> Example:<br><br> /etc/shorewall/macro.SMTP<br><br> PARAM - loc tcp 25<br><br> /etc/shorewall/rules:<br><br> SMTP/DNAT:info net 192.168.1.5<br><br> Would be equivalent to the following in the rules file:<br><br> DNAT:info net loc:192.168.1.5 tcp 25<br><br> Rest Any value in the invocation replaces the value in the<br> rule in the macro.<br><br> One additional restriction applies to the mixing of macros and<br> actions. Macros that are invoked from actions cannot themselves<br> invoke other actions.<
<span style="font-weight: bold;">10/31/2005
Shorewall 2.4.6<br>
<br>
</span>Problems Corrected in 2.4.6<br>
<ol>
<li>"shorewall refresh" would fail if there were entries in
/etc/shorewall/tcrules with non-empty USER/GROUP or TEST columns.</li>
<li>An unprintable character in a comment caused /sbin/shorewall to
fail when used with a light-weight shell like 'dash'.</li>
<li>When using some flavors of 'ash', certain /sbin/shorewall
commands produced 'ipset: not found' messages.</li>
<li>Support for OpenVPN TCP tunnels was released in Shorewall 2.2.0
but the implementation was incomplete. It has now been completed and is
documented in the /etc/shorewall/tunnels file.</li>
<li>The test that Shorewall uses to detect the availability of the
owner match capability has been changed to avoid the generation of
ipt_owner messages under kernel 2.6.14.</li>
</ol>
New Features in 2.4.6<br>
<ol>
<li>Normally MAC verification triggered by the 'maclist' interface
and host options is done out of the INPUT and FORWARD chains of the
filter table. Users have reported that under some circulstances, MAC
verification is failing for forwarded packets when the packets are
being forwarded out of a bridge.<br>
<br>
To work around this problem, a MACLIST_TABLE option has been added to
shorewall.conf. The default value is MACLIST_TABLE=filter which results
in the current behavior. If MACLIST_TABLE=mangle then filtering will
take place out of the PREROUTING chain of the mangle table. Because the
REJECT target may not be used in the PREROUTING chain, the settings
MACLIST_DISPOSITION=REJECT and MACLIST_TABLE=mangle are incompatible.</li>
<li>A "dump" command has been added to /sbin/shorewall for
compatibility with Shorewall 3.0. In 2.4.6, the "dump" command provides
the same output as the "status".<br>
</li>
</ol>
<span style="font-weight: bold;">Old News <a href="oldnews.html">here</a><br>
</span>
</body>
</html>