forked from extern/shorewall_code
42ee8d0c19
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2493 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
346 lines
13 KiB
Plaintext
Executable File
346 lines
13 KiB
Plaintext
Executable File
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.*
|
|
|
|
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).
|
|
|
|
9) Shorewall not generates an error if the 'norfc1918' option is
|
|
specified for an interface with an RFC 1918 address.
|
|
|
|
10) You may now specify "!" followed by a list of addresses in the
|
|
SOURCE and DEST columns of entries in /etc/shorewall/rules and
|
|
Shorewall will generate the rule that you expect.
|
|
|
|
Example:
|
|
|
|
#ACTION SOURCE DEST PROTO DEST PORT(S)
|
|
ACCEPT loc:!192.168.1.0/24,10.0.0.0/8 net tcp 80
|
|
|
|
That rule would allow loc->net HTTP access except for the local
|
|
networks 192.168.1.0/24 and 10.0.0.0/8.
|