mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-28 10:33:21 +01:00
Misc updates
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1677 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
parent
3b2535619e
commit
204b949836
@ -3060,8 +3060,8 @@ createlogactionchain() # $1 = Action Name, $2 = Log Level [: Log Tag ]
|
|||||||
eval actchain=\${${action}_actchain}
|
eval actchain=\${${action}_actchain}
|
||||||
|
|
||||||
case ${#action} in
|
case ${#action} in
|
||||||
10|11)
|
29|30)
|
||||||
CHAIN=$(echo $action | cut -b -9)
|
CHAIN=$(echo $action | cut -b -28)
|
||||||
;;
|
;;
|
||||||
*)
|
*)
|
||||||
CHAIN=${action}
|
CHAIN=${action}
|
||||||
@ -3072,7 +3072,7 @@ createlogactionchain() # $1 = Action Name, $2 = Log Level [: Log Tag ]
|
|||||||
[ "$COMMAND" != check ] && \
|
[ "$COMMAND" != check ] && \
|
||||||
while havechain %${CHAIN}${actchain}; do
|
while havechain %${CHAIN}${actchain}; do
|
||||||
actchain=$(($actchain + 1))
|
actchain=$(($actchain + 1))
|
||||||
[ $actchain -eq 10 -a ${#CHAIN} -eq 9 ] && CHAIN=$(echo $CHAIN | cut -b -8)
|
[ $actchain -eq 10 -a ${#CHAIN} -eq 28 ] && CHAIN=$(echo $CHAIN | cut -b -27)
|
||||||
done
|
done
|
||||||
|
|
||||||
CHAIN=%${CHAIN}${actchain}
|
CHAIN=%${CHAIN}${actchain}
|
||||||
@ -3233,7 +3233,7 @@ merge_levels() # $1=level at which superior action is called, $2=level at which
|
|||||||
# As the rules file is scanned, each action[:level[:tag]] is merged onto the USEDACTIONS list. When an <action>
|
# As the rules file is scanned, each action[:level[:tag]] is merged onto the USEDACTIONS list. When an <action>
|
||||||
# is merged onto this list, its action chain is created. Where logging is specified, a chain with the name
|
# is merged onto this list, its action chain is created. Where logging is specified, a chain with the name
|
||||||
# %<action>n is used where the <action> name is truncated on the right where necessary to ensure that the total
|
# %<action>n is used where the <action> name is truncated on the right where necessary to ensure that the total
|
||||||
# length of the chain name does not exceed 11 characters.
|
# length of the chain name does not exceed 30 characters.
|
||||||
#
|
#
|
||||||
# The second phase (process_actions2) occurs after the rules file is scanned. The transitive closure of
|
# The second phase (process_actions2) occurs after the rules file is scanned. The transitive closure of
|
||||||
# USEDACTIONS is generated; again, as new actions are merged onto this list, their action chains are created.
|
# USEDACTIONS is generated; again, as new actions are merged onto this list, their action chains are created.
|
||||||
|
@ -193,7 +193,7 @@ New Features:
|
|||||||
questions on the support and development lists regarding why the
|
questions on the support and development lists regarding why the
|
||||||
default entries are the way they are.
|
default entries are the way they are.
|
||||||
|
|
||||||
5) Previously, specifying a log level (and optionally a log tag) on a
|
5) Previously, including a log level (and optionally a log tag) on a
|
||||||
rule that specified a user-defined (or Shorewall-defined) action
|
rule that specified a user-defined (or Shorewall-defined) action
|
||||||
would log all traffic passed to the action. Beginning with this
|
would log all traffic passed to the action. Beginning with this
|
||||||
release, specifying a log level in a rule that specifies a user-
|
release, specifying a log level in a rule that specifies a user-
|
||||||
@ -218,7 +218,7 @@ New Features:
|
|||||||
|
|
||||||
foo:debug fw net
|
foo:debug fw net
|
||||||
|
|
||||||
Logging in the invoke 'foo' action will be:
|
Logging in the invoked 'foo' action will be:
|
||||||
|
|
||||||
ACCEPT:debug - - tcp 22
|
ACCEPT:debug - - tcp 22
|
||||||
bar:info
|
bar:info
|
||||||
@ -244,7 +244,7 @@ New Features:
|
|||||||
|
|
||||||
This change has an effect on extension scripts used with
|
This change has an effect on extension scripts used with
|
||||||
user-defined actions. If you define an action 'acton' and you have
|
user-defined actions. If you define an action 'acton' and you have
|
||||||
a /etc/shorewall/acton script then when that script is invoked,
|
an /etc/shorewall/acton script then when that script is invoked,
|
||||||
the following three variables will be set for use by the script:
|
the following three variables will be set for use by the script:
|
||||||
|
|
||||||
$CHAIN = the name of the chain where your rules are to be
|
$CHAIN = the name of the chain where your rules are to be
|
||||||
@ -264,7 +264,7 @@ New Features:
|
|||||||
|
|
||||||
Your /etc/shorewall/acton file will be run with:
|
Your /etc/shorewall/acton file will be run with:
|
||||||
|
|
||||||
$CHAIN="acton1"
|
$CHAIN="%acton1"
|
||||||
$LEVEL="info"
|
$LEVEL="info"
|
||||||
$TAG="test"
|
$TAG="test"
|
||||||
|
|
||||||
@ -282,8 +282,9 @@ New Features:
|
|||||||
|
|
||||||
7) Some additional support has been added for the 2.6 Kernel IPSEC
|
7) Some additional support has been added for the 2.6 Kernel IPSEC
|
||||||
implementation. To use this support, you must have installed the
|
implementation. To use this support, you must have installed the
|
||||||
IPSEC policy match patch from Patch-0-Matic-ng. That patch affects
|
IPSEC policy match patch and the four IPSEC/Netfilter patches
|
||||||
both your kernel and iptables.
|
from Patch-0-Matic-ng. The policy match patch affects both your
|
||||||
|
kernel and iptables.
|
||||||
|
|
||||||
There are two ways to specify that IPSEC is to be used when
|
There are two ways to specify that IPSEC is to be used when
|
||||||
communicating with a set of hosts; both methods involve the new
|
communicating with a set of hosts; both methods involve the new
|
||||||
@ -402,7 +403,7 @@ New Features:
|
|||||||
should only appear in the IN OPTIONS and OUT OPTIONS columns.
|
should only appear in the IN OPTIONS and OUT OPTIONS columns.
|
||||||
|
|
||||||
strict (if specified, packets must match all policies;
|
strict (if specified, packets must match all policies;
|
||||||
polcies are delimited by 'next').
|
policies are delimited by 'next').
|
||||||
|
|
||||||
next (only available with strict)
|
next (only available with strict)
|
||||||
|
|
||||||
@ -477,7 +478,7 @@ New Features:
|
|||||||
|
|
||||||
15) Support has been added for the iptables CLASSIFY target. That
|
15) Support has been added for the iptables CLASSIFY target. That
|
||||||
target allows you to classify packets for traffic shaping directly
|
target allows you to classify packets for traffic shaping directly
|
||||||
rather than indirectly through fwmark. Simply entry the
|
rather than indirectly through fwmark. Simply enter the
|
||||||
<major>:<minor> classification in the first column of
|
<major>:<minor> classification in the first column of
|
||||||
/etc/shorewall/tcrules:
|
/etc/shorewall/tcrules:
|
||||||
|
|
||||||
@ -542,3 +543,11 @@ New Features:
|
|||||||
|
|
||||||
Type 3 code 4 (fragmentation needed)
|
Type 3 code 4 (fragmentation needed)
|
||||||
Type 11 (TTL exceeded)
|
Type 11 (TTL exceeded)
|
||||||
|
|
||||||
|
21) Explicit control over the kernel's Martian logging is now provided
|
||||||
|
using the new 'logmartians' interface option. If you include
|
||||||
|
'logmartians' in the interface option list then logging of Martian
|
||||||
|
packets on will be enabled on the specified interface.
|
||||||
|
If you wish to globally enable martian logging, you can set
|
||||||
|
MARTIAN_LOGGING=Yes in shorewall.conf.
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user