holm/shorewall_code
1
0
Fork 0
forked from extern/shorewall_code
Code Pull Requests Activity
ea1bf1a7c8
shorewall_code/Shorewall/releasenotes.txt

331 lines
12 KiB
Plaintext
Executable File
Raw Blame History

Shorewall 2.5.1
Problems Corrected in 2.5.1:
1) Shorewall is no longer dependent on the 'which' utility.
2) "shorewall add" no longer fails when the 'ipsec' option has appeared
in /etc/shorewall/hosts.
3) The Makefile has been changed to compare the modification times of
the files in /etc/shorewall with
/var/lib/shorewall/restore-base. That file is modified each time
that Shorewall is [re]started whereas /var/lib/shorewall/restarted
is also modified by "shorewall reset" and "shorewall refresh".
4) The handling of log levels passed to macros has been
corrected. Previously, passing a log level to a macro resulted in a
[re]start error.
Problems Corrected in 2.5.0:
1) The behavior of CONTINUE policies has been improved. Shorewall no
longer generates a useless policy chain corresponding to these
policies.
2) The combining of the zones and ipsec files has now been made upward
compatible provided that the user doesn't do something idiotic such
as install the new shorewall.conf file then manually update it
with exactly the changes that had been applied to the old file.
Migration Considerations:
1) The "monitor" command has been eliminated.
2) The "DISPLAY" and "COMMENTS" columns in the /etc/shorewall/zones
file have been removed and have been replaced by the former
columns of the /etc/shorewall/ipsec file. The latter file has been
removed.
Adhering to the principle of least astonishment, the old
/etc/shorewall/ipsec file will continue to be supported. A new
IPSECFILE variable in /etc/shorewall/shorewall.conf determines the
name of the file that Shorewall looks in for IPSEC information. If
that variable is not set or is set to the empty value then
IPSECFILE=ipsec is assumed. So if you simply upgrade and don't do
something idiotic like replace your current shorewall.conf file with
the new one, your old configuration will continue to work. A dummy
'ipsec' file is included in the release so that your package manager
(e.g., rpm) won't remove your existing file.
The shorewall.conf file included in this release sets
IPSECFILE=zones so that new users are expected to use the new zone
file format.
As a result, the columns in the /etc/shorewall/zones file
are now as follows:
ZONE Short name of the zone (5 Characters or less in
length).
The names "all" and "none" are reserved and may
not beused as zone names.
IPSEC Yes -- Communication with all zone hosts is
ONLY encrypted. Your kernel and iptables
must include policy match support.
No -- Communication with some zone hosts may
be encrypted. Encrypted hosts are
designated using the 'ipsec' option in
/etc/shorewall/hosts.
OPTIONS, A comma-separated list of options as
IN OPTIONS, follows:
OUT OPTIONS
reqid=<number> where <number> is
specified using setkey(8) using the
'unique:<number> option for the SPD
level.
spi=<number> where <number> is the SPI
of the SA used to encrypt/decrypt
packets.
proto=ah|esp|ipcomp
mss=<number> (sets the MSS field in TCP
packets)
mode=transport|tunnel
tunnel-src=<address>[/<mask>] (only
available with mode=tunnel)
tunnel-dst=<address>[/<mask>] (only
available with mode=tunnel)
strict Means that packets must match
all rules.
next Separates rules; can only be
used with strict..
Example:
mode=transport,reqid=44
The options in the OPTIONS column are applied to both
incoming and outgoing traffic. The IN OPTIONS are
applied to incoming traffic (in addition to OPTIONS)
and the OUT OPTIONS are applied to outgoing traffic.
If you wish to leave a column empty but need to make an
entry in a following column, use "-".
THE ORDER OF THE ENTRIES IN THIS FILE IS IMPORTANT IF YOU HAVE
NESTED OR OVERLAPPING ZONES DEFINED THROUGH /etc/shorewall/hosts.
3) The DROPINVALID option has been removed from shorewall.conf. The
behavior will be as if DROPINVALID=No had been specified. If you
wish to drop invalid state packets, use the dropInvalid built-in
action.
4) The 'nobogons' interface and hosts option as well as the
BOGON_LOG_LEVEL option have been eliminated.
5) Most of the standard actions have been replaced by parameterized
macros (see below). So for example, the action.AllowSMTP and
action.DropSMTP have been removed an a parameterized macro
macro.SMTP has been added to replace them.
In order that current users don't have to immediately update their
rules and user-defined actions, Shorewall can substitute an
invocation of the a new macro for an existing invocation of one of
the old actions. So if your rules file calls AllowSMTP, Shorewall
will replace that call with SMTP/ACCEPT. Because this substitution
is expensive, it is conditional based on the setting of
MAPOLDACTIONS in shorewall.conf. If this option is set to YES or if
it is not set (such as if you are using your old shorewall.conf
file) then Shorewall will perform the substitution. Once you have
converted to use the new macros, you can set MAPOLDACTIONS=No and
invocations of those actions will go much quicker during 'shorewall
[re]start'.
6) The STATEDIR variable in /etc/shorewall/shorewall.conf has been
removed. STATEDIR is now fixed at /var/lib/shorewall. If you have
previously set STATEDIR to another directory, please copy the files
from that directory to /var/lib/shorewall/ before [re]starting
Shorewall after the upgrade to this version.
7) The "shorewall status" command now just gives the status of
Shorewall (started or not-started). The previous status command has
been renamed "dump". The command also shows the state relative to the
state diagram at
http://shorewall.net/starting_and_stopping_shorewall.htm. In
addition to the state, the time and date at which that state was
entered is shown.
Note that at least one "shorewall [re]start" must be issued after
upgrading to this release before "shorewall status" will show
anything but "Unknown" for the state.
8) The "shorewall forget" command now removes the dynamic blacklist
save file (/var/lib/shorewall/save).
New Features in Shorewall 2.5.0
1) Error and warning messages are made easier to spot by using
capitalization (e.g., ERROR: and WARNING:).
2) Beginning with this version, the POLICY column in
/etc/shorewall/policy can potentially contain two policies separated
by ":". The first policy is the policy for new connections (the only
policy that you can currently configure). The second policy is for
ESTABLISHED packets (those that are part of an established
connection) and must be either ACCEPT (the default) or QUEUE. So if
the policy column contains DROP:QUEUE then new connection requests
are dropped by default but packets that are part of an established
connection are sent to the QUEUE target. RELATED state packets are
always ACCEPTED so that ICMPs (which are almost always RELATED)
won't go through QUEUE.
3) A new option 'critical' has been added to
/etc/shorewall/routestopped. This option can be used to enable
communication with a host or set of hosts during the entire
"shorewall [re]start/stop" process. Listing a host with this option
differs from listing it without the option in several ways:
a) The option only affect traffic between the listed host(s) and the
firewall itself.
b) If there are any entries with 'critical', the firewall
will be completely opened briefly during start, restart and stop but
there will be no chance of any packets to/from the listed host(s)
being dropped or rejected.
Possible uses for this option are:
a) Root fileset is NFS mounted. You will want to list the NFS server
in the 'critical' option.
b) You are running Shorewall in a Crossbeam environment
(www.crossbeam.com). You will want to list the Crossbeam interface
in this option
4) A new 'macro' feature has been added.
Macros are very similar to actions and can be used in similar
ways. The differences between actions and macros are as follows:
a) An action creates a separate chain with the same name as the
action (when logging is specified on the invocation of an action,
a chain beginning with "%" followed by the name of the action and
possibly followed by a number is created). When a macro is
invoked, it is expanded in-line and no new chain is created.
b) An action may be specified as the default action for a policy;
macros cannot be specified this way.
c) Actions must be listed in either /usr/share/shorewall/actions.std
or in /etc/shorewall/actions. Macros are defined simply by
placing their definition file in the CONFIG_PATH.
d) Actions are defined in a file with a name beginning with
"action." and followed by the name of the action. Macro files are
defined in a file with a name beginning with "macro.".
e) Actions may invoke other actions. Macros may not directly invoke
other macros although they may invoke other macros indirectly
through an action.
f) DNAT[-] and REDIRECT[-] rules may not appear in an action. They
are allowed in a macro with the restriction that the a macro
containing one of these rules may not be invoked from an action.
g) The values specified in the various columns when you invoke a
macro are substituted in the corresponding column in each rule in
the macro. The first three columns get special treatment:
TARGET If you code PARAM as the target in a macro then
when you invoke the macro, you can include the
name of the macro followed by a slash ("/") and
an ACTION (either builtin or user-defined. All
instances of PARAM in the body of the macro will be
replaced with the ACTION.
Any logging applied when the action is invoked is
applied following the same rules as for actions.
SOURCE and
DEST If the rule in the macro file specifies a value and
the invocation of the rule also specifies a value then
the value in the invocation is appended to the value
in the rule using ":" as a separator.
Example:
/etc/shorewall/macro.SMTP
PARAM - loc tcp 25
/etc/shorewall/rules:
SMTP/DNAT:info net 192.168.1.5
Would be equivalent to the following in the rules file:
DNAT:info net loc:192.168.1.5 tcp 25
Rest Any value in the invocation replaces the value in the
rule in the macro.
One additional restriction applies to the mixing of macros and
actions. Macros that are invoked from actions cannot themselves
invoke other actions.
5) If you have 'make' installed on your firewall, then when you use
the '-f' option to 'shorewall start' (as happens when you reboot),
if your /etc/shorewall/ directory contains files that were modified
after Shorewall was last restarted then Shorewall is started using
the config files rather than using the saved configuration.
6) The 'arp_ignore' option has been added to /etc/shorewall/interfaces
entries. This option sets
/proc/sys/net/ipv4/conf/<interface>/arp_ignore. By default, the
option sets the value to 1. You can also write arp_ignore=<value>
where value is one of the following:
1 - reply only if the target IP address is local address
configured on the incoming interface
2 - reply only if the target IP address is local address
configured on the incoming interface and both with the sender's
IP address are part from same subnet on this interface
3 - do not reply for local addresses configured with scope
host, only resolutions for global and link addresses are
replied
4-7 - reserved
8 - do not reply for all local addresses
WARNING -- DO NOT SPECIFY arp_ignore FOR ANY INTERFACE INVOLVED IN
PROXY ARP.
7) In /etc/shorewall/rules, "all+" in the SOURCE or DEST column works
like "all" but also includes intrazone traffic. So the rule:
ACCEPT loc all+ tcp 22
would allow SSH traffic from loc->loc whereas
ACCEPT loc all tcp 22
does not.
8) A new FASTACCEPT option has been added to shorewall.conf.
Normally, Shorewall accepting ESTABLISHED/RELATED packets until
these packets reach the chain in which the original connection was
accepted. So for packets going from the 'loc' zone to the 'net'
zone, ESTABLISHED/RELATED packets are ACCEPTED in the 'loc2net'
chain.
If you set FASTACCEPT=Yes, then ESTABLISHED/RELEATED packets are
accepted early in the INPUT, FORWARD and OUTPUT chains. If you set
FASTACCEPT=Yes then you may not specify ESTABLISHED policies in
/etc/shorewall/policy (see above).
View Git Blame Copy Permalink