forked from extern/shorewall_code
b235cd19e1
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@690 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
129 lines
4.9 KiB
Plaintext
Executable File
129 lines
4.9 KiB
Plaintext
Executable File
This is a minor release of Shorewall.
|
|
|
|
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.
|
|
|