forked from extern/shorewall_code
Update release documentation for 3.1.0
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3247 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
parent
20489c736b
commit
183c4287ae
@ -1,268 +1,5 @@
|
||||
Changes in 3.0.4
|
||||
Changes in 3.1.0
|
||||
|
||||
1) Console-friendly version of shorewall.conf.
|
||||
1) Removal of dynamic zones.
|
||||
|
||||
2) Add 'Limit' as a standard action.
|
||||
|
||||
3) Enabled loopback traffic under the DISABLE_IPV6 option.
|
||||
|
||||
4) Close hole in bridged configurations.
|
||||
|
||||
5) Fix bug in NONE intra-zone policy handling.
|
||||
|
||||
6) Fix bug in RETAIN_ALIASES=Yes.
|
||||
|
||||
7) Wildcard port support.
|
||||
|
||||
8) Fix logging of old mapped standard actions.
|
||||
|
||||
Changes in 3.0.3
|
||||
|
||||
1) Implement "shorewall show macros"
|
||||
|
||||
2) Comments regarding bridge configuration were improved.
|
||||
|
||||
3) Applied Tuomo Soini's patch to pretty up the tc4shorewall files.
|
||||
|
||||
4) Fix 'safe-start' and 'safe'restart' -- add support for -q in the process.
|
||||
|
||||
5) Fix help text for restore. Add -q to help for safe-start and safe-restart.
|
||||
|
||||
6) Add more migration information to release notes.
|
||||
|
||||
7) Allow "-" in the ADDRESS/SUBNET column of the blacklist file.
|
||||
|
||||
8) Add traffic shaping information to "dump" output.
|
||||
|
||||
9) Allow 'none' in the COPY column of /etc/shorewall/providers.
|
||||
|
||||
10) Implement 'ipdecimal' command.
|
||||
|
||||
11) Implement 'reload' in the init script.
|
||||
|
||||
12) Correct README.txt
|
||||
|
||||
13) Add upgrade considerations for 2.0 users to release notes.
|
||||
|
||||
14) Change default for CLEAR_TC to "Yes".
|
||||
|
||||
15) Added warning to the zones file.
|
||||
|
||||
16) Fixed bug in tcrules processing (interface name in SOURCE column).
|
||||
|
||||
17) Create /var/log/shorewall-init.log when installing on Debian.
|
||||
|
||||
Changes in 3.0.2
|
||||
|
||||
1) Typos in the Samples corrected.
|
||||
|
||||
2) Incompatibility with old kernels worked around.
|
||||
|
||||
3) Added new Webmin macro
|
||||
|
||||
4) Arch Linux installation routines improved
|
||||
|
||||
Changes in 3.0.1
|
||||
|
||||
1) Set policies for chains in nat, mangle and raw tables.
|
||||
|
||||
2) Applied Tuomo's patch for Makefile.
|
||||
|
||||
3) Add Farkas ordering to generated SOURCE and DEST column when expanding
|
||||
macros.
|
||||
|
||||
4) Clarify PORTS column in blacklist file.
|
||||
|
||||
5) Correct CLAMPMSS/FASTACCEPT interaction.
|
||||
|
||||
Changes in 3.0.0 Final
|
||||
|
||||
None.
|
||||
|
||||
Changes in 3.0.0 RC 3.
|
||||
|
||||
1) ROUTE target and Extended Mark removed from capabilities.
|
||||
|
||||
2) Suppress 'ambiguous redirect' error messages.
|
||||
|
||||
3) Correct stupid typo in release notes ([rej|drop]NewNot vs. [rej|drop]NewNon).
|
||||
|
||||
4) Stop whining about ipt_owner messages under kernel 2.6.14.
|
||||
|
||||
5) Update config files with cmd-owner info.
|
||||
|
||||
6) Fix DHCP with MACLIST_TABLE=mangle.
|
||||
|
||||
7) Remove Slackware special case from INSTALL instructions.
|
||||
|
||||
Changes in 3.0.0 RC 2.
|
||||
|
||||
1) Fix support for OpenVPN and tcp.
|
||||
|
||||
2) Correct cut-and-paste error in 'arp_ignore' processing.
|
||||
|
||||
3) Add 'src' to gateway routes. Make 'find_first_interface_address' look for
|
||||
global addresses only.
|
||||
|
||||
4) Update /etc/shorewall/interfaces to describe multiple interfaces to a zone.
|
||||
|
||||
Changes in 3.0.0 RC 1.
|
||||
|
||||
1) Correct spelling of MACLIST_TABLE in shorewall.conf.
|
||||
|
||||
Changes in 3.0.0 Beta 1.
|
||||
|
||||
1) Add TC_ENABLED=Internal
|
||||
|
||||
2) Fix default tc class bug.
|
||||
|
||||
Changes in 2.5.8
|
||||
|
||||
1) Fix 'shorewall refresh' with long tcrules entries.
|
||||
|
||||
2) Implement MACLIST_TABLE.
|
||||
|
||||
3) Make tc class ids unique between devices.
|
||||
|
||||
Changes in 2.5.7
|
||||
|
||||
1) Fix ADMINISABSENTMINDED=Yes vs. entries in /etc/shorewall/routestopped.
|
||||
|
||||
2) Fix traffic shaping and "shorewall refresh"
|
||||
|
||||
3) Add capabilities report to "shorewall dump".
|
||||
|
||||
4) Rename 'plain' to 'ipv4'
|
||||
|
||||
5) Deimplement NEWNOTSYN
|
||||
|
||||
6) Fix logging IPP2P rules.
|
||||
|
||||
7) Add zone type to /var/lib/shorewall/zones.
|
||||
|
||||
8) Give better diagnostics when IPP2P match isn't available.
|
||||
|
||||
9) Do not touch mangle chain during "refresh".
|
||||
|
||||
10) Implement support for UDP IPP2P Matching.
|
||||
|
||||
Changes in 2.5.6
|
||||
|
||||
1) Finish install/fallback cleanup.
|
||||
|
||||
2) Fix startup failure.
|
||||
|
||||
3) Add "-n" option.
|
||||
|
||||
Changes in 2.5.5
|
||||
|
||||
1) Zone file alchemy attempted.
|
||||
|
||||
2) Fix install.sh re: Makefile
|
||||
|
||||
3) Fix error handling.
|
||||
|
||||
4) Add SHOREWALL_LIBRARY function.
|
||||
|
||||
Changes in 2.5.4
|
||||
|
||||
1) Allow TAG to be used as a general parameter mechanism [hack].
|
||||
|
||||
2) Fix some ghastly bugs in macros.
|
||||
|
||||
3) "shorewall check" now checks the masq file.
|
||||
|
||||
4) "shorewall check" now checks the proxyarp file.
|
||||
|
||||
5) "shorewall check" now checks the nat file.
|
||||
|
||||
6) "shorewall check" now checks the providers file.
|
||||
|
||||
7) Merge 'tc4shorewall'
|
||||
|
||||
8) Modify tc4shorewall so that it plays well with Shorewall
|
||||
save/restore.
|
||||
|
||||
Changes in 2.5.3
|
||||
|
||||
1) Allow exclusion lists in /etc/shorewall/tcrules.
|
||||
|
||||
2) Added 'openvpnserver' and 'openvpnclient' tunnel types.
|
||||
|
||||
3) Set COMMAND=restore in restore-base.
|
||||
|
||||
4) Allow exclusion lists in actions.
|
||||
|
||||
5) Make intra-zone policies more rational.
|
||||
|
||||
6) Clear the raw table on stop and [re]start
|
||||
|
||||
7) Section the rules file.
|
||||
|
||||
8) Fixed tunnels/rules interaction problems.
|
||||
|
||||
9) Provide hack for passing arguments to action extension scripts.
|
||||
|
||||
Changes in 2.5.2
|
||||
|
||||
1) Allow port lists in /etc/shorewall/accounting.
|
||||
|
||||
2) Fix PKTTYPE=No and packet type match capability reporting.
|
||||
|
||||
3) Add FASTACCEPT option.
|
||||
|
||||
4) Generate error if norfc1918 is specified on an interface with an RFC
|
||||
1918 IP address.
|
||||
|
||||
5) Implement exclusion lists in /etc/shorewall/rules.
|
||||
|
||||
Changes in 2.5.1
|
||||
|
||||
1) Make "shorewall add" work with 'ipsec' in hosts file.
|
||||
|
||||
2) Remove dependence on 'which'
|
||||
|
||||
3) Rename "status" to "dump" and add real status command.
|
||||
|
||||
4) Fix Makefile (compare to restore-base rather than restarted).
|
||||
|
||||
5) Add "all+"
|
||||
|
||||
6) Don't generate redundant ACCEPT rules for DNAT/REDIRECT/SAME
|
||||
|
||||
7) Add FASTACCEPT option in shorewall.conf.
|
||||
|
||||
8) Generate error for 'norfc1918' on an interface with an RFC 1918 IP
|
||||
address.
|
||||
|
||||
9) Finally implement exclude lists in rules.
|
||||
|
||||
Changes in 2.5.1ex/2.5.0
|
||||
|
||||
1) Clean up handling of zones
|
||||
|
||||
2) Make the removal of the ipsec file upward compatible.
|
||||
|
||||
3) Improve CONTINUE policy handling.
|
||||
|
||||
4) Implement arp_ignore support.
|
||||
|
||||
Changes in 2.5.0ex
|
||||
|
||||
1) Make warning and error messages easier to find by using
|
||||
capitalization.
|
||||
|
||||
2) Remove /etc/shorewall/ipsec and merge it's function with
|
||||
/etc/shorewall/zones.
|
||||
|
||||
3) Apply small fix to the above patch.
|
||||
|
||||
4) Remove dynamic zone support.
|
||||
|
||||
5) Add "established policy" support.
|
||||
|
||||
6) Add CRITICALHOSTS support.
|
||||
|
||||
7) Remove 'bogon' stuff.
|
||||
|
||||
8) Implement Macros.
|
||||
2) Implement 'generate' command.
|
||||
|
@ -1,6 +1,6 @@
|
||||
Shorewall 3.0.4
|
||||
Shorewall 3.1.0
|
||||
|
||||
Note to users upgrading from Shorewall 2.x
|
||||
Note to users upgrading from Shorewall 2.x or 3.0
|
||||
|
||||
Most problems associated with upgrades come from two causes:
|
||||
|
||||
@ -15,26 +15,6 @@ Note to users upgrading from Shorewall 2.x
|
||||
comments and options in your shorewall.conf then you must proceed
|
||||
carefully.
|
||||
|
||||
The new/changed options in shorewall 3.0 are listed below. If you don't
|
||||
want to convert to the new 3.0 format for /etc/shorewall/zones and you
|
||||
don't want to replace your current rules that use 2.x builtin actions,
|
||||
then if you plan to use the 3.0 shorewall.conf file then you must change
|
||||
it as follows:
|
||||
|
||||
- SPECFILE The 3.0 shorewall.conf file has IPSECFILE=zones. You want to
|
||||
set it to IPSECFILE=ipsec. This will indicate that your
|
||||
/etc/shorewall/zones file is in the pre-3.0 format.
|
||||
|
||||
- FW The 3.0 shorewall.conf file has FW undefined. If you have
|
||||
named your firewall zone something other than 'fw' then you
|
||||
must set FW accordingly.
|
||||
|
||||
- MAPOLDACTIONS
|
||||
|
||||
The 3.0 shorewall.conf file has MAPOLDACTIONS=No. You want to
|
||||
set it to MAPOLDACTIONS=Yes in order to permit rules that use
|
||||
the 2.x builtin actions such as AllowPing to continue to work.
|
||||
|
||||
While you are at it, if you have a file named /etc/shorewall/rfc1918 then
|
||||
please check that file. If it has addresses listed that are NOT in one of
|
||||
these three ranges, then please rename the file to /etc/shorewall/rfc1918.old.
|
||||
@ -46,772 +26,66 @@ Note to users upgrading from Shorewall 2.x
|
||||
Please see the "Migration Considerations" below for additional upgrade
|
||||
information.
|
||||
|
||||
Problems Corrected in 3.0.4
|
||||
Problems corrected in 3.1.0
|
||||
|
||||
1) The shorewall.conf file is once again "console friendly". Patch is
|
||||
courtesy of Tuomo Soini.
|
||||
1) If /etc/shorewall/ipsets exists, it is processed during [re]start but not
|
||||
during 'shorewall restore'.
|
||||
|
||||
2) A potential security hole has been closed. Previously, Shorewall ACCEPTed
|
||||
all traffic from a bridge port that was sent back out on the same port. If
|
||||
the port was described in /etc/shorewall/hosts using the wildcard "+" (eg,
|
||||
xenbr0:vif+), this could lead to traffic being passed in variance with the
|
||||
supplied policies and rules.
|
||||
Migration Considerations:
|
||||
|
||||
3) Previously, an intra-zone policy of NONE would cause a startup error. That
|
||||
problem has been corrected.
|
||||
1) The dynamic zone capability has been removed from Shorewall. Based on when
|
||||
ipsets are made a standard part of the Linux kernels from kernel.org, dynamic
|
||||
zones may be restored prior to the release of Shorewall 3.2.
|
||||
|
||||
4) When RETAIN_ALIASES=Yes, the script produced by "shorewall save" did not
|
||||
add the retained aliases. This means that the following sequence of
|
||||
events resulted in missing aliases:
|
||||
New Features:
|
||||
|
||||
shorewall start
|
||||
shorewall restart
|
||||
shorewall save
|
||||
reboot
|
||||
shorewall -f start (which is the default during boot up)
|
||||
1) A new 'shorewall generate' command has been added.
|
||||
|
||||
5) When a 2.x standard action is invoked with a log level (example
|
||||
"AllowPing:info"), logging does not occur.
|
||||
shorewall [ -q ] generate [ <config directory> ] <script file>
|
||||
|
||||
New Features in 3.0.4
|
||||
where:
|
||||
|
||||
1) By popular demand, the 'Limit' action described at
|
||||
http://www1.shorewall.net/PortKnocking.html#Limit has been made a standard
|
||||
action. Limit requires 'recent match' support in your kernel and iptables.
|
||||
-q Suppresses many of the progress messages
|
||||
<config directory> Is an optional directory to be searched for
|
||||
configuration files prior to those listed
|
||||
in CONFIG_DIR in /etc/shorewall/shorewall.conf.
|
||||
<script file> Is the name of the output file. If a simple
|
||||
filename is given, the file will be created in
|
||||
/var/lib/shorewall.
|
||||
|
||||
2) DISABLE_IPV6 no longer disabled local (loopback) IPV6 traffic. This
|
||||
change is reported to improve Java startup time on some distributions.
|
||||
The 'generate' command processes the configuration and writes a script file
|
||||
which may then be executed (either directly or using the 'shorewall restore'
|
||||
command) to configure the firewall.
|
||||
|
||||
3) Shorewall now contains support for wildcard ports. In /etc/shorewall/hosts,
|
||||
you may specify the port name with trailing "+" then use specific port names
|
||||
in rules.
|
||||
WARNING: The generated script HAS ABSOLUTELY NO ERROR CHECKING so if there
|
||||
are errors in your configuration files that result in errors when
|
||||
the script is run then you may not be able to access your firewall
|
||||
or your firewall may have security holes.
|
||||
|
||||
Example:
|
||||
Given the above warning, I recommend that you use 'generate' when making
|
||||
simple changes to your configuration but that you continue to use 'restart'
|
||||
for complex changes.
|
||||
|
||||
/etc/shorewall/hosts
|
||||
Some additional considerations:
|
||||
|
||||
vpn br0:tap+
|
||||
a) All 'detect' operations are done at the time that the 'generate' command
|
||||
is run. So it is generally not possible to run 'generate' on one system
|
||||
then move the generated script to another system.
|
||||
|
||||
/etc/shorewall/hosts
|
||||
b) If you have extension scripts, they may need modification. The scripts
|
||||
will be run at generation time, rather than when the generated script
|
||||
is executed. The standard functions like 'run_iptables' and
|
||||
'log_rule_limit' will write the iptables command to the script file
|
||||
rather than executing the command. As always, you can check $COMMAND
|
||||
to determine which shorewall command is being executed.
|
||||
|
||||
DROP vpn:tap0 vpn:tap1 udp 9999
|
||||
In addition to 'generate', a 'shorewall reload' command has been added.
|
||||
|
||||
Migration Considerations for Users upgrading from Shorewall 2.x.
|
||||
shorewall [ -q ] reload [ <config directory>
|
||||
|
||||
1) The "monitor" command has been eliminated.
|
||||
where -q and <config directory> are as above.
|
||||
|
||||
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.
|
||||
|
||||
Additionally the FW option in shorewall.conf has been deprecated and
|
||||
is no longer set to 'fw' by default. New users are expected to
|
||||
define the firewall zone in /etc/shorewall/zones.
|
||||
|
||||
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 be used as zone names.
|
||||
|
||||
Where a zone is nested in one or more other
|
||||
zones, you may follow the (sub)zone name by ":"
|
||||
and a comma-separated list of the parent
|
||||
zones. The parent zones must have been defined
|
||||
in earlier records in this file.
|
||||
|
||||
Example:
|
||||
|
||||
#ZONE TYPE OPTIONS
|
||||
a ipv4
|
||||
b ipv4
|
||||
c:a,b ipv4
|
||||
|
||||
Currently, Shorewall uses this information only
|
||||
to reorder the zone list so that parent zones
|
||||
appear after their sub zones in the list. In the
|
||||
future, Shorewall may make more extensive use
|
||||
of that information.
|
||||
|
||||
TYPE ipv4 - This is the standard Shorewall zone type and is
|
||||
the default if the column is left empty or if
|
||||
it is entered as "-". Communication with some
|
||||
zone hosts may be encrypted. Encrypted hosts
|
||||
are designated using the 'ipsec' option in
|
||||
/etc/shorewall/hosts.
|
||||
ipsec - Communication with all zone hosts is encrypted
|
||||
Your kernel and iptables must include policy
|
||||
match support.
|
||||
firewall
|
||||
- Designates the firewall itself. You must have
|
||||
exactly one 'firewall' zone. No options are
|
||||
permitted with a 'firewall' zone.
|
||||
|
||||
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 parametrized
|
||||
macros (see below). So for example, action.AllowSMTP and
|
||||
action.DropSMTP have been removed and a parametrized 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 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).
|
||||
|
||||
9) In previous versions of Shorewall, the rules generated by entries in
|
||||
/etc/shorewall/tunnels preceded those rules generated by entries in
|
||||
/etc/shorewall/rules. Beginning with this release, the rules
|
||||
generated by entries in the tunnels file will appear *AFTER* the
|
||||
rules generated by the rules file. This may cause you problems if
|
||||
you have REJECT, DENY or CONTINUE rules in your rules file that
|
||||
would cause the tunnel transport packets to not reach the rules that
|
||||
ACCEPT them. See http://www.shorewall.net/VPNBasics.html for
|
||||
information on the rules generated by entries in the tunnels file.
|
||||
|
||||
10) The NEWNOTSYN and LOGNEWNOTSYN options in shorewall.conf have been
|
||||
removed as have the 'newnotsyn' options in /etc/shorewall/interfaces
|
||||
and /etc/shorewall/hosts.
|
||||
|
||||
TCP new-not-syn packets may be blocked using the 'dropNotSyn' or
|
||||
'rejNotSyn' built-in actions.
|
||||
|
||||
Example: Reject all new-not-syn packets from the net and log them at
|
||||
the 'info' level.
|
||||
|
||||
#ACTION SOURCE DEST PROTO
|
||||
SECTION NEW
|
||||
rejNotSyn:info net all tcp
|
||||
|
||||
Note that the rule is added at the front of the NEW section of the
|
||||
rules file.
|
||||
|
||||
11) A new value is defined for the TC_ENABLED option in shorewall.conf to
|
||||
enable the built-in tc4shorewall traffic shaper. If you set
|
||||
TC_ENABLED=internal then tc4shorewall will be used. If the option is
|
||||
set to Yes then Shorewall will continue to look for a 'tcstart' script.
|
||||
Note that Shorewall itself does not provide a file named
|
||||
/etc/shorewall/tcstart so if you set TC_ENABLED=Yes, then you must
|
||||
supply that script.
|
||||
|
||||
Additional Migration Considerations for Users upgrading from Shorewall 2.2 or 2.0.
|
||||
|
||||
Note that these are in addition to the considerations listed above.
|
||||
|
||||
1) Shorewall now enforces the restriction that mark values used in
|
||||
/etc/shorewall/tcrules are less than 256. If you are using mark
|
||||
values >= 256, you must change your configuration before you
|
||||
upgrade.
|
||||
|
||||
2) LEAF/Bering packages for version 2.4.0 and later will not be
|
||||
available from shorewall.net. See http://leaf.sf.net for the lastest
|
||||
version of Shorewall for LEAF variants.
|
||||
|
||||
Additional Migration Considerations for Users upgrading from Shorewall 2.0.
|
||||
|
||||
Note that these are in addition to the considerations listed above.
|
||||
|
||||
1) Shorewall configuration files except shorewall.conf are now empty
|
||||
(they contain only comments). If you wish to retain the defaults
|
||||
in any of the following files, you should copy these files before
|
||||
upgrading them then restore them after the upgrade:
|
||||
|
||||
/etc/shorewall/zones
|
||||
/etc/shorewall/policy
|
||||
/etc/shorewall/tos
|
||||
|
||||
2) If shorewall.conf is upgraded to the latest version, it needs to be
|
||||
modified to set STARTUP_ENABLED=Yes
|
||||
|
||||
3) The ORIGINAL DEST column of the /etc/shorewall/rules file may no
|
||||
longer contain a second (SNAT) address. You must use an entry in
|
||||
/etc/shorewall/masq instead.
|
||||
|
||||
Example from Shorewall FAQ #1:
|
||||
|
||||
Prior to Shorewall 2.2:
|
||||
|
||||
/etc/shorewall/interfaces
|
||||
|
||||
loc eth1 detect routeback,...
|
||||
|
||||
/etc/shorewall/rules
|
||||
|
||||
DNAT loc loc:192.168.1.12 tcp 80 \
|
||||
- 130.252.100.69:192.168.1.254
|
||||
|
||||
Shorewall 2.2 and Later:
|
||||
|
||||
/etc/shorewall/interfaces
|
||||
|
||||
loc eth1 detect routeback,...
|
||||
|
||||
/etc/shorewall/masq:
|
||||
|
||||
eth1 eth1 192.168.1.254 tcp 80
|
||||
|
||||
|
||||
/etc/shorewall/rules:
|
||||
|
||||
DNAT loc loc:192.168.1.12 tcp 80 \
|
||||
- 130.252.100.69
|
||||
|
||||
4) The 'logunclean' and 'dropunclean' options that were deprecated in
|
||||
Shorewall 2.0 have now been removed completely.
|
||||
|
||||
5) A new IPTABLES variable has been added to shorewall.conf. This
|
||||
variable names the iptables executable that Shorewall will use. The
|
||||
variable is set to "/sbin/iptables". If you use the new
|
||||
shorewall.conf, you may need to change this setting to maintain
|
||||
compabibility with your current setup (if you use your existing
|
||||
shorewall.conf that does not set IPTABLES then you should
|
||||
experience no change in behavior).
|
||||
|
||||
6) The default port for OpenVPN tunnels has been changed from 5000 to
|
||||
1194 to reflect the recent IANA allocation of that port for
|
||||
OpenVPN.
|
||||
|
||||
7) If you are setting a shell variable using a statement similar to:
|
||||
|
||||
ETH0_IP=`find_interface_address eth0`
|
||||
|
||||
then you must change that statement to read as follows:
|
||||
|
||||
ETH0_IP=`find_first_interface_address eth0`
|
||||
|
||||
New Features in Shorewall 3.0.0.
|
||||
|
||||
1) Error and warning messages are made easier to spot by using
|
||||
capitalization (e.g., ERROR: and WARNING:).
|
||||
|
||||
2) 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 file system 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
|
||||
|
||||
3) 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:
|
||||
|
||||
ACTION If you code PARAM as the action 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 built-in or user-defined. All
|
||||
instances of PARAM in the body of the macro will be
|
||||
replaced with the ACTION.
|
||||
|
||||
Any logging applied when the macro 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.
|
||||
|
||||
4) 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.
|
||||
|
||||
5) 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.
|
||||
|
||||
6) 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.
|
||||
|
||||
7) A new FASTACCEPT option has been added to shorewall.conf.
|
||||
|
||||
Normally, Shorewall defers 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 include rules in the ESTABLISHED or
|
||||
RELATED sections of /etc/shorewall/rules.
|
||||
|
||||
8) Shorewall now generates an error if the 'norfc1918' option is
|
||||
specified for an interface with an RFC 1918 address.
|
||||
|
||||
9) You may now specify "!" followed by a list of addresses in the
|
||||
SOURCE and DEST columns of entries in /etc/shorewall/rules,
|
||||
/etc/shorewall/tcrules and in action files and Shorewall will
|
||||
generate the rule that you expect.
|
||||
|
||||
Example 1 (/etc/shorewall/rules):
|
||||
|
||||
#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.
|
||||
|
||||
Example 2 (/etc/shorewall/rules):
|
||||
|
||||
#ACTION SOURCE DEST PROTO DEST PORT(S)
|
||||
ACCEPT loc:10.0.0.0/24!10.0.0.4,10.0.0.22 \
|
||||
net tcp 80
|
||||
|
||||
That rule would allow loc->net HTTP access from the local
|
||||
network 10.0.0.0/24 except for hosts 10.0.0.4 and 10.0.0.22.
|
||||
|
||||
10) Tunnel types "openvpnserver" and "openvpnclient" have been added
|
||||
to reflect the introduction of client and server OpenVPN
|
||||
configurations in OpenVPN 2.0.
|
||||
|
||||
11) The COMMAND variable is now set to 'restore' in restore
|
||||
scripts. The value of this variable is sometimes of interest to
|
||||
programmers providing custom /etc/shorewall/tcstart scripts.
|
||||
|
||||
12) Previously, if you defined any intra-zone rule(s) then any traffic
|
||||
not matching the rule(s) was subject to normal policies (which
|
||||
usually turned out to involve the all->all REJECT policy). Now, the
|
||||
intra-zone ACCEPT policy will still be in effect in the presence of
|
||||
intra-zone rules. That policy can still be overridden by an
|
||||
explicit policy in your /etc/shorewall/policy file.
|
||||
|
||||
Example:
|
||||
|
||||
/etc/shorewall/rules:
|
||||
|
||||
DNAT loc:!192.168.1.4 loc:192.168.1.4:3128 tcp 80
|
||||
|
||||
Any other loc->loc traffic will still be accepted. If you want to
|
||||
also log that other loc->loc traffic at the info log level then
|
||||
insert this into /etc/shorewall/policy:
|
||||
|
||||
#SOURCE DEST POLICY LOG LEVEL
|
||||
loc loc ACCEPT info
|
||||
|
||||
13) Prior to Shorewall 2.5.3, the rules file only controlled packets in
|
||||
the Netfilter states NEW and INVALID. Beginning with this release,
|
||||
the rules file can also deal with packets in the ESTABLISHED and
|
||||
RELATED states.
|
||||
|
||||
The /etc/shorewall/rules file may now be divided into
|
||||
"sections". Each section is introduced by a line that begins with
|
||||
the keyword SECTION followed by the section name. Sections
|
||||
are as listed below and must appear in the order shown.
|
||||
|
||||
ESTABLISHED
|
||||
|
||||
Rules in this section apply to packets in the ESTABLISHED
|
||||
state.
|
||||
|
||||
RELATED
|
||||
|
||||
Rules in this section apply to packets in the RELATED state.
|
||||
|
||||
NEW
|
||||
|
||||
Rules in this section apply to packets in the NEW and INVALID
|
||||
states.
|
||||
|
||||
Rules in the ESTABLISHED and RELATED sections are limited to the
|
||||
following ACTIONs:
|
||||
|
||||
ACCEPT, DROP, REJECT, QUEUE, LOG and User-defined actions.
|
||||
|
||||
Macros may be used in these sections provided that they expand to
|
||||
only these ACTIONs.
|
||||
|
||||
At the end of the ESTABLISHED and RELATED sections, there is an
|
||||
implicit "ALLOW all all all" rule.
|
||||
|
||||
RESTRICTION: If you specify FASTACCEPT=Yes in
|
||||
/etc/shorewall.shorewall.conf then the ESTABLISHED and RELATED
|
||||
sections must be empty.
|
||||
|
||||
14) The value 'ipp2p' is once again allowed in the PROTO column of
|
||||
the rules file. It is recommended that rules specifying 'ipp2p'
|
||||
only be included in the ESTABLISHED section of the file.
|
||||
|
||||
|
||||
15) Shorewall actions lack a generalized way to pass parameters to an
|
||||
extension script associated with an action. To work around this
|
||||
lack, some users have used the log tag as a parameter. This works
|
||||
but requires that a log level other than 'none' be specified when
|
||||
the action is invoked. Beginning with this release, you can invoke
|
||||
an action with 'none'.
|
||||
|
||||
Example:
|
||||
|
||||
#ACTION SOURCE DEST
|
||||
A:none:these,are,parameters $FW net
|
||||
|
||||
When /etc/shorewall/A is invoked, the LEVEL variable will be empty
|
||||
but the TAG variable will contain "these,are,parameters" which
|
||||
can be easily parsed to isolate "these", "are" and "parameters":
|
||||
|
||||
ifs=$IFS
|
||||
IFS=,
|
||||
set -- $TAG
|
||||
IFS=$ifs
|
||||
|
||||
Now, $1 = these, $2 = are and $3 = parameters
|
||||
|
||||
16) The "shorewall check" command now checks the /etc/shorewall/masq,
|
||||
/etc/shorewall/blacklist, /etc/shorewall/proxyarp,
|
||||
/etc/shorewall/nat and /etc/shorewall/providers files.
|
||||
|
||||
17) Arne Bernin's "tc4shorewall" package has been integrated into
|
||||
Shorewall.
|
||||
|
||||
See: http://www.shorewall.net/3.0/traffic_shaping.htm for details.
|
||||
|
||||
Thanks, Arne!
|
||||
|
||||
18) When /usr/share/shorewall/functions is loaded it now sets
|
||||
|
||||
SHOREWALL_LIBRARY=Loaded
|
||||
|
||||
Application code such as /etc/shorewall/tcstart may test that
|
||||
variable to determine if the library has been loaded into the
|
||||
current shell process.
|
||||
|
||||
19) The install.sh script now does a much cleaner job of backing up the
|
||||
current installation. It copies the directories /etc/shorewall,
|
||||
/usr/share/shorewall and /var/lib/shorewall to a directory of the
|
||||
same name with "-$VERSION.bkout" appended. The init script and
|
||||
/sbin/shorewall are backed up to the /usr/share/shorewall and
|
||||
/var/lib/shorewall directories respectively. This makes it very
|
||||
simple to remove the backups:
|
||||
|
||||
rm -rf /etc/shorewall-*.bkout
|
||||
rm -rf /usr/share/shorewall-*.bkout
|
||||
rm -rf /var/lib/shorewall-*.bkout
|
||||
|
||||
20) A new '-n' option has been added to the "start", "restart",
|
||||
"restore", "stop" and "try" commands. This option instructs
|
||||
Shorewall to not alter the routing in any way.
|
||||
|
||||
This option is useful when you have a multi-ISP environment because
|
||||
it prevents the route cache from being flushed which preserves the
|
||||
mapping of end-point address pairs to routes.
|
||||
|
||||
21) The output of "shorewall dump" now includes a capabilities report
|
||||
such as the one produced by "shorewall show capabilities".
|
||||
|
||||
22) Note: This change is only important for users who ran Shorewall 2.5.x.
|
||||
|
||||
The "plain" zone type has been replaced by "ipv4". The types
|
||||
"IPv4" and "IPV4" are synonyms for "ipv4". In addition, "IPSEC",
|
||||
"ipsec4" and "IPSEC4" are recognized synonyms for "ipsec".
|
||||
|
||||
23) The NEWNOTSYN and LOGNEWNOTSYN options in shorewall.conf have been
|
||||
removed as have the 'newnotsyn' options in /etc/shorewall/interfaces
|
||||
and /etc/shorewall/hosts. See the Migration Considerations for
|
||||
instructions if you wish to block "new-not-syn" TCP packets.
|
||||
|
||||
24) The "shorewall show zones" command now displays the zone type. You
|
||||
must have restarted Shorewall using this release before this feature
|
||||
will work correctly.
|
||||
|
||||
25) Shorewall now supports UDP IPP2P matching. In addition to the "ipp2p"
|
||||
keyword in the PROTOCOL column of the relevant files, the following
|
||||
values may be specified:
|
||||
|
||||
ipp2p:tcp Equivalent to ipp2p and matches TCP traffic
|
||||
only.
|
||||
ipp2p:udp Matches UDP traffic.
|
||||
ipp2p:all Matches both UDP and TCP traffic. You may
|
||||
not specify a SOURCE PORT with this PROTOCOL.
|
||||
|
||||
26) Normally MAC verification triggered by the 'maclist' interface and host
|
||||
options is done out of the INPUT and FORWARD chains of the filter table.
|
||||
Users have reported that under some circumstances, MAC verification is
|
||||
failing for forwarded packets when the packets are being forwarded out
|
||||
of a bridge.
|
||||
|
||||
To work around this problem, a MACLIST_TABLE option has been added to
|
||||
shorewall.conf. The default value is MACLIST_TABLE=filter which results
|
||||
in the current behavior. If MACLIST_TABLE=mangle then filtering will
|
||||
take place out of the PREROUTING chain of the mangle table. Because
|
||||
the REJECT target may not be used in the PREROUTING chain, the settings
|
||||
MACLIST_DISPOSITION=REJECT and MACLIST_TABLE=mangle are incompatible.
|
||||
|
||||
27) The sample configurations are now packaged with the product. They are
|
||||
in the Samples directory on the tarball and are in the RPM they are
|
||||
in the Samples sub-directory of the Shorewall documentation
|
||||
directory.
|
||||
|
||||
New Features in 3.0.1
|
||||
|
||||
1) To make the macro facility more flexible, Shorewall now examines the
|
||||
contents of the SOURCE and DEST columns in both the macro body and in
|
||||
the invocation and tries to create the intended rule. If the value in
|
||||
the invocation appears to be an address (IP or MAC) or the name of an
|
||||
ipset, then it is placed after the value in the macro body. Otherwise,
|
||||
it is placed before the value in the macro body.
|
||||
|
||||
Example 1:
|
||||
|
||||
/etc/shorewall/macro.foo:
|
||||
|
||||
PARAM - 192.168.1.5 tcp http
|
||||
|
||||
/etc/shorewallrules:
|
||||
|
||||
foo/ACCEPT net loc
|
||||
|
||||
Effective rule:
|
||||
|
||||
ACCEPT net loc:192.168.1.5 tcp http
|
||||
|
||||
Example 2:
|
||||
|
||||
/etc/shorewall/macro.bar:
|
||||
|
||||
PARAM net loc tcp http
|
||||
|
||||
/etc/shorewall/rules:
|
||||
|
||||
bar/ACCEPT - 192.168.1.5
|
||||
|
||||
Effective rule:
|
||||
|
||||
ACCEPT net loc:192.168.1.5 tcp http
|
||||
|
||||
New Features in 3.0.2
|
||||
|
||||
1) A new Webmin macro has been added. This macro assumes that Webmin is
|
||||
running on its default port (10000).
|
||||
|
||||
New Features in 3.0.3
|
||||
|
||||
1) A "shorewall show macros" command has been added. This command displays
|
||||
a list of the standard macros along with a brief description of each.
|
||||
|
||||
2) The '-q' option is now supported with 'safe-start' and 'safe-restart'.
|
||||
|
||||
3) The value "-" is now allowed in the ADDRESS/SUBNET column of
|
||||
/etc/shorewall/blacklist. That value is equivalent to specifying
|
||||
0.0.0.0/0 in that column.
|
||||
|
||||
4) The output of "shorewall show tc" and "shorewall show classifiers" is
|
||||
now included in the output from "shorewall dump". This will aid us in
|
||||
analyzing traffic shaping problems.
|
||||
|
||||
5) You can now specify 'none' in the COPY column of /etc/shorewall/providers
|
||||
to signal that you want Shorewall to only copy routes through the interface
|
||||
listed in the INTERFACE column.
|
||||
|
||||
Note: This works on older versions of Shorewall as well. It is
|
||||
now documented.
|
||||
|
||||
6) An 'ipdecimal' command has been added to /sbin/shorewall. This command
|
||||
converts between dot-quad and decimal.
|
||||
|
||||
Example:
|
||||
|
||||
gateway:/etc/openvpn# shorewall ipdecimal 192.168.1.4
|
||||
3232235780
|
||||
gateway:/etc/openvpn# shorewall ipdecimal 3232235780
|
||||
192.168.1.4
|
||||
gateway:/etc/openvpn#
|
||||
|
||||
7) /etc/init.d/shorewall now supports a 'reload' command which is
|
||||
synonymous with the 'restart' command.
|
||||
The 'reload' command creates a script using 'generate' and if there are
|
||||
no errors, it then restores that script. It is equivalent to:
|
||||
|
||||
if shorewall generate <temp file>; then restore <tempfile>; fi
|
||||
|
Loading…
Reference in New Issue
Block a user