http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.4
ftp://shorewall.net/pub/shorewall/2.2/shorewall-2.2.4
Problems Corrected:
1. The error message:
Error: No appropriate chain for zone <z1> to zone <z2>
has been changed to one that is more self-explanatory:
Error: No policy defined for zone <z1> to zone <z2>
2. 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:
Error: Invalid HOST(S) column contents: <column contents>
New Features:
1. Support has been added for UPnP using linux-igd
(http://linux-idg.sourceforge.net). UPnP is required by a number of
popular applications including MSN IM.
WARNING:
From a security architecture viewpoint, UPnP is a disaster. It
assumes that:
1. All local systems and their users are completely trustworthy.
2. No local system is infected with any worm or trojan.
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.
In short: USE UPnP AT YOUR OWN RISK.
WARNING:
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.
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).
Configuring linux-igd:
In /etc/upnpd.conf, you will want:
insert_forward_rules = yes
prerouting_chain_name = UPnP
forward_chain_name = forwardUPnP
Shorewall Configuration:
In /etc/shorewall/interfaces, you need the ''upnp'' option on
your
external interface.
If your fw->loc policy is not ACCEPT then you need this rule:
allowoutUPnP fw loc
Note: To use ''allowoutUPnP'', your iptables and kernel must
support the ''owner match'' feature (see the output of
"shorewall
check").
If your loc->fw policy is not ACCEPT then you need this rule:
allowinUPnP loc fw
You MUST have this rule:
forwardUPnP net loc
You must also ensure that you have a route to 224.0.0.0/4 on you
internal (local) interface.
2. 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.
/etc/shorewall/started should not change the firewall
configuration directly but may do so indirectly by running
/sbin/shorewall with the ''nolock'' option.
3. 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.
Example: If you want Shorewall to always use the config files even
if there is a saved configuration, then specify:
OPTIONS=""
4. Shorewall now has support for the SAME target. This change affects
the /etc/shorewall/masq and /etc/shorewall/rules file.
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).
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:"
Example: SAME:206.124.146.176-206.124.146.180
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:".
Example: SAME:nodst:206.124.146.176-206.124.146.180
Note that it is not possible to map port numbers when using SAME.
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.
5. A "shorewall show capabilities" command has been added to report
the capabilities of your kernel and iptables.
Example:
gateway:~# shorewall show capabilities
Loading /usr/share/shorewall/functions...
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf...
Loading Modules...
Shorewall has detected the following iptables/netfilter
capabilities:
NAT: Available
Packet Mangling: Available
Multi-port Match: Available
Extended Multi-port Match: Available
Connection Tracking Match: Available
Packet Type Match: Not available
Policy Match: Available
Physdev Match: Available
IP range Match: Available
Recent Match: Available
Owner Match: Available
gateway:~#
6. 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.
7. 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:
Example:
/etc/shorewall/rules:
AllowFTP $FTP_CLIENTS fw
When FTP_CLIENTS is set to ''none'', the above rule is ignored.
Otherwise, the rule is evaluated and generates Netfilter rules.
8. The installer now detects that it is running on a Slackware system
and adjusts the DEST and INIT variables accordingly.
-Tom
--
Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://shorewall.net
Washington USA \ teastep@shorewall.net
PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key