http://shorewall.net/pub/shorewall/Snapshots
ftp://shorewall.net/pub/shorewall/Snapshots
Problems Corrected since version 1.4.6:
1) Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was
being tested before it was set.
2) Corrected handling of MAC addresses in the SOURCE column of the
tcrules file. Previously, these addresses resulted in an invalid
iptables command.
3) 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.
4) 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.
The firewall script has been modified to eliminate the error
messages.
Migration Issues:
1) Once you have installed this version of Shorewall, you must
restart Shorewall before you may use the ''drop'',
''reject'', ''allow''
or ''save'' commands.
2) To maintain strict compatibility with previous versions, current
uses of "shorewall drop" and "shorewall reject" should be
replaced
with "shorewall dropall" and "shorewall rejectall".
New Features:
1) 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).
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.
2) Thanks to Steve Herber, the help command can now give
command-specific help.
3) A new option "ADMINISABSENTMINDED" has been added to
/etc/shorewall/shorewall.conf. This option has a default value of
"No" for existing Shorewall users who are upgrading to this
release.
With this setting, Shorewall''s ''stopped'' state
continues as it has
been; namely, in the stopped state only traffic to/from hosts listed
in /etc/shorewall/routestopped is accepted.
The default for new users installing Shorewall for the first time is
ADMINISABSENTMINDED=Yes.With that setting, in addition to traffic
to/from the hosts listed in /etc/shorewall/routestopped, Shorewall
will allow:
a) All traffic originating from the firewall itself; and
b) All traffic that is part of or related to an already-existing
connection.
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
entered through an ssh session will not kill the session.
Note though that it is still possible for people to shoot themselves
in the foot.
Example:
/etc/shorewall/nat:
206.124.146.178 eth0:0 192.168.1.5
/etc/shorewall/rules:
ACCEPT net loc:192.168.1.5 tcp 22
ACCEPT loc fw tcp 22
I ssh into 206.124.146.178 which establishes an SSH connection with
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 stopping, Shorewall removes eth0:0 which kills my
SSH connection to 192.168.1.5!!!
4) 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.
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
implement your security policy regarding traffic to/from those
systems.
In the /etc/shorewall/tunnels file, you can have entries of the
form:
# TYPE ZONE GATEWAY GATEWAY ZONE
generic:<protocol>[:<port>] <zone> <ip address>
<gateway zones>
where:
<protocol> is the protocol used by the tunnel
<port> if the protocol is ''udp'' or
''tcp'' then this
is the destination port number used by the
tunnel.
<zone> is the zone of the remote tunnel gateway
<ip address> is the IP address of the remote tunnel
gateway.
<gateway zone> Optional. A comma-separated list of zone names.
If specified, the remote gateway is to be
considered part of these zones.
5) 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 of 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.
-Tom
--
Tom Eastep \ Shorewall - iptables made easy
Shoreline, \ http://shorewall.net
Washington USA \ teastep@shorewall.net