Add NFQUEUE_DEFAULT to shorewall.conf

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@7893 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2007-12-10 21:18:54 +00:00
parent 8bf6acdc68
commit 528ed44682
10 changed files with 317 additions and 25 deletions

View File

@ -95,6 +95,7 @@ DROP_DEFAULT="Drop"
REJECT_DEFAULT="Reject"
ACCEPT_DEFAULT="none"
QUEUE_DEFAULT="none"
NFQUEUE_DEFAULT="none"
###############################################################################
# R S H / R C P C O M M A N D S

View File

@ -97,6 +97,7 @@ DROP_DEFAULT="Drop"
REJECT_DEFAULT="Reject"
ACCEPT_DEFAULT="none"
QUEUE_DEFAULT="none"
NFQUEUE_DEFAULT="none"
###############################################################################
# R S H / R C P C O M M A N D S

View File

@ -95,6 +95,7 @@ DROP_DEFAULT="Drop"
REJECT_DEFAULT="Reject"
ACCEPT_DEFAULT="none"
QUEUE_DEFAULT="none"
NFQUEUE_DEFAULT="none"
###############################################################################
# R S H / R C P C O M M A N D S

View File

@ -93,6 +93,7 @@ DROP_DEFAULT="Drop"
REJECT_DEFAULT="Reject"
ACCEPT_DEFAULT="none"
QUEUE_DEFAULT="none"
NFQUEUE_DEFAULT="none"
###############################################################################
# R S H / R C P C O M M A N D S

View File

@ -643,7 +643,7 @@ process_actions1() {
while read mtarget mclients mservers mprotocol mports mcports mratelimit muserspec; do
[ $mtarget eq COMMENT ] && continue
[ $mtarget = COMMENT ] && continue
temp="${mtarget%%:*}"
case "$temp" in
@ -796,7 +796,7 @@ process_action3() {
while read mtarget mclients mservers mprotocol mports mcports mratelimit muserspec; do
[ $mtarget eq COMMENT ] && continue
[ $mtarget = COMMENT ] && continue
mtarget=$(merge_levels $xaction2 $mtarget)

View File

@ -53,10 +53,10 @@
<para>Shorewall macros allow a symbolic name to be associated with a
series of one or more iptables rules. The symbolic name may appear in the
ACTION column of an <filename><ulink
url="manpages/shorewall-rules.html">/etc/shorewall/rules</ulink></filename> file
entry and in the TARGET column of an action in which case, the traffic
matching that rules file entry will be passed to the series of iptables
rules named by the macro.</para>
url="manpages/shorewall-rules.html">/etc/shorewall/rules</ulink></filename>
file entry and in the TARGET column of an action in which case, the
traffic matching that rules file entry will be passed to the series of
iptables rules named by the macro.</para>
<para>Macros can be thought of as templates. When a macro is invoked in an
<filename>/etc/shorewall/rules</filename> entry, it may be qualified by a
@ -109,9 +109,11 @@ PARAM - - tcp 135,139,445
<para>Most Standard Macros are <firstterm>parameterized</firstterm>. That
means that you specify what you want to do (ACCEPT, DROP, REJECT, etc.)
when you invoke the macro. The SMB macro shown above is parameterized
(note PARAM in the TARGET column). When invoking a parameterized macro,
you follow the name of the macro with a slash ("/") and the action that
you want to substitute for PARAM.</para>
(note PARAM in the TARGET column).</para>
<para><emphasis role="bold">Shorewall versions prior to 4.1:</emphasis>
When invoking a parameterized macro, you follow the name of the macro with
a slash ("/") and the action that you want to substitute for PARAM.</para>
<para>Example:</para>
@ -131,6 +133,30 @@ ACCEPT loc fw udp 1024: 137
ACCEPT loc fw tcp 135,139,445</programlisting>
</blockquote>
<para><emphasis role="bold">Shorewall versions 4.1 and later:</emphasis>
When invoking a parameterized macro, you follow the name of the macro with
the action that you want to substitute for PARAM enclosed in parentheses.
The older syntax described above is still supported but is
deprecated.</para>
<para>Example:</para>
<blockquote>
<para>/etc/shorewall/rules:</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
SMB(ACCEPT) loc fw </programlisting>
<para>The above is equivalent to coding the following series of
rules:</para>
<programlisting>#TARGET SOURCE DEST PROTO DEST PORT(s)
ACCEPT loc fw udp 135,445
ACCEPT loc fw udp 137:139
ACCEPT loc fw udp 1024: 137
ACCEPT loc fw tcp 135,139,445</programlisting>
</blockquote>
<para>Logging is covered in <link linkend="Logging">a following
section</link>. The other columns are treated as follows:</para>
@ -155,11 +181,16 @@ ACCEPT loc fw tcp 135,139,445</programlisting>
<programlisting>#TARGET SOURCE DEST PROTO DEST PORT(S)
PARAM - loc tcp 25</programlisting>
<para>/etc/shorewall/rules</para>
<para>/etc/shorewall/rules (Shorewall 4.0):</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
SMTP/DNAT:info net 192.168.1.5</programlisting>
<para>/etc/shorewall/rules (Shorewall 4.1 and later):</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
SMTP(DNAT):info net 192.168.1.5</programlisting>
<para>This would be equivalent to coding the following directly in
/etc/shorewall/rules</para>
@ -175,11 +206,16 @@ DNAT:info net loc:192.168.1.5 tcp 25</programlisting>
<programlisting>#TARGET SOURCE DEST PROTO DEST PORT(S)
PARAM - 192.168.1.5 tcp 25</programlisting>
<para>/etc/shorewall/rules</para>
<para>/etc/shorewall/rules (Shorewall 4.0)</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
SMTP/DNAT:info net loc</programlisting>
<para>/etc/shorewall/rules (Shorewall 4.1 and later)</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
SMTP(DNAT):info net loc</programlisting>
<para>This would be equivalent to coding the following directly in
/etc/shorewall/rules</para>
@ -210,11 +246,16 @@ PARAM DEST SOURCE udp 1024: 137
PARAM DEST SOURCE tcp 135,139,445
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
<para>/etc/shorewall/rules:</para>
<para>/etc/shorewall/rules (Shorewall 4.0):</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
SMBBI/ACCEPT loc fw</programlisting>
<para>/etc/shorewall/rules (Shorewall 4.1 and later):</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
SMBBI(ACCEPT) loc fw</programlisting>
<para>This would be equivalent to coding the following directly in
/etc/shorewall/rules</para>

View File

@ -100,9 +100,15 @@ case $1 in
shellrpm=shorewall-shell-${1%-*}-0${1#*-}.noarch.rpm
BASE=Yes
;;
4.0.*-*)
DEST="/srv/ftp/pub/shorewall/development/staging/${1%.*}/shorewall-${1}"
*.*.*.*)
BASEVERSION=${1%.*}
PATCHNUM=${1##*.}
DEST="/srv/ftp/pub/shorewall/development/staging/${BASEVERSION%.*}/shorewall-${BASEVERSION}"
SHOREWALL=shorewall-common
rpm=shorewall-common-${BASEVERSION}-${PATCHNUM}.noarch.rpm
literpm=shorewall-lite-${BASEVERSION}-${PATCHNUM}.noarch.rpm
perlrpm=shorewall-perl-${BASEVERSION}-${PATCHNUM}.noarch.rpm
shellrpm=shorewall-shell-${BASEVERSION}-${PATCHNUM}.noarch.rpm
;;
4.0.*)
DEST="/srv/ftp/pub/shorewall/development/staging/${1%.*}/shorewall-$1"
@ -113,10 +119,6 @@ case $1 in
shellrpm=shorewall-shell-${1}-1.noarch.rpm
BASE=Yes
;;
4.1.*-*)
DEST="/srv/ftp/pub/shorewall/development/staging/${1%.*}/shorewall-${1%-*}"
SHOREWALL=shorewall-common
;;
4.1.*)
DEST="/srv/ftp/pub/shorewall/development/staging/${1%.*}/shorewall-$1"
SHOREWALL=shorewall-common

View File

@ -100,9 +100,15 @@ case $1 in
shellrpm=shorewall-shell-${1%-*}-0${1#*-}.noarch.rpm
BASE=Yes
;;
4.0.*-*)
DEST="/srv/ftp/pub/shorewall/${1%.*}/shorewall-${1%-*}"
4.0.*.*)
BASEVERSION=${1%.*}
PATCHNUM=${1##*.}
DEST="/srv/ftp/pub/shorewall/${BASEVERSION%.*}/shorewall-${BASEVERSION}"
SHOREWALL=shorewall-common
rpm=shorewall-common-${BASEVERSION}-${PATCHNUM}.noarch.rpm
literpm=shorewall-lite-${BASEVERSION}-${PATCHNUM}.noarch.rpm
perlrpm=shorewall-perl-${BASEVERSION}-${PATCHNUM}.noarch.rpm
shellrpm=shorewall-shell-${BASEVERSION}-${PATCHNUM}.noarch.rpm
;;
4.0.*)
DEST="/srv/ftp/pub/shorewall/${1%.*}/shorewall-$1"
@ -113,9 +119,15 @@ case $1 in
shellrpm=shorewall-shell-${1}-1.noarch.rpm
BASE=Yes
;;
4.1.*-*)
DEST="/srv/ftp/pub/shorewall/development/${1%.*}/shorewall-${1%-*}"
4.1.*.*)
BASEVERSION=${1%.*}
PATCHNUM=${1##*.}
DEST="/srv/ftp/pub/shorewall/development/${BASEVERSION%.*}/shorewall-${BASEVERSION}"
SHOREWALL=shorewall-common
rpm=shorewall-common-${BASEVERSION}-${PATCHNUM}.noarch.rpm
literpm=shorewall-lite-${BASEVERSION}-${PATCHNUM}.noarch.rpm
perlrpm=shorewall-perl-${BASEVERSION}-${PATCHNUM}.noarch.rpm
shellrpm=shorewall-shell-${BASEVERSION}-${PATCHNUM}.noarch.rpm
;;
4.1.*)
DEST="/srv/ftp/pub/shorewall/development/${1%.*}/shorewall-$1"

View File

@ -28,7 +28,11 @@ case $(/sbin/shorewall version) in
;;
esac
for directory in *; do
DIRECTORIES="$*"
[ -n "${DIRECTORIES:=*}" ]
for directory in $DIRECTORIES; do
if [ -d $directory ]; then
if /sbin/shorewall -${OPTIONS} compile -t $directory $directory/firewall > $directory/compileroutput 2> $directory/compilererrors; then
if [ -f $directory/firewall.last ]; then

View File

@ -24,9 +24,238 @@ href="GnuCopyright.htm" target="_self">GNU Free Documentation
License</a></span>”.<br>
</p>
<p>October 22, 2007</p>
<p>November 23, 2007</p>
<hr style="width: 100%; height: 2px;">
<p><strong>2007-11-23 Shorewall 4.0.6</strong></p>
<pre>Problems corrected in Shorewall-perl 4.0.6.
1) In a DNAT or REDIRECT rule, if no serverport was given and the DEST
PORT(S) list contained a service name containing a hyphen ("-") then
an ERROR was generated.
Example -- Rules file:
DNAT net loc:$WINDOWS_IP tcp https,pptp,ms-wbt-server,4125
Results in:
ERROR: Invalid port range (ms:wbt:server) : rules (line 49)
Problem was introduced in Shorewall 4.0.5 and does not occur in
earlier releases.
2) If a long destination port list needed to be broken at a port pair,
the generated rule contained an extra comma which resulted in an
iptables-restore failure.
3) Several problems involving port ranges and port lists in REDIRECT
rules have been corrected.
4) Shorewall-perl no longer requires an address in the GATEWAY column
of /etc/shorewall/tunnels. If the column is left empty (or contains
'-') then 0.0.0.0/0 is assumed.
5) Previously with Shorewall-perl, redirecting both STDOUT and STDERR
to the same file descriptor resulted in scrambled output between
the two. The error messages were often in the middle of the
regular output far ahead of the point where the error occurred.
This problem was possible in the Debian Shorewall init script
(/etc/init.d/shorewall) which redirects output to the
Debian-specific /var/log/shorewall-init.log file in this way:
$SRWL $SRWL_OPTS start &gt;&gt; $INITLOG 2&gt;&amp;1 &amp;&amp; ...
6) With both compilers, when HIGH_ROUTE_MARKS=Yes, unpredictable
results could occur when marking in the PREROUTING or OUTPUT
chains. When a rule specified a mark value &gt; 255, the compilers
were using the '--or-mark' operator rather than the '--set-mark'
operator. Consequently, when a packet matched more than one
rule, the resulting routing mark was the logical product of the
mark values in the matching rules rather than the mark value from
the last matching rule.
Example:
0x100 192.168.1.44 0.0.0.0/0
0x200 0.0.0.0/0 0.0.0.0/0 tcp 25
A TCP packet from 192.168.1.44 with destination port 25 would have
a mark value of 0x300 rather than the expected value of 0x200.
7) Previously, a 'start -f' on Shorewall Lite would produce the
following distressing output before starting the firewall:
make: *** No rule to make target `/firewall', needed by
`/var/lib/shorewall-lite/restore'. Stop.
Furthermore, the Makefile for both Shorewall and Shorewall Lite
failed to take into account the /etc/shorewall/vardir file.
This has been corrected. As part of the fix, both /sbin/shorewall
and /sbin/shorewall-lite support a "show vardir" command that
displays the VARDIR setting.
8) Shorewall-perl was previously ignoring the USER/GROUP column of the
tcrules file.
9) Supplying the name of a built-in chain in the 'refresh' command
caused entries in the chain to be duplicated. Since this is a
feature of iptables-restore with the '-n' option, built-in chains
in the 'refresh' list will now be rejected.
Known Problems Remaining.
1) The 'refresh' command doesn't refresh the mangle table. So changes
made to /etc/shorewall/providers and/or /etc/shorewall/tcrules may
not be reflected in the running ruleset.
Other changes in Shorewall 4.0.6.
1) Shorewall-perl now uses the '--physdev-is-bridged' option when it
is available. This option will suppress messages like the following:
kernel: physdev match: using --physdev-out in the OUTPUT, FORWARD and
POSTROUTING chains for non-bridged traffic is not supported
anymore.
This change only affects users who use bport/bport4 zones in a
briged configuration and requires that capabilities files be
regenerated using Shorewall-common or Shorewall-lite 4.0.6.
2) Shorewall-perl now allows you to embed Shell or Perl scripts in
all configuration files except /etc/shorewall/params and
/etc/shorewall/shorewall.conf (As always, you can continue to
include arbitrary shell code in /etc/shorewall/params).
To embed a one-line script, use one of the following:
SHELL &lt;shell script&gt;
PERL &lt;perl script&gt;
For multi-line scripts, use:
BEGIN SHELL
&lt;shell script&gt;
END SHELL
BEGIN PERL
&lt;perl script&gt;
END PERL
For SHELL scripts, the output from the script is processed as if it
were part of the file.
Example 1 (Shell): To generate SMTP/ACCEPT rules from zones a b c d
and e to the firewall:
Either:
BEGIN SHELL
for z in a b c d e; do
echo SMTP/ACCEPT $z fw tcp 25
done
END SHELL
or
SHELL for z in a b c d e; do echo SMTP/ACCEPT $z fw tcp 25; done
Either is equivalent to:
SMTP/ACCEPT a fw tcp 25
SMTP/ACCEPT b fw tcp 25
SMTP/ACCEPT c fw tcp 25
SMTP/ACCEPT d fw tcp 25
SMTP/ACCEPT e fw tcp 25
With a Perl script, if you want to output text to be processed as
if it were part of the file, then pass the text to the shorewall()
function.
Example 2 (Perl): To generate SMTP/ACCEPT rules from zones a b c d
and e to the firewall:
BEGIN PERL
for ( qw/a b c d e/ ) {
shorewall "SMTP/ACCEPT $_ fw tcp 25";
}
END PERL
PERL scripts have access to any context accumulated in earlier PERL
scripts. All such embedded Perl, as well as conventional Perl
extension scripts are placed in the Shorewall::User package. That
way, your global variables and functions won't conflict with any of
Shorewall's.
To allow you to load Perl modules and initialize any global state,
a new 'compile' compile-time extension script has been added. It is
called early in the compilation process.
For additional information, see
- http://www.shorewall.net/configuration_file_basics.html#Embedded
3) To complement Embedded Perl scripts, Shorewall 4.0.6 allows Perl
scripts to create filter chains using
Shorewall::Chains::new_manual_chain() and then use the chain as a
target in subsequent entries in /etc/shorewall/rules.
See http://www.shorewall.net/ManualChains.html for information.
4) The 'hits' command now accepts a -t option which limits the report
to those log records generated today.
5) A DONT_LOAD option has been added to shorewall.conf. If there are
kernel modules that you don't wish to have loaded, you can list
them in this entry as a comma-separated list.
Example:
DONT_LOAD=nf_conntrack_sip,nf_nat_sip
6) Shorewall-perl now supports the --random option of the iptables
SNAT, MASQUERADE, DNAT and REDIRECT targets. Please note that
iptables support for this option is currently broken for the DNAT
and REDIRECT targets; I've sent a patch to the Netfilter team.
For MASQUERADE, simply place the word 'random' in the ADDRESS
column. This causes Netfilter to randomize the source port seen by
the remote host.
Example:
#INTERFACE SOURCE ADDRESS
eth0 eth1 random
For SNAT, follow the port list by ":random".
Example:
#INTERFACE SOURCE ADDRESS
eth0 eth1 206.124.146.179:10000-10999:random
For DNAT, follow the port list by ":random".
Example:
#ACTION SOURCE DEST PROTO DEST
# PORT(S)
DNAT net loc:192.168.1.4:40-50:random tcp 22
For REDIRECT, you must use the fully-qualified form of the DEST:
#ACTION SOURCE DEST PROTO DEST
# PORT(S)
REDIRECT net $FW::40-50:random tcp 22
Note that ':random' is only effective with SNAT, DNAT and REDIRECT
when a port range is specified in the ADDRESS/DEST column. It is
ignored by iptables/iptables-restore otherwise.
</pre>
<hr>
<p><strong>2007-10-22 Shorewall 4.0.5</strong></p>
<pre>Problems corrected in Shorewall 4.0.5.