mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-15 04:04:10 +01:00
c334e92103
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@783 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
105 lines
4.1 KiB
Plaintext
Executable File
105 lines
4.1 KiB
Plaintext
Executable File
This is a minor release of Shorewall.
|
|
|
|
Problems Corrected since version 1.4.7:
|
|
|
|
1) Tuomo Soini has supplied a correction to a problem that occurs using
|
|
some versions of 'ash'. The symptom is that "shorewall start" fails
|
|
with:
|
|
|
|
local: --limit: bad variable name
|
|
iptables v1.2.8: Couldn't load match `-j':/lib/iptables/libipt_-j.so:
|
|
cannot open shared object file: No such file or directory
|
|
Try `iptables -h' or 'iptables --help' for more information.
|
|
|
|
2) Andres Zhoglo has supplied a correction that avoids trying to use
|
|
the multiport match iptables facility on ICMP rules.
|
|
|
|
Example of rule that previously caused "shorewall start" to fail:
|
|
|
|
ACCEPT loc $FW icmp 0,8,11,12
|
|
|
|
3) Previously, if the following error message was issued, Shorewall
|
|
was left in an inconsistent state.
|
|
|
|
Error: Unable to determine the routes through interface xxx
|
|
|
|
4) Handling of the LOGUNCLEAN option in shorewall.conf has been
|
|
corrected.
|
|
|
|
5) 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.
|
|
|
|
6) 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.
|
|
|
|
7) The original fix for item 5) above contained a bug which caused the
|
|
"<zone>_frwd" chain to have too few rules. That has been corrected
|
|
(twice).
|
|
|
|
8) An incorrect comment concerning Debian's use of the SYBSYSLOCK
|
|
option has been removed from shorewall.conf.
|
|
|
|
9) Previously, neither the 'routefilter' interface option nor the
|
|
ROUTE_FILTER parameter were working properly. This has been
|
|
corrected (thanks to Eric Bowles for his 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.
|
|
|
|
10) If MAC verification was enabled on an interface that had a /32
|
|
address with a broadcast address then an error would occur during
|
|
startup.
|
|
|
|
Migration Issues:
|
|
|
|
1. The definition of the ROUTE_FILTER option in shorewall.conf has
|
|
changed as described in item 9) above.
|
|
|
|
New Features:
|
|
|
|
1. 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 your 'loc' zone,
|
|
you would add the following rules:
|
|
|
|
QUEUE loc net tcp
|
|
QUEUE loc net udp
|
|
QUEUE loc fw udp
|
|
|
|
You would normally want to place those three rules BEFORE any ACCEPT
|
|
rules for loc->net or loc->fw udp or tcp.
|
|
|
|
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.
|
|
|
|
2. 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.
|
|
|
|
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.
|
|
|
|
3. Chain names used in the /etc/shorewall/accounting file may now begin
|
|
with a digit ([0-9]) and may contain embedded dashes ("-").
|
|
|
|
|
|
|
|
|