Shorewall 3.3.2 Note to users upgrading from Shorewall 3.0 or 3.2 Most problems associated with upgrades come from two causes: - The user didn't read and follow the migration considerations in these release notes. - The user mis-handled the /etc/shorewall/shorewall.conf file during upgrade. Shorewall is designed to allow the default behavior of the product to evolve over time. To make this possible, the design assumes that you will not replace your current shorewall.conf file during upgrades. If you feel absolutely compelled to have the latest comments and options in your shorewall.conf then you must proceed carefully. 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. 10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255 If you have a file named /etc/shorewall/modules, please remove it. The default modules file is now located in /usr/share/shorewall/ (see the "Migration Considerations" below). Please see the "Migration Considerations" below for additional upgrade information. Problems Corrected in 3.3.2 1) The 'proxyarp' option in /etc/shorewall/interfaces was not triggering the loading of lib.proxyarp with the result that the option was ignored unless there were also entries in /etc/shorewall/proxyarp. 2) If both /etc/shorewall/tcdevices and /etc/shorewall/tcclasses were empty then the compiler would fail with: setup_traffic_shaping: command not found Other changes in 3.3.2 1) /etc/shorewall/functions has been renamed /etc/shorewall/lib.base. If you soure the 'functions' file in any of your own scripts, please modify them accordingly. 2) The output of "shorewall show log" and "shorewall logwatch" now include the name of the log file being accessed. Migration Considerations: 1) Shorewall supports the notion of "default actions". A default action defines a set of rules that are applied before a policy is enforced. Default actions accomplish two goals: a) Relieve log congestion. Default actions typically include rules to silently drop or reject traffic that would otherwise be logged when the policy is enforced. b) Ensure correct operation. Default actions can also avoid common pitfalls like dropping connection requests on port TCP port 113. If these connections are dropped (rather than rejected) then you may encounter problems connecting to internet services that utilize the AUTH protocol of client authentication. In prior Shorewall versions, default actions (action.Drop and action.Reject) were defined for DROP and REJECT policies in /usr/share/shorewall/actions.std. These could be overridden in /etc/shorewall/actions. This approach has two drawbacks: a) All DROP policies must use the same default action and all REJECT policies must use the same default action. b) Now that we have modularized action processing (see the New Features section below), we need a way to define default rules for a policy. If you have not overridden the defaults using entries in /etc/shorewall/actions then you need make no changes to migrate to Shorewall version 3.3. Otherwise, please see item 3) in the New Features below. 2) The 'Limit' action is now a builtin. If you have 'Limit' listed in /etc/shorewall/actions, remove the entry. Also remove the files /etc/shorewall/action.Limit and/or /etc/shorewall/Limit if you have them. New Features: 1) In order to accomodate small embedded applications, Shorewall 3.3 is now modularized. In addition to the base files, there are loadable "libraries" that may be included or omitted from an embedded system as required. Loadable Shorewall libraries reside in /usr/share/shorewall/ and have names that begin with "lib.". The following libraries are included in Shorewall 3.3: - lib.accounting. Must be available if you include entries in /etc/shorewall/accounting. - lib.actions. Must be available if you do not specify USE_ACTIONS=No in /etc/shorewall/shorewall.conf. - lib.dynamiczones. Must be available if you specify DYNAMIC_ZONES=Yes in shorewall.conf. - lib.maclist. Must be available if you specify the 'maclist' option in /etc/shorewall/interfaces or /etc/shorewall/hosts. - lib.nat. Must be available if you have entries in /etc/shorewall/masq, /etc/shorewall/nat or /etc/shorewall/netmap. - lib.providers. Must be available if you have entries in /etc/shorewall/providers. - lib.proxyarp. Must be available if you have entries in /etc/shorewall/proxyarp or if you specify the 'proxyarp' option in /etc/shorewall/interfaces. - lib.tc. Must be available if you have entries in /etc/shorewall/tcdevices and /etc/shorewall/tcclasses. - lib.tcrules. Must be available if you have entries in /etc/shorewall/tcrules. - lib.tunnels. Must be available if you have entries in /etc/shorewall/tunnels. Embedded applications can further decrease the size of the Shorewall footprint by: - Omitting the macro files. - Only including the 'modules' file appropriate for the kernel in use. - Omitting all unused extension scripts. - Stripping the comments (except for copyright) from the various files. 2) As hinted in the previous bullet, there is a new USE_ACTIONS option in /etc/shorewall/shorewall.conf. Shorewall actions can be very powerful but they also require a lot of code to implement. Embedded applications can omit that code by setting USE_ACTIONS=No. Shorewall will ignore all action-related files including /usr/share/shorewall/actions.std and /etc/shorewall/actions. Builtin actions will still be available for use in rules and macros. The 'Limit' action has been converted to a builtin so that Limit is available even when USE_ACTIONS=No. See the next item for more information. 3) Prior to Shorewall 3.3, default actions were specified in /usr/share/shorewall/actions.std or in /etc/shorewall/actions. This approach has two drawbacks: a) All DROP policies must use the same default action and all REJECT policies must use the same default action. b) Now that we have modularized action processing, we need a way to define default rules for a policy. The solution is two-fold: - Four new options have been added to the /etc/shorewall/shorewall.conf file that allow specifying the default action for DROP, REJECT, ACCEPT and QUEUE. The options are DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT and QUEUE_DEFAULT. DROP_DEFAULT describes the rules to be applied before a connection request is dropped by a DROP policy; REJECT_DEFAULT describes the rules to be applied if a connection request is rejected by a REJECT policy. The other two are similar for ACCEPT and QUEUE policies. The value assigned to these may be: a) The name of an action. b) The name of a macro c) 'None' or 'none' The default values are: DROP_DEFAULT="Drop" REJECT_DEFAULT="Reject" ACCEPT_DEFAULT=none QUEUE_DEFAULT=none If USE_ACTIONS=Yes, then these values refer to action.Drop and action.Reject respectively. If USE_ACTIONS=No, then these values refer to macro.Drop and macro.Reject. If you set the value of either option to "None" then no default action will be used and the default action or macro must be specified in /etc/shorewall/policy - The POLICY column in /etc/shorewall/policy has been extended. In /etc/shorewall/policy, when the POLICY is DROP, REJECT, ACCEPT or QUEUE then the policy may be followed by ":" and one of the following: a) The word "None" or "none". This causes any default action define in /etc/shorewall/actions.std or /etc/shorewall/actions to be omitted for this policy. b) The name of an action (requires that USE_ACTIONS=Yes in shorewall.conf). That action will be invoked before the policy is enforced. c) The name of a macro. The rules in that macro will be applied before the policy is enforced. This does not require USE_ACTIONS=Yes. Example: #SOURCE DEST POLICY LOG # LEVEL loc net ACCEPT net all DROP:Drop info # # THE FOLLOWING POLICY MUST BE LAST # all all REJECT:Reject info