mirror of
https://gitlab.com/shorewall/code.git
synced 2025-06-03 00:15:54 +02:00
Fix some ghastly bugs in Macros
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2589 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep
parent
a6c792c731
commit
fe6cd6d349
@ -1,3 +1,8 @@
|
||||
Changes in 2.5.4
|
||||
|
||||
1) Allow TAG to be used as a general parameter mechanism [hack].
|
||||
|
||||
2) Fix some ghastly bugs in macros.
|
||||
|
||||
Changes in 2.5.3
|
||||
|
||||
@ -21,7 +26,7 @@ Changes in 2.5.3
|
||||
|
||||
Changes in 2.5.2
|
||||
|
||||
1) Allow port lists in /etc/sorewall/accounting.
|
||||
1) Allow port lists in /etc/shorewall/accounting.
|
||||
|
||||
2) Fix PKTTYPE=No and packet type match capability reporting.
|
||||
|
||||
|
||||
@ -5803,7 +5803,24 @@ process_macro() # $1 = target
|
||||
PARAM|PARAM:*)
|
||||
[ -n "$param" ] && mtarget=$(substitute_action $param $mtarget) || fatal_error "PARAM requires that a parameter be supplied in macro invocation"
|
||||
;;
|
||||
esac
|
||||
esac
|
||||
|
||||
case $mtarget in
|
||||
ACCEPT|ACCEPT+|NONAT|DROP|REJECT|DNAT|DNAT-|REDIRECT|REDIRECT-|LOG|CONTINUE|QUEUE|SAME|SAME-)
|
||||
;;
|
||||
*)
|
||||
if list_search ${mtarget%%:*} $ACTIONS; then
|
||||
if ! list_search $mtarget $USEDACTIONS; then
|
||||
createactionchain $mtarget
|
||||
USEDACTIONS="$USEDACTIONS $mtarget"
|
||||
fi
|
||||
|
||||
mtarget=$(find_logactionchain $mtarget)
|
||||
else
|
||||
fatal_error "Invalid Action in rule \"$mtarget ${mclients:--} ${mservers:--} ${mprotocol:--} ${mports:--} ${mcports:--} ${xaddress:--} ${mratelimit:--} ${muserspec:--}\""
|
||||
fi
|
||||
;;
|
||||
esac
|
||||
|
||||
if [ -n "$mclients" ]; then
|
||||
case $mclients in
|
||||
@ -5828,7 +5845,7 @@ process_macro() # $1 = target
|
||||
;;
|
||||
esac
|
||||
else
|
||||
mservers=${iserverss}
|
||||
mservers=${iservers}
|
||||
fi
|
||||
|
||||
[ -n "$iprotocol" ] && [ "x${iprotocol}" != x- ] && mprotocol=$iprotocol
|
||||
|
||||
@ -1,89 +1,12 @@
|
||||
Shorewall 2.5.3
|
||||
Shorewall 2.5.4
|
||||
|
||||
Problems Corrected in 2.5.3:
|
||||
Problems Corrected in 2.5.4:
|
||||
|
||||
1) The Netfilter 'raw' table is now cleared during "shorewall stop",
|
||||
"shorewall [re]start" and "shorewall clear".
|
||||
1) Several problems associated with macros have been corrected.
|
||||
|
||||
New Features in Shorewall 2.5.3
|
||||
New Features in Shorewall 2.5.4
|
||||
|
||||
1) You may now specify "!" followed by a list of addresses in the
|
||||
SOURCE and DEST columns of entries in /etc/shorewall/tcrules and
|
||||
in action files and Shorewall will generate the rule that you
|
||||
expect.
|
||||
|
||||
2) Tunnel types "openvpnserver" and "openvpnclient" have been added
|
||||
to reflect the introduction of client and server OpenVPN
|
||||
configurations in OpenVPN 2.0.
|
||||
|
||||
3) 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.
|
||||
|
||||
4) 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 presense 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
|
||||
|
||||
5) 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 which is 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.
|
||||
|
||||
6) 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.
|
||||
|
||||
7) Shorewall actions lack a generalized way to pass parameters to an
|
||||
1) 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
|
||||
@ -106,6 +29,11 @@ New Features in Shorewall 2.5.3
|
||||
|
||||
Now, $1 = these, $2 = are and $3 = parameters
|
||||
|
||||
Problems Corrected in 2.5.3:
|
||||
|
||||
1) The Netfilter 'raw' table is now cleared during "shorewall stop",
|
||||
"shorewall [re]start" and "shorewall clear".
|
||||
|
||||
Problems Corrected in 2.5.2:
|
||||
|
||||
1) You may now include port lists in in the /etc/shorewall/accounting
|
||||
@ -554,3 +482,26 @@ New Features in Shorewall 2.5.*
|
||||
only be included in the ESTABLISHED section of the file.
|
||||
|
||||
|
||||
17) 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
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user