shorewall6-5.2.3.4/ 0000775 0000000 0000000 00000000000 13531077635 012463 5 ustar root root shorewall6-5.2.3.4/shorewallrc.default 0000664 0000000 0000000 00000003643 13531077635 016364 0 ustar root root #
# Default Shorewall 5.2 rc file
#
BUILD= #Default is to detect the build system
HOST=linux #Generic Linux
PREFIX=/usr #Top-level directory for shared files, libraries, etc.
SHAREDIR=${PREFIX}/share #Directory for arch-neutral files.
LIBEXECDIR=${PREFIX}/share #Directory for executable scripts.
PERLLIBDIR=${PREFIX}/share/shorewall #Directory to install Shorewall Perl module directory
CONFDIR=/etc #Directory where subsystem configurations are installed
SBINDIR=/sbin #Directory where system administration programs are installed
MANDIR=${PREFIX}/man #Directory where manpages are installed.
INITDIR=/etc/init.d #Directory where SysV init scripts are installed.
INITFILE=$PRODUCT #Name of the product's installed SysV init script
INITSOURCE=init.sh #Name of the distributed file to be installed as the SysV init script
ANNOTATED= #If non-zero, annotated configuration files are installed
SERVICEDIR= #Directory where .service files are installed (systems running systemd only)
SERVICEFILE= #Name of the file to install in $SYSTEMD. Default is $PRODUCT.service
SYSCONFFILE= #Name of the distributed file to be installed in $SYSCONFDIR
SYSCONFDIR= #Directory where SysV init parameter files are installed
SPARSE= #If non-empty, only install $PRODUCT/$PRODUCT.conf in $CONFDIR
VARLIB=/var/lib #Directory where product variable data is stored.
VARDIR=${VARLIB}/$PRODUCT #Directory where product variable data is stored.
DEFAULT_PAGER= #Pager to use if none specified in shorewall[6].conf
shorewall6-5.2.3.4/shorewallrc.openwrt 0000664 0000000 0000000 00000003514 13531077635 016433 0 ustar root root #
# OpenWRT/LEDE Shorewall 5.2 rc file
#
BUILD= #Default is to detect the build system
HOST=openwrt
PREFIX=/usr #Top-level directory for shared files, libraries, etc.
SHAREDIR=${PREFIX}/share #Directory for arch-neutral files.
LIBEXECDIR=${PREFIX}/share #Directory for executable scripts.
PERLLIBDIR=${PREFIX}/share/shorewall #Directory to install Shorewall Perl module directory
CONFDIR=/etc #Directory where subsystem configurations are installed
SBINDIR=/sbin #Directory where system administration programs are installed
MANDIR= #Directory where manpages are installed.
INITDIR=/etc/init.d #Directory where SysV init scripts are installed.
INITFILE=$PRODUCT #Name of the product's installed SysV init script
INITSOURCE=init.openwrt.sh #Name of the distributed file to be installed as the SysV init script
ANNOTATED= #If non-zero, annotated configuration files are installed
SYSCONFDIR=${CONFDIR}/sysconfig #Directory where SysV init parameter files are installed
SYSCONFFILE=sysconfig #Name of the distributed file to be installed in $SYSCONFDIR
SERVICEDIR= #Directory where .service files are installed (systems running systemd only)
SERVICEFILE= #Name of the file to install in $SYSTEMD. Default is $PRODUCT.service
SPARSE= #If non-empty, only install $PRODUCT/$PRODUCT.conf in $CONFDIR
VARLIB=/lib #Directory where product variable data is stored.
VARDIR=${VARLIB}/$PRODUCT #Directory where product variable data is stored.
DEFAULT_PAGER= #Pager to use if none specified in shorewall[6].conf
shorewall6-5.2.3.4/lib.uninstaller 0000664 0000000 0000000 00000004411 13531077635 015513 0 ustar root root #
# Shorewall 5.2 -- /usr/share/shorewall/lib.installer
#
# (c) 2017 - Tom Eastep (teastep@shorewall.net)
# (c) 2017 - Matt Darfeuille (matdarf@gmail.com)
#
# Complete documentation is available at http://shorewall.net
#
# This program is part of Shorewall.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by the
# Free Software Foundation, either version 2 of the license or, at your
# option, any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, see = ...
#
#
################################################################################################
use strict;
#
# Build updates this
#
use constant {
VERSION => '5.2.3.4'
};
my %params;
my %options;
my %aliases = ( VENDOR => 'HOST',
SHAREDSTATEDIR => 'VARLIB',
DATADIR => 'SHAREDIR' );
for ( @ARGV ) {
die "ERROR: Invalid option specification ( $_ )" unless /^(?:--)?(\w+)=(.*)$/;
my $pn = uc $1;
my $pv = $2 || '';
$pn = $aliases{$pn} if exists $aliases{$pn};
$params{$pn} = $pv;
}
use File::Basename;
chdir dirname($0);
my $vendor = $params{HOST};
my $rcfile;
my $rcfilename;
unless ( defined $vendor ) {
if ( -f '/etc/os-release' ) {
my $id = `cat /etc/os-release | grep ^ID=`;
chomp $id;
$id =~ s/ID=//;
if ( $id eq 'fedora' || $id eq 'rhel' ) {
$vendor = 'redhat';
} elsif ( $id eq 'opensuse' ) {
$vendor = 'suse';
} elsif ( $id eq 'ubuntu' || $id eq 'debian' ) {
my $init = `ls -l /sbin/init`;
$vendor = $init =~ /systemd/ ? 'debian.systemd' : 'debian.sysvinit';
} elsif ( $id eq 'alt' || $id eq 'basealt' || $id eq 'altlinux' ) {
$vendor = 'alt';
} else {
$vendor = $id;
}
}
$params{HOST} = $vendor;
$params{HOST} =~ s/\..*//;
}
if ( defined $vendor ) {
if ( $vendor eq 'debian' && -f '/etc/debian_version' ) {
if ( -l '/sbin/init' ) {
if ( readlink('/sbin/init') =~ /systemd/ ) {
$rcfilename = 'shorewallrc.debian.systemd';
} else {
$rcfilename = 'shorewallrc.debian.sysvinit';
}
} else {
$rcfilename = 'shorewallrc.debian.sysvinit';
}
} else {
$rcfilename = $vendor eq 'linux' ? 'shorewallrc.default' : 'shorewallrc.' . $vendor;
}
unless ( -f $rcfilename ) {
die qq("ERROR: $vendor" is not a recognized host type);
} elsif ( $vendor eq 'default' ) {
$params{HOST} = $vendor = 'linux';
} elsif ( $vendor =~ /^debian\./ ) {
$params{HOST} = $vendor = 'debian';
}
} else {
if ( -f '/etc/debian_version' ) {
$vendor = 'debian';
if ( -l '/sbin/init' ) {
if ( readlink( '/sbin/init' ) =~ /systemd/ ) {
$rcfilename = 'shorewallrc.debian.systemd';
} else {
$rcfilename = 'shorewallrc.debian.sysvinit';
}
} else {
$rcfilename = 'shorewallrc.debian.sysvinit';
}
} elsif ( -f '/etc/altlinux-release' ){
$vendor = 'alt';
$rcfilename = 'shorewallrc.alt';
} elsif ( -f '/etc/redhat-release' ){
$vendor = 'redhat';
$rcfilename = 'shorewallrc.redhat';
} elsif ( -f '/etc/slackware-version' ) {
$vendor = 'slackware';
$rcfilename = 'shorewallrc.slackware';
} elsif ( -f '/etc/SuSE-release' ) {
$vendor = 'suse';
$rcfilename = 'shorewallrc.suse';
} elsif ( -f '/etc/arch-release' ) {
$vendor = 'archlinux';
$rcfilename = 'shorewallrc.archlinux';
} elsif ( `uname` =~ '^Darwin' ) {
$vendor = 'apple';
$rcfilename = 'shorewallrc.apple';
} elsif ( `uname` =~ /^Cygwin/i ) {
$vendor = 'cygwin';
$rcfilename = 'shorewallrc.cygwin';
} else {
$vendor = 'linux';
$rcfilename = 'shorewallrc.default';
}
$params{HOST} = $vendor;
}
my @localtime = localtime;
my @abbr = qw( Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec );
if ( $vendor eq 'linux' ) {
printf "INFO: Creating a generic Linux installation - %s %2d %04d %02d:%02d:%02d\n\n", $abbr[$localtime[4]], $localtime[3], 1900 + $localtime[5] , @localtime[2,1,0];;
} else {
printf "INFO: Creating a %s-specific installation - %s %2d %04d %02d:%02d:%02d\n\n", $params{HOST}, $abbr[$localtime[4]], $localtime[3], 1900 + $localtime[5] , @localtime[2,1,0];;
}
open $rcfile, '<', $rcfilename or die "Unable to open $rcfilename for input: $!";
while ( <$rcfile> ) {
s/\s*#.*//;
unless ( /^\s*$/ ) {
chomp;
die "ERROR: Invalid entry ($_) in $rcfilename, line $." unless /\s*(\w+)=(.*)/;
$options{$1} = $2;
}
}
close $rcfile;
while ( my ( $p, $v ) = each %params ) {
$options{$p} = ${v};
}
my $outfile;
open $outfile, '>', 'shorewallrc' or die "Can't open 'shorewallrc' for output: $!";
if ( $ENV{SOURCE_DATE_EPOCH} ) {
printf $outfile "#\n# Created by Shorewall Core version %s configure.pl - %s\n", VERSION, `date --utc --date=\"\@$ENV{SOURCE_DATE_EPOCH}\"`;
} else {
printf $outfile "#\n# Created by Shorewall Core version %s configure.pl - %s %2d %04d %02d:%02d:%02d\n", VERSION, $abbr[$localtime[4]], $localtime[3], 1900 + $localtime[5] , @localtime[2,1,0];
}
print $outfile "# rc file: $rcfilename\n#\n";
print $outfile "# Input: @ARGV\n#\n" if @ARGV;
if ( $options{VARLIB} ) {
unless ( $options{VARDIR} ) {
$options{VARDIR} = '${VARLIB}/${PRODUCT}';
}
} elsif ( $options{VARDIR} ) {
$options{VARLIB} = $options{VARDIR};
$options{VARDIR} = '${VARLIB}/${PRODUCT}';
}
$options{SERVICEDIR}=$options{SYSTEMD} unless $options{SERVICEDIR};
for ( qw/ HOST
PREFIX
SHAREDIR
LIBEXECDIR
PERLLIBDIR
CONFDIR
SBINDIR
MANDIR
INITDIR
INITSOURCE
INITFILE
AUXINITSOURCE
AUXINITFILE
SERVICEDIR
SERVICEFILE
SYSCONFFILE
SYSCONFDIR
SPARSE
ANNOTATED
VARLIB
VARDIR
DEFAULT_PAGER / ) {
my $val = $options{$_} || '';
print "$_=$val\n";
print $outfile "$_=$val\n";
}
close $outfile;
1;
shorewall6-5.2.3.4/COPYING 0000664 0000000 0000000 00000043162 13531060406 013510 0 ustar root root GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor,
Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
Copyright (C) 19yy
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) 19yy name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, the commands you use may
be called something other than `show w' and `show c'; they could even be
mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the program, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
Public License instead of this License.
shorewall6-5.2.3.4/releasenotes.txt 0000664 0000000 0000000 00000117477 13531077635 015736 0 ustar root root ----------------------------------------------------------------------------
S H O R E W A L L 5 . 2 . 3 . 4
-------------------------------
A U G U S T 2 5 , 2 0 1 9
----------------------------------------------------------------------------
I. PROBLEMS CORRECTED IN THIS RELEASE
II. KNOWN PROBLEMS REMAINING
III. NEW FEATURES IN THIS RELEASE
IV. MIGRATION ISSUES
V. PROBLEMS CORRECTED AND NEW FEATURES IN PRIOR RELEASES
----------------------------------------------------------------------------
I. P R O B L E M S C O R R E C T E D I N T H I S R E L E A S E
----------------------------------------------------------------------------
5.2.3.4
1) If multi-queue NFQUEUE (e.g., NFQUEUE(0:1) ) WAS used as a policy,
an error such as the following was previously incorrectly raised.
ERROR: Invalid policy (NFQUEUE(0) /etc/shorewall/policy (line
15)
That has been corrected such that no error is raised.
2) If multi-queue NFQUEUE( e.g., NFQUEUE(0:1,bypass) ) was passed to a
macro, an error such as the following was previously incorrectly
raised:
ERROR: Invalid ACTION (PARAM:1c,bypass)))
/usr/share/shorewall/macro.BitTorrent (line 12)
from /etc/shorewall/rules (line 40)
Now, the NFQUEUE action is correctly substituted for PARAM in
the Macro body.
3) If shorewall[6].conf didn't set AUTOMAKE, the 'update' command
previously produced a new file with 'AUTOMAKE=Yes'. This resulted
in an unexpected change of behavior. Now, the new file contains
'AUTOMAKE=No', which preserves the pre-update behavior.
4) Shorewall-rules(5) incorrectly stated that the 'bypass' option to
NFQUEUE causes the rule to be silently bypassed if there is no
application attached to the queue. The actual behavior is that the
rule acts like ACCEPT in that case. Shorewall-rules(5) has been
corrected.
5.2.3.3
1) Previously, if an ipset was specified in an SPORT column, the
compiler would raise an error similar to:
ERROR: Invalid ipset name () /etc/shorewall/rules (line 44)
That has been corrected.
5.2.3.2
1) Shorewall 5.2 automatically converts and existing 'masq' file to an
equivalent 'snat' file. Regrettably, Shorewall 5.2.3 broke that
automatic update, such that the following error message was issued:
Use of uninitialized value $Shorewall::Nat::raw::currentline in
pattern match (m//) at /usr/share/shorewall/Shorewall/Nat.pm
line 511, <$currentfile> line nnn.
and the generted 'masq' file contains only initial comments.
That has been corrected.
5.2.3.1
1) An issue in the implementation of policy file zone exclusion,
released in 5.2.3 has been resolved. In the original release,
if more than one zone was excluded, then the following error was
raised:
ERROR: 'all' is not allowed in a source zone list
etc/shorewall/policy (line ...)
5.2.3
1) To prevent a helper kernel module from being loaded, it was
previously necessary to list both its current name and its
pre-kernel-2.6.20 name in the DONT_LOAD option in
/etc/shorewall[6].conf. For example, to prevent nf_conntrack_sip
from being loaded, it was necessary to also list ip_conntrack_sip
in DONT_LOAD. That is no longer necessary.
----------------------------------------------------------------------------
I I. K N O W N P R O B L E M S R E M A I N I N G
----------------------------------------------------------------------------
1) On systems running Upstart, shorewall-init cannot reliably secure
the firewall before interfaces are brought up.
2) The 'enable', 'reenable' and 'disable' commands do not work
correctly in configurations with USE_DEFAULT_RT=No and optional
providers listed in the DUPLICATE column.
3) While the 'ip' utility now accepts IPv6 routes with multiple
'nexthop' destinations, these routes are not balanced. They are
rather instantiated as a sequence of single routes with different
metrics. Furthermore, the 'ip route replace' command fails on
such routes. Beginning with Shorewall6 5.0.15, the generated script
uses a "delete..add.." sequence on these routes rather than a
single "replace" command.
----------------------------------------------------------------------------
I I I. N E W F E A T U R E S I N T H I S R E L E A S E
----------------------------------------------------------------------------
1) Zone exclusion (e.g., "all!z2,z2,...") is now supported in the
policy file.
2) With the availability of zone exclusion in the rules file, 'all[+]-'
and 'any[+]-' are equivalent to 'all[+]!$FW' and 'any[+]!$FW'
respectively. Beginning with this release, the former are
deprecated in favor of the latter and will result in a warning
message, if used.
3) Internal documentaton of the undocumented 'test' parameter to
compiler.pl has been added (it is used by the regression test
library to suppress versions and date/times from the generated
script).
4) The LOAD_HELPERS_ONLY option has been removed from
shorewall[6].conf. Hereafter, Shorewall[6] will behave as if
LOAD_HELPERS_ONLY=Yes had been specified.
----------------------------------------------------------------------------
I V. M I G R A T I O N I S S U E S
----------------------------------------------------------------------------
If you are migrating from Shorewall 4.6.x or earlier, please see
http://www.shorewall.org/pub/shorewall/5.0/shorewall-5.0.15/releasenotes.txt
Immediately after installing Shorewall 5.2.x, we recommend that you run
'shorewall[6] update'. This command will handle many of the migration
issues described here.
------------------------------------------------------------------------
I S S U E S M I G R A T I N G T O S H O R E W A L L 5 . 2
F R O M S H O R E W A L L 5 . 0
------------------------------------------------------------------------
If you are migrating from Shorewall 5.0, this section will
familiarize you with the changes in Shorewall 5.1 that may affect
your configuration.
1) Shorewall 5.1 now has a single CLI program, ${SBINDIR}/shorewall
(normally /sbin/shorewall). This program performs all of the same
functions previously performed by /sbin/shorewall,
/sbin/shorewall6, /sbin/shorewall-lite and /sbin/shorewall6-lite
and is installed as part of the Shorewall-core package. It's
default 'personality' is determined by the Shorewall packages
installed:
a) If the Shorewall package is installed, then by default,
/sbin/shorewall behaves as in prior versions.
b) If the Shorewall package is not installed, but the
Shorewall-lite package is present, then /sbin/shorewall behaves
as did /sbin/shorewall-lite in prior versions.
c) If neither the Shorewall nor Shorewall-lite packages are
installed, but the Shorewall6-lite package is installed, then
/sbin/shorewall behaves as did /sbin/shorewall6-lite in prior
versions.
The program's personality can be altered through use of two new
options.
-6 When specified, changes the personality from Shorewall to
Shorewall6 or from Shorewall-lite to Shorewall6-lite.
-l When specified, changes the personality from Shorewall to
Shorewall-lite or from Shorewall6 to Shorewall6-lite. This
option is only required when both the standard package
(Shorewall or Shorewall6) and the corresponding -lite package
are installed on the system.
The following is a comparison of Shorewall 5.0 and Shorewall 5.1
with respect to the CLI invocation:
All four packages installed:
Shorewall 5.0 Shorewall 5.1
shorewall shorewall
shorewall6 shorewall -6
shorewall-lite shorewall -l
shorewall6-lite shorewall -6l
Only Shorewall-lite and Shorewall6-lite installed:
Shorewall 5.0 Shorewall 5.1
shorewall-lite shorewall
shorewall6-lite shorewall -6
A single shorewall(8) manpage now describes the CLI.
The shorewall6(8), shorewall-lite(8) and shorewall6-lite(8)
manpages are now minimal and refer the reader to shorewall(8).
For backward compatibility, Shorewall6, Shorewall-lite and
Shorewall6-lite install symlinks $SBINDIR/shorewall6,
$SBINDIR/shorewall-lite and
$SBINDIR/shorewall6-lite respectively. When the shorewall program
is invoked through one of these symlinks, it adopts the appropriate
personality.
2) The CHAIN_SCRIPTS option in the .conf files has been eliminated,
and the compiler no longer looks for script files with the same
name as a chain or action.
If you are using such files, you will need to convert them into
equivalent ?begin perl .... ?end perl text or to use the
IP[6]TABLES target and/or inline matches.
For the common case where you have an action xxx with an empty
action.xxx file and have perl code in a file named xxx, the
compiler will now generate a fatal error:
ERROR: File action.xxx is empty and file xxx exists - the two
must be combined as described in the Migration
Considerations section of the Shorewall release notes
For information about resolving this error, see
http://www.shorewall.org/Shorewall-5.html#idp41228128.
This issue is not handled by 'shorewall update' and must be
corrected manually.
4) The Netfilter team have removed support for the rawpost table, so
Shorewall no longer supports features requiring that table
(stateless netmapping in the netmap file). The good news is that,
since kernel 3.7, Netfilter supports stateful IPv6 network mapping
which is now also supported in Shorewall6 (see
shorewall6-netmap(5)).
This issue is not handled by 'shorewall update' and must be
corrected manually.
5) The (undocumented) Makefiles haven't been maintained for many
releases and have been removed.
6) Beginning with Shorewall 5.1.2, The DROP_DEFAULT, REJECT_DEFAULT,
etc. options may now specify a comma-separated list of actions
rather than just a single action. The actions are invoked in the
order in which they are listed and each action may optionally be
followed by a colon (":") and a log level. The POLICY column in
shorewall[6]-policy can now specify a similar list of actions. In
that file, the list may be preceded by a plus sign ("+"), in which
case the listed actions will be in addition to those listed in the
related _DEFAULT setting in shorewall[6].conf.
With these changes, the Drop and Reject policy actions are now
deprecated in favor of a list of smaller actions. A warning is
issued when these deprecated actions are used; the warning refers
the reader to http://www.shorewall.org/Actions.html#Default.
This issue is partially handled by 'shorewall update' - see
the 5.2 issues below.
7) Beginning with Shorewall 5.1.2, the allowBcast, dropBcast, and
Broadcast no longer handle multicast. Multicast is handeled
separately in actions allowMcast, dropMcast and Multicast. The
now-deprecated Drop and Reject policy actions have been modified so
that they continue to silently drop multicast packets.
8) According to the Netfilter team (see
https://patchwork.kernel.org/patch/9198133/), the --nflog-range option
of the NFLOG target has never worked correctly, and they have
deprecated that option in favor of the --nflog-size option.
To accomodate this change, Shorewall 5.1.5 added an "--nflog-size
support" (NFLOG_SIZE) Shorewall capability and a USE_NFLOG_SIZE
option in shorewall[6].conf. If USE_NFLOG_SIZE=Yes, then if the
capability is present, Shorewall will use '--nflog-size' in place
of '--nflog-range'. If USE_NFLOG_SIZE=Yes and the capability is not
present, an error is raised.
If you don't use NFLOG or if you use NFLOG with omittted second
parameter or with 0 as the second parameter, and 'shorewall show
capabilities' indicated that --nflog-size support is present, you
may safely set USE_NFLOG_SIZE=Yes.
If you pass a non-zero value as the second parameter to NFLOG and
the '--nflog-size support' capability is present, you need to
verify that those NFLOG messages are as you expect with
USE_NFLOG_SIZE=Yes.
This issue is not handled by 'shorewall update' and must be
corrected manually.
9) The MODULE_SUFFIX option in shorewall[6].conf was eliminated in
Shorewall 5.1.7. Shorewall now finds modules, independent of their
filename suffix.
'shorewall [-6] update' will automatically remove any MODULE_SUFFIX
setting.
10) Beginning with Shorewall 5.1.8, when RESTORE_DEFAULT_ROUTE=Yes the
default route is only restored when there are no enabled
'balance/primary' providers and no enabled fallback providers.
Also beginning with Shorewall 5.1.8, if the default route(s) have
been restored to the 'main' table, and a fallback provider is
successfully enabled, the default route(s) are removed from the
main table.
11) Because restoring default routes to the main routing table can
break the ability of Foolsm and other link status monitors to
properly detect non-functioning provider links, a warning message
is issued when the 'persistent' provider option is specified and
RESTORE_DEFAULT_ROUTE=Yes.
WARNING: When RESTORE_DEFAULT_ROUTE=Yes, the 'persistent' option
may not work as expected
This change was released in Shorewall 5.1.8.
This issue is not handled by 'shorewall update' and must be
corrected manually.
12) Most interface OPTIONS have always been ignored when the INTERFACE
name is '+'. Beginning with the Shorewall 5.1.10 release, a warning
is issued when an ignored option is specified with interface name '+'.
Example: The 'sourceroute' option is ignored when used with
interface name '+'
In many cases, this issue can be worked around by a change similar
to the following:
Original:
net + dhcp,routeback,sourceroute=0
Change to:
net all dhcp,physical=+,routeback,sourceroute=0
--- ----------
As part of this change, interfaces that specify a wildcard physical
interface name will generate a warning if any of the following
options are specified:
accept_ra
arp_filter
arp_ignore
forward
logmartians
proxyarp
proxyndp
routefilter
sourceroute
When the warning is issued, the specified option is then ignored
for the interface.
Example:
WARNING: The 'sourceroute' option is ignored when used with a
wildcard physical name
/etc/shorewall6.universal/interfaces (line 14)
This issue is not handled by 'shorewall update' and must be
corrected manually.
13) INLINE_MATCHES=Yes has been documented as deprecated for some
time, but it has not generated a warning. Beginning with the
Shorewall 5.1.12 release, a warning is issued:
WARNING: Option INLINE_MATCHES=Yes is deprecated
Additionally, each line that requires modification to work with
INLINE_MATCHES=No is flagged with the warning:
WARNING: This entry needs to be changed (replace ';' with ';;')
before the INLINE_MATCHES option is removed in
Shorewall 5.2
You can eliminate the warnings by setting INLINE_MATCHES=No and
by replacing the single semicolon (";") separating inline matches
from the column-oriented part of the rule with two semicolons
(";;") in each entry flagged by the second warning.
This issue is mostly handled by 'shorewall update' - see
the 5.2 issues below.
------------------------------------------------------------------------
I S S U E S M I G R A T I N G T O S H O R E W A L L 5 . 2
F R O M S H O R E W A L L 5 . 0 A N D 5 . 1
------------------------------------------------------------------------
1) The MAPOLDACTIONS option in shorewall.conf has been removed. This
option provided compatibility with releases prior to Shorewall 3.0.
'shorewall update' will remove the setting of this option from
shorewall.conf.
2) The INLINE_MATCH option has been removed. Shorewall now behaves as
if INLINE_MATCH=No had been specified:
- A single semicolon (';') is used to separate column-oriented
input from column-name/value input.
- The preferred method of specifying column-name/value input is to
enclose such input in curly braces ("{....}").
- A pair of semicolons (';;') is used to introduce raw IP[6]TABLES
input. This is true in INLINE and IP[6]TABLES rules as well as
rules with other targets.
As part of this change, 'shorewall update' will replace ';' with
';;' in INLINE and IP[6]TABLES rules. It will also replace ';' by
';;', if ';' is followed by '-m', '-j' or '-g'.
3) With the wide availability of ipset-based blacklisting, the need
for the 'refresh' command has been largely eliminated. As a result,
that command has been removed.
Some users may have been using 'refresh' as a lightweight form of
reload. The most common of these uses seem to be for reloading
traffic shaping after an interface has gone down and come back up.
The best way to handle this situation under 5.2 is to make the
interface 'optional' in your /etc/shorewall[6]/interfaces file,
then either:
- Install Shorewall-init and enable IFUPDOWN; or
- Use the 'reenable' command when the interface comes back up
in place of the 'refresh' command.
4) The following deprecated macros and actions have been removed:
Action A_AllowICMPs - use AllowICMPs(A_ACCEPT)
Action A_Drop - see below
Action A_Reject - see below
Action Drop - see below
Action Reject - see below
Macro SNMPTrap - use SNMPtrap
The [A_]Drop and [A_]Reject actions are used primarily as policy
actions. As part of this change, 'shorewall update' will update
DROP_DEFAULT=[A_]Drop and REJECT_DEFAULT=[A_]Reject as follows:
IPv4
DROP_DEFAULT=Drop becomes Broadcast(DROP),Multicast(DROP)
DROP_DEFAULT=A_Drop becomes
Broadcast(A_DROP),Multicast(A_DROP)
REJECT_DEFAULT=Reject becomes Broadcast(DROP),Multicast(DROP)
REJECT_DEFAULT=A_Reject becomes
Broadcast(A_DROP),Multicast(A_DROP)
IPv6
DROP_DEFAULT=Drop becomes
AllowICMPs,Broadcast(DROP),Multicast(DROP)
DROP_DEFAULT=A_Drop becomes
AllowICMPs(A_ACCEPT),Broadcast(A_DROP),Multicast(A_DROP)
REJECT_DEFAULT=Reject becomes
AllowICMPs,Broadcast(DROP),Multicast(DROP)
REJECT_DEFAULT=A_Reject becomes
AllowICMPs(A_ACCEPT),Broadcast(A_DROP),Multicast(A_DROP)
The 'update' commmand will also make similar changes in the policy
file.
'shorewall update' does not handle invocations of 'Drop' and
'Reject' within the rules file, or within actions and macros. Those
instances will generate an error which must be corrected manually.
It should also be noted that, in prior releases, Drop and Reject
silently dropped more traffic than their replacements. As a
consequence, you will see more traffic being logged with Shorewall
5.2 than you did on earlier releases. The translations performed
by 'update' can be extended after the update to drop additional
traffic as desired.
5) When AUTOMAKE=Yes, each directory in the CONFIG_PATH was originally
searched recursively for files newer than the compiled script. That
was changed in Shorewall 5.1.10.2 such that only the listed
directories themselves were searched. That broke some
configurations that played tricks with embedded SHELL such as:
SHELL cat /etc/shorewall/rules.d/loc/*.rules
Prior to 5.1.10.2, a change to a file in or adding a file to
/etc/shorewall/rules.d/loc/ would trigger recompilation. Beginning
with 5.1.10.2, such changes would not trigger recompilation.
Beginning with Shorewall 5.2.0, the pre-5.1.10.2 behavior can be
obtained by setting AUTOMAKE=recursive.
Also beginning with Shorewall 5.2.0, AUTOMAKE may be set to a
numeric which specifies how deeply each listed directory is
to be searched. AUTOMAKE=1 only searches each directory itself and
is equivalent to AUTOMAKE=Yes. AUTOMAKE=2 will search each
directory and its immediate sub-directories; AUTOMAKE=3 will search
each diretory, each of its immediate sub-directories, and each of
their immediate sub-directories, etc.
6) Support for the deprecated 'masq' file has been deleted. Any
existing 'masq' file will automatically be converted to the
equivalent 'snat' file.
7) Where two or more providers share a network interface, the
'optional' interface/provider option has never worked correctly.
Beginning with Shorewall 5.2.1, the 'optional' option is disallowed
on such interfaces and providers.
8) With the availability of zone exclusion in the rules file, 'all[+]-'
and 'any[+]-' are equivalent to 'all[+]!$FW' and 'any[+]!$FW'
respectively. Beginning with Shorewall 5.2.3, the former are
deprecated in favor of the latter and will result in a warning
message, if used.
9) Beginning with Shorewall 5.2.3, the LOAD_HELPERS_ONLY option in
shorewall[6].conf has been removed, and the behavior is as if
LOAD_HELPERS_ONLY=Yes had been specified. 'shorewall[6] update'
will remove the option from shorewall[6].conf.
----------------------------------------------------------------------------
V. N O T E S F R O M O T H E R 5 . 2 R E L E A S E S
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 5 . 2 . 2
----------------------------------------------------------------------------
1) This release includes defect repair through Shorewall 5.2.1.4.
2) When processing inline matches, the compiler previously inserted
the matches before the column-generated matches if there was a plus
sign ("+") anywhere in the matches. Now, it only does so if the
first non-blank character in the matches is a plus sign.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 5 . 2 . 1
----------------------------------------------------------------------------
1) New macros have been contributed by Vincas Dargis:
Bitcoin
Tor
ONCRPC
Additionally, Tuomo Soini has contributed a WUDO (Windows Update
Delivery Optimization) macro.
2) The Perl modules have undergone some cleanup/optimization.
3) Given that recent kernels have dropped ULOG support, use of ULOG in
Shorewall is now deprecated and results in a warning message. The
warning can be eliminated by switching to NFLOG and ulogd2.
4) Shorewall can now detect interface default gateways configured by
Network Manager.
5) Inline matches are now supported in the 'conntrack' file.
6) In the 'accounting' file, Inline matches in an INLINE(...) rule now
allow a leading '+' to cause the matches to be evaluated before
those generated by the column specifications.
7) If view of the fact that some modems take an eternity to recover
from a power failure, the limit of the 'wait' interface option
setting has been increased from 120 seconds (2 minutes) to 300
seconds (5 minutes).
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 5 . 2 . 1
----------------------------------------------------------------------------
5.2.1.4
1) A change in 5.2.0.5 that corrected an ip[6]tables error in the
UNTRACKED section of the rules file, changed the name of the chain
used to hold UNTRACKED rules. Previously, the chain was named
&z1-z2, where 'z1' is the source zone and 'z2' is the
destination; after the change, the chain was named =z1-z2.
Unfortunately, some log messages generated out of these chains
still referred to &z1-z2; that has been corrected.
2) Some dead/silly code has been removed from two functions in
the Chains.pm Perl module. The two functions have been combined
into a single function.
3) When the RATE column contains both a source and a destination rate,
it was previously impossible to specifiy a netmask (VLSM) on either
rate. Attempting to specify a mask would result in:
ERROR: Invalid rate (...)
That has been corrected. Note that when specifying a
netmask, the leading 's' or 'd' may not be omitted.
4) Several typos in the man pages have been corrected (Roberto
Sánchez).
5.2.1.3
1) When a configuration had optional interfaces but no providers, the
'status -i' command previously would fail to show interface status
for interfaces that had not been disabled or enabled since the
last start, restart or reload. That has been corrected.
5.2.1.2
1) The fix for DOCKER=Yes in 5.2.1.1 inadvertantly results in an
assertion failure when processing a 'check -r' command when
DOCKER=Yes. That has been corrected. As part of that change,
empty 'cat' commands in the generated script were eliminated.
2) When the HELPER target is used with an empty HELPER column, the
error message produced previously incorrectly read:
ERROR: HELPER require requires that ...
That has been corrected so that the message now reads:
ERROR: HELPER requires that ...
3) On Centos 7, the following journal message appeared when Shorewall
attempted to load kernel modules:
nf_log: can't load ipt_ULOG, conflicting nfnetlink_log already
loaded
To eliminate that message, Shorewall no longer attempts to load
ipt_ULOG. Note that most current distributions no longer support
ULOG. Current users of ULOG should convert to using NFLOG at the
earliest opportunity.
5.2.1.1
1) The Perl module versions were not updated for the 5.2.1
release. That has been corrected.
2) The lib.common file previously confused Emacs such that editing the
file in shell mode was awkward. Because lib.common is included in
compiled scripts, this defect also made editing a compiled script
awkward. The issue has been resolved, so that the file now renders
properly in Emacs's shell mode.
3) Previously, if ip6tables-restore failed during Shorewall6 start,
restart or reload, the resulting error message indicated that
iptables-load had failed. That has been corrected.
4) Setting Docker=Yes did not work correctly with Docker version
18.03.1-ce. In that version, the DOCKER-ISOLATION chain was
replaced by a pair of chains: DOCKER-ISOLATION-STAGE-1 and
DOCKER-ISOLATION-STAGE-2. That has been corrected. As part of this
change, Shorewall now correctly handles the DOCKER-USER chain as
well as the two new isolation chains.
5) Previously, if there were multiple 'balance' providers and more
than one of them were experiencing carrier loss, then the 'enable' and
'disable' operations could fail. That has been corrected.
5.2.1
1) This release contains defect repair up through Shorewall 5.2.0.5.
2) Previously, if:
a) IP[6]TABLES was not set in shorewall[6].conf; and
b) The ip[6]tables binary was not found on the PATH.
then a shell 'not found' error on 'fatal-error' was generated. That
has been corrected (Matt Darfeuille)
3) A number of files in the Shorewall-common package have had their
heading version updated to version 5.2 (Matt Darfeuille).
4) Previously, if statistical load balancing ('load=' in
provider OPTIONS) was configured on providers that shared an
interface, then the compiler would die with an assertion
failure. That has been corrected so that this combination now works
as expected.
5) Where two or more providers share a network interface, the
'optional' interface/provider option has never worked correctly.
Beginning with this release, the 'optional' option is disallowed
on such interfaces and providers.
6) Previously, when rate limiting was applied to a DNAT or
REDIRECT rule, rate limiting was applied to the accompanying
ACCEPT rule. Since logging is applied in the DNAT/REDIRECT rule, if
the connection failed the rate limit then the connection attempt
could be logged twice - once in the nat table and once when the
applicable policy was applied. Beginning with this release, rate
limiting is applied to the DNAT/REDIRECT rule so that no nat-table
logging occurs if the connection attempt exceeds the rate limit.
7) Some regular expressions used in Shorewall's Perl code will be
disallowed by Perl version 5.23. These have been changed to be
acceptable to that version of Perl.
8) Previously, if SNAT(detect) was used on an optional interface and
the resulting ip[6]tables rule was unreachable, then invalid shell
code similar to the following was generated:
if [ "$SW_PPP1_ADDRESS" != 0.0.0.0 ]; then
fi
That has been corrected such that the above code is not generated
and a warning message is issued, indicating that the entry generated
no ip[6]tables rule.
----------------------------------------------------------------------------
N E W F E A T U R E S I N 5 . 2 . 1
----------------------------------------------------------------------------
5.2.1.2
1) A new variable SW_CONFDIR has been added. $SW_CONFDIR evaluates to
$CONFDIR/shorewall[6] if no directory name is passed to a compile,
check, start, restart or reload command. If a directory name is
passed to one of these commands, then $SW_CONFDIR expands to that
directory name.
5.2.1
1) New macros for IPFS (https://ipfs.io/) have been contributed by
Răzvan Sandu.
2) Several new man pages have been added:
- shorewall-addresses(5) describes specification of addresses in
shorewall configuration files.
- shorewall-files(5) describes the shorewall configuration files
together with features common to multiple files.
- shorewall-logging(5) describes shorewall's logging facilities.
- shorewall-names(5) describes restrictions on names used in
Shorewall configuration files.
Additional man pages will be included in future 5.2.1 pre-releases.
3) In the SOURCE and DEST columns, it is now possible to exclude an
interface by preceding the interface name with '!'. This is useful
for excluding the loopback interface (lo).
Example from the mangle file:
#ACTION SOURCE DEST
DROP:T 127.0.0.0/8 !lo
4) The MARK, CONNMARK, SAVE and RESTORE commands may now be placed in
the nat table through used of new chain designators in the mangle
file:
NP - nat table PREROUTING chain
NI - nat table INPUT chain
NO - nat table OUTPUT chain
NT - nat table POSTROUTING chain
5) When TC_EXPERT=Yes, it is now possible to specify any mark/mask
values that are displayed by the 'show marks' command, including
the Exclusion and TPROXY values.
6) The configure and install scripts now support ALT Linux (Alexey
Shabalin).
7) The verbosity of the 'remote-*' CLI commands has been increased
(Matt Darfeuille).
8) You may now specify a VLSM in the RATE columns of the policy and
rules files, when per-IP limiting is used. This results in one hash
table entry per subnet rather than one entry per hosts, and applies
the limit to the subnet. See shorewall-policy(5) and
shorewall-rules(5) for details. This provides a means for reducing
the size of the hash tables.
9) You man now specify the number of hash table buckets and the
maximum number of hash table entries in the RATE columns of the
policy and rules files, when per-IP limiting is used. This allows
you to increase the size of the tables to more fully handle DDOS
attacks. See shorewall-policy(5) and shorewall-rules(5) for
details.
10) Eric Teeter has contributed a macro for Cockpit.
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N 5 . 2 . 0
----------------------------------------------------------------------------
5.2.0.1
1) This release includes defect repair through Shorewall 5.1.12.4.
2) The getrc and getcaps commands added in 5.2.0 did not read the
params file. That has been corrected.
3) A shell syntax error in the code that implements the 'ipdecimal'
command has been corrected.
5.2.0
1) This release includes defect repair through Shorewall 5.1.12.3.
2) Previously, optimize category 8 (combine identical chains) was
applied before optimize category 16 (eliminate duplicate rules,
...). This could (and has) resulted in uncombined identical chains
in the final ruleset. Beginning with this release:
a) Optimize category 16 will be applied before optimize category 8.
b) If optimize category 8 combined any chains, then optimize
category 16 will be applied again.
This change ensures that the final ruleset has no duplicate chains
and that all combatible adjacent port and state rules are combined.
3) Previously, use of &lo would result in an error:
ERROR: Can't determine the IP address of lo: Firewall state not changed
That problem has been corrected such that &lo always expands to
127.0.0.1 (IPv4) or ::1 (IPv6).
----------------------------------------------------------------------------
N E W F E A T U R E S I N 5 . 2 . 0
----------------------------------------------------------------------------
1) The MAPOLDACTIONS option in shorewall.conf has been removed. This
option provided compatibility with releases prior to Shorewall 3.0.
'shorewall update' will remove the setting of this option from
shorewall.conf.
2) The INLINE_MATCH option has been removed. Shorewall now behaves as
if INLINE_MATCH=No had been specified:
- A single semicolon (';') is used to separate column-oriented
input from column-name/value input.
- The preferred method of specifying column-name/value input is to
enclose such input in curly braces ("{....}").
- A pair of semicolons (';;') is used to introduce raw IP[6]TABLES
input. This is true in INLINE and IP[6]TABLES rules as well as
rules with other targets.
As part of this change, 'shorewall update' will replace ';' with
';;' in INLINE and IP[6]TABLES rules.
3) With the wide availability of ipset-based blacklisting, the need
for the 'refresh' command has been largely eliminated. As a result,
that command has been removed.
Some users may have been using 'refresh' as a lightweight form of
reload. The most common of these uses seem to be for reloading
traffic shaping after an interface has gone down and come back up.
The best way to handle this situation under 5.2 is to make the
interface 'optional' in your /etc/shorewall[6]/interfaces file,
then either:
- Install Shorewall-init and enable IFUPDOWN; or
- Use the 'reenable' command when the interface comes back up
in place of the 'refresh' command.
4) The following deprecated macros and actions have been removed:
Action A_AllowICMPs - use AllowICMPs(A_ACCEPT)
Action A_Drop - see below
Action A_Reject - see below
Action Drop - see below
Action Reject - see below
Macro SNMPTrap - use SNMPtrap
The [A_]Drop and [A_]Reject actions are used primarily as policy
actions. As part of this change, 'shorewall update' will update
DROP_DEFAULT=[A_]Drop and REJECT_DEFAULT=[A_]Reject as follows:
IPv4
DROP_DEFAULT=Drop becomes Broadcast(DROP),Multicast(DROP)
DROP_DEFAULT=A_Drop becomes
Broadcast(A_DROP),Multicast(A_DROP)
REJECT_DEFAULT=Reject becomes Broadcast(DROP),Multicast(DROP)
REJECT_DEFAULT=A_Reject becomes
Broadcast(A_DROP),Multicast(A_DROP)
IPv6
DROP_DEFAULT=Drop becomes
AllowICMPs,Broadcast(DROP),Multicast(DROP)
DROP_DEFAULT=A_Drop becomes
AllowICMPs(A_ACCEPT),Broadcast(A_DROP),Multicast(A_DROP)
REJECT_DEFAULT=Reject becomes
AllowICMPs,Broadcast(DROP),Multicast(DROP)
REJECT_DEFAULT=A_Reject becomes
AllowICMPs(A_ACCEPT),Broadcast(A_DROP),Multicast(A_DROP)
See the Migration Issues for additional information.
5) A 'show saves' command has been added to list the snapshots
created using the 'save' command.
Example:
root@gateway:~# shorewall show saves
Shorewall 5.2.0 Saves at gateway - Thu Feb 15 11:58:37 PST 2018
Saved snapshots are:
Feb 15 10:08 foo
Feb 14 12:34 restore (default)
root@gateway:~#
The snapshots are listed by creation time from latest to
earliest. If the name of one matches the RESTOREFILE setting, that
snapshot is marked as the default for the 'restore' command.
6) For installing into a Sandbox, the file shorewallrc.sandbox has
been added to Shorewall-core. See
http://www.shorewall.org/install.htm#idm327.
7) The "Use Pkttype Match (USEPKTTYPE)" capability is no longer used
and has been deleted. This removal has introduced a new
capabilities version.
8) When a log message is issued from a chain that relates to a pair of
zones (e.g, 'fw-net'), the chain name normally appears in the log
message (unless LOGTAGONLY=Yes and a log tag is specified). This
can prevent OPTIMIZE category 8 from combining chains which are
identical except for chain names in logging rules. The new
LOG_ZONE option in shorewall[6].conf allows for only the source or
destination zone to appear in the messages by setting LOG_ZONE to
'src' or 'dst' respectively. If LOG_ZONE=both (the default), then
the full chain name is included in log messages
Setting LOG_ZONE=src has been shown to decrease the size of the
generated ruleset by more than 10 prcent in some cases. Your
results may vary.
9) Traditionally, when OPTIMIZE category 8 is enabled, identical
chains are combined under a name beginning with '~comb' or
'~blacklist'. Beginning with this release, setting
RENAME_COMBINED=Yes (the default) in shorewall[6].conf retains that
behavior. If RENAME_COMBINED=No, identical chains are combined
under the original name of one of the chains.
10) When AUTOMAKE=Yes, each directory in the CONFIG_PATH was originally
searched recursively for files newer than the compiled script. That
was changed in Shorewall 5.1.10.2 such that only the listed
directories themselves were searched. That broke some
configurations that played tricks with embedded SHELL such as:
SHELL cat /etc/shorewall/rules.d/loc/*.rules
Prior to 5.1.10.2, a change to a file in or adding a file to
/etc/shorewall/rules.d/loc/ would trigger recompilation. Beginning
with 5.1.10.2, such changes would not trigger
recompilation.
Beginning with this release, the pre-5.1.10.2 behavior can be
obtained by setting AUTOMAKE=recursive.
Also beginning with this release, AUTOMAKE may be set to a numeric
which specifies how deeply each listed directory is to be
searched. AUTOMAKE=1 only searches each directory itself and is
equivalent to AUTOMAKE=Yes. AUTOMAKE=2 will search each directory
and its immediate sub-directories; AUTOMAKE=3 will search each
diretory, each of its immediate sub-directories, and each of their
immediate sub-directories, etc.
11) Previously, the maximum depth of INCLUDEs was four (although the
documentation gave the limit as three). Beginning with this
release, that limit has been raised to 20.
12) Support for the deprecated 'masq' file has been deleted. Any
existing 'masq' file will automatically be converted to the
equivalent 'snat' file.
13) Three new shorewall commands have been implemented:
a) show rc
Displays the contents of the shorewallrc file
($SHAREDIR/shorewall/shorewallrc).
b) getcaps
Generates a capabilities file on a remote system and copies it
to a directory on the local system.
c) getrc
Copies the shorewallrc file from a remote system to a directory
on the local system.
See shorewall(8) for details.
Implemented by Matt Darfeuille
shorewall6-5.2.3.4/sysconfig 0000664 0000000 0000000 00000000331 13531060406 014373 0 ustar root root #
# Global start/restart/reload/stop options
#
OPTIONS=""
#
# Start options
#
STARTOPTIONS=""
#
# Restart options
#
RESTARTOPTIONS=""
#
# Reload options
#
RELOADOPTIONS=""
#
# Stop options
#
STOPOPTIONS=""
# EOF
shorewall6-5.2.3.4/init.debian.sh 0000775 0000000 0000000 00000006257 13531060406 015204 0 ustar root root #!/bin/sh
### BEGIN INIT INFO
# Provides: shorewall6
# Required-Start: $network $remote_fs
# Required-Stop: $network $remote_fs
# Default-Start: S
# Default-Stop: 0 1 6
# Short-Description: Configure the firewall at boot time
# Description: Configure the firewall according to the rules specified in
# /etc/shorewall6
### END INIT INFO
. /lib/lsb/init-functions
SRWL='/sbin/shorewall -6'
SRWL_OPTS="-tvv"
WAIT_FOR_IFUP=/usr/share/shorewall/wait4ifup
test -n ${INITLOG:=/var/log/shorewall6-init.log}
test -x $SRWL || exit 0
test -x $WAIT_FOR_IFUP || exit 0
test -n "$INITLOG" || {
echo "INITLOG cannot be empty, please configure $0" ;
exit 1;
}
if [ "$(id -u)" != "0" ]
then
echo "You must be root to start, stop or restart \"Shorewall6 firewall\"."
exit 1
fi
echo_notdone () {
if [ "$INITLOG" = "/dev/null" ] ; then
echo "not done."
else
echo "not done (check $INITLOG)."
fi
exit 1
}
not_configured () {
echo "#### WARNING ####"
echo "The firewall won't be started/stopped unless it is configured"
if [ "$1" != "stop" ]
then
echo ""
echo "Please read about Debian specific customization in"
echo "/usr/share/doc/shorewall6/README.Debian.gz."
fi
echo "#################"
exit 0
}
#
# The installer may alter this
#
. /usr/share/shorewall/shorewallrc
# check if shorewall is configured or not
if [ -f "${SYSCONFDIR}/shorewall6" ]
then
. ${SYSCONFDIR}/shorewall6
SRWL_OPTS="$SRWL_OPTS $OPTIONS"
if [ "$startup" != "1" ]
then
not_configured
fi
else
not_configured
fi
[ "$INITLOG" = "/dev/null" ] && SHOREWALL_INIT_SCRIPT=1 || SHOREWALL_INIT_SCRIPT=0
export SHOREWALL_INIT_SCRIPT
# wait for an unconfigured interface
wait_for_pppd () {
if [ "$wait_interface" != "" ]
then
for i in $wait_interface
do
$WAIT_FOR_IFUP $i 90
done
fi
}
# start the firewall
shorewall6_start () {
printf "Starting \"Shorewall6 firewall\": "
wait_for_pppd
$SRWL $SRWL_OPTS start $STARTOPTIONS >> $INITLOG 2>&1 && echo "done." || echo_notdone
return 0
}
# stop the firewall
shorewall6_stop () {
if [ "$SAFESTOP" = 1 ]; then
printf "Stopping \"Shorewall6 firewall\": "
$SRWL $SRWL_OPTS stop >> $INITLOG 2>&1 && echo "done." || echo_notdone
else
printf "Clearing all \"Shorewall6 firewall\" rules: "
$SRWL $SRWL_OPTS clear >> $INITLOG 2>&1 && echo "done." || echo_notdone
fi
return 0
}
# restart the firewall
shorewall6_restart () {
printf "Restarting \"Shorewall6 firewall\": "
$SRWL $SRWL_OPTS restart $RESTARTOPTIONS >> $INITLOG 2>&1 && echo "done." || echo_notdone
return 0
}
# refresh the firewall
shorewall6_refresh () {
printf "Refreshing \"Shorewall6 firewall\": "
$SRWL $SRWL_OPTS refresh >> $INITLOG 2>&1 && echo "done." || echo_notdone
return 0
}
# status of the firewall
shorewall6_status () {
$SRWL $SRWL_OPTS status && exit 0 || exit $?
}
case "$1" in
start)
shorewall6_start
;;
stop)
shorewall6_stop
;;
refresh)
shorewall6_refresh
;;
force-reload|restart)
shorewall6_restart
;;
status)
shorewall6_status
;;
*)
echo "Usage: /etc/init.d/shorewall6 {start|stop|refresh|restart|force-reload|status}"
exit 1
esac
exit 0
shorewall6-5.2.3.4/INSTALL 0000664 0000000 0000000 00000001711 13531060406 013500 0 ustar root root Shoreline Firewall (Shorewall) Version 5
----- ----
-----------------------------------------------------------------------------
This program is free software; you can redistribute it and/or modify
it under the terms of Version 2 of the GNU General Public License
as published by the Free Software Foundation.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
---------------------------------------------------------------------------
Please see http://www.shorewall.net/Install.htm for installation
instructions.
shorewall6-5.2.3.4/shorewall6.service 0000664 0000000 0000000 00000001150 13531060406 016114 0 ustar root root #
# The Shoreline Firewall (Shorewall) Packet Filtering Firewall
#
# Copyright 2011 Jonathan Underwood
#
[Unit]
Description=Shorewall IPv6 firewall
Wants=network-online.target
After=network-online.target
After=shorewall.service
Conflicts=ip6tables.service firewalld.service
[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=-/etc/sysconfig/shorewall6
StandardOutput=syslog
ExecStart=/sbin/shorewall -6 $OPTIONS start $STARTOPTIONS
ExecStop=/sbin/shorewall -6 $OPTIONS stop
ExecReload=/sbin/shorewall -6 $OPTIONS reload $RELOADOPTIONS
[Install]
WantedBy=basic.target
shorewall6-5.2.3.4/init.alt.sh 0000775 0000000 0000000 00000004311 13531060406 014527 0 ustar root root #!/bin/sh
#
# Shorewall6 init script
#
# chkconfig: - 28 90
# description: Packet filtering firewall
#
### BEGIN INIT INFO
# Provides: shorewall6
# Required-Start: $local_fs $remote_fs $syslog $network
# Should-Start: $time $named
# Required-Stop:
# Default-Start: 3 4 5
# Default-Stop: 0 1 2 6
# Short-Description: Packet filtering firewall
# Description: The Shoreline Firewall, more commonly known as "Shorewall", is a
# Netfilter (iptables) based firewall
### END INIT INFO
# Do not load RH compatibility interface.
WITHOUT_RC_COMPAT=1
# Source function library.
. /etc/init.d/functions
#
# The installer may alter this
#
. /usr/share/shorewall/shorewallrc
NAME="Shorewall6 firewall"
PROG="shorewall"
SHOREWALL="$SBINDIR/$PROG -6"
LOGGER="logger -i -t $PROG"
# Get startup options (override default)
OPTIONS=
SourceIfNotEmpty $SYSCONFDIR/${PROG}6
LOCKFILE="/var/lock/subsys/${PROG}6"
RETVAL=0
start() {
action $"Applying $NAME rules:" "$SHOREWALL" "$OPTIONS" start "$STARTOPTIONS" 2>&1 | "$LOGGER"
RETVAL=$?
[ $RETVAL -eq 0 ] && touch "$LOCKFILE"
return $RETVAL
}
stop() {
action $"Stoping $NAME :" "$SHOREWALL" "$OPTIONS" stop "$STOPOPTIONS" 2>&1 | "$LOGGER"
RETVAL=$?
[ $RETVAL -eq 0 ] && rm -f "$LOCKFILE"
return $RETVAL
}
restart() {
action $"Restarting $NAME rules: " "$SHOREWALL" "$OPTIONS" restart "$RESTARTOPTIONS" 2>&1 | "$LOGGER"
RETVAL=$?
return $RETVAL
}
reload() {
action $"Reloadinging $NAME rules: " "$SHOREWALL" "$OPTIONS" reload "$RELOADOPTIONS" 2>&1 | "$LOGGER"
RETVAL=$?
return $RETVAL
}
clear() {
action $"Clearing $NAME rules: " "$SHOREWALL" "$OPTIONS" clear 2>&1 | "$LOGGER"
RETVAL=$?
return $RETVAL
}
# See how we were called.
case "$1" in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
reload)
reload
;;
clear)
clear
;;
condrestart)
if [ -e "$LOCKFILE" ]; then
restart
fi
;;
condreload)
if [ -e "$LOCKFILE" ]; then
restart
fi
;;
condstop)
if [ -e "$LOCKFILE" ]; then
stop
fi
;;
status)
"$SHOREWALL" status
RETVAL=$?
;;
*)
echo $"Usage: ${0##*/} {start|stop|restart|reload|clear|condrestart|condstop|status}"
RETVAL=1
esac
exit $RETVAL
shorewall6-5.2.3.4/shorewall6.service.debian 0000664 0000000 0000000 00000001237 13531060406 017343 0 ustar root root #
# The Shoreline Firewall (Shorewall) Packet Filtering Firewall
#
# Copyright 2011 Jonathan Underwood
# Copyright 2015 Tom Eastep
#
[Unit]
Description=Shorewall IPv6 firewall
Wants=network-online.target
After=network-online.target
After=shorewall.service
Conflicts=ip6tables.service firewalld.service
[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=-/etc/default/shorewall6
StandardOutput=syslog
ExecStart=/sbin/shorewall -6 $OPTIONS start $STARTOPTIONS
ExecStop=/sbin/shorewall -6 $OPTIONS clear
ExecReload=/sbin/shorewall -6 $OPTIONS reload $RELOADOPTIONS
[Install]
WantedBy=basic.target
shorewall6-5.2.3.4/configure 0000775 0000000 0000000 00000012473 13531077635 014401 0 ustar root root #!/bin/bash
#
# Shorewall Packet Filtering Firewall configuration program - V5.2
#
# (c) 2012,2014,2017 - Tom Eastep (teastep@shorewall.net)
#
# Shorewall documentation is available at http://www.shorewall.net
#
# This program is part of Shorewall.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by the
# Free Software Foundation, either version 2 of the license or, at your
# option, any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, see = ] ...
#
#
################################################################################################
#
# Build updates this
#
VERSION=5.2.3.4
case "$BASH_VERSION" in
[4-9].*)
;;
*)
echo "ERROR: This program requires Bash 4.0 or later" >&2
exit 1
;;
esac
declare -A params
declare -A options
getfileparams() {
while read option; do
case $option in
\#*)
;;
*)
on=${option%=*}
ov=${option#*=}
ov=${ov%#*}
[ -n "$on" ] && options[${on}]="${ov}"
;;
esac
done
return 0
}
for p in $@; do
if [ -n "${p}" ]; then
declare -u pn
pn=${p%=*}
pn=${pn#--}
pv=${p#*=}
if [ -n "${pn}" ]; then
case ${pn} in
VENDOR)
pn=HOST
;;
SHAREDSTATEDIR)
pn=VARLIB
;;
DATADIR)
pn=SHAREDIR
;;
esac
params[${pn}]="${pv}"
else
echo "ERROR: Invalid option ($p)" >&2
exit 1
fi
fi
done
cd $(dirname $0)
vendor=${params[HOST]}
if [ -z "$vendor" ]; then
if [ -f /etc/os-release ]; then
eval $(cat /etc/os-release | grep ^ID=)
case $ID in
fedora|rhel)
vendor=redhat
;;
debian|ubuntu)
vendor=debian
;;
opensuse)
vendor=suse
;;
alt|basealt|altlinux)
vendor=alt
;;
*)
vendor="$ID"
;;
esac
params[HOST]="$vendor"
fi
fi
if [ -z "$vendor" ]; then
case `uname` in
Darwin)
params[HOST]=apple
rcfile=shorewallrc.apple
;;
cygwin*|CYGWIN*)
params[HOST]=cygwin
rcfile=shorewallrc.cygwin
;;
*)
if [ -f /etc/debian_version ]; then
params[HOST]=debian
ls -l /sbin/init | fgrep -q systemd && rcfile=shorewallrc.debian.systemd || rcfile=shorewallrc.debian.sysvinit
elif [ -f /etc/altlinux-release ] ; then
params[HOST]=alt
elif [ -f /etc/redhat-release ]; then
params[HOST]=redhat
rcfile=shorewallrc.redhat
elif [ -f /etc/slackware-version ] ; then
params[HOST]=slackware
rcfile=shorewallrc.slackware
elif [ -f /etc/SuSE-release ]; then
params[HOST]=suse
rcfile=shorewallrc.suse
elif [ -f /etc/arch-release ] ; then
params[HOST]=archlinux
rcfile=shorewallrc.archlinux
elif [ -f /etc/openwrt_release ]; then
params[HOST]=openwrt
rcfile=shorewallrc.openwrt
else
params[HOST]=linux
rcfile=shorewallrc.default
fi
;;
esac
vendor=${params[HOST]}
else
if [ $vendor = linux ]; then
rcfile=shorewallrc.default;
elif [ $vendor = debian -a -f /etc/debian_version ]; then
ls -l /sbin/init | fgrep -q systemd && rcfile=shorewallrc.debian.systemd || rcfile=shorewallrc.debian.sysvinit
else
rcfile=shorewallrc.$vendor
fi
if [ ! -f $rcfile ]; then
echo "ERROR: $vendor is not a recognized host type" >&2
exit 1
elif [ $vendor = default ]; then
params[HOST]=linux
vendor=linux
elif [[ $vendor == debian.* ]]; then
params[HOST]=debian
vendor=debian
fi
fi
if [ $vendor = linux ]; then
echo "INFO: Creating a generic Linux installation - " `date`;
else
echo "INFO: Creating a ${params[HOST]}-specific installation - " `date`;
fi
echo
getfileparams < $rcfile || exit 1
for p in ${!params[@]}; do
options[${p}]="${params[${p}]}"
done
echo '#' > shorewallrc
echo "# Created by Shorewall Core version $VERSION configure - " `date --utc --date="@${SOURCE_DATE_EPOCH:-$(date +%s)}"` >> shorewallrc
echo "# rc file: $rcfile" >> shorewallrc
echo '#' >> shorewallrc
if [ $# -gt 0 ]; then
echo "# Input: $@" >> shorewallrc
echo '#' >> shorewallrc
fi
if [ -n "${options[VARLIB]}" ]; then
if [ -z "${options[VARDIR]}" ]; then
options[VARDIR]='${VARLIB}/${PRODUCT}'
fi
elif [ -n "${options[VARDIR]}" ]; then
if [ -z "{$options[VARLIB]}" ]; then
options[VARLIB]=${options[VARDIR]}
options[VARDIR]='${VARLIB}/${PRODUCT}'
fi
fi
if [ -z "${options[SERVICEDIR]}" ]; then
options[SERVICEDIR]="${options[SYSTEMD]}"
fi
for on in \
HOST \
PREFIX \
SHAREDIR \
LIBEXECDIR \
PERLLIBDIR \
CONFDIR \
SBINDIR \
MANDIR \
INITDIR \
INITSOURCE \
INITFILE \
AUXINITSOURCE \
AUXINITFILE \
SERVICEDIR \
SERVICEFILE \
SYSCONFFILE \
SYSCONFDIR \
SPARSE \
ANNOTATED \
VARLIB \
VARDIR \
DEFAULT_PAGER
do
echo "$on=${options[${on}]}"
echo "$on=${options[${on}]}" >> shorewallrc
done
shorewall6-5.2.3.4/init.fedora.sh 0000775 0000000 0000000 00000004244 13531060406 015214 0 ustar root root #!/bin/sh
#
# Shorewall init script
#
# chkconfig: - 28 90
# description: Packet filtering firewall
### BEGIN INIT INFO
# Provides: shorewall6
# Required-Start: $local_fs $remote_fs $syslog $network
# Should-Start: VMware $time $named
# Required-Stop:
# Default-Start:
# Default-Stop: 0 1 2 3 4 5 6
# Short-Description: Packet filtering firewall
# Description: The Shoreline Firewall, more commonly known as "Shorewall", is a
# Netfilter (iptables) based firewall
### END INIT INFO
# Source function library.
. /etc/rc.d/init.d/functions
#
# The installer may alter this
#
. /usr/share/shorewall/shorewallrc
prog="shorewall -6"
shorewall="${SBINDIR}/$prog"
logger="logger -i -t $prog"
lockfile="/var/lock/subsys/$prog"
# Get startup options (override default)
OPTIONS=
if [ -f ${SYSCONFDIR}/$prog ]; then
. ${SYSCONFDIR}/$prog
fi
start() {
printf $"Starting Shorewall: "
$shorewall $OPTIONS start $STARTOPTIONS 2>&1 | $logger
retval=${PIPESTATUS[0]}
if [[ $retval == 0 ]]; then
touch $lockfile
success
else
failure
fi
echo
return $retval
}
stop() {
printf $"Stopping Shorewall: "
$shorewall $OPTIONS stop 2>&1 | $logger
retval=${PIPESTATUS[0]}
if [[ $retval == 0 ]]; then
rm -f $lockfile
success
else
failure
fi
echo
return $retval
}
restart() {
# Note that we don't simply stop and start since shorewall has a built in
# restart which stops the firewall if running and then starts it.
printf $"Restarting Shorewall: "
$shorewall $OPTIONS restart $RESTARTOPTIONS 2>&1 | $logger
retval=${PIPESTATUS[0]}
if [[ $retval == 0 ]]; then
touch $lockfile
success
else # Failed to start, clean up lock file if present
rm -f $lockfile
failure
fi
echo
return $retval
}
status(){
$shorewall status
return $?
}
status_q() {
status > /dev/null 2>&1
}
case "$1" in
start)
status_q && exit 0
$1
;;
stop)
status_q || exit 0
$1
;;
restart|reload|force-reload)
restart
;;
condrestart|try-restart)
status_q || exit 0
restart
;;
status)
$1
;;
*)
echo "Usage: $0 start|stop|reload|restart|force-reload|status"
exit 1
;;
esac
shorewall6-5.2.3.4/actions.std 0000664 0000000 0000000 00000004132 13531060406 014623 0 ustar root root #
# Shorewall6 version 5 - Actions.std File
#
# /usr/share/shorewall6/actions.std
#
# Please see http://shorewall.net/Actions.html for additional
# information.
#
###############################################################################
#ACTION
AllowICMPs proto=58 # Accept needed ICMP6 types
allowBcast inline # Silently Allow Broadcast
allowInvalid inline # Accepts packets in the INVALID conntrack state
allowMcast inline # Silently Allow Multicast
AutoBL noinline # Auto-blacklist IPs that exceed thesholds
AutoBLL noinline # Helper for AutoBL
BLACKLIST logjump,section # Add sender to the dynamic blacklist
Broadcast noinline # Handles Broadcast/Anycast
dropBcast inline # Silently Drop Broadcast
dropBcasts inline # Silently Drop Broadcast
dropInvalid inline # Drops packets in the INVALID conntrack state
dropMcast inline # Silently Drop Multicast
dropNotSyn noinline,proto=6 # Silently Drop Non-syn TCP packets
DropDNSrep inline,proto=17 # Drops DNS replies
DropSmurfs noinline # Handles packets with a broadcast source address
Established inline,\ # Handles packets in the ESTABLISHED state
state=ESTABLISHED
FIN inline,audit,\ # Handles ACK,FIN,PSH packets
proto=6
forwardUPnP noinline # Allow traffic that upnpd has redirected from 'upnp' interfaces.
IfEvent noinline # Perform an action based on an event
Invalid inline,audit,\ # Handles packets in the INVALID conntrack state
state=INVALID
Multicast noinline # Handles Multicast
New inline,state=NEW # Handles packets in the NEW conntrack state
NotSyn inline,proto=6 # Handles TCP packets that do not have SYN=1 and ACK=0
rejNotSyn noinline,proto=6 # Silently Reject Non-syn TCP packets
Related inline,\ # Handles packets in the RELATED conntrack state
state=RELATED
ResetEvent inline # Reset an Event
RST inline,proto=6 # Handle packets with RST set
SetEvent inline # Initialize an event
TCPFlags proto=6 # Handles bad flags combinations
Untracked inline,\ # Handles packets in the UNTRACKED conntrack state
state=UNTRACKED
shorewall6-5.2.3.4/init.sh 0000775 0000000 0000000 00000005501 13531060406 013752 0 ustar root root #!/bin/sh
RCDLINKS="2,S41 3,S41 6,K41"
#
# The Shoreline Firewall (Shorewall6) Packet Filtering Firewall - V5.2
#
# (c) 1999,2000,2001,2002,2003,2004,2005,2012,2014 - Tom Eastep (teastep@shorewall.net)
#
# On most distributions, this file should be called /etc/init.d/shorewall.
#
# Complete documentation is available at http://shorewall.net
#
# This program is part of Shorewall.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by the
# Free Software Foundation, either version 2 of the license or, at your
# option, any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, see 2" or "-
# ".
#
# ☆ So if M is the maximum zone name length, such chains can have
# length 2*M + 1.
#
# 12 + 6 + 2*M + 1 = 29 which reduces to
# 2*M = 29 - 12 - 6 - 1 = 10 or
# M = 5
#
# In Shorewall 5.1.0, the LOGFORMAT in the default and sample
# shorewall.conf files was changed to "%s:%s ".
#
# ☆ That formatting string has 2 fixed characters (":" and a space).
#
# ☆ So the maximum zone name length M is calculated as:
#
# 2 + 6 + 2*M + 1 = 29
# 2M = 29 - 2 - 6 - 1 = 20
# M = 10
#
# The order in which Shorewall matches addresses from packets to zones is
# determined by the order of zone declarations. Where a zone is nested in one
# or more other zones, you may either ensure that the nested zone precedes
# its parents in this file, or you may follow the (sub)zone name by ":" and a
# comma-separated list of the parent zones. The parent zones must have been
# declared in earlier records in this file. See shorewall-nesting(5) for
# additional information.
#
# Example:
#
# #ZONE TYPE OPTIONS IN OPTIONS OUT OPTIONS
# a ip
# b ip
# c:a,b ip
#
# Currently, Shorewall uses this information to reorder the zone list so that
# parent zones appear after their subzones in the list. The IMPLICIT_CONTINUE
# option in shorewall.conf(5) can also create implicit CONTINUE policies to/
# from the subzone.
#
# Where an ipsec zone is explicitly included as a child of an ip zone, the
# ruleset allows CONTINUE policies (explicit or implicit) to work as
# expected.
#
# In the future, Shorewall may make additional use of nesting information.
#
# TYPE
#
# ip
#
# This is the standard Shorewall zone type and is the default if you
# leave this column empty or if you enter "-" in the column.
# Communication with some zone hosts may be encrypted. Encrypted hosts
# are designated using the 'ipsec' option in shorewall-hosts(5). For
# clarity, this zone type may be specified as ipv4 in IPv4 configurations
# and ipv6 in IPv6 configurations.
#
# ipsec
#
# Communication with all zone hosts is encrypted. Your kernel and
# iptables must include policy match support. For clarity, this zone type
# may be specified as ipsec4 in IPv4 configurations and ipsec6 in IPv6
# configurations.
#
# firewall
#
# Designates the firewall itself. You must have exactly one 'firewall'
# zone. No options are permitted with a 'firewall' zone. The name that
# you enter in the ZONE column will be stored in the shell variable $FW
# which you may use in other configuration files to designate the
# firewall zone.
#
# bport
#
# The zone is associated with one or more ports on a single bridge. For
# clarity, this zone type may be specified as bport4 in IPv4
# configurations and bport6 in IPv6 configurations.
#
# vserver
#
# Added in Shorewall 4.4.11 Beta 2 - A zone composed of Linux-vserver
# guests. The zone contents must be defined in shorewall-hosts (5).
#
# Vserver zones are implicitly handled as subzones of the firewall zone.
#
# loopback
#
# Added in Shorewall 4.5.17.
#
# Normally, Shorewall treats the loopback interface (lo) in the following
# way:
#
# ☆ By default, all traffic through the interface is ACCEPTed.
#
# ☆ If a $FW -> $FW policy is defined or $FW -> $FW rules are defined,
# they are placed in a chain named ${FW}2${F2} or ${FW}-${FW} (e.g.,
# 'fw2fw' or 'fw-fw' ) depending on the ZONE2ZONE setting in
# shorewall.conf(5).
#
# ☆ $FW -> $FW traffic is only filtered in the OUTPUT chain.
#
# By defining a loopback zone and associating it with the loopback
# interface in shorewall-interfaces(5), you can effect a slightly
# different model. Suppose that the loopback zone name is 'local'; then:
#
# ☆ Both $FW -> local and local -> $FW chains are created.
#
# ☆ The $FW -> local and local -> $FW policies may be different.
#
# ☆ Both $FW -> local and local -> $FW rules may be specified.
#
# Rules to/from the loopback zone and any zone other than the firewall
# zone are ignored with a warning.
#
# loopback zones may be nested within other loopback zones.
#
# local
#
# Added in Shorewall 4.5.17. local is the same as ipv4 with the exception
# that the zone is only accessible from the firewall and vserver zones.
#
# OPTIONS, IN OPTIONS and OUT OPTIONS (options, in_options, out_options) - [
# option[,option]...]
#
# A comma-separated list of options. With the exception of the mss and
# blacklist options, these only apply to TYPE ipsec zones.
#
# dynamic_shared
#
# Added in Shorewall 4.5.9. May only be specified in the OPTIONS column
# and indicates that only a single ipset should be created for this zone
# if it has multiple dynamic entries in shorewall-hosts(5). Without this
# option, a separate ipset is created for each interface.
#
# reqid=number
#
# where number is specified using setkey(8) using the 'unique:number
# option for the SPD level.
#
# spi=
#
# where number is the SPI of the SA used to encrypt/decrypt packets.
#
# proto=ah|esp|ipcomp
#
# IPSEC Encapsulation Protocol
#
# mss=number
#
# sets the MSS field in TCP packets. If you supply this option, you
# should also set FASTACCEPT=No in shorewall.conf(5) to insure that both
# the SYN and SYN,ACK packets have their MSS field adjusted.
#
# mode=transport|tunnel
#
# IPSEC mode
#
# 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
#
# 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 "-".
#
###############################################################################
#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
fw firewall
net ip
shorewall6-5.2.3.4/Samples6/Universal/interfaces.annotated 0000664 0000000 0000000 00000060764 13531077670 022163 0 ustar root root #
# Shorewall version 4 - Interfaces File
#
# For information about entries in this file, type "man shorewall-interfaces"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall-interfaces.html
#
###############################################################################
#
# The interfaces file serves to define the firewall's network interfaces to
# Shorewall. The order of entries in this file is not significant in determining
# zone composition.
#
# Beginning with Shorewall 4.5.3, the interfaces file supports two different
# formats:
#
# FORMAT 1 (default - deprecated)
#
# There is a BROADCAST column which can be used to specify the broadcast
# address associated with the interface.
#
# FORMAT 2
#
# The BROADCAST column is omitted.
#
# The format is specified by a line as follows:
#
# ?FORMAT {1|2}
#
# The columns in the file are as follows.
#
# ZONE - zone-name
#
# Zone for this interface. Must match the name of a zone declared in /etc/
# shorewall/zones. You may not list the firewall zone in this column.
#
# If the interface serves multiple zones that will be defined in the
# shorewall-hosts(5) file, you should place "-" in this column.
#
# If there are multiple interfaces to the same zone, you must list them in
# separate entries.
#
# Example:
#
# #ZONE INTERFACE BROADCAST
# loc eth1 -
# loc eth2 -
#
# INTERFACE - interface[:port]
#
# Logical name of interface. Each interface may be listed only once in this
# file. You may NOT specify the name of a "virtual" interface (e.g., eth0:0)
# here; see http://www.shorewall.net/FAQ.htm#faq18. If the physical option is
# not specified, then the logical name is also the name of the actual
# interface.
#
# You may use wildcards here by specifying a prefix followed by the plus sign
# ("+"). For example, if you want to make an entry that applies to all PPP
# interfaces, use 'ppp+'; that would match ppp0, ppp1, ppp2, …
#
# When using Shorewall versions before 4.1.4, care must be exercised when
# using wildcards where there is another zone that uses a matching specific
# interface. See shorewall-nesting(5) for a discussion of this problem.
#
# Shorewall allows '+' as an interface name, but that usage is deprecated. A
# better approach is to specify 'physical=+' in the OPTIONS column (see
# below).
#
# There is no need to define the loopback interface (lo) in this file.
#
# If a port is given, then the interface must have been defined previously
# with the bridge option. The OPTIONS column may not contain the following
# options when a port is given.
#
# arp_filter
# arp_ignore
# bridge
# log_martians
# mss
# optional
# proxyarp
# required
# routefilter
# sourceroute
# upnp
# wait
#
# Beginning with Shorewall 4.5.17, if you specify a zone for the 'lo'
# interface, then that zone must be defined as type local in shorewall6-zones
# (5).
#
# BROADCAST (Optional) - {-|detect|address[,address]...}
#
# Only available if FORMAT 1.
#
# If you use the special value detect, Shorewall will detect the broadcast
# address(es) for you if your iptables and kernel include Address Type Match
# support.
#
# If your iptables and/or kernel lack Address Type Match support then you may
# list the broadcast address(es) for the network(s) to which the interface
# belongs. For P-T-P interfaces, this column is left blank. If the interface
# has multiple addresses on multiple subnets then list the broadcast
# addresses as a comma-separated list.
#
# If you don't want to give a value for this column but you want to enter a
# value in the OPTIONS column, enter - in this column.
#
# OPTIONS (Optional) - [option[,option]...]
#
# A comma-separated list of options from the following list. The order in
# which you list the options is not significant but the list should have no
# embedded white-space.
#
# accept_ra[={0|1|2}]
#
# IPv6 only; added in Shorewall 4.5.16. Values are:
#
# 0
#
# Do not accept Router Advertisements.
#
# 1
#
# Accept Route Advertisements if forwarding is disabled.
#
# 2
#
# Overrule forwarding behavior. Accept Route Advertisements even if
# forwarding is enabled.
#
# If the option is specified without a value, then the value 1 is
# assumed.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# arp_filter[={0|1}]
#
# IPv4 only. If specified, this interface will only respond to ARP
# who-has requests for IP addresses configured on the interface. If not
# specified, the interface can respond to ARP who-has requests for IP
# addresses on any of the firewall's interface. The interface must be up
# when Shorewall is started.
#
# Only those interfaces with the arp_filter option will have their
# setting changed; the value assigned to the setting will be the value
# specified (if any) or 1 if no value is given.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# arp_ignore[=number]
#
# IPv4 only. If specified, this interface will respond to arp requests
# based on the value of number (defaults to 1).
#
# 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 the sender's IP address is part from same
# subnet on this interface's address
#
# 3 - do not reply for local addresses configured with scope host, only
# resolutions for global and link
#
# 4-7 - reserved
#
# 8 - do not reply for all local addresses
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# Warning
#
# Do not specify arp_ignore for any interface involved in Proxy ARP.
#
# blacklist
#
# Checks packets arriving on this interface against the
# shorewall-blacklist(5) file.
#
# Beginning with Shorewall 4.4.13:
#
# ☆ If a zone is given in the ZONES column, then the behavior is as if
# blacklist had been specified in the IN_OPTIONS column of
# shorewall-zones(5).
#
# ☆ Otherwise, the option is ignored with a warning:
#
# WARNING: The 'blacklist' option is ignored on multi-zone
# interfaces
#
# bridge
#
# Designates the interface as a bridge. Beginning with Shorewall 4.4.7,
# setting this option also sets routeback.
#
# Note
#
# If you have a bridge that you don't intend to define bport zones on,
# then it is best to omit this option and simply specify routeback.
#
# dbl={none|src|dst|src-dst}
#
# Added in Shorewall 5.0.10. This option defined whether or not dynamic
# blacklisting is applied to packets entering the firewall through this
# interface and whether the source address and/or destination address is
# to be compared against the ipset-based dynamic blacklist
# (DYNAMIC_BLACKLIST=ipset... in shorewall.conf(5)). The default is
# determine by the setting of DYNAMIC_BLACKLIST:
#
# DYNAMIC_BLACKLIST=No
#
# Default is none (e.g., no dynamic blacklist checking).
#
# DYNAMIC_BLACKLIST=Yes
#
# Default is src (e.g., the source IP address is checked).
#
# DYNAMIC_BLACKLIST=ipset[-only]
#
# Default is src.
#
# DYNAMIC_BLACKLIST=ipset[-only],src-dst...
#
# Default is src-dst (e.g., the source IP addresses in checked
# against the ipset on input and the destination IP address is
# checked against the ipset on packets originating from the firewall
# and leaving through this interface).
#
# The normal setting for this option will be dst or none for internal
# interfaces and src or src-dst for Internet-facing interfaces.
#
# destonly
#
# Added in Shorewall 4.5.17. Causes the compiler to omit rules to handle
# traffic from this interface.
#
# dhcp
#
# Specify this option when any of the following are true:
#
# 1. the interface gets its IP address via DHCP
#
# 2. the interface is used by a DHCP server running on the firewall
#
# 3. the interface has a static IP but is on a LAN segment with lots of
# DHCP clients.
#
# 4. the interface is a simple bridge with a DHCP server on one port and
# DHCP clients on another port.
#
# Note
#
# If you use Shorewall-perl for firewall/bridging, then you need to
# include DHCP-specific rules in shorewall-rules(5). DHCP uses UDP
# ports 67 and 68.
#
# This option allows DHCP datagrams to enter and leave the interface.
#
# forward[={0|1}]
#
# IPv6 only Sets the /proc/sys/net/ipv6/conf/interface/forwarding option
# to the specified value. If no value is supplied, then 1 is assumed.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# ignore[=1]
#
# When specified, causes the generated script to ignore up/down events
# from Shorewall-init for this device. Additionally, the option exempts
# the interface from hairpin filtering. When '=1' is omitted, the ZONE
# column must contain '-' and ignore must be the only OPTION.
#
# Beginning with Shorewall 4.5.5, may be specified as 'ignore=1' which
# only causes the generated script to ignore up/down events from
# Shorewall-init; hairpin filtering is still applied. In this case, the
# above restrictions on the ZONE and OPTIONS columns are lifted.
#
# loopback
#
# Added in Shorewall 4.6.6. Designates the interface as the loopback
# interface. This option is assumed if the interface's physical name is
# 'lo'. Only one interface man have the loopback option specified.
#
# logmartians[={0|1}]
#
# IPv4 only. Turn on kernel martian logging (logging of packets with
# impossible source addresses. It is strongly suggested that if you set
# routefilter on an interface that you also set logmartians. Even if you
# do not specify the routefilter option, it is a good idea to specify
# logmartians because your distribution may have enabled route filtering
# without you knowing it.
#
# Only those interfaces with the logmartians option will have their
# setting changed; the value assigned to the setting will be the value
# specified (if any) or 1 if no value is given.
#
# To find out if route filtering is set on a given interface, check the
# contents of /proc/sys/net/ipv4/conf/interface/rp_filter - a non-zero
# value indicates that route filtering is enabled.
#
# Example:
#
# teastep@lists:~$ cat /proc/sys/net/ipv4/conf/eth0/rp_filter
# 1
# teastep@lists:~$
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# This option may also be enabled globally in the shorewall.conf(5)
# file.
#
# maclist
#
# Connection requests from this interface are compared against the
# contents of shorewall-maclist(5). If this option is specified, the
# interface must be an Ethernet NIC and must be up before Shorewall is
# started.
#
# mss=number
#
# Added in Shorewall 4.0.3. Causes forwarded TCP SYN packets entering or
# leaving on this interface to have their MSS field set to the specified
# number.
#
# nets=(net[,...])
#
# Limit the zone named in the ZONE column to only the listed networks.
# The parentheses may be omitted if only a single net is given (e.g.,
# nets=192.168.1.0/24). Limited broadcast to the zone is supported.
# Beginning with Shorewall 4.4.1, multicast traffic to the zone is also
# supported.
#
# nets=dynamic
#
# Defines the zone as dynamic. Requires ipset match support in your
# iptables and kernel. See http://www.shorewall.net/Dynamic.html for
# further information.
#
# nodbl
#
# Added in Shorewall 5.0.8. When specified, dynamic blacklisting is
# disabled on the interface. Beginning with Shorewall 5.0.10, nodbl is
# equivalent to dbl=none.
#
# nosmurfs
#
# IPv4 only. Filter packets for smurfs (packets with a broadcast address
# as the source).
#
# Smurfs will be optionally logged based on the setting of
# SMURF_LOG_LEVEL in shorewall.conf(5). After logging, the packets are
# dropped.
#
# optional
#
# When optional is specified for an interface, Shorewall will be silent
# when:
#
# ☆ a /proc/sys/net/ipv[46]/conf/ entry for the interface cannot be
# modified (including for proxy ARP or proxy NDP).
#
# ☆ The first address of the interface cannot be obtained.
#
# May not be specified with required.
#
# physical=name
#
# Added in Shorewall 4.4.4. When specified, the interface or port name in
# the INTERFACE column is a logical name that refers to the name given in
# this option. It is useful when you want to specify the same wildcard
# port name on two or more bridges. See http://www.shorewall.net/
# bridge-Shorewall-perl.html#Multiple.
#
# If the interface name is a wildcard name (ends with '+'), then the
# physical name must also end in '+'. The physical name may end in '+'
# (or be exactly '+') when the interface name is not a wildcard name.
#
# If physical is not specified, then it's value defaults to the interface
# name.
#
# proxyarp[={0|1}]
#
# IPv4 only. Sets /proc/sys/net/ipv4/conf/interface/proxy_arp. Do NOT use
# this option if you are employing Proxy ARP through entries in
# shorewall-proxyarp(5). This option is intended solely for use with
# Proxy ARP sub-networking as described at: http://tldp.org/HOWTO/
# Proxy-ARP-Subnet/index.html.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# Only those interfaces with the proxyarp option will have their setting
# changed; the value assigned to the setting will be the value specified
# (if any) or 1 if no value is given.
#
# proxyndp[={0|1}]
#
# IPv6 only. Sets /proc/sys/net/ipv6/conf/interface/proxy_ndp.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# Only those interfaces with the proxyndp option will have their setting
# changed; the value assigned to the setting will be the value specified
# (if any) or 1 if no value is given.
#
# required
#
# Added in Shorewall 4.4.10. If this option is set, the firewall will
# fail to start if the interface is not usable. May not be specified
# together with optional.
#
# routeback[={0|1}]
#
# If specified, indicates that Shorewall should include rules that allow
# traffic arriving on this interface to be routed back out that same
# interface. This option is also required when you have used a wildcard
# in the INTERFACE column if you want to allow traffic between the
# interfaces that match the wildcard.
#
# Beginning with Shorewall 4.4.20, if you specify this option, then you
# should also specify either sfilter (see below) or routefilter on all
# interfaces (see below).
#
# Beginning with Shorewall 4.5.18, you may specify this option to
# explicitly reset (e.g., routeback=0). This can be used to override
# Shorewall's default setting for bridge devices which is routeback=1.
#
# routefilter[={0|1|2}]
#
# IPv4 only. Turn on kernel route filtering for this interface
# (anti-spoofing measure).
#
# Only those interfaces with the routefilter option will have their
# setting changes; the value assigned to the setting will be the value
# specified (if any) or 1 if no value is given.
#
# The value 2 is only available with Shorewall 4.4.5.1 and later when the
# kernel version is 2.6.31 or later. It specifies a loose form of reverse
# path filtering.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# This option can also be enabled globally via the ROUTE_FILTER option in
# the shorewall.conf(5) file.
#
# Important
#
# If ROUTE_FILTER=Yes in shorewall.conf(5), or if your distribution sets
# net.ipv4.conf.all.rp_filter=1 in /etc/sysctl.conf, then setting
# routefilter=0 in an interface entry will not disable route filtering on
# that interface! The effective setting for an interface is the maximum
# of the contents of /proc/sys/net/ipv4/conf/all/rp_filter and the
# routefilter setting specified in this file (/proc/sys/net/ipv4/conf/
# interface/rp_filter).
#
# Note
#
# There are certain cases where routefilter cannot be used on an
# interface:
#
# ☆ If USE_DEFAULT_RT=Yes in shorewall.conf(5) and the interface is
# listed in shorewall-providers(5).
#
# ☆ If there is an entry for the interface in shorewall-providers(5)
# that doesn't specify the balance option.
#
# ☆ If IPSEC is used to allow a road-warrior to have a local address,
# then any interface through which the road-warrior might connect
# cannot specify routefilter.
#
# Beginning with Shorewall 5.1.1, when routefilter is set to a non-zero
# value, the logmartians option is also implicitly set. If you actually
# want route filtering without logging, then you must also specify
# logmartians=0 after routefilter.
#
# rpfilter
#
# Added in Shorewall 4.5.7. This is an anti-spoofing measure that
# requires the 'RPFilter Match' capability in your iptables and kernel.
# It provides a more efficient alternative to the sfilter option below.
# It performs a function similar to routefilter (see above) but works
# with Multi-ISP configurations that do not use balanced routes.
#
# sfilter=(net[,...])
#
# Added in Shorewall 4.4.20. This option provides an anti-spoofing
# alternative to routefilter on interfaces where that option cannot be
# used, but where the routeback option is required (on a bridge, for
# example). On these interfaces, sfilter should list those local networks
# that are connected to the firewall through other interfaces.
#
# sourceroute[={0|1}]
#
# If this option is not specified for an interface, then source-routed
# packets will not be accepted from that interface unless it has been
# explicitly enabled via sysconf. Only set this option to 1 (enable
# source routing) if you know what you are doing. This might represent a
# security risk and is usually unneeded.
#
# Only those interfaces with the sourceroute option will have their
# setting changed; the value assigned to the setting will be the value
# specified (if any) or 1 if no value is given.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# tcpflags[={0|1}]
#
# Packets arriving on this interface are checked for certain illegal
# combinations of TCP flags. Packets found to have such a combination of
# flags are handled according to the setting of TCP_FLAGS_DISPOSITION
# after having been logged according to the setting of
# TCP_FLAGS_LOG_LEVEL.
#
# Beginning with Shorewall 4.6.0, tcpflags=1 is the default. To disable
# this option, specify tcpflags=0.
#
# unmanaged
#
# Added in Shorewall 4.5.18. Causes all traffic between the firewall and
# hosts on the interface to be accepted. When this option is given:
#
# ☆ The ZONE column must contain '-'.
#
# ☆ Only the following other options are allowed with unmanaged:
#
# arp_filter
# arp_ignore
# ignore
# routefilter
# optional
# physical
# routefilter
# proxyarp
# proxyudp
# sourceroute
#
# upnp
#
# Incoming requests from this interface may be remapped via UPNP (upnpd).
# See http://www.shorewall.net/UPnP.html. Supported in IPv4 and in IPv6
# in Shorewall 5.1.4 and later.
#
# upnpclient
#
# This option is intended for laptop users who always run Shorewall on
# their system yet need to run UPnP-enabled client apps such as
# Transmission (BitTorrent client). The option causes Shorewall to detect
# the default gateway through the interface and to accept UDP packets
# from that gateway. Note that, like all aspects of UPnP, this is a
# security hole so use this option at your own risk. Supported in IPv4
# and in IPv6 in Shorewall 5.1.4 and later.
#
# wait=seconds
#
# Added in Shorewall 4.4.10. Causes the generated script to wait up to
# seconds seconds for the interface to become usable before applying the
# required or optional options.
#
# Example
#
# IPv4 Example 1:
#
# Suppose you have eth0 connected to a DSL modem and eth1 connected to your
# local network and that your local subnet is 192.168.1.0/24. The interface
# gets its IP address via DHCP from subnet 206.191.149.192/27. You have a DMZ
# with subnet 192.168.2.0/24 using eth2. Your iptables and/or kernel do not
# support "Address Type Match" and you prefer to specify broadcast addresses
# explicitly rather than having Shorewall detect them.
#
# Your entries for this setup would look like:
#
# ?FORMAT 1
# #ZONE INTERFACE BROADCAST OPTIONS
# net eth0 206.191.149.223 dhcp
# loc eth1 192.168.1.255
# dmz eth2 192.168.2.255
#
# Example 2:
#
# The same configuration without specifying broadcast addresses is:
#
# ?FORMAT 2
# #ZONE INTERFACE OPTIONS
# net eth0 dhcp
# loc eth1
# dmz eth2
#
# Example 3:
#
# You have a simple dial-in system with no Ethernet connections.
#
# ?FORMAT 2
# #ZONE INTERFACE OPTIONS
# net ppp0 -
#
# Example 4 (Shorewall 4.4.9 and later):
#
# You have a bridge with no IP address and you want to allow traffic through
# the bridge.
#
# ?FORMAT 2
# #ZONE INTERFACE OPTIONS
# - br0 bridge
#
###############################################################################
?FORMAT 2
###############################################################################
#ZONE INTERFACE OPTIONS
- lo ignore
net all dhcp,physical=+,routeback
shorewall6-5.2.3.4/Samples6/Universal/policy.annotated 0000664 0000000 0000000 00000024723 13531077670 021332 0 ustar root root #
# Shorewall version 4 - Policy File
#
# For information about entries in this file, type "man shorewall-policy"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall-policy.html
#
###############################################################################
#
# This file defines the high-level policy for connections between zones defined
# in shorewall-zones(5).
#
# Important
#
# The order of entries in this file is important
#
# This file determines what to do with a new connection request if we don't get a
# match from the shorewall-blrules(5) or shorewall-rules(5) files. For each
# source/destination pair, the file is processed in order until a match is found
# ("all" will match any source or destination).
#
# Important
#
# Intra-zone policies are pre-defined
#
# For $FW and for all of the zones defined in shorewall-zones(5), the POLICY for
# connections from the zone to itself is ACCEPT (with no logging or TCP
# connection rate limiting) but may be overridden by an entry in this file. The
# overriding entry must be explicit (specifying the zone name in both SOURCE and
# DEST) or it must use "all+" (Shorewall 4.5.17 or later).
#
# Similarly, if you have IMPLICIT_CONTINUE=Yes in shorewall.conf(5), then the
# implicit policy to/from any sub-zone is CONTINUE. These implicit CONTINUE
# policies may also be overridden by an explicit entry in this file.
#
# The columns in the file are as follows (where the column name is followed by a
# different name in parentheses, the different name is used in the alternate
# specification syntax).
#
# SOURCE - zone[,...[+]]|$FW|all[+][!ezone[,...]]
#
# Source zone. Must be the name of a zone defined in shorewall-zones(5), $FW,
# "all" or "all+".
#
# Support for all+ was added in Shorewall 4.5.17. all does not override the
# implicit intra-zone ACCEPT policy while all+ does.
#
# Beginning with Shorewall 5.0.12, multiple zones may be listed separated by
# commas. As above, if '+' is specified after two or more zone names, then
# the policy overrides the implicit intra-zone ACCEPT policy if the same zone
# appears in both the SOURCE and DEST columns.
#
# Beginning with Shorewall 5.2.3, a comma-separated list of excluded zones
# preceded by "!" may follow all or all+.
#
# DEST - zone[,...[+]]|$FW|all[+][!ezone[,...]]
#
# Destination zone. Must be the name of a zone defined in shorewall-zones(5),
# $FW, "all" or "all+". If the DEST is a bport zone, then the SOURCE must be
# "all", "all+", another bport zone associated with the same bridge, or it
# must be an ipv4 zone that is associated with only the same bridge.
#
# Support for "all+" was added in Shorewall 4.5.17. "all" does not override
# the implicit intra-zone ACCEPT policy while "all+" does.
#
# Beginning with Shorewall 5.0.12, multiple zones may be listed separated by
# commas. As above, if '+' is specified after two or more zone names, then
# the policy overrides the implicit intra-zone ACCEPT policy if the same zone
# appears in both the SOURCE and DEST columns.
#
# Beginning with Shorewall 5.2.3, a comma-separated list of excluded zones
# preceded by "!" may follow all or all+.
#
# POLICY - {ACCEPT|DROP|REJECT|BLACKLIST|CONTINUE|QUEUE|NFQUEUE[(queuenumber1[:
# queuenumber2])]|NONE}[:{[+]policy-action[:level][,...]|None}]
#
# Policy if no match from the rules file is found.
#
# If the policy is neither CONTINUE nor NONE then the policy may be followed
# by ":" and one of the following:
#
# a. The word "None" or "none". This causes any default action defined in
# shorewall.conf(5) to be omitted for this policy.
#
# b. The name of an action with optional parameters enclosed in parentheses.
# The action will be invoked before the policy is enforced.
#
# Actions can have parameters specified.
#
# Beginning with Shorewall 4.5.10, the action name can be followed optionally
# by a colon and a log level. The level will be applied to each rule in the
# action or body that does not already have a log level.
#
# Beginning with Shorewall 5.1.2, multiple action[:level] specification may
# be listeded, separated by commas. The actions are invoked in the order
# listed. Also beginning with Shorewall 5.1.2, the policy-action list can be
# prefixed with a plus sign ("+") indicating that the listed actions are in
# addition to those listed in the related _DEFAULT setting in shorewall.conf
# (5).
#
# Possible policies are:
#
# ACCEPT
#
# Accept the connection.
#
# DROP
#
# Ignore the connection request.
#
# REJECT
#
# For TCP, send RST. For all other, send an "unreachable" ICMP.
#
# BLACKLIST
#
# Added in Shorewall 5.1.1 and requires that the DYNAMIC_BLACKLIST
# setting in shorewall.conf(5) specifies ipset-based dynamic
# blacklisting. The SOURCE IP address is added to the blacklist ipset and
# the connection request is ignored.
#
# QUEUE
#
# Queue the request for a user-space application such as Snort-inline.
#
# NFQUEUE
#
# Queue the request for a user-space application using the
# nfnetlink_queue mechanism. If a queuenumber1 is not given, queue zero
# (0) is assumed. Beginning with Shorewall 4.6.10, a second queue number
# (queuenumber2) may be given. This specifies a range of queues to use.
# Packets are then balanced across the given queues. This is useful for
# multicore systems: start multiple instances of the userspace program on
# queues x, x+1, .. x+n and use "x:x+n". Packets belonging to the same
# connection are put into the same nfqueue.
#
# CONTINUE
#
# Pass the connection request past any other rules that it might also
# match (where the source or destination zone in those rules is a
# superset of the SOURCE or DEST in this policy). See shorewall-nesting
# (5) for additional information.
#
# NONE
#
# Assume that there will never be any packets from this SOURCE to this
# DEST. Shorewall will not create any infrastructure to handle such
# packets and you may not have any rules with this SOURCE and DEST in the
# /etc/shorewall/rules file. If such a packet is received, the result is
# undefined. NONE may not be used if the SOURCE or DEST columns contain
# the firewall zone ($FW) or "all".
#
# LOGLEVEL (loglevel) - [log-level|ULOG|NFLOG]
#
# Optional - if supplied, each connection handled under the default POLICY is
# logged at that level. If not supplied, no log message is generated. See
# syslog.conf(5) for a description of log levels.
#
# You may also specify ULOG or NFLOG (must be in upper case). This will log
# to the ULOG or NFLOG target and will send to a separate log through use of
# ulogd (http://www.netfilter.org/projects/ulogd/index.html).
#
# For a description of logging, see shorewall-logging(5).
#
# If you don't want to log but need to specify the following column, place
# "-" here.
#
# RATE (rate) - [-|limit]
#
# where limit is one of:
#
# [-|[{s|d}[/vlsm]:[[name][(ht-buckets,ht-max)]:]]]rate/{sec|min|hour|day}[:
# burst]
# [name1:]rate1/{sec|min|hour|day}[:burst1],[name2:]rate2/{sec|min|hour|day}
# [:burst2]
#
# If passed, specifies the maximum TCP connection rate and the size of an
# acceptable burst. If not specified, TCP connections are not limited. If the
# burst parameter is omitted, a value of 5 is assumed.
#
# When s: or d: is specified, the rate applies per source IP address or per
# destination IP address respectively. The name may be chosen by the user and
# specifies a hash table to be used to count matching connections. If not
# give, the name shorewall is assumed. Where more than one POLICY or rule
# specifies the same name, the connections counts for the policies are
# aggregated and the individual rates apply to the aggregated count.
# Beginning with Shorewall 5.2.1, the s or d may be followed by a slash ("/")
# and an integer vlsm. When a vlsm is specified, all source or destination
# addresses encountered will be grouped according to the given prefix length
# and the so-created subnet will be subject to the rate limit.
#
# Beginning with Shorewall 4.6.5, two limits may be specified, separated by a
# comma. In this case, the first limit (name1, rate1, burst1) specifies the
# per-source IP limit and the second limit specifies the per-destination IP
# limit.
#
# Example: client:10/sec:20,:60/sec:100
#
# Beginning with Shorewall 5.2.1, the table name, if any, may be followed by
# two integers separated by commas and enclosed in parentheses. The first
# integer (ht-buckets) specifies the number of buckets in the generated hash
# table. The second integer (ht-max) specifies the maximum number of entries
# in the hash table.
#
# Example: s:client(1024,65536):10/sec
#
# CONNLIMIT - limit[:mask]
#
# May be used to limit the number of simultaneous connections from each
# individual host to limit connections. While the limit is only checked on
# connections to which this policy could apply, the number of current
# connections is calculated over all current connections from the SOURCE
# host. By default, the limit is applied to each host individually but can be
# made to apply to networks of hosts by specifying a mask. The mask specifies
# the width of a VLSM mask to be applied to the source address; the number of
# current connections is then taken over all hosts in the subnet
# source-address/mask.
#
# Example
#
# a. All connections from the local network to the internet are allowed
#
# b. All connections from the internet are ignored but logged at syslog level
# KERNEL.INFO.
#
# c. All other connection requests are rejected and logged at level KERNEL.INFO.
#
# #SOURCE DEST POLICY LOG BURST:LIMIT
# # LEVEL
# loc net ACCEPT
# net all DROP info
# #
# # THE FOLLOWING POLICY MUST BE LAST
# #
# all all REJECT info
#
###############################################################################
#SOURCE DEST POLICY LOGLEVEL RATE CONNLIMIT
fw net ACCEPT
net all DROP $LOG_LEVEL
shorewall6-5.2.3.4/Samples6/Universal/rules.annotated 0000664 0000000 0000000 00000163022 13531077671 021162 0 ustar root root #
# Shorewall version 4 - Rules File
#
# For information on the settings in this file, type "man shorewall-rules"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall-rules.html
#
######################################################################################################################################################################################################
#
# Entries in this file govern connection establishment by defining exceptions to
# the policies laid out in shorewall-policy(5). By default, subsequent requests
# and responses are automatically allowed using connection tracking. For any
# particular (source,dest) pair of zones, the rules are evaluated in the order in
# which they appear in this file and the first terminating match is the one that
# determines the disposition of the request. All rules are terminating except LOG
# and COUNT rules.
#
# Warning
#
# If you masquerade or use SNAT from a local system to the internet, you cannot
# use an ACCEPT rule to allow traffic from the internet to that system. You must
# use a DNAT rule instead.
#
# The rules file is divided into sections. Each section is introduced by a
# "Section Header" which is a line beginning with ?SECTION and followed by the
# section name.
#
# Sections are as follows and must appear in the order listed:
#
# ALL
#
# This section was added in Shorewall 4.4.23. Rules in this section are
# applied, regardless of the connection tracking state of the packet and are
# applied before rules in the other sections.
#
# ESTABLISHED
#
# Packets in the ESTABLISHED state are processed by rules in this section.
#
# The only ACTIONs allowed in this section are ACCEPT, DROP, REJECT, LOG,
# NFLOG, NFQUEUE and QUEUE
#
# There is an implicit ACCEPT rule inserted at the end of this section.
#
# RELATED
#
# Packets in the RELATED state are processed by rules in this section.
#
# The only ACTIONs allowed in this section are ACCEPT, DROP, REJECT, LOG,
# NFLOG, NFQUEUE and QUEUE
#
# There is an implicit rule added at the end of this section that invokes the
# RELATED_DISPOSITION (shorewall.conf(5)).
#
# INVALID
#
# Added in Shorewall 4.5.13. Packets in the INVALID state are processed by
# rules in this section.
#
# The only Actions allowed in this section are ACCEPT, DROP, REJECT, LOG,
# NFLOG, NFQUEUE and QUEUE.
#
# There is an implicit rule added at the end of this section that invokes the
# INVALID_DISPOSITION (shorewall.conf(5)).
#
# UNTRACKED
#
# Added in Shorewall 4.5.13. Packets in the UNTRACKED state are processed by
# rules in this section.
#
# The only Actions allowed in this section are ACCEPT, DROP, REJECT, LOG,
# NFLOG, NFQUEUE and QUEUE.
#
# There is an implicit rule added at the end of this section that invokes the
# UNTRACKED_DISPOSITION (shorewall.conf(5)).
#
# NEW
#
# Packets in the NEW state are processed by rules in this section. If the
# INVALID and/or UNTRACKED sections are empty or not included, then the
# packets in the corresponding state(s) are also processed in this section.
#
# Note
#
# If you are not familiar with Netfilter to the point where you are comfortable
# with the differences between the various connection tracking states, then it is
# suggested that you place all of your rules in the NEW section (That's after the
# line that reads ?SECTION NEW').
#
# Warning
#
# If you specify FASTACCEPT=Yes in shorewall.conf(5) then the ALL, ESTABLISHED
# and RELATED sections must be empty.
#
# An exception is made if you are running Shorewall 4.4.27 or later and you have
# specified a non-default value for RELATED_DISPOSITION or RELATED_LOG_LEVEL. In
# that case, you may have rules in the RELATED section of this file.
#
# You may omit any section that you don't need. If no Section Headers appear in
# the file then all rules are assumed to be in the NEW section.
#
# When defining rules that rewrite the destination IP address and/or port number
# (namely DNAT and REDIRECT rules), it is important to keep straight which
# columns in the file specify the packet before rewriting and which specify how
# the packet will look after rewriting.
#
# • The DEST column specifies the final destination for the packet after
# rewriting and can include the final IP address and/or port number.
#
# • The remaining columns specify characteristics of the packet before
# rewriting. In particular, the ORIGDEST column gives the original
# destination IP address of the packet and the DPORT column give the original
# destination port(s).
#
# The columns in the file are as follows (where the column name is followed by a
# different name in parentheses, the different name is used in the alternate
# specification syntax).
#
# ACTION - target[:{log-level|none}[!][:tag]]
#
# Specifies the action to be taken if the connection request matches the
# rule. target must be one of the following.
#
# ACCEPT
#
# Allow the connection request.
#
# ACCEPT+
#
# like ACCEPT but also excludes the connection from any subsequent
# matching DNAT[-] or REDIRECT[-] rules. Use with IPv6 requires Shorewall
# 4.5.14 or later.
#
# ACCEPT!
#
# like ACCEPT but exempts the rule from being suppressed by OPTIMIZE=1 in
# shorewall.conf(5).
#
# action
#
# The name of an action declared in shorewall-actions(5) or in /usr/share
# /shorewall[6]/actions.std.
#
# ADD(ipset:flags[:timeout])
#
# Added in Shorewall 4.4.12. Causes addresses and/or port numbers to be
# added to the named ipset. The flags specify the address or tuple to be
# added to the set and must match the type of ipset involved. For
# example, for an iphash ipset, either the SOURCE or DESTINATION address
# can be added using flags src or dst respectively (see the -A command in
# ipset (8)).
#
# Beginning with Shorewall 5.0.3, an optional timeout can be specified.
# This is the number of seconds that the new entry in the ipset is to
# remain valid and overrides any timeout specified when the ipset was
# created.
#
# ADD is non-terminating. Even if a packet matches the rule, it is passed
# on to the next rule.
#
# AUDIT[(accept|drop|reject)]
#
# Added in Shorewall 4.5.10. Audits the packet with the specified type;
# if the type is omitted, then drop is assumed. Require AUDIT_TARGET
# support in the kernel and iptables.
#
# A_ACCEPT, A_ACCEPT+ and A_ACCEPT!
#
# Added in Shorewall 4.4.20. Audited versions of ACCEPT, ACCEPT+ and
# ACCEPT! respectively. Require AUDIT_TARGET support in the kernel and
# iptables. A_ACCEPT+ with IPv6 requires Shorewall 4.5.14 or later.
#
# A_DROP and A_DROP!
#
# Added in Shorewall 4.4.20. Audited versions of DROP and DROP!
# respectively. Require AUDIT_TARGET support in the kernel and iptables.
#
# A_REJECT AND A_REJECT!
#
# Added in Shorewall 4.4.20. Audited versions of REJECT and REJECT!
# respectively. Require AUDIT_TARGET support in the kernel and iptables.
#
# ?COMMENT
#
# the rest of the line will be attached as a comment to the Netfilter
# rule(s) generated by the following entries. The comment will appear
# delimited by "/* ... */" in the output of "shorewall show ". To
# stop the comment from being attached to further rules, simply include ?
# COMMENT on a line by itself.
#
# CONMARK({mark})
#
# Added in Shorewall 5.0.7, CONNMARK is identical to MARK with the
# exception that the mark is assigned to connection to which the packet
# belongs is marked rather than to the packet itself.
#
# CONTINUE
#
# For experts only.
#
# Do not process any of the following rules for this (source
# zone,destination zone). If the source and/or destination IP address
# falls into a zone defined later in shorewall-zones(5) or in a parent
# zone of the source or destination zones, then this connection request
# will be passed to the rules defined for that (those) zone(s). See
# shorewall-nesting(5) for additional information.
#
# CONTINUE!
#
# like CONTINUE but exempts the rule from being suppressed by OPTIMIZE=1
# in shorewall.conf(5).
#
# COUNT
#
# Simply increment the rule's packet and byte count and pass the packet
# to the next rule.
#
# DEL(ipset:flags)
#
# Added in Shorewall 4.4.12. Causes an entry to be deleted from the named
# ipset. The flags specify the address or tuple to be deleted from the
# set and must match the type of ipset involved. For example, for an
# iphash ipset, either the SOURCE or DESTINATION address can be deleted
# using flags src or dst respectively (see the -D command in ipset (8)).
#
# DEL is non-terminating. Even if a packet matches the rule, it is passed
# on to the next rule.
#
# DNAT
#
# Forward the request to another system (and optionally another port).
# Use with IPv6 requires Shorewall 4.5.14 or later.
#
# DNAT-
#
# Advanced users only.
#
# Like DNAT but only generates the DNAT iptables rule and not the
# companion ACCEPT rule. Use with IPv6 requires Shorewall 4.5.14 or
# later.
#
# DROP
#
# Ignore the request.
#
# DROP!
#
# like DROP but exempts the rule from being suppressed by OPTIMIZE=1 in
# shorewall.conf(5).
#
# HELPER
#
# Added in Shorewall 4.5.7. This action requires that the HELPER column
# contains the name of the Netfilter helper to be associated with
# connections matching this connection. May only be specified in the NEW
# section and is useful for being able to specify a helper when the
# applicable policy is ACCEPT. No destination zone should be specified in
# HELPER rules.
#
# INLINE[(action)]
#
# Added in Shorewall 4.5.16. This action allows you to construct most of
# the rule yourself using iptables syntax. The part that you specify must
# follow two semicolons (';;') and is completely free-form. If the target
# of the rule (the part following 'j') is something that Shorewall
# supports in the ACTION column, then you may enclose it in parentheses
# (e.g., INLINE(ACCEPT)). Otherwise, you can include it after the
# semicolon(s). In this case, you must declare the target as a builtin
# action in shorewall-actions(5).
#
# Some considerations when using INLINE:
#
# ☆ The p, s, d, i, o, policy, and state match (state or conntrack
# --ctstate) matches will always appear in the front of the rule in
# that order.
#
# ☆ When multiple matches are specified, the compiler will keep them in
# the order in which they appear (excluding the above listed ones),
# but they will not necessarily be at the end of the generated rule.
# For example, if addresses are specified in the SOURCE and/or DEST
# columns, their generated matches will appear after those specified
# using ';;' or ';'.
#
# IPTABLES({iptables-target [option ...])
#
# IPv4 only. This action allows you to specify an iptables target with
# options (e.g., 'IPTABLES(MARK --set-xmark 0x01/0xff)'. If the
# iptables-target is not one recognized by Shorewall, the following error
# message will be issued:
#
# ERROR: Unknown target (iptables-target)
#
# This error message may be eliminated by adding the iptables-target as a
# builtin action in shorewall-actions(5).
#
# Important
#
# If you specify REJECT as the iptables-target, the target of the rule
# will be the iptables REJECT target and not Shorewall's builtin 'reject'
# chain which is used when REJECT (see below) is specified as the target
# in the ACTION column.
#
# IP6TABLES({ip6tables-target [option ...])
#
# IPv6 only. This action allows you to specify an ip6tables target with
# options (e.g., 'IPTABLES(MARK --set-xmark 0x01/0xff)'. If the
# ip6tables-target is not one recognized by Shorewall, the following
# error message will be issued:
#
# ERROR: Unknown target (ip6tables-target)
#
# This error message may be eliminated by adding the ip6tables-target as
# a builtin action in shorewall-actions(5).
#
# Important
#
# If you specify REJECT as the ip6tables-target, the target of the rule
# will be the i6ptables REJECT target and not Shorewall's builtin
# 'reject' chain which is used when REJECT (see below) is specified as
# the target in the ACTION column.
#
# LOG:level
#
# Simply log the packet and continue with the next rule.
#
# macro[(macrotarget)]
#
# The name of a macro defined in a file named macro.macro. If the macro
# accepts an action parameter (Look at the macro source to see if it has
# PARAM in the TARGET column) then the macro name is followed by the
# parenthesized macrotarget (ACCEPT, DROP, REJECT, ...) to be substituted
# for the parameter.
#
# Example: FTP(ACCEPT).
#
# The older syntax where the macro name and the target are separated by a
# slash (e.g. FTP/ACCEPT) is still allowed but is deprecated.
#
# MARK({mark})
#
# where mark is a packet mark value.
#
# Added in Shorewall 5.0.7, MARK requires "Mark in filter table" support
# in your kernel and iptables.
#
# Normally will set the mark value of the current packet. If preceded by
# a vertical bar ("|"), the mark value will be logically ORed with the
# current mark value to produce a new mark value. If preceded by an
# ampersand ("&"), will be logically ANDed with the current mark value to
# produce a new mark value.
#
# Both "|" and "&" require Extended MARK Target support in your kernel
# and iptables.
#
# The mark value may be optionally followed by "/" and a mask value (used
# to determine those bits of the connection mark to actually be set).
# When a mask is specified, the result of logically ANDing the mark value
# with the mask must be the same as the mark value.
#
# NFLOG[(nflog-parameters)]
#
# Added in Shorewall 4.5.9.3. Queues matching packets to a back end
# logging daemon via a netlink socket then continues to the next rule.
# See http://www.shorewall.net/shorewall_logging.html.
#
# The nflog-parameters are a comma-separated list of up to 3 numbers:
#
# ☆ The first number specifies the netlink group (0-65535). If omitted
# (e.g., NFLOG(,0,10)) then a value of 0 is assumed.
#
# ☆ The second number specifies the maximum number of bytes to copy. If
# omitted, 0 (no limit) is assumed.
#
# ☆ The third number specifies the number of log messages that should
# be buffered in the kernel before they are sent to user space. The
# default is 1.
#
# NFLOG is similar to LOG:NFLOG[(nflog-parameters)], except that the log
# level is not changed when this ACTION is used in an action or macro
# body and the invocation of that action or macro specifies a log level.
#
# NFQUEUE[([queuenumber1[:queuenumber2[c]][,bypass]]|bypass)]
#
# Queues the packet to a user-space application using the nfnetlink_queue
# mechanism. If a queuenumber1 is not specified, queue zero (0) is
# assumed. Beginning with Shorewall 4.6.10, the keyword bypass can be
# given. By default, if no userspace program is listening on an NFQUEUE,
# then all packets that are to be queued are dropped. When this option is
# used, the NFQUEUE rule behaves like ACCEPT instead. Also beginning in
# Shorewall 4.6.10, a second queue number (queuenumber2) may be
# specified. This specifies a range of queues to use. Packets are then
# balanced across the given queues. This is useful for multicore systems:
# start multiple instances of the userspace program on queues x, x+1, ..
# x+n and use "x:x+n". Packets belonging to the same connection are put
# into the same nfqueue.
#
# Beginning with Shorewall 5.1.0, queuenumber2 may be followed by the
# letter 'c' to indicate that the CPU ID will be used as an index to map
# packets to the queues. The idea is that you can improve performance if
# there's a queue per CPU. Requires the NFQUEUE CPU Fanout capability in
# your kernel and iptables.
#
# NFQUEUE![([queuenumber1[:queuenumber2[c]][,bypass]]|bypass)]
#
# like NFQUEUE but exempts the rule from being suppressed by OPTIMIZE=1
# in shorewall.conf(5).
#
# NONAT
#
# Excludes the connection from any subsequent DNAT[-] or REDIRECT[-]
# rules but doesn't generate a rule to accept the traffic. Use with IPv6
# requires Shorewall 4.5.14 or later.
#
# QUEUE
#
# Queue the packet to a user-space application such as ftwall (http://
# p2pwall.sf.net). The application may reinsert the packet for further
# processing.
#
# QUEUE!
#
# like QUEUE but exempts the rule from being suppressed by OPTIMIZE=1 in
# shorewall.conf(5).
#
# REJECT[(option)]
#
# disallow the request and return an icmp-unreachable or an RST packet.
# If no option is passed, Shorewall selects the appropriate option based
# on the protocol of the packet.
#
# Beginning with Shorewall 5.0.8, the type of reject may be specified in
# the option paramater. Valid IPv4 option values are:
#
# icmp-net-unreachable
# icmp-host-unreachable
# icmp-port-unreachable
# icmp-proto-unreachable
# icmp-net-prohibited
# icmp-host-prohibited
# icmp-admin-prohibited
# icmp-tcp-reset (the PROTO column must specify TCP). Beginning with
# Shorewall 5.1.3, this option may also be specified as tcp-reset.
#
# Valid IPv6 option values are:
#
# icmp6-no-route
# no-route
# icmp6-adm-prohibited
# adm-prohibited
# icmp6-addr-unreachable
# addr-unreach
# icmp6-port-unreachable
# tcp-reset (the PROTO column must specify TCP)
#
# REJECT!
#
# like REJECT but exempts the rule from being suppressed by OPTIMIZE=1 in
# shorewall.conf(5).
#
# REDIRECT
#
# Redirect the request to a server running on the firewall. Use with IPv6
# requires Shorewall 4.5.14 or later.
#
# REDIRECT-
#
# Advanced users only.
#
# Like REDIRECT but only generates the REDIRECT iptables rule and not the
# companion ACCEPT rule. Use with IPv6 requires Shorewall 4.5.14 or
# later.
#
# TARPIT [(tarpit | honeypot | reset)]
#
# Added in Shorewall 4.6.6.
#
# TARPIT captures and holds incoming TCP connections using no local
# per-connection resources.
#
# TARPIT only works with the PROTO column set to tcp (6), and is totally
# application agnostic. This module will answer a TCP request and play
# along like a listening server, but aside from sending an ACK or RST, no
# data is sent. Incoming packets are ignored and dropped. The attacker
# will terminate the session eventually. This module allows the initial
# packets of an attack to be captured by other software for inspection.
# In most cases this is sufficient to determine the nature of the attack.
#
# This offers similar functionality to LaBrea " was specified
# in the command (e.g., shorewall [-6] check ./gateway) then the
# directory given in the command is searched first.
#
# □ Next, each directory in the CONFIG_PATH setting is searched in
# sequence.
#
# If CONFIG_PATH is not given or if it is set to the empty value then the
# contents of /usr/share/shorewall/configpath are used. As released from
# shorewall.net, that file sets the CONFIG_PATH to /etc/shorewall:/usr/share/
# shorewall but your particular distribution may set it differently. See the
# output of shorewall show config for the default on your system.
#
# Beginning with Shorewall 5.1.10, the CONFIG_PATH setting may begin with a
# colon (":"), to signal that the first directory listed will be skipped if
# the user performing a compilation is not root or if the configuration is
# being compiled for export (-e option specified or if running one of the
# remote-* commands) . This prevents the compiler from looking in /etc/
# shorewall[6]/ when compilation is being done by a non-root user or if the
# generated script is to be sent to a remote firewall system.
#
GEOIPDIR=/usr/share/xt_geoip/LE
#
# GEOIPDIR=[pathname]
#
# Added in Shorewall 4.5.4. Specifies the pathname of the directory
# containing the GeoIP Match database. See http://www.shorewall.net/
# ISO-3661.html. If not specified, the default value is /usr/share/xt_geoip/
# LE which is the default location of the little-endian database.
#
IP6TABLES=
#
# IP6TABLES=[pathname]
#
# IPv6 only.
#
# This parameter names the ip6tables executable to be used by Shorewall6. If
# not specified or if specified as a null value, then the ip6tables
# executable located using the PATH option is used.
#
# Regardless of how the ip6tables utility is located (specified via IP6TABLES
# = or located via PATH), Shorewall6 uses the ip6tables-restore and
# ip6tables-save utilities from that same directory.
#
IP=
#
# IP=[pathname]
#
# If specified, gives the pathname of the 'ip' executable. If not specified,
# 'ip' is assumed and the utility will be located using the current PATH
# setting.
#
IPSET=
#
# IPSET=[pathname]
#
# If specified, gives the pathname of the 'ipset' executable. If not
# specified, 'ipset' is assumed and the utility will be located using the
# current PATH setting.
#
LOCKFILE=
#
# LOCKFILE=[pathname]
#
# Specifies the name of the Shorewall[6] lock file, used to prevent
# simultaneous state-changing commands. If not specified, ${VARDIR}/shorewall
# [6]/lock is assumed (${VARDIR} is normally /var/lib but can be changed when
# Shorewall-core is installed -- see the output of shorewall show vardir).
#
MODULESDIR=
#
# MODULESDIR=[[+]pathname[:pathname]...]
#
# This parameter specifies the directory/directories where your kernel
# netfilter modules may be found. If you leave the variable empty, Shorewall
# will supply the value "/lib/modules/$uname/kernel/net/ipv${g_family}/
# netfilter:/lib/modules/$uname/kernel/net/netfilter:/lib/modules/$uname/
# kernel/net/sched:/lib/modules/$uname/extra:/lib/modules/$uname/extra/ipset"
# where uname holds the output of 'uname -r' and g_family holds '4' in IPv4
# configurations and '6' in IPv6 configurations.
#
# The option plus sign ('+') was added in Shorewall 5.0.3 and causes the
# listed pathnames to be appended to the default list above.
#
NFACCT=
#
# NFACCT=[pathname]
#
# Added in Shorewall 4.5.7. Specifies the pathname of the nfacct utility. If
# not specified, Shorewall will use the PATH setting to find the program.
#
PERL=/usr/bin/perl
#
# PERL=pathname
#
# Added in Shorewall 4.4.11 RC1. Specifies the path name of the Perl
# executable. Default is /usr/bin/perl. If the pathname specified by this
# option does not exist or the named file is not executable, then Shorewall
# falls back to /usr/bin/perl
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
#
# PATH=pathname[:pathname]...
#
# Determines the order in which Shorewall searches directories for executable
# files.
#
RESTOREFILE=restore
#
# RESTOREFILE=filename
#
# Specifies the simple name of a file in /var/lib/shorewall to be used as the
# default restore script in the shorewall [-6] save, shorewall [-6] restore,
# shorewall [-6] forget and shorewall [6] -f start commands.
#
SHOREWALL_SHELL=/bin/sh
#
# SHOREWALL_SHELL=[pathname]
#
# This option is used to specify the shell program to be used to interpret
# the compiled script. If not specified or specified as a null value, /bin/sh
# is assumed. Using a light-weight shell such as ash or dash can
# significantly improve performance.
#
SUBSYSLOCK=
#
# SUBSYSLOCK=[pathname]
#
# This parameter should be set to the name of a file that the firewall should
# create if it starts successfully and remove when it stops. Creating and
# removing this file allows Shorewall to work with your distribution's
# initscripts. For OpenSuSE, this should be set to /var/lock/subsys/shorewall
# (var/lock/subsys/shorewall-lite if building for export). For Gentoo, it
# should be set to /run/lock/shorewall (/run/lock/shorewall-lite). For Redhat
# and derivatives as well as Debian and derivatives, the pathname should be
# omitted.
#
# Important
#
# Beginning with Shorewall 5.1.0, this setting is ignored when SERVICEDIR is
# non-empty in ${SHAREDIR}/shorewall/shorewallrc (usually /usr/share/
# shorewall/shorewallrc).
#
TC=
#
# TC=[pathname]
#
# If specified, gives the pathname of the 'tc' executable. If not specified,
# 'tc' is assumed and the utility will be located using the current PATH
# setting.
#
###############################################################################
# D E F A U L T A C T I O N S / M A C R O S
###############################################################################
ACCEPT_DEFAULT="none"
#
# ACCEPT_DEFAULT={action[(parameters)][:level][,...]|none}
#
BLACKLIST_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP),dropNotSyn:$LOG_LEVEL,dropInvalid:$LOG_LEVEL,DropDNSrep:$LOG_LEVEL"
#
# BLACKLIST_DEFAULT={action[(parameters)][:level][,...]|none}
#
DROP_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)"
#
# DROP_DEFAULT={action[(parameters)][:level][,...]|none}
#
NFQUEUE_DEFAULT="none"
#
# NFQUEUE_DEFAULT={action[(parameters)][:level][,...]|none}
#
QUEUE_DEFAULT="none"
#
# QUEUE_DEFAULT={action[(parameters)][:level][,...]|none}
#
REJECT_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)"
#
# REJECT_DEFAULT={action[(parameters)][:level][,...]|none}
#
# In earlier Shorewall versions, a "default action" for DROP and REJECT
# policies was specified in the file /usr/share/shorewall/actions.std.
#
# In Shorewall 4.4.0, the DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT,
# QUEUE_DEFAULT and NFQUEUE_DEFAULT options were added.
#
# 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
# three are similar for ACCEPT, QUEUE and NFQUEUE policies.
#
# The value applied to these may be:
#
# a) The name of an action. The name may optionally be followed by a
# comma-separated list of parameters enclosed in parentheses if the specified
# action accepts parameters (e.g., 'Drop(audit)').
# c) None or none
#
# Prior to Shorewall 5.1.2, the default values are:
#
# DROP_DEFAULT="Drop"
# REJECT_DEFAULT="Reject"
# BLACKLIST_DEFAULT="Drop" (added in Shorewall 5.1.1)
# ACCEPT_DEFAULT="none"
# QUEUE_DEFAULT="none"
# NFQUEUE_DEFAULT="none"
#
# Beginning with Shorewall 5.1.2, the default value is 'none' for all of
# these. Note that the sample configuration files do, however, provide
# settings for DROP_DEFAULT, BLACKLIST_DEFAULT and REJECT_DEFAULT.
#
# 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
# shorewall-policy(5).
#
# You can pass parameters to the specified action (e.g., myaction(audit,DROP)
# ).
#
# Beginning with Shorewall 4.5.10, the action name can be followed optionally
# by a colon and a log level. The level will be applied to each rule in the
# action or body that does not already have a log level.
#
# Beginning with Shorewall 5.1.2, multiple action[(parameters)][:level]
# specifications may be listed, separated by commas.
#
###############################################################################
# R S H / R C P C O M M A N D S
###############################################################################
RCP_COMMAND='scp ${files} ${root}@${system}:${destination}'
#
# RCP_COMMAND="command"
#
RSH_COMMAND='ssh ${root}@${system} ${command}'
#
# RSH_COMMAND="command"
#
# Earlier generations of Shorewall Lite required that remote root login via
# ssh be enabled in order to use the load and reload commands. Beginning with
# release 3.9.5, you may define an alternative means for accessing the remote
# firewall system. In that release, two new options were added to
# shorewall.conf:
#
# RSH_COMMAND
# RCP_COMMAND
#
# The default values for these are as follows:
#
# RSH_COMMAND: ssh ${root}@${system} ${command}
# RCP_COMMAND: scp ${files} ${root}@${system}:${destination}
#
# Shell variables that will be set when the commands are invoked are as
# follows:
#
# root - root user. Normally root but may be overridden using the '-r' option.
# system - The name/IP address of the remote firewall system.
# command - For RSH_COMMAND, the command to be executed on the firewall system.
# files - For RCP_COMMAND, a space-separated list of files to be copied to the remote firewall system.
# destination - The directory on the remote system that the files are to be copied into.
#
###############################################################################
# F I R E W A L L O P T I O N S
###############################################################################
ACCOUNTING=Yes
#
# ACCOUNTING=[Yes|No]
#
# Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting is enabled
# (see shorewall-accounting(5)). If not specified or set to the empty value,
# ACCOUNTING=Yes is assumed.
#
ACCOUNTING_TABLE=filter
#
# ACCOUNTING_TABLE=[filter|mangle]
#
# Added in Shorewall 4.4.20. This setting determines which Netfilter table
# the accounting rules are added in. By default, ACCOUNTING_TABLE=filter is
# assumed. See also shorewall-accounting(5).
#
ADMINISABSENTMINDED=Yes
#
# ADMINISABSENTMINDED=[Yes|No]
#
# The value of this variable affects Shorewall's stopped state. The behavior
# differs depending on whether shorewall-routestopped(5) or
# shorewall-stoppedrules(5) is used:
#
# routestopped
#
# When ADMINISABSENTMINDED=No, only traffic to/from those addresses
# listed in routestopped is accepted when Shorewall is stopped. When
# ADMINISABSENTMINDED=Yes, in addition to traffic to/from addresses in
# routestopped, connections that were active when Shorewall stopped
# continue to work and all new connections from the firewall system
# itself are allowed.
#
# Note that the routestopped file is not supported in Shorewall 5.0 and
# later versions.
#
# stoppedrules
#
# All existing connections continue to work. To sever all existing
# connections when the firewall is stopped, install the conntrack utility
# and place the command conntrack -F in the stopped user exit (/etc/
# shorewall/stopped).
#
# If ADMINISABSENTMINDED=No, only new connections matching entries in
# stoppedrules are accepted when Shorewall is stopped. Response packets
# and related connections are automatically accepted.
#
# If ADMINISABSENTMINDED=Yes, in addition to connections matching entries
# in stoppedrules, all new connections from the firewall system itself
# are allowed when the firewall is stopped. Response packets and related
# connections are automatically accepted.
#
# If this variable is not set or is given the empty value then
# ADMINISABSENTMINDED=No is assumed.
#
AUTOCOMMENT=Yes
#
# AUTOCOMMENT=[Yes|No]
#
# Formerly named AUTO_COMMENT. If set, if there is not a current comment when
# a macro is invoked, the behavior is as if the first line of the macro file
# was "COMMENT ". If not specified, the AUTO_COMMENT option has a
# default value of 'Yes'.
#
AUTOHELPERS=Yes
#
# AUTOHELPERS=[Yes|No]
#
# Added in Shorewall 4.5.7. When set to Yes (the default), the generated
# ruleset will automatically associate helpers with applications that require
# them (FTP, IRC, etc.). When configuring your firewall on systems running
# kernel 3.5 or later, it is recommended that you:
#
# 1. Set AUTOHELPERS=No.
#
# 2. Modify the HELPERS setting (see below) to list the helpers that you
# need.
#
# 3. Either:
#
# a. Modify shorewall-conntrack (5) to only apply helpers where they are
# required; or
#
# b. Specify the appropriate helper in the HELPER column in
# shorewall-rules (5).
#
# Note
#
# The macros for those applications requiring a helper automatically
# specify the appropriate HELPER where required.
#
AUTOMAKE=Yes
#
# AUTOMAKE=[Yes|No|recursive|depth]
#
# If set, the behavior of the start, reload and restart commands are changed;
# if no files in CONFIG_PATH (see below) have been changed since the last
# successful start, reload or restart command, then the compilation step is
# skipped and the compiled script that executed the last start, reload or
# restart command is used. If not specified, the default is AUTOMAKE=No.
#
# The setting of the AUTOMAKE option is ignored if the start, reload or
# restart command includes a directory name (e.g., shorewall restart /etc/
# shorewall.new).
#
# When AUTOMAKE=Yes, each directory in the CONFIG_PATH was originally
# searched recursively for files newer than the compiled script. That was
# changed in Shorewall 5.1.10.2 such that only the listed directories
# themselves were searched. That broke some configurations that played tricks
# with embedded SHELL such as "SHELL cat /etc/shorewall/rules.d/loc/*.rules".
# Prior to 5.1.10.2, a change to a file in or adding a file to /etc/shorewall
# /rules.d/loc/ would trigger recompilation. Beginning with 5.1.10.2, such
# changes would not trigger recompilation. Beginning with Shorewall 5.2.0,
# the pre-5.1.10.2 behavior can be obtained by setting AUTOMAKE=recursive.
#
# Also beginning with Shorewall 5.2.0, AUTOMAKE may be set to a numeric depth
# which specifies how deeply each listed directory is to be searched.
# AUTOMAKE=1 only searches each directory itself and is equivalent to
# AUTOMAKE=Yes. AUTOMAKE=2 will search each directory and its immediate
# sub-directories; AUTOMAKE=3 will search each directory, each of its
# immediate sub-directories, and each of their immediate sub-directories,
# etc.
#
BALANCE_PROVIDERS=No
#
# BALANCE_PROVIDERS=[Yes|No]
#
# Added in Shorewall 5.1.1. When USE_DEFAULT_RT=Yes, this option determines
# whether the balance provider option (see shorewall-providers(5)) is the
# default. When BALANCE_PROVIDERS=Yes, then the balance option is assumed
# unless the fallback, loose, load or tproxy option is specified. If this
# option is not set or is set to the empty value, then the default value is
# the value of USE_DEFAULT_RT.
#
BASIC_FILTERS=No
#
# BASIC_FILTERS=[Yes|No]
#
# Added in Shorewall-4.6.0. When set to Yes, causes entries in
# shorewall-tcfilters(5) to generate a basic filter rather than a u32 filter.
# This setting requires the Basic Ematch capability in your kernel and
# iptables.
#
# Note
#
# One of the advantages of basic filters is that ipset matches are supported
# in newer iproute2 and kernel versions. Because Shorewall cannot reliably
# detect this capability, use of basic filters is controlled by this option.
#
# The default value is No which causes u32 filters to be generated.
#
BLACKLIST="NEW,INVALID,UNTRACKED"
#
# BLACKLIST=[{ALL|state[,...]}]
#
# where state is one of NEW, ESTABLISHED, RELATED, INVALID,or UNTRACKED.
#
# Added in Shorewall 4.5.13 to replace the BLACKLISTNEWONLY option. Specifies
# the connection tracking states that are to be subject to blacklist
# screening. If BLACKLIST is not specified then the states subject to
# blacklisting are NEW,ESTABLISHED,INVALID,UNTRACKED.
#
# ALL sends all packets through the blacklist chains.
#
# Note: The ESTABLISHED state may not be specified if FASTACCEPT=Yes is
# specified.
#
CLAMPMSS=No
#
# CLAMPMSS=[Yes|No|value]
#
# This parameter enables the TCP Clamp MSS to PMTU feature of Netfilter and
# is usually required when your internet connection is through PPPoE or PPTP.
# If set to Yes or yes, the feature is enabled. If left blank or set to No or
# no, the feature is not enabled.
#
# Important: This option requires CONFIG_IP_NF_TARGET_TCPMSS in your kernel.
#
# You may also set CLAMPMSS to a numeric value (e.g., CLAMPMSS=1400). This
# will set the MSS field in TCP SYN packets going through the firewall to the
# value that you specify.
#
CLEAR_TC=No
#
# CLEAR_TC=[Yes|No]
#
# If this option is set to No then Shorewall won't clear the current traffic
# control rules during [re]start or reload. This setting is intended for use
# by people who prefer to configure traffic shaping when the network
# interfaces come up rather than when the firewall is started. If that is
# what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not supply
# an /etc/shorewall/tcstart file. That way, your traffic shaping rules can
# still use the “fwmark” classifier based on packet marking defined in
# shorewall-tcrules(5). If not specified, CLEAR_TC=Yes is assumed.
#
# Warning
#
# When you specify TC_ENABLED=shared (see below), then you should also
# specify CLEAR_TC=No.
#
COMPLETE=Yes
#
# COMPLETE=[Yes|No]
#
# Added in Shorewall 4.4.12. When you set this option to Yes, you are
# asserting that the configuration is complete so that your set of zones
# encompasses any hosts that can send or receive traffic to/from/through the
# firewall. This causes Shorewall to omit the rules that catch packets in
# which the source or destination IP address is outside of any of your zones.
# Default is No. It is recommended that this option only be set to Yes if:
#
# □ You have defined an interface whose effective physical setting is '+'.
#
# □ That interface is assigned to a zone.
#
# □ You have no CONTINUE policies or rules.
#
DEFER_DNS_RESOLUTION=Yes
#
# DEFER_DNS_RESOLUTION=[Yes|No]
#
# Added in Shorewall 4.5.12. When set to 'Yes' (the default), DNS names are
# validated in the compiler and then passed on to the generated script where
# they are resolved by ip[6]tables-restore. This is an advantage if you use
# AUTOMAKE=Yes and the IP address associated with the DNS name is subject to
# change. When DEFER_DNS_RESOLUTION=No, DNS names are converted into IP
# addresses by the compiler. This has the advantage that when AUTOMAKE=Yes,
# the start, reload and restart commands will succeed even if no DNS server
# is reachable (assuming that the configuration hasn't changed since the
# compiled script was last generated).
#
# Important
#
# When DEFER_DNS_RESOLUTION=No and AUTOMAKE=Yes and a DNS change makes it
# necessary to recompile an existing firewall script, the -c option must be
# used with the reload or restart command to force recompilation.
#
DELETE_THEN_ADD=Yes
#
# DELETE_THEN_ADD={Yes|No}
#
# If set to Yes (the default value), entries in the /etc/shorewall[6]/rtrules
# files cause an 'ip rule del' command to be generated in addition to an 'ip
# rule add' command. Setting this option to No, causes the 'ip rule del'
# command to be omitted.
#
DONT_LOAD=
#
# DONT_LOAD=[module[,module]...]
#
# Causes Shorewall to not load the listed kernel modules.
#
DYNAMIC_BLACKLIST=Yes
#
# DYNAMIC_BLACKLIST={Yes|No||ipset[-only][,option[,...]][:[setname][:log_level|:l
# og_tag]]]}
#
# Added in Shorewall 4.4.7. When set to No or no, chain-based dynamic
# blacklisting using shorewall [-6] [-l] drop, shorewall [-6] [-l] reject,
# shorewall logdrop and shorewall [-6] [-l] logreject is disabled. Default is
# Yes. Beginning with Shorewall 5.0.8, ipset-based dynamic blacklisting using
# the shorewall blacklist command is also supported. The name of the set (
# setname) and the level (log_level), if any, at which blacklisted traffic is
# to be logged may also be specified. The default IPv4 set name is SW_DBL4
# and the default IPv6 set name is SW_DBL6. The default log level is none (no
# logging). If ipset-only is given, then chain-based dynamic blacklisting is
# disabled just as if DYNAMIC_BLACKLISTING=No had been specified.
#
# Possible options are:
#
# src-dst
#
# Normally, only packets whose source address matches an entry in the
# ipset are dropped. If src-dst is included, then packets whose
# destination address matches an entry in the ipset are also dropped.
#
# disconnect
#
# The disconnect option was added in Shorewall 5.0.13 and requires that
# the conntrack utility be installed on the firewall system. When an
# address is blacklisted using the blacklist command, all connections
# originating from that address are disconnected. if the src-dst option
# was also specified, then all connections to that address are also
# disconnected.
#
# timeout=seconds
#
# Added in Shorewall 5.0.13. Normally, Shorewall creates the dynamic
# blacklisting ipset with timeout 0 which means that entries are
# permanent. If you want entries in the set that are not accessed for a
# period of time to be deleted from the set, you may specify that period
# using this option. Note that the blacklist command can override the
# ipset's timeout setting.
#
# Important
#
# Once the dynamic blacklisting ipset has been created, changing this
# option setting requires a complete restart of the firewall; shorewall
# [-6] restart if RESTART=restart, otherwise shorewall [-6] [-l] stop &&
# shorewall [-6] [-l] start
#
# When ipset-based dynamic blacklisting is enabled, the contents of the
# blacklist will be preserved over stop/reboot/start sequences if SAVE_IPSETS
# =Yes, SAVE_IPSETS=ipv4 or if setname is included in the list of sets to be
# saved in SAVE_IPSETS.
#
EXPAND_POLICIES=Yes
#
# EXPAND_POLICIES={Yes|No}
#
# Normally, when the SOURCE or DEST columns in shorewall-policy(5) contains
# 'all', a single policy chain is created and thes policy is enforced in that
# chain. For example, if the policy entry is
#
# #SOURCE DEST POLICY LOG
# # LEVEL
# net all DROP info
#
# then the chain name is 'net-all' ('net2all if ZONE2ZONE=2) which is also
# the chain named in Shorewall log messages generated as a result of the
# policy. If EXPAND_POLICIES=Yes, then Shorewall will create a separate chain
# for each pair of zones covered by the policy. This makes the resulting log
# messages easier to interpret since the chain in the messages will have a
# name of the form 'a2b' where 'a' is the SOURCE zone and 'b' is the DEST
# zone.
#
EXPORTMODULES=Yes
#
# EXPORTMODULES=[Yes|No]
#
# Added in Shorewall 4.4.17. When set to Yes when compiling for use by
# Shorewall Lite (shorewall [-6] remote-start, shorewall [-6] remote-reload,
# shorewall [-6] remote-restart or shorewall [-6] export commands), the
# compiler will copy the modules or helpers file from the administrative
# system into the script. When set to No or not specified, the compiler will
# not copy the modules or helpers file from /usr/share/shorewall[6] but will
# copy those found in another location on the CONFIG_PATH.
#
# When compiling for direct use by Shorewall, causes the contents of the
# local module or helpers file to be copied into the compiled script. When
# set to No or not set, the compiled script reads the file itself.
#
FASTACCEPT=Yes
#
# FASTACCEPT={Yes|No}
#
# 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 'loc-net' or 'loc2net'
# chain, depending on the setting of ZONE2ZONE (see below).
#
# If you set FASTACCEPT=Yes, then ESTABLISHED/RELATED 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
# shorewall-rules(5).
#
FORWARD_CLEAR_MARK=
#
# FORWARD_CLEAR_MARK={Yes|No}
#
# Added in Shorewall 4.4.11. Traditionally, Shorewall has cleared the packet
# mark in the first rule in the mangle FORWARD chain. This behavior is
# maintained with the default setting of this option (FORWARD_CLEAR_MARK=
# Yes). If FORWARD_CLEAR_MARK is set to 'No', packet marks set in the mangle
# PREROUTING chain are retained in the FORWARD chains.
#
HELPERS=
#
# HELPERS=[helper[,helper...]]
#
# Added in Shorewall 4.5.7. This option specifies a comma-separated list
# naming the Netfilter application helpers that are to be enabled. If not
# specified, the default is to enable all helpers.
#
# Possible values for helper are:
#
# □ amanda
#
# □ ftp
#
# □ h323
#
# □ irc
#
# □ netbios-ns
#
# □ none - This special value was added in Shorewall 4.5.16 and indicates
# that no helpers are to be enabled. It also prevents the compiler for
# probing for helper support; such probing generates messages on the
# system log of the form "xt_CT: No such helper XXX" where XXX is the
# helper name. When used, none must be the only helper specified.
#
# □ pptp
#
# □ sane
#
# □ sip
#
# □ snmp
#
# □ tftp
#
# When HELPERS is specified on a system running Kernel 3.5.0 or later,
# automatic association of helpers to connections is disabled.
#
IGNOREUNKNOWNVARIABLES=No
#
# IGNOREUNKNOWNVARIABLES=[Yes|No]
#
# Added in Shorewall 4.5.11. Normally, if an unknown shell variable is
# encountered in a configuration file (except in ?IF and ?ELSIF directives),
# the compiler raises a fatal error. If IGNOREUNKNOWNVARIABLES is set to Yes,
# then such variables simply expand to an empty string. Default is No.
#
IMPLICIT_CONTINUE=No
#
# IMPLICIT_CONTINUE={Yes|No}
#
# When this option is set to Yes, it causes subzones to be treated
# differently with respect to policies.
#
# Subzones are defined by following their name with ":" and a list of parent
# zones (in shorewall-zones(5)). Normally, you want to have a set of special
# rules for the subzone and if a connection doesn't match any of those
# subzone-specific rules then you want the parent zone rules and policies to
# be applied; see shorewall-nesting(5). With IMPLICIT_CONTINUE=Yes, that
# happens automatically.
#
# If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set, then subzones
# are not subject to this special treatment. With IMPLICIT_CONTINUE=Yes, an
# implicit CONTINUE policy may be overridden by including an explicit policy
# (one that does not specify "all" in either the SOURCE or the DEST columns).
#
IPSET_WARNINGS=Yes
#
# IPSET_WARNINGS={Yes|No}
#
# Added in Shorewall 4.5.2. Default is Yes. When set, causes the rules
# compiler to issue a warning when:
#
# □ The compiler is being run by root and an ipset specified in the
# configuration does not exists. Only one warning is issued for each
# missing ipset.
#
# □ When [src] is specified in a destination column and when [dst] is
# specified in a source column.
#
IP_FORWARDING=Keep
#
# IP_FORWARDING=[On|Off|Keep]
#
# This IPv4 parameter determines whether Shorewall enables or disables IPv4
# Packet Forwarding (/proc/sys/net/ipv4/ip_forward). In an IPv6
# configuration, this parameter determines the setting of /proc/sys/net/ipv6/
# config/all/ip_forwarding.
#
# Possible values are:
#
# On or on
#
# packet forwarding will be enabled.
#
# Off or off
#
# packet forwarding will be disabled.
#
# Keep or keep
#
# Shorewall will neither enable nor disable packet forwarding.
#
# If this variable is not set or is given an empty value (IP_FORWARD="") then
# IP_FORWARD=On is assumed.
#
KEEP_RT_TABLES=Yes
#
# KEEP_RT_TABLES={Yes|No}
#
# IPv4:
#
# When set to Yes, this option prevents generated scripts from altering
# the /etc/iproute2/rt_tables database when there are entries in /etc/
# shorewall/providers. If you set this option to Yes while Shorewall
# (Shorewall-lite) is running, you should remove the file /var/lib/
# shorewall/rt_tables (/var/lib/shorewall-lite/rt_tables) before your
# next stop, restore, reload or restart command.
#
# IPv6:
#
# When set to Yes, this option prevents scripts generated by Shorewall6
# from altering the /etc/iproute2/rt_tables database when there are
# entries in /etc/shorewall6/providers. If you set this option to Yes
# while Shorewall6 (Shorewall6-lite) is running, you should remove the
# file /var/lib/shorewall6/rt_tables (/var/lib/shorewall6-lite/rt_tables)
# before your next stop, restore, reload or restart command.
#
# Important
#
# When both IPv4 and IPv6 Shorewall configurations are present,
# KEEP_RT_TABLES=No should be specified in only one of the two configurations
# unless the two provider configurations are identical with respect to
# interface and provider names and numbers.
#
# The default is KEEP_RT_TABLES=No.
#
MACLIST_TABLE=filter
#
# MACLIST_TABLE=[filter|mangle]
#
# Normally, MAC verification occurs in the filter table (INPUT and FORWARD)
# chains. When forwarding a packet from an interface with MAC verification to
# a bridge interface, that doesn't work.
#
# This problem can be worked around by setting MACLIST_TABLE=mangle which
# will cause Mac verification to occur out of the PREROUTING chain. Because
# REJECT isn't available in that environment, you may not specify
# MACLIST_DISPOSITION=REJECT or MACLIST_DISPOSITION=A_REJECT with
# MACLIST_TABLE=mangle.
#
MACLIST_TTL=
#
# MACLIST_TTL=[number]
#
# The performance of configurations with a large numbers of entries in
# shorewall-maclist(5) can be improved by setting the MACLIST_TTL variable in
# shorewall[6].conf(5).
#
# If your iptables and kernel support the "Recent Match" (see the output of
# "shorewall check" near the top), you can cache the results of a 'maclist'
# file lookup and thus reduce the overhead associated with MAC Verification.
#
# When a new connection arrives from a 'maclist' interface, the packet passes
# through then list of entries for that interface in shorewall-maclist(5). If
# there is a match then the source IP address is added to the 'Recent' set
# for that interface. Subsequent connection attempts from that IP address
# occurring within $MACLIST_TTL seconds will be accepted without having to
# scan all of the entries. After $MACLIST_TTL from the first accepted
# connection request from an IP address, the next connection request from
# that IP address will be checked against the entire list.
#
# If MACLIST_TTL is not specified or is specified as empty (e.g, MACLIST_TTL=
# "" or is specified as zero then 'maclist' lookups will not be cached).
#
MANGLE_ENABLED=Yes
#
# MANGLE_ENABLED=[Yes|No]
#
# Determines whether Shorewall will generate rules in the Netfilter mangle
# table. Setting MANGLE_ENABLED=No disables all Shorewall features that
# require the mangle table. The default is MANGLE_ENABLED=Yes.
#
MARK_IN_FORWARD_CHAIN=No
#
# MARK_IN_FORWARD_CHAIN=[Yes|No]
#
# If your kernel has a FORWARD chain in the mangle table, you may set
# MARK_IN_FORWARD_CHAIN=Yes to cause the marking specified in the tcrules
# file to occur in that chain rather than in the PREROUTING chain. This
# permits you to mark inbound traffic based on its destination address when
# DNAT is in use. To determine if your kernel has a FORWARD chain in the
# mangle table, use the shorewall [-6] show mangle command; if a FORWARD
# chain is displayed then your kernel will support this option. If this
# option is not specified or if it is given the empty value (e.g.,
# MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed.
#
MINIUPNPD=No
#
# MINIUPNPD=[Yes|No]
#
# Added in Shorewall 5.0.8. If set to Yes, Shorewall will create a chain in
# the nat table named MINIUPNPD-POSTROUTING and will add jumps from
# POSTROUTING to that chain for each interface with the upnpd option
# specified. Default is No.
#
MUTEX_TIMEOUT=60
#
# MUTEX_TIMEOUT=[seconds]
#
# The value of this variable determines the number of seconds that programs
# will wait for exclusive access to the Shorewall[6] lock file. After the
# number of seconds corresponding to the value of this variable, programs
# will assume that the last program to hold the lock died without releasing
# the lock.
#
# If not set or set to the empty value, a value of 60 (60 seconds) is
# assumed.
#
# An appropriate value for this parameter would be twice the length of time
# that it takes your firewall system to process a shorewall [-6] restart
# command.
#
OPTIMIZE=All
#
# OPTIMIZE=[value]
#
# The specified value enables certain optimizations. Each optimization
# category is associated with a power of two. To enable multiple optimization
# categories, simply add their corresponding numbers together.
#
# Beginning with Shorewall 4.5.20, you may specify OPTIMIZE=All to enable all
# optimization categories, and you may also specify OPTIMIZE=None to disable
# optimization.
#
# □ Optimization category 1 - Traditionally, Shorewall has created rules
# for the complete matrix of host groups defined by the zones, interfaces
# and hosts files. Any traffic that didn't correspond to an element of
# that matrix was rejected in one of the built-in chains. When the matrix
# is sparse, this results in lots of largely useless rules.
#
# These extra rules can be eliminated by setting the 1 bit in OPTIMIZE.
#
# The 1 bit setting also controls the suppression of redundant wildcard
# rules (those specifying "all" in the SOURCE or DEST column). A wildcard
# rule is considered to be redundant when it has the same ACTION and Log
# Level as the applicable policy.
#
# Note
#
# Optimization level 1 is ignored when optimization level 4 is also
# selected, since level 4 performs similar optimizations in a more robust
# way.
#
# □ Optimization category 2 - Added in Shorewall 4.4.7. When set,
# suppresses superfluous ACCEPT rules in a policy chain that implements
# an ACCEPT policy. Any ACCEPT rules that immediately precede the final
# blanket ACCEPT rule in the chain are now omitted.
#
# □ Optimization category 4 - Added in Shorewall 4.4.7. When set, causes
# short chains (those with less than 2 rules) to be optimized away. The
# following chains are excluded from optimization:
#
# ☆ accounting chains (unless OPTIMIZE_ACCOUNTING=Yes)
#
# ☆ action chains (user-defined)
#
# ☆ 'blacklst' chain
#
# ☆ dynamic
#
# ☆ forwardUPnP
#
# ☆ UPnP (nat table)
#
# Additionally:
#
# ☆ If a built-in chain has a single rule that branches to a second
# chain, then the rules from the second chain are moved to the
# built-in chain and the target chain is omitted.
#
# ☆ Chains with no references are deleted.
#
# ☆ Accounting chains are subject to optimization if the
# OPTIMIZE_ACCOUNTING option is set to 'Yes'.
#
# ☆ If a chain ends with an unconditional branch to a second chain
# (other than to 'reject'), then the branch is deleted from the first
# chain and the rules from the second chain are appended to it.
#
# An additional optimization was added in Shorewall 4.5.4. If the last
# rule in a chain is an unqualified jump to a simple target, then all
# immediately preceding rules with the same simple target are omitted.
#
# For example, consider this chain:
#
# -A fw-net -p udp --dport 67:68 -j ACCEPT
# -A fw-net -p udp --sport 1194 -j ACCEPT
# -A fw-net -p 41 -j ACCEPT
# -A fw-net -j ACCEPT
#
# Since all of the rules are jumps to the simple target ACCEPT, this
# chain is totally optimized away and jumps to the chain are replace with
# jumps to ACCEPT.
#
# □ Optimization category 8 - Added in Shorewall 4.4.9. When set, causes
# chains with identical rules to be collapsed into a single chain.
#
# Warning
#
# While Optimization category 8 can significantly reduce the size of the
# generated iptables ruleset, it can also take significant system
# resources during compilation. If you find that compilation takes an
# unreasonably long time, try disabling this category by setting OPTIMIZE
# =23.
#
# □ Optimization category 16 - Added in Shorewall 4.4.26. When set, causes
# sequences of compatible rules to be combined into a single rule. Rules
# are considered compatible if they differ only in their destination
# ports and comments.
#
# A sequence of compatible rules is often generated when macros are
# invoked in sequence.
#
# The ability to combine adjacent rules is limited by two factors:
#
# ☆ Destination port lists may only be combined up to a maximum of 15
# ports, where a port-pair counts as two ports.
#
# ☆ Rules may only be combined until the length of their concatenated
# comment reaches 255 characters.
#
# When either of these limits would be exceeded, the current combined
# rule is emitted and the compiler attempts to combine rules beginning
# with the one that would have exceeded the limit. Adjacent combined
# comments are separated by ', '. Empty comments at the front of a group
# of combined comments are replaced by 'Others and'. Empty comments at
# the end of a group of combined comments are replaced by 'and others'.
#
# Beginning in Shorewall 4.5.10, this option also suppresses duplicate
# adjacent rules and duplicate non-adjacent rules that don't include mark
# , connmark, dscp, ecn, set, tos or u32 matches.
#
# Example 1:
#
# Rules with comments "FOO", and "BAR" would result in the
# combined comment "FOO and others, BAR".
#
# Example 2:
#
# Rules with comments , "FOO" and "BAR" would result in the
# combined comment "Others and FOO, BAR". Note: Optimize level 16
# requires "Extended Multi-port Match" in your iptables and kernel.
#
# In versions prior to 5.1.0, the default value is zero which disables all
# optimizations. Beginning with Shorewall 5.1.0, the default value is All
# which enables all optimizations.
#
OPTIMIZE_ACCOUNTING=No
#
# OPTIMIZE_ACCOUNTING=[Yes|No]
#
# Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting changes are
# subject to optimization (OPTIMIZE=4,5,6 or 7). If not specified or set to
# the empty value, OPTIMIZE_ACCOUNTING=No is assumed.
#
PERL_HASH_SEED=0
#
# PERL_HASH_SEED=seed|random
#
# Added in Shorewall 5.1.4. Sets the Perl hash seed (an integer in the range
# 0-99999) when running the Shorewall rules compiler. If not specified, the
# value 0 is assumed. If random is specified, a random seed will be chosed by
# Perl. See perlsec(1) for additional information.
#
REJECT_ACTION=
#
# REJECT_ACTION=action
#
# Added in Shorewall 4.5.21. When a REJECT target is specified, Shorewall
# normally handles the response as follows:
#
# □ If the destination address of the packet is a broadcast or multicast
# address, the packet is dropped.
#
# □ if the protocol is ICMP (2) then the packet is dropped.
#
# □ if the protocol is TCP (6) then the packet is rejected with an RST.
#
# □ if the protocol is UDP (17) then the packet is rejected with an
# 'port-unreachable' ICMP.
#
# □ if the protocol is ICMP (1) then the packet is rejected with a
# 'host-unreachable' ICMP.
#
# □ if the protocol is ICMP6 (1) then the packet is rejected with a
# 'icmp6-addr-unreachable' ICMP6.
#
# □ otherwise, the packet is rejected with a 'host-prohibited' ICMP.
#
# You can modify this behavior by implementing your own action that handles
# REJECT and specifying it's name in this option. The nolog and noinline
# options will automatically be assumed for the specified action.
#
# The following action implements the default reject action:
#
# ?format 2
# #TARGET SOURCE DEST PROTO
# Broadcast(DROP) - - -
# DROP - - 2
# INLINE - - 6 ;; -j REJECT --reject-with tcp-reset
# ?if __ENHANCED_REJECT
# INLINE - - 17 ;; -j REJECT
# ?if __IPV4
# INLINE - - 1 ;; -j REJECT --reject-with icmp-host-unreachable
# INLINE - - - ;; -j REJECT --reject-with icmp-host-prohibited
# ?else
# INLINE - - 58 ;; -j REJECT --reject-with icmp6-addr-unreachable
# INLINE - - - ;; -j REJECT --reject-with icmp6-adm-prohibited
# ?endif
# ?else
# INLINE - - - ;; -j REJECT
# ?endif
#
RENAME_COMBINED=Yes
#
# RENAME_COMBINED=[Yes|No]
#
# Added in Shorewall 5.2.0. Traditionally, when OPTIMIZE category 8 is
# enabled, identical chains are combined under a name beginning with '~comb'
# or '~blacklist'. This behavior is maintained under the default setting
# RENAME_COMBINED=Yes. If RENAMED_COMBINED=No, the chains are combined under
# the original name of one of the chains.
#
REQUIRE_INTERFACE=Yes
#
# REQUIRE_INTERFACE=[Yes|No]
#
# Added in Shorewall 4.4.10. The default is No. If set to Yes, at least one
# optional interface must be up in order for the firewall to be in the
# started state. Intended to be used with the Shorewall Init Package.
#
RESTART=restart
#
# RESTART=[restart|reload]
#
# Added in Shorewall 5.0.1 to replace LEGACY_RESTART which was added in
# Shorewall 5.0.0. In that release, the reload command was redefined to do
# what restart had done in earlier releases and restart became a true restart
# (equivalent to stop followed by start). When RESTART=reload, the restart
# command performs the same operation as the reload command making it
# compatible with earlier releases. If not specified, RESTART=reload is
# assumed.
#
RESTORE_DEFAULT_ROUTE=Yes
#
# RESTORE_DEFAULT_ROUTE=[Yes|No]
#
# This option determines whether to restore the default route saved when here
# are 'balance' providers defined but all of them are down.
#
# The default is RESTORE_DEFAULT_ROUTE=Yes which preserves the pre-4.2.6
# behavior.
#
# RESTORE_DEFAULT_ROUTE=No is appropriate when you don't want a default route
# in the main table (USE_DEFAULT_RT=No) or in the default table
# (USE_DEFAULT_RT=Yes) when there are no balance providers available. In that
# case, RESTORE_DEFAULT_ROUTE=No will cause any default route in the relevant
# table to be deleted.
#
RESTORE_ROUTEMARKS=Yes
#
# RESTORE_ROUTEMARKS=[Yes|No]
#
# Added in Shorewall 4.5.9. When set to Yes (the default), provider marks are
# restored unconditionally at the top of the mangle OUTPUT and PREROUTING
# chains, even if the saved mark is zero. When this option is set to No, the
# mark is restored only if it is non-zero. If you have problems with IPSEC
# ESP packets not being routed correctly on output, try setting this option
# to No.
#
SAVE_IPSETS=No
#
# SAVE_IPSETS={Yes|No|ipv4|setlist}
#
# Re-enabled in Shorewall 4.4.6. If SAVE_IPSETS=Yes, then the current
# contents of your ipsets will be saved by the shorewall stop and shorewall
# save commands and restored by the shorewall start and shorewall restore
# commands.
#
# Beginning with Shorewall 4.6.4, you can restrict the set of ipsets saved by
# specifying a setlist (a comma-separated list of ipv4 ipset names). You may
# also restrict the saved sets to just the ipv4 ones by specifying ipv4.
#
TC_ENABLED=Shared
#
# TC_ENABLED=[Yes|No|Internal|Simple|Shared]
#
# If you say Yes or yes here, Shorewall will use a script that you supply to
# configure traffic shaping. The script must be named 'tcstart' and must be
# placed in a directory on your CONFIG_PATH.
#
# If you say No or no then traffic shaping is not enabled.
#
# If you set TC_ENABLED=Simple (Shorewall 4.4.6 and later), simple traffic
# shaping using shorewall-tcinterfaces(5) and shorewall-tcpri(5) is enabled.
#
# If you set TC_ENABLED=Internal or internal or leave the option empty then
# Shorewall will use its builtin traffic shaper (tc4shorewall written by Arne
# Bernin.
#
# Beginning with Shorewall 4.4.15, you can set TC_ENABLED=Shared. This allows
# you to configure the tcdevices and tcclasses in your Shorewall6
# configuration yet make them available to the compiler when compiling your
# Shorewall configuration. In addition to setting TC_ENABLED=Shared, you need
# to create symbolic links from your Shorewall configuration directory
# (normally /etc/shorewall/) to the tcdevices and tcclasses files in your
# Shorewall6 configuration directory (normally /etc/shorewall6/).
#
TC_EXPERT=No
#
# TC_EXPERT={Yes|No}
#
# Normally, Shorewall tries to protect users from themselves by preventing
# PREROUTING and OUTPUT tcrules from being applied to packets that have been
# marked by the 'track' option in shorewall-providers(5).
#
# If you know what you are doing, you can set TC_EXPERT=Yes and Shorewall
# will not include these cautionary checks.
#
TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2"
#
# TC_PRIOMAP=map
#
# Added in Shorewall 4.4.6. Determines the mapping of a packet's TOS field to
# priority bands. See shorewall-tcpri(5). The map consists of 16
# space-separated digits with values 1, 2 or 3. A value of 1 corresponds to
# Linux priority 0, 2 to Linux priority 1, and 3 to Linux Priority 2. The
# first entry gives the priority of TOS value 0, the second of TOS value 1,
# and so on. See tc-prio(8) for additional information.
#
# The default setting is TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2".
#
TRACK_PROVIDERS=Yes
#
# TRACK_PROVIDERS={Yes|No}
#
# Added in Shorewall 4.4.3. When set to Yes, causes the track option to be
# assumed on all providers defined in shorewall-providers(5). May be
# overridden on an individual provider through use of the notrack option. The
# default value is 'No'.
#
# Beginning in Shorewall 4.4.6, setting this option to 'Yes' also simplifies
# PREROUTING rules in shorewall-tcrules(5). Previously, when TC_EXPERT=No,
# packets arriving through 'tracked' provider interfaces were unconditionally
# passed to the PREROUTING tcrules. This was done so that tcrules could reset
# the packet mark to zero, thus allowing the packet to be routed using the
# 'main' routing table. Using the main table allowed dynamic routes (such as
# those added for VPNs) to be effective. The rtrules file was created to
# provide a better alternative to clearing the packet mark. As a consequence,
# passing these packets to PREROUTING complicates things without providing
# any real benefit. Beginning with Shorewall 4.4.6, when TRACK_PROVIDERS=Yes
# and TC_EXPERT=No, packets arriving through 'tracked' interfaces will not be
# passed to the PREROUTING rules. Since TRACK_PROVIDERS was just introduced
# in 4.4.3, this change should be transparent to most, if not all, users.
#
TRACK_RULES=No
#
# TRACK_RULES={Yes|No|File}
#
# Added in Shorewall 4.5.20. If set to Yes, causes the compiler to add a
# comment to iptables rules to indicate the file name and line number of the
# configuration entry that generated the rule. If set to No (the default),
# then no such comments are added.
#
# Setting this option to Yes requires the Comments capability in iptables and
# kernel.
#
# Beginning with Shorewall 5.0.5, the option may also be set to File. That
# setting causes similar comments to be added to the .iptables-restore-input
# file, which is normally created in /var/lib/shorewall.
#
USE_DEFAULT_RT=Yes
#
# USE_DEFAULT_RT=[Yes|No]
#
# When set to 'Yes', this option causes the Shorewall multi-ISP feature to
# create a set of routing rules which are resilient to changes in the main
# routing table. Such changes can occur for a number of reasons, VPNs going
# up and down being an example. The idea is to send packets through the main
# table prior to applying any of the Shorewall-generated routing rules. So
# changes to the main table will affect the routing of packets by default.
#
# When USE_DEFAULT_RT=Yes:
#
# 1. Both the DUPLICATE and the COPY columns in providers(5) file must
# remain empty (or contain "-").
#
# 2. The default route is added to the the 'default' table rather than to
# the main table.
#
# 3. If running Shorewall 5.1.0 or earlier or if BALANCE_PROVIDERS=Yes
# (Shorewall 5.1.1 or later), then the balance provider option is assumed
# unless the fallback, loose, load or tproxy option is specified.
#
# 4. Packets are sent through the main routing table by a rule with priority
# 999. In shorewall-rtrules(5), the range 1-998 may be used for inserting
# rules that bypass the main table.
#
# 5. All provider gateways must be specified explicitly in the GATEWAY
# column. detect may not be specified.
#
# Note
#
# detect may be specified for interfaces whose configuration is managed
# by dhcpcd. Shorewall will use dhcpcd's database to find the interface's
# gateway.
#
# 6. You should disable all default route management outside of Shorewall.
# If a default route is added to the main table while Shorewall is
# started, then all policy routing will stop working (except for those
# routing rules in the priority range 1-998).
#
# Prior to Shorewall 4.6.0, if USE_DEFAULT_RT was not set or if it was set to
# the empty string then USE_DEFAULT_RT=No was assumed. Beginning with
# Shorewall 4.6.0, the default is USE_DEFAULT_RT=Yes and use of
# USE_DEFAULT_RT=No is deprecated.
#
# Warning
#
# The enable, disable and reenable commands do not work correctly when
# USE_DEFAULT_RT=No.
#
USE_NFLOG_SIZE=No
#
# USE_NFLOG_SIZE=[Yes|No]
#
# Added in Shorewall 5.1.5. The second parameter to the NFLOG target
# specifies how many bytes of the packet to copy to the log; if omitted or if
# supplied as zero, the entire packet is copied. This feature has
# traditionally been implemented using the --nflog-range option to the NFLOG
# iptables target. Unfortuntely, the --nflog-range option never worked (the
# entire packet was always copied). To deal with this issue, the Netfilter
# team:
#
# □ Added a warning message when --nflog-range is used
#
# □ Added --nflog-size which works like --nflog-range was intended to work.
#
# When USE_NFLOG_SIZE=Yes, Shorewall will attempt to use the new --nflog-size
# feature. If that feature is not available in the running kernel and ip[6]
# tables, an error is raised.
#
# When USE_NFLOG_SIZE is not supplied, USE_NFLOG_SIZE=No is assumed. When
# USE_NFLOG_SIZE is added by shorewall update, it is added with setting No.
#
USE_PHYSICAL_NAMES=No
#
# USE_PHYSICAL_NAMES=[Yes|No]
#
# Added in Shorewall 4.4.27. Normally, when Shorewall creates a Netfilter
# chain that relates to an interface, it uses the interface's logical name as
# the base of the chain name. For example, if the logical name for an
# interface is OAKLAND, then the input chain for traffic arriving on that
# interface would be 'OAKLAND_in'. If this option is set to Yes, then the
# physical name of the interface will be used the base of the chain name.
#
USE_RT_NAMES=No
#
# USE_RT_NAMES=[Yes|No]
#
# Added in Shorewall 4.5.15. When set to 'Yes', Shorewall will use routing
# table (provider) names in the generated script rather than table numbers.
# When set to 'No' (the default), routing table numbers will be used.
#
# Caution
#
# If you set USE_RT_NAMES=Yes and KEEP_RT_TABLES=Yes, then you must insure
# that all of your providers have entries in /etc/iproute2/rt_tables as well
# as the following entries:
#
# 255 local
# 254 main
# 253 default
# 250 balance
# 0 unspec
#
# Without these entries, the firewall will fail to start.
#
VERBOSE_MESSAGES=Yes
#
# VERBOSE_MESSAGES=[Yes|No]
#
# Added in Shorewall 5.0.9. When Yes (the default), messages produced by the
# ?INFO and ?WARNING directives include the filename and linenumber of the
# directive. When set to No, that additional information is omitted. The
# setting may be overridden on a directive by directive basis by following ?
# INFO or ?WARNING with '!' (no intervening white space).
#
WARNOLDCAPVERSION=Yes
#
# WARNOLDCAPVERSION=[Yes|No]
#
# Added in Shorewall 4.5.12. When set to Yes (the default), the compiler
# issues a warning when it finds a capabilities file that doesn't specify all
# of the capabilities supported by the compiler. When WARNOLDCAPVERSION is
# set to No, no warning is issued.
#
WORKAROUNDS=No
#
# WORKAROUNDS=[Yes|No]
#
# Added in Shorewall 4.6.11. Over time, there have been a number of changes
# in Shorewall that work around defects in other products such as iptables
# and ipset. When WORKAROUNDS=Yes, these workarounds are enabled; when
# WORKAROUNDS=No, they are disabled. If not specified or if specified as
# empty, WORKAROUNDS=Yes is assumed.
#
# Warning
#
# Do not set WORKAROUNDS=Yes if you need to be able to use
# Shorewall-generated scripts (such as created by the save command) built by
# Shorewall 4.4.7 or older.
#
ZERO_MARKS=No
#
# ZERO_MARKS=[Yes|No]
#
# Added in Shorewall 5.0.12, this is a workaround for an issue where packet
# marks are not zeroed by the kernel. It should be set to No (the default)
# unless you find that incoming packets are being mis-routed for no apparent
# reasons.
#
# Caution
#
# Do not set this option to Yes if you have IPSEC software running on the
# firewall system.
#
ZONE2ZONE=-
#
# ZONE2ZONE=[2|-]
#
# Added in Shorewall 4.4.4. This option determines how Shorewall constructs
# chain names involving zone names and/or 'all'. Beginning with Shorewall
# 4.6.0, the default is '-' (e.g., fw-net); prior to that release, the
# default was '2' (e.g., fw2net).
#
###############################################################################
# P A C K E T D I S P O S I T I O N
###############################################################################
BLACKLIST_DISPOSITION=DROP
#
# BLACKLIST_DISPOSITION=[DROP|A_DROP|REJECT|A_REJECT]
#
# This parameter determines the disposition of packets from blacklisted
# hosts. It may have the value DROP if the packets are to be dropped or
# REJECT if the packets are to be replied with an ICMP port unreachable reply
# or a TCP RST (tcp only). If you do not assign a value or if you assign an
# empty value then DROP is assumed.
#
# A_DROP and A_REJECT are audited versions of DROP and REJECT respectively
# and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel
# and iptables.
#
# The BLACKLIST_DISPOSITION setting determines the disposition of packets
# sent to the blacklog target of shorewall-blrules (5), but otherwise does
# not affect entries in that file.
#
INVALID_DISPOSITION=CONTINUE
#
# INVALID_DISPOSITION=[A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
#
# Added in Shorewall 4.5.13. Shorewall has traditionally passed INVALID
# packets through the NEW section of shorewall-rules (5). When a packet in
# INVALID state fails to match any rule in the INVALID section, the packet is
# disposed of based on this setting. The default value is CONTINUE for
# compatibility with earlier versions.
#
MACLIST_DISPOSITION=REJECT
#
# MACLIST_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]
#
# Determines the disposition of connections requests that fail MAC
# Verification and must have the value ACCEPT (accept the connection request
# anyway), REJECT (reject the connection request) or DROP (ignore the
# connection request). If not set or if set to the empty value (e.g.,
# MACLIST_DISPOSITION="") then MACLIST_DISPOSITION=REJECT is assumed.
#
# A_DROP and A_REJECT are audited versions of DROP and REJECT respectively
# and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel
# and ip[6]tables.
#
RELATED_DISPOSITION=ACCEPT
#
# RELATED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
#
# Added in Shorewall 4.4.27. Shorewall has traditionally ACCEPTed RELATED
# packets that don't match any rule in the RELATED section of shorewall-rules
# (5). Concern about the safety of this practice resulted in the addition of
# this option. When a packet in RELATED state fails to match any rule in the
# RELATED section, the packet is disposed of based on this setting. The
# default value is ACCEPT for compatibility with earlier versions.
#
SFILTER_DISPOSITION=DROP
#
# SFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]
#
# Added in Shorewall 4.4.20. Determines the disposition of packets matching
# the sfilter option (see shorewall-interfaces(5)) and of hairpin packets on
# interfaces without the routeback option.^[1]
#
RPFILTER_DISPOSITION=DROP
#
# RPFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]
#
# Added in Shorewall 4.5.7. Determines the disposition of packets entering
# from interfaces the rpfilter option (see shorewall-interfaces(5)). Packets
# disposed of by this option are those whose response packets would not be
# sent through the same interface receiving the packet.
#
SMURF_DISPOSITION=DROP
#
# SMURF_DISPOSITION=[DROP|A_DROP]
#
# Added in Shorewall 4.4.20. The default setting is DROP which causes smurf
# packets (see the nosmurfs option in shorewall-interfaces(5)) to be dropped.
# A_DROP causes the packets to be audited prior to being dropped and requires
# AUDIT_TARGET support in the kernel and iptables.
#
TCP_FLAGS_DISPOSITION=DROP
#
# TCP_FLAGS_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]
#
# Determines the disposition of TCP packets that fail the checks enabled by
# the tcpflags interface option (see shorewall-interfaces(5)) and must have a
# value of ACCEPT (accept the packet), REJECT (send an RST response) or DROP
# (ignore the packet). If not set or if set to the empty value (e.g.,
# TCP_FLAGS_DISPOSITION="") then TCP_FLAGS_DISPOSITION=DROP is assumed.
#
# A_DROP and A_REJECT are audited versions of DROP and REJECT respectively
# and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel
# and iptables.
#
UNTRACKED_DISPOSITION=CONTINUE
#
# UNTRACKED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
#
# Added in Shorewall 4.5.13. Shorewall has traditionally passed UNTRACKED
# packets through the NEW section of shorewall-rules (5). When a packet in
# UNTRACKED state fails to match any rule in the UNTRACKED section, the
# packet is disposed of based on this setting. The default value is CONTINUE
# for compatibility with earlier versions.
#
################################################################################
# P A C K E T M A R K L A Y O U T
################################################################################
TC_BITS=
#
# TC_BITS=[number]
#
# The number of bits at the low end of the 32-bit packet mark to be used for
# traffic shaping marking. May be zero. See MASK_BITS above for default
# value.
#
PROVIDER_BITS=
#
# PROVIDER_BITS=[number]
#
# Added in Shorewall 4.4.26. The number of bits in the 32-bit packet mark to
# be used for provider numbers. May be zero. See MASK_BITS above for default
# value.
#
PROVIDER_OFFSET=
#
# PROVIDER_OFFSET=[number]If
#
# Added in Shorewall 4.4.26. The offset from the right (low-order end) of the
# provider number field in the 32-bit packet mark. If non-zero, must be >=
# TC_BITS (Shorewall automatically adjusts PROVIDER_OFFSET's value).
# PROVIDER_OFFSET + PROVIDER_BITS + ZONE_BITS must be < 32. See MASK_BITS
# above for default value.
#
MASK_BITS=
#
# MASK_BITS=[number]
#
# Added in Shorewall 4.4.26. Number of bits on the right of the 32-bit packet
# mark to be masked when clearing the traffic shaping mark. Must be >=
# TC_BITS and <= PROVIDER_OFFSET (if PROVIDER_OFFSET > 0). Prior to Shorewall
# 5.0.0, default value and the default values of the other mark layout
# options is determined as follows:
#
# Table 1. Default Packet Mark Layout
#
# WIDE_TC_MARKS=No, TC_BITS=8, PROVIDER_BITS=8, PROVIDER_OFFSET=
# HIGH_ROUTE_MARKS=No 0, MASK_BITS=8
# WIDE_TC_MARKS=No, TC_BITS=8, PROVIDER_BITS=8, PROVIDER_OFFSET=
# HIGH_ROUTE_MARKS=Yes 8, MASK_BITS=8
# WIDE_TC_MARKS=Yes, TC_BITS=14, PROVIDER_BITS=8, PROVIDER_OFFSET=
# HIGH_ROUTE_MARKS=No 0, MASK_BITS=16
# WIDE_TC_MARKS=Yes, TC_BITS=14, PROVIDER_BITS=8, PROVIDER_OFFSET=
# HIGH_ROUTE_MARKS=Yes 16, MASK_BITS=16
#
#
# From 5.0.0 onward, the default value of MASK_BITS is 8, the default value
# of PROVIDER_BITS, TC_BITS, MASK_BITS and PROVIDER_OFFSET is 8.
#
ZONE_BITS=0
#
# ZONE_BITS=[number]
#
# Added in Shorewall 4.4.26. When non-zero, enables automatic packet marking
# by source zone and determines the number of bits in the 32-bit packet mark
# to be used for the zone mark. Default value is 0.
#
shorewall6-5.2.3.4/Samples6/Universal/shorewall6.conf 0000664 0000000 0000000 00000012057 13531060406 021053 0 ustar root root ###############################################################################
#
# Shorewall Version 5 -- /etc/shorewall6/shorewall6.conf
#
# For information about the settings in this file, type "man shorewall6.conf"
#
# Manpage also online at
# http://www.shorewall.net/manpages6/shorewall6.conf.html
###############################################################################
# S T A R T U P E N A B L E D
###############################################################################
STARTUP_ENABLED=Yes
###############################################################################
# V E R B O S I T Y
###############################################################################
VERBOSITY=1
###############################################################################
# P A G E R
###############################################################################
PAGER=
###############################################################################
# F I R E W A L L
###############################################################################
FIREWALL=
###############################################################################
# L O G G I N G
###############################################################################
LOG_LEVEL="info"
BLACKLIST_LOG_LEVEL=
INVALID_LOG_LEVEL=
LOG_BACKEND=
LOG_VERBOSITY=2
LOG_ZONE=Both
LOGALLNEW=
LOGFILE=
LOGFORMAT="%s %s "
LOGLIMIT="s:1/sec:10"
LOGTAGONLY=No
MACLIST_LOG_LEVEL="$LOG_LEVEL"
RELATED_LOG_LEVEL=
RPFILTER_LOG_LEVEL="$LOG_LEVEL"
SFILTER_LOG_LEVEL="$LOG_LEVEL"
SMURF_LOG_LEVEL="$LOG_LEVEL"
STARTUP_LOG=/var/log/shorewall6-init.log
TCP_FLAGS_LOG_LEVEL="$LOG_LEVEL"
UNTRACKED_LOG_LEVEL=
###############################################################################
# L O C A T I O N O F F I L E S A N D D I R E C T O R I E S
###############################################################################
CONFIG_PATH=":${CONFDIR}/shorewall6:${SHAREDIR}/shorewall6:${SHAREDIR}/shorewall"
GEOIPDIR=/usr/share/xt_geoip/LE
IP6TABLES=
IP=
IPSET=
LOCKFILE=
MODULESDIR=
NFACCT=
PERL=/usr/bin/perl
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
RESTOREFILE=restore
SHOREWALL_SHELL=/bin/sh
SUBSYSLOCK=
TC=
###############################################################################
# D E F A U L T A C T I O N S / M A C R O S
###############################################################################
ACCEPT_DEFAULT="none"
BLACKLIST_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP),dropNotSyn:$LOG_LEVEL,dropInvalid:$LOG_LEVEL,DropDNSrep:$LOG_LEVEL"
DROP_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)"
NFQUEUE_DEFAULT="none"
QUEUE_DEFAULT="none"
REJECT_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)"
###############################################################################
# R S H / R C P C O M M A N D S
###############################################################################
RCP_COMMAND='scp ${files} ${root}@${system}:${destination}'
RSH_COMMAND='ssh ${root}@${system} ${command}'
###############################################################################
# F I R E W A L L O P T I O N S
###############################################################################
ACCOUNTING=Yes
ACCOUNTING_TABLE=filter
ADMINISABSENTMINDED=Yes
AUTOCOMMENT=Yes
AUTOHELPERS=Yes
AUTOMAKE=Yes
BALANCE_PROVIDERS=No
BASIC_FILTERS=No
BLACKLIST="NEW,INVALID,UNTRACKED"
CLAMPMSS=No
CLEAR_TC=No
COMPLETE=Yes
DEFER_DNS_RESOLUTION=Yes
DELETE_THEN_ADD=Yes
DONT_LOAD=
DYNAMIC_BLACKLIST=Yes
EXPAND_POLICIES=Yes
EXPORTMODULES=Yes
FASTACCEPT=Yes
FORWARD_CLEAR_MARK=
HELPERS=
IGNOREUNKNOWNVARIABLES=No
IMPLICIT_CONTINUE=No
IPSET_WARNINGS=Yes
IP_FORWARDING=Keep
KEEP_RT_TABLES=Yes
MACLIST_TABLE=filter
MACLIST_TTL=
MANGLE_ENABLED=Yes
MARK_IN_FORWARD_CHAIN=No
MINIUPNPD=No
MUTEX_TIMEOUT=60
OPTIMIZE=All
OPTIMIZE_ACCOUNTING=No
PERL_HASH_SEED=0
REJECT_ACTION=
RENAME_COMBINED=Yes
REQUIRE_INTERFACE=Yes
RESTART=restart
RESTORE_DEFAULT_ROUTE=Yes
RESTORE_ROUTEMARKS=Yes
SAVE_IPSETS=No
TC_ENABLED=Shared
TC_EXPERT=No
TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2"
TRACK_PROVIDERS=Yes
TRACK_RULES=No
USE_DEFAULT_RT=Yes
USE_NFLOG_SIZE=No
USE_PHYSICAL_NAMES=No
USE_RT_NAMES=No
VERBOSE_MESSAGES=Yes
WARNOLDCAPVERSION=Yes
WORKAROUNDS=No
ZERO_MARKS=No
ZONE2ZONE=-
###############################################################################
# P A C K E T D I S P O S I T I O N
###############################################################################
BLACKLIST_DISPOSITION=DROP
INVALID_DISPOSITION=CONTINUE
MACLIST_DISPOSITION=REJECT
RELATED_DISPOSITION=ACCEPT
SFILTER_DISPOSITION=DROP
RPFILTER_DISPOSITION=DROP
SMURF_DISPOSITION=DROP
TCP_FLAGS_DISPOSITION=DROP
UNTRACKED_DISPOSITION=CONTINUE
################################################################################
# P A C K E T M A R K L A Y O U T
################################################################################
TC_BITS=
PROVIDER_BITS=
PROVIDER_OFFSET=
MASK_BITS=
ZONE_BITS=0
shorewall6-5.2.3.4/Samples6/Universal/params 0000664 0000000 0000000 00000001440 13531060406 017316 0 ustar root root #
# Shorewall - Sample Params File for universal configuration.
# Copyright (C) 2006-2017 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------------------------------------
# For information on entries in this file, type "man shorewall-params"
######################################################################################################################################################################################################
shorewall6-5.2.3.4/Samples6/three-interfaces/ 0000775 0000000 0000000 00000000000 13531077663 017406 5 ustar root root shorewall6-5.2.3.4/Samples6/three-interfaces/rules 0000664 0000000 0000000 00000004114 13531060406 020446 0 ustar root root #
# Shorewall6 version 5.2 - Sample Rules File for three-interface configuration.
# Copyright (C) 2006-2014 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------------------------------------
# For information about entries in this file, type "man shorewall6-rules"
######################################################################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER
# PORT PORT(S) DEST LIMIT GROUP
?SECTION ALL
?SECTION ESTABLISHED
?SECTION RELATED
?SECTION INVALID
?SECTION UNTRACKED
?SECTION NEW
# Don't allow connection pickup from the net
#
Invalid(DROP) net all tcp
#
# Accept DNS connections from the firewall to the Internet
#
DNS(ACCEPT) $FW net
#
#
# Accept SSH connections from the local network to the firewall and DMZ
#
SSH(ACCEPT) loc $FW
SSH(ACCEPT) loc dmz
#
# DMZ DNS access to the Internet
#
DNS(ACCEPT) dmz net
# Drop Ping from the "bad" net zone.
Ping(DROP) net $FW
#
# Make ping work bi-directionally between the dmz, net, Firewall and local zone
# (assumes that the loc-> net policy is ACCEPT).
#
Ping(ACCEPT) loc $FW
Ping(ACCEPT) dmz $FW
Ping(ACCEPT) loc dmz
Ping(ACCEPT) dmz loc
Ping(ACCEPT) dmz net
ACCEPT $FW net ipv6-icmp
ACCEPT $FW loc ipv6-icmp
ACCEPT $FW dmz ipv6-icmp
# Uncomment this if using Proxy ARP and static NAT and you want to allow ping from
# the net zone to the dmz and loc
#Ping(ACCEPT) net dmz
#Ping(ACCEPT) net loc
shorewall6-5.2.3.4/Samples6/three-interfaces/zones 0000664 0000000 0000000 00000001377 13531060406 020462 0 ustar root root #
# Shorewall6 version 5.2 - Sample Zones File for three-interface configuration.
# Copyright (C) 2006-2014 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------
# For information about entries in this file, type "man shorewall6-zones"
#
###############################################################################
#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
fw firewall
net ipv6
loc ipv6
dmz ipv6
shorewall6-5.2.3.4/Samples6/three-interfaces/stoppedrules 0000664 0000000 0000000 00000001454 13531060406 022051 0 ustar root root #
# Shorewall6 - Sample Stoppedrules File for three-interface configuration.
# Copyright (C) 2012-2017 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------
# For information about entries in this file, type "man shorewall-stoppedrules"
###############################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE
# PORT(S) PORT(S)
ACCEPT LOC_IF -
ACCEPT - LOC_IF
ACCEPT DMZ_IF -
ACCEPT - DMZ_IF
shorewall6-5.2.3.4/Samples6/three-interfaces/zones.annotated 0000664 0000000 0000000 00000021524 13531077663 022447 0 ustar root root #
# Shorewall6 version 5.2 - Sample Zones File for three-interface configuration.
# Copyright (C) 2006-2014 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------
# For information about entries in this file, type "man shorewall6-zones"
#
###############################################################################
#
# The /etc/shorewall/zones file declares your network zones. You specify the
# hosts in each zone through entries in /etc/shorewall/interfaces or /etc/
# shorewall/hosts.
#
# The columns in the file are as follows (where the column name is followed by a
# different name in parentheses, the different name is used in the alternate
# specification syntax).
#
# ZONE - zone[:parent-zone[,parent-zone]...]
#
# Name of the zone. Must start with a letter and consist of letters, digits
# or '_'. The names "all", "none", "any", "SOURCE" and "DEST" are reserved
# and may not be used as zone names. The maximum length of a zone name is
# determined by the setting of the LOGFORMAT option in shorewall.conf(5).
# With the default LOGFORMAT, zone names can be at most 5 characters long.
#
# The maximum length of an iptables log prefix is 29 bytes. As explained
# in shorewall.conf (5), the legacy default LOGPREFIX formatting string
# is “Shorewall:%s:%s:” where the first %s is replaced by the chain name
# and the second is replaced by the disposition.
#
# ☆ The "Shorewall:%s:%s:" formatting string has 12 fixed characters
# ("Shorewall" and three colons).
#
# ☆ The longest of the standard dispositions are ACCEPT and REJECT
# which have 6 characters each.
#
# ☆ The canonical name for the chain containing the rules for traffic
# going from zone 1 to zone 2 is "2" or "-
# ".
#
# ☆ So if M is the maximum zone name length, such chains can have
# length 2*M + 1.
#
# 12 + 6 + 2*M + 1 = 29 which reduces to
# 2*M = 29 - 12 - 6 - 1 = 10 or
# M = 5
#
# In Shorewall 5.1.0, the LOGFORMAT in the default and sample
# shorewall.conf files was changed to "%s:%s ".
#
# ☆ That formatting string has 2 fixed characters (":" and a space).
#
# ☆ So the maximum zone name length M is calculated as:
#
# 2 + 6 + 2*M + 1 = 29
# 2M = 29 - 2 - 6 - 1 = 20
# M = 10
#
# The order in which Shorewall matches addresses from packets to zones is
# determined by the order of zone declarations. Where a zone is nested in one
# or more other zones, you may either ensure that the nested zone precedes
# its parents in this file, or you may follow the (sub)zone name by ":" and a
# comma-separated list of the parent zones. The parent zones must have been
# declared in earlier records in this file. See shorewall-nesting(5) for
# additional information.
#
# Example:
#
# #ZONE TYPE OPTIONS IN OPTIONS OUT OPTIONS
# a ip
# b ip
# c:a,b ip
#
# Currently, Shorewall uses this information to reorder the zone list so that
# parent zones appear after their subzones in the list. The IMPLICIT_CONTINUE
# option in shorewall.conf(5) can also create implicit CONTINUE policies to/
# from the subzone.
#
# Where an ipsec zone is explicitly included as a child of an ip zone, the
# ruleset allows CONTINUE policies (explicit or implicit) to work as
# expected.
#
# In the future, Shorewall may make additional use of nesting information.
#
# TYPE
#
# ip
#
# This is the standard Shorewall zone type and is the default if you
# leave this column empty or if you enter "-" in the column.
# Communication with some zone hosts may be encrypted. Encrypted hosts
# are designated using the 'ipsec' option in shorewall-hosts(5). For
# clarity, this zone type may be specified as ipv4 in IPv4 configurations
# and ipv6 in IPv6 configurations.
#
# ipsec
#
# Communication with all zone hosts is encrypted. Your kernel and
# iptables must include policy match support. For clarity, this zone type
# may be specified as ipsec4 in IPv4 configurations and ipsec6 in IPv6
# configurations.
#
# firewall
#
# Designates the firewall itself. You must have exactly one 'firewall'
# zone. No options are permitted with a 'firewall' zone. The name that
# you enter in the ZONE column will be stored in the shell variable $FW
# which you may use in other configuration files to designate the
# firewall zone.
#
# bport
#
# The zone is associated with one or more ports on a single bridge. For
# clarity, this zone type may be specified as bport4 in IPv4
# configurations and bport6 in IPv6 configurations.
#
# vserver
#
# Added in Shorewall 4.4.11 Beta 2 - A zone composed of Linux-vserver
# guests. The zone contents must be defined in shorewall-hosts (5).
#
# Vserver zones are implicitly handled as subzones of the firewall zone.
#
# loopback
#
# Added in Shorewall 4.5.17.
#
# Normally, Shorewall treats the loopback interface (lo) in the following
# way:
#
# ☆ By default, all traffic through the interface is ACCEPTed.
#
# ☆ If a $FW -> $FW policy is defined or $FW -> $FW rules are defined,
# they are placed in a chain named ${FW}2${F2} or ${FW}-${FW} (e.g.,
# 'fw2fw' or 'fw-fw' ) depending on the ZONE2ZONE setting in
# shorewall.conf(5).
#
# ☆ $FW -> $FW traffic is only filtered in the OUTPUT chain.
#
# By defining a loopback zone and associating it with the loopback
# interface in shorewall-interfaces(5), you can effect a slightly
# different model. Suppose that the loopback zone name is 'local'; then:
#
# ☆ Both $FW -> local and local -> $FW chains are created.
#
# ☆ The $FW -> local and local -> $FW policies may be different.
#
# ☆ Both $FW -> local and local -> $FW rules may be specified.
#
# Rules to/from the loopback zone and any zone other than the firewall
# zone are ignored with a warning.
#
# loopback zones may be nested within other loopback zones.
#
# local
#
# Added in Shorewall 4.5.17. local is the same as ipv4 with the exception
# that the zone is only accessible from the firewall and vserver zones.
#
# OPTIONS, IN OPTIONS and OUT OPTIONS (options, in_options, out_options) - [
# option[,option]...]
#
# A comma-separated list of options. With the exception of the mss and
# blacklist options, these only apply to TYPE ipsec zones.
#
# dynamic_shared
#
# Added in Shorewall 4.5.9. May only be specified in the OPTIONS column
# and indicates that only a single ipset should be created for this zone
# if it has multiple dynamic entries in shorewall-hosts(5). Without this
# option, a separate ipset is created for each interface.
#
# reqid=number
#
# where number is specified using setkey(8) using the 'unique:number
# option for the SPD level.
#
# spi=
#
# where number is the SPI of the SA used to encrypt/decrypt packets.
#
# proto=ah|esp|ipcomp
#
# IPSEC Encapsulation Protocol
#
# mss=number
#
# sets the MSS field in TCP packets. If you supply this option, you
# should also set FASTACCEPT=No in shorewall.conf(5) to insure that both
# the SYN and SYN,ACK packets have their MSS field adjusted.
#
# mode=transport|tunnel
#
# IPSEC mode
#
# 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
#
# 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 "-".
#
###############################################################################
#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
fw firewall
net ipv6
loc ipv6
dmz ipv6
shorewall6-5.2.3.4/Samples6/three-interfaces/interfaces.annotated 0000664 0000000 0000000 00000061757 13531077660 023445 0 ustar root root #
# Shorewall6 - Sample Interfaces File for three-interface configuration.
# Copyright (C) 2006-2017 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------
# For information about entries in this file, type "man shorewall6-interfaces"
###############################################################################
#
# The interfaces file serves to define the firewall's network interfaces to
# Shorewall. The order of entries in this file is not significant in determining
# zone composition.
#
# Beginning with Shorewall 4.5.3, the interfaces file supports two different
# formats:
#
# FORMAT 1 (default - deprecated)
#
# There is a BROADCAST column which can be used to specify the broadcast
# address associated with the interface.
#
# FORMAT 2
#
# The BROADCAST column is omitted.
#
# The format is specified by a line as follows:
#
# ?FORMAT {1|2}
#
# The columns in the file are as follows.
#
# ZONE - zone-name
#
# Zone for this interface. Must match the name of a zone declared in /etc/
# shorewall/zones. You may not list the firewall zone in this column.
#
# If the interface serves multiple zones that will be defined in the
# shorewall-hosts(5) file, you should place "-" in this column.
#
# If there are multiple interfaces to the same zone, you must list them in
# separate entries.
#
# Example:
#
# #ZONE INTERFACE BROADCAST
# loc eth1 -
# loc eth2 -
#
# INTERFACE - interface[:port]
#
# Logical name of interface. Each interface may be listed only once in this
# file. You may NOT specify the name of a "virtual" interface (e.g., eth0:0)
# here; see http://www.shorewall.net/FAQ.htm#faq18. If the physical option is
# not specified, then the logical name is also the name of the actual
# interface.
#
# You may use wildcards here by specifying a prefix followed by the plus sign
# ("+"). For example, if you want to make an entry that applies to all PPP
# interfaces, use 'ppp+'; that would match ppp0, ppp1, ppp2, …
#
# When using Shorewall versions before 4.1.4, care must be exercised when
# using wildcards where there is another zone that uses a matching specific
# interface. See shorewall-nesting(5) for a discussion of this problem.
#
# Shorewall allows '+' as an interface name, but that usage is deprecated. A
# better approach is to specify 'physical=+' in the OPTIONS column (see
# below).
#
# There is no need to define the loopback interface (lo) in this file.
#
# If a port is given, then the interface must have been defined previously
# with the bridge option. The OPTIONS column may not contain the following
# options when a port is given.
#
# arp_filter
# arp_ignore
# bridge
# log_martians
# mss
# optional
# proxyarp
# required
# routefilter
# sourceroute
# upnp
# wait
#
# Beginning with Shorewall 4.5.17, if you specify a zone for the 'lo'
# interface, then that zone must be defined as type local in shorewall6-zones
# (5).
#
# BROADCAST (Optional) - {-|detect|address[,address]...}
#
# Only available if FORMAT 1.
#
# If you use the special value detect, Shorewall will detect the broadcast
# address(es) for you if your iptables and kernel include Address Type Match
# support.
#
# If your iptables and/or kernel lack Address Type Match support then you may
# list the broadcast address(es) for the network(s) to which the interface
# belongs. For P-T-P interfaces, this column is left blank. If the interface
# has multiple addresses on multiple subnets then list the broadcast
# addresses as a comma-separated list.
#
# If you don't want to give a value for this column but you want to enter a
# value in the OPTIONS column, enter - in this column.
#
# OPTIONS (Optional) - [option[,option]...]
#
# A comma-separated list of options from the following list. The order in
# which you list the options is not significant but the list should have no
# embedded white-space.
#
# accept_ra[={0|1|2}]
#
# IPv6 only; added in Shorewall 4.5.16. Values are:
#
# 0
#
# Do not accept Router Advertisements.
#
# 1
#
# Accept Route Advertisements if forwarding is disabled.
#
# 2
#
# Overrule forwarding behavior. Accept Route Advertisements even if
# forwarding is enabled.
#
# If the option is specified without a value, then the value 1 is
# assumed.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# arp_filter[={0|1}]
#
# IPv4 only. If specified, this interface will only respond to ARP
# who-has requests for IP addresses configured on the interface. If not
# specified, the interface can respond to ARP who-has requests for IP
# addresses on any of the firewall's interface. The interface must be up
# when Shorewall is started.
#
# Only those interfaces with the arp_filter option will have their
# setting changed; the value assigned to the setting will be the value
# specified (if any) or 1 if no value is given.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# arp_ignore[=number]
#
# IPv4 only. If specified, this interface will respond to arp requests
# based on the value of number (defaults to 1).
#
# 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 the sender's IP address is part from same
# subnet on this interface's address
#
# 3 - do not reply for local addresses configured with scope host, only
# resolutions for global and link
#
# 4-7 - reserved
#
# 8 - do not reply for all local addresses
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# Warning
#
# Do not specify arp_ignore for any interface involved in Proxy ARP.
#
# blacklist
#
# Checks packets arriving on this interface against the
# shorewall-blacklist(5) file.
#
# Beginning with Shorewall 4.4.13:
#
# ☆ If a zone is given in the ZONES column, then the behavior is as if
# blacklist had been specified in the IN_OPTIONS column of
# shorewall-zones(5).
#
# ☆ Otherwise, the option is ignored with a warning:
#
# WARNING: The 'blacklist' option is ignored on multi-zone
# interfaces
#
# bridge
#
# Designates the interface as a bridge. Beginning with Shorewall 4.4.7,
# setting this option also sets routeback.
#
# Note
#
# If you have a bridge that you don't intend to define bport zones on,
# then it is best to omit this option and simply specify routeback.
#
# dbl={none|src|dst|src-dst}
#
# Added in Shorewall 5.0.10. This option defined whether or not dynamic
# blacklisting is applied to packets entering the firewall through this
# interface and whether the source address and/or destination address is
# to be compared against the ipset-based dynamic blacklist
# (DYNAMIC_BLACKLIST=ipset... in shorewall.conf(5)). The default is
# determine by the setting of DYNAMIC_BLACKLIST:
#
# DYNAMIC_BLACKLIST=No
#
# Default is none (e.g., no dynamic blacklist checking).
#
# DYNAMIC_BLACKLIST=Yes
#
# Default is src (e.g., the source IP address is checked).
#
# DYNAMIC_BLACKLIST=ipset[-only]
#
# Default is src.
#
# DYNAMIC_BLACKLIST=ipset[-only],src-dst...
#
# Default is src-dst (e.g., the source IP addresses in checked
# against the ipset on input and the destination IP address is
# checked against the ipset on packets originating from the firewall
# and leaving through this interface).
#
# The normal setting for this option will be dst or none for internal
# interfaces and src or src-dst for Internet-facing interfaces.
#
# destonly
#
# Added in Shorewall 4.5.17. Causes the compiler to omit rules to handle
# traffic from this interface.
#
# dhcp
#
# Specify this option when any of the following are true:
#
# 1. the interface gets its IP address via DHCP
#
# 2. the interface is used by a DHCP server running on the firewall
#
# 3. the interface has a static IP but is on a LAN segment with lots of
# DHCP clients.
#
# 4. the interface is a simple bridge with a DHCP server on one port and
# DHCP clients on another port.
#
# Note
#
# If you use Shorewall-perl for firewall/bridging, then you need to
# include DHCP-specific rules in shorewall-rules(5). DHCP uses UDP
# ports 67 and 68.
#
# This option allows DHCP datagrams to enter and leave the interface.
#
# forward[={0|1}]
#
# IPv6 only Sets the /proc/sys/net/ipv6/conf/interface/forwarding option
# to the specified value. If no value is supplied, then 1 is assumed.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# ignore[=1]
#
# When specified, causes the generated script to ignore up/down events
# from Shorewall-init for this device. Additionally, the option exempts
# the interface from hairpin filtering. When '=1' is omitted, the ZONE
# column must contain '-' and ignore must be the only OPTION.
#
# Beginning with Shorewall 4.5.5, may be specified as 'ignore=1' which
# only causes the generated script to ignore up/down events from
# Shorewall-init; hairpin filtering is still applied. In this case, the
# above restrictions on the ZONE and OPTIONS columns are lifted.
#
# loopback
#
# Added in Shorewall 4.6.6. Designates the interface as the loopback
# interface. This option is assumed if the interface's physical name is
# 'lo'. Only one interface man have the loopback option specified.
#
# logmartians[={0|1}]
#
# IPv4 only. Turn on kernel martian logging (logging of packets with
# impossible source addresses. It is strongly suggested that if you set
# routefilter on an interface that you also set logmartians. Even if you
# do not specify the routefilter option, it is a good idea to specify
# logmartians because your distribution may have enabled route filtering
# without you knowing it.
#
# Only those interfaces with the logmartians option will have their
# setting changed; the value assigned to the setting will be the value
# specified (if any) or 1 if no value is given.
#
# To find out if route filtering is set on a given interface, check the
# contents of /proc/sys/net/ipv4/conf/interface/rp_filter - a non-zero
# value indicates that route filtering is enabled.
#
# Example:
#
# teastep@lists:~$ cat /proc/sys/net/ipv4/conf/eth0/rp_filter
# 1
# teastep@lists:~$
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# This option may also be enabled globally in the shorewall.conf(5)
# file.
#
# maclist
#
# Connection requests from this interface are compared against the
# contents of shorewall-maclist(5). If this option is specified, the
# interface must be an Ethernet NIC and must be up before Shorewall is
# started.
#
# mss=number
#
# Added in Shorewall 4.0.3. Causes forwarded TCP SYN packets entering or
# leaving on this interface to have their MSS field set to the specified
# number.
#
# nets=(net[,...])
#
# Limit the zone named in the ZONE column to only the listed networks.
# The parentheses may be omitted if only a single net is given (e.g.,
# nets=192.168.1.0/24). Limited broadcast to the zone is supported.
# Beginning with Shorewall 4.4.1, multicast traffic to the zone is also
# supported.
#
# nets=dynamic
#
# Defines the zone as dynamic. Requires ipset match support in your
# iptables and kernel. See http://www.shorewall.net/Dynamic.html for
# further information.
#
# nodbl
#
# Added in Shorewall 5.0.8. When specified, dynamic blacklisting is
# disabled on the interface. Beginning with Shorewall 5.0.10, nodbl is
# equivalent to dbl=none.
#
# nosmurfs
#
# IPv4 only. Filter packets for smurfs (packets with a broadcast address
# as the source).
#
# Smurfs will be optionally logged based on the setting of
# SMURF_LOG_LEVEL in shorewall.conf(5). After logging, the packets are
# dropped.
#
# optional
#
# When optional is specified for an interface, Shorewall will be silent
# when:
#
# ☆ a /proc/sys/net/ipv[46]/conf/ entry for the interface cannot be
# modified (including for proxy ARP or proxy NDP).
#
# ☆ The first address of the interface cannot be obtained.
#
# May not be specified with required.
#
# physical=name
#
# Added in Shorewall 4.4.4. When specified, the interface or port name in
# the INTERFACE column is a logical name that refers to the name given in
# this option. It is useful when you want to specify the same wildcard
# port name on two or more bridges. See http://www.shorewall.net/
# bridge-Shorewall-perl.html#Multiple.
#
# If the interface name is a wildcard name (ends with '+'), then the
# physical name must also end in '+'. The physical name may end in '+'
# (or be exactly '+') when the interface name is not a wildcard name.
#
# If physical is not specified, then it's value defaults to the interface
# name.
#
# proxyarp[={0|1}]
#
# IPv4 only. Sets /proc/sys/net/ipv4/conf/interface/proxy_arp. Do NOT use
# this option if you are employing Proxy ARP through entries in
# shorewall-proxyarp(5). This option is intended solely for use with
# Proxy ARP sub-networking as described at: http://tldp.org/HOWTO/
# Proxy-ARP-Subnet/index.html.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# Only those interfaces with the proxyarp option will have their setting
# changed; the value assigned to the setting will be the value specified
# (if any) or 1 if no value is given.
#
# proxyndp[={0|1}]
#
# IPv6 only. Sets /proc/sys/net/ipv6/conf/interface/proxy_ndp.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# Only those interfaces with the proxyndp option will have their setting
# changed; the value assigned to the setting will be the value specified
# (if any) or 1 if no value is given.
#
# required
#
# Added in Shorewall 4.4.10. If this option is set, the firewall will
# fail to start if the interface is not usable. May not be specified
# together with optional.
#
# routeback[={0|1}]
#
# If specified, indicates that Shorewall should include rules that allow
# traffic arriving on this interface to be routed back out that same
# interface. This option is also required when you have used a wildcard
# in the INTERFACE column if you want to allow traffic between the
# interfaces that match the wildcard.
#
# Beginning with Shorewall 4.4.20, if you specify this option, then you
# should also specify either sfilter (see below) or routefilter on all
# interfaces (see below).
#
# Beginning with Shorewall 4.5.18, you may specify this option to
# explicitly reset (e.g., routeback=0). This can be used to override
# Shorewall's default setting for bridge devices which is routeback=1.
#
# routefilter[={0|1|2}]
#
# IPv4 only. Turn on kernel route filtering for this interface
# (anti-spoofing measure).
#
# Only those interfaces with the routefilter option will have their
# setting changes; the value assigned to the setting will be the value
# specified (if any) or 1 if no value is given.
#
# The value 2 is only available with Shorewall 4.4.5.1 and later when the
# kernel version is 2.6.31 or later. It specifies a loose form of reverse
# path filtering.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# This option can also be enabled globally via the ROUTE_FILTER option in
# the shorewall.conf(5) file.
#
# Important
#
# If ROUTE_FILTER=Yes in shorewall.conf(5), or if your distribution sets
# net.ipv4.conf.all.rp_filter=1 in /etc/sysctl.conf, then setting
# routefilter=0 in an interface entry will not disable route filtering on
# that interface! The effective setting for an interface is the maximum
# of the contents of /proc/sys/net/ipv4/conf/all/rp_filter and the
# routefilter setting specified in this file (/proc/sys/net/ipv4/conf/
# interface/rp_filter).
#
# Note
#
# There are certain cases where routefilter cannot be used on an
# interface:
#
# ☆ If USE_DEFAULT_RT=Yes in shorewall.conf(5) and the interface is
# listed in shorewall-providers(5).
#
# ☆ If there is an entry for the interface in shorewall-providers(5)
# that doesn't specify the balance option.
#
# ☆ If IPSEC is used to allow a road-warrior to have a local address,
# then any interface through which the road-warrior might connect
# cannot specify routefilter.
#
# Beginning with Shorewall 5.1.1, when routefilter is set to a non-zero
# value, the logmartians option is also implicitly set. If you actually
# want route filtering without logging, then you must also specify
# logmartians=0 after routefilter.
#
# rpfilter
#
# Added in Shorewall 4.5.7. This is an anti-spoofing measure that
# requires the 'RPFilter Match' capability in your iptables and kernel.
# It provides a more efficient alternative to the sfilter option below.
# It performs a function similar to routefilter (see above) but works
# with Multi-ISP configurations that do not use balanced routes.
#
# sfilter=(net[,...])
#
# Added in Shorewall 4.4.20. This option provides an anti-spoofing
# alternative to routefilter on interfaces where that option cannot be
# used, but where the routeback option is required (on a bridge, for
# example). On these interfaces, sfilter should list those local networks
# that are connected to the firewall through other interfaces.
#
# sourceroute[={0|1}]
#
# If this option is not specified for an interface, then source-routed
# packets will not be accepted from that interface unless it has been
# explicitly enabled via sysconf. Only set this option to 1 (enable
# source routing) if you know what you are doing. This might represent a
# security risk and is usually unneeded.
#
# Only those interfaces with the sourceroute option will have their
# setting changed; the value assigned to the setting will be the value
# specified (if any) or 1 if no value is given.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# tcpflags[={0|1}]
#
# Packets arriving on this interface are checked for certain illegal
# combinations of TCP flags. Packets found to have such a combination of
# flags are handled according to the setting of TCP_FLAGS_DISPOSITION
# after having been logged according to the setting of
# TCP_FLAGS_LOG_LEVEL.
#
# Beginning with Shorewall 4.6.0, tcpflags=1 is the default. To disable
# this option, specify tcpflags=0.
#
# unmanaged
#
# Added in Shorewall 4.5.18. Causes all traffic between the firewall and
# hosts on the interface to be accepted. When this option is given:
#
# ☆ The ZONE column must contain '-'.
#
# ☆ Only the following other options are allowed with unmanaged:
#
# arp_filter
# arp_ignore
# ignore
# routefilter
# optional
# physical
# routefilter
# proxyarp
# proxyudp
# sourceroute
#
# upnp
#
# Incoming requests from this interface may be remapped via UPNP (upnpd).
# See http://www.shorewall.net/UPnP.html. Supported in IPv4 and in IPv6
# in Shorewall 5.1.4 and later.
#
# upnpclient
#
# This option is intended for laptop users who always run Shorewall on
# their system yet need to run UPnP-enabled client apps such as
# Transmission (BitTorrent client). The option causes Shorewall to detect
# the default gateway through the interface and to accept UDP packets
# from that gateway. Note that, like all aspects of UPnP, this is a
# security hole so use this option at your own risk. Supported in IPv4
# and in IPv6 in Shorewall 5.1.4 and later.
#
# wait=seconds
#
# Added in Shorewall 4.4.10. Causes the generated script to wait up to
# seconds seconds for the interface to become usable before applying the
# required or optional options.
#
# Example
#
# IPv4 Example 1:
#
# Suppose you have eth0 connected to a DSL modem and eth1 connected to your
# local network and that your local subnet is 192.168.1.0/24. The interface
# gets its IP address via DHCP from subnet 206.191.149.192/27. You have a DMZ
# with subnet 192.168.2.0/24 using eth2. Your iptables and/or kernel do not
# support "Address Type Match" and you prefer to specify broadcast addresses
# explicitly rather than having Shorewall detect them.
#
# Your entries for this setup would look like:
#
# ?FORMAT 1
# #ZONE INTERFACE BROADCAST OPTIONS
# net eth0 206.191.149.223 dhcp
# loc eth1 192.168.1.255
# dmz eth2 192.168.2.255
#
# Example 2:
#
# The same configuration without specifying broadcast addresses is:
#
# ?FORMAT 2
# #ZONE INTERFACE OPTIONS
# net eth0 dhcp
# loc eth1
# dmz eth2
#
# Example 3:
#
# You have a simple dial-in system with no Ethernet connections.
#
# ?FORMAT 2
# #ZONE INTERFACE OPTIONS
# net ppp0 -
#
# Example 4 (Shorewall 4.4.9 and later):
#
# You have a bridge with no IP address and you want to allow traffic through
# the bridge.
#
# ?FORMAT 2
# #ZONE INTERFACE OPTIONS
# - br0 bridge
#
###############################################################################
?FORMAT 2
###############################################################################
#ZONE INTERFACE OPTIONS
net NET_IF tcpflags,forward=1,sourceroute=0,physical=eth0
loc LOC_IF tcpflags,forward=1,physical=eth1
dmz DMZ_IF tcpflags,forward=1,physical=eth2
shorewall6-5.2.3.4/Samples6/three-interfaces/policy.annotated 0000664 0000000 0000000 00000025562 13531077661 022614 0 ustar root root #
# Shorewall6 Version 4 - Sample Policy File for three-interface configuration.
# Copyright (C) 2006-2014 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------
# For information about entries in this file, type "man shorewall6-policy"
###############################################################################
#
# This file defines the high-level policy for connections between zones defined
# in shorewall-zones(5).
#
# Important
#
# The order of entries in this file is important
#
# This file determines what to do with a new connection request if we don't get a
# match from the shorewall-blrules(5) or shorewall-rules(5) files. For each
# source/destination pair, the file is processed in order until a match is found
# ("all" will match any source or destination).
#
# Important
#
# Intra-zone policies are pre-defined
#
# For $FW and for all of the zones defined in shorewall-zones(5), the POLICY for
# connections from the zone to itself is ACCEPT (with no logging or TCP
# connection rate limiting) but may be overridden by an entry in this file. The
# overriding entry must be explicit (specifying the zone name in both SOURCE and
# DEST) or it must use "all+" (Shorewall 4.5.17 or later).
#
# Similarly, if you have IMPLICIT_CONTINUE=Yes in shorewall.conf(5), then the
# implicit policy to/from any sub-zone is CONTINUE. These implicit CONTINUE
# policies may also be overridden by an explicit entry in this file.
#
# The columns in the file are as follows (where the column name is followed by a
# different name in parentheses, the different name is used in the alternate
# specification syntax).
#
# SOURCE - zone[,...[+]]|$FW|all[+][!ezone[,...]]
#
# Source zone. Must be the name of a zone defined in shorewall-zones(5), $FW,
# "all" or "all+".
#
# Support for all+ was added in Shorewall 4.5.17. all does not override the
# implicit intra-zone ACCEPT policy while all+ does.
#
# Beginning with Shorewall 5.0.12, multiple zones may be listed separated by
# commas. As above, if '+' is specified after two or more zone names, then
# the policy overrides the implicit intra-zone ACCEPT policy if the same zone
# appears in both the SOURCE and DEST columns.
#
# Beginning with Shorewall 5.2.3, a comma-separated list of excluded zones
# preceded by "!" may follow all or all+.
#
# DEST - zone[,...[+]]|$FW|all[+][!ezone[,...]]
#
# Destination zone. Must be the name of a zone defined in shorewall-zones(5),
# $FW, "all" or "all+". If the DEST is a bport zone, then the SOURCE must be
# "all", "all+", another bport zone associated with the same bridge, or it
# must be an ipv4 zone that is associated with only the same bridge.
#
# Support for "all+" was added in Shorewall 4.5.17. "all" does not override
# the implicit intra-zone ACCEPT policy while "all+" does.
#
# Beginning with Shorewall 5.0.12, multiple zones may be listed separated by
# commas. As above, if '+' is specified after two or more zone names, then
# the policy overrides the implicit intra-zone ACCEPT policy if the same zone
# appears in both the SOURCE and DEST columns.
#
# Beginning with Shorewall 5.2.3, a comma-separated list of excluded zones
# preceded by "!" may follow all or all+.
#
# POLICY - {ACCEPT|DROP|REJECT|BLACKLIST|CONTINUE|QUEUE|NFQUEUE[(queuenumber1[:
# queuenumber2])]|NONE}[:{[+]policy-action[:level][,...]|None}]
#
# Policy if no match from the rules file is found.
#
# If the policy is neither CONTINUE nor NONE then the policy may be followed
# by ":" and one of the following:
#
# a. The word "None" or "none". This causes any default action defined in
# shorewall.conf(5) to be omitted for this policy.
#
# b. The name of an action with optional parameters enclosed in parentheses.
# The action will be invoked before the policy is enforced.
#
# Actions can have parameters specified.
#
# Beginning with Shorewall 4.5.10, the action name can be followed optionally
# by a colon and a log level. The level will be applied to each rule in the
# action or body that does not already have a log level.
#
# Beginning with Shorewall 5.1.2, multiple action[:level] specification may
# be listeded, separated by commas. The actions are invoked in the order
# listed. Also beginning with Shorewall 5.1.2, the policy-action list can be
# prefixed with a plus sign ("+") indicating that the listed actions are in
# addition to those listed in the related _DEFAULT setting in shorewall.conf
# (5).
#
# Possible policies are:
#
# ACCEPT
#
# Accept the connection.
#
# DROP
#
# Ignore the connection request.
#
# REJECT
#
# For TCP, send RST. For all other, send an "unreachable" ICMP.
#
# BLACKLIST
#
# Added in Shorewall 5.1.1 and requires that the DYNAMIC_BLACKLIST
# setting in shorewall.conf(5) specifies ipset-based dynamic
# blacklisting. The SOURCE IP address is added to the blacklist ipset and
# the connection request is ignored.
#
# QUEUE
#
# Queue the request for a user-space application such as Snort-inline.
#
# NFQUEUE
#
# Queue the request for a user-space application using the
# nfnetlink_queue mechanism. If a queuenumber1 is not given, queue zero
# (0) is assumed. Beginning with Shorewall 4.6.10, a second queue number
# (queuenumber2) may be given. This specifies a range of queues to use.
# Packets are then balanced across the given queues. This is useful for
# multicore systems: start multiple instances of the userspace program on
# queues x, x+1, .. x+n and use "x:x+n". Packets belonging to the same
# connection are put into the same nfqueue.
#
# CONTINUE
#
# Pass the connection request past any other rules that it might also
# match (where the source or destination zone in those rules is a
# superset of the SOURCE or DEST in this policy). See shorewall-nesting
# (5) for additional information.
#
# NONE
#
# Assume that there will never be any packets from this SOURCE to this
# DEST. Shorewall will not create any infrastructure to handle such
# packets and you may not have any rules with this SOURCE and DEST in the
# /etc/shorewall/rules file. If such a packet is received, the result is
# undefined. NONE may not be used if the SOURCE or DEST columns contain
# the firewall zone ($FW) or "all".
#
# LOGLEVEL (loglevel) - [log-level|ULOG|NFLOG]
#
# Optional - if supplied, each connection handled under the default POLICY is
# logged at that level. If not supplied, no log message is generated. See
# syslog.conf(5) for a description of log levels.
#
# You may also specify ULOG or NFLOG (must be in upper case). This will log
# to the ULOG or NFLOG target and will send to a separate log through use of
# ulogd (http://www.netfilter.org/projects/ulogd/index.html).
#
# For a description of logging, see shorewall-logging(5).
#
# If you don't want to log but need to specify the following column, place
# "-" here.
#
# RATE (rate) - [-|limit]
#
# where limit is one of:
#
# [-|[{s|d}[/vlsm]:[[name][(ht-buckets,ht-max)]:]]]rate/{sec|min|hour|day}[:
# burst]
# [name1:]rate1/{sec|min|hour|day}[:burst1],[name2:]rate2/{sec|min|hour|day}
# [:burst2]
#
# If passed, specifies the maximum TCP connection rate and the size of an
# acceptable burst. If not specified, TCP connections are not limited. If the
# burst parameter is omitted, a value of 5 is assumed.
#
# When s: or d: is specified, the rate applies per source IP address or per
# destination IP address respectively. The name may be chosen by the user and
# specifies a hash table to be used to count matching connections. If not
# give, the name shorewall is assumed. Where more than one POLICY or rule
# specifies the same name, the connections counts for the policies are
# aggregated and the individual rates apply to the aggregated count.
# Beginning with Shorewall 5.2.1, the s or d may be followed by a slash ("/")
# and an integer vlsm. When a vlsm is specified, all source or destination
# addresses encountered will be grouped according to the given prefix length
# and the so-created subnet will be subject to the rate limit.
#
# Beginning with Shorewall 4.6.5, two limits may be specified, separated by a
# comma. In this case, the first limit (name1, rate1, burst1) specifies the
# per-source IP limit and the second limit specifies the per-destination IP
# limit.
#
# Example: client:10/sec:20,:60/sec:100
#
# Beginning with Shorewall 5.2.1, the table name, if any, may be followed by
# two integers separated by commas and enclosed in parentheses. The first
# integer (ht-buckets) specifies the number of buckets in the generated hash
# table. The second integer (ht-max) specifies the maximum number of entries
# in the hash table.
#
# Example: s:client(1024,65536):10/sec
#
# CONNLIMIT - limit[:mask]
#
# May be used to limit the number of simultaneous connections from each
# individual host to limit connections. While the limit is only checked on
# connections to which this policy could apply, the number of current
# connections is calculated over all current connections from the SOURCE
# host. By default, the limit is applied to each host individually but can be
# made to apply to networks of hosts by specifying a mask. The mask specifies
# the width of a VLSM mask to be applied to the source address; the number of
# current connections is then taken over all hosts in the subnet
# source-address/mask.
#
# Example
#
# a. All connections from the local network to the internet are allowed
#
# b. All connections from the internet are ignored but logged at syslog level
# KERNEL.INFO.
#
# c. All other connection requests are rejected and logged at level KERNEL.INFO.
#
# #SOURCE DEST POLICY LOG BURST:LIMIT
# # LEVEL
# loc net ACCEPT
# net all DROP info
# #
# # THE FOLLOWING POLICY MUST BE LAST
# #
# all all REJECT info
#
###############################################################################
#SOURCE DEST POLICY LOGLEVEL RATE CONNLIMIT
loc net ACCEPT
net all DROP $LOG_LEVEL
all all REJECT $LOG_LEVEL
shorewall6-5.2.3.4/Samples6/three-interfaces/README.txt 0000664 0000000 0000000 00000002162 13531060406 021070 0 ustar root root For instructions on using these sample configurations, please see
http://www.shorewall.net/three-interface.htm
Shorewall Samples
Copyright (C) 2006-2014 by the following authors:
Thomas M. Eastep
Paul D. Gear
Cristian Rodriguez
Francesca Smith
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
02110-1301 USA
Sample files are licensed under the LGPL, please see the LICENSE file or
http://www.gnu.org/licenses/lgpl.html for more details.
shorewall6-5.2.3.4/Samples6/three-interfaces/rules.annotated 0000664 0000000 0000000 00000165576 13531077662 022462 0 ustar root root #
# Shorewall6 version 5.2 - Sample Rules File for three-interface configuration.
# Copyright (C) 2006-2014 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------------------------------------
# For information about entries in this file, type "man shorewall6-rules"
######################################################################################################################################################################################################
#
# Entries in this file govern connection establishment by defining exceptions to
# the policies laid out in shorewall-policy(5). By default, subsequent requests
# and responses are automatically allowed using connection tracking. For any
# particular (source,dest) pair of zones, the rules are evaluated in the order in
# which they appear in this file and the first terminating match is the one that
# determines the disposition of the request. All rules are terminating except LOG
# and COUNT rules.
#
# Warning
#
# If you masquerade or use SNAT from a local system to the internet, you cannot
# use an ACCEPT rule to allow traffic from the internet to that system. You must
# use a DNAT rule instead.
#
# The rules file is divided into sections. Each section is introduced by a
# "Section Header" which is a line beginning with ?SECTION and followed by the
# section name.
#
# Sections are as follows and must appear in the order listed:
#
# ALL
#
# This section was added in Shorewall 4.4.23. Rules in this section are
# applied, regardless of the connection tracking state of the packet and are
# applied before rules in the other sections.
#
# ESTABLISHED
#
# Packets in the ESTABLISHED state are processed by rules in this section.
#
# The only ACTIONs allowed in this section are ACCEPT, DROP, REJECT, LOG,
# NFLOG, NFQUEUE and QUEUE
#
# There is an implicit ACCEPT rule inserted at the end of this section.
#
# RELATED
#
# Packets in the RELATED state are processed by rules in this section.
#
# The only ACTIONs allowed in this section are ACCEPT, DROP, REJECT, LOG,
# NFLOG, NFQUEUE and QUEUE
#
# There is an implicit rule added at the end of this section that invokes the
# RELATED_DISPOSITION (shorewall.conf(5)).
#
# INVALID
#
# Added in Shorewall 4.5.13. Packets in the INVALID state are processed by
# rules in this section.
#
# The only Actions allowed in this section are ACCEPT, DROP, REJECT, LOG,
# NFLOG, NFQUEUE and QUEUE.
#
# There is an implicit rule added at the end of this section that invokes the
# INVALID_DISPOSITION (shorewall.conf(5)).
#
# UNTRACKED
#
# Added in Shorewall 4.5.13. Packets in the UNTRACKED state are processed by
# rules in this section.
#
# The only Actions allowed in this section are ACCEPT, DROP, REJECT, LOG,
# NFLOG, NFQUEUE and QUEUE.
#
# There is an implicit rule added at the end of this section that invokes the
# UNTRACKED_DISPOSITION (shorewall.conf(5)).
#
# NEW
#
# Packets in the NEW state are processed by rules in this section. If the
# INVALID and/or UNTRACKED sections are empty or not included, then the
# packets in the corresponding state(s) are also processed in this section.
#
# Note
#
# If you are not familiar with Netfilter to the point where you are comfortable
# with the differences between the various connection tracking states, then it is
# suggested that you place all of your rules in the NEW section (That's after the
# line that reads ?SECTION NEW').
#
# Warning
#
# If you specify FASTACCEPT=Yes in shorewall.conf(5) then the ALL, ESTABLISHED
# and RELATED sections must be empty.
#
# An exception is made if you are running Shorewall 4.4.27 or later and you have
# specified a non-default value for RELATED_DISPOSITION or RELATED_LOG_LEVEL. In
# that case, you may have rules in the RELATED section of this file.
#
# You may omit any section that you don't need. If no Section Headers appear in
# the file then all rules are assumed to be in the NEW section.
#
# When defining rules that rewrite the destination IP address and/or port number
# (namely DNAT and REDIRECT rules), it is important to keep straight which
# columns in the file specify the packet before rewriting and which specify how
# the packet will look after rewriting.
#
# • The DEST column specifies the final destination for the packet after
# rewriting and can include the final IP address and/or port number.
#
# • The remaining columns specify characteristics of the packet before
# rewriting. In particular, the ORIGDEST column gives the original
# destination IP address of the packet and the DPORT column give the original
# destination port(s).
#
# The columns in the file are as follows (where the column name is followed by a
# different name in parentheses, the different name is used in the alternate
# specification syntax).
#
# ACTION - target[:{log-level|none}[!][:tag]]
#
# Specifies the action to be taken if the connection request matches the
# rule. target must be one of the following.
#
# ACCEPT
#
# Allow the connection request.
#
# ACCEPT+
#
# like ACCEPT but also excludes the connection from any subsequent
# matching DNAT[-] or REDIRECT[-] rules. Use with IPv6 requires Shorewall
# 4.5.14 or later.
#
# ACCEPT!
#
# like ACCEPT but exempts the rule from being suppressed by OPTIMIZE=1 in
# shorewall.conf(5).
#
# action
#
# The name of an action declared in shorewall-actions(5) or in /usr/share
# /shorewall[6]/actions.std.
#
# ADD(ipset:flags[:timeout])
#
# Added in Shorewall 4.4.12. Causes addresses and/or port numbers to be
# added to the named ipset. The flags specify the address or tuple to be
# added to the set and must match the type of ipset involved. For
# example, for an iphash ipset, either the SOURCE or DESTINATION address
# can be added using flags src or dst respectively (see the -A command in
# ipset (8)).
#
# Beginning with Shorewall 5.0.3, an optional timeout can be specified.
# This is the number of seconds that the new entry in the ipset is to
# remain valid and overrides any timeout specified when the ipset was
# created.
#
# ADD is non-terminating. Even if a packet matches the rule, it is passed
# on to the next rule.
#
# AUDIT[(accept|drop|reject)]
#
# Added in Shorewall 4.5.10. Audits the packet with the specified type;
# if the type is omitted, then drop is assumed. Require AUDIT_TARGET
# support in the kernel and iptables.
#
# A_ACCEPT, A_ACCEPT+ and A_ACCEPT!
#
# Added in Shorewall 4.4.20. Audited versions of ACCEPT, ACCEPT+ and
# ACCEPT! respectively. Require AUDIT_TARGET support in the kernel and
# iptables. A_ACCEPT+ with IPv6 requires Shorewall 4.5.14 or later.
#
# A_DROP and A_DROP!
#
# Added in Shorewall 4.4.20. Audited versions of DROP and DROP!
# respectively. Require AUDIT_TARGET support in the kernel and iptables.
#
# A_REJECT AND A_REJECT!
#
# Added in Shorewall 4.4.20. Audited versions of REJECT and REJECT!
# respectively. Require AUDIT_TARGET support in the kernel and iptables.
#
# ?COMMENT
#
# the rest of the line will be attached as a comment to the Netfilter
# rule(s) generated by the following entries. The comment will appear
# delimited by "/* ... */" in the output of "shorewall show ". To
# stop the comment from being attached to further rules, simply include ?
# COMMENT on a line by itself.
#
# CONMARK({mark})
#
# Added in Shorewall 5.0.7, CONNMARK is identical to MARK with the
# exception that the mark is assigned to connection to which the packet
# belongs is marked rather than to the packet itself.
#
# CONTINUE
#
# For experts only.
#
# Do not process any of the following rules for this (source
# zone,destination zone). If the source and/or destination IP address
# falls into a zone defined later in shorewall-zones(5) or in a parent
# zone of the source or destination zones, then this connection request
# will be passed to the rules defined for that (those) zone(s). See
# shorewall-nesting(5) for additional information.
#
# CONTINUE!
#
# like CONTINUE but exempts the rule from being suppressed by OPTIMIZE=1
# in shorewall.conf(5).
#
# COUNT
#
# Simply increment the rule's packet and byte count and pass the packet
# to the next rule.
#
# DEL(ipset:flags)
#
# Added in Shorewall 4.4.12. Causes an entry to be deleted from the named
# ipset. The flags specify the address or tuple to be deleted from the
# set and must match the type of ipset involved. For example, for an
# iphash ipset, either the SOURCE or DESTINATION address can be deleted
# using flags src or dst respectively (see the -D command in ipset (8)).
#
# DEL is non-terminating. Even if a packet matches the rule, it is passed
# on to the next rule.
#
# DNAT
#
# Forward the request to another system (and optionally another port).
# Use with IPv6 requires Shorewall 4.5.14 or later.
#
# DNAT-
#
# Advanced users only.
#
# Like DNAT but only generates the DNAT iptables rule and not the
# companion ACCEPT rule. Use with IPv6 requires Shorewall 4.5.14 or
# later.
#
# DROP
#
# Ignore the request.
#
# DROP!
#
# like DROP but exempts the rule from being suppressed by OPTIMIZE=1 in
# shorewall.conf(5).
#
# HELPER
#
# Added in Shorewall 4.5.7. This action requires that the HELPER column
# contains the name of the Netfilter helper to be associated with
# connections matching this connection. May only be specified in the NEW
# section and is useful for being able to specify a helper when the
# applicable policy is ACCEPT. No destination zone should be specified in
# HELPER rules.
#
# INLINE[(action)]
#
# Added in Shorewall 4.5.16. This action allows you to construct most of
# the rule yourself using iptables syntax. The part that you specify must
# follow two semicolons (';;') and is completely free-form. If the target
# of the rule (the part following 'j') is something that Shorewall
# supports in the ACTION column, then you may enclose it in parentheses
# (e.g., INLINE(ACCEPT)). Otherwise, you can include it after the
# semicolon(s). In this case, you must declare the target as a builtin
# action in shorewall-actions(5).
#
# Some considerations when using INLINE:
#
# ☆ The p, s, d, i, o, policy, and state match (state or conntrack
# --ctstate) matches will always appear in the front of the rule in
# that order.
#
# ☆ When multiple matches are specified, the compiler will keep them in
# the order in which they appear (excluding the above listed ones),
# but they will not necessarily be at the end of the generated rule.
# For example, if addresses are specified in the SOURCE and/or DEST
# columns, their generated matches will appear after those specified
# using ';;' or ';'.
#
# IPTABLES({iptables-target [option ...])
#
# IPv4 only. This action allows you to specify an iptables target with
# options (e.g., 'IPTABLES(MARK --set-xmark 0x01/0xff)'. If the
# iptables-target is not one recognized by Shorewall, the following error
# message will be issued:
#
# ERROR: Unknown target (iptables-target)
#
# This error message may be eliminated by adding the iptables-target as a
# builtin action in shorewall-actions(5).
#
# Important
#
# If you specify REJECT as the iptables-target, the target of the rule
# will be the iptables REJECT target and not Shorewall's builtin 'reject'
# chain which is used when REJECT (see below) is specified as the target
# in the ACTION column.
#
# IP6TABLES({ip6tables-target [option ...])
#
# IPv6 only. This action allows you to specify an ip6tables target with
# options (e.g., 'IPTABLES(MARK --set-xmark 0x01/0xff)'. If the
# ip6tables-target is not one recognized by Shorewall, the following
# error message will be issued:
#
# ERROR: Unknown target (ip6tables-target)
#
# This error message may be eliminated by adding the ip6tables-target as
# a builtin action in shorewall-actions(5).
#
# Important
#
# If you specify REJECT as the ip6tables-target, the target of the rule
# will be the i6ptables REJECT target and not Shorewall's builtin
# 'reject' chain which is used when REJECT (see below) is specified as
# the target in the ACTION column.
#
# LOG:level
#
# Simply log the packet and continue with the next rule.
#
# macro[(macrotarget)]
#
# The name of a macro defined in a file named macro.macro. If the macro
# accepts an action parameter (Look at the macro source to see if it has
# PARAM in the TARGET column) then the macro name is followed by the
# parenthesized macrotarget (ACCEPT, DROP, REJECT, ...) to be substituted
# for the parameter.
#
# Example: FTP(ACCEPT).
#
# The older syntax where the macro name and the target are separated by a
# slash (e.g. FTP/ACCEPT) is still allowed but is deprecated.
#
# MARK({mark})
#
# where mark is a packet mark value.
#
# Added in Shorewall 5.0.7, MARK requires "Mark in filter table" support
# in your kernel and iptables.
#
# Normally will set the mark value of the current packet. If preceded by
# a vertical bar ("|"), the mark value will be logically ORed with the
# current mark value to produce a new mark value. If preceded by an
# ampersand ("&"), will be logically ANDed with the current mark value to
# produce a new mark value.
#
# Both "|" and "&" require Extended MARK Target support in your kernel
# and iptables.
#
# The mark value may be optionally followed by "/" and a mask value (used
# to determine those bits of the connection mark to actually be set).
# When a mask is specified, the result of logically ANDing the mark value
# with the mask must be the same as the mark value.
#
# NFLOG[(nflog-parameters)]
#
# Added in Shorewall 4.5.9.3. Queues matching packets to a back end
# logging daemon via a netlink socket then continues to the next rule.
# See http://www.shorewall.net/shorewall_logging.html.
#
# The nflog-parameters are a comma-separated list of up to 3 numbers:
#
# ☆ The first number specifies the netlink group (0-65535). If omitted
# (e.g., NFLOG(,0,10)) then a value of 0 is assumed.
#
# ☆ The second number specifies the maximum number of bytes to copy. If
# omitted, 0 (no limit) is assumed.
#
# ☆ The third number specifies the number of log messages that should
# be buffered in the kernel before they are sent to user space. The
# default is 1.
#
# NFLOG is similar to LOG:NFLOG[(nflog-parameters)], except that the log
# level is not changed when this ACTION is used in an action or macro
# body and the invocation of that action or macro specifies a log level.
#
# NFQUEUE[([queuenumber1[:queuenumber2[c]][,bypass]]|bypass)]
#
# Queues the packet to a user-space application using the nfnetlink_queue
# mechanism. If a queuenumber1 is not specified, queue zero (0) is
# assumed. Beginning with Shorewall 4.6.10, the keyword bypass can be
# given. By default, if no userspace program is listening on an NFQUEUE,
# then all packets that are to be queued are dropped. When this option is
# used, the NFQUEUE rule behaves like ACCEPT instead. Also beginning in
# Shorewall 4.6.10, a second queue number (queuenumber2) may be
# specified. This specifies a range of queues to use. Packets are then
# balanced across the given queues. This is useful for multicore systems:
# start multiple instances of the userspace program on queues x, x+1, ..
# x+n and use "x:x+n". Packets belonging to the same connection are put
# into the same nfqueue.
#
# Beginning with Shorewall 5.1.0, queuenumber2 may be followed by the
# letter 'c' to indicate that the CPU ID will be used as an index to map
# packets to the queues. The idea is that you can improve performance if
# there's a queue per CPU. Requires the NFQUEUE CPU Fanout capability in
# your kernel and iptables.
#
# NFQUEUE![([queuenumber1[:queuenumber2[c]][,bypass]]|bypass)]
#
# like NFQUEUE but exempts the rule from being suppressed by OPTIMIZE=1
# in shorewall.conf(5).
#
# NONAT
#
# Excludes the connection from any subsequent DNAT[-] or REDIRECT[-]
# rules but doesn't generate a rule to accept the traffic. Use with IPv6
# requires Shorewall 4.5.14 or later.
#
# QUEUE
#
# Queue the packet to a user-space application such as ftwall (http://
# p2pwall.sf.net). The application may reinsert the packet for further
# processing.
#
# QUEUE!
#
# like QUEUE but exempts the rule from being suppressed by OPTIMIZE=1 in
# shorewall.conf(5).
#
# REJECT[(option)]
#
# disallow the request and return an icmp-unreachable or an RST packet.
# If no option is passed, Shorewall selects the appropriate option based
# on the protocol of the packet.
#
# Beginning with Shorewall 5.0.8, the type of reject may be specified in
# the option paramater. Valid IPv4 option values are:
#
# icmp-net-unreachable
# icmp-host-unreachable
# icmp-port-unreachable
# icmp-proto-unreachable
# icmp-net-prohibited
# icmp-host-prohibited
# icmp-admin-prohibited
# icmp-tcp-reset (the PROTO column must specify TCP). Beginning with
# Shorewall 5.1.3, this option may also be specified as tcp-reset.
#
# Valid IPv6 option values are:
#
# icmp6-no-route
# no-route
# icmp6-adm-prohibited
# adm-prohibited
# icmp6-addr-unreachable
# addr-unreach
# icmp6-port-unreachable
# tcp-reset (the PROTO column must specify TCP)
#
# REJECT!
#
# like REJECT but exempts the rule from being suppressed by OPTIMIZE=1 in
# shorewall.conf(5).
#
# REDIRECT
#
# Redirect the request to a server running on the firewall. Use with IPv6
# requires Shorewall 4.5.14 or later.
#
# REDIRECT-
#
# Advanced users only.
#
# Like REDIRECT but only generates the REDIRECT iptables rule and not the
# companion ACCEPT rule. Use with IPv6 requires Shorewall 4.5.14 or
# later.
#
# TARPIT [(tarpit | honeypot | reset)]
#
# Added in Shorewall 4.6.6.
#
# TARPIT captures and holds incoming TCP connections using no local
# per-connection resources.
#
# TARPIT only works with the PROTO column set to tcp (6), and is totally
# application agnostic. This module will answer a TCP request and play
# along like a listening server, but aside from sending an ACK or RST, no
# data is sent. Incoming packets are ignored and dropped. The attacker
# will terminate the session eventually. This module allows the initial
# packets of an attack to be captured by other software for inspection.
# In most cases this is sufficient to determine the nature of the attack.
#
# This offers similar functionality to LaBrea " was specified
# in the command (e.g., shorewall [-6] check ./gateway) then the
# directory given in the command is searched first.
#
# □ Next, each directory in the CONFIG_PATH setting is searched in
# sequence.
#
# If CONFIG_PATH is not given or if it is set to the empty value then the
# contents of /usr/share/shorewall/configpath are used. As released from
# shorewall.net, that file sets the CONFIG_PATH to /etc/shorewall:/usr/share/
# shorewall but your particular distribution may set it differently. See the
# output of shorewall show config for the default on your system.
#
# Beginning with Shorewall 5.1.10, the CONFIG_PATH setting may begin with a
# colon (":"), to signal that the first directory listed will be skipped if
# the user performing a compilation is not root or if the configuration is
# being compiled for export (-e option specified or if running one of the
# remote-* commands) . This prevents the compiler from looking in /etc/
# shorewall[6]/ when compilation is being done by a non-root user or if the
# generated script is to be sent to a remote firewall system.
#
GEOIPDIR=/usr/share/xt_geoip/LE
#
# GEOIPDIR=[pathname]
#
# Added in Shorewall 4.5.4. Specifies the pathname of the directory
# containing the GeoIP Match database. See http://www.shorewall.net/
# ISO-3661.html. If not specified, the default value is /usr/share/xt_geoip/
# LE which is the default location of the little-endian database.
#
IP6TABLES=
#
# IP6TABLES=[pathname]
#
# IPv6 only.
#
# This parameter names the ip6tables executable to be used by Shorewall6. If
# not specified or if specified as a null value, then the ip6tables
# executable located using the PATH option is used.
#
# Regardless of how the ip6tables utility is located (specified via IP6TABLES
# = or located via PATH), Shorewall6 uses the ip6tables-restore and
# ip6tables-save utilities from that same directory.
#
IP=
#
# IP=[pathname]
#
# If specified, gives the pathname of the 'ip' executable. If not specified,
# 'ip' is assumed and the utility will be located using the current PATH
# setting.
#
IPSET=
#
# IPSET=[pathname]
#
# If specified, gives the pathname of the 'ipset' executable. If not
# specified, 'ipset' is assumed and the utility will be located using the
# current PATH setting.
#
LOCKFILE=
#
# LOCKFILE=[pathname]
#
# Specifies the name of the Shorewall[6] lock file, used to prevent
# simultaneous state-changing commands. If not specified, ${VARDIR}/shorewall
# [6]/lock is assumed (${VARDIR} is normally /var/lib but can be changed when
# Shorewall-core is installed -- see the output of shorewall show vardir).
#
MODULESDIR=
#
# MODULESDIR=[[+]pathname[:pathname]...]
#
# This parameter specifies the directory/directories where your kernel
# netfilter modules may be found. If you leave the variable empty, Shorewall
# will supply the value "/lib/modules/$uname/kernel/net/ipv${g_family}/
# netfilter:/lib/modules/$uname/kernel/net/netfilter:/lib/modules/$uname/
# kernel/net/sched:/lib/modules/$uname/extra:/lib/modules/$uname/extra/ipset"
# where uname holds the output of 'uname -r' and g_family holds '4' in IPv4
# configurations and '6' in IPv6 configurations.
#
# The option plus sign ('+') was added in Shorewall 5.0.3 and causes the
# listed pathnames to be appended to the default list above.
#
NFACCT=
#
# NFACCT=[pathname]
#
# Added in Shorewall 4.5.7. Specifies the pathname of the nfacct utility. If
# not specified, Shorewall will use the PATH setting to find the program.
#
PERL=/usr/bin/perl
#
# PERL=pathname
#
# Added in Shorewall 4.4.11 RC1. Specifies the path name of the Perl
# executable. Default is /usr/bin/perl. If the pathname specified by this
# option does not exist or the named file is not executable, then Shorewall
# falls back to /usr/bin/perl
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
#
# PATH=pathname[:pathname]...
#
# Determines the order in which Shorewall searches directories for executable
# files.
#
RESTOREFILE=restore
#
# RESTOREFILE=filename
#
# Specifies the simple name of a file in /var/lib/shorewall to be used as the
# default restore script in the shorewall [-6] save, shorewall [-6] restore,
# shorewall [-6] forget and shorewall [6] -f start commands.
#
SHOREWALL_SHELL=/bin/sh
#
# SHOREWALL_SHELL=[pathname]
#
# This option is used to specify the shell program to be used to interpret
# the compiled script. If not specified or specified as a null value, /bin/sh
# is assumed. Using a light-weight shell such as ash or dash can
# significantly improve performance.
#
SUBSYSLOCK=
#
# SUBSYSLOCK=[pathname]
#
# This parameter should be set to the name of a file that the firewall should
# create if it starts successfully and remove when it stops. Creating and
# removing this file allows Shorewall to work with your distribution's
# initscripts. For OpenSuSE, this should be set to /var/lock/subsys/shorewall
# (var/lock/subsys/shorewall-lite if building for export). For Gentoo, it
# should be set to /run/lock/shorewall (/run/lock/shorewall-lite). For Redhat
# and derivatives as well as Debian and derivatives, the pathname should be
# omitted.
#
# Important
#
# Beginning with Shorewall 5.1.0, this setting is ignored when SERVICEDIR is
# non-empty in ${SHAREDIR}/shorewall/shorewallrc (usually /usr/share/
# shorewall/shorewallrc).
#
TC=
#
# TC=[pathname]
#
# If specified, gives the pathname of the 'tc' executable. If not specified,
# 'tc' is assumed and the utility will be located using the current PATH
# setting.
#
###############################################################################
# D E F A U L T A C T I O N S / M A C R O S
###############################################################################
ACCEPT_DEFAULT="none"
#
# ACCEPT_DEFAULT={action[(parameters)][:level][,...]|none}
#
BLACKLIST_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP),dropNotSyn:$LOG_LEVEL,dropInvalid:$LOG_LEVEL,DropDNSrep:$LOG_LEVEL"
#
# BLACKLIST_DEFAULT={action[(parameters)][:level][,...]|none}
#
DROP_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)"
#
# DROP_DEFAULT={action[(parameters)][:level][,...]|none}
#
NFQUEUE_DEFAULT="none"
#
# NFQUEUE_DEFAULT={action[(parameters)][:level][,...]|none}
#
QUEUE_DEFAULT="none"
#
# QUEUE_DEFAULT={action[(parameters)][:level][,...]|none}
#
REJECT_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)"
#
# REJECT_DEFAULT={action[(parameters)][:level][,...]|none}
#
# In earlier Shorewall versions, a "default action" for DROP and REJECT
# policies was specified in the file /usr/share/shorewall/actions.std.
#
# In Shorewall 4.4.0, the DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT,
# QUEUE_DEFAULT and NFQUEUE_DEFAULT options were added.
#
# 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
# three are similar for ACCEPT, QUEUE and NFQUEUE policies.
#
# The value applied to these may be:
#
# a) The name of an action. The name may optionally be followed by a
# comma-separated list of parameters enclosed in parentheses if the specified
# action accepts parameters (e.g., 'Drop(audit)').
# c) None or none
#
# Prior to Shorewall 5.1.2, the default values are:
#
# DROP_DEFAULT="Drop"
# REJECT_DEFAULT="Reject"
# BLACKLIST_DEFAULT="Drop" (added in Shorewall 5.1.1)
# ACCEPT_DEFAULT="none"
# QUEUE_DEFAULT="none"
# NFQUEUE_DEFAULT="none"
#
# Beginning with Shorewall 5.1.2, the default value is 'none' for all of
# these. Note that the sample configuration files do, however, provide
# settings for DROP_DEFAULT, BLACKLIST_DEFAULT and REJECT_DEFAULT.
#
# 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
# shorewall-policy(5).
#
# You can pass parameters to the specified action (e.g., myaction(audit,DROP)
# ).
#
# Beginning with Shorewall 4.5.10, the action name can be followed optionally
# by a colon and a log level. The level will be applied to each rule in the
# action or body that does not already have a log level.
#
# Beginning with Shorewall 5.1.2, multiple action[(parameters)][:level]
# specifications may be listed, separated by commas.
#
###############################################################################
# R S H / R C P C O M M A N D S
###############################################################################
RCP_COMMAND='scp ${files} ${root}@${system}:${destination}'
#
# RCP_COMMAND="command"
#
RSH_COMMAND='ssh ${root}@${system} ${command}'
#
# RSH_COMMAND="command"
#
# Earlier generations of Shorewall Lite required that remote root login via
# ssh be enabled in order to use the load and reload commands. Beginning with
# release 3.9.5, you may define an alternative means for accessing the remote
# firewall system. In that release, two new options were added to
# shorewall.conf:
#
# RSH_COMMAND
# RCP_COMMAND
#
# The default values for these are as follows:
#
# RSH_COMMAND: ssh ${root}@${system} ${command}
# RCP_COMMAND: scp ${files} ${root}@${system}:${destination}
#
# Shell variables that will be set when the commands are invoked are as
# follows:
#
# root - root user. Normally root but may be overridden using the '-r' option.
# system - The name/IP address of the remote firewall system.
# command - For RSH_COMMAND, the command to be executed on the firewall system.
# files - For RCP_COMMAND, a space-separated list of files to be copied to the remote firewall system.
# destination - The directory on the remote system that the files are to be copied into.
#
###############################################################################
# F I R E W A L L O P T I O N S
###############################################################################
ACCOUNTING=Yes
#
# ACCOUNTING=[Yes|No]
#
# Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting is enabled
# (see shorewall-accounting(5)). If not specified or set to the empty value,
# ACCOUNTING=Yes is assumed.
#
ACCOUNTING_TABLE=filter
#
# ACCOUNTING_TABLE=[filter|mangle]
#
# Added in Shorewall 4.4.20. This setting determines which Netfilter table
# the accounting rules are added in. By default, ACCOUNTING_TABLE=filter is
# assumed. See also shorewall-accounting(5).
#
ADMINISABSENTMINDED=Yes
#
# ADMINISABSENTMINDED=[Yes|No]
#
# The value of this variable affects Shorewall's stopped state. The behavior
# differs depending on whether shorewall-routestopped(5) or
# shorewall-stoppedrules(5) is used:
#
# routestopped
#
# When ADMINISABSENTMINDED=No, only traffic to/from those addresses
# listed in routestopped is accepted when Shorewall is stopped. When
# ADMINISABSENTMINDED=Yes, in addition to traffic to/from addresses in
# routestopped, connections that were active when Shorewall stopped
# continue to work and all new connections from the firewall system
# itself are allowed.
#
# Note that the routestopped file is not supported in Shorewall 5.0 and
# later versions.
#
# stoppedrules
#
# All existing connections continue to work. To sever all existing
# connections when the firewall is stopped, install the conntrack utility
# and place the command conntrack -F in the stopped user exit (/etc/
# shorewall/stopped).
#
# If ADMINISABSENTMINDED=No, only new connections matching entries in
# stoppedrules are accepted when Shorewall is stopped. Response packets
# and related connections are automatically accepted.
#
# If ADMINISABSENTMINDED=Yes, in addition to connections matching entries
# in stoppedrules, all new connections from the firewall system itself
# are allowed when the firewall is stopped. Response packets and related
# connections are automatically accepted.
#
# If this variable is not set or is given the empty value then
# ADMINISABSENTMINDED=No is assumed.
#
AUTOCOMMENT=Yes
#
# AUTOCOMMENT=[Yes|No]
#
# Formerly named AUTO_COMMENT. If set, if there is not a current comment when
# a macro is invoked, the behavior is as if the first line of the macro file
# was "COMMENT ". If not specified, the AUTO_COMMENT option has a
# default value of 'Yes'.
#
AUTOHELPERS=Yes
#
# AUTOHELPERS=[Yes|No]
#
# Added in Shorewall 4.5.7. When set to Yes (the default), the generated
# ruleset will automatically associate helpers with applications that require
# them (FTP, IRC, etc.). When configuring your firewall on systems running
# kernel 3.5 or later, it is recommended that you:
#
# 1. Set AUTOHELPERS=No.
#
# 2. Modify the HELPERS setting (see below) to list the helpers that you
# need.
#
# 3. Either:
#
# a. Modify shorewall-conntrack (5) to only apply helpers where they are
# required; or
#
# b. Specify the appropriate helper in the HELPER column in
# shorewall-rules (5).
#
# Note
#
# The macros for those applications requiring a helper automatically
# specify the appropriate HELPER where required.
#
AUTOMAKE=Yes
#
# AUTOMAKE=[Yes|No|recursive|depth]
#
# If set, the behavior of the start, reload and restart commands are changed;
# if no files in CONFIG_PATH (see below) have been changed since the last
# successful start, reload or restart command, then the compilation step is
# skipped and the compiled script that executed the last start, reload or
# restart command is used. If not specified, the default is AUTOMAKE=No.
#
# The setting of the AUTOMAKE option is ignored if the start, reload or
# restart command includes a directory name (e.g., shorewall restart /etc/
# shorewall.new).
#
# When AUTOMAKE=Yes, each directory in the CONFIG_PATH was originally
# searched recursively for files newer than the compiled script. That was
# changed in Shorewall 5.1.10.2 such that only the listed directories
# themselves were searched. That broke some configurations that played tricks
# with embedded SHELL such as "SHELL cat /etc/shorewall/rules.d/loc/*.rules".
# Prior to 5.1.10.2, a change to a file in or adding a file to /etc/shorewall
# /rules.d/loc/ would trigger recompilation. Beginning with 5.1.10.2, such
# changes would not trigger recompilation. Beginning with Shorewall 5.2.0,
# the pre-5.1.10.2 behavior can be obtained by setting AUTOMAKE=recursive.
#
# Also beginning with Shorewall 5.2.0, AUTOMAKE may be set to a numeric depth
# which specifies how deeply each listed directory is to be searched.
# AUTOMAKE=1 only searches each directory itself and is equivalent to
# AUTOMAKE=Yes. AUTOMAKE=2 will search each directory and its immediate
# sub-directories; AUTOMAKE=3 will search each directory, each of its
# immediate sub-directories, and each of their immediate sub-directories,
# etc.
#
BALANCE_PROVIDERS=No
#
# BALANCE_PROVIDERS=[Yes|No]
#
# Added in Shorewall 5.1.1. When USE_DEFAULT_RT=Yes, this option determines
# whether the balance provider option (see shorewall-providers(5)) is the
# default. When BALANCE_PROVIDERS=Yes, then the balance option is assumed
# unless the fallback, loose, load or tproxy option is specified. If this
# option is not set or is set to the empty value, then the default value is
# the value of USE_DEFAULT_RT.
#
BASIC_FILTERS=No
#
# BASIC_FILTERS=[Yes|No]
#
# Added in Shorewall-4.6.0. When set to Yes, causes entries in
# shorewall-tcfilters(5) to generate a basic filter rather than a u32 filter.
# This setting requires the Basic Ematch capability in your kernel and
# iptables.
#
# Note
#
# One of the advantages of basic filters is that ipset matches are supported
# in newer iproute2 and kernel versions. Because Shorewall cannot reliably
# detect this capability, use of basic filters is controlled by this option.
#
# The default value is No which causes u32 filters to be generated.
#
BLACKLIST="NEW,INVALID,UNTRACKED"
#
# BLACKLIST=[{ALL|state[,...]}]
#
# where state is one of NEW, ESTABLISHED, RELATED, INVALID,or UNTRACKED.
#
# Added in Shorewall 4.5.13 to replace the BLACKLISTNEWONLY option. Specifies
# the connection tracking states that are to be subject to blacklist
# screening. If BLACKLIST is not specified then the states subject to
# blacklisting are NEW,ESTABLISHED,INVALID,UNTRACKED.
#
# ALL sends all packets through the blacklist chains.
#
# Note: The ESTABLISHED state may not be specified if FASTACCEPT=Yes is
# specified.
#
CLAMPMSS=No
#
# CLAMPMSS=[Yes|No|value]
#
# This parameter enables the TCP Clamp MSS to PMTU feature of Netfilter and
# is usually required when your internet connection is through PPPoE or PPTP.
# If set to Yes or yes, the feature is enabled. If left blank or set to No or
# no, the feature is not enabled.
#
# Important: This option requires CONFIG_IP_NF_TARGET_TCPMSS in your kernel.
#
# You may also set CLAMPMSS to a numeric value (e.g., CLAMPMSS=1400). This
# will set the MSS field in TCP SYN packets going through the firewall to the
# value that you specify.
#
CLEAR_TC=No
#
# CLEAR_TC=[Yes|No]
#
# If this option is set to No then Shorewall won't clear the current traffic
# control rules during [re]start or reload. This setting is intended for use
# by people who prefer to configure traffic shaping when the network
# interfaces come up rather than when the firewall is started. If that is
# what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not supply
# an /etc/shorewall/tcstart file. That way, your traffic shaping rules can
# still use the “fwmark” classifier based on packet marking defined in
# shorewall-tcrules(5). If not specified, CLEAR_TC=Yes is assumed.
#
# Warning
#
# When you specify TC_ENABLED=shared (see below), then you should also
# specify CLEAR_TC=No.
#
COMPLETE=No
#
# COMPLETE=[Yes|No]
#
# Added in Shorewall 4.4.12. When you set this option to Yes, you are
# asserting that the configuration is complete so that your set of zones
# encompasses any hosts that can send or receive traffic to/from/through the
# firewall. This causes Shorewall to omit the rules that catch packets in
# which the source or destination IP address is outside of any of your zones.
# Default is No. It is recommended that this option only be set to Yes if:
#
# □ You have defined an interface whose effective physical setting is '+'.
#
# □ That interface is assigned to a zone.
#
# □ You have no CONTINUE policies or rules.
#
DEFER_DNS_RESOLUTION=Yes
#
# DEFER_DNS_RESOLUTION=[Yes|No]
#
# Added in Shorewall 4.5.12. When set to 'Yes' (the default), DNS names are
# validated in the compiler and then passed on to the generated script where
# they are resolved by ip[6]tables-restore. This is an advantage if you use
# AUTOMAKE=Yes and the IP address associated with the DNS name is subject to
# change. When DEFER_DNS_RESOLUTION=No, DNS names are converted into IP
# addresses by the compiler. This has the advantage that when AUTOMAKE=Yes,
# the start, reload and restart commands will succeed even if no DNS server
# is reachable (assuming that the configuration hasn't changed since the
# compiled script was last generated).
#
# Important
#
# When DEFER_DNS_RESOLUTION=No and AUTOMAKE=Yes and a DNS change makes it
# necessary to recompile an existing firewall script, the -c option must be
# used with the reload or restart command to force recompilation.
#
DELETE_THEN_ADD=Yes
#
# DELETE_THEN_ADD={Yes|No}
#
# If set to Yes (the default value), entries in the /etc/shorewall[6]/rtrules
# files cause an 'ip rule del' command to be generated in addition to an 'ip
# rule add' command. Setting this option to No, causes the 'ip rule del'
# command to be omitted.
#
DONT_LOAD=
#
# DONT_LOAD=[module[,module]...]
#
# Causes Shorewall to not load the listed kernel modules.
#
DYNAMIC_BLACKLIST=Yes
#
# DYNAMIC_BLACKLIST={Yes|No||ipset[-only][,option[,...]][:[setname][:log_level|:l
# og_tag]]]}
#
# Added in Shorewall 4.4.7. When set to No or no, chain-based dynamic
# blacklisting using shorewall [-6] [-l] drop, shorewall [-6] [-l] reject,
# shorewall logdrop and shorewall [-6] [-l] logreject is disabled. Default is
# Yes. Beginning with Shorewall 5.0.8, ipset-based dynamic blacklisting using
# the shorewall blacklist command is also supported. The name of the set (
# setname) and the level (log_level), if any, at which blacklisted traffic is
# to be logged may also be specified. The default IPv4 set name is SW_DBL4
# and the default IPv6 set name is SW_DBL6. The default log level is none (no
# logging). If ipset-only is given, then chain-based dynamic blacklisting is
# disabled just as if DYNAMIC_BLACKLISTING=No had been specified.
#
# Possible options are:
#
# src-dst
#
# Normally, only packets whose source address matches an entry in the
# ipset are dropped. If src-dst is included, then packets whose
# destination address matches an entry in the ipset are also dropped.
#
# disconnect
#
# The disconnect option was added in Shorewall 5.0.13 and requires that
# the conntrack utility be installed on the firewall system. When an
# address is blacklisted using the blacklist command, all connections
# originating from that address are disconnected. if the src-dst option
# was also specified, then all connections to that address are also
# disconnected.
#
# timeout=seconds
#
# Added in Shorewall 5.0.13. Normally, Shorewall creates the dynamic
# blacklisting ipset with timeout 0 which means that entries are
# permanent. If you want entries in the set that are not accessed for a
# period of time to be deleted from the set, you may specify that period
# using this option. Note that the blacklist command can override the
# ipset's timeout setting.
#
# Important
#
# Once the dynamic blacklisting ipset has been created, changing this
# option setting requires a complete restart of the firewall; shorewall
# [-6] restart if RESTART=restart, otherwise shorewall [-6] [-l] stop &&
# shorewall [-6] [-l] start
#
# When ipset-based dynamic blacklisting is enabled, the contents of the
# blacklist will be preserved over stop/reboot/start sequences if SAVE_IPSETS
# =Yes, SAVE_IPSETS=ipv4 or if setname is included in the list of sets to be
# saved in SAVE_IPSETS.
#
EXPAND_POLICIES=Yes
#
# EXPAND_POLICIES={Yes|No}
#
# Normally, when the SOURCE or DEST columns in shorewall-policy(5) contains
# 'all', a single policy chain is created and thes policy is enforced in that
# chain. For example, if the policy entry is
#
# #SOURCE DEST POLICY LOG
# # LEVEL
# net all DROP info
#
# then the chain name is 'net-all' ('net2all if ZONE2ZONE=2) which is also
# the chain named in Shorewall log messages generated as a result of the
# policy. If EXPAND_POLICIES=Yes, then Shorewall will create a separate chain
# for each pair of zones covered by the policy. This makes the resulting log
# messages easier to interpret since the chain in the messages will have a
# name of the form 'a2b' where 'a' is the SOURCE zone and 'b' is the DEST
# zone.
#
EXPORTMODULES=Yes
#
# EXPORTMODULES=[Yes|No]
#
# Added in Shorewall 4.4.17. When set to Yes when compiling for use by
# Shorewall Lite (shorewall [-6] remote-start, shorewall [-6] remote-reload,
# shorewall [-6] remote-restart or shorewall [-6] export commands), the
# compiler will copy the modules or helpers file from the administrative
# system into the script. When set to No or not specified, the compiler will
# not copy the modules or helpers file from /usr/share/shorewall[6] but will
# copy those found in another location on the CONFIG_PATH.
#
# When compiling for direct use by Shorewall, causes the contents of the
# local module or helpers file to be copied into the compiled script. When
# set to No or not set, the compiled script reads the file itself.
#
FASTACCEPT=No
#
# FASTACCEPT={Yes|No}
#
# 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 'loc-net' or 'loc2net'
# chain, depending on the setting of ZONE2ZONE (see below).
#
# If you set FASTACCEPT=Yes, then ESTABLISHED/RELATED 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
# shorewall-rules(5).
#
FORWARD_CLEAR_MARK=
#
# FORWARD_CLEAR_MARK={Yes|No}
#
# Added in Shorewall 4.4.11. Traditionally, Shorewall has cleared the packet
# mark in the first rule in the mangle FORWARD chain. This behavior is
# maintained with the default setting of this option (FORWARD_CLEAR_MARK=
# Yes). If FORWARD_CLEAR_MARK is set to 'No', packet marks set in the mangle
# PREROUTING chain are retained in the FORWARD chains.
#
HELPERS=
#
# HELPERS=[helper[,helper...]]
#
# Added in Shorewall 4.5.7. This option specifies a comma-separated list
# naming the Netfilter application helpers that are to be enabled. If not
# specified, the default is to enable all helpers.
#
# Possible values for helper are:
#
# □ amanda
#
# □ ftp
#
# □ h323
#
# □ irc
#
# □ netbios-ns
#
# □ none - This special value was added in Shorewall 4.5.16 and indicates
# that no helpers are to be enabled. It also prevents the compiler for
# probing for helper support; such probing generates messages on the
# system log of the form "xt_CT: No such helper XXX" where XXX is the
# helper name. When used, none must be the only helper specified.
#
# □ pptp
#
# □ sane
#
# □ sip
#
# □ snmp
#
# □ tftp
#
# When HELPERS is specified on a system running Kernel 3.5.0 or later,
# automatic association of helpers to connections is disabled.
#
IGNOREUNKNOWNVARIABLES=No
#
# IGNOREUNKNOWNVARIABLES=[Yes|No]
#
# Added in Shorewall 4.5.11. Normally, if an unknown shell variable is
# encountered in a configuration file (except in ?IF and ?ELSIF directives),
# the compiler raises a fatal error. If IGNOREUNKNOWNVARIABLES is set to Yes,
# then such variables simply expand to an empty string. Default is No.
#
IMPLICIT_CONTINUE=No
#
# IMPLICIT_CONTINUE={Yes|No}
#
# When this option is set to Yes, it causes subzones to be treated
# differently with respect to policies.
#
# Subzones are defined by following their name with ":" and a list of parent
# zones (in shorewall-zones(5)). Normally, you want to have a set of special
# rules for the subzone and if a connection doesn't match any of those
# subzone-specific rules then you want the parent zone rules and policies to
# be applied; see shorewall-nesting(5). With IMPLICIT_CONTINUE=Yes, that
# happens automatically.
#
# If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set, then subzones
# are not subject to this special treatment. With IMPLICIT_CONTINUE=Yes, an
# implicit CONTINUE policy may be overridden by including an explicit policy
# (one that does not specify "all" in either the SOURCE or the DEST columns).
#
IPSET_WARNINGS=Yes
#
# IPSET_WARNINGS={Yes|No}
#
# Added in Shorewall 4.5.2. Default is Yes. When set, causes the rules
# compiler to issue a warning when:
#
# □ The compiler is being run by root and an ipset specified in the
# configuration does not exists. Only one warning is issued for each
# missing ipset.
#
# □ When [src] is specified in a destination column and when [dst] is
# specified in a source column.
#
IP_FORWARDING=Keep
#
# IP_FORWARDING=[On|Off|Keep]
#
# This IPv4 parameter determines whether Shorewall enables or disables IPv4
# Packet Forwarding (/proc/sys/net/ipv4/ip_forward). In an IPv6
# configuration, this parameter determines the setting of /proc/sys/net/ipv6/
# config/all/ip_forwarding.
#
# Possible values are:
#
# On or on
#
# packet forwarding will be enabled.
#
# Off or off
#
# packet forwarding will be disabled.
#
# Keep or keep
#
# Shorewall will neither enable nor disable packet forwarding.
#
# If this variable is not set or is given an empty value (IP_FORWARD="") then
# IP_FORWARD=On is assumed.
#
KEEP_RT_TABLES=Yes
#
# KEEP_RT_TABLES={Yes|No}
#
# IPv4:
#
# When set to Yes, this option prevents generated scripts from altering
# the /etc/iproute2/rt_tables database when there are entries in /etc/
# shorewall/providers. If you set this option to Yes while Shorewall
# (Shorewall-lite) is running, you should remove the file /var/lib/
# shorewall/rt_tables (/var/lib/shorewall-lite/rt_tables) before your
# next stop, restore, reload or restart command.
#
# IPv6:
#
# When set to Yes, this option prevents scripts generated by Shorewall6
# from altering the /etc/iproute2/rt_tables database when there are
# entries in /etc/shorewall6/providers. If you set this option to Yes
# while Shorewall6 (Shorewall6-lite) is running, you should remove the
# file /var/lib/shorewall6/rt_tables (/var/lib/shorewall6-lite/rt_tables)
# before your next stop, restore, reload or restart command.
#
# Important
#
# When both IPv4 and IPv6 Shorewall configurations are present,
# KEEP_RT_TABLES=No should be specified in only one of the two configurations
# unless the two provider configurations are identical with respect to
# interface and provider names and numbers.
#
# The default is KEEP_RT_TABLES=No.
#
MACLIST_TABLE=filter
#
# MACLIST_TABLE=[filter|mangle]
#
# Normally, MAC verification occurs in the filter table (INPUT and FORWARD)
# chains. When forwarding a packet from an interface with MAC verification to
# a bridge interface, that doesn't work.
#
# This problem can be worked around by setting MACLIST_TABLE=mangle which
# will cause Mac verification to occur out of the PREROUTING chain. Because
# REJECT isn't available in that environment, you may not specify
# MACLIST_DISPOSITION=REJECT or MACLIST_DISPOSITION=A_REJECT with
# MACLIST_TABLE=mangle.
#
MACLIST_TTL=
#
# MACLIST_TTL=[number]
#
# The performance of configurations with a large numbers of entries in
# shorewall-maclist(5) can be improved by setting the MACLIST_TTL variable in
# shorewall[6].conf(5).
#
# If your iptables and kernel support the "Recent Match" (see the output of
# "shorewall check" near the top), you can cache the results of a 'maclist'
# file lookup and thus reduce the overhead associated with MAC Verification.
#
# When a new connection arrives from a 'maclist' interface, the packet passes
# through then list of entries for that interface in shorewall-maclist(5). If
# there is a match then the source IP address is added to the 'Recent' set
# for that interface. Subsequent connection attempts from that IP address
# occurring within $MACLIST_TTL seconds will be accepted without having to
# scan all of the entries. After $MACLIST_TTL from the first accepted
# connection request from an IP address, the next connection request from
# that IP address will be checked against the entire list.
#
# If MACLIST_TTL is not specified or is specified as empty (e.g, MACLIST_TTL=
# "" or is specified as zero then 'maclist' lookups will not be cached).
#
MANGLE_ENABLED=Yes
#
# MANGLE_ENABLED=[Yes|No]
#
# Determines whether Shorewall will generate rules in the Netfilter mangle
# table. Setting MANGLE_ENABLED=No disables all Shorewall features that
# require the mangle table. The default is MANGLE_ENABLED=Yes.
#
MARK_IN_FORWARD_CHAIN=No
#
# MARK_IN_FORWARD_CHAIN=[Yes|No]
#
# If your kernel has a FORWARD chain in the mangle table, you may set
# MARK_IN_FORWARD_CHAIN=Yes to cause the marking specified in the tcrules
# file to occur in that chain rather than in the PREROUTING chain. This
# permits you to mark inbound traffic based on its destination address when
# DNAT is in use. To determine if your kernel has a FORWARD chain in the
# mangle table, use the shorewall [-6] show mangle command; if a FORWARD
# chain is displayed then your kernel will support this option. If this
# option is not specified or if it is given the empty value (e.g.,
# MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed.
#
MINIUPNPD=No
#
# MINIUPNPD=[Yes|No]
#
# Added in Shorewall 5.0.8. If set to Yes, Shorewall will create a chain in
# the nat table named MINIUPNPD-POSTROUTING and will add jumps from
# POSTROUTING to that chain for each interface with the upnpd option
# specified. Default is No.
#
MUTEX_TIMEOUT=60
#
# MUTEX_TIMEOUT=[seconds]
#
# The value of this variable determines the number of seconds that programs
# will wait for exclusive access to the Shorewall[6] lock file. After the
# number of seconds corresponding to the value of this variable, programs
# will assume that the last program to hold the lock died without releasing
# the lock.
#
# If not set or set to the empty value, a value of 60 (60 seconds) is
# assumed.
#
# An appropriate value for this parameter would be twice the length of time
# that it takes your firewall system to process a shorewall [-6] restart
# command.
#
OPTIMIZE=All
#
# OPTIMIZE=[value]
#
# The specified value enables certain optimizations. Each optimization
# category is associated with a power of two. To enable multiple optimization
# categories, simply add their corresponding numbers together.
#
# Beginning with Shorewall 4.5.20, you may specify OPTIMIZE=All to enable all
# optimization categories, and you may also specify OPTIMIZE=None to disable
# optimization.
#
# □ Optimization category 1 - Traditionally, Shorewall has created rules
# for the complete matrix of host groups defined by the zones, interfaces
# and hosts files. Any traffic that didn't correspond to an element of
# that matrix was rejected in one of the built-in chains. When the matrix
# is sparse, this results in lots of largely useless rules.
#
# These extra rules can be eliminated by setting the 1 bit in OPTIMIZE.
#
# The 1 bit setting also controls the suppression of redundant wildcard
# rules (those specifying "all" in the SOURCE or DEST column). A wildcard
# rule is considered to be redundant when it has the same ACTION and Log
# Level as the applicable policy.
#
# Note
#
# Optimization level 1 is ignored when optimization level 4 is also
# selected, since level 4 performs similar optimizations in a more robust
# way.
#
# □ Optimization category 2 - Added in Shorewall 4.4.7. When set,
# suppresses superfluous ACCEPT rules in a policy chain that implements
# an ACCEPT policy. Any ACCEPT rules that immediately precede the final
# blanket ACCEPT rule in the chain are now omitted.
#
# □ Optimization category 4 - Added in Shorewall 4.4.7. When set, causes
# short chains (those with less than 2 rules) to be optimized away. The
# following chains are excluded from optimization:
#
# ☆ accounting chains (unless OPTIMIZE_ACCOUNTING=Yes)
#
# ☆ action chains (user-defined)
#
# ☆ 'blacklst' chain
#
# ☆ dynamic
#
# ☆ forwardUPnP
#
# ☆ UPnP (nat table)
#
# Additionally:
#
# ☆ If a built-in chain has a single rule that branches to a second
# chain, then the rules from the second chain are moved to the
# built-in chain and the target chain is omitted.
#
# ☆ Chains with no references are deleted.
#
# ☆ Accounting chains are subject to optimization if the
# OPTIMIZE_ACCOUNTING option is set to 'Yes'.
#
# ☆ If a chain ends with an unconditional branch to a second chain
# (other than to 'reject'), then the branch is deleted from the first
# chain and the rules from the second chain are appended to it.
#
# An additional optimization was added in Shorewall 4.5.4. If the last
# rule in a chain is an unqualified jump to a simple target, then all
# immediately preceding rules with the same simple target are omitted.
#
# For example, consider this chain:
#
# -A fw-net -p udp --dport 67:68 -j ACCEPT
# -A fw-net -p udp --sport 1194 -j ACCEPT
# -A fw-net -p 41 -j ACCEPT
# -A fw-net -j ACCEPT
#
# Since all of the rules are jumps to the simple target ACCEPT, this
# chain is totally optimized away and jumps to the chain are replace with
# jumps to ACCEPT.
#
# □ Optimization category 8 - Added in Shorewall 4.4.9. When set, causes
# chains with identical rules to be collapsed into a single chain.
#
# Warning
#
# While Optimization category 8 can significantly reduce the size of the
# generated iptables ruleset, it can also take significant system
# resources during compilation. If you find that compilation takes an
# unreasonably long time, try disabling this category by setting OPTIMIZE
# =23.
#
# □ Optimization category 16 - Added in Shorewall 4.4.26. When set, causes
# sequences of compatible rules to be combined into a single rule. Rules
# are considered compatible if they differ only in their destination
# ports and comments.
#
# A sequence of compatible rules is often generated when macros are
# invoked in sequence.
#
# The ability to combine adjacent rules is limited by two factors:
#
# ☆ Destination port lists may only be combined up to a maximum of 15
# ports, where a port-pair counts as two ports.
#
# ☆ Rules may only be combined until the length of their concatenated
# comment reaches 255 characters.
#
# When either of these limits would be exceeded, the current combined
# rule is emitted and the compiler attempts to combine rules beginning
# with the one that would have exceeded the limit. Adjacent combined
# comments are separated by ', '. Empty comments at the front of a group
# of combined comments are replaced by 'Others and'. Empty comments at
# the end of a group of combined comments are replaced by 'and others'.
#
# Beginning in Shorewall 4.5.10, this option also suppresses duplicate
# adjacent rules and duplicate non-adjacent rules that don't include mark
# , connmark, dscp, ecn, set, tos or u32 matches.
#
# Example 1:
#
# Rules with comments "FOO", and "BAR" would result in the
# combined comment "FOO and others, BAR".
#
# Example 2:
#
# Rules with comments , "FOO" and "BAR" would result in the
# combined comment "Others and FOO, BAR". Note: Optimize level 16
# requires "Extended Multi-port Match" in your iptables and kernel.
#
# In versions prior to 5.1.0, the default value is zero which disables all
# optimizations. Beginning with Shorewall 5.1.0, the default value is All
# which enables all optimizations.
#
OPTIMIZE_ACCOUNTING=No
#
# OPTIMIZE_ACCOUNTING=[Yes|No]
#
# Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting changes are
# subject to optimization (OPTIMIZE=4,5,6 or 7). If not specified or set to
# the empty value, OPTIMIZE_ACCOUNTING=No is assumed.
#
PERL_HASH_SEED=0
#
# PERL_HASH_SEED=seed|random
#
# Added in Shorewall 5.1.4. Sets the Perl hash seed (an integer in the range
# 0-99999) when running the Shorewall rules compiler. If not specified, the
# value 0 is assumed. If random is specified, a random seed will be chosed by
# Perl. See perlsec(1) for additional information.
#
REJECT_ACTION=
#
# REJECT_ACTION=action
#
# Added in Shorewall 4.5.21. When a REJECT target is specified, Shorewall
# normally handles the response as follows:
#
# □ If the destination address of the packet is a broadcast or multicast
# address, the packet is dropped.
#
# □ if the protocol is ICMP (2) then the packet is dropped.
#
# □ if the protocol is TCP (6) then the packet is rejected with an RST.
#
# □ if the protocol is UDP (17) then the packet is rejected with an
# 'port-unreachable' ICMP.
#
# □ if the protocol is ICMP (1) then the packet is rejected with a
# 'host-unreachable' ICMP.
#
# □ if the protocol is ICMP6 (1) then the packet is rejected with a
# 'icmp6-addr-unreachable' ICMP6.
#
# □ otherwise, the packet is rejected with a 'host-prohibited' ICMP.
#
# You can modify this behavior by implementing your own action that handles
# REJECT and specifying it's name in this option. The nolog and noinline
# options will automatically be assumed for the specified action.
#
# The following action implements the default reject action:
#
# ?format 2
# #TARGET SOURCE DEST PROTO
# Broadcast(DROP) - - -
# DROP - - 2
# INLINE - - 6 ;; -j REJECT --reject-with tcp-reset
# ?if __ENHANCED_REJECT
# INLINE - - 17 ;; -j REJECT
# ?if __IPV4
# INLINE - - 1 ;; -j REJECT --reject-with icmp-host-unreachable
# INLINE - - - ;; -j REJECT --reject-with icmp-host-prohibited
# ?else
# INLINE - - 58 ;; -j REJECT --reject-with icmp6-addr-unreachable
# INLINE - - - ;; -j REJECT --reject-with icmp6-adm-prohibited
# ?endif
# ?else
# INLINE - - - ;; -j REJECT
# ?endif
#
RENAME_COMBINED=Yes
#
# RENAME_COMBINED=[Yes|No]
#
# Added in Shorewall 5.2.0. Traditionally, when OPTIMIZE category 8 is
# enabled, identical chains are combined under a name beginning with '~comb'
# or '~blacklist'. This behavior is maintained under the default setting
# RENAME_COMBINED=Yes. If RENAMED_COMBINED=No, the chains are combined under
# the original name of one of the chains.
#
REQUIRE_INTERFACE=No
#
# REQUIRE_INTERFACE=[Yes|No]
#
# Added in Shorewall 4.4.10. The default is No. If set to Yes, at least one
# optional interface must be up in order for the firewall to be in the
# started state. Intended to be used with the Shorewall Init Package.
#
RESTART=restart
#
# RESTART=[restart|reload]
#
# Added in Shorewall 5.0.1 to replace LEGACY_RESTART which was added in
# Shorewall 5.0.0. In that release, the reload command was redefined to do
# what restart had done in earlier releases and restart became a true restart
# (equivalent to stop followed by start). When RESTART=reload, the restart
# command performs the same operation as the reload command making it
# compatible with earlier releases. If not specified, RESTART=reload is
# assumed.
#
RESTORE_DEFAULT_ROUTE=Yes
#
# RESTORE_DEFAULT_ROUTE=[Yes|No]
#
# This option determines whether to restore the default route saved when here
# are 'balance' providers defined but all of them are down.
#
# The default is RESTORE_DEFAULT_ROUTE=Yes which preserves the pre-4.2.6
# behavior.
#
# RESTORE_DEFAULT_ROUTE=No is appropriate when you don't want a default route
# in the main table (USE_DEFAULT_RT=No) or in the default table
# (USE_DEFAULT_RT=Yes) when there are no balance providers available. In that
# case, RESTORE_DEFAULT_ROUTE=No will cause any default route in the relevant
# table to be deleted.
#
RESTORE_ROUTEMARKS=Yes
#
# RESTORE_ROUTEMARKS=[Yes|No]
#
# Added in Shorewall 4.5.9. When set to Yes (the default), provider marks are
# restored unconditionally at the top of the mangle OUTPUT and PREROUTING
# chains, even if the saved mark is zero. When this option is set to No, the
# mark is restored only if it is non-zero. If you have problems with IPSEC
# ESP packets not being routed correctly on output, try setting this option
# to No.
#
SAVE_IPSETS=No
#
# SAVE_IPSETS={Yes|No|ipv4|setlist}
#
# Re-enabled in Shorewall 4.4.6. If SAVE_IPSETS=Yes, then the current
# contents of your ipsets will be saved by the shorewall stop and shorewall
# save commands and restored by the shorewall start and shorewall restore
# commands.
#
# Beginning with Shorewall 4.6.4, you can restrict the set of ipsets saved by
# specifying a setlist (a comma-separated list of ipv4 ipset names). You may
# also restrict the saved sets to just the ipv4 ones by specifying ipv4.
#
TC_ENABLED=Shared
#
# TC_ENABLED=[Yes|No|Internal|Simple|Shared]
#
# If you say Yes or yes here, Shorewall will use a script that you supply to
# configure traffic shaping. The script must be named 'tcstart' and must be
# placed in a directory on your CONFIG_PATH.
#
# If you say No or no then traffic shaping is not enabled.
#
# If you set TC_ENABLED=Simple (Shorewall 4.4.6 and later), simple traffic
# shaping using shorewall-tcinterfaces(5) and shorewall-tcpri(5) is enabled.
#
# If you set TC_ENABLED=Internal or internal or leave the option empty then
# Shorewall will use its builtin traffic shaper (tc4shorewall written by Arne
# Bernin.
#
# Beginning with Shorewall 4.4.15, you can set TC_ENABLED=Shared. This allows
# you to configure the tcdevices and tcclasses in your Shorewall6
# configuration yet make them available to the compiler when compiling your
# Shorewall configuration. In addition to setting TC_ENABLED=Shared, you need
# to create symbolic links from your Shorewall configuration directory
# (normally /etc/shorewall/) to the tcdevices and tcclasses files in your
# Shorewall6 configuration directory (normally /etc/shorewall6/).
#
TC_EXPERT=No
#
# TC_EXPERT={Yes|No}
#
# Normally, Shorewall tries to protect users from themselves by preventing
# PREROUTING and OUTPUT tcrules from being applied to packets that have been
# marked by the 'track' option in shorewall-providers(5).
#
# If you know what you are doing, you can set TC_EXPERT=Yes and Shorewall
# will not include these cautionary checks.
#
TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2"
#
# TC_PRIOMAP=map
#
# Added in Shorewall 4.4.6. Determines the mapping of a packet's TOS field to
# priority bands. See shorewall-tcpri(5). The map consists of 16
# space-separated digits with values 1, 2 or 3. A value of 1 corresponds to
# Linux priority 0, 2 to Linux priority 1, and 3 to Linux Priority 2. The
# first entry gives the priority of TOS value 0, the second of TOS value 1,
# and so on. See tc-prio(8) for additional information.
#
# The default setting is TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2".
#
TRACK_PROVIDERS=Yes
#
# TRACK_PROVIDERS={Yes|No}
#
# Added in Shorewall 4.4.3. When set to Yes, causes the track option to be
# assumed on all providers defined in shorewall-providers(5). May be
# overridden on an individual provider through use of the notrack option. The
# default value is 'No'.
#
# Beginning in Shorewall 4.4.6, setting this option to 'Yes' also simplifies
# PREROUTING rules in shorewall-tcrules(5). Previously, when TC_EXPERT=No,
# packets arriving through 'tracked' provider interfaces were unconditionally
# passed to the PREROUTING tcrules. This was done so that tcrules could reset
# the packet mark to zero, thus allowing the packet to be routed using the
# 'main' routing table. Using the main table allowed dynamic routes (such as
# those added for VPNs) to be effective. The rtrules file was created to
# provide a better alternative to clearing the packet mark. As a consequence,
# passing these packets to PREROUTING complicates things without providing
# any real benefit. Beginning with Shorewall 4.4.6, when TRACK_PROVIDERS=Yes
# and TC_EXPERT=No, packets arriving through 'tracked' interfaces will not be
# passed to the PREROUTING rules. Since TRACK_PROVIDERS was just introduced
# in 4.4.3, this change should be transparent to most, if not all, users.
#
TRACK_RULES=No
#
# TRACK_RULES={Yes|No|File}
#
# Added in Shorewall 4.5.20. If set to Yes, causes the compiler to add a
# comment to iptables rules to indicate the file name and line number of the
# configuration entry that generated the rule. If set to No (the default),
# then no such comments are added.
#
# Setting this option to Yes requires the Comments capability in iptables and
# kernel.
#
# Beginning with Shorewall 5.0.5, the option may also be set to File. That
# setting causes similar comments to be added to the .iptables-restore-input
# file, which is normally created in /var/lib/shorewall.
#
USE_DEFAULT_RT=Yes
#
# USE_DEFAULT_RT=[Yes|No]
#
# When set to 'Yes', this option causes the Shorewall multi-ISP feature to
# create a set of routing rules which are resilient to changes in the main
# routing table. Such changes can occur for a number of reasons, VPNs going
# up and down being an example. The idea is to send packets through the main
# table prior to applying any of the Shorewall-generated routing rules. So
# changes to the main table will affect the routing of packets by default.
#
# When USE_DEFAULT_RT=Yes:
#
# 1. Both the DUPLICATE and the COPY columns in providers(5) file must
# remain empty (or contain "-").
#
# 2. The default route is added to the the 'default' table rather than to
# the main table.
#
# 3. If running Shorewall 5.1.0 or earlier or if BALANCE_PROVIDERS=Yes
# (Shorewall 5.1.1 or later), then the balance provider option is assumed
# unless the fallback, loose, load or tproxy option is specified.
#
# 4. Packets are sent through the main routing table by a rule with priority
# 999. In shorewall-rtrules(5), the range 1-998 may be used for inserting
# rules that bypass the main table.
#
# 5. All provider gateways must be specified explicitly in the GATEWAY
# column. detect may not be specified.
#
# Note
#
# detect may be specified for interfaces whose configuration is managed
# by dhcpcd. Shorewall will use dhcpcd's database to find the interface's
# gateway.
#
# 6. You should disable all default route management outside of Shorewall.
# If a default route is added to the main table while Shorewall is
# started, then all policy routing will stop working (except for those
# routing rules in the priority range 1-998).
#
# Prior to Shorewall 4.6.0, if USE_DEFAULT_RT was not set or if it was set to
# the empty string then USE_DEFAULT_RT=No was assumed. Beginning with
# Shorewall 4.6.0, the default is USE_DEFAULT_RT=Yes and use of
# USE_DEFAULT_RT=No is deprecated.
#
# Warning
#
# The enable, disable and reenable commands do not work correctly when
# USE_DEFAULT_RT=No.
#
USE_NFLOG_SIZE=No
#
# USE_NFLOG_SIZE=[Yes|No]
#
# Added in Shorewall 5.1.5. The second parameter to the NFLOG target
# specifies how many bytes of the packet to copy to the log; if omitted or if
# supplied as zero, the entire packet is copied. This feature has
# traditionally been implemented using the --nflog-range option to the NFLOG
# iptables target. Unfortuntely, the --nflog-range option never worked (the
# entire packet was always copied). To deal with this issue, the Netfilter
# team:
#
# □ Added a warning message when --nflog-range is used
#
# □ Added --nflog-size which works like --nflog-range was intended to work.
#
# When USE_NFLOG_SIZE=Yes, Shorewall will attempt to use the new --nflog-size
# feature. If that feature is not available in the running kernel and ip[6]
# tables, an error is raised.
#
# When USE_NFLOG_SIZE is not supplied, USE_NFLOG_SIZE=No is assumed. When
# USE_NFLOG_SIZE is added by shorewall update, it is added with setting No.
#
USE_PHYSICAL_NAMES=No
#
# USE_PHYSICAL_NAMES=[Yes|No]
#
# Added in Shorewall 4.4.27. Normally, when Shorewall creates a Netfilter
# chain that relates to an interface, it uses the interface's logical name as
# the base of the chain name. For example, if the logical name for an
# interface is OAKLAND, then the input chain for traffic arriving on that
# interface would be 'OAKLAND_in'. If this option is set to Yes, then the
# physical name of the interface will be used the base of the chain name.
#
USE_RT_NAMES=No
#
# USE_RT_NAMES=[Yes|No]
#
# Added in Shorewall 4.5.15. When set to 'Yes', Shorewall will use routing
# table (provider) names in the generated script rather than table numbers.
# When set to 'No' (the default), routing table numbers will be used.
#
# Caution
#
# If you set USE_RT_NAMES=Yes and KEEP_RT_TABLES=Yes, then you must insure
# that all of your providers have entries in /etc/iproute2/rt_tables as well
# as the following entries:
#
# 255 local
# 254 main
# 253 default
# 250 balance
# 0 unspec
#
# Without these entries, the firewall will fail to start.
#
VERBOSE_MESSAGES=Yes
#
# VERBOSE_MESSAGES=[Yes|No]
#
# Added in Shorewall 5.0.9. When Yes (the default), messages produced by the
# ?INFO and ?WARNING directives include the filename and linenumber of the
# directive. When set to No, that additional information is omitted. The
# setting may be overridden on a directive by directive basis by following ?
# INFO or ?WARNING with '!' (no intervening white space).
#
WARNOLDCAPVERSION=Yes
#
# WARNOLDCAPVERSION=[Yes|No]
#
# Added in Shorewall 4.5.12. When set to Yes (the default), the compiler
# issues a warning when it finds a capabilities file that doesn't specify all
# of the capabilities supported by the compiler. When WARNOLDCAPVERSION is
# set to No, no warning is issued.
#
WORKAROUNDS=No
#
# WORKAROUNDS=[Yes|No]
#
# Added in Shorewall 4.6.11. Over time, there have been a number of changes
# in Shorewall that work around defects in other products such as iptables
# and ipset. When WORKAROUNDS=Yes, these workarounds are enabled; when
# WORKAROUNDS=No, they are disabled. If not specified or if specified as
# empty, WORKAROUNDS=Yes is assumed.
#
# Warning
#
# Do not set WORKAROUNDS=Yes if you need to be able to use
# Shorewall-generated scripts (such as created by the save command) built by
# Shorewall 4.4.7 or older.
#
ZERO_MARKS=No
#
# ZERO_MARKS=[Yes|No]
#
# Added in Shorewall 5.0.12, this is a workaround for an issue where packet
# marks are not zeroed by the kernel. It should be set to No (the default)
# unless you find that incoming packets are being mis-routed for no apparent
# reasons.
#
# Caution
#
# Do not set this option to Yes if you have IPSEC software running on the
# firewall system.
#
ZONE2ZONE=-
#
# ZONE2ZONE=[2|-]
#
# Added in Shorewall 4.4.4. This option determines how Shorewall constructs
# chain names involving zone names and/or 'all'. Beginning with Shorewall
# 4.6.0, the default is '-' (e.g., fw-net); prior to that release, the
# default was '2' (e.g., fw2net).
#
###############################################################################
# P A C K E T D I S P O S I T I O N
###############################################################################
BLACKLIST_DISPOSITION=DROP
#
# BLACKLIST_DISPOSITION=[DROP|A_DROP|REJECT|A_REJECT]
#
# This parameter determines the disposition of packets from blacklisted
# hosts. It may have the value DROP if the packets are to be dropped or
# REJECT if the packets are to be replied with an ICMP port unreachable reply
# or a TCP RST (tcp only). If you do not assign a value or if you assign an
# empty value then DROP is assumed.
#
# A_DROP and A_REJECT are audited versions of DROP and REJECT respectively
# and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel
# and iptables.
#
# The BLACKLIST_DISPOSITION setting determines the disposition of packets
# sent to the blacklog target of shorewall-blrules (5), but otherwise does
# not affect entries in that file.
#
INVALID_DISPOSITION=CONTINUE
#
# INVALID_DISPOSITION=[A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
#
# Added in Shorewall 4.5.13. Shorewall has traditionally passed INVALID
# packets through the NEW section of shorewall-rules (5). When a packet in
# INVALID state fails to match any rule in the INVALID section, the packet is
# disposed of based on this setting. The default value is CONTINUE for
# compatibility with earlier versions.
#
MACLIST_DISPOSITION=REJECT
#
# MACLIST_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]
#
# Determines the disposition of connections requests that fail MAC
# Verification and must have the value ACCEPT (accept the connection request
# anyway), REJECT (reject the connection request) or DROP (ignore the
# connection request). If not set or if set to the empty value (e.g.,
# MACLIST_DISPOSITION="") then MACLIST_DISPOSITION=REJECT is assumed.
#
# A_DROP and A_REJECT are audited versions of DROP and REJECT respectively
# and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel
# and ip[6]tables.
#
RELATED_DISPOSITION=ACCEPT
#
# RELATED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
#
# Added in Shorewall 4.4.27. Shorewall has traditionally ACCEPTed RELATED
# packets that don't match any rule in the RELATED section of shorewall-rules
# (5). Concern about the safety of this practice resulted in the addition of
# this option. When a packet in RELATED state fails to match any rule in the
# RELATED section, the packet is disposed of based on this setting. The
# default value is ACCEPT for compatibility with earlier versions.
#
SFILTER_DISPOSITION=DROP
#
# SFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]
#
# Added in Shorewall 4.4.20. Determines the disposition of packets matching
# the sfilter option (see shorewall-interfaces(5)) and of hairpin packets on
# interfaces without the routeback option.^[1]
#
RPFILTER_DISPOSITION=DROP
#
# RPFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]
#
# Added in Shorewall 4.5.7. Determines the disposition of packets entering
# from interfaces the rpfilter option (see shorewall-interfaces(5)). Packets
# disposed of by this option are those whose response packets would not be
# sent through the same interface receiving the packet.
#
SMURF_DISPOSITION=DROP
#
# SMURF_DISPOSITION=[DROP|A_DROP]
#
# Added in Shorewall 4.4.20. The default setting is DROP which causes smurf
# packets (see the nosmurfs option in shorewall-interfaces(5)) to be dropped.
# A_DROP causes the packets to be audited prior to being dropped and requires
# AUDIT_TARGET support in the kernel and iptables.
#
TCP_FLAGS_DISPOSITION=DROP
#
# TCP_FLAGS_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]
#
# Determines the disposition of TCP packets that fail the checks enabled by
# the tcpflags interface option (see shorewall-interfaces(5)) and must have a
# value of ACCEPT (accept the packet), REJECT (send an RST response) or DROP
# (ignore the packet). If not set or if set to the empty value (e.g.,
# TCP_FLAGS_DISPOSITION="") then TCP_FLAGS_DISPOSITION=DROP is assumed.
#
# A_DROP and A_REJECT are audited versions of DROP and REJECT respectively
# and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel
# and iptables.
#
UNTRACKED_DISPOSITION=CONTINUE
#
# UNTRACKED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
#
# Added in Shorewall 4.5.13. Shorewall has traditionally passed UNTRACKED
# packets through the NEW section of shorewall-rules (5). When a packet in
# UNTRACKED state fails to match any rule in the UNTRACKED section, the
# packet is disposed of based on this setting. The default value is CONTINUE
# for compatibility with earlier versions.
#
################################################################################
# P A C K E T M A R K L A Y O U T
################################################################################
TC_BITS=
#
# TC_BITS=[number]
#
# The number of bits at the low end of the 32-bit packet mark to be used for
# traffic shaping marking. May be zero. See MASK_BITS above for default
# value.
#
PROVIDER_BITS=
#
# PROVIDER_BITS=[number]
#
# Added in Shorewall 4.4.26. The number of bits in the 32-bit packet mark to
# be used for provider numbers. May be zero. See MASK_BITS above for default
# value.
#
PROVIDER_OFFSET=
#
# PROVIDER_OFFSET=[number]If
#
# Added in Shorewall 4.4.26. The offset from the right (low-order end) of the
# provider number field in the 32-bit packet mark. If non-zero, must be >=
# TC_BITS (Shorewall automatically adjusts PROVIDER_OFFSET's value).
# PROVIDER_OFFSET + PROVIDER_BITS + ZONE_BITS must be < 32. See MASK_BITS
# above for default value.
#
MASK_BITS=
#
# MASK_BITS=[number]
#
# Added in Shorewall 4.4.26. Number of bits on the right of the 32-bit packet
# mark to be masked when clearing the traffic shaping mark. Must be >=
# TC_BITS and <= PROVIDER_OFFSET (if PROVIDER_OFFSET > 0). Prior to Shorewall
# 5.0.0, default value and the default values of the other mark layout
# options is determined as follows:
#
# Table 1. Default Packet Mark Layout
#
# WIDE_TC_MARKS=No, TC_BITS=8, PROVIDER_BITS=8, PROVIDER_OFFSET=
# HIGH_ROUTE_MARKS=No 0, MASK_BITS=8
# WIDE_TC_MARKS=No, TC_BITS=8, PROVIDER_BITS=8, PROVIDER_OFFSET=
# HIGH_ROUTE_MARKS=Yes 8, MASK_BITS=8
# WIDE_TC_MARKS=Yes, TC_BITS=14, PROVIDER_BITS=8, PROVIDER_OFFSET=
# HIGH_ROUTE_MARKS=No 0, MASK_BITS=16
# WIDE_TC_MARKS=Yes, TC_BITS=14, PROVIDER_BITS=8, PROVIDER_OFFSET=
# HIGH_ROUTE_MARKS=Yes 16, MASK_BITS=16
#
#
# From 5.0.0 onward, the default value of MASK_BITS is 8, the default value
# of PROVIDER_BITS, TC_BITS, MASK_BITS and PROVIDER_OFFSET is 8.
#
ZONE_BITS=0
#
# ZONE_BITS=[number]
#
# Added in Shorewall 4.4.26. When non-zero, enables automatic packet marking
# by source zone and determines the number of bits in the 32-bit packet mark
# to be used for the zone mark. Default value is 0.
#
shorewall6-5.2.3.4/Samples6/three-interfaces/shorewall6.conf 0000664 0000000 0000000 00000012074 13531060406 022332 0 ustar root root ###############################################################################
#
# Shorewall Version 5 -- /etc/shorewall6/shorewall6.conf
#
# For information about the settings in this file, type "man shorewall6.conf"
#
# Manpage also online at
# http://www.shorewall.net/manpages6/shorewall6.conf.html
###############################################################################
# S T A R T U P E N A B L E D
###############################################################################
STARTUP_ENABLED=No
###############################################################################
# V E R B O S I T Y
###############################################################################
VERBOSITY=1
###############################################################################
# P A G E R
###############################################################################
PAGER=
###############################################################################
# F I R E W A L L
###############################################################################
FIREWALL=
###############################################################################
# L O G G I N G
###############################################################################
LOG_LEVEL="info"
BLACKLIST_LOG_LEVEL=
INVALID_LOG_LEVEL=
LOG_BACKEND=
LOG_VERBOSITY=2
LOG_ZONE=Both
LOGALLNEW=
LOGFILE=/var/log/messages
LOGFORMAT="%s %s "
LOGLIMIT="s:1/sec:10"
LOGTAGONLY=No
MACLIST_LOG_LEVEL="$LOG_LEVEL"
RELATED_LOG_LEVEL=
RPFILTER_LOG_LEVEL="$LOG_LEVEL"
SFILTER_LOG_LEVEL="$LOG_LEVEL"
SMURF_LOG_LEVEL="$LOG_LEVEL"
STARTUP_LOG=/var/log/shorewall6-init.log
TCP_FLAGS_LOG_LEVEL="$LOG_LEVEL"
UNTRACKED_LOG_LEVEL=
###############################################################################
# L O C A T I O N O F F I L E S A N D D I R E C T O R I E S
###############################################################################
CONFIG_PATH=":${CONFDIR}/shorewall6:${SHAREDIR}/shorewall6:${SHAREDIR}/shorewall"
GEOIPDIR=/usr/share/xt_geoip/LE
IP6TABLES=
IP=
IPSET=
LOCKFILE=
MODULESDIR=
NFACCT=
PERL=/usr/bin/perl
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
RESTOREFILE=restore
SHOREWALL_SHELL=/bin/sh
SUBSYSLOCK=
TC=
###############################################################################
# D E F A U L T A C T I O N S / M A C R O S
###############################################################################
ACCEPT_DEFAULT="none"
BLACKLIST_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP),dropNotSyn:$LOG_LEVEL,dropInvalid:$LOG_LEVEL,DropDNSrep:$LOG_LEVEL"
DROP_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)"
NFQUEUE_DEFAULT="none"
QUEUE_DEFAULT="none"
REJECT_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)"
###############################################################################
# R S H / R C P C O M M A N D S
###############################################################################
RCP_COMMAND='scp ${files} ${root}@${system}:${destination}'
RSH_COMMAND='ssh ${root}@${system} ${command}'
###############################################################################
# F I R E W A L L O P T I O N S
###############################################################################
ACCOUNTING=Yes
ACCOUNTING_TABLE=filter
ADMINISABSENTMINDED=Yes
AUTOCOMMENT=Yes
AUTOHELPERS=Yes
AUTOMAKE=Yes
BALANCE_PROVIDERS=No
BASIC_FILTERS=No
BLACKLIST="NEW,INVALID,UNTRACKED"
CLAMPMSS=No
CLEAR_TC=No
COMPLETE=No
DEFER_DNS_RESOLUTION=Yes
DELETE_THEN_ADD=Yes
DONT_LOAD=
DYNAMIC_BLACKLIST=Yes
EXPAND_POLICIES=Yes
EXPORTMODULES=Yes
FASTACCEPT=No
FORWARD_CLEAR_MARK=
HELPERS=
IGNOREUNKNOWNVARIABLES=No
IMPLICIT_CONTINUE=No
IPSET_WARNINGS=Yes
IP_FORWARDING=Keep
KEEP_RT_TABLES=Yes
MACLIST_TABLE=filter
MACLIST_TTL=
MANGLE_ENABLED=Yes
MARK_IN_FORWARD_CHAIN=No
MINIUPNPD=No
MUTEX_TIMEOUT=60
OPTIMIZE=All
OPTIMIZE_ACCOUNTING=No
PERL_HASH_SEED=0
REJECT_ACTION=
RENAME_COMBINED=Yes
REQUIRE_INTERFACE=No
RESTART=restart
RESTORE_DEFAULT_ROUTE=Yes
RESTORE_ROUTEMARKS=Yes
SAVE_IPSETS=No
TC_ENABLED=Shared
TC_EXPERT=No
TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2"
TRACK_PROVIDERS=Yes
TRACK_RULES=No
USE_DEFAULT_RT=Yes
USE_NFLOG_SIZE=No
USE_PHYSICAL_NAMES=No
USE_RT_NAMES=No
VERBOSE_MESSAGES=Yes
WARNOLDCAPVERSION=Yes
WORKAROUNDS=No
ZERO_MARKS=No
ZONE2ZONE=-
###############################################################################
# P A C K E T D I S P O S I T I O N
###############################################################################
BLACKLIST_DISPOSITION=DROP
INVALID_DISPOSITION=CONTINUE
MACLIST_DISPOSITION=REJECT
RELATED_DISPOSITION=ACCEPT
SFILTER_DISPOSITION=DROP
RPFILTER_DISPOSITION=DROP
SMURF_DISPOSITION=DROP
TCP_FLAGS_DISPOSITION=DROP
UNTRACKED_DISPOSITION=CONTINUE
################################################################################
# P A C K E T M A R K L A Y O U T
################################################################################
TC_BITS=
PROVIDER_BITS=
PROVIDER_OFFSET=
MASK_BITS=
ZONE_BITS=0
shorewall6-5.2.3.4/Samples6/three-interfaces/params 0000664 0000000 0000000 00000001446 13531060406 020604 0 ustar root root #
# Shorewall - Sample Params File for three-interface configuration.
# Copyright (C) 2006-2017 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------------------------------------
# For information on entries in this file, type "man shorewall-params"
######################################################################################################################################################################################################
shorewall6-5.2.3.4/Samples6/two-interfaces/ 0000775 0000000 0000000 00000000000 13531077667 017114 5 ustar root root shorewall6-5.2.3.4/Samples6/two-interfaces/rules 0000664 0000000 0000000 00000002762 13531060406 020157 0 ustar root root #
# Shorewall6 version 5.2 - Sample Rules File for two-interface configuration.
# Copyright (C) 2006-2014 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------
# For information about entries in this file, type "man shorewall6-rules"
######################################################################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER
# PORT PORT(S) DEST LIMIT GROUP
?SECTION ALL
?SECTION ESTABLISHED
?SECTION RELATED
?SECTION INVALID
?SECTION UNTRACKED
?SECTION NEW
# Don't allow connection pickup from the net
#
Invalid(DROP) net all tcp
#
# Accept DNS connections from the firewall to the network
#
DNS(ACCEPT) $FW net
#
# Accept SSH connections from the local network for administration
#
SSH(ACCEPT) loc $FW
#
# Allow Ping from the local network
#
Ping(ACCEPT) loc $FW
#
# Drop Ping from the "bad" net zone.. and prevent your log from being flooded..
#
Ping(DROP) net $FW
ACCEPT $FW loc ipv6-icmp
ACCEPT $FW net ipv6-icmp
#
shorewall6-5.2.3.4/Samples6/two-interfaces/zones 0000664 0000000 0000000 00000001363 13531060406 020157 0 ustar root root #
# Shorewall6 version 5.2 - Sample Zones File for two-interface configuration.
# Copyright (C) 2006-2014 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------
# For information about entries in this file, type "man shorewall6-zones"
###############################################################################
#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
fw firewall
net ipv6
loc ipv6
shorewall6-5.2.3.4/Samples6/two-interfaces/stoppedrules 0000664 0000000 0000000 00000001406 13531060406 021550 0 ustar root root #
# Shorewall6 - Sample Stoppedrules File for two-interface configuration.
# Copyright (C) 2012-2017 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------
# For information about entries in this file, type "man shorewall-stoppedrules"
###############################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE
# PORT(S) PORT(S)
ACCEPT LOC_IF -
ACCEPT - LOC_IF
shorewall6-5.2.3.4/Samples6/two-interfaces/zones.annotated 0000664 0000000 0000000 00000021507 13531077667 022156 0 ustar root root #
# Shorewall6 version 5.2 - Sample Zones File for two-interface configuration.
# Copyright (C) 2006-2014 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------
# For information about entries in this file, type "man shorewall6-zones"
###############################################################################
#
# The /etc/shorewall/zones file declares your network zones. You specify the
# hosts in each zone through entries in /etc/shorewall/interfaces or /etc/
# shorewall/hosts.
#
# The columns in the file are as follows (where the column name is followed by a
# different name in parentheses, the different name is used in the alternate
# specification syntax).
#
# ZONE - zone[:parent-zone[,parent-zone]...]
#
# Name of the zone. Must start with a letter and consist of letters, digits
# or '_'. The names "all", "none", "any", "SOURCE" and "DEST" are reserved
# and may not be used as zone names. The maximum length of a zone name is
# determined by the setting of the LOGFORMAT option in shorewall.conf(5).
# With the default LOGFORMAT, zone names can be at most 5 characters long.
#
# The maximum length of an iptables log prefix is 29 bytes. As explained
# in shorewall.conf (5), the legacy default LOGPREFIX formatting string
# is “Shorewall:%s:%s:” where the first %s is replaced by the chain name
# and the second is replaced by the disposition.
#
# ☆ The "Shorewall:%s:%s:" formatting string has 12 fixed characters
# ("Shorewall" and three colons).
#
# ☆ The longest of the standard dispositions are ACCEPT and REJECT
# which have 6 characters each.
#
# ☆ The canonical name for the chain containing the rules for traffic
# going from zone 1 to zone 2 is "2" or "-
# ".
#
# ☆ So if M is the maximum zone name length, such chains can have
# length 2*M + 1.
#
# 12 + 6 + 2*M + 1 = 29 which reduces to
# 2*M = 29 - 12 - 6 - 1 = 10 or
# M = 5
#
# In Shorewall 5.1.0, the LOGFORMAT in the default and sample
# shorewall.conf files was changed to "%s:%s ".
#
# ☆ That formatting string has 2 fixed characters (":" and a space).
#
# ☆ So the maximum zone name length M is calculated as:
#
# 2 + 6 + 2*M + 1 = 29
# 2M = 29 - 2 - 6 - 1 = 20
# M = 10
#
# The order in which Shorewall matches addresses from packets to zones is
# determined by the order of zone declarations. Where a zone is nested in one
# or more other zones, you may either ensure that the nested zone precedes
# its parents in this file, or you may follow the (sub)zone name by ":" and a
# comma-separated list of the parent zones. The parent zones must have been
# declared in earlier records in this file. See shorewall-nesting(5) for
# additional information.
#
# Example:
#
# #ZONE TYPE OPTIONS IN OPTIONS OUT OPTIONS
# a ip
# b ip
# c:a,b ip
#
# Currently, Shorewall uses this information to reorder the zone list so that
# parent zones appear after their subzones in the list. The IMPLICIT_CONTINUE
# option in shorewall.conf(5) can also create implicit CONTINUE policies to/
# from the subzone.
#
# Where an ipsec zone is explicitly included as a child of an ip zone, the
# ruleset allows CONTINUE policies (explicit or implicit) to work as
# expected.
#
# In the future, Shorewall may make additional use of nesting information.
#
# TYPE
#
# ip
#
# This is the standard Shorewall zone type and is the default if you
# leave this column empty or if you enter "-" in the column.
# Communication with some zone hosts may be encrypted. Encrypted hosts
# are designated using the 'ipsec' option in shorewall-hosts(5). For
# clarity, this zone type may be specified as ipv4 in IPv4 configurations
# and ipv6 in IPv6 configurations.
#
# ipsec
#
# Communication with all zone hosts is encrypted. Your kernel and
# iptables must include policy match support. For clarity, this zone type
# may be specified as ipsec4 in IPv4 configurations and ipsec6 in IPv6
# configurations.
#
# firewall
#
# Designates the firewall itself. You must have exactly one 'firewall'
# zone. No options are permitted with a 'firewall' zone. The name that
# you enter in the ZONE column will be stored in the shell variable $FW
# which you may use in other configuration files to designate the
# firewall zone.
#
# bport
#
# The zone is associated with one or more ports on a single bridge. For
# clarity, this zone type may be specified as bport4 in IPv4
# configurations and bport6 in IPv6 configurations.
#
# vserver
#
# Added in Shorewall 4.4.11 Beta 2 - A zone composed of Linux-vserver
# guests. The zone contents must be defined in shorewall-hosts (5).
#
# Vserver zones are implicitly handled as subzones of the firewall zone.
#
# loopback
#
# Added in Shorewall 4.5.17.
#
# Normally, Shorewall treats the loopback interface (lo) in the following
# way:
#
# ☆ By default, all traffic through the interface is ACCEPTed.
#
# ☆ If a $FW -> $FW policy is defined or $FW -> $FW rules are defined,
# they are placed in a chain named ${FW}2${F2} or ${FW}-${FW} (e.g.,
# 'fw2fw' or 'fw-fw' ) depending on the ZONE2ZONE setting in
# shorewall.conf(5).
#
# ☆ $FW -> $FW traffic is only filtered in the OUTPUT chain.
#
# By defining a loopback zone and associating it with the loopback
# interface in shorewall-interfaces(5), you can effect a slightly
# different model. Suppose that the loopback zone name is 'local'; then:
#
# ☆ Both $FW -> local and local -> $FW chains are created.
#
# ☆ The $FW -> local and local -> $FW policies may be different.
#
# ☆ Both $FW -> local and local -> $FW rules may be specified.
#
# Rules to/from the loopback zone and any zone other than the firewall
# zone are ignored with a warning.
#
# loopback zones may be nested within other loopback zones.
#
# local
#
# Added in Shorewall 4.5.17. local is the same as ipv4 with the exception
# that the zone is only accessible from the firewall and vserver zones.
#
# OPTIONS, IN OPTIONS and OUT OPTIONS (options, in_options, out_options) - [
# option[,option]...]
#
# A comma-separated list of options. With the exception of the mss and
# blacklist options, these only apply to TYPE ipsec zones.
#
# dynamic_shared
#
# Added in Shorewall 4.5.9. May only be specified in the OPTIONS column
# and indicates that only a single ipset should be created for this zone
# if it has multiple dynamic entries in shorewall-hosts(5). Without this
# option, a separate ipset is created for each interface.
#
# reqid=number
#
# where number is specified using setkey(8) using the 'unique:number
# option for the SPD level.
#
# spi=
#
# where number is the SPI of the SA used to encrypt/decrypt packets.
#
# proto=ah|esp|ipcomp
#
# IPSEC Encapsulation Protocol
#
# mss=number
#
# sets the MSS field in TCP packets. If you supply this option, you
# should also set FASTACCEPT=No in shorewall.conf(5) to insure that both
# the SYN and SYN,ACK packets have their MSS field adjusted.
#
# mode=transport|tunnel
#
# IPSEC mode
#
# 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
#
# 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 "-".
#
###############################################################################
#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
fw firewall
net ipv6
loc ipv6
shorewall6-5.2.3.4/Samples6/two-interfaces/interfaces.annotated 0000664 0000000 0000000 00000061664 13531077664 023150 0 ustar root root #
# Shorewall6 - Sample Interfaces File for two-interface configuration.
# Copyright (C) 2006-2017 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------
# For information about entries in this file, type "man shorewall6-interfaces"
###############################################################################
#
# The interfaces file serves to define the firewall's network interfaces to
# Shorewall. The order of entries in this file is not significant in determining
# zone composition.
#
# Beginning with Shorewall 4.5.3, the interfaces file supports two different
# formats:
#
# FORMAT 1 (default - deprecated)
#
# There is a BROADCAST column which can be used to specify the broadcast
# address associated with the interface.
#
# FORMAT 2
#
# The BROADCAST column is omitted.
#
# The format is specified by a line as follows:
#
# ?FORMAT {1|2}
#
# The columns in the file are as follows.
#
# ZONE - zone-name
#
# Zone for this interface. Must match the name of a zone declared in /etc/
# shorewall/zones. You may not list the firewall zone in this column.
#
# If the interface serves multiple zones that will be defined in the
# shorewall-hosts(5) file, you should place "-" in this column.
#
# If there are multiple interfaces to the same zone, you must list them in
# separate entries.
#
# Example:
#
# #ZONE INTERFACE BROADCAST
# loc eth1 -
# loc eth2 -
#
# INTERFACE - interface[:port]
#
# Logical name of interface. Each interface may be listed only once in this
# file. You may NOT specify the name of a "virtual" interface (e.g., eth0:0)
# here; see http://www.shorewall.net/FAQ.htm#faq18. If the physical option is
# not specified, then the logical name is also the name of the actual
# interface.
#
# You may use wildcards here by specifying a prefix followed by the plus sign
# ("+"). For example, if you want to make an entry that applies to all PPP
# interfaces, use 'ppp+'; that would match ppp0, ppp1, ppp2, …
#
# When using Shorewall versions before 4.1.4, care must be exercised when
# using wildcards where there is another zone that uses a matching specific
# interface. See shorewall-nesting(5) for a discussion of this problem.
#
# Shorewall allows '+' as an interface name, but that usage is deprecated. A
# better approach is to specify 'physical=+' in the OPTIONS column (see
# below).
#
# There is no need to define the loopback interface (lo) in this file.
#
# If a port is given, then the interface must have been defined previously
# with the bridge option. The OPTIONS column may not contain the following
# options when a port is given.
#
# arp_filter
# arp_ignore
# bridge
# log_martians
# mss
# optional
# proxyarp
# required
# routefilter
# sourceroute
# upnp
# wait
#
# Beginning with Shorewall 4.5.17, if you specify a zone for the 'lo'
# interface, then that zone must be defined as type local in shorewall6-zones
# (5).
#
# BROADCAST (Optional) - {-|detect|address[,address]...}
#
# Only available if FORMAT 1.
#
# If you use the special value detect, Shorewall will detect the broadcast
# address(es) for you if your iptables and kernel include Address Type Match
# support.
#
# If your iptables and/or kernel lack Address Type Match support then you may
# list the broadcast address(es) for the network(s) to which the interface
# belongs. For P-T-P interfaces, this column is left blank. If the interface
# has multiple addresses on multiple subnets then list the broadcast
# addresses as a comma-separated list.
#
# If you don't want to give a value for this column but you want to enter a
# value in the OPTIONS column, enter - in this column.
#
# OPTIONS (Optional) - [option[,option]...]
#
# A comma-separated list of options from the following list. The order in
# which you list the options is not significant but the list should have no
# embedded white-space.
#
# accept_ra[={0|1|2}]
#
# IPv6 only; added in Shorewall 4.5.16. Values are:
#
# 0
#
# Do not accept Router Advertisements.
#
# 1
#
# Accept Route Advertisements if forwarding is disabled.
#
# 2
#
# Overrule forwarding behavior. Accept Route Advertisements even if
# forwarding is enabled.
#
# If the option is specified without a value, then the value 1 is
# assumed.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# arp_filter[={0|1}]
#
# IPv4 only. If specified, this interface will only respond to ARP
# who-has requests for IP addresses configured on the interface. If not
# specified, the interface can respond to ARP who-has requests for IP
# addresses on any of the firewall's interface. The interface must be up
# when Shorewall is started.
#
# Only those interfaces with the arp_filter option will have their
# setting changed; the value assigned to the setting will be the value
# specified (if any) or 1 if no value is given.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# arp_ignore[=number]
#
# IPv4 only. If specified, this interface will respond to arp requests
# based on the value of number (defaults to 1).
#
# 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 the sender's IP address is part from same
# subnet on this interface's address
#
# 3 - do not reply for local addresses configured with scope host, only
# resolutions for global and link
#
# 4-7 - reserved
#
# 8 - do not reply for all local addresses
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# Warning
#
# Do not specify arp_ignore for any interface involved in Proxy ARP.
#
# blacklist
#
# Checks packets arriving on this interface against the
# shorewall-blacklist(5) file.
#
# Beginning with Shorewall 4.4.13:
#
# ☆ If a zone is given in the ZONES column, then the behavior is as if
# blacklist had been specified in the IN_OPTIONS column of
# shorewall-zones(5).
#
# ☆ Otherwise, the option is ignored with a warning:
#
# WARNING: The 'blacklist' option is ignored on multi-zone
# interfaces
#
# bridge
#
# Designates the interface as a bridge. Beginning with Shorewall 4.4.7,
# setting this option also sets routeback.
#
# Note
#
# If you have a bridge that you don't intend to define bport zones on,
# then it is best to omit this option and simply specify routeback.
#
# dbl={none|src|dst|src-dst}
#
# Added in Shorewall 5.0.10. This option defined whether or not dynamic
# blacklisting is applied to packets entering the firewall through this
# interface and whether the source address and/or destination address is
# to be compared against the ipset-based dynamic blacklist
# (DYNAMIC_BLACKLIST=ipset... in shorewall.conf(5)). The default is
# determine by the setting of DYNAMIC_BLACKLIST:
#
# DYNAMIC_BLACKLIST=No
#
# Default is none (e.g., no dynamic blacklist checking).
#
# DYNAMIC_BLACKLIST=Yes
#
# Default is src (e.g., the source IP address is checked).
#
# DYNAMIC_BLACKLIST=ipset[-only]
#
# Default is src.
#
# DYNAMIC_BLACKLIST=ipset[-only],src-dst...
#
# Default is src-dst (e.g., the source IP addresses in checked
# against the ipset on input and the destination IP address is
# checked against the ipset on packets originating from the firewall
# and leaving through this interface).
#
# The normal setting for this option will be dst or none for internal
# interfaces and src or src-dst for Internet-facing interfaces.
#
# destonly
#
# Added in Shorewall 4.5.17. Causes the compiler to omit rules to handle
# traffic from this interface.
#
# dhcp
#
# Specify this option when any of the following are true:
#
# 1. the interface gets its IP address via DHCP
#
# 2. the interface is used by a DHCP server running on the firewall
#
# 3. the interface has a static IP but is on a LAN segment with lots of
# DHCP clients.
#
# 4. the interface is a simple bridge with a DHCP server on one port and
# DHCP clients on another port.
#
# Note
#
# If you use Shorewall-perl for firewall/bridging, then you need to
# include DHCP-specific rules in shorewall-rules(5). DHCP uses UDP
# ports 67 and 68.
#
# This option allows DHCP datagrams to enter and leave the interface.
#
# forward[={0|1}]
#
# IPv6 only Sets the /proc/sys/net/ipv6/conf/interface/forwarding option
# to the specified value. If no value is supplied, then 1 is assumed.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# ignore[=1]
#
# When specified, causes the generated script to ignore up/down events
# from Shorewall-init for this device. Additionally, the option exempts
# the interface from hairpin filtering. When '=1' is omitted, the ZONE
# column must contain '-' and ignore must be the only OPTION.
#
# Beginning with Shorewall 4.5.5, may be specified as 'ignore=1' which
# only causes the generated script to ignore up/down events from
# Shorewall-init; hairpin filtering is still applied. In this case, the
# above restrictions on the ZONE and OPTIONS columns are lifted.
#
# loopback
#
# Added in Shorewall 4.6.6. Designates the interface as the loopback
# interface. This option is assumed if the interface's physical name is
# 'lo'. Only one interface man have the loopback option specified.
#
# logmartians[={0|1}]
#
# IPv4 only. Turn on kernel martian logging (logging of packets with
# impossible source addresses. It is strongly suggested that if you set
# routefilter on an interface that you also set logmartians. Even if you
# do not specify the routefilter option, it is a good idea to specify
# logmartians because your distribution may have enabled route filtering
# without you knowing it.
#
# Only those interfaces with the logmartians option will have their
# setting changed; the value assigned to the setting will be the value
# specified (if any) or 1 if no value is given.
#
# To find out if route filtering is set on a given interface, check the
# contents of /proc/sys/net/ipv4/conf/interface/rp_filter - a non-zero
# value indicates that route filtering is enabled.
#
# Example:
#
# teastep@lists:~$ cat /proc/sys/net/ipv4/conf/eth0/rp_filter
# 1
# teastep@lists:~$
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# This option may also be enabled globally in the shorewall.conf(5)
# file.
#
# maclist
#
# Connection requests from this interface are compared against the
# contents of shorewall-maclist(5). If this option is specified, the
# interface must be an Ethernet NIC and must be up before Shorewall is
# started.
#
# mss=number
#
# Added in Shorewall 4.0.3. Causes forwarded TCP SYN packets entering or
# leaving on this interface to have their MSS field set to the specified
# number.
#
# nets=(net[,...])
#
# Limit the zone named in the ZONE column to only the listed networks.
# The parentheses may be omitted if only a single net is given (e.g.,
# nets=192.168.1.0/24). Limited broadcast to the zone is supported.
# Beginning with Shorewall 4.4.1, multicast traffic to the zone is also
# supported.
#
# nets=dynamic
#
# Defines the zone as dynamic. Requires ipset match support in your
# iptables and kernel. See http://www.shorewall.net/Dynamic.html for
# further information.
#
# nodbl
#
# Added in Shorewall 5.0.8. When specified, dynamic blacklisting is
# disabled on the interface. Beginning with Shorewall 5.0.10, nodbl is
# equivalent to dbl=none.
#
# nosmurfs
#
# IPv4 only. Filter packets for smurfs (packets with a broadcast address
# as the source).
#
# Smurfs will be optionally logged based on the setting of
# SMURF_LOG_LEVEL in shorewall.conf(5). After logging, the packets are
# dropped.
#
# optional
#
# When optional is specified for an interface, Shorewall will be silent
# when:
#
# ☆ a /proc/sys/net/ipv[46]/conf/ entry for the interface cannot be
# modified (including for proxy ARP or proxy NDP).
#
# ☆ The first address of the interface cannot be obtained.
#
# May not be specified with required.
#
# physical=name
#
# Added in Shorewall 4.4.4. When specified, the interface or port name in
# the INTERFACE column is a logical name that refers to the name given in
# this option. It is useful when you want to specify the same wildcard
# port name on two or more bridges. See http://www.shorewall.net/
# bridge-Shorewall-perl.html#Multiple.
#
# If the interface name is a wildcard name (ends with '+'), then the
# physical name must also end in '+'. The physical name may end in '+'
# (or be exactly '+') when the interface name is not a wildcard name.
#
# If physical is not specified, then it's value defaults to the interface
# name.
#
# proxyarp[={0|1}]
#
# IPv4 only. Sets /proc/sys/net/ipv4/conf/interface/proxy_arp. Do NOT use
# this option if you are employing Proxy ARP through entries in
# shorewall-proxyarp(5). This option is intended solely for use with
# Proxy ARP sub-networking as described at: http://tldp.org/HOWTO/
# Proxy-ARP-Subnet/index.html.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# Only those interfaces with the proxyarp option will have their setting
# changed; the value assigned to the setting will be the value specified
# (if any) or 1 if no value is given.
#
# proxyndp[={0|1}]
#
# IPv6 only. Sets /proc/sys/net/ipv6/conf/interface/proxy_ndp.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# Only those interfaces with the proxyndp option will have their setting
# changed; the value assigned to the setting will be the value specified
# (if any) or 1 if no value is given.
#
# required
#
# Added in Shorewall 4.4.10. If this option is set, the firewall will
# fail to start if the interface is not usable. May not be specified
# together with optional.
#
# routeback[={0|1}]
#
# If specified, indicates that Shorewall should include rules that allow
# traffic arriving on this interface to be routed back out that same
# interface. This option is also required when you have used a wildcard
# in the INTERFACE column if you want to allow traffic between the
# interfaces that match the wildcard.
#
# Beginning with Shorewall 4.4.20, if you specify this option, then you
# should also specify either sfilter (see below) or routefilter on all
# interfaces (see below).
#
# Beginning with Shorewall 4.5.18, you may specify this option to
# explicitly reset (e.g., routeback=0). This can be used to override
# Shorewall's default setting for bridge devices which is routeback=1.
#
# routefilter[={0|1|2}]
#
# IPv4 only. Turn on kernel route filtering for this interface
# (anti-spoofing measure).
#
# Only those interfaces with the routefilter option will have their
# setting changes; the value assigned to the setting will be the value
# specified (if any) or 1 if no value is given.
#
# The value 2 is only available with Shorewall 4.4.5.1 and later when the
# kernel version is 2.6.31 or later. It specifies a loose form of reverse
# path filtering.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# This option can also be enabled globally via the ROUTE_FILTER option in
# the shorewall.conf(5) file.
#
# Important
#
# If ROUTE_FILTER=Yes in shorewall.conf(5), or if your distribution sets
# net.ipv4.conf.all.rp_filter=1 in /etc/sysctl.conf, then setting
# routefilter=0 in an interface entry will not disable route filtering on
# that interface! The effective setting for an interface is the maximum
# of the contents of /proc/sys/net/ipv4/conf/all/rp_filter and the
# routefilter setting specified in this file (/proc/sys/net/ipv4/conf/
# interface/rp_filter).
#
# Note
#
# There are certain cases where routefilter cannot be used on an
# interface:
#
# ☆ If USE_DEFAULT_RT=Yes in shorewall.conf(5) and the interface is
# listed in shorewall-providers(5).
#
# ☆ If there is an entry for the interface in shorewall-providers(5)
# that doesn't specify the balance option.
#
# ☆ If IPSEC is used to allow a road-warrior to have a local address,
# then any interface through which the road-warrior might connect
# cannot specify routefilter.
#
# Beginning with Shorewall 5.1.1, when routefilter is set to a non-zero
# value, the logmartians option is also implicitly set. If you actually
# want route filtering without logging, then you must also specify
# logmartians=0 after routefilter.
#
# rpfilter
#
# Added in Shorewall 4.5.7. This is an anti-spoofing measure that
# requires the 'RPFilter Match' capability in your iptables and kernel.
# It provides a more efficient alternative to the sfilter option below.
# It performs a function similar to routefilter (see above) but works
# with Multi-ISP configurations that do not use balanced routes.
#
# sfilter=(net[,...])
#
# Added in Shorewall 4.4.20. This option provides an anti-spoofing
# alternative to routefilter on interfaces where that option cannot be
# used, but where the routeback option is required (on a bridge, for
# example). On these interfaces, sfilter should list those local networks
# that are connected to the firewall through other interfaces.
#
# sourceroute[={0|1}]
#
# If this option is not specified for an interface, then source-routed
# packets will not be accepted from that interface unless it has been
# explicitly enabled via sysconf. Only set this option to 1 (enable
# source routing) if you know what you are doing. This might represent a
# security risk and is usually unneeded.
#
# Only those interfaces with the sourceroute option will have their
# setting changed; the value assigned to the setting will be the value
# specified (if any) or 1 if no value is given.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# tcpflags[={0|1}]
#
# Packets arriving on this interface are checked for certain illegal
# combinations of TCP flags. Packets found to have such a combination of
# flags are handled according to the setting of TCP_FLAGS_DISPOSITION
# after having been logged according to the setting of
# TCP_FLAGS_LOG_LEVEL.
#
# Beginning with Shorewall 4.6.0, tcpflags=1 is the default. To disable
# this option, specify tcpflags=0.
#
# unmanaged
#
# Added in Shorewall 4.5.18. Causes all traffic between the firewall and
# hosts on the interface to be accepted. When this option is given:
#
# ☆ The ZONE column must contain '-'.
#
# ☆ Only the following other options are allowed with unmanaged:
#
# arp_filter
# arp_ignore
# ignore
# routefilter
# optional
# physical
# routefilter
# proxyarp
# proxyudp
# sourceroute
#
# upnp
#
# Incoming requests from this interface may be remapped via UPNP (upnpd).
# See http://www.shorewall.net/UPnP.html. Supported in IPv4 and in IPv6
# in Shorewall 5.1.4 and later.
#
# upnpclient
#
# This option is intended for laptop users who always run Shorewall on
# their system yet need to run UPnP-enabled client apps such as
# Transmission (BitTorrent client). The option causes Shorewall to detect
# the default gateway through the interface and to accept UDP packets
# from that gateway. Note that, like all aspects of UPnP, this is a
# security hole so use this option at your own risk. Supported in IPv4
# and in IPv6 in Shorewall 5.1.4 and later.
#
# wait=seconds
#
# Added in Shorewall 4.4.10. Causes the generated script to wait up to
# seconds seconds for the interface to become usable before applying the
# required or optional options.
#
# Example
#
# IPv4 Example 1:
#
# Suppose you have eth0 connected to a DSL modem and eth1 connected to your
# local network and that your local subnet is 192.168.1.0/24. The interface
# gets its IP address via DHCP from subnet 206.191.149.192/27. You have a DMZ
# with subnet 192.168.2.0/24 using eth2. Your iptables and/or kernel do not
# support "Address Type Match" and you prefer to specify broadcast addresses
# explicitly rather than having Shorewall detect them.
#
# Your entries for this setup would look like:
#
# ?FORMAT 1
# #ZONE INTERFACE BROADCAST OPTIONS
# net eth0 206.191.149.223 dhcp
# loc eth1 192.168.1.255
# dmz eth2 192.168.2.255
#
# Example 2:
#
# The same configuration without specifying broadcast addresses is:
#
# ?FORMAT 2
# #ZONE INTERFACE OPTIONS
# net eth0 dhcp
# loc eth1
# dmz eth2
#
# Example 3:
#
# You have a simple dial-in system with no Ethernet connections.
#
# ?FORMAT 2
# #ZONE INTERFACE OPTIONS
# net ppp0 -
#
# Example 4 (Shorewall 4.4.9 and later):
#
# You have a bridge with no IP address and you want to allow traffic through
# the bridge.
#
# ?FORMAT 2
# #ZONE INTERFACE OPTIONS
# - br0 bridge
#
###############################################################################
?FORMAT 2
###############################################################################
#ZONE INTERFACE OPTIONS
net NET_IF tcpflags,forward=1,sourceroute=0,physical=eth0
loc LOC_IF tcpflags,forward=1,physical=eth1
shorewall6-5.2.3.4/Samples6/two-interfaces/policy.annotated 0000664 0000000 0000000 00000025560 13531077665 022320 0 ustar root root #
# Shorewall6 version 4 - Sample Policy File for two-interface configuration.
# Copyright (C) 2006-2014 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------
# For information about entries in this file, type "man shorewall6-policy"
###############################################################################
#
# This file defines the high-level policy for connections between zones defined
# in shorewall-zones(5).
#
# Important
#
# The order of entries in this file is important
#
# This file determines what to do with a new connection request if we don't get a
# match from the shorewall-blrules(5) or shorewall-rules(5) files. For each
# source/destination pair, the file is processed in order until a match is found
# ("all" will match any source or destination).
#
# Important
#
# Intra-zone policies are pre-defined
#
# For $FW and for all of the zones defined in shorewall-zones(5), the POLICY for
# connections from the zone to itself is ACCEPT (with no logging or TCP
# connection rate limiting) but may be overridden by an entry in this file. The
# overriding entry must be explicit (specifying the zone name in both SOURCE and
# DEST) or it must use "all+" (Shorewall 4.5.17 or later).
#
# Similarly, if you have IMPLICIT_CONTINUE=Yes in shorewall.conf(5), then the
# implicit policy to/from any sub-zone is CONTINUE. These implicit CONTINUE
# policies may also be overridden by an explicit entry in this file.
#
# The columns in the file are as follows (where the column name is followed by a
# different name in parentheses, the different name is used in the alternate
# specification syntax).
#
# SOURCE - zone[,...[+]]|$FW|all[+][!ezone[,...]]
#
# Source zone. Must be the name of a zone defined in shorewall-zones(5), $FW,
# "all" or "all+".
#
# Support for all+ was added in Shorewall 4.5.17. all does not override the
# implicit intra-zone ACCEPT policy while all+ does.
#
# Beginning with Shorewall 5.0.12, multiple zones may be listed separated by
# commas. As above, if '+' is specified after two or more zone names, then
# the policy overrides the implicit intra-zone ACCEPT policy if the same zone
# appears in both the SOURCE and DEST columns.
#
# Beginning with Shorewall 5.2.3, a comma-separated list of excluded zones
# preceded by "!" may follow all or all+.
#
# DEST - zone[,...[+]]|$FW|all[+][!ezone[,...]]
#
# Destination zone. Must be the name of a zone defined in shorewall-zones(5),
# $FW, "all" or "all+". If the DEST is a bport zone, then the SOURCE must be
# "all", "all+", another bport zone associated with the same bridge, or it
# must be an ipv4 zone that is associated with only the same bridge.
#
# Support for "all+" was added in Shorewall 4.5.17. "all" does not override
# the implicit intra-zone ACCEPT policy while "all+" does.
#
# Beginning with Shorewall 5.0.12, multiple zones may be listed separated by
# commas. As above, if '+' is specified after two or more zone names, then
# the policy overrides the implicit intra-zone ACCEPT policy if the same zone
# appears in both the SOURCE and DEST columns.
#
# Beginning with Shorewall 5.2.3, a comma-separated list of excluded zones
# preceded by "!" may follow all or all+.
#
# POLICY - {ACCEPT|DROP|REJECT|BLACKLIST|CONTINUE|QUEUE|NFQUEUE[(queuenumber1[:
# queuenumber2])]|NONE}[:{[+]policy-action[:level][,...]|None}]
#
# Policy if no match from the rules file is found.
#
# If the policy is neither CONTINUE nor NONE then the policy may be followed
# by ":" and one of the following:
#
# a. The word "None" or "none". This causes any default action defined in
# shorewall.conf(5) to be omitted for this policy.
#
# b. The name of an action with optional parameters enclosed in parentheses.
# The action will be invoked before the policy is enforced.
#
# Actions can have parameters specified.
#
# Beginning with Shorewall 4.5.10, the action name can be followed optionally
# by a colon and a log level. The level will be applied to each rule in the
# action or body that does not already have a log level.
#
# Beginning with Shorewall 5.1.2, multiple action[:level] specification may
# be listeded, separated by commas. The actions are invoked in the order
# listed. Also beginning with Shorewall 5.1.2, the policy-action list can be
# prefixed with a plus sign ("+") indicating that the listed actions are in
# addition to those listed in the related _DEFAULT setting in shorewall.conf
# (5).
#
# Possible policies are:
#
# ACCEPT
#
# Accept the connection.
#
# DROP
#
# Ignore the connection request.
#
# REJECT
#
# For TCP, send RST. For all other, send an "unreachable" ICMP.
#
# BLACKLIST
#
# Added in Shorewall 5.1.1 and requires that the DYNAMIC_BLACKLIST
# setting in shorewall.conf(5) specifies ipset-based dynamic
# blacklisting. The SOURCE IP address is added to the blacklist ipset and
# the connection request is ignored.
#
# QUEUE
#
# Queue the request for a user-space application such as Snort-inline.
#
# NFQUEUE
#
# Queue the request for a user-space application using the
# nfnetlink_queue mechanism. If a queuenumber1 is not given, queue zero
# (0) is assumed. Beginning with Shorewall 4.6.10, a second queue number
# (queuenumber2) may be given. This specifies a range of queues to use.
# Packets are then balanced across the given queues. This is useful for
# multicore systems: start multiple instances of the userspace program on
# queues x, x+1, .. x+n and use "x:x+n". Packets belonging to the same
# connection are put into the same nfqueue.
#
# CONTINUE
#
# Pass the connection request past any other rules that it might also
# match (where the source or destination zone in those rules is a
# superset of the SOURCE or DEST in this policy). See shorewall-nesting
# (5) for additional information.
#
# NONE
#
# Assume that there will never be any packets from this SOURCE to this
# DEST. Shorewall will not create any infrastructure to handle such
# packets and you may not have any rules with this SOURCE and DEST in the
# /etc/shorewall/rules file. If such a packet is received, the result is
# undefined. NONE may not be used if the SOURCE or DEST columns contain
# the firewall zone ($FW) or "all".
#
# LOGLEVEL (loglevel) - [log-level|ULOG|NFLOG]
#
# Optional - if supplied, each connection handled under the default POLICY is
# logged at that level. If not supplied, no log message is generated. See
# syslog.conf(5) for a description of log levels.
#
# You may also specify ULOG or NFLOG (must be in upper case). This will log
# to the ULOG or NFLOG target and will send to a separate log through use of
# ulogd (http://www.netfilter.org/projects/ulogd/index.html).
#
# For a description of logging, see shorewall-logging(5).
#
# If you don't want to log but need to specify the following column, place
# "-" here.
#
# RATE (rate) - [-|limit]
#
# where limit is one of:
#
# [-|[{s|d}[/vlsm]:[[name][(ht-buckets,ht-max)]:]]]rate/{sec|min|hour|day}[:
# burst]
# [name1:]rate1/{sec|min|hour|day}[:burst1],[name2:]rate2/{sec|min|hour|day}
# [:burst2]
#
# If passed, specifies the maximum TCP connection rate and the size of an
# acceptable burst. If not specified, TCP connections are not limited. If the
# burst parameter is omitted, a value of 5 is assumed.
#
# When s: or d: is specified, the rate applies per source IP address or per
# destination IP address respectively. The name may be chosen by the user and
# specifies a hash table to be used to count matching connections. If not
# give, the name shorewall is assumed. Where more than one POLICY or rule
# specifies the same name, the connections counts for the policies are
# aggregated and the individual rates apply to the aggregated count.
# Beginning with Shorewall 5.2.1, the s or d may be followed by a slash ("/")
# and an integer vlsm. When a vlsm is specified, all source or destination
# addresses encountered will be grouped according to the given prefix length
# and the so-created subnet will be subject to the rate limit.
#
# Beginning with Shorewall 4.6.5, two limits may be specified, separated by a
# comma. In this case, the first limit (name1, rate1, burst1) specifies the
# per-source IP limit and the second limit specifies the per-destination IP
# limit.
#
# Example: client:10/sec:20,:60/sec:100
#
# Beginning with Shorewall 5.2.1, the table name, if any, may be followed by
# two integers separated by commas and enclosed in parentheses. The first
# integer (ht-buckets) specifies the number of buckets in the generated hash
# table. The second integer (ht-max) specifies the maximum number of entries
# in the hash table.
#
# Example: s:client(1024,65536):10/sec
#
# CONNLIMIT - limit[:mask]
#
# May be used to limit the number of simultaneous connections from each
# individual host to limit connections. While the limit is only checked on
# connections to which this policy could apply, the number of current
# connections is calculated over all current connections from the SOURCE
# host. By default, the limit is applied to each host individually but can be
# made to apply to networks of hosts by specifying a mask. The mask specifies
# the width of a VLSM mask to be applied to the source address; the number of
# current connections is then taken over all hosts in the subnet
# source-address/mask.
#
# Example
#
# a. All connections from the local network to the internet are allowed
#
# b. All connections from the internet are ignored but logged at syslog level
# KERNEL.INFO.
#
# c. All other connection requests are rejected and logged at level KERNEL.INFO.
#
# #SOURCE DEST POLICY LOG BURST:LIMIT
# # LEVEL
# loc net ACCEPT
# net all DROP info
# #
# # THE FOLLOWING POLICY MUST BE LAST
# #
# all all REJECT info
#
###############################################################################
#SOURCE DEST POLICY LOGLEVEL RATE CONNLIMIT
loc net ACCEPT
net all DROP $LOG_LEVEL
all all REJECT $LOG_LEVEL
shorewall6-5.2.3.4/Samples6/two-interfaces/README.txt 0000664 0000000 0000000 00000002160 13531060406 020570 0 ustar root root For instructions on using these sample configurations, please see
http://www.shorewall.net/two-interface.htm
Shorewall Samples
Copyright (C) 2006-2014 by the following authors:
Thomas M. Eastep
Paul D. Gear
Cristian Rodriguez
Francesca Smith
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
02110-1301 USA
Sample files are licensed under the LGPL, please see the LICENSE file or
http://www.gnu.org/licenses/lgpl.html for more details.
shorewall6-5.2.3.4/Samples6/two-interfaces/rules.annotated 0000664 0000000 0000000 00000164452 13531077665 022157 0 ustar root root #
# Shorewall6 version 5.2 - Sample Rules File for two-interface configuration.
# Copyright (C) 2006-2014 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------
# For information about entries in this file, type "man shorewall6-rules"
######################################################################################################################################################################################################
#
# Entries in this file govern connection establishment by defining exceptions to
# the policies laid out in shorewall-policy(5). By default, subsequent requests
# and responses are automatically allowed using connection tracking. For any
# particular (source,dest) pair of zones, the rules are evaluated in the order in
# which they appear in this file and the first terminating match is the one that
# determines the disposition of the request. All rules are terminating except LOG
# and COUNT rules.
#
# Warning
#
# If you masquerade or use SNAT from a local system to the internet, you cannot
# use an ACCEPT rule to allow traffic from the internet to that system. You must
# use a DNAT rule instead.
#
# The rules file is divided into sections. Each section is introduced by a
# "Section Header" which is a line beginning with ?SECTION and followed by the
# section name.
#
# Sections are as follows and must appear in the order listed:
#
# ALL
#
# This section was added in Shorewall 4.4.23. Rules in this section are
# applied, regardless of the connection tracking state of the packet and are
# applied before rules in the other sections.
#
# ESTABLISHED
#
# Packets in the ESTABLISHED state are processed by rules in this section.
#
# The only ACTIONs allowed in this section are ACCEPT, DROP, REJECT, LOG,
# NFLOG, NFQUEUE and QUEUE
#
# There is an implicit ACCEPT rule inserted at the end of this section.
#
# RELATED
#
# Packets in the RELATED state are processed by rules in this section.
#
# The only ACTIONs allowed in this section are ACCEPT, DROP, REJECT, LOG,
# NFLOG, NFQUEUE and QUEUE
#
# There is an implicit rule added at the end of this section that invokes the
# RELATED_DISPOSITION (shorewall.conf(5)).
#
# INVALID
#
# Added in Shorewall 4.5.13. Packets in the INVALID state are processed by
# rules in this section.
#
# The only Actions allowed in this section are ACCEPT, DROP, REJECT, LOG,
# NFLOG, NFQUEUE and QUEUE.
#
# There is an implicit rule added at the end of this section that invokes the
# INVALID_DISPOSITION (shorewall.conf(5)).
#
# UNTRACKED
#
# Added in Shorewall 4.5.13. Packets in the UNTRACKED state are processed by
# rules in this section.
#
# The only Actions allowed in this section are ACCEPT, DROP, REJECT, LOG,
# NFLOG, NFQUEUE and QUEUE.
#
# There is an implicit rule added at the end of this section that invokes the
# UNTRACKED_DISPOSITION (shorewall.conf(5)).
#
# NEW
#
# Packets in the NEW state are processed by rules in this section. If the
# INVALID and/or UNTRACKED sections are empty or not included, then the
# packets in the corresponding state(s) are also processed in this section.
#
# Note
#
# If you are not familiar with Netfilter to the point where you are comfortable
# with the differences between the various connection tracking states, then it is
# suggested that you place all of your rules in the NEW section (That's after the
# line that reads ?SECTION NEW').
#
# Warning
#
# If you specify FASTACCEPT=Yes in shorewall.conf(5) then the ALL, ESTABLISHED
# and RELATED sections must be empty.
#
# An exception is made if you are running Shorewall 4.4.27 or later and you have
# specified a non-default value for RELATED_DISPOSITION or RELATED_LOG_LEVEL. In
# that case, you may have rules in the RELATED section of this file.
#
# You may omit any section that you don't need. If no Section Headers appear in
# the file then all rules are assumed to be in the NEW section.
#
# When defining rules that rewrite the destination IP address and/or port number
# (namely DNAT and REDIRECT rules), it is important to keep straight which
# columns in the file specify the packet before rewriting and which specify how
# the packet will look after rewriting.
#
# • The DEST column specifies the final destination for the packet after
# rewriting and can include the final IP address and/or port number.
#
# • The remaining columns specify characteristics of the packet before
# rewriting. In particular, the ORIGDEST column gives the original
# destination IP address of the packet and the DPORT column give the original
# destination port(s).
#
# The columns in the file are as follows (where the column name is followed by a
# different name in parentheses, the different name is used in the alternate
# specification syntax).
#
# ACTION - target[:{log-level|none}[!][:tag]]
#
# Specifies the action to be taken if the connection request matches the
# rule. target must be one of the following.
#
# ACCEPT
#
# Allow the connection request.
#
# ACCEPT+
#
# like ACCEPT but also excludes the connection from any subsequent
# matching DNAT[-] or REDIRECT[-] rules. Use with IPv6 requires Shorewall
# 4.5.14 or later.
#
# ACCEPT!
#
# like ACCEPT but exempts the rule from being suppressed by OPTIMIZE=1 in
# shorewall.conf(5).
#
# action
#
# The name of an action declared in shorewall-actions(5) or in /usr/share
# /shorewall[6]/actions.std.
#
# ADD(ipset:flags[:timeout])
#
# Added in Shorewall 4.4.12. Causes addresses and/or port numbers to be
# added to the named ipset. The flags specify the address or tuple to be
# added to the set and must match the type of ipset involved. For
# example, for an iphash ipset, either the SOURCE or DESTINATION address
# can be added using flags src or dst respectively (see the -A command in
# ipset (8)).
#
# Beginning with Shorewall 5.0.3, an optional timeout can be specified.
# This is the number of seconds that the new entry in the ipset is to
# remain valid and overrides any timeout specified when the ipset was
# created.
#
# ADD is non-terminating. Even if a packet matches the rule, it is passed
# on to the next rule.
#
# AUDIT[(accept|drop|reject)]
#
# Added in Shorewall 4.5.10. Audits the packet with the specified type;
# if the type is omitted, then drop is assumed. Require AUDIT_TARGET
# support in the kernel and iptables.
#
# A_ACCEPT, A_ACCEPT+ and A_ACCEPT!
#
# Added in Shorewall 4.4.20. Audited versions of ACCEPT, ACCEPT+ and
# ACCEPT! respectively. Require AUDIT_TARGET support in the kernel and
# iptables. A_ACCEPT+ with IPv6 requires Shorewall 4.5.14 or later.
#
# A_DROP and A_DROP!
#
# Added in Shorewall 4.4.20. Audited versions of DROP and DROP!
# respectively. Require AUDIT_TARGET support in the kernel and iptables.
#
# A_REJECT AND A_REJECT!
#
# Added in Shorewall 4.4.20. Audited versions of REJECT and REJECT!
# respectively. Require AUDIT_TARGET support in the kernel and iptables.
#
# ?COMMENT
#
# the rest of the line will be attached as a comment to the Netfilter
# rule(s) generated by the following entries. The comment will appear
# delimited by "/* ... */" in the output of "shorewall show ". To
# stop the comment from being attached to further rules, simply include ?
# COMMENT on a line by itself.
#
# CONMARK({mark})
#
# Added in Shorewall 5.0.7, CONNMARK is identical to MARK with the
# exception that the mark is assigned to connection to which the packet
# belongs is marked rather than to the packet itself.
#
# CONTINUE
#
# For experts only.
#
# Do not process any of the following rules for this (source
# zone,destination zone). If the source and/or destination IP address
# falls into a zone defined later in shorewall-zones(5) or in a parent
# zone of the source or destination zones, then this connection request
# will be passed to the rules defined for that (those) zone(s). See
# shorewall-nesting(5) for additional information.
#
# CONTINUE!
#
# like CONTINUE but exempts the rule from being suppressed by OPTIMIZE=1
# in shorewall.conf(5).
#
# COUNT
#
# Simply increment the rule's packet and byte count and pass the packet
# to the next rule.
#
# DEL(ipset:flags)
#
# Added in Shorewall 4.4.12. Causes an entry to be deleted from the named
# ipset. The flags specify the address or tuple to be deleted from the
# set and must match the type of ipset involved. For example, for an
# iphash ipset, either the SOURCE or DESTINATION address can be deleted
# using flags src or dst respectively (see the -D command in ipset (8)).
#
# DEL is non-terminating. Even if a packet matches the rule, it is passed
# on to the next rule.
#
# DNAT
#
# Forward the request to another system (and optionally another port).
# Use with IPv6 requires Shorewall 4.5.14 or later.
#
# DNAT-
#
# Advanced users only.
#
# Like DNAT but only generates the DNAT iptables rule and not the
# companion ACCEPT rule. Use with IPv6 requires Shorewall 4.5.14 or
# later.
#
# DROP
#
# Ignore the request.
#
# DROP!
#
# like DROP but exempts the rule from being suppressed by OPTIMIZE=1 in
# shorewall.conf(5).
#
# HELPER
#
# Added in Shorewall 4.5.7. This action requires that the HELPER column
# contains the name of the Netfilter helper to be associated with
# connections matching this connection. May only be specified in the NEW
# section and is useful for being able to specify a helper when the
# applicable policy is ACCEPT. No destination zone should be specified in
# HELPER rules.
#
# INLINE[(action)]
#
# Added in Shorewall 4.5.16. This action allows you to construct most of
# the rule yourself using iptables syntax. The part that you specify must
# follow two semicolons (';;') and is completely free-form. If the target
# of the rule (the part following 'j') is something that Shorewall
# supports in the ACTION column, then you may enclose it in parentheses
# (e.g., INLINE(ACCEPT)). Otherwise, you can include it after the
# semicolon(s). In this case, you must declare the target as a builtin
# action in shorewall-actions(5).
#
# Some considerations when using INLINE:
#
# ☆ The p, s, d, i, o, policy, and state match (state or conntrack
# --ctstate) matches will always appear in the front of the rule in
# that order.
#
# ☆ When multiple matches are specified, the compiler will keep them in
# the order in which they appear (excluding the above listed ones),
# but they will not necessarily be at the end of the generated rule.
# For example, if addresses are specified in the SOURCE and/or DEST
# columns, their generated matches will appear after those specified
# using ';;' or ';'.
#
# IPTABLES({iptables-target [option ...])
#
# IPv4 only. This action allows you to specify an iptables target with
# options (e.g., 'IPTABLES(MARK --set-xmark 0x01/0xff)'. If the
# iptables-target is not one recognized by Shorewall, the following error
# message will be issued:
#
# ERROR: Unknown target (iptables-target)
#
# This error message may be eliminated by adding the iptables-target as a
# builtin action in shorewall-actions(5).
#
# Important
#
# If you specify REJECT as the iptables-target, the target of the rule
# will be the iptables REJECT target and not Shorewall's builtin 'reject'
# chain which is used when REJECT (see below) is specified as the target
# in the ACTION column.
#
# IP6TABLES({ip6tables-target [option ...])
#
# IPv6 only. This action allows you to specify an ip6tables target with
# options (e.g., 'IPTABLES(MARK --set-xmark 0x01/0xff)'. If the
# ip6tables-target is not one recognized by Shorewall, the following
# error message will be issued:
#
# ERROR: Unknown target (ip6tables-target)
#
# This error message may be eliminated by adding the ip6tables-target as
# a builtin action in shorewall-actions(5).
#
# Important
#
# If you specify REJECT as the ip6tables-target, the target of the rule
# will be the i6ptables REJECT target and not Shorewall's builtin
# 'reject' chain which is used when REJECT (see below) is specified as
# the target in the ACTION column.
#
# LOG:level
#
# Simply log the packet and continue with the next rule.
#
# macro[(macrotarget)]
#
# The name of a macro defined in a file named macro.macro. If the macro
# accepts an action parameter (Look at the macro source to see if it has
# PARAM in the TARGET column) then the macro name is followed by the
# parenthesized macrotarget (ACCEPT, DROP, REJECT, ...) to be substituted
# for the parameter.
#
# Example: FTP(ACCEPT).
#
# The older syntax where the macro name and the target are separated by a
# slash (e.g. FTP/ACCEPT) is still allowed but is deprecated.
#
# MARK({mark})
#
# where mark is a packet mark value.
#
# Added in Shorewall 5.0.7, MARK requires "Mark in filter table" support
# in your kernel and iptables.
#
# Normally will set the mark value of the current packet. If preceded by
# a vertical bar ("|"), the mark value will be logically ORed with the
# current mark value to produce a new mark value. If preceded by an
# ampersand ("&"), will be logically ANDed with the current mark value to
# produce a new mark value.
#
# Both "|" and "&" require Extended MARK Target support in your kernel
# and iptables.
#
# The mark value may be optionally followed by "/" and a mask value (used
# to determine those bits of the connection mark to actually be set).
# When a mask is specified, the result of logically ANDing the mark value
# with the mask must be the same as the mark value.
#
# NFLOG[(nflog-parameters)]
#
# Added in Shorewall 4.5.9.3. Queues matching packets to a back end
# logging daemon via a netlink socket then continues to the next rule.
# See http://www.shorewall.net/shorewall_logging.html.
#
# The nflog-parameters are a comma-separated list of up to 3 numbers:
#
# ☆ The first number specifies the netlink group (0-65535). If omitted
# (e.g., NFLOG(,0,10)) then a value of 0 is assumed.
#
# ☆ The second number specifies the maximum number of bytes to copy. If
# omitted, 0 (no limit) is assumed.
#
# ☆ The third number specifies the number of log messages that should
# be buffered in the kernel before they are sent to user space. The
# default is 1.
#
# NFLOG is similar to LOG:NFLOG[(nflog-parameters)], except that the log
# level is not changed when this ACTION is used in an action or macro
# body and the invocation of that action or macro specifies a log level.
#
# NFQUEUE[([queuenumber1[:queuenumber2[c]][,bypass]]|bypass)]
#
# Queues the packet to a user-space application using the nfnetlink_queue
# mechanism. If a queuenumber1 is not specified, queue zero (0) is
# assumed. Beginning with Shorewall 4.6.10, the keyword bypass can be
# given. By default, if no userspace program is listening on an NFQUEUE,
# then all packets that are to be queued are dropped. When this option is
# used, the NFQUEUE rule behaves like ACCEPT instead. Also beginning in
# Shorewall 4.6.10, a second queue number (queuenumber2) may be
# specified. This specifies a range of queues to use. Packets are then
# balanced across the given queues. This is useful for multicore systems:
# start multiple instances of the userspace program on queues x, x+1, ..
# x+n and use "x:x+n". Packets belonging to the same connection are put
# into the same nfqueue.
#
# Beginning with Shorewall 5.1.0, queuenumber2 may be followed by the
# letter 'c' to indicate that the CPU ID will be used as an index to map
# packets to the queues. The idea is that you can improve performance if
# there's a queue per CPU. Requires the NFQUEUE CPU Fanout capability in
# your kernel and iptables.
#
# NFQUEUE![([queuenumber1[:queuenumber2[c]][,bypass]]|bypass)]
#
# like NFQUEUE but exempts the rule from being suppressed by OPTIMIZE=1
# in shorewall.conf(5).
#
# NONAT
#
# Excludes the connection from any subsequent DNAT[-] or REDIRECT[-]
# rules but doesn't generate a rule to accept the traffic. Use with IPv6
# requires Shorewall 4.5.14 or later.
#
# QUEUE
#
# Queue the packet to a user-space application such as ftwall (http://
# p2pwall.sf.net). The application may reinsert the packet for further
# processing.
#
# QUEUE!
#
# like QUEUE but exempts the rule from being suppressed by OPTIMIZE=1 in
# shorewall.conf(5).
#
# REJECT[(option)]
#
# disallow the request and return an icmp-unreachable or an RST packet.
# If no option is passed, Shorewall selects the appropriate option based
# on the protocol of the packet.
#
# Beginning with Shorewall 5.0.8, the type of reject may be specified in
# the option paramater. Valid IPv4 option values are:
#
# icmp-net-unreachable
# icmp-host-unreachable
# icmp-port-unreachable
# icmp-proto-unreachable
# icmp-net-prohibited
# icmp-host-prohibited
# icmp-admin-prohibited
# icmp-tcp-reset (the PROTO column must specify TCP). Beginning with
# Shorewall 5.1.3, this option may also be specified as tcp-reset.
#
# Valid IPv6 option values are:
#
# icmp6-no-route
# no-route
# icmp6-adm-prohibited
# adm-prohibited
# icmp6-addr-unreachable
# addr-unreach
# icmp6-port-unreachable
# tcp-reset (the PROTO column must specify TCP)
#
# REJECT!
#
# like REJECT but exempts the rule from being suppressed by OPTIMIZE=1 in
# shorewall.conf(5).
#
# REDIRECT
#
# Redirect the request to a server running on the firewall. Use with IPv6
# requires Shorewall 4.5.14 or later.
#
# REDIRECT-
#
# Advanced users only.
#
# Like REDIRECT but only generates the REDIRECT iptables rule and not the
# companion ACCEPT rule. Use with IPv6 requires Shorewall 4.5.14 or
# later.
#
# TARPIT [(tarpit | honeypot | reset)]
#
# Added in Shorewall 4.6.6.
#
# TARPIT captures and holds incoming TCP connections using no local
# per-connection resources.
#
# TARPIT only works with the PROTO column set to tcp (6), and is totally
# application agnostic. This module will answer a TCP request and play
# along like a listening server, but aside from sending an ACK or RST, no
# data is sent. Incoming packets are ignored and dropped. The attacker
# will terminate the session eventually. This module allows the initial
# packets of an attack to be captured by other software for inspection.
# In most cases this is sufficient to determine the nature of the attack.
#
# This offers similar functionality to LaBrea " was specified
# in the command (e.g., shorewall [-6] check ./gateway) then the
# directory given in the command is searched first.
#
# □ Next, each directory in the CONFIG_PATH setting is searched in
# sequence.
#
# If CONFIG_PATH is not given or if it is set to the empty value then the
# contents of /usr/share/shorewall/configpath are used. As released from
# shorewall.net, that file sets the CONFIG_PATH to /etc/shorewall:/usr/share/
# shorewall but your particular distribution may set it differently. See the
# output of shorewall show config for the default on your system.
#
# Beginning with Shorewall 5.1.10, the CONFIG_PATH setting may begin with a
# colon (":"), to signal that the first directory listed will be skipped if
# the user performing a compilation is not root or if the configuration is
# being compiled for export (-e option specified or if running one of the
# remote-* commands) . This prevents the compiler from looking in /etc/
# shorewall[6]/ when compilation is being done by a non-root user or if the
# generated script is to be sent to a remote firewall system.
#
GEOIPDIR=/usr/share/xt_geoip/LE
#
# GEOIPDIR=[pathname]
#
# Added in Shorewall 4.5.4. Specifies the pathname of the directory
# containing the GeoIP Match database. See http://www.shorewall.net/
# ISO-3661.html. If not specified, the default value is /usr/share/xt_geoip/
# LE which is the default location of the little-endian database.
#
IP6TABLES=
#
# IP6TABLES=[pathname]
#
# IPv6 only.
#
# This parameter names the ip6tables executable to be used by Shorewall6. If
# not specified or if specified as a null value, then the ip6tables
# executable located using the PATH option is used.
#
# Regardless of how the ip6tables utility is located (specified via IP6TABLES
# = or located via PATH), Shorewall6 uses the ip6tables-restore and
# ip6tables-save utilities from that same directory.
#
IP=
#
# IP=[pathname]
#
# If specified, gives the pathname of the 'ip' executable. If not specified,
# 'ip' is assumed and the utility will be located using the current PATH
# setting.
#
IPSET=
#
# IPSET=[pathname]
#
# If specified, gives the pathname of the 'ipset' executable. If not
# specified, 'ipset' is assumed and the utility will be located using the
# current PATH setting.
#
LOCKFILE=
#
# LOCKFILE=[pathname]
#
# Specifies the name of the Shorewall[6] lock file, used to prevent
# simultaneous state-changing commands. If not specified, ${VARDIR}/shorewall
# [6]/lock is assumed (${VARDIR} is normally /var/lib but can be changed when
# Shorewall-core is installed -- see the output of shorewall show vardir).
#
MODULESDIR=
#
# MODULESDIR=[[+]pathname[:pathname]...]
#
# This parameter specifies the directory/directories where your kernel
# netfilter modules may be found. If you leave the variable empty, Shorewall
# will supply the value "/lib/modules/$uname/kernel/net/ipv${g_family}/
# netfilter:/lib/modules/$uname/kernel/net/netfilter:/lib/modules/$uname/
# kernel/net/sched:/lib/modules/$uname/extra:/lib/modules/$uname/extra/ipset"
# where uname holds the output of 'uname -r' and g_family holds '4' in IPv4
# configurations and '6' in IPv6 configurations.
#
# The option plus sign ('+') was added in Shorewall 5.0.3 and causes the
# listed pathnames to be appended to the default list above.
#
NFACCT=
#
# NFACCT=[pathname]
#
# Added in Shorewall 4.5.7. Specifies the pathname of the nfacct utility. If
# not specified, Shorewall will use the PATH setting to find the program.
#
PERL=/usr/bin/perl
#
# PERL=pathname
#
# Added in Shorewall 4.4.11 RC1. Specifies the path name of the Perl
# executable. Default is /usr/bin/perl. If the pathname specified by this
# option does not exist or the named file is not executable, then Shorewall
# falls back to /usr/bin/perl
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
#
# PATH=pathname[:pathname]...
#
# Determines the order in which Shorewall searches directories for executable
# files.
#
RESTOREFILE=restore
#
# RESTOREFILE=filename
#
# Specifies the simple name of a file in /var/lib/shorewall to be used as the
# default restore script in the shorewall [-6] save, shorewall [-6] restore,
# shorewall [-6] forget and shorewall [6] -f start commands.
#
SHOREWALL_SHELL=/bin/sh
#
# SHOREWALL_SHELL=[pathname]
#
# This option is used to specify the shell program to be used to interpret
# the compiled script. If not specified or specified as a null value, /bin/sh
# is assumed. Using a light-weight shell such as ash or dash can
# significantly improve performance.
#
SUBSYSLOCK=
#
# SUBSYSLOCK=[pathname]
#
# This parameter should be set to the name of a file that the firewall should
# create if it starts successfully and remove when it stops. Creating and
# removing this file allows Shorewall to work with your distribution's
# initscripts. For OpenSuSE, this should be set to /var/lock/subsys/shorewall
# (var/lock/subsys/shorewall-lite if building for export). For Gentoo, it
# should be set to /run/lock/shorewall (/run/lock/shorewall-lite). For Redhat
# and derivatives as well as Debian and derivatives, the pathname should be
# omitted.
#
# Important
#
# Beginning with Shorewall 5.1.0, this setting is ignored when SERVICEDIR is
# non-empty in ${SHAREDIR}/shorewall/shorewallrc (usually /usr/share/
# shorewall/shorewallrc).
#
TC=
#
# TC=[pathname]
#
# If specified, gives the pathname of the 'tc' executable. If not specified,
# 'tc' is assumed and the utility will be located using the current PATH
# setting.
#
###############################################################################
# D E F A U L T A C T I O N S / M A C R O S
###############################################################################
ACCEPT_DEFAULT="none"
#
# ACCEPT_DEFAULT={action[(parameters)][:level][,...]|none}
#
BLACKLIST_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP),dropNotSyn:$LOG_LEVEL,dropInvalid:$LOG_LEVEL,DropDNSrep:$LOG_LEVEL"
#
# BLACKLIST_DEFAULT={action[(parameters)][:level][,...]|none}
#
DROP_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)"
#
# DROP_DEFAULT={action[(parameters)][:level][,...]|none}
#
NFQUEUE_DEFAULT="none"
#
# NFQUEUE_DEFAULT={action[(parameters)][:level][,...]|none}
#
QUEUE_DEFAULT="none"
#
# QUEUE_DEFAULT={action[(parameters)][:level][,...]|none}
#
REJECT_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)"
#
# REJECT_DEFAULT={action[(parameters)][:level][,...]|none}
#
# In earlier Shorewall versions, a "default action" for DROP and REJECT
# policies was specified in the file /usr/share/shorewall/actions.std.
#
# In Shorewall 4.4.0, the DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT,
# QUEUE_DEFAULT and NFQUEUE_DEFAULT options were added.
#
# 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
# three are similar for ACCEPT, QUEUE and NFQUEUE policies.
#
# The value applied to these may be:
#
# a) The name of an action. The name may optionally be followed by a
# comma-separated list of parameters enclosed in parentheses if the specified
# action accepts parameters (e.g., 'Drop(audit)').
# c) None or none
#
# Prior to Shorewall 5.1.2, the default values are:
#
# DROP_DEFAULT="Drop"
# REJECT_DEFAULT="Reject"
# BLACKLIST_DEFAULT="Drop" (added in Shorewall 5.1.1)
# ACCEPT_DEFAULT="none"
# QUEUE_DEFAULT="none"
# NFQUEUE_DEFAULT="none"
#
# Beginning with Shorewall 5.1.2, the default value is 'none' for all of
# these. Note that the sample configuration files do, however, provide
# settings for DROP_DEFAULT, BLACKLIST_DEFAULT and REJECT_DEFAULT.
#
# 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
# shorewall-policy(5).
#
# You can pass parameters to the specified action (e.g., myaction(audit,DROP)
# ).
#
# Beginning with Shorewall 4.5.10, the action name can be followed optionally
# by a colon and a log level. The level will be applied to each rule in the
# action or body that does not already have a log level.
#
# Beginning with Shorewall 5.1.2, multiple action[(parameters)][:level]
# specifications may be listed, separated by commas.
#
###############################################################################
# R S H / R C P C O M M A N D S
###############################################################################
RCP_COMMAND='scp ${files} ${root}@${system}:${destination}'
#
# RCP_COMMAND="command"
#
RSH_COMMAND='ssh ${root}@${system} ${command}'
#
# RSH_COMMAND="command"
#
# Earlier generations of Shorewall Lite required that remote root login via
# ssh be enabled in order to use the load and reload commands. Beginning with
# release 3.9.5, you may define an alternative means for accessing the remote
# firewall system. In that release, two new options were added to
# shorewall.conf:
#
# RSH_COMMAND
# RCP_COMMAND
#
# The default values for these are as follows:
#
# RSH_COMMAND: ssh ${root}@${system} ${command}
# RCP_COMMAND: scp ${files} ${root}@${system}:${destination}
#
# Shell variables that will be set when the commands are invoked are as
# follows:
#
# root - root user. Normally root but may be overridden using the '-r' option.
# system - The name/IP address of the remote firewall system.
# command - For RSH_COMMAND, the command to be executed on the firewall system.
# files - For RCP_COMMAND, a space-separated list of files to be copied to the remote firewall system.
# destination - The directory on the remote system that the files are to be copied into.
#
###############################################################################
# F I R E W A L L O P T I O N S
###############################################################################
ACCOUNTING=Yes
#
# ACCOUNTING=[Yes|No]
#
# Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting is enabled
# (see shorewall-accounting(5)). If not specified or set to the empty value,
# ACCOUNTING=Yes is assumed.
#
ACCOUNTING_TABLE=filter
#
# ACCOUNTING_TABLE=[filter|mangle]
#
# Added in Shorewall 4.4.20. This setting determines which Netfilter table
# the accounting rules are added in. By default, ACCOUNTING_TABLE=filter is
# assumed. See also shorewall-accounting(5).
#
ADMINISABSENTMINDED=Yes
#
# ADMINISABSENTMINDED=[Yes|No]
#
# The value of this variable affects Shorewall's stopped state. The behavior
# differs depending on whether shorewall-routestopped(5) or
# shorewall-stoppedrules(5) is used:
#
# routestopped
#
# When ADMINISABSENTMINDED=No, only traffic to/from those addresses
# listed in routestopped is accepted when Shorewall is stopped. When
# ADMINISABSENTMINDED=Yes, in addition to traffic to/from addresses in
# routestopped, connections that were active when Shorewall stopped
# continue to work and all new connections from the firewall system
# itself are allowed.
#
# Note that the routestopped file is not supported in Shorewall 5.0 and
# later versions.
#
# stoppedrules
#
# All existing connections continue to work. To sever all existing
# connections when the firewall is stopped, install the conntrack utility
# and place the command conntrack -F in the stopped user exit (/etc/
# shorewall/stopped).
#
# If ADMINISABSENTMINDED=No, only new connections matching entries in
# stoppedrules are accepted when Shorewall is stopped. Response packets
# and related connections are automatically accepted.
#
# If ADMINISABSENTMINDED=Yes, in addition to connections matching entries
# in stoppedrules, all new connections from the firewall system itself
# are allowed when the firewall is stopped. Response packets and related
# connections are automatically accepted.
#
# If this variable is not set or is given the empty value then
# ADMINISABSENTMINDED=No is assumed.
#
AUTOCOMMENT=Yes
#
# AUTOCOMMENT=[Yes|No]
#
# Formerly named AUTO_COMMENT. If set, if there is not a current comment when
# a macro is invoked, the behavior is as if the first line of the macro file
# was "COMMENT ". If not specified, the AUTO_COMMENT option has a
# default value of 'Yes'.
#
AUTOHELPERS=Yes
#
# AUTOHELPERS=[Yes|No]
#
# Added in Shorewall 4.5.7. When set to Yes (the default), the generated
# ruleset will automatically associate helpers with applications that require
# them (FTP, IRC, etc.). When configuring your firewall on systems running
# kernel 3.5 or later, it is recommended that you:
#
# 1. Set AUTOHELPERS=No.
#
# 2. Modify the HELPERS setting (see below) to list the helpers that you
# need.
#
# 3. Either:
#
# a. Modify shorewall-conntrack (5) to only apply helpers where they are
# required; or
#
# b. Specify the appropriate helper in the HELPER column in
# shorewall-rules (5).
#
# Note
#
# The macros for those applications requiring a helper automatically
# specify the appropriate HELPER where required.
#
AUTOMAKE=Yes
#
# AUTOMAKE=[Yes|No|recursive|depth]
#
# If set, the behavior of the start, reload and restart commands are changed;
# if no files in CONFIG_PATH (see below) have been changed since the last
# successful start, reload or restart command, then the compilation step is
# skipped and the compiled script that executed the last start, reload or
# restart command is used. If not specified, the default is AUTOMAKE=No.
#
# The setting of the AUTOMAKE option is ignored if the start, reload or
# restart command includes a directory name (e.g., shorewall restart /etc/
# shorewall.new).
#
# When AUTOMAKE=Yes, each directory in the CONFIG_PATH was originally
# searched recursively for files newer than the compiled script. That was
# changed in Shorewall 5.1.10.2 such that only the listed directories
# themselves were searched. That broke some configurations that played tricks
# with embedded SHELL such as "SHELL cat /etc/shorewall/rules.d/loc/*.rules".
# Prior to 5.1.10.2, a change to a file in or adding a file to /etc/shorewall
# /rules.d/loc/ would trigger recompilation. Beginning with 5.1.10.2, such
# changes would not trigger recompilation. Beginning with Shorewall 5.2.0,
# the pre-5.1.10.2 behavior can be obtained by setting AUTOMAKE=recursive.
#
# Also beginning with Shorewall 5.2.0, AUTOMAKE may be set to a numeric depth
# which specifies how deeply each listed directory is to be searched.
# AUTOMAKE=1 only searches each directory itself and is equivalent to
# AUTOMAKE=Yes. AUTOMAKE=2 will search each directory and its immediate
# sub-directories; AUTOMAKE=3 will search each directory, each of its
# immediate sub-directories, and each of their immediate sub-directories,
# etc.
#
BALANCE_PROVIDERS=No
#
# BALANCE_PROVIDERS=[Yes|No]
#
# Added in Shorewall 5.1.1. When USE_DEFAULT_RT=Yes, this option determines
# whether the balance provider option (see shorewall-providers(5)) is the
# default. When BALANCE_PROVIDERS=Yes, then the balance option is assumed
# unless the fallback, loose, load or tproxy option is specified. If this
# option is not set or is set to the empty value, then the default value is
# the value of USE_DEFAULT_RT.
#
BASIC_FILTERS=No
#
# BASIC_FILTERS=[Yes|No]
#
# Added in Shorewall-4.6.0. When set to Yes, causes entries in
# shorewall-tcfilters(5) to generate a basic filter rather than a u32 filter.
# This setting requires the Basic Ematch capability in your kernel and
# iptables.
#
# Note
#
# One of the advantages of basic filters is that ipset matches are supported
# in newer iproute2 and kernel versions. Because Shorewall cannot reliably
# detect this capability, use of basic filters is controlled by this option.
#
# The default value is No which causes u32 filters to be generated.
#
BLACKLIST="NEW,INVALID,UNTRACKED"
#
# BLACKLIST=[{ALL|state[,...]}]
#
# where state is one of NEW, ESTABLISHED, RELATED, INVALID,or UNTRACKED.
#
# Added in Shorewall 4.5.13 to replace the BLACKLISTNEWONLY option. Specifies
# the connection tracking states that are to be subject to blacklist
# screening. If BLACKLIST is not specified then the states subject to
# blacklisting are NEW,ESTABLISHED,INVALID,UNTRACKED.
#
# ALL sends all packets through the blacklist chains.
#
# Note: The ESTABLISHED state may not be specified if FASTACCEPT=Yes is
# specified.
#
CLAMPMSS=No
#
# CLAMPMSS=[Yes|No|value]
#
# This parameter enables the TCP Clamp MSS to PMTU feature of Netfilter and
# is usually required when your internet connection is through PPPoE or PPTP.
# If set to Yes or yes, the feature is enabled. If left blank or set to No or
# no, the feature is not enabled.
#
# Important: This option requires CONFIG_IP_NF_TARGET_TCPMSS in your kernel.
#
# You may also set CLAMPMSS to a numeric value (e.g., CLAMPMSS=1400). This
# will set the MSS field in TCP SYN packets going through the firewall to the
# value that you specify.
#
CLEAR_TC=No
#
# CLEAR_TC=[Yes|No]
#
# If this option is set to No then Shorewall won't clear the current traffic
# control rules during [re]start or reload. This setting is intended for use
# by people who prefer to configure traffic shaping when the network
# interfaces come up rather than when the firewall is started. If that is
# what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not supply
# an /etc/shorewall/tcstart file. That way, your traffic shaping rules can
# still use the “fwmark” classifier based on packet marking defined in
# shorewall-tcrules(5). If not specified, CLEAR_TC=Yes is assumed.
#
# Warning
#
# When you specify TC_ENABLED=shared (see below), then you should also
# specify CLEAR_TC=No.
#
COMPLETE=No
#
# COMPLETE=[Yes|No]
#
# Added in Shorewall 4.4.12. When you set this option to Yes, you are
# asserting that the configuration is complete so that your set of zones
# encompasses any hosts that can send or receive traffic to/from/through the
# firewall. This causes Shorewall to omit the rules that catch packets in
# which the source or destination IP address is outside of any of your zones.
# Default is No. It is recommended that this option only be set to Yes if:
#
# □ You have defined an interface whose effective physical setting is '+'.
#
# □ That interface is assigned to a zone.
#
# □ You have no CONTINUE policies or rules.
#
DEFER_DNS_RESOLUTION=Yes
#
# DEFER_DNS_RESOLUTION=[Yes|No]
#
# Added in Shorewall 4.5.12. When set to 'Yes' (the default), DNS names are
# validated in the compiler and then passed on to the generated script where
# they are resolved by ip[6]tables-restore. This is an advantage if you use
# AUTOMAKE=Yes and the IP address associated with the DNS name is subject to
# change. When DEFER_DNS_RESOLUTION=No, DNS names are converted into IP
# addresses by the compiler. This has the advantage that when AUTOMAKE=Yes,
# the start, reload and restart commands will succeed even if no DNS server
# is reachable (assuming that the configuration hasn't changed since the
# compiled script was last generated).
#
# Important
#
# When DEFER_DNS_RESOLUTION=No and AUTOMAKE=Yes and a DNS change makes it
# necessary to recompile an existing firewall script, the -c option must be
# used with the reload or restart command to force recompilation.
#
DELETE_THEN_ADD=Yes
#
# DELETE_THEN_ADD={Yes|No}
#
# If set to Yes (the default value), entries in the /etc/shorewall[6]/rtrules
# files cause an 'ip rule del' command to be generated in addition to an 'ip
# rule add' command. Setting this option to No, causes the 'ip rule del'
# command to be omitted.
#
DONT_LOAD=
#
# DONT_LOAD=[module[,module]...]
#
# Causes Shorewall to not load the listed kernel modules.
#
DYNAMIC_BLACKLIST=Yes
#
# DYNAMIC_BLACKLIST={Yes|No||ipset[-only][,option[,...]][:[setname][:log_level|:l
# og_tag]]]}
#
# Added in Shorewall 4.4.7. When set to No or no, chain-based dynamic
# blacklisting using shorewall [-6] [-l] drop, shorewall [-6] [-l] reject,
# shorewall logdrop and shorewall [-6] [-l] logreject is disabled. Default is
# Yes. Beginning with Shorewall 5.0.8, ipset-based dynamic blacklisting using
# the shorewall blacklist command is also supported. The name of the set (
# setname) and the level (log_level), if any, at which blacklisted traffic is
# to be logged may also be specified. The default IPv4 set name is SW_DBL4
# and the default IPv6 set name is SW_DBL6. The default log level is none (no
# logging). If ipset-only is given, then chain-based dynamic blacklisting is
# disabled just as if DYNAMIC_BLACKLISTING=No had been specified.
#
# Possible options are:
#
# src-dst
#
# Normally, only packets whose source address matches an entry in the
# ipset are dropped. If src-dst is included, then packets whose
# destination address matches an entry in the ipset are also dropped.
#
# disconnect
#
# The disconnect option was added in Shorewall 5.0.13 and requires that
# the conntrack utility be installed on the firewall system. When an
# address is blacklisted using the blacklist command, all connections
# originating from that address are disconnected. if the src-dst option
# was also specified, then all connections to that address are also
# disconnected.
#
# timeout=seconds
#
# Added in Shorewall 5.0.13. Normally, Shorewall creates the dynamic
# blacklisting ipset with timeout 0 which means that entries are
# permanent. If you want entries in the set that are not accessed for a
# period of time to be deleted from the set, you may specify that period
# using this option. Note that the blacklist command can override the
# ipset's timeout setting.
#
# Important
#
# Once the dynamic blacklisting ipset has been created, changing this
# option setting requires a complete restart of the firewall; shorewall
# [-6] restart if RESTART=restart, otherwise shorewall [-6] [-l] stop &&
# shorewall [-6] [-l] start
#
# When ipset-based dynamic blacklisting is enabled, the contents of the
# blacklist will be preserved over stop/reboot/start sequences if SAVE_IPSETS
# =Yes, SAVE_IPSETS=ipv4 or if setname is included in the list of sets to be
# saved in SAVE_IPSETS.
#
EXPAND_POLICIES=Yes
#
# EXPAND_POLICIES={Yes|No}
#
# Normally, when the SOURCE or DEST columns in shorewall-policy(5) contains
# 'all', a single policy chain is created and thes policy is enforced in that
# chain. For example, if the policy entry is
#
# #SOURCE DEST POLICY LOG
# # LEVEL
# net all DROP info
#
# then the chain name is 'net-all' ('net2all if ZONE2ZONE=2) which is also
# the chain named in Shorewall log messages generated as a result of the
# policy. If EXPAND_POLICIES=Yes, then Shorewall will create a separate chain
# for each pair of zones covered by the policy. This makes the resulting log
# messages easier to interpret since the chain in the messages will have a
# name of the form 'a2b' where 'a' is the SOURCE zone and 'b' is the DEST
# zone.
#
EXPORTMODULES=Yes
#
# EXPORTMODULES=[Yes|No]
#
# Added in Shorewall 4.4.17. When set to Yes when compiling for use by
# Shorewall Lite (shorewall [-6] remote-start, shorewall [-6] remote-reload,
# shorewall [-6] remote-restart or shorewall [-6] export commands), the
# compiler will copy the modules or helpers file from the administrative
# system into the script. When set to No or not specified, the compiler will
# not copy the modules or helpers file from /usr/share/shorewall[6] but will
# copy those found in another location on the CONFIG_PATH.
#
# When compiling for direct use by Shorewall, causes the contents of the
# local module or helpers file to be copied into the compiled script. When
# set to No or not set, the compiled script reads the file itself.
#
FASTACCEPT=No
#
# FASTACCEPT={Yes|No}
#
# 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 'loc-net' or 'loc2net'
# chain, depending on the setting of ZONE2ZONE (see below).
#
# If you set FASTACCEPT=Yes, then ESTABLISHED/RELATED 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
# shorewall-rules(5).
#
FORWARD_CLEAR_MARK=
#
# FORWARD_CLEAR_MARK={Yes|No}
#
# Added in Shorewall 4.4.11. Traditionally, Shorewall has cleared the packet
# mark in the first rule in the mangle FORWARD chain. This behavior is
# maintained with the default setting of this option (FORWARD_CLEAR_MARK=
# Yes). If FORWARD_CLEAR_MARK is set to 'No', packet marks set in the mangle
# PREROUTING chain are retained in the FORWARD chains.
#
HELPERS=
#
# HELPERS=[helper[,helper...]]
#
# Added in Shorewall 4.5.7. This option specifies a comma-separated list
# naming the Netfilter application helpers that are to be enabled. If not
# specified, the default is to enable all helpers.
#
# Possible values for helper are:
#
# □ amanda
#
# □ ftp
#
# □ h323
#
# □ irc
#
# □ netbios-ns
#
# □ none - This special value was added in Shorewall 4.5.16 and indicates
# that no helpers are to be enabled. It also prevents the compiler for
# probing for helper support; such probing generates messages on the
# system log of the form "xt_CT: No such helper XXX" where XXX is the
# helper name. When used, none must be the only helper specified.
#
# □ pptp
#
# □ sane
#
# □ sip
#
# □ snmp
#
# □ tftp
#
# When HELPERS is specified on a system running Kernel 3.5.0 or later,
# automatic association of helpers to connections is disabled.
#
IGNOREUNKNOWNVARIABLES=No
#
# IGNOREUNKNOWNVARIABLES=[Yes|No]
#
# Added in Shorewall 4.5.11. Normally, if an unknown shell variable is
# encountered in a configuration file (except in ?IF and ?ELSIF directives),
# the compiler raises a fatal error. If IGNOREUNKNOWNVARIABLES is set to Yes,
# then such variables simply expand to an empty string. Default is No.
#
IMPLICIT_CONTINUE=No
#
# IMPLICIT_CONTINUE={Yes|No}
#
# When this option is set to Yes, it causes subzones to be treated
# differently with respect to policies.
#
# Subzones are defined by following their name with ":" and a list of parent
# zones (in shorewall-zones(5)). Normally, you want to have a set of special
# rules for the subzone and if a connection doesn't match any of those
# subzone-specific rules then you want the parent zone rules and policies to
# be applied; see shorewall-nesting(5). With IMPLICIT_CONTINUE=Yes, that
# happens automatically.
#
# If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set, then subzones
# are not subject to this special treatment. With IMPLICIT_CONTINUE=Yes, an
# implicit CONTINUE policy may be overridden by including an explicit policy
# (one that does not specify "all" in either the SOURCE or the DEST columns).
#
IPSET_WARNINGS=Yes
#
# IPSET_WARNINGS={Yes|No}
#
# Added in Shorewall 4.5.2. Default is Yes. When set, causes the rules
# compiler to issue a warning when:
#
# □ The compiler is being run by root and an ipset specified in the
# configuration does not exists. Only one warning is issued for each
# missing ipset.
#
# □ When [src] is specified in a destination column and when [dst] is
# specified in a source column.
#
IP_FORWARDING=Keep
#
# IP_FORWARDING=[On|Off|Keep]
#
# This IPv4 parameter determines whether Shorewall enables or disables IPv4
# Packet Forwarding (/proc/sys/net/ipv4/ip_forward). In an IPv6
# configuration, this parameter determines the setting of /proc/sys/net/ipv6/
# config/all/ip_forwarding.
#
# Possible values are:
#
# On or on
#
# packet forwarding will be enabled.
#
# Off or off
#
# packet forwarding will be disabled.
#
# Keep or keep
#
# Shorewall will neither enable nor disable packet forwarding.
#
# If this variable is not set or is given an empty value (IP_FORWARD="") then
# IP_FORWARD=On is assumed.
#
KEEP_RT_TABLES=Yes
#
# KEEP_RT_TABLES={Yes|No}
#
# IPv4:
#
# When set to Yes, this option prevents generated scripts from altering
# the /etc/iproute2/rt_tables database when there are entries in /etc/
# shorewall/providers. If you set this option to Yes while Shorewall
# (Shorewall-lite) is running, you should remove the file /var/lib/
# shorewall/rt_tables (/var/lib/shorewall-lite/rt_tables) before your
# next stop, restore, reload or restart command.
#
# IPv6:
#
# When set to Yes, this option prevents scripts generated by Shorewall6
# from altering the /etc/iproute2/rt_tables database when there are
# entries in /etc/shorewall6/providers. If you set this option to Yes
# while Shorewall6 (Shorewall6-lite) is running, you should remove the
# file /var/lib/shorewall6/rt_tables (/var/lib/shorewall6-lite/rt_tables)
# before your next stop, restore, reload or restart command.
#
# Important
#
# When both IPv4 and IPv6 Shorewall configurations are present,
# KEEP_RT_TABLES=No should be specified in only one of the two configurations
# unless the two provider configurations are identical with respect to
# interface and provider names and numbers.
#
# The default is KEEP_RT_TABLES=No.
#
MACLIST_TABLE=filter
#
# MACLIST_TABLE=[filter|mangle]
#
# Normally, MAC verification occurs in the filter table (INPUT and FORWARD)
# chains. When forwarding a packet from an interface with MAC verification to
# a bridge interface, that doesn't work.
#
# This problem can be worked around by setting MACLIST_TABLE=mangle which
# will cause Mac verification to occur out of the PREROUTING chain. Because
# REJECT isn't available in that environment, you may not specify
# MACLIST_DISPOSITION=REJECT or MACLIST_DISPOSITION=A_REJECT with
# MACLIST_TABLE=mangle.
#
MACLIST_TTL=
#
# MACLIST_TTL=[number]
#
# The performance of configurations with a large numbers of entries in
# shorewall-maclist(5) can be improved by setting the MACLIST_TTL variable in
# shorewall[6].conf(5).
#
# If your iptables and kernel support the "Recent Match" (see the output of
# "shorewall check" near the top), you can cache the results of a 'maclist'
# file lookup and thus reduce the overhead associated with MAC Verification.
#
# When a new connection arrives from a 'maclist' interface, the packet passes
# through then list of entries for that interface in shorewall-maclist(5). If
# there is a match then the source IP address is added to the 'Recent' set
# for that interface. Subsequent connection attempts from that IP address
# occurring within $MACLIST_TTL seconds will be accepted without having to
# scan all of the entries. After $MACLIST_TTL from the first accepted
# connection request from an IP address, the next connection request from
# that IP address will be checked against the entire list.
#
# If MACLIST_TTL is not specified or is specified as empty (e.g, MACLIST_TTL=
# "" or is specified as zero then 'maclist' lookups will not be cached).
#
MANGLE_ENABLED=Yes
#
# MANGLE_ENABLED=[Yes|No]
#
# Determines whether Shorewall will generate rules in the Netfilter mangle
# table. Setting MANGLE_ENABLED=No disables all Shorewall features that
# require the mangle table. The default is MANGLE_ENABLED=Yes.
#
MARK_IN_FORWARD_CHAIN=No
#
# MARK_IN_FORWARD_CHAIN=[Yes|No]
#
# If your kernel has a FORWARD chain in the mangle table, you may set
# MARK_IN_FORWARD_CHAIN=Yes to cause the marking specified in the tcrules
# file to occur in that chain rather than in the PREROUTING chain. This
# permits you to mark inbound traffic based on its destination address when
# DNAT is in use. To determine if your kernel has a FORWARD chain in the
# mangle table, use the shorewall [-6] show mangle command; if a FORWARD
# chain is displayed then your kernel will support this option. If this
# option is not specified or if it is given the empty value (e.g.,
# MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed.
#
MINIUPNPD=No
#
# MINIUPNPD=[Yes|No]
#
# Added in Shorewall 5.0.8. If set to Yes, Shorewall will create a chain in
# the nat table named MINIUPNPD-POSTROUTING and will add jumps from
# POSTROUTING to that chain for each interface with the upnpd option
# specified. Default is No.
#
MUTEX_TIMEOUT=60
#
# MUTEX_TIMEOUT=[seconds]
#
# The value of this variable determines the number of seconds that programs
# will wait for exclusive access to the Shorewall[6] lock file. After the
# number of seconds corresponding to the value of this variable, programs
# will assume that the last program to hold the lock died without releasing
# the lock.
#
# If not set or set to the empty value, a value of 60 (60 seconds) is
# assumed.
#
# An appropriate value for this parameter would be twice the length of time
# that it takes your firewall system to process a shorewall [-6] restart
# command.
#
OPTIMIZE=All
#
# OPTIMIZE=[value]
#
# The specified value enables certain optimizations. Each optimization
# category is associated with a power of two. To enable multiple optimization
# categories, simply add their corresponding numbers together.
#
# Beginning with Shorewall 4.5.20, you may specify OPTIMIZE=All to enable all
# optimization categories, and you may also specify OPTIMIZE=None to disable
# optimization.
#
# □ Optimization category 1 - Traditionally, Shorewall has created rules
# for the complete matrix of host groups defined by the zones, interfaces
# and hosts files. Any traffic that didn't correspond to an element of
# that matrix was rejected in one of the built-in chains. When the matrix
# is sparse, this results in lots of largely useless rules.
#
# These extra rules can be eliminated by setting the 1 bit in OPTIMIZE.
#
# The 1 bit setting also controls the suppression of redundant wildcard
# rules (those specifying "all" in the SOURCE or DEST column). A wildcard
# rule is considered to be redundant when it has the same ACTION and Log
# Level as the applicable policy.
#
# Note
#
# Optimization level 1 is ignored when optimization level 4 is also
# selected, since level 4 performs similar optimizations in a more robust
# way.
#
# □ Optimization category 2 - Added in Shorewall 4.4.7. When set,
# suppresses superfluous ACCEPT rules in a policy chain that implements
# an ACCEPT policy. Any ACCEPT rules that immediately precede the final
# blanket ACCEPT rule in the chain are now omitted.
#
# □ Optimization category 4 - Added in Shorewall 4.4.7. When set, causes
# short chains (those with less than 2 rules) to be optimized away. The
# following chains are excluded from optimization:
#
# ☆ accounting chains (unless OPTIMIZE_ACCOUNTING=Yes)
#
# ☆ action chains (user-defined)
#
# ☆ 'blacklst' chain
#
# ☆ dynamic
#
# ☆ forwardUPnP
#
# ☆ UPnP (nat table)
#
# Additionally:
#
# ☆ If a built-in chain has a single rule that branches to a second
# chain, then the rules from the second chain are moved to the
# built-in chain and the target chain is omitted.
#
# ☆ Chains with no references are deleted.
#
# ☆ Accounting chains are subject to optimization if the
# OPTIMIZE_ACCOUNTING option is set to 'Yes'.
#
# ☆ If a chain ends with an unconditional branch to a second chain
# (other than to 'reject'), then the branch is deleted from the first
# chain and the rules from the second chain are appended to it.
#
# An additional optimization was added in Shorewall 4.5.4. If the last
# rule in a chain is an unqualified jump to a simple target, then all
# immediately preceding rules with the same simple target are omitted.
#
# For example, consider this chain:
#
# -A fw-net -p udp --dport 67:68 -j ACCEPT
# -A fw-net -p udp --sport 1194 -j ACCEPT
# -A fw-net -p 41 -j ACCEPT
# -A fw-net -j ACCEPT
#
# Since all of the rules are jumps to the simple target ACCEPT, this
# chain is totally optimized away and jumps to the chain are replace with
# jumps to ACCEPT.
#
# □ Optimization category 8 - Added in Shorewall 4.4.9. When set, causes
# chains with identical rules to be collapsed into a single chain.
#
# Warning
#
# While Optimization category 8 can significantly reduce the size of the
# generated iptables ruleset, it can also take significant system
# resources during compilation. If you find that compilation takes an
# unreasonably long time, try disabling this category by setting OPTIMIZE
# =23.
#
# □ Optimization category 16 - Added in Shorewall 4.4.26. When set, causes
# sequences of compatible rules to be combined into a single rule. Rules
# are considered compatible if they differ only in their destination
# ports and comments.
#
# A sequence of compatible rules is often generated when macros are
# invoked in sequence.
#
# The ability to combine adjacent rules is limited by two factors:
#
# ☆ Destination port lists may only be combined up to a maximum of 15
# ports, where a port-pair counts as two ports.
#
# ☆ Rules may only be combined until the length of their concatenated
# comment reaches 255 characters.
#
# When either of these limits would be exceeded, the current combined
# rule is emitted and the compiler attempts to combine rules beginning
# with the one that would have exceeded the limit. Adjacent combined
# comments are separated by ', '. Empty comments at the front of a group
# of combined comments are replaced by 'Others and'. Empty comments at
# the end of a group of combined comments are replaced by 'and others'.
#
# Beginning in Shorewall 4.5.10, this option also suppresses duplicate
# adjacent rules and duplicate non-adjacent rules that don't include mark
# , connmark, dscp, ecn, set, tos or u32 matches.
#
# Example 1:
#
# Rules with comments "FOO", and "BAR" would result in the
# combined comment "FOO and others, BAR".
#
# Example 2:
#
# Rules with comments , "FOO" and "BAR" would result in the
# combined comment "Others and FOO, BAR". Note: Optimize level 16
# requires "Extended Multi-port Match" in your iptables and kernel.
#
# In versions prior to 5.1.0, the default value is zero which disables all
# optimizations. Beginning with Shorewall 5.1.0, the default value is All
# which enables all optimizations.
#
OPTIMIZE_ACCOUNTING=No
#
# OPTIMIZE_ACCOUNTING=[Yes|No]
#
# Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting changes are
# subject to optimization (OPTIMIZE=4,5,6 or 7). If not specified or set to
# the empty value, OPTIMIZE_ACCOUNTING=No is assumed.
#
PERL_HASH_SEED=0
#
# PERL_HASH_SEED=seed|random
#
# Added in Shorewall 5.1.4. Sets the Perl hash seed (an integer in the range
# 0-99999) when running the Shorewall rules compiler. If not specified, the
# value 0 is assumed. If random is specified, a random seed will be chosed by
# Perl. See perlsec(1) for additional information.
#
REJECT_ACTION=
#
# REJECT_ACTION=action
#
# Added in Shorewall 4.5.21. When a REJECT target is specified, Shorewall
# normally handles the response as follows:
#
# □ If the destination address of the packet is a broadcast or multicast
# address, the packet is dropped.
#
# □ if the protocol is ICMP (2) then the packet is dropped.
#
# □ if the protocol is TCP (6) then the packet is rejected with an RST.
#
# □ if the protocol is UDP (17) then the packet is rejected with an
# 'port-unreachable' ICMP.
#
# □ if the protocol is ICMP (1) then the packet is rejected with a
# 'host-unreachable' ICMP.
#
# □ if the protocol is ICMP6 (1) then the packet is rejected with a
# 'icmp6-addr-unreachable' ICMP6.
#
# □ otherwise, the packet is rejected with a 'host-prohibited' ICMP.
#
# You can modify this behavior by implementing your own action that handles
# REJECT and specifying it's name in this option. The nolog and noinline
# options will automatically be assumed for the specified action.
#
# The following action implements the default reject action:
#
# ?format 2
# #TARGET SOURCE DEST PROTO
# Broadcast(DROP) - - -
# DROP - - 2
# INLINE - - 6 ;; -j REJECT --reject-with tcp-reset
# ?if __ENHANCED_REJECT
# INLINE - - 17 ;; -j REJECT
# ?if __IPV4
# INLINE - - 1 ;; -j REJECT --reject-with icmp-host-unreachable
# INLINE - - - ;; -j REJECT --reject-with icmp-host-prohibited
# ?else
# INLINE - - 58 ;; -j REJECT --reject-with icmp6-addr-unreachable
# INLINE - - - ;; -j REJECT --reject-with icmp6-adm-prohibited
# ?endif
# ?else
# INLINE - - - ;; -j REJECT
# ?endif
#
RENAME_COMBINED=Yes
#
# RENAME_COMBINED=[Yes|No]
#
# Added in Shorewall 5.2.0. Traditionally, when OPTIMIZE category 8 is
# enabled, identical chains are combined under a name beginning with '~comb'
# or '~blacklist'. This behavior is maintained under the default setting
# RENAME_COMBINED=Yes. If RENAMED_COMBINED=No, the chains are combined under
# the original name of one of the chains.
#
REQUIRE_INTERFACE=No
#
# REQUIRE_INTERFACE=[Yes|No]
#
# Added in Shorewall 4.4.10. The default is No. If set to Yes, at least one
# optional interface must be up in order for the firewall to be in the
# started state. Intended to be used with the Shorewall Init Package.
#
RESTART=restart
#
# RESTART=[restart|reload]
#
# Added in Shorewall 5.0.1 to replace LEGACY_RESTART which was added in
# Shorewall 5.0.0. In that release, the reload command was redefined to do
# what restart had done in earlier releases and restart became a true restart
# (equivalent to stop followed by start). When RESTART=reload, the restart
# command performs the same operation as the reload command making it
# compatible with earlier releases. If not specified, RESTART=reload is
# assumed.
#
RESTORE_DEFAULT_ROUTE=Yes
#
# RESTORE_DEFAULT_ROUTE=[Yes|No]
#
# This option determines whether to restore the default route saved when here
# are 'balance' providers defined but all of them are down.
#
# The default is RESTORE_DEFAULT_ROUTE=Yes which preserves the pre-4.2.6
# behavior.
#
# RESTORE_DEFAULT_ROUTE=No is appropriate when you don't want a default route
# in the main table (USE_DEFAULT_RT=No) or in the default table
# (USE_DEFAULT_RT=Yes) when there are no balance providers available. In that
# case, RESTORE_DEFAULT_ROUTE=No will cause any default route in the relevant
# table to be deleted.
#
RESTORE_ROUTEMARKS=Yes
#
# RESTORE_ROUTEMARKS=[Yes|No]
#
# Added in Shorewall 4.5.9. When set to Yes (the default), provider marks are
# restored unconditionally at the top of the mangle OUTPUT and PREROUTING
# chains, even if the saved mark is zero. When this option is set to No, the
# mark is restored only if it is non-zero. If you have problems with IPSEC
# ESP packets not being routed correctly on output, try setting this option
# to No.
#
SAVE_IPSETS=No
#
# SAVE_IPSETS={Yes|No|ipv4|setlist}
#
# Re-enabled in Shorewall 4.4.6. If SAVE_IPSETS=Yes, then the current
# contents of your ipsets will be saved by the shorewall stop and shorewall
# save commands and restored by the shorewall start and shorewall restore
# commands.
#
# Beginning with Shorewall 4.6.4, you can restrict the set of ipsets saved by
# specifying a setlist (a comma-separated list of ipv4 ipset names). You may
# also restrict the saved sets to just the ipv4 ones by specifying ipv4.
#
TC_ENABLED=Shared
#
# TC_ENABLED=[Yes|No|Internal|Simple|Shared]
#
# If you say Yes or yes here, Shorewall will use a script that you supply to
# configure traffic shaping. The script must be named 'tcstart' and must be
# placed in a directory on your CONFIG_PATH.
#
# If you say No or no then traffic shaping is not enabled.
#
# If you set TC_ENABLED=Simple (Shorewall 4.4.6 and later), simple traffic
# shaping using shorewall-tcinterfaces(5) and shorewall-tcpri(5) is enabled.
#
# If you set TC_ENABLED=Internal or internal or leave the option empty then
# Shorewall will use its builtin traffic shaper (tc4shorewall written by Arne
# Bernin.
#
# Beginning with Shorewall 4.4.15, you can set TC_ENABLED=Shared. This allows
# you to configure the tcdevices and tcclasses in your Shorewall6
# configuration yet make them available to the compiler when compiling your
# Shorewall configuration. In addition to setting TC_ENABLED=Shared, you need
# to create symbolic links from your Shorewall configuration directory
# (normally /etc/shorewall/) to the tcdevices and tcclasses files in your
# Shorewall6 configuration directory (normally /etc/shorewall6/).
#
TC_EXPERT=No
#
# TC_EXPERT={Yes|No}
#
# Normally, Shorewall tries to protect users from themselves by preventing
# PREROUTING and OUTPUT tcrules from being applied to packets that have been
# marked by the 'track' option in shorewall-providers(5).
#
# If you know what you are doing, you can set TC_EXPERT=Yes and Shorewall
# will not include these cautionary checks.
#
TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2"
#
# TC_PRIOMAP=map
#
# Added in Shorewall 4.4.6. Determines the mapping of a packet's TOS field to
# priority bands. See shorewall-tcpri(5). The map consists of 16
# space-separated digits with values 1, 2 or 3. A value of 1 corresponds to
# Linux priority 0, 2 to Linux priority 1, and 3 to Linux Priority 2. The
# first entry gives the priority of TOS value 0, the second of TOS value 1,
# and so on. See tc-prio(8) for additional information.
#
# The default setting is TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2".
#
TRACK_PROVIDERS=Yes
#
# TRACK_PROVIDERS={Yes|No}
#
# Added in Shorewall 4.4.3. When set to Yes, causes the track option to be
# assumed on all providers defined in shorewall-providers(5). May be
# overridden on an individual provider through use of the notrack option. The
# default value is 'No'.
#
# Beginning in Shorewall 4.4.6, setting this option to 'Yes' also simplifies
# PREROUTING rules in shorewall-tcrules(5). Previously, when TC_EXPERT=No,
# packets arriving through 'tracked' provider interfaces were unconditionally
# passed to the PREROUTING tcrules. This was done so that tcrules could reset
# the packet mark to zero, thus allowing the packet to be routed using the
# 'main' routing table. Using the main table allowed dynamic routes (such as
# those added for VPNs) to be effective. The rtrules file was created to
# provide a better alternative to clearing the packet mark. As a consequence,
# passing these packets to PREROUTING complicates things without providing
# any real benefit. Beginning with Shorewall 4.4.6, when TRACK_PROVIDERS=Yes
# and TC_EXPERT=No, packets arriving through 'tracked' interfaces will not be
# passed to the PREROUTING rules. Since TRACK_PROVIDERS was just introduced
# in 4.4.3, this change should be transparent to most, if not all, users.
#
TRACK_RULES=No
#
# TRACK_RULES={Yes|No|File}
#
# Added in Shorewall 4.5.20. If set to Yes, causes the compiler to add a
# comment to iptables rules to indicate the file name and line number of the
# configuration entry that generated the rule. If set to No (the default),
# then no such comments are added.
#
# Setting this option to Yes requires the Comments capability in iptables and
# kernel.
#
# Beginning with Shorewall 5.0.5, the option may also be set to File. That
# setting causes similar comments to be added to the .iptables-restore-input
# file, which is normally created in /var/lib/shorewall.
#
USE_DEFAULT_RT=Yes
#
# USE_DEFAULT_RT=[Yes|No]
#
# When set to 'Yes', this option causes the Shorewall multi-ISP feature to
# create a set of routing rules which are resilient to changes in the main
# routing table. Such changes can occur for a number of reasons, VPNs going
# up and down being an example. The idea is to send packets through the main
# table prior to applying any of the Shorewall-generated routing rules. So
# changes to the main table will affect the routing of packets by default.
#
# When USE_DEFAULT_RT=Yes:
#
# 1. Both the DUPLICATE and the COPY columns in providers(5) file must
# remain empty (or contain "-").
#
# 2. The default route is added to the the 'default' table rather than to
# the main table.
#
# 3. If running Shorewall 5.1.0 or earlier or if BALANCE_PROVIDERS=Yes
# (Shorewall 5.1.1 or later), then the balance provider option is assumed
# unless the fallback, loose, load or tproxy option is specified.
#
# 4. Packets are sent through the main routing table by a rule with priority
# 999. In shorewall-rtrules(5), the range 1-998 may be used for inserting
# rules that bypass the main table.
#
# 5. All provider gateways must be specified explicitly in the GATEWAY
# column. detect may not be specified.
#
# Note
#
# detect may be specified for interfaces whose configuration is managed
# by dhcpcd. Shorewall will use dhcpcd's database to find the interface's
# gateway.
#
# 6. You should disable all default route management outside of Shorewall.
# If a default route is added to the main table while Shorewall is
# started, then all policy routing will stop working (except for those
# routing rules in the priority range 1-998).
#
# Prior to Shorewall 4.6.0, if USE_DEFAULT_RT was not set or if it was set to
# the empty string then USE_DEFAULT_RT=No was assumed. Beginning with
# Shorewall 4.6.0, the default is USE_DEFAULT_RT=Yes and use of
# USE_DEFAULT_RT=No is deprecated.
#
# Warning
#
# The enable, disable and reenable commands do not work correctly when
# USE_DEFAULT_RT=No.
#
USE_NFLOG_SIZE=No
#
# USE_NFLOG_SIZE=[Yes|No]
#
# Added in Shorewall 5.1.5. The second parameter to the NFLOG target
# specifies how many bytes of the packet to copy to the log; if omitted or if
# supplied as zero, the entire packet is copied. This feature has
# traditionally been implemented using the --nflog-range option to the NFLOG
# iptables target. Unfortuntely, the --nflog-range option never worked (the
# entire packet was always copied). To deal with this issue, the Netfilter
# team:
#
# □ Added a warning message when --nflog-range is used
#
# □ Added --nflog-size which works like --nflog-range was intended to work.
#
# When USE_NFLOG_SIZE=Yes, Shorewall will attempt to use the new --nflog-size
# feature. If that feature is not available in the running kernel and ip[6]
# tables, an error is raised.
#
# When USE_NFLOG_SIZE is not supplied, USE_NFLOG_SIZE=No is assumed. When
# USE_NFLOG_SIZE is added by shorewall update, it is added with setting No.
#
USE_PHYSICAL_NAMES=No
#
# USE_PHYSICAL_NAMES=[Yes|No]
#
# Added in Shorewall 4.4.27. Normally, when Shorewall creates a Netfilter
# chain that relates to an interface, it uses the interface's logical name as
# the base of the chain name. For example, if the logical name for an
# interface is OAKLAND, then the input chain for traffic arriving on that
# interface would be 'OAKLAND_in'. If this option is set to Yes, then the
# physical name of the interface will be used the base of the chain name.
#
USE_RT_NAMES=No
#
# USE_RT_NAMES=[Yes|No]
#
# Added in Shorewall 4.5.15. When set to 'Yes', Shorewall will use routing
# table (provider) names in the generated script rather than table numbers.
# When set to 'No' (the default), routing table numbers will be used.
#
# Caution
#
# If you set USE_RT_NAMES=Yes and KEEP_RT_TABLES=Yes, then you must insure
# that all of your providers have entries in /etc/iproute2/rt_tables as well
# as the following entries:
#
# 255 local
# 254 main
# 253 default
# 250 balance
# 0 unspec
#
# Without these entries, the firewall will fail to start.
#
VERBOSE_MESSAGES=Yes
#
# VERBOSE_MESSAGES=[Yes|No]
#
# Added in Shorewall 5.0.9. When Yes (the default), messages produced by the
# ?INFO and ?WARNING directives include the filename and linenumber of the
# directive. When set to No, that additional information is omitted. The
# setting may be overridden on a directive by directive basis by following ?
# INFO or ?WARNING with '!' (no intervening white space).
#
WARNOLDCAPVERSION=Yes
#
# WARNOLDCAPVERSION=[Yes|No]
#
# Added in Shorewall 4.5.12. When set to Yes (the default), the compiler
# issues a warning when it finds a capabilities file that doesn't specify all
# of the capabilities supported by the compiler. When WARNOLDCAPVERSION is
# set to No, no warning is issued.
#
WORKAROUNDS=No
#
# WORKAROUNDS=[Yes|No]
#
# Added in Shorewall 4.6.11. Over time, there have been a number of changes
# in Shorewall that work around defects in other products such as iptables
# and ipset. When WORKAROUNDS=Yes, these workarounds are enabled; when
# WORKAROUNDS=No, they are disabled. If not specified or if specified as
# empty, WORKAROUNDS=Yes is assumed.
#
# Warning
#
# Do not set WORKAROUNDS=Yes if you need to be able to use
# Shorewall-generated scripts (such as created by the save command) built by
# Shorewall 4.4.7 or older.
#
ZERO_MARKS=No
#
# ZERO_MARKS=[Yes|No]
#
# Added in Shorewall 5.0.12, this is a workaround for an issue where packet
# marks are not zeroed by the kernel. It should be set to No (the default)
# unless you find that incoming packets are being mis-routed for no apparent
# reasons.
#
# Caution
#
# Do not set this option to Yes if you have IPSEC software running on the
# firewall system.
#
ZONE2ZONE=-
#
# ZONE2ZONE=[2|-]
#
# Added in Shorewall 4.4.4. This option determines how Shorewall constructs
# chain names involving zone names and/or 'all'. Beginning with Shorewall
# 4.6.0, the default is '-' (e.g., fw-net); prior to that release, the
# default was '2' (e.g., fw2net).
#
###############################################################################
# P A C K E T D I S P O S I T I O N
###############################################################################
BLACKLIST_DISPOSITION=DROP
#
# BLACKLIST_DISPOSITION=[DROP|A_DROP|REJECT|A_REJECT]
#
# This parameter determines the disposition of packets from blacklisted
# hosts. It may have the value DROP if the packets are to be dropped or
# REJECT if the packets are to be replied with an ICMP port unreachable reply
# or a TCP RST (tcp only). If you do not assign a value or if you assign an
# empty value then DROP is assumed.
#
# A_DROP and A_REJECT are audited versions of DROP and REJECT respectively
# and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel
# and iptables.
#
# The BLACKLIST_DISPOSITION setting determines the disposition of packets
# sent to the blacklog target of shorewall-blrules (5), but otherwise does
# not affect entries in that file.
#
INVALID_DISPOSITION=CONTINUE
#
# INVALID_DISPOSITION=[A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
#
# Added in Shorewall 4.5.13. Shorewall has traditionally passed INVALID
# packets through the NEW section of shorewall-rules (5). When a packet in
# INVALID state fails to match any rule in the INVALID section, the packet is
# disposed of based on this setting. The default value is CONTINUE for
# compatibility with earlier versions.
#
MACLIST_DISPOSITION=REJECT
#
# MACLIST_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]
#
# Determines the disposition of connections requests that fail MAC
# Verification and must have the value ACCEPT (accept the connection request
# anyway), REJECT (reject the connection request) or DROP (ignore the
# connection request). If not set or if set to the empty value (e.g.,
# MACLIST_DISPOSITION="") then MACLIST_DISPOSITION=REJECT is assumed.
#
# A_DROP and A_REJECT are audited versions of DROP and REJECT respectively
# and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel
# and ip[6]tables.
#
RELATED_DISPOSITION=ACCEPT
#
# RELATED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
#
# Added in Shorewall 4.4.27. Shorewall has traditionally ACCEPTed RELATED
# packets that don't match any rule in the RELATED section of shorewall-rules
# (5). Concern about the safety of this practice resulted in the addition of
# this option. When a packet in RELATED state fails to match any rule in the
# RELATED section, the packet is disposed of based on this setting. The
# default value is ACCEPT for compatibility with earlier versions.
#
SFILTER_DISPOSITION=DROP
#
# SFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]
#
# Added in Shorewall 4.4.20. Determines the disposition of packets matching
# the sfilter option (see shorewall-interfaces(5)) and of hairpin packets on
# interfaces without the routeback option.^[1]
#
RPFILTER_DISPOSITION=DROP
#
# RPFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]
#
# Added in Shorewall 4.5.7. Determines the disposition of packets entering
# from interfaces the rpfilter option (see shorewall-interfaces(5)). Packets
# disposed of by this option are those whose response packets would not be
# sent through the same interface receiving the packet.
#
SMURF_DISPOSITION=DROP
#
# SMURF_DISPOSITION=[DROP|A_DROP]
#
# Added in Shorewall 4.4.20. The default setting is DROP which causes smurf
# packets (see the nosmurfs option in shorewall-interfaces(5)) to be dropped.
# A_DROP causes the packets to be audited prior to being dropped and requires
# AUDIT_TARGET support in the kernel and iptables.
#
TCP_FLAGS_DISPOSITION=DROP
#
# TCP_FLAGS_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]
#
# Determines the disposition of TCP packets that fail the checks enabled by
# the tcpflags interface option (see shorewall-interfaces(5)) and must have a
# value of ACCEPT (accept the packet), REJECT (send an RST response) or DROP
# (ignore the packet). If not set or if set to the empty value (e.g.,
# TCP_FLAGS_DISPOSITION="") then TCP_FLAGS_DISPOSITION=DROP is assumed.
#
# A_DROP and A_REJECT are audited versions of DROP and REJECT respectively
# and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel
# and iptables.
#
UNTRACKED_DISPOSITION=CONTINUE
#
# UNTRACKED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
#
# Added in Shorewall 4.5.13. Shorewall has traditionally passed UNTRACKED
# packets through the NEW section of shorewall-rules (5). When a packet in
# UNTRACKED state fails to match any rule in the UNTRACKED section, the
# packet is disposed of based on this setting. The default value is CONTINUE
# for compatibility with earlier versions.
#
################################################################################
# P A C K E T M A R K L A Y O U T
################################################################################
TC_BITS=
#
# TC_BITS=[number]
#
# The number of bits at the low end of the 32-bit packet mark to be used for
# traffic shaping marking. May be zero. See MASK_BITS above for default
# value.
#
PROVIDER_BITS=
#
# PROVIDER_BITS=[number]
#
# Added in Shorewall 4.4.26. The number of bits in the 32-bit packet mark to
# be used for provider numbers. May be zero. See MASK_BITS above for default
# value.
#
PROVIDER_OFFSET=
#
# PROVIDER_OFFSET=[number]If
#
# Added in Shorewall 4.4.26. The offset from the right (low-order end) of the
# provider number field in the 32-bit packet mark. If non-zero, must be >=
# TC_BITS (Shorewall automatically adjusts PROVIDER_OFFSET's value).
# PROVIDER_OFFSET + PROVIDER_BITS + ZONE_BITS must be < 32. See MASK_BITS
# above for default value.
#
MASK_BITS=
#
# MASK_BITS=[number]
#
# Added in Shorewall 4.4.26. Number of bits on the right of the 32-bit packet
# mark to be masked when clearing the traffic shaping mark. Must be >=
# TC_BITS and <= PROVIDER_OFFSET (if PROVIDER_OFFSET > 0). Prior to Shorewall
# 5.0.0, default value and the default values of the other mark layout
# options is determined as follows:
#
# Table 1. Default Packet Mark Layout
#
# WIDE_TC_MARKS=No, TC_BITS=8, PROVIDER_BITS=8, PROVIDER_OFFSET=
# HIGH_ROUTE_MARKS=No 0, MASK_BITS=8
# WIDE_TC_MARKS=No, TC_BITS=8, PROVIDER_BITS=8, PROVIDER_OFFSET=
# HIGH_ROUTE_MARKS=Yes 8, MASK_BITS=8
# WIDE_TC_MARKS=Yes, TC_BITS=14, PROVIDER_BITS=8, PROVIDER_OFFSET=
# HIGH_ROUTE_MARKS=No 0, MASK_BITS=16
# WIDE_TC_MARKS=Yes, TC_BITS=14, PROVIDER_BITS=8, PROVIDER_OFFSET=
# HIGH_ROUTE_MARKS=Yes 16, MASK_BITS=16
#
#
# From 5.0.0 onward, the default value of MASK_BITS is 8, the default value
# of PROVIDER_BITS, TC_BITS, MASK_BITS and PROVIDER_OFFSET is 8.
#
ZONE_BITS=0
#
# ZONE_BITS=[number]
#
# Added in Shorewall 4.4.26. When non-zero, enables automatic packet marking
# by source zone and determines the number of bits in the 32-bit packet mark
# to be used for the zone mark. Default value is 0.
#
shorewall6-5.2.3.4/Samples6/two-interfaces/shorewall6.conf 0000664 0000000 0000000 00000012074 13531060406 022034 0 ustar root root ###############################################################################
#
# Shorewall Version 4 -- /etc/shorewall6/shorewall6.conf
#
# For information about the settings in this file, type "man shorewall6.conf"
#
# Manpage also online at
# http://www.shorewall.net/manpages6/shorewall6.conf.html
###############################################################################
# S T A R T U P E N A B L E D
###############################################################################
STARTUP_ENABLED=No
###############################################################################
# V E R B O S I T Y
###############################################################################
VERBOSITY=1
###############################################################################
# P A G E R
###############################################################################
PAGER=
###############################################################################
# F I R E W A L L
###############################################################################
FIREWALL=
###############################################################################
# L O G G I N G
###############################################################################
LOG_LEVEL="info"
BLACKLIST_LOG_LEVEL=
INVALID_LOG_LEVEL=
LOG_BACKEND=
LOG_VERBOSITY=2
LOG_ZONE=Both
LOGALLNEW=
LOGFILE=/var/log/messages
LOGFORMAT="%s %s "
LOGLIMIT="s:1/sec:10"
LOGTAGONLY=No
MACLIST_LOG_LEVEL="$LOG_LEVEL"
RELATED_LOG_LEVEL=
RPFILTER_LOG_LEVEL="$LOG_LEVEL"
SFILTER_LOG_LEVEL="$LOG_LEVEL"
SMURF_LOG_LEVEL="$LOG_LEVEL"
STARTUP_LOG=/var/log/shorewall6-init.log
TCP_FLAGS_LOG_LEVEL="$LOG_LEVEL"
UNTRACKED_LOG_LEVEL=
###############################################################################
# L O C A T I O N O F F I L E S A N D D I R E C T O R I E S
###############################################################################
CONFIG_PATH=":${CONFDIR}/shorewall6:${SHAREDIR}/shorewall6:${SHAREDIR}/shorewall"
GEOIPDIR=/usr/share/xt_geoip/LE
IP6TABLES=
IP=
IPSET=
LOCKFILE=
MODULESDIR=
NFACCT=
PERL=/usr/bin/perl
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
RESTOREFILE=restore
SHOREWALL_SHELL=/bin/sh
SUBSYSLOCK=
TC=
###############################################################################
# D E F A U L T A C T I O N S / M A C R O S
###############################################################################
ACCEPT_DEFAULT="none"
BLACKLIST_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP),dropNotSyn:$LOG_LEVEL,dropInvalid:$LOG_LEVEL,DropDNSrep:$LOG_LEVEL"
DROP_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)"
NFQUEUE_DEFAULT="none"
QUEUE_DEFAULT="none"
REJECT_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)"
###############################################################################
# R S H / R C P C O M M A N D S
###############################################################################
RCP_COMMAND='scp ${files} ${root}@${system}:${destination}'
RSH_COMMAND='ssh ${root}@${system} ${command}'
###############################################################################
# F I R E W A L L O P T I O N S
###############################################################################
ACCOUNTING=Yes
ACCOUNTING_TABLE=filter
ADMINISABSENTMINDED=Yes
AUTOCOMMENT=Yes
AUTOHELPERS=Yes
AUTOMAKE=Yes
BALANCE_PROVIDERS=No
BASIC_FILTERS=No
BLACKLIST="NEW,INVALID,UNTRACKED"
CLAMPMSS=No
CLEAR_TC=No
COMPLETE=No
DEFER_DNS_RESOLUTION=Yes
DELETE_THEN_ADD=Yes
DONT_LOAD=
DYNAMIC_BLACKLIST=Yes
EXPAND_POLICIES=Yes
EXPORTMODULES=Yes
FASTACCEPT=No
FORWARD_CLEAR_MARK=
HELPERS=
IGNOREUNKNOWNVARIABLES=No
IMPLICIT_CONTINUE=No
IPSET_WARNINGS=Yes
IP_FORWARDING=Keep
KEEP_RT_TABLES=Yes
MACLIST_TABLE=filter
MACLIST_TTL=
MANGLE_ENABLED=Yes
MARK_IN_FORWARD_CHAIN=No
MINIUPNPD=No
MUTEX_TIMEOUT=60
OPTIMIZE=All
OPTIMIZE_ACCOUNTING=No
PERL_HASH_SEED=0
REJECT_ACTION=
RENAME_COMBINED=Yes
REQUIRE_INTERFACE=No
RESTART=restart
RESTORE_DEFAULT_ROUTE=Yes
RESTORE_ROUTEMARKS=Yes
SAVE_IPSETS=No
TC_ENABLED=Shared
TC_EXPERT=No
TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2"
TRACK_PROVIDERS=Yes
TRACK_RULES=No
USE_DEFAULT_RT=Yes
USE_NFLOG_SIZE=No
USE_PHYSICAL_NAMES=No
USE_RT_NAMES=No
VERBOSE_MESSAGES=Yes
WARNOLDCAPVERSION=Yes
WORKAROUNDS=No
ZERO_MARKS=No
ZONE2ZONE=-
###############################################################################
# P A C K E T D I S P O S I T I O N
###############################################################################
BLACKLIST_DISPOSITION=DROP
INVALID_DISPOSITION=CONTINUE
MACLIST_DISPOSITION=REJECT
RELATED_DISPOSITION=ACCEPT
SFILTER_DISPOSITION=DROP
RPFILTER_DISPOSITION=DROP
SMURF_DISPOSITION=DROP
TCP_FLAGS_DISPOSITION=DROP
UNTRACKED_DISPOSITION=CONTINUE
################################################################################
# P A C K E T M A R K L A Y O U T
################################################################################
TC_BITS=
PROVIDER_BITS=
PROVIDER_OFFSET=
MASK_BITS=
ZONE_BITS=0
shorewall6-5.2.3.4/Samples6/two-interfaces/params 0000664 0000000 0000000 00000001444 13531060406 020304 0 ustar root root #
# Shorewall - Sample Params File for two-interface configuration.
# Copyright (C) 2006-2017 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------------------------------------
# For information on entries in this file, type "man shorewall-params"
######################################################################################################################################################################################################
shorewall6-5.2.3.4/Samples6/README.txt 0000664 0000000 0000000 00000002170 13531060406 015637 0 ustar root root For instructions on using these sample configurations, please see
http://www.shorewall.net/shorewall_quickstart_guide.htm
Shorewall Samples
Copyright (C) 2006 by the following authors:
Thomas M. Eastep
Paul D. Gear
Cristian Rodriguez
Francesca Smith
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
02110-1301 USA
Sample files are licensed under the LGPL, please see the LICENSE file or
http://www.gnu.org/licenses/lgpl.html for more details.
shorewall6-5.2.3.4/Samples6/one-interface/ 0000775 0000000 0000000 00000000000 13531077657 016700 5 ustar root root shorewall6-5.2.3.4/Samples6/one-interface/rules 0000664 0000000 0000000 00000002466 13531060406 017745 0 ustar root root #
# Shorewall6 version 5 - Sample Rules File for one-interface configuration.
# Copyright (C) 2006-2015 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------------------------------------
# For information on entries in this file, type "man shorewall6-rules"
######################################################################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER
# PORT PORT(S) DEST LIMIT GROUP
?SECTION ALL
?SECTION ESTABLISHED
?SECTION RELATED
?SECTION INVALID
?SECTION UNTRACKED
?SECTION NEW
# Drop packets in the INVALID state
Invalid(DROP) net $FW tcp
# Drop Ping from the "bad" net zone.. and prevent your log from being flooded..
Ping(DROP) net $FW
# Permit all ICMP traffic FROM the firewall TO the net zone
ACCEPT $FW net ipv6-icmp
shorewall6-5.2.3.4/Samples6/one-interface/zones 0000664 0000000 0000000 00000001353 13531060406 017743 0 ustar root root #
# Shorewall6 version 5 - Sample Zones File for one-interface IPv6 configuration.
# Copyright (C) 2006-2015 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#-----------------------------------------------------------------------------
# For information about entries in this file, type "man shorewall6-zones"
###############################################################################
#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
fw firewall
net ipv6
shorewall6-5.2.3.4/Samples6/one-interface/zones.annotated 0000664 0000000 0000000 00000021500 13531077657 021733 0 ustar root root #
# Shorewall6 version 5 - Sample Zones File for one-interface IPv6 configuration.
# Copyright (C) 2006-2015 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#-----------------------------------------------------------------------------
# For information about entries in this file, type "man shorewall6-zones"
###############################################################################
#
# The /etc/shorewall/zones file declares your network zones. You specify the
# hosts in each zone through entries in /etc/shorewall/interfaces or /etc/
# shorewall/hosts.
#
# The columns in the file are as follows (where the column name is followed by a
# different name in parentheses, the different name is used in the alternate
# specification syntax).
#
# ZONE - zone[:parent-zone[,parent-zone]...]
#
# Name of the zone. Must start with a letter and consist of letters, digits
# or '_'. The names "all", "none", "any", "SOURCE" and "DEST" are reserved
# and may not be used as zone names. The maximum length of a zone name is
# determined by the setting of the LOGFORMAT option in shorewall.conf(5).
# With the default LOGFORMAT, zone names can be at most 5 characters long.
#
# The maximum length of an iptables log prefix is 29 bytes. As explained
# in shorewall.conf (5), the legacy default LOGPREFIX formatting string
# is “Shorewall:%s:%s:” where the first %s is replaced by the chain name
# and the second is replaced by the disposition.
#
# ☆ The "Shorewall:%s:%s:" formatting string has 12 fixed characters
# ("Shorewall" and three colons).
#
# ☆ The longest of the standard dispositions are ACCEPT and REJECT
# which have 6 characters each.
#
# ☆ The canonical name for the chain containing the rules for traffic
# going from zone 1 to zone 2 is "2" or "-
# ".
#
# ☆ So if M is the maximum zone name length, such chains can have
# length 2*M + 1.
#
# 12 + 6 + 2*M + 1 = 29 which reduces to
# 2*M = 29 - 12 - 6 - 1 = 10 or
# M = 5
#
# In Shorewall 5.1.0, the LOGFORMAT in the default and sample
# shorewall.conf files was changed to "%s:%s ".
#
# ☆ That formatting string has 2 fixed characters (":" and a space).
#
# ☆ So the maximum zone name length M is calculated as:
#
# 2 + 6 + 2*M + 1 = 29
# 2M = 29 - 2 - 6 - 1 = 20
# M = 10
#
# The order in which Shorewall matches addresses from packets to zones is
# determined by the order of zone declarations. Where a zone is nested in one
# or more other zones, you may either ensure that the nested zone precedes
# its parents in this file, or you may follow the (sub)zone name by ":" and a
# comma-separated list of the parent zones. The parent zones must have been
# declared in earlier records in this file. See shorewall-nesting(5) for
# additional information.
#
# Example:
#
# #ZONE TYPE OPTIONS IN OPTIONS OUT OPTIONS
# a ip
# b ip
# c:a,b ip
#
# Currently, Shorewall uses this information to reorder the zone list so that
# parent zones appear after their subzones in the list. The IMPLICIT_CONTINUE
# option in shorewall.conf(5) can also create implicit CONTINUE policies to/
# from the subzone.
#
# Where an ipsec zone is explicitly included as a child of an ip zone, the
# ruleset allows CONTINUE policies (explicit or implicit) to work as
# expected.
#
# In the future, Shorewall may make additional use of nesting information.
#
# TYPE
#
# ip
#
# This is the standard Shorewall zone type and is the default if you
# leave this column empty or if you enter "-" in the column.
# Communication with some zone hosts may be encrypted. Encrypted hosts
# are designated using the 'ipsec' option in shorewall-hosts(5). For
# clarity, this zone type may be specified as ipv4 in IPv4 configurations
# and ipv6 in IPv6 configurations.
#
# ipsec
#
# Communication with all zone hosts is encrypted. Your kernel and
# iptables must include policy match support. For clarity, this zone type
# may be specified as ipsec4 in IPv4 configurations and ipsec6 in IPv6
# configurations.
#
# firewall
#
# Designates the firewall itself. You must have exactly one 'firewall'
# zone. No options are permitted with a 'firewall' zone. The name that
# you enter in the ZONE column will be stored in the shell variable $FW
# which you may use in other configuration files to designate the
# firewall zone.
#
# bport
#
# The zone is associated with one or more ports on a single bridge. For
# clarity, this zone type may be specified as bport4 in IPv4
# configurations and bport6 in IPv6 configurations.
#
# vserver
#
# Added in Shorewall 4.4.11 Beta 2 - A zone composed of Linux-vserver
# guests. The zone contents must be defined in shorewall-hosts (5).
#
# Vserver zones are implicitly handled as subzones of the firewall zone.
#
# loopback
#
# Added in Shorewall 4.5.17.
#
# Normally, Shorewall treats the loopback interface (lo) in the following
# way:
#
# ☆ By default, all traffic through the interface is ACCEPTed.
#
# ☆ If a $FW -> $FW policy is defined or $FW -> $FW rules are defined,
# they are placed in a chain named ${FW}2${F2} or ${FW}-${FW} (e.g.,
# 'fw2fw' or 'fw-fw' ) depending on the ZONE2ZONE setting in
# shorewall.conf(5).
#
# ☆ $FW -> $FW traffic is only filtered in the OUTPUT chain.
#
# By defining a loopback zone and associating it with the loopback
# interface in shorewall-interfaces(5), you can effect a slightly
# different model. Suppose that the loopback zone name is 'local'; then:
#
# ☆ Both $FW -> local and local -> $FW chains are created.
#
# ☆ The $FW -> local and local -> $FW policies may be different.
#
# ☆ Both $FW -> local and local -> $FW rules may be specified.
#
# Rules to/from the loopback zone and any zone other than the firewall
# zone are ignored with a warning.
#
# loopback zones may be nested within other loopback zones.
#
# local
#
# Added in Shorewall 4.5.17. local is the same as ipv4 with the exception
# that the zone is only accessible from the firewall and vserver zones.
#
# OPTIONS, IN OPTIONS and OUT OPTIONS (options, in_options, out_options) - [
# option[,option]...]
#
# A comma-separated list of options. With the exception of the mss and
# blacklist options, these only apply to TYPE ipsec zones.
#
# dynamic_shared
#
# Added in Shorewall 4.5.9. May only be specified in the OPTIONS column
# and indicates that only a single ipset should be created for this zone
# if it has multiple dynamic entries in shorewall-hosts(5). Without this
# option, a separate ipset is created for each interface.
#
# reqid=number
#
# where number is specified using setkey(8) using the 'unique:number
# option for the SPD level.
#
# spi=
#
# where number is the SPI of the SA used to encrypt/decrypt packets.
#
# proto=ah|esp|ipcomp
#
# IPSEC Encapsulation Protocol
#
# mss=number
#
# sets the MSS field in TCP packets. If you supply this option, you
# should also set FASTACCEPT=No in shorewall.conf(5) to insure that both
# the SYN and SYN,ACK packets have their MSS field adjusted.
#
# mode=transport|tunnel
#
# IPSEC mode
#
# 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
#
# 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 "-".
#
###############################################################################
#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
fw firewall
net ipv6
shorewall6-5.2.3.4/Samples6/one-interface/interfaces.annotated 0000664 0000000 0000000 00000061543 13531077655 022731 0 ustar root root #
# Shorewall6 - Sample Interfaces File for one-interface configuration.
# Copyright (C) 2006-2017 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------
# For information about entries in this file, type "man shorewall6-interfaces"
###############################################################################
#
# The interfaces file serves to define the firewall's network interfaces to
# Shorewall. The order of entries in this file is not significant in determining
# zone composition.
#
# Beginning with Shorewall 4.5.3, the interfaces file supports two different
# formats:
#
# FORMAT 1 (default - deprecated)
#
# There is a BROADCAST column which can be used to specify the broadcast
# address associated with the interface.
#
# FORMAT 2
#
# The BROADCAST column is omitted.
#
# The format is specified by a line as follows:
#
# ?FORMAT {1|2}
#
# The columns in the file are as follows.
#
# ZONE - zone-name
#
# Zone for this interface. Must match the name of a zone declared in /etc/
# shorewall/zones. You may not list the firewall zone in this column.
#
# If the interface serves multiple zones that will be defined in the
# shorewall-hosts(5) file, you should place "-" in this column.
#
# If there are multiple interfaces to the same zone, you must list them in
# separate entries.
#
# Example:
#
# #ZONE INTERFACE BROADCAST
# loc eth1 -
# loc eth2 -
#
# INTERFACE - interface[:port]
#
# Logical name of interface. Each interface may be listed only once in this
# file. You may NOT specify the name of a "virtual" interface (e.g., eth0:0)
# here; see http://www.shorewall.net/FAQ.htm#faq18. If the physical option is
# not specified, then the logical name is also the name of the actual
# interface.
#
# You may use wildcards here by specifying a prefix followed by the plus sign
# ("+"). For example, if you want to make an entry that applies to all PPP
# interfaces, use 'ppp+'; that would match ppp0, ppp1, ppp2, …
#
# When using Shorewall versions before 4.1.4, care must be exercised when
# using wildcards where there is another zone that uses a matching specific
# interface. See shorewall-nesting(5) for a discussion of this problem.
#
# Shorewall allows '+' as an interface name, but that usage is deprecated. A
# better approach is to specify 'physical=+' in the OPTIONS column (see
# below).
#
# There is no need to define the loopback interface (lo) in this file.
#
# If a port is given, then the interface must have been defined previously
# with the bridge option. The OPTIONS column may not contain the following
# options when a port is given.
#
# arp_filter
# arp_ignore
# bridge
# log_martians
# mss
# optional
# proxyarp
# required
# routefilter
# sourceroute
# upnp
# wait
#
# Beginning with Shorewall 4.5.17, if you specify a zone for the 'lo'
# interface, then that zone must be defined as type local in shorewall6-zones
# (5).
#
# BROADCAST (Optional) - {-|detect|address[,address]...}
#
# Only available if FORMAT 1.
#
# If you use the special value detect, Shorewall will detect the broadcast
# address(es) for you if your iptables and kernel include Address Type Match
# support.
#
# If your iptables and/or kernel lack Address Type Match support then you may
# list the broadcast address(es) for the network(s) to which the interface
# belongs. For P-T-P interfaces, this column is left blank. If the interface
# has multiple addresses on multiple subnets then list the broadcast
# addresses as a comma-separated list.
#
# If you don't want to give a value for this column but you want to enter a
# value in the OPTIONS column, enter - in this column.
#
# OPTIONS (Optional) - [option[,option]...]
#
# A comma-separated list of options from the following list. The order in
# which you list the options is not significant but the list should have no
# embedded white-space.
#
# accept_ra[={0|1|2}]
#
# IPv6 only; added in Shorewall 4.5.16. Values are:
#
# 0
#
# Do not accept Router Advertisements.
#
# 1
#
# Accept Route Advertisements if forwarding is disabled.
#
# 2
#
# Overrule forwarding behavior. Accept Route Advertisements even if
# forwarding is enabled.
#
# If the option is specified without a value, then the value 1 is
# assumed.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# arp_filter[={0|1}]
#
# IPv4 only. If specified, this interface will only respond to ARP
# who-has requests for IP addresses configured on the interface. If not
# specified, the interface can respond to ARP who-has requests for IP
# addresses on any of the firewall's interface. The interface must be up
# when Shorewall is started.
#
# Only those interfaces with the arp_filter option will have their
# setting changed; the value assigned to the setting will be the value
# specified (if any) or 1 if no value is given.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# arp_ignore[=number]
#
# IPv4 only. If specified, this interface will respond to arp requests
# based on the value of number (defaults to 1).
#
# 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 the sender's IP address is part from same
# subnet on this interface's address
#
# 3 - do not reply for local addresses configured with scope host, only
# resolutions for global and link
#
# 4-7 - reserved
#
# 8 - do not reply for all local addresses
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# Warning
#
# Do not specify arp_ignore for any interface involved in Proxy ARP.
#
# blacklist
#
# Checks packets arriving on this interface against the
# shorewall-blacklist(5) file.
#
# Beginning with Shorewall 4.4.13:
#
# ☆ If a zone is given in the ZONES column, then the behavior is as if
# blacklist had been specified in the IN_OPTIONS column of
# shorewall-zones(5).
#
# ☆ Otherwise, the option is ignored with a warning:
#
# WARNING: The 'blacklist' option is ignored on multi-zone
# interfaces
#
# bridge
#
# Designates the interface as a bridge. Beginning with Shorewall 4.4.7,
# setting this option also sets routeback.
#
# Note
#
# If you have a bridge that you don't intend to define bport zones on,
# then it is best to omit this option and simply specify routeback.
#
# dbl={none|src|dst|src-dst}
#
# Added in Shorewall 5.0.10. This option defined whether or not dynamic
# blacklisting is applied to packets entering the firewall through this
# interface and whether the source address and/or destination address is
# to be compared against the ipset-based dynamic blacklist
# (DYNAMIC_BLACKLIST=ipset... in shorewall.conf(5)). The default is
# determine by the setting of DYNAMIC_BLACKLIST:
#
# DYNAMIC_BLACKLIST=No
#
# Default is none (e.g., no dynamic blacklist checking).
#
# DYNAMIC_BLACKLIST=Yes
#
# Default is src (e.g., the source IP address is checked).
#
# DYNAMIC_BLACKLIST=ipset[-only]
#
# Default is src.
#
# DYNAMIC_BLACKLIST=ipset[-only],src-dst...
#
# Default is src-dst (e.g., the source IP addresses in checked
# against the ipset on input and the destination IP address is
# checked against the ipset on packets originating from the firewall
# and leaving through this interface).
#
# The normal setting for this option will be dst or none for internal
# interfaces and src or src-dst for Internet-facing interfaces.
#
# destonly
#
# Added in Shorewall 4.5.17. Causes the compiler to omit rules to handle
# traffic from this interface.
#
# dhcp
#
# Specify this option when any of the following are true:
#
# 1. the interface gets its IP address via DHCP
#
# 2. the interface is used by a DHCP server running on the firewall
#
# 3. the interface has a static IP but is on a LAN segment with lots of
# DHCP clients.
#
# 4. the interface is a simple bridge with a DHCP server on one port and
# DHCP clients on another port.
#
# Note
#
# If you use Shorewall-perl for firewall/bridging, then you need to
# include DHCP-specific rules in shorewall-rules(5). DHCP uses UDP
# ports 67 and 68.
#
# This option allows DHCP datagrams to enter and leave the interface.
#
# forward[={0|1}]
#
# IPv6 only Sets the /proc/sys/net/ipv6/conf/interface/forwarding option
# to the specified value. If no value is supplied, then 1 is assumed.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# ignore[=1]
#
# When specified, causes the generated script to ignore up/down events
# from Shorewall-init for this device. Additionally, the option exempts
# the interface from hairpin filtering. When '=1' is omitted, the ZONE
# column must contain '-' and ignore must be the only OPTION.
#
# Beginning with Shorewall 4.5.5, may be specified as 'ignore=1' which
# only causes the generated script to ignore up/down events from
# Shorewall-init; hairpin filtering is still applied. In this case, the
# above restrictions on the ZONE and OPTIONS columns are lifted.
#
# loopback
#
# Added in Shorewall 4.6.6. Designates the interface as the loopback
# interface. This option is assumed if the interface's physical name is
# 'lo'. Only one interface man have the loopback option specified.
#
# logmartians[={0|1}]
#
# IPv4 only. Turn on kernel martian logging (logging of packets with
# impossible source addresses. It is strongly suggested that if you set
# routefilter on an interface that you also set logmartians. Even if you
# do not specify the routefilter option, it is a good idea to specify
# logmartians because your distribution may have enabled route filtering
# without you knowing it.
#
# Only those interfaces with the logmartians option will have their
# setting changed; the value assigned to the setting will be the value
# specified (if any) or 1 if no value is given.
#
# To find out if route filtering is set on a given interface, check the
# contents of /proc/sys/net/ipv4/conf/interface/rp_filter - a non-zero
# value indicates that route filtering is enabled.
#
# Example:
#
# teastep@lists:~$ cat /proc/sys/net/ipv4/conf/eth0/rp_filter
# 1
# teastep@lists:~$
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# This option may also be enabled globally in the shorewall.conf(5)
# file.
#
# maclist
#
# Connection requests from this interface are compared against the
# contents of shorewall-maclist(5). If this option is specified, the
# interface must be an Ethernet NIC and must be up before Shorewall is
# started.
#
# mss=number
#
# Added in Shorewall 4.0.3. Causes forwarded TCP SYN packets entering or
# leaving on this interface to have their MSS field set to the specified
# number.
#
# nets=(net[,...])
#
# Limit the zone named in the ZONE column to only the listed networks.
# The parentheses may be omitted if only a single net is given (e.g.,
# nets=192.168.1.0/24). Limited broadcast to the zone is supported.
# Beginning with Shorewall 4.4.1, multicast traffic to the zone is also
# supported.
#
# nets=dynamic
#
# Defines the zone as dynamic. Requires ipset match support in your
# iptables and kernel. See http://www.shorewall.net/Dynamic.html for
# further information.
#
# nodbl
#
# Added in Shorewall 5.0.8. When specified, dynamic blacklisting is
# disabled on the interface. Beginning with Shorewall 5.0.10, nodbl is
# equivalent to dbl=none.
#
# nosmurfs
#
# IPv4 only. Filter packets for smurfs (packets with a broadcast address
# as the source).
#
# Smurfs will be optionally logged based on the setting of
# SMURF_LOG_LEVEL in shorewall.conf(5). After logging, the packets are
# dropped.
#
# optional
#
# When optional is specified for an interface, Shorewall will be silent
# when:
#
# ☆ a /proc/sys/net/ipv[46]/conf/ entry for the interface cannot be
# modified (including for proxy ARP or proxy NDP).
#
# ☆ The first address of the interface cannot be obtained.
#
# May not be specified with required.
#
# physical=name
#
# Added in Shorewall 4.4.4. When specified, the interface or port name in
# the INTERFACE column is a logical name that refers to the name given in
# this option. It is useful when you want to specify the same wildcard
# port name on two or more bridges. See http://www.shorewall.net/
# bridge-Shorewall-perl.html#Multiple.
#
# If the interface name is a wildcard name (ends with '+'), then the
# physical name must also end in '+'. The physical name may end in '+'
# (or be exactly '+') when the interface name is not a wildcard name.
#
# If physical is not specified, then it's value defaults to the interface
# name.
#
# proxyarp[={0|1}]
#
# IPv4 only. Sets /proc/sys/net/ipv4/conf/interface/proxy_arp. Do NOT use
# this option if you are employing Proxy ARP through entries in
# shorewall-proxyarp(5). This option is intended solely for use with
# Proxy ARP sub-networking as described at: http://tldp.org/HOWTO/
# Proxy-ARP-Subnet/index.html.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# Only those interfaces with the proxyarp option will have their setting
# changed; the value assigned to the setting will be the value specified
# (if any) or 1 if no value is given.
#
# proxyndp[={0|1}]
#
# IPv6 only. Sets /proc/sys/net/ipv6/conf/interface/proxy_ndp.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# Only those interfaces with the proxyndp option will have their setting
# changed; the value assigned to the setting will be the value specified
# (if any) or 1 if no value is given.
#
# required
#
# Added in Shorewall 4.4.10. If this option is set, the firewall will
# fail to start if the interface is not usable. May not be specified
# together with optional.
#
# routeback[={0|1}]
#
# If specified, indicates that Shorewall should include rules that allow
# traffic arriving on this interface to be routed back out that same
# interface. This option is also required when you have used a wildcard
# in the INTERFACE column if you want to allow traffic between the
# interfaces that match the wildcard.
#
# Beginning with Shorewall 4.4.20, if you specify this option, then you
# should also specify either sfilter (see below) or routefilter on all
# interfaces (see below).
#
# Beginning with Shorewall 4.5.18, you may specify this option to
# explicitly reset (e.g., routeback=0). This can be used to override
# Shorewall's default setting for bridge devices which is routeback=1.
#
# routefilter[={0|1|2}]
#
# IPv4 only. Turn on kernel route filtering for this interface
# (anti-spoofing measure).
#
# Only those interfaces with the routefilter option will have their
# setting changes; the value assigned to the setting will be the value
# specified (if any) or 1 if no value is given.
#
# The value 2 is only available with Shorewall 4.4.5.1 and later when the
# kernel version is 2.6.31 or later. It specifies a loose form of reverse
# path filtering.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# This option can also be enabled globally via the ROUTE_FILTER option in
# the shorewall.conf(5) file.
#
# Important
#
# If ROUTE_FILTER=Yes in shorewall.conf(5), or if your distribution sets
# net.ipv4.conf.all.rp_filter=1 in /etc/sysctl.conf, then setting
# routefilter=0 in an interface entry will not disable route filtering on
# that interface! The effective setting for an interface is the maximum
# of the contents of /proc/sys/net/ipv4/conf/all/rp_filter and the
# routefilter setting specified in this file (/proc/sys/net/ipv4/conf/
# interface/rp_filter).
#
# Note
#
# There are certain cases where routefilter cannot be used on an
# interface:
#
# ☆ If USE_DEFAULT_RT=Yes in shorewall.conf(5) and the interface is
# listed in shorewall-providers(5).
#
# ☆ If there is an entry for the interface in shorewall-providers(5)
# that doesn't specify the balance option.
#
# ☆ If IPSEC is used to allow a road-warrior to have a local address,
# then any interface through which the road-warrior might connect
# cannot specify routefilter.
#
# Beginning with Shorewall 5.1.1, when routefilter is set to a non-zero
# value, the logmartians option is also implicitly set. If you actually
# want route filtering without logging, then you must also specify
# logmartians=0 after routefilter.
#
# rpfilter
#
# Added in Shorewall 4.5.7. This is an anti-spoofing measure that
# requires the 'RPFilter Match' capability in your iptables and kernel.
# It provides a more efficient alternative to the sfilter option below.
# It performs a function similar to routefilter (see above) but works
# with Multi-ISP configurations that do not use balanced routes.
#
# sfilter=(net[,...])
#
# Added in Shorewall 4.4.20. This option provides an anti-spoofing
# alternative to routefilter on interfaces where that option cannot be
# used, but where the routeback option is required (on a bridge, for
# example). On these interfaces, sfilter should list those local networks
# that are connected to the firewall through other interfaces.
#
# sourceroute[={0|1}]
#
# If this option is not specified for an interface, then source-routed
# packets will not be accepted from that interface unless it has been
# explicitly enabled via sysconf. Only set this option to 1 (enable
# source routing) if you know what you are doing. This might represent a
# security risk and is usually unneeded.
#
# Only those interfaces with the sourceroute option will have their
# setting changed; the value assigned to the setting will be the value
# specified (if any) or 1 if no value is given.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# tcpflags[={0|1}]
#
# Packets arriving on this interface are checked for certain illegal
# combinations of TCP flags. Packets found to have such a combination of
# flags are handled according to the setting of TCP_FLAGS_DISPOSITION
# after having been logged according to the setting of
# TCP_FLAGS_LOG_LEVEL.
#
# Beginning with Shorewall 4.6.0, tcpflags=1 is the default. To disable
# this option, specify tcpflags=0.
#
# unmanaged
#
# Added in Shorewall 4.5.18. Causes all traffic between the firewall and
# hosts on the interface to be accepted. When this option is given:
#
# ☆ The ZONE column must contain '-'.
#
# ☆ Only the following other options are allowed with unmanaged:
#
# arp_filter
# arp_ignore
# ignore
# routefilter
# optional
# physical
# routefilter
# proxyarp
# proxyudp
# sourceroute
#
# upnp
#
# Incoming requests from this interface may be remapped via UPNP (upnpd).
# See http://www.shorewall.net/UPnP.html. Supported in IPv4 and in IPv6
# in Shorewall 5.1.4 and later.
#
# upnpclient
#
# This option is intended for laptop users who always run Shorewall on
# their system yet need to run UPnP-enabled client apps such as
# Transmission (BitTorrent client). The option causes Shorewall to detect
# the default gateway through the interface and to accept UDP packets
# from that gateway. Note that, like all aspects of UPnP, this is a
# security hole so use this option at your own risk. Supported in IPv4
# and in IPv6 in Shorewall 5.1.4 and later.
#
# wait=seconds
#
# Added in Shorewall 4.4.10. Causes the generated script to wait up to
# seconds seconds for the interface to become usable before applying the
# required or optional options.
#
# Example
#
# IPv4 Example 1:
#
# Suppose you have eth0 connected to a DSL modem and eth1 connected to your
# local network and that your local subnet is 192.168.1.0/24. The interface
# gets its IP address via DHCP from subnet 206.191.149.192/27. You have a DMZ
# with subnet 192.168.2.0/24 using eth2. Your iptables and/or kernel do not
# support "Address Type Match" and you prefer to specify broadcast addresses
# explicitly rather than having Shorewall detect them.
#
# Your entries for this setup would look like:
#
# ?FORMAT 1
# #ZONE INTERFACE BROADCAST OPTIONS
# net eth0 206.191.149.223 dhcp
# loc eth1 192.168.1.255
# dmz eth2 192.168.2.255
#
# Example 2:
#
# The same configuration without specifying broadcast addresses is:
#
# ?FORMAT 2
# #ZONE INTERFACE OPTIONS
# net eth0 dhcp
# loc eth1
# dmz eth2
#
# Example 3:
#
# You have a simple dial-in system with no Ethernet connections.
#
# ?FORMAT 2
# #ZONE INTERFACE OPTIONS
# net ppp0 -
#
# Example 4 (Shorewall 4.4.9 and later):
#
# You have a bridge with no IP address and you want to allow traffic through
# the bridge.
#
# ?FORMAT 2
# #ZONE INTERFACE OPTIONS
# - br0 bridge
#
###############################################################################
?FORMAT 2
###############################################################################
#ZONE INTERFACE OPTIONS
net NET_IF tcpflags,physical=eth0
shorewall6-5.2.3.4/Samples6/one-interface/policy.annotated 0000664 0000000 0000000 00000025623 13531077656 022105 0 ustar root root #
# Shorewall6 version 5 - Sample Policy File for one-interface configuration.
# Copyright (C) 2006-2015 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#-----------------------------------------------------------------------------
# For information about entries in this file, type "man shorewall6-policy"
#
##############################################################################
#
# This file defines the high-level policy for connections between zones defined
# in shorewall-zones(5).
#
# Important
#
# The order of entries in this file is important
#
# This file determines what to do with a new connection request if we don't get a
# match from the shorewall-blrules(5) or shorewall-rules(5) files. For each
# source/destination pair, the file is processed in order until a match is found
# ("all" will match any source or destination).
#
# Important
#
# Intra-zone policies are pre-defined
#
# For $FW and for all of the zones defined in shorewall-zones(5), the POLICY for
# connections from the zone to itself is ACCEPT (with no logging or TCP
# connection rate limiting) but may be overridden by an entry in this file. The
# overriding entry must be explicit (specifying the zone name in both SOURCE and
# DEST) or it must use "all+" (Shorewall 4.5.17 or later).
#
# Similarly, if you have IMPLICIT_CONTINUE=Yes in shorewall.conf(5), then the
# implicit policy to/from any sub-zone is CONTINUE. These implicit CONTINUE
# policies may also be overridden by an explicit entry in this file.
#
# The columns in the file are as follows (where the column name is followed by a
# different name in parentheses, the different name is used in the alternate
# specification syntax).
#
# SOURCE - zone[,...[+]]|$FW|all[+][!ezone[,...]]
#
# Source zone. Must be the name of a zone defined in shorewall-zones(5), $FW,
# "all" or "all+".
#
# Support for all+ was added in Shorewall 4.5.17. all does not override the
# implicit intra-zone ACCEPT policy while all+ does.
#
# Beginning with Shorewall 5.0.12, multiple zones may be listed separated by
# commas. As above, if '+' is specified after two or more zone names, then
# the policy overrides the implicit intra-zone ACCEPT policy if the same zone
# appears in both the SOURCE and DEST columns.
#
# Beginning with Shorewall 5.2.3, a comma-separated list of excluded zones
# preceded by "!" may follow all or all+.
#
# DEST - zone[,...[+]]|$FW|all[+][!ezone[,...]]
#
# Destination zone. Must be the name of a zone defined in shorewall-zones(5),
# $FW, "all" or "all+". If the DEST is a bport zone, then the SOURCE must be
# "all", "all+", another bport zone associated with the same bridge, or it
# must be an ipv4 zone that is associated with only the same bridge.
#
# Support for "all+" was added in Shorewall 4.5.17. "all" does not override
# the implicit intra-zone ACCEPT policy while "all+" does.
#
# Beginning with Shorewall 5.0.12, multiple zones may be listed separated by
# commas. As above, if '+' is specified after two or more zone names, then
# the policy overrides the implicit intra-zone ACCEPT policy if the same zone
# appears in both the SOURCE and DEST columns.
#
# Beginning with Shorewall 5.2.3, a comma-separated list of excluded zones
# preceded by "!" may follow all or all+.
#
# POLICY - {ACCEPT|DROP|REJECT|BLACKLIST|CONTINUE|QUEUE|NFQUEUE[(queuenumber1[:
# queuenumber2])]|NONE}[:{[+]policy-action[:level][,...]|None}]
#
# Policy if no match from the rules file is found.
#
# If the policy is neither CONTINUE nor NONE then the policy may be followed
# by ":" and one of the following:
#
# a. The word "None" or "none". This causes any default action defined in
# shorewall.conf(5) to be omitted for this policy.
#
# b. The name of an action with optional parameters enclosed in parentheses.
# The action will be invoked before the policy is enforced.
#
# Actions can have parameters specified.
#
# Beginning with Shorewall 4.5.10, the action name can be followed optionally
# by a colon and a log level. The level will be applied to each rule in the
# action or body that does not already have a log level.
#
# Beginning with Shorewall 5.1.2, multiple action[:level] specification may
# be listeded, separated by commas. The actions are invoked in the order
# listed. Also beginning with Shorewall 5.1.2, the policy-action list can be
# prefixed with a plus sign ("+") indicating that the listed actions are in
# addition to those listed in the related _DEFAULT setting in shorewall.conf
# (5).
#
# Possible policies are:
#
# ACCEPT
#
# Accept the connection.
#
# DROP
#
# Ignore the connection request.
#
# REJECT
#
# For TCP, send RST. For all other, send an "unreachable" ICMP.
#
# BLACKLIST
#
# Added in Shorewall 5.1.1 and requires that the DYNAMIC_BLACKLIST
# setting in shorewall.conf(5) specifies ipset-based dynamic
# blacklisting. The SOURCE IP address is added to the blacklist ipset and
# the connection request is ignored.
#
# QUEUE
#
# Queue the request for a user-space application such as Snort-inline.
#
# NFQUEUE
#
# Queue the request for a user-space application using the
# nfnetlink_queue mechanism. If a queuenumber1 is not given, queue zero
# (0) is assumed. Beginning with Shorewall 4.6.10, a second queue number
# (queuenumber2) may be given. This specifies a range of queues to use.
# Packets are then balanced across the given queues. This is useful for
# multicore systems: start multiple instances of the userspace program on
# queues x, x+1, .. x+n and use "x:x+n". Packets belonging to the same
# connection are put into the same nfqueue.
#
# CONTINUE
#
# Pass the connection request past any other rules that it might also
# match (where the source or destination zone in those rules is a
# superset of the SOURCE or DEST in this policy). See shorewall-nesting
# (5) for additional information.
#
# NONE
#
# Assume that there will never be any packets from this SOURCE to this
# DEST. Shorewall will not create any infrastructure to handle such
# packets and you may not have any rules with this SOURCE and DEST in the
# /etc/shorewall/rules file. If such a packet is received, the result is
# undefined. NONE may not be used if the SOURCE or DEST columns contain
# the firewall zone ($FW) or "all".
#
# LOGLEVEL (loglevel) - [log-level|ULOG|NFLOG]
#
# Optional - if supplied, each connection handled under the default POLICY is
# logged at that level. If not supplied, no log message is generated. See
# syslog.conf(5) for a description of log levels.
#
# You may also specify ULOG or NFLOG (must be in upper case). This will log
# to the ULOG or NFLOG target and will send to a separate log through use of
# ulogd (http://www.netfilter.org/projects/ulogd/index.html).
#
# For a description of logging, see shorewall-logging(5).
#
# If you don't want to log but need to specify the following column, place
# "-" here.
#
# RATE (rate) - [-|limit]
#
# where limit is one of:
#
# [-|[{s|d}[/vlsm]:[[name][(ht-buckets,ht-max)]:]]]rate/{sec|min|hour|day}[:
# burst]
# [name1:]rate1/{sec|min|hour|day}[:burst1],[name2:]rate2/{sec|min|hour|day}
# [:burst2]
#
# If passed, specifies the maximum TCP connection rate and the size of an
# acceptable burst. If not specified, TCP connections are not limited. If the
# burst parameter is omitted, a value of 5 is assumed.
#
# When s: or d: is specified, the rate applies per source IP address or per
# destination IP address respectively. The name may be chosen by the user and
# specifies a hash table to be used to count matching connections. If not
# give, the name shorewall is assumed. Where more than one POLICY or rule
# specifies the same name, the connections counts for the policies are
# aggregated and the individual rates apply to the aggregated count.
# Beginning with Shorewall 5.2.1, the s or d may be followed by a slash ("/")
# and an integer vlsm. When a vlsm is specified, all source or destination
# addresses encountered will be grouped according to the given prefix length
# and the so-created subnet will be subject to the rate limit.
#
# Beginning with Shorewall 4.6.5, two limits may be specified, separated by a
# comma. In this case, the first limit (name1, rate1, burst1) specifies the
# per-source IP limit and the second limit specifies the per-destination IP
# limit.
#
# Example: client:10/sec:20,:60/sec:100
#
# Beginning with Shorewall 5.2.1, the table name, if any, may be followed by
# two integers separated by commas and enclosed in parentheses. The first
# integer (ht-buckets) specifies the number of buckets in the generated hash
# table. The second integer (ht-max) specifies the maximum number of entries
# in the hash table.
#
# Example: s:client(1024,65536):10/sec
#
# CONNLIMIT - limit[:mask]
#
# May be used to limit the number of simultaneous connections from each
# individual host to limit connections. While the limit is only checked on
# connections to which this policy could apply, the number of current
# connections is calculated over all current connections from the SOURCE
# host. By default, the limit is applied to each host individually but can be
# made to apply to networks of hosts by specifying a mask. The mask specifies
# the width of a VLSM mask to be applied to the source address; the number of
# current connections is then taken over all hosts in the subnet
# source-address/mask.
#
# Example
#
# a. All connections from the local network to the internet are allowed
#
# b. All connections from the internet are ignored but logged at syslog level
# KERNEL.INFO.
#
# c. All other connection requests are rejected and logged at level KERNEL.INFO.
#
# #SOURCE DEST POLICY LOG BURST:LIMIT
# # LEVEL
# loc net ACCEPT
# net all DROP info
# #
# # THE FOLLOWING POLICY MUST BE LAST
# #
# all all REJECT info
#
##############################################################################
#SOURCE DEST POLICY LOGLEVEL RATE CONNLIMIT
$FW net ACCEPT
net all DROP $LOG_LEVEL
# The FOLLOWING POLICY MUST BE LAST
all all REJECT $LOG_LEVEL
shorewall6-5.2.3.4/Samples6/one-interface/README.txt 0000664 0000000 0000000 00000002153 13531060406 020357 0 ustar root root For instructions on using this sample configuration, please see
http://www.shorewall.net/standalone.htm
Shorewall Samples
Copyright (C) 2006-2015 by the following authors:
Thomas M. Eastep
Paul D. Gear
Cristian Rodriguez
Francesca Smith
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
02110-1301 USA
Sample files are licensed under the LGPL, please see the LICENSE file or
http://www.gnu.org/licenses/lgpl.html for more details.
shorewall6-5.2.3.4/Samples6/one-interface/rules.annotated 0000664 0000000 0000000 00000164153 13531077656 021742 0 ustar root root #
# Shorewall6 version 5 - Sample Rules File for one-interface configuration.
# Copyright (C) 2006-2015 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------------------------------------
# For information on entries in this file, type "man shorewall6-rules"
######################################################################################################################################################################################################
#
# Entries in this file govern connection establishment by defining exceptions to
# the policies laid out in shorewall-policy(5). By default, subsequent requests
# and responses are automatically allowed using connection tracking. For any
# particular (source,dest) pair of zones, the rules are evaluated in the order in
# which they appear in this file and the first terminating match is the one that
# determines the disposition of the request. All rules are terminating except LOG
# and COUNT rules.
#
# Warning
#
# If you masquerade or use SNAT from a local system to the internet, you cannot
# use an ACCEPT rule to allow traffic from the internet to that system. You must
# use a DNAT rule instead.
#
# The rules file is divided into sections. Each section is introduced by a
# "Section Header" which is a line beginning with ?SECTION and followed by the
# section name.
#
# Sections are as follows and must appear in the order listed:
#
# ALL
#
# This section was added in Shorewall 4.4.23. Rules in this section are
# applied, regardless of the connection tracking state of the packet and are
# applied before rules in the other sections.
#
# ESTABLISHED
#
# Packets in the ESTABLISHED state are processed by rules in this section.
#
# The only ACTIONs allowed in this section are ACCEPT, DROP, REJECT, LOG,
# NFLOG, NFQUEUE and QUEUE
#
# There is an implicit ACCEPT rule inserted at the end of this section.
#
# RELATED
#
# Packets in the RELATED state are processed by rules in this section.
#
# The only ACTIONs allowed in this section are ACCEPT, DROP, REJECT, LOG,
# NFLOG, NFQUEUE and QUEUE
#
# There is an implicit rule added at the end of this section that invokes the
# RELATED_DISPOSITION (shorewall.conf(5)).
#
# INVALID
#
# Added in Shorewall 4.5.13. Packets in the INVALID state are processed by
# rules in this section.
#
# The only Actions allowed in this section are ACCEPT, DROP, REJECT, LOG,
# NFLOG, NFQUEUE and QUEUE.
#
# There is an implicit rule added at the end of this section that invokes the
# INVALID_DISPOSITION (shorewall.conf(5)).
#
# UNTRACKED
#
# Added in Shorewall 4.5.13. Packets in the UNTRACKED state are processed by
# rules in this section.
#
# The only Actions allowed in this section are ACCEPT, DROP, REJECT, LOG,
# NFLOG, NFQUEUE and QUEUE.
#
# There is an implicit rule added at the end of this section that invokes the
# UNTRACKED_DISPOSITION (shorewall.conf(5)).
#
# NEW
#
# Packets in the NEW state are processed by rules in this section. If the
# INVALID and/or UNTRACKED sections are empty or not included, then the
# packets in the corresponding state(s) are also processed in this section.
#
# Note
#
# If you are not familiar with Netfilter to the point where you are comfortable
# with the differences between the various connection tracking states, then it is
# suggested that you place all of your rules in the NEW section (That's after the
# line that reads ?SECTION NEW').
#
# Warning
#
# If you specify FASTACCEPT=Yes in shorewall.conf(5) then the ALL, ESTABLISHED
# and RELATED sections must be empty.
#
# An exception is made if you are running Shorewall 4.4.27 or later and you have
# specified a non-default value for RELATED_DISPOSITION or RELATED_LOG_LEVEL. In
# that case, you may have rules in the RELATED section of this file.
#
# You may omit any section that you don't need. If no Section Headers appear in
# the file then all rules are assumed to be in the NEW section.
#
# When defining rules that rewrite the destination IP address and/or port number
# (namely DNAT and REDIRECT rules), it is important to keep straight which
# columns in the file specify the packet before rewriting and which specify how
# the packet will look after rewriting.
#
# • The DEST column specifies the final destination for the packet after
# rewriting and can include the final IP address and/or port number.
#
# • The remaining columns specify characteristics of the packet before
# rewriting. In particular, the ORIGDEST column gives the original
# destination IP address of the packet and the DPORT column give the original
# destination port(s).
#
# The columns in the file are as follows (where the column name is followed by a
# different name in parentheses, the different name is used in the alternate
# specification syntax).
#
# ACTION - target[:{log-level|none}[!][:tag]]
#
# Specifies the action to be taken if the connection request matches the
# rule. target must be one of the following.
#
# ACCEPT
#
# Allow the connection request.
#
# ACCEPT+
#
# like ACCEPT but also excludes the connection from any subsequent
# matching DNAT[-] or REDIRECT[-] rules. Use with IPv6 requires Shorewall
# 4.5.14 or later.
#
# ACCEPT!
#
# like ACCEPT but exempts the rule from being suppressed by OPTIMIZE=1 in
# shorewall.conf(5).
#
# action
#
# The name of an action declared in shorewall-actions(5) or in /usr/share
# /shorewall[6]/actions.std.
#
# ADD(ipset:flags[:timeout])
#
# Added in Shorewall 4.4.12. Causes addresses and/or port numbers to be
# added to the named ipset. The flags specify the address or tuple to be
# added to the set and must match the type of ipset involved. For
# example, for an iphash ipset, either the SOURCE or DESTINATION address
# can be added using flags src or dst respectively (see the -A command in
# ipset (8)).
#
# Beginning with Shorewall 5.0.3, an optional timeout can be specified.
# This is the number of seconds that the new entry in the ipset is to
# remain valid and overrides any timeout specified when the ipset was
# created.
#
# ADD is non-terminating. Even if a packet matches the rule, it is passed
# on to the next rule.
#
# AUDIT[(accept|drop|reject)]
#
# Added in Shorewall 4.5.10. Audits the packet with the specified type;
# if the type is omitted, then drop is assumed. Require AUDIT_TARGET
# support in the kernel and iptables.
#
# A_ACCEPT, A_ACCEPT+ and A_ACCEPT!
#
# Added in Shorewall 4.4.20. Audited versions of ACCEPT, ACCEPT+ and
# ACCEPT! respectively. Require AUDIT_TARGET support in the kernel and
# iptables. A_ACCEPT+ with IPv6 requires Shorewall 4.5.14 or later.
#
# A_DROP and A_DROP!
#
# Added in Shorewall 4.4.20. Audited versions of DROP and DROP!
# respectively. Require AUDIT_TARGET support in the kernel and iptables.
#
# A_REJECT AND A_REJECT!
#
# Added in Shorewall 4.4.20. Audited versions of REJECT and REJECT!
# respectively. Require AUDIT_TARGET support in the kernel and iptables.
#
# ?COMMENT
#
# the rest of the line will be attached as a comment to the Netfilter
# rule(s) generated by the following entries. The comment will appear
# delimited by "/* ... */" in the output of "shorewall show ". To
# stop the comment from being attached to further rules, simply include ?
# COMMENT on a line by itself.
#
# CONMARK({mark})
#
# Added in Shorewall 5.0.7, CONNMARK is identical to MARK with the
# exception that the mark is assigned to connection to which the packet
# belongs is marked rather than to the packet itself.
#
# CONTINUE
#
# For experts only.
#
# Do not process any of the following rules for this (source
# zone,destination zone). If the source and/or destination IP address
# falls into a zone defined later in shorewall-zones(5) or in a parent
# zone of the source or destination zones, then this connection request
# will be passed to the rules defined for that (those) zone(s). See
# shorewall-nesting(5) for additional information.
#
# CONTINUE!
#
# like CONTINUE but exempts the rule from being suppressed by OPTIMIZE=1
# in shorewall.conf(5).
#
# COUNT
#
# Simply increment the rule's packet and byte count and pass the packet
# to the next rule.
#
# DEL(ipset:flags)
#
# Added in Shorewall 4.4.12. Causes an entry to be deleted from the named
# ipset. The flags specify the address or tuple to be deleted from the
# set and must match the type of ipset involved. For example, for an
# iphash ipset, either the SOURCE or DESTINATION address can be deleted
# using flags src or dst respectively (see the -D command in ipset (8)).
#
# DEL is non-terminating. Even if a packet matches the rule, it is passed
# on to the next rule.
#
# DNAT
#
# Forward the request to another system (and optionally another port).
# Use with IPv6 requires Shorewall 4.5.14 or later.
#
# DNAT-
#
# Advanced users only.
#
# Like DNAT but only generates the DNAT iptables rule and not the
# companion ACCEPT rule. Use with IPv6 requires Shorewall 4.5.14 or
# later.
#
# DROP
#
# Ignore the request.
#
# DROP!
#
# like DROP but exempts the rule from being suppressed by OPTIMIZE=1 in
# shorewall.conf(5).
#
# HELPER
#
# Added in Shorewall 4.5.7. This action requires that the HELPER column
# contains the name of the Netfilter helper to be associated with
# connections matching this connection. May only be specified in the NEW
# section and is useful for being able to specify a helper when the
# applicable policy is ACCEPT. No destination zone should be specified in
# HELPER rules.
#
# INLINE[(action)]
#
# Added in Shorewall 4.5.16. This action allows you to construct most of
# the rule yourself using iptables syntax. The part that you specify must
# follow two semicolons (';;') and is completely free-form. If the target
# of the rule (the part following 'j') is something that Shorewall
# supports in the ACTION column, then you may enclose it in parentheses
# (e.g., INLINE(ACCEPT)). Otherwise, you can include it after the
# semicolon(s). In this case, you must declare the target as a builtin
# action in shorewall-actions(5).
#
# Some considerations when using INLINE:
#
# ☆ The p, s, d, i, o, policy, and state match (state or conntrack
# --ctstate) matches will always appear in the front of the rule in
# that order.
#
# ☆ When multiple matches are specified, the compiler will keep them in
# the order in which they appear (excluding the above listed ones),
# but they will not necessarily be at the end of the generated rule.
# For example, if addresses are specified in the SOURCE and/or DEST
# columns, their generated matches will appear after those specified
# using ';;' or ';'.
#
# IPTABLES({iptables-target [option ...])
#
# IPv4 only. This action allows you to specify an iptables target with
# options (e.g., 'IPTABLES(MARK --set-xmark 0x01/0xff)'. If the
# iptables-target is not one recognized by Shorewall, the following error
# message will be issued:
#
# ERROR: Unknown target (iptables-target)
#
# This error message may be eliminated by adding the iptables-target as a
# builtin action in shorewall-actions(5).
#
# Important
#
# If you specify REJECT as the iptables-target, the target of the rule
# will be the iptables REJECT target and not Shorewall's builtin 'reject'
# chain which is used when REJECT (see below) is specified as the target
# in the ACTION column.
#
# IP6TABLES({ip6tables-target [option ...])
#
# IPv6 only. This action allows you to specify an ip6tables target with
# options (e.g., 'IPTABLES(MARK --set-xmark 0x01/0xff)'. If the
# ip6tables-target is not one recognized by Shorewall, the following
# error message will be issued:
#
# ERROR: Unknown target (ip6tables-target)
#
# This error message may be eliminated by adding the ip6tables-target as
# a builtin action in shorewall-actions(5).
#
# Important
#
# If you specify REJECT as the ip6tables-target, the target of the rule
# will be the i6ptables REJECT target and not Shorewall's builtin
# 'reject' chain which is used when REJECT (see below) is specified as
# the target in the ACTION column.
#
# LOG:level
#
# Simply log the packet and continue with the next rule.
#
# macro[(macrotarget)]
#
# The name of a macro defined in a file named macro.macro. If the macro
# accepts an action parameter (Look at the macro source to see if it has
# PARAM in the TARGET column) then the macro name is followed by the
# parenthesized macrotarget (ACCEPT, DROP, REJECT, ...) to be substituted
# for the parameter.
#
# Example: FTP(ACCEPT).
#
# The older syntax where the macro name and the target are separated by a
# slash (e.g. FTP/ACCEPT) is still allowed but is deprecated.
#
# MARK({mark})
#
# where mark is a packet mark value.
#
# Added in Shorewall 5.0.7, MARK requires "Mark in filter table" support
# in your kernel and iptables.
#
# Normally will set the mark value of the current packet. If preceded by
# a vertical bar ("|"), the mark value will be logically ORed with the
# current mark value to produce a new mark value. If preceded by an
# ampersand ("&"), will be logically ANDed with the current mark value to
# produce a new mark value.
#
# Both "|" and "&" require Extended MARK Target support in your kernel
# and iptables.
#
# The mark value may be optionally followed by "/" and a mask value (used
# to determine those bits of the connection mark to actually be set).
# When a mask is specified, the result of logically ANDing the mark value
# with the mask must be the same as the mark value.
#
# NFLOG[(nflog-parameters)]
#
# Added in Shorewall 4.5.9.3. Queues matching packets to a back end
# logging daemon via a netlink socket then continues to the next rule.
# See http://www.shorewall.net/shorewall_logging.html.
#
# The nflog-parameters are a comma-separated list of up to 3 numbers:
#
# ☆ The first number specifies the netlink group (0-65535). If omitted
# (e.g., NFLOG(,0,10)) then a value of 0 is assumed.
#
# ☆ The second number specifies the maximum number of bytes to copy. If
# omitted, 0 (no limit) is assumed.
#
# ☆ The third number specifies the number of log messages that should
# be buffered in the kernel before they are sent to user space. The
# default is 1.
#
# NFLOG is similar to LOG:NFLOG[(nflog-parameters)], except that the log
# level is not changed when this ACTION is used in an action or macro
# body and the invocation of that action or macro specifies a log level.
#
# NFQUEUE[([queuenumber1[:queuenumber2[c]][,bypass]]|bypass)]
#
# Queues the packet to a user-space application using the nfnetlink_queue
# mechanism. If a queuenumber1 is not specified, queue zero (0) is
# assumed. Beginning with Shorewall 4.6.10, the keyword bypass can be
# given. By default, if no userspace program is listening on an NFQUEUE,
# then all packets that are to be queued are dropped. When this option is
# used, the NFQUEUE rule behaves like ACCEPT instead. Also beginning in
# Shorewall 4.6.10, a second queue number (queuenumber2) may be
# specified. This specifies a range of queues to use. Packets are then
# balanced across the given queues. This is useful for multicore systems:
# start multiple instances of the userspace program on queues x, x+1, ..
# x+n and use "x:x+n". Packets belonging to the same connection are put
# into the same nfqueue.
#
# Beginning with Shorewall 5.1.0, queuenumber2 may be followed by the
# letter 'c' to indicate that the CPU ID will be used as an index to map
# packets to the queues. The idea is that you can improve performance if
# there's a queue per CPU. Requires the NFQUEUE CPU Fanout capability in
# your kernel and iptables.
#
# NFQUEUE![([queuenumber1[:queuenumber2[c]][,bypass]]|bypass)]
#
# like NFQUEUE but exempts the rule from being suppressed by OPTIMIZE=1
# in shorewall.conf(5).
#
# NONAT
#
# Excludes the connection from any subsequent DNAT[-] or REDIRECT[-]
# rules but doesn't generate a rule to accept the traffic. Use with IPv6
# requires Shorewall 4.5.14 or later.
#
# QUEUE
#
# Queue the packet to a user-space application such as ftwall (http://
# p2pwall.sf.net). The application may reinsert the packet for further
# processing.
#
# QUEUE!
#
# like QUEUE but exempts the rule from being suppressed by OPTIMIZE=1 in
# shorewall.conf(5).
#
# REJECT[(option)]
#
# disallow the request and return an icmp-unreachable or an RST packet.
# If no option is passed, Shorewall selects the appropriate option based
# on the protocol of the packet.
#
# Beginning with Shorewall 5.0.8, the type of reject may be specified in
# the option paramater. Valid IPv4 option values are:
#
# icmp-net-unreachable
# icmp-host-unreachable
# icmp-port-unreachable
# icmp-proto-unreachable
# icmp-net-prohibited
# icmp-host-prohibited
# icmp-admin-prohibited
# icmp-tcp-reset (the PROTO column must specify TCP). Beginning with
# Shorewall 5.1.3, this option may also be specified as tcp-reset.
#
# Valid IPv6 option values are:
#
# icmp6-no-route
# no-route
# icmp6-adm-prohibited
# adm-prohibited
# icmp6-addr-unreachable
# addr-unreach
# icmp6-port-unreachable
# tcp-reset (the PROTO column must specify TCP)
#
# REJECT!
#
# like REJECT but exempts the rule from being suppressed by OPTIMIZE=1 in
# shorewall.conf(5).
#
# REDIRECT
#
# Redirect the request to a server running on the firewall. Use with IPv6
# requires Shorewall 4.5.14 or later.
#
# REDIRECT-
#
# Advanced users only.
#
# Like REDIRECT but only generates the REDIRECT iptables rule and not the
# companion ACCEPT rule. Use with IPv6 requires Shorewall 4.5.14 or
# later.
#
# TARPIT [(tarpit | honeypot | reset)]
#
# Added in Shorewall 4.6.6.
#
# TARPIT captures and holds incoming TCP connections using no local
# per-connection resources.
#
# TARPIT only works with the PROTO column set to tcp (6), and is totally
# application agnostic. This module will answer a TCP request and play
# along like a listening server, but aside from sending an ACK or RST, no
# data is sent. Incoming packets are ignored and dropped. The attacker
# will terminate the session eventually. This module allows the initial
# packets of an attack to be captured by other software for inspection.
# In most cases this is sufficient to determine the nature of the attack.
#
# This offers similar functionality to LaBrea " was specified
# in the command (e.g., shorewall [-6] check ./gateway) then the
# directory given in the command is searched first.
#
# □ Next, each directory in the CONFIG_PATH setting is searched in
# sequence.
#
# If CONFIG_PATH is not given or if it is set to the empty value then the
# contents of /usr/share/shorewall/configpath are used. As released from
# shorewall.net, that file sets the CONFIG_PATH to /etc/shorewall:/usr/share/
# shorewall but your particular distribution may set it differently. See the
# output of shorewall show config for the default on your system.
#
# Beginning with Shorewall 5.1.10, the CONFIG_PATH setting may begin with a
# colon (":"), to signal that the first directory listed will be skipped if
# the user performing a compilation is not root or if the configuration is
# being compiled for export (-e option specified or if running one of the
# remote-* commands) . This prevents the compiler from looking in /etc/
# shorewall[6]/ when compilation is being done by a non-root user or if the
# generated script is to be sent to a remote firewall system.
#
GEOIPDIR=/usr/share/xt_geoip/LE
#
# GEOIPDIR=[pathname]
#
# Added in Shorewall 4.5.4. Specifies the pathname of the directory
# containing the GeoIP Match database. See http://www.shorewall.net/
# ISO-3661.html. If not specified, the default value is /usr/share/xt_geoip/
# LE which is the default location of the little-endian database.
#
IP6TABLES=
#
# IP6TABLES=[pathname]
#
# IPv6 only.
#
# This parameter names the ip6tables executable to be used by Shorewall6. If
# not specified or if specified as a null value, then the ip6tables
# executable located using the PATH option is used.
#
# Regardless of how the ip6tables utility is located (specified via IP6TABLES
# = or located via PATH), Shorewall6 uses the ip6tables-restore and
# ip6tables-save utilities from that same directory.
#
IP=
#
# IP=[pathname]
#
# If specified, gives the pathname of the 'ip' executable. If not specified,
# 'ip' is assumed and the utility will be located using the current PATH
# setting.
#
IPSET=
#
# IPSET=[pathname]
#
# If specified, gives the pathname of the 'ipset' executable. If not
# specified, 'ipset' is assumed and the utility will be located using the
# current PATH setting.
#
LOCKFILE=
#
# LOCKFILE=[pathname]
#
# Specifies the name of the Shorewall[6] lock file, used to prevent
# simultaneous state-changing commands. If not specified, ${VARDIR}/shorewall
# [6]/lock is assumed (${VARDIR} is normally /var/lib but can be changed when
# Shorewall-core is installed -- see the output of shorewall show vardir).
#
MODULESDIR=
#
# MODULESDIR=[[+]pathname[:pathname]...]
#
# This parameter specifies the directory/directories where your kernel
# netfilter modules may be found. If you leave the variable empty, Shorewall
# will supply the value "/lib/modules/$uname/kernel/net/ipv${g_family}/
# netfilter:/lib/modules/$uname/kernel/net/netfilter:/lib/modules/$uname/
# kernel/net/sched:/lib/modules/$uname/extra:/lib/modules/$uname/extra/ipset"
# where uname holds the output of 'uname -r' and g_family holds '4' in IPv4
# configurations and '6' in IPv6 configurations.
#
# The option plus sign ('+') was added in Shorewall 5.0.3 and causes the
# listed pathnames to be appended to the default list above.
#
NFACCT=
#
# NFACCT=[pathname]
#
# Added in Shorewall 4.5.7. Specifies the pathname of the nfacct utility. If
# not specified, Shorewall will use the PATH setting to find the program.
#
PERL=/usr/bin/perl
#
# PERL=pathname
#
# Added in Shorewall 4.4.11 RC1. Specifies the path name of the Perl
# executable. Default is /usr/bin/perl. If the pathname specified by this
# option does not exist or the named file is not executable, then Shorewall
# falls back to /usr/bin/perl
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
#
# PATH=pathname[:pathname]...
#
# Determines the order in which Shorewall searches directories for executable
# files.
#
RESTOREFILE=restore
#
# RESTOREFILE=filename
#
# Specifies the simple name of a file in /var/lib/shorewall to be used as the
# default restore script in the shorewall [-6] save, shorewall [-6] restore,
# shorewall [-6] forget and shorewall [6] -f start commands.
#
SHOREWALL_SHELL=/bin/sh
#
# SHOREWALL_SHELL=[pathname]
#
# This option is used to specify the shell program to be used to interpret
# the compiled script. If not specified or specified as a null value, /bin/sh
# is assumed. Using a light-weight shell such as ash or dash can
# significantly improve performance.
#
SUBSYSLOCK=
#
# SUBSYSLOCK=[pathname]
#
# This parameter should be set to the name of a file that the firewall should
# create if it starts successfully and remove when it stops. Creating and
# removing this file allows Shorewall to work with your distribution's
# initscripts. For OpenSuSE, this should be set to /var/lock/subsys/shorewall
# (var/lock/subsys/shorewall-lite if building for export). For Gentoo, it
# should be set to /run/lock/shorewall (/run/lock/shorewall-lite). For Redhat
# and derivatives as well as Debian and derivatives, the pathname should be
# omitted.
#
# Important
#
# Beginning with Shorewall 5.1.0, this setting is ignored when SERVICEDIR is
# non-empty in ${SHAREDIR}/shorewall/shorewallrc (usually /usr/share/
# shorewall/shorewallrc).
#
TC=
#
# TC=[pathname]
#
# If specified, gives the pathname of the 'tc' executable. If not specified,
# 'tc' is assumed and the utility will be located using the current PATH
# setting.
#
###############################################################################
# D E F A U L T A C T I O N S / M A C R O S
###############################################################################
ACCEPT_DEFAULT="none"
#
# ACCEPT_DEFAULT={action[(parameters)][:level][,...]|none}
#
BLACKLIST_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP),dropNotSyn:$LOG_LEVEL,dropInvalid:$LOG_LEVEL,DropDNSrep:$LOG_LEVEL"
#
# BLACKLIST_DEFAULT={action[(parameters)][:level][,...]|none}
#
DROP_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)"
#
# DROP_DEFAULT={action[(parameters)][:level][,...]|none}
#
NFQUEUE_DEFAULT="none"
#
# NFQUEUE_DEFAULT={action[(parameters)][:level][,...]|none}
#
QUEUE_DEFAULT="none"
#
# QUEUE_DEFAULT={action[(parameters)][:level][,...]|none}
#
REJECT_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)"
#
# REJECT_DEFAULT={action[(parameters)][:level][,...]|none}
#
# In earlier Shorewall versions, a "default action" for DROP and REJECT
# policies was specified in the file /usr/share/shorewall/actions.std.
#
# In Shorewall 4.4.0, the DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT,
# QUEUE_DEFAULT and NFQUEUE_DEFAULT options were added.
#
# 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
# three are similar for ACCEPT, QUEUE and NFQUEUE policies.
#
# The value applied to these may be:
#
# a) The name of an action. The name may optionally be followed by a
# comma-separated list of parameters enclosed in parentheses if the specified
# action accepts parameters (e.g., 'Drop(audit)').
# c) None or none
#
# Prior to Shorewall 5.1.2, the default values are:
#
# DROP_DEFAULT="Drop"
# REJECT_DEFAULT="Reject"
# BLACKLIST_DEFAULT="Drop" (added in Shorewall 5.1.1)
# ACCEPT_DEFAULT="none"
# QUEUE_DEFAULT="none"
# NFQUEUE_DEFAULT="none"
#
# Beginning with Shorewall 5.1.2, the default value is 'none' for all of
# these. Note that the sample configuration files do, however, provide
# settings for DROP_DEFAULT, BLACKLIST_DEFAULT and REJECT_DEFAULT.
#
# 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
# shorewall-policy(5).
#
# You can pass parameters to the specified action (e.g., myaction(audit,DROP)
# ).
#
# Beginning with Shorewall 4.5.10, the action name can be followed optionally
# by a colon and a log level. The level will be applied to each rule in the
# action or body that does not already have a log level.
#
# Beginning with Shorewall 5.1.2, multiple action[(parameters)][:level]
# specifications may be listed, separated by commas.
#
###############################################################################
# R S H / R C P C O M M A N D S
###############################################################################
RCP_COMMAND='scp ${files} ${root}@${system}:${destination}'
#
# RCP_COMMAND="command"
#
RSH_COMMAND='ssh ${root}@${system} ${command}'
#
# RSH_COMMAND="command"
#
# Earlier generations of Shorewall Lite required that remote root login via
# ssh be enabled in order to use the load and reload commands. Beginning with
# release 3.9.5, you may define an alternative means for accessing the remote
# firewall system. In that release, two new options were added to
# shorewall.conf:
#
# RSH_COMMAND
# RCP_COMMAND
#
# The default values for these are as follows:
#
# RSH_COMMAND: ssh ${root}@${system} ${command}
# RCP_COMMAND: scp ${files} ${root}@${system}:${destination}
#
# Shell variables that will be set when the commands are invoked are as
# follows:
#
# root - root user. Normally root but may be overridden using the '-r' option.
# system - The name/IP address of the remote firewall system.
# command - For RSH_COMMAND, the command to be executed on the firewall system.
# files - For RCP_COMMAND, a space-separated list of files to be copied to the remote firewall system.
# destination - The directory on the remote system that the files are to be copied into.
#
###############################################################################
# F I R E W A L L O P T I O N S
###############################################################################
ACCOUNTING=Yes
#
# ACCOUNTING=[Yes|No]
#
# Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting is enabled
# (see shorewall-accounting(5)). If not specified or set to the empty value,
# ACCOUNTING=Yes is assumed.
#
ACCOUNTING_TABLE=filter
#
# ACCOUNTING_TABLE=[filter|mangle]
#
# Added in Shorewall 4.4.20. This setting determines which Netfilter table
# the accounting rules are added in. By default, ACCOUNTING_TABLE=filter is
# assumed. See also shorewall-accounting(5).
#
ADMINISABSENTMINDED=Yes
#
# ADMINISABSENTMINDED=[Yes|No]
#
# The value of this variable affects Shorewall's stopped state. The behavior
# differs depending on whether shorewall-routestopped(5) or
# shorewall-stoppedrules(5) is used:
#
# routestopped
#
# When ADMINISABSENTMINDED=No, only traffic to/from those addresses
# listed in routestopped is accepted when Shorewall is stopped. When
# ADMINISABSENTMINDED=Yes, in addition to traffic to/from addresses in
# routestopped, connections that were active when Shorewall stopped
# continue to work and all new connections from the firewall system
# itself are allowed.
#
# Note that the routestopped file is not supported in Shorewall 5.0 and
# later versions.
#
# stoppedrules
#
# All existing connections continue to work. To sever all existing
# connections when the firewall is stopped, install the conntrack utility
# and place the command conntrack -F in the stopped user exit (/etc/
# shorewall/stopped).
#
# If ADMINISABSENTMINDED=No, only new connections matching entries in
# stoppedrules are accepted when Shorewall is stopped. Response packets
# and related connections are automatically accepted.
#
# If ADMINISABSENTMINDED=Yes, in addition to connections matching entries
# in stoppedrules, all new connections from the firewall system itself
# are allowed when the firewall is stopped. Response packets and related
# connections are automatically accepted.
#
# If this variable is not set or is given the empty value then
# ADMINISABSENTMINDED=No is assumed.
#
AUTOCOMMENT=Yes
#
# AUTOCOMMENT=[Yes|No]
#
# Formerly named AUTO_COMMENT. If set, if there is not a current comment when
# a macro is invoked, the behavior is as if the first line of the macro file
# was "COMMENT ". If not specified, the AUTO_COMMENT option has a
# default value of 'Yes'.
#
AUTOHELPERS=Yes
#
# AUTOHELPERS=[Yes|No]
#
# Added in Shorewall 4.5.7. When set to Yes (the default), the generated
# ruleset will automatically associate helpers with applications that require
# them (FTP, IRC, etc.). When configuring your firewall on systems running
# kernel 3.5 or later, it is recommended that you:
#
# 1. Set AUTOHELPERS=No.
#
# 2. Modify the HELPERS setting (see below) to list the helpers that you
# need.
#
# 3. Either:
#
# a. Modify shorewall-conntrack (5) to only apply helpers where they are
# required; or
#
# b. Specify the appropriate helper in the HELPER column in
# shorewall-rules (5).
#
# Note
#
# The macros for those applications requiring a helper automatically
# specify the appropriate HELPER where required.
#
AUTOMAKE=Yes
#
# AUTOMAKE=[Yes|No|recursive|depth]
#
# If set, the behavior of the start, reload and restart commands are changed;
# if no files in CONFIG_PATH (see below) have been changed since the last
# successful start, reload or restart command, then the compilation step is
# skipped and the compiled script that executed the last start, reload or
# restart command is used. If not specified, the default is AUTOMAKE=No.
#
# The setting of the AUTOMAKE option is ignored if the start, reload or
# restart command includes a directory name (e.g., shorewall restart /etc/
# shorewall.new).
#
# When AUTOMAKE=Yes, each directory in the CONFIG_PATH was originally
# searched recursively for files newer than the compiled script. That was
# changed in Shorewall 5.1.10.2 such that only the listed directories
# themselves were searched. That broke some configurations that played tricks
# with embedded SHELL such as "SHELL cat /etc/shorewall/rules.d/loc/*.rules".
# Prior to 5.1.10.2, a change to a file in or adding a file to /etc/shorewall
# /rules.d/loc/ would trigger recompilation. Beginning with 5.1.10.2, such
# changes would not trigger recompilation. Beginning with Shorewall 5.2.0,
# the pre-5.1.10.2 behavior can be obtained by setting AUTOMAKE=recursive.
#
# Also beginning with Shorewall 5.2.0, AUTOMAKE may be set to a numeric depth
# which specifies how deeply each listed directory is to be searched.
# AUTOMAKE=1 only searches each directory itself and is equivalent to
# AUTOMAKE=Yes. AUTOMAKE=2 will search each directory and its immediate
# sub-directories; AUTOMAKE=3 will search each directory, each of its
# immediate sub-directories, and each of their immediate sub-directories,
# etc.
#
BALANCE_PROVIDERS=No
#
# BALANCE_PROVIDERS=[Yes|No]
#
# Added in Shorewall 5.1.1. When USE_DEFAULT_RT=Yes, this option determines
# whether the balance provider option (see shorewall-providers(5)) is the
# default. When BALANCE_PROVIDERS=Yes, then the balance option is assumed
# unless the fallback, loose, load or tproxy option is specified. If this
# option is not set or is set to the empty value, then the default value is
# the value of USE_DEFAULT_RT.
#
BASIC_FILTERS=No
#
# BASIC_FILTERS=[Yes|No]
#
# Added in Shorewall-4.6.0. When set to Yes, causes entries in
# shorewall-tcfilters(5) to generate a basic filter rather than a u32 filter.
# This setting requires the Basic Ematch capability in your kernel and
# iptables.
#
# Note
#
# One of the advantages of basic filters is that ipset matches are supported
# in newer iproute2 and kernel versions. Because Shorewall cannot reliably
# detect this capability, use of basic filters is controlled by this option.
#
# The default value is No which causes u32 filters to be generated.
#
BLACKLIST="NEW,INVALID,UNTRACKED"
#
# BLACKLIST=[{ALL|state[,...]}]
#
# where state is one of NEW, ESTABLISHED, RELATED, INVALID,or UNTRACKED.
#
# Added in Shorewall 4.5.13 to replace the BLACKLISTNEWONLY option. Specifies
# the connection tracking states that are to be subject to blacklist
# screening. If BLACKLIST is not specified then the states subject to
# blacklisting are NEW,ESTABLISHED,INVALID,UNTRACKED.
#
# ALL sends all packets through the blacklist chains.
#
# Note: The ESTABLISHED state may not be specified if FASTACCEPT=Yes is
# specified.
#
CLAMPMSS=No
#
# CLAMPMSS=[Yes|No|value]
#
# This parameter enables the TCP Clamp MSS to PMTU feature of Netfilter and
# is usually required when your internet connection is through PPPoE or PPTP.
# If set to Yes or yes, the feature is enabled. If left blank or set to No or
# no, the feature is not enabled.
#
# Important: This option requires CONFIG_IP_NF_TARGET_TCPMSS in your kernel.
#
# You may also set CLAMPMSS to a numeric value (e.g., CLAMPMSS=1400). This
# will set the MSS field in TCP SYN packets going through the firewall to the
# value that you specify.
#
CLEAR_TC=No
#
# CLEAR_TC=[Yes|No]
#
# If this option is set to No then Shorewall won't clear the current traffic
# control rules during [re]start or reload. This setting is intended for use
# by people who prefer to configure traffic shaping when the network
# interfaces come up rather than when the firewall is started. If that is
# what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not supply
# an /etc/shorewall/tcstart file. That way, your traffic shaping rules can
# still use the “fwmark” classifier based on packet marking defined in
# shorewall-tcrules(5). If not specified, CLEAR_TC=Yes is assumed.
#
# Warning
#
# When you specify TC_ENABLED=shared (see below), then you should also
# specify CLEAR_TC=No.
#
COMPLETE=No
#
# COMPLETE=[Yes|No]
#
# Added in Shorewall 4.4.12. When you set this option to Yes, you are
# asserting that the configuration is complete so that your set of zones
# encompasses any hosts that can send or receive traffic to/from/through the
# firewall. This causes Shorewall to omit the rules that catch packets in
# which the source or destination IP address is outside of any of your zones.
# Default is No. It is recommended that this option only be set to Yes if:
#
# □ You have defined an interface whose effective physical setting is '+'.
#
# □ That interface is assigned to a zone.
#
# □ You have no CONTINUE policies or rules.
#
DEFER_DNS_RESOLUTION=Yes
#
# DEFER_DNS_RESOLUTION=[Yes|No]
#
# Added in Shorewall 4.5.12. When set to 'Yes' (the default), DNS names are
# validated in the compiler and then passed on to the generated script where
# they are resolved by ip[6]tables-restore. This is an advantage if you use
# AUTOMAKE=Yes and the IP address associated with the DNS name is subject to
# change. When DEFER_DNS_RESOLUTION=No, DNS names are converted into IP
# addresses by the compiler. This has the advantage that when AUTOMAKE=Yes,
# the start, reload and restart commands will succeed even if no DNS server
# is reachable (assuming that the configuration hasn't changed since the
# compiled script was last generated).
#
# Important
#
# When DEFER_DNS_RESOLUTION=No and AUTOMAKE=Yes and a DNS change makes it
# necessary to recompile an existing firewall script, the -c option must be
# used with the reload or restart command to force recompilation.
#
DELETE_THEN_ADD=Yes
#
# DELETE_THEN_ADD={Yes|No}
#
# If set to Yes (the default value), entries in the /etc/shorewall[6]/rtrules
# files cause an 'ip rule del' command to be generated in addition to an 'ip
# rule add' command. Setting this option to No, causes the 'ip rule del'
# command to be omitted.
#
DONT_LOAD=
#
# DONT_LOAD=[module[,module]...]
#
# Causes Shorewall to not load the listed kernel modules.
#
DYNAMIC_BLACKLIST=Yes
#
# DYNAMIC_BLACKLIST={Yes|No||ipset[-only][,option[,...]][:[setname][:log_level|:l
# og_tag]]]}
#
# Added in Shorewall 4.4.7. When set to No or no, chain-based dynamic
# blacklisting using shorewall [-6] [-l] drop, shorewall [-6] [-l] reject,
# shorewall logdrop and shorewall [-6] [-l] logreject is disabled. Default is
# Yes. Beginning with Shorewall 5.0.8, ipset-based dynamic blacklisting using
# the shorewall blacklist command is also supported. The name of the set (
# setname) and the level (log_level), if any, at which blacklisted traffic is
# to be logged may also be specified. The default IPv4 set name is SW_DBL4
# and the default IPv6 set name is SW_DBL6. The default log level is none (no
# logging). If ipset-only is given, then chain-based dynamic blacklisting is
# disabled just as if DYNAMIC_BLACKLISTING=No had been specified.
#
# Possible options are:
#
# src-dst
#
# Normally, only packets whose source address matches an entry in the
# ipset are dropped. If src-dst is included, then packets whose
# destination address matches an entry in the ipset are also dropped.
#
# disconnect
#
# The disconnect option was added in Shorewall 5.0.13 and requires that
# the conntrack utility be installed on the firewall system. When an
# address is blacklisted using the blacklist command, all connections
# originating from that address are disconnected. if the src-dst option
# was also specified, then all connections to that address are also
# disconnected.
#
# timeout=seconds
#
# Added in Shorewall 5.0.13. Normally, Shorewall creates the dynamic
# blacklisting ipset with timeout 0 which means that entries are
# permanent. If you want entries in the set that are not accessed for a
# period of time to be deleted from the set, you may specify that period
# using this option. Note that the blacklist command can override the
# ipset's timeout setting.
#
# Important
#
# Once the dynamic blacklisting ipset has been created, changing this
# option setting requires a complete restart of the firewall; shorewall
# [-6] restart if RESTART=restart, otherwise shorewall [-6] [-l] stop &&
# shorewall [-6] [-l] start
#
# When ipset-based dynamic blacklisting is enabled, the contents of the
# blacklist will be preserved over stop/reboot/start sequences if SAVE_IPSETS
# =Yes, SAVE_IPSETS=ipv4 or if setname is included in the list of sets to be
# saved in SAVE_IPSETS.
#
EXPAND_POLICIES=Yes
#
# EXPAND_POLICIES={Yes|No}
#
# Normally, when the SOURCE or DEST columns in shorewall-policy(5) contains
# 'all', a single policy chain is created and thes policy is enforced in that
# chain. For example, if the policy entry is
#
# #SOURCE DEST POLICY LOG
# # LEVEL
# net all DROP info
#
# then the chain name is 'net-all' ('net2all if ZONE2ZONE=2) which is also
# the chain named in Shorewall log messages generated as a result of the
# policy. If EXPAND_POLICIES=Yes, then Shorewall will create a separate chain
# for each pair of zones covered by the policy. This makes the resulting log
# messages easier to interpret since the chain in the messages will have a
# name of the form 'a2b' where 'a' is the SOURCE zone and 'b' is the DEST
# zone.
#
EXPORTMODULES=Yes
#
# EXPORTMODULES=[Yes|No]
#
# Added in Shorewall 4.4.17. When set to Yes when compiling for use by
# Shorewall Lite (shorewall [-6] remote-start, shorewall [-6] remote-reload,
# shorewall [-6] remote-restart or shorewall [-6] export commands), the
# compiler will copy the modules or helpers file from the administrative
# system into the script. When set to No or not specified, the compiler will
# not copy the modules or helpers file from /usr/share/shorewall[6] but will
# copy those found in another location on the CONFIG_PATH.
#
# When compiling for direct use by Shorewall, causes the contents of the
# local module or helpers file to be copied into the compiled script. When
# set to No or not set, the compiled script reads the file itself.
#
FASTACCEPT=No
#
# FASTACCEPT={Yes|No}
#
# 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 'loc-net' or 'loc2net'
# chain, depending on the setting of ZONE2ZONE (see below).
#
# If you set FASTACCEPT=Yes, then ESTABLISHED/RELATED 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
# shorewall-rules(5).
#
FORWARD_CLEAR_MARK=Yes
#
# FORWARD_CLEAR_MARK={Yes|No}
#
# Added in Shorewall 4.4.11. Traditionally, Shorewall has cleared the packet
# mark in the first rule in the mangle FORWARD chain. This behavior is
# maintained with the default setting of this option (FORWARD_CLEAR_MARK=
# Yes). If FORWARD_CLEAR_MARK is set to 'No', packet marks set in the mangle
# PREROUTING chain are retained in the FORWARD chains.
#
HELPERS=
#
# HELPERS=[helper[,helper...]]
#
# Added in Shorewall 4.5.7. This option specifies a comma-separated list
# naming the Netfilter application helpers that are to be enabled. If not
# specified, the default is to enable all helpers.
#
# Possible values for helper are:
#
# □ amanda
#
# □ ftp
#
# □ h323
#
# □ irc
#
# □ netbios-ns
#
# □ none - This special value was added in Shorewall 4.5.16 and indicates
# that no helpers are to be enabled. It also prevents the compiler for
# probing for helper support; such probing generates messages on the
# system log of the form "xt_CT: No such helper XXX" where XXX is the
# helper name. When used, none must be the only helper specified.
#
# □ pptp
#
# □ sane
#
# □ sip
#
# □ snmp
#
# □ tftp
#
# When HELPERS is specified on a system running Kernel 3.5.0 or later,
# automatic association of helpers to connections is disabled.
#
IGNOREUNKNOWNVARIABLES=No
#
# IGNOREUNKNOWNVARIABLES=[Yes|No]
#
# Added in Shorewall 4.5.11. Normally, if an unknown shell variable is
# encountered in a configuration file (except in ?IF and ?ELSIF directives),
# the compiler raises a fatal error. If IGNOREUNKNOWNVARIABLES is set to Yes,
# then such variables simply expand to an empty string. Default is No.
#
IMPLICIT_CONTINUE=No
#
# IMPLICIT_CONTINUE={Yes|No}
#
# When this option is set to Yes, it causes subzones to be treated
# differently with respect to policies.
#
# Subzones are defined by following their name with ":" and a list of parent
# zones (in shorewall-zones(5)). Normally, you want to have a set of special
# rules for the subzone and if a connection doesn't match any of those
# subzone-specific rules then you want the parent zone rules and policies to
# be applied; see shorewall-nesting(5). With IMPLICIT_CONTINUE=Yes, that
# happens automatically.
#
# If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set, then subzones
# are not subject to this special treatment. With IMPLICIT_CONTINUE=Yes, an
# implicit CONTINUE policy may be overridden by including an explicit policy
# (one that does not specify "all" in either the SOURCE or the DEST columns).
#
IPSET_WARNINGS=Yes
#
# IPSET_WARNINGS={Yes|No}
#
# Added in Shorewall 4.5.2. Default is Yes. When set, causes the rules
# compiler to issue a warning when:
#
# □ The compiler is being run by root and an ipset specified in the
# configuration does not exists. Only one warning is issued for each
# missing ipset.
#
# □ When [src] is specified in a destination column and when [dst] is
# specified in a source column.
#
IP_FORWARDING=Keep
#
# IP_FORWARDING=[On|Off|Keep]
#
# This IPv4 parameter determines whether Shorewall enables or disables IPv4
# Packet Forwarding (/proc/sys/net/ipv4/ip_forward). In an IPv6
# configuration, this parameter determines the setting of /proc/sys/net/ipv6/
# config/all/ip_forwarding.
#
# Possible values are:
#
# On or on
#
# packet forwarding will be enabled.
#
# Off or off
#
# packet forwarding will be disabled.
#
# Keep or keep
#
# Shorewall will neither enable nor disable packet forwarding.
#
# If this variable is not set or is given an empty value (IP_FORWARD="") then
# IP_FORWARD=On is assumed.
#
KEEP_RT_TABLES=Yes
#
# KEEP_RT_TABLES={Yes|No}
#
# IPv4:
#
# When set to Yes, this option prevents generated scripts from altering
# the /etc/iproute2/rt_tables database when there are entries in /etc/
# shorewall/providers. If you set this option to Yes while Shorewall
# (Shorewall-lite) is running, you should remove the file /var/lib/
# shorewall/rt_tables (/var/lib/shorewall-lite/rt_tables) before your
# next stop, restore, reload or restart command.
#
# IPv6:
#
# When set to Yes, this option prevents scripts generated by Shorewall6
# from altering the /etc/iproute2/rt_tables database when there are
# entries in /etc/shorewall6/providers. If you set this option to Yes
# while Shorewall6 (Shorewall6-lite) is running, you should remove the
# file /var/lib/shorewall6/rt_tables (/var/lib/shorewall6-lite/rt_tables)
# before your next stop, restore, reload or restart command.
#
# Important
#
# When both IPv4 and IPv6 Shorewall configurations are present,
# KEEP_RT_TABLES=No should be specified in only one of the two configurations
# unless the two provider configurations are identical with respect to
# interface and provider names and numbers.
#
# The default is KEEP_RT_TABLES=No.
#
MACLIST_TABLE=filter
#
# MACLIST_TABLE=[filter|mangle]
#
# Normally, MAC verification occurs in the filter table (INPUT and FORWARD)
# chains. When forwarding a packet from an interface with MAC verification to
# a bridge interface, that doesn't work.
#
# This problem can be worked around by setting MACLIST_TABLE=mangle which
# will cause Mac verification to occur out of the PREROUTING chain. Because
# REJECT isn't available in that environment, you may not specify
# MACLIST_DISPOSITION=REJECT or MACLIST_DISPOSITION=A_REJECT with
# MACLIST_TABLE=mangle.
#
MACLIST_TTL=
#
# MACLIST_TTL=[number]
#
# The performance of configurations with a large numbers of entries in
# shorewall-maclist(5) can be improved by setting the MACLIST_TTL variable in
# shorewall[6].conf(5).
#
# If your iptables and kernel support the "Recent Match" (see the output of
# "shorewall check" near the top), you can cache the results of a 'maclist'
# file lookup and thus reduce the overhead associated with MAC Verification.
#
# When a new connection arrives from a 'maclist' interface, the packet passes
# through then list of entries for that interface in shorewall-maclist(5). If
# there is a match then the source IP address is added to the 'Recent' set
# for that interface. Subsequent connection attempts from that IP address
# occurring within $MACLIST_TTL seconds will be accepted without having to
# scan all of the entries. After $MACLIST_TTL from the first accepted
# connection request from an IP address, the next connection request from
# that IP address will be checked against the entire list.
#
# If MACLIST_TTL is not specified or is specified as empty (e.g, MACLIST_TTL=
# "" or is specified as zero then 'maclist' lookups will not be cached).
#
MANGLE_ENABLED=Yes
#
# MANGLE_ENABLED=[Yes|No]
#
# Determines whether Shorewall will generate rules in the Netfilter mangle
# table. Setting MANGLE_ENABLED=No disables all Shorewall features that
# require the mangle table. The default is MANGLE_ENABLED=Yes.
#
MARK_IN_FORWARD_CHAIN=No
#
# MARK_IN_FORWARD_CHAIN=[Yes|No]
#
# If your kernel has a FORWARD chain in the mangle table, you may set
# MARK_IN_FORWARD_CHAIN=Yes to cause the marking specified in the tcrules
# file to occur in that chain rather than in the PREROUTING chain. This
# permits you to mark inbound traffic based on its destination address when
# DNAT is in use. To determine if your kernel has a FORWARD chain in the
# mangle table, use the shorewall [-6] show mangle command; if a FORWARD
# chain is displayed then your kernel will support this option. If this
# option is not specified or if it is given the empty value (e.g.,
# MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed.
#
MINIUPNPD=No
#
# MINIUPNPD=[Yes|No]
#
# Added in Shorewall 5.0.8. If set to Yes, Shorewall will create a chain in
# the nat table named MINIUPNPD-POSTROUTING and will add jumps from
# POSTROUTING to that chain for each interface with the upnpd option
# specified. Default is No.
#
MUTEX_TIMEOUT=60
#
# MUTEX_TIMEOUT=[seconds]
#
# The value of this variable determines the number of seconds that programs
# will wait for exclusive access to the Shorewall[6] lock file. After the
# number of seconds corresponding to the value of this variable, programs
# will assume that the last program to hold the lock died without releasing
# the lock.
#
# If not set or set to the empty value, a value of 60 (60 seconds) is
# assumed.
#
# An appropriate value for this parameter would be twice the length of time
# that it takes your firewall system to process a shorewall [-6] restart
# command.
#
OPTIMIZE=All
#
# OPTIMIZE=[value]
#
# The specified value enables certain optimizations. Each optimization
# category is associated with a power of two. To enable multiple optimization
# categories, simply add their corresponding numbers together.
#
# Beginning with Shorewall 4.5.20, you may specify OPTIMIZE=All to enable all
# optimization categories, and you may also specify OPTIMIZE=None to disable
# optimization.
#
# □ Optimization category 1 - Traditionally, Shorewall has created rules
# for the complete matrix of host groups defined by the zones, interfaces
# and hosts files. Any traffic that didn't correspond to an element of
# that matrix was rejected in one of the built-in chains. When the matrix
# is sparse, this results in lots of largely useless rules.
#
# These extra rules can be eliminated by setting the 1 bit in OPTIMIZE.
#
# The 1 bit setting also controls the suppression of redundant wildcard
# rules (those specifying "all" in the SOURCE or DEST column). A wildcard
# rule is considered to be redundant when it has the same ACTION and Log
# Level as the applicable policy.
#
# Note
#
# Optimization level 1 is ignored when optimization level 4 is also
# selected, since level 4 performs similar optimizations in a more robust
# way.
#
# □ Optimization category 2 - Added in Shorewall 4.4.7. When set,
# suppresses superfluous ACCEPT rules in a policy chain that implements
# an ACCEPT policy. Any ACCEPT rules that immediately precede the final
# blanket ACCEPT rule in the chain are now omitted.
#
# □ Optimization category 4 - Added in Shorewall 4.4.7. When set, causes
# short chains (those with less than 2 rules) to be optimized away. The
# following chains are excluded from optimization:
#
# ☆ accounting chains (unless OPTIMIZE_ACCOUNTING=Yes)
#
# ☆ action chains (user-defined)
#
# ☆ 'blacklst' chain
#
# ☆ dynamic
#
# ☆ forwardUPnP
#
# ☆ UPnP (nat table)
#
# Additionally:
#
# ☆ If a built-in chain has a single rule that branches to a second
# chain, then the rules from the second chain are moved to the
# built-in chain and the target chain is omitted.
#
# ☆ Chains with no references are deleted.
#
# ☆ Accounting chains are subject to optimization if the
# OPTIMIZE_ACCOUNTING option is set to 'Yes'.
#
# ☆ If a chain ends with an unconditional branch to a second chain
# (other than to 'reject'), then the branch is deleted from the first
# chain and the rules from the second chain are appended to it.
#
# An additional optimization was added in Shorewall 4.5.4. If the last
# rule in a chain is an unqualified jump to a simple target, then all
# immediately preceding rules with the same simple target are omitted.
#
# For example, consider this chain:
#
# -A fw-net -p udp --dport 67:68 -j ACCEPT
# -A fw-net -p udp --sport 1194 -j ACCEPT
# -A fw-net -p 41 -j ACCEPT
# -A fw-net -j ACCEPT
#
# Since all of the rules are jumps to the simple target ACCEPT, this
# chain is totally optimized away and jumps to the chain are replace with
# jumps to ACCEPT.
#
# □ Optimization category 8 - Added in Shorewall 4.4.9. When set, causes
# chains with identical rules to be collapsed into a single chain.
#
# Warning
#
# While Optimization category 8 can significantly reduce the size of the
# generated iptables ruleset, it can also take significant system
# resources during compilation. If you find that compilation takes an
# unreasonably long time, try disabling this category by setting OPTIMIZE
# =23.
#
# □ Optimization category 16 - Added in Shorewall 4.4.26. When set, causes
# sequences of compatible rules to be combined into a single rule. Rules
# are considered compatible if they differ only in their destination
# ports and comments.
#
# A sequence of compatible rules is often generated when macros are
# invoked in sequence.
#
# The ability to combine adjacent rules is limited by two factors:
#
# ☆ Destination port lists may only be combined up to a maximum of 15
# ports, where a port-pair counts as two ports.
#
# ☆ Rules may only be combined until the length of their concatenated
# comment reaches 255 characters.
#
# When either of these limits would be exceeded, the current combined
# rule is emitted and the compiler attempts to combine rules beginning
# with the one that would have exceeded the limit. Adjacent combined
# comments are separated by ', '. Empty comments at the front of a group
# of combined comments are replaced by 'Others and'. Empty comments at
# the end of a group of combined comments are replaced by 'and others'.
#
# Beginning in Shorewall 4.5.10, this option also suppresses duplicate
# adjacent rules and duplicate non-adjacent rules that don't include mark
# , connmark, dscp, ecn, set, tos or u32 matches.
#
# Example 1:
#
# Rules with comments "FOO", and "BAR" would result in the
# combined comment "FOO and others, BAR".
#
# Example 2:
#
# Rules with comments , "FOO" and "BAR" would result in the
# combined comment "Others and FOO, BAR". Note: Optimize level 16
# requires "Extended Multi-port Match" in your iptables and kernel.
#
# In versions prior to 5.1.0, the default value is zero which disables all
# optimizations. Beginning with Shorewall 5.1.0, the default value is All
# which enables all optimizations.
#
OPTIMIZE_ACCOUNTING=No
#
# OPTIMIZE_ACCOUNTING=[Yes|No]
#
# Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting changes are
# subject to optimization (OPTIMIZE=4,5,6 or 7). If not specified or set to
# the empty value, OPTIMIZE_ACCOUNTING=No is assumed.
#
PERL_HASH_SEED=0
#
# PERL_HASH_SEED=seed|random
#
# Added in Shorewall 5.1.4. Sets the Perl hash seed (an integer in the range
# 0-99999) when running the Shorewall rules compiler. If not specified, the
# value 0 is assumed. If random is specified, a random seed will be chosed by
# Perl. See perlsec(1) for additional information.
#
REJECT_ACTION=
#
# REJECT_ACTION=action
#
# Added in Shorewall 4.5.21. When a REJECT target is specified, Shorewall
# normally handles the response as follows:
#
# □ If the destination address of the packet is a broadcast or multicast
# address, the packet is dropped.
#
# □ if the protocol is ICMP (2) then the packet is dropped.
#
# □ if the protocol is TCP (6) then the packet is rejected with an RST.
#
# □ if the protocol is UDP (17) then the packet is rejected with an
# 'port-unreachable' ICMP.
#
# □ if the protocol is ICMP (1) then the packet is rejected with a
# 'host-unreachable' ICMP.
#
# □ if the protocol is ICMP6 (1) then the packet is rejected with a
# 'icmp6-addr-unreachable' ICMP6.
#
# □ otherwise, the packet is rejected with a 'host-prohibited' ICMP.
#
# You can modify this behavior by implementing your own action that handles
# REJECT and specifying it's name in this option. The nolog and noinline
# options will automatically be assumed for the specified action.
#
# The following action implements the default reject action:
#
# ?format 2
# #TARGET SOURCE DEST PROTO
# Broadcast(DROP) - - -
# DROP - - 2
# INLINE - - 6 ;; -j REJECT --reject-with tcp-reset
# ?if __ENHANCED_REJECT
# INLINE - - 17 ;; -j REJECT
# ?if __IPV4
# INLINE - - 1 ;; -j REJECT --reject-with icmp-host-unreachable
# INLINE - - - ;; -j REJECT --reject-with icmp-host-prohibited
# ?else
# INLINE - - 58 ;; -j REJECT --reject-with icmp6-addr-unreachable
# INLINE - - - ;; -j REJECT --reject-with icmp6-adm-prohibited
# ?endif
# ?else
# INLINE - - - ;; -j REJECT
# ?endif
#
RENAME_COMBINED=Yes
#
# RENAME_COMBINED=[Yes|No]
#
# Added in Shorewall 5.2.0. Traditionally, when OPTIMIZE category 8 is
# enabled, identical chains are combined under a name beginning with '~comb'
# or '~blacklist'. This behavior is maintained under the default setting
# RENAME_COMBINED=Yes. If RENAMED_COMBINED=No, the chains are combined under
# the original name of one of the chains.
#
REQUIRE_INTERFACE=No
#
# REQUIRE_INTERFACE=[Yes|No]
#
# Added in Shorewall 4.4.10. The default is No. If set to Yes, at least one
# optional interface must be up in order for the firewall to be in the
# started state. Intended to be used with the Shorewall Init Package.
#
RESTART=restart
#
# RESTART=[restart|reload]
#
# Added in Shorewall 5.0.1 to replace LEGACY_RESTART which was added in
# Shorewall 5.0.0. In that release, the reload command was redefined to do
# what restart had done in earlier releases and restart became a true restart
# (equivalent to stop followed by start). When RESTART=reload, the restart
# command performs the same operation as the reload command making it
# compatible with earlier releases. If not specified, RESTART=reload is
# assumed.
#
RESTORE_DEFAULT_ROUTE=Yes
#
# RESTORE_DEFAULT_ROUTE=[Yes|No]
#
# This option determines whether to restore the default route saved when here
# are 'balance' providers defined but all of them are down.
#
# The default is RESTORE_DEFAULT_ROUTE=Yes which preserves the pre-4.2.6
# behavior.
#
# RESTORE_DEFAULT_ROUTE=No is appropriate when you don't want a default route
# in the main table (USE_DEFAULT_RT=No) or in the default table
# (USE_DEFAULT_RT=Yes) when there are no balance providers available. In that
# case, RESTORE_DEFAULT_ROUTE=No will cause any default route in the relevant
# table to be deleted.
#
RESTORE_ROUTEMARKS=Yes
#
# RESTORE_ROUTEMARKS=[Yes|No]
#
# Added in Shorewall 4.5.9. When set to Yes (the default), provider marks are
# restored unconditionally at the top of the mangle OUTPUT and PREROUTING
# chains, even if the saved mark is zero. When this option is set to No, the
# mark is restored only if it is non-zero. If you have problems with IPSEC
# ESP packets not being routed correctly on output, try setting this option
# to No.
#
SAVE_IPSETS=No
#
# SAVE_IPSETS={Yes|No|ipv4|setlist}
#
# Re-enabled in Shorewall 4.4.6. If SAVE_IPSETS=Yes, then the current
# contents of your ipsets will be saved by the shorewall stop and shorewall
# save commands and restored by the shorewall start and shorewall restore
# commands.
#
# Beginning with Shorewall 4.6.4, you can restrict the set of ipsets saved by
# specifying a setlist (a comma-separated list of ipv4 ipset names). You may
# also restrict the saved sets to just the ipv4 ones by specifying ipv4.
#
TC_ENABLED=Shared
#
# TC_ENABLED=[Yes|No|Internal|Simple|Shared]
#
# If you say Yes or yes here, Shorewall will use a script that you supply to
# configure traffic shaping. The script must be named 'tcstart' and must be
# placed in a directory on your CONFIG_PATH.
#
# If you say No or no then traffic shaping is not enabled.
#
# If you set TC_ENABLED=Simple (Shorewall 4.4.6 and later), simple traffic
# shaping using shorewall-tcinterfaces(5) and shorewall-tcpri(5) is enabled.
#
# If you set TC_ENABLED=Internal or internal or leave the option empty then
# Shorewall will use its builtin traffic shaper (tc4shorewall written by Arne
# Bernin.
#
# Beginning with Shorewall 4.4.15, you can set TC_ENABLED=Shared. This allows
# you to configure the tcdevices and tcclasses in your Shorewall6
# configuration yet make them available to the compiler when compiling your
# Shorewall configuration. In addition to setting TC_ENABLED=Shared, you need
# to create symbolic links from your Shorewall configuration directory
# (normally /etc/shorewall/) to the tcdevices and tcclasses files in your
# Shorewall6 configuration directory (normally /etc/shorewall6/).
#
TC_EXPERT=No
#
# TC_EXPERT={Yes|No}
#
# Normally, Shorewall tries to protect users from themselves by preventing
# PREROUTING and OUTPUT tcrules from being applied to packets that have been
# marked by the 'track' option in shorewall-providers(5).
#
# If you know what you are doing, you can set TC_EXPERT=Yes and Shorewall
# will not include these cautionary checks.
#
TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2"
#
# TC_PRIOMAP=map
#
# Added in Shorewall 4.4.6. Determines the mapping of a packet's TOS field to
# priority bands. See shorewall-tcpri(5). The map consists of 16
# space-separated digits with values 1, 2 or 3. A value of 1 corresponds to
# Linux priority 0, 2 to Linux priority 1, and 3 to Linux Priority 2. The
# first entry gives the priority of TOS value 0, the second of TOS value 1,
# and so on. See tc-prio(8) for additional information.
#
# The default setting is TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2".
#
TRACK_PROVIDERS=Yes
#
# TRACK_PROVIDERS={Yes|No}
#
# Added in Shorewall 4.4.3. When set to Yes, causes the track option to be
# assumed on all providers defined in shorewall-providers(5). May be
# overridden on an individual provider through use of the notrack option. The
# default value is 'No'.
#
# Beginning in Shorewall 4.4.6, setting this option to 'Yes' also simplifies
# PREROUTING rules in shorewall-tcrules(5). Previously, when TC_EXPERT=No,
# packets arriving through 'tracked' provider interfaces were unconditionally
# passed to the PREROUTING tcrules. This was done so that tcrules could reset
# the packet mark to zero, thus allowing the packet to be routed using the
# 'main' routing table. Using the main table allowed dynamic routes (such as
# those added for VPNs) to be effective. The rtrules file was created to
# provide a better alternative to clearing the packet mark. As a consequence,
# passing these packets to PREROUTING complicates things without providing
# any real benefit. Beginning with Shorewall 4.4.6, when TRACK_PROVIDERS=Yes
# and TC_EXPERT=No, packets arriving through 'tracked' interfaces will not be
# passed to the PREROUTING rules. Since TRACK_PROVIDERS was just introduced
# in 4.4.3, this change should be transparent to most, if not all, users.
#
TRACK_RULES=No
#
# TRACK_RULES={Yes|No|File}
#
# Added in Shorewall 4.5.20. If set to Yes, causes the compiler to add a
# comment to iptables rules to indicate the file name and line number of the
# configuration entry that generated the rule. If set to No (the default),
# then no such comments are added.
#
# Setting this option to Yes requires the Comments capability in iptables and
# kernel.
#
# Beginning with Shorewall 5.0.5, the option may also be set to File. That
# setting causes similar comments to be added to the .iptables-restore-input
# file, which is normally created in /var/lib/shorewall.
#
USE_DEFAULT_RT=Yes
#
# USE_DEFAULT_RT=[Yes|No]
#
# When set to 'Yes', this option causes the Shorewall multi-ISP feature to
# create a set of routing rules which are resilient to changes in the main
# routing table. Such changes can occur for a number of reasons, VPNs going
# up and down being an example. The idea is to send packets through the main
# table prior to applying any of the Shorewall-generated routing rules. So
# changes to the main table will affect the routing of packets by default.
#
# When USE_DEFAULT_RT=Yes:
#
# 1. Both the DUPLICATE and the COPY columns in providers(5) file must
# remain empty (or contain "-").
#
# 2. The default route is added to the the 'default' table rather than to
# the main table.
#
# 3. If running Shorewall 5.1.0 or earlier or if BALANCE_PROVIDERS=Yes
# (Shorewall 5.1.1 or later), then the balance provider option is assumed
# unless the fallback, loose, load or tproxy option is specified.
#
# 4. Packets are sent through the main routing table by a rule with priority
# 999. In shorewall-rtrules(5), the range 1-998 may be used for inserting
# rules that bypass the main table.
#
# 5. All provider gateways must be specified explicitly in the GATEWAY
# column. detect may not be specified.
#
# Note
#
# detect may be specified for interfaces whose configuration is managed
# by dhcpcd. Shorewall will use dhcpcd's database to find the interface's
# gateway.
#
# 6. You should disable all default route management outside of Shorewall.
# If a default route is added to the main table while Shorewall is
# started, then all policy routing will stop working (except for those
# routing rules in the priority range 1-998).
#
# Prior to Shorewall 4.6.0, if USE_DEFAULT_RT was not set or if it was set to
# the empty string then USE_DEFAULT_RT=No was assumed. Beginning with
# Shorewall 4.6.0, the default is USE_DEFAULT_RT=Yes and use of
# USE_DEFAULT_RT=No is deprecated.
#
# Warning
#
# The enable, disable and reenable commands do not work correctly when
# USE_DEFAULT_RT=No.
#
USE_NFLOG_SIZE=No
#
# USE_NFLOG_SIZE=[Yes|No]
#
# Added in Shorewall 5.1.5. The second parameter to the NFLOG target
# specifies how many bytes of the packet to copy to the log; if omitted or if
# supplied as zero, the entire packet is copied. This feature has
# traditionally been implemented using the --nflog-range option to the NFLOG
# iptables target. Unfortuntely, the --nflog-range option never worked (the
# entire packet was always copied). To deal with this issue, the Netfilter
# team:
#
# □ Added a warning message when --nflog-range is used
#
# □ Added --nflog-size which works like --nflog-range was intended to work.
#
# When USE_NFLOG_SIZE=Yes, Shorewall will attempt to use the new --nflog-size
# feature. If that feature is not available in the running kernel and ip[6]
# tables, an error is raised.
#
# When USE_NFLOG_SIZE is not supplied, USE_NFLOG_SIZE=No is assumed. When
# USE_NFLOG_SIZE is added by shorewall update, it is added with setting No.
#
USE_PHYSICAL_NAMES=No
#
# USE_PHYSICAL_NAMES=[Yes|No]
#
# Added in Shorewall 4.4.27. Normally, when Shorewall creates a Netfilter
# chain that relates to an interface, it uses the interface's logical name as
# the base of the chain name. For example, if the logical name for an
# interface is OAKLAND, then the input chain for traffic arriving on that
# interface would be 'OAKLAND_in'. If this option is set to Yes, then the
# physical name of the interface will be used the base of the chain name.
#
USE_RT_NAMES=No
#
# USE_RT_NAMES=[Yes|No]
#
# Added in Shorewall 4.5.15. When set to 'Yes', Shorewall will use routing
# table (provider) names in the generated script rather than table numbers.
# When set to 'No' (the default), routing table numbers will be used.
#
# Caution
#
# If you set USE_RT_NAMES=Yes and KEEP_RT_TABLES=Yes, then you must insure
# that all of your providers have entries in /etc/iproute2/rt_tables as well
# as the following entries:
#
# 255 local
# 254 main
# 253 default
# 250 balance
# 0 unspec
#
# Without these entries, the firewall will fail to start.
#
VERBOSE_MESSAGES=Yes
#
# VERBOSE_MESSAGES=[Yes|No]
#
# Added in Shorewall 5.0.9. When Yes (the default), messages produced by the
# ?INFO and ?WARNING directives include the filename and linenumber of the
# directive. When set to No, that additional information is omitted. The
# setting may be overridden on a directive by directive basis by following ?
# INFO or ?WARNING with '!' (no intervening white space).
#
WARNOLDCAPVERSION=Yes
#
# WARNOLDCAPVERSION=[Yes|No]
#
# Added in Shorewall 4.5.12. When set to Yes (the default), the compiler
# issues a warning when it finds a capabilities file that doesn't specify all
# of the capabilities supported by the compiler. When WARNOLDCAPVERSION is
# set to No, no warning is issued.
#
WORKAROUNDS=No
#
# WORKAROUNDS=[Yes|No]
#
# Added in Shorewall 4.6.11. Over time, there have been a number of changes
# in Shorewall that work around defects in other products such as iptables
# and ipset. When WORKAROUNDS=Yes, these workarounds are enabled; when
# WORKAROUNDS=No, they are disabled. If not specified or if specified as
# empty, WORKAROUNDS=Yes is assumed.
#
# Warning
#
# Do not set WORKAROUNDS=Yes if you need to be able to use
# Shorewall-generated scripts (such as created by the save command) built by
# Shorewall 4.4.7 or older.
#
ZERO_MARKS=No
#
# ZERO_MARKS=[Yes|No]
#
# Added in Shorewall 5.0.12, this is a workaround for an issue where packet
# marks are not zeroed by the kernel. It should be set to No (the default)
# unless you find that incoming packets are being mis-routed for no apparent
# reasons.
#
# Caution
#
# Do not set this option to Yes if you have IPSEC software running on the
# firewall system.
#
ZONE2ZONE=-
#
# ZONE2ZONE=[2|-]
#
# Added in Shorewall 4.4.4. This option determines how Shorewall constructs
# chain names involving zone names and/or 'all'. Beginning with Shorewall
# 4.6.0, the default is '-' (e.g., fw-net); prior to that release, the
# default was '2' (e.g., fw2net).
#
###############################################################################
# P A C K E T D I S P O S I T I O N
###############################################################################
BLACKLIST_DISPOSITION=DROP
#
# BLACKLIST_DISPOSITION=[DROP|A_DROP|REJECT|A_REJECT]
#
# This parameter determines the disposition of packets from blacklisted
# hosts. It may have the value DROP if the packets are to be dropped or
# REJECT if the packets are to be replied with an ICMP port unreachable reply
# or a TCP RST (tcp only). If you do not assign a value or if you assign an
# empty value then DROP is assumed.
#
# A_DROP and A_REJECT are audited versions of DROP and REJECT respectively
# and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel
# and iptables.
#
# The BLACKLIST_DISPOSITION setting determines the disposition of packets
# sent to the blacklog target of shorewall-blrules (5), but otherwise does
# not affect entries in that file.
#
INVALID_DISPOSITION=CONTINUE
#
# INVALID_DISPOSITION=[A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
#
# Added in Shorewall 4.5.13. Shorewall has traditionally passed INVALID
# packets through the NEW section of shorewall-rules (5). When a packet in
# INVALID state fails to match any rule in the INVALID section, the packet is
# disposed of based on this setting. The default value is CONTINUE for
# compatibility with earlier versions.
#
MACLIST_DISPOSITION=REJECT
#
# MACLIST_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]
#
# Determines the disposition of connections requests that fail MAC
# Verification and must have the value ACCEPT (accept the connection request
# anyway), REJECT (reject the connection request) or DROP (ignore the
# connection request). If not set or if set to the empty value (e.g.,
# MACLIST_DISPOSITION="") then MACLIST_DISPOSITION=REJECT is assumed.
#
# A_DROP and A_REJECT are audited versions of DROP and REJECT respectively
# and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel
# and ip[6]tables.
#
RELATED_DISPOSITION=ACCEPT
#
# RELATED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
#
# Added in Shorewall 4.4.27. Shorewall has traditionally ACCEPTed RELATED
# packets that don't match any rule in the RELATED section of shorewall-rules
# (5). Concern about the safety of this practice resulted in the addition of
# this option. When a packet in RELATED state fails to match any rule in the
# RELATED section, the packet is disposed of based on this setting. The
# default value is ACCEPT for compatibility with earlier versions.
#
SFILTER_DISPOSITION=DROP
#
# SFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]
#
# Added in Shorewall 4.4.20. Determines the disposition of packets matching
# the sfilter option (see shorewall-interfaces(5)) and of hairpin packets on
# interfaces without the routeback option.^[1]
#
RPFILTER_DISPOSITION=DROP
#
# RPFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]
#
# Added in Shorewall 4.5.7. Determines the disposition of packets entering
# from interfaces the rpfilter option (see shorewall-interfaces(5)). Packets
# disposed of by this option are those whose response packets would not be
# sent through the same interface receiving the packet.
#
SMURF_DISPOSITION=DROP
#
# SMURF_DISPOSITION=[DROP|A_DROP]
#
# Added in Shorewall 4.4.20. The default setting is DROP which causes smurf
# packets (see the nosmurfs option in shorewall-interfaces(5)) to be dropped.
# A_DROP causes the packets to be audited prior to being dropped and requires
# AUDIT_TARGET support in the kernel and iptables.
#
TCP_FLAGS_DISPOSITION=DROP
#
# TCP_FLAGS_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]
#
# Determines the disposition of TCP packets that fail the checks enabled by
# the tcpflags interface option (see shorewall-interfaces(5)) and must have a
# value of ACCEPT (accept the packet), REJECT (send an RST response) or DROP
# (ignore the packet). If not set or if set to the empty value (e.g.,
# TCP_FLAGS_DISPOSITION="") then TCP_FLAGS_DISPOSITION=DROP is assumed.
#
# A_DROP and A_REJECT are audited versions of DROP and REJECT respectively
# and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel
# and iptables.
#
UNTRACKED_DISPOSITION=CONTINUE
#
# UNTRACKED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
#
# Added in Shorewall 4.5.13. Shorewall has traditionally passed UNTRACKED
# packets through the NEW section of shorewall-rules (5). When a packet in
# UNTRACKED state fails to match any rule in the UNTRACKED section, the
# packet is disposed of based on this setting. The default value is CONTINUE
# for compatibility with earlier versions.
#
################################################################################
# P A C K E T M A R K L A Y O U T
################################################################################
TC_BITS=
#
# TC_BITS=[number]
#
# The number of bits at the low end of the 32-bit packet mark to be used for
# traffic shaping marking. May be zero. See MASK_BITS above for default
# value.
#
PROVIDER_BITS=
#
# PROVIDER_BITS=[number]
#
# Added in Shorewall 4.4.26. The number of bits in the 32-bit packet mark to
# be used for provider numbers. May be zero. See MASK_BITS above for default
# value.
#
PROVIDER_OFFSET=
#
# PROVIDER_OFFSET=[number]If
#
# Added in Shorewall 4.4.26. The offset from the right (low-order end) of the
# provider number field in the 32-bit packet mark. If non-zero, must be >=
# TC_BITS (Shorewall automatically adjusts PROVIDER_OFFSET's value).
# PROVIDER_OFFSET + PROVIDER_BITS + ZONE_BITS must be < 32. See MASK_BITS
# above for default value.
#
MASK_BITS=
#
# MASK_BITS=[number]
#
# Added in Shorewall 4.4.26. Number of bits on the right of the 32-bit packet
# mark to be masked when clearing the traffic shaping mark. Must be >=
# TC_BITS and <= PROVIDER_OFFSET (if PROVIDER_OFFSET > 0). Prior to Shorewall
# 5.0.0, default value and the default values of the other mark layout
# options is determined as follows:
#
# Table 1. Default Packet Mark Layout
#
# WIDE_TC_MARKS=No, TC_BITS=8, PROVIDER_BITS=8, PROVIDER_OFFSET=
# HIGH_ROUTE_MARKS=No 0, MASK_BITS=8
# WIDE_TC_MARKS=No, TC_BITS=8, PROVIDER_BITS=8, PROVIDER_OFFSET=
# HIGH_ROUTE_MARKS=Yes 8, MASK_BITS=8
# WIDE_TC_MARKS=Yes, TC_BITS=14, PROVIDER_BITS=8, PROVIDER_OFFSET=
# HIGH_ROUTE_MARKS=No 0, MASK_BITS=16
# WIDE_TC_MARKS=Yes, TC_BITS=14, PROVIDER_BITS=8, PROVIDER_OFFSET=
# HIGH_ROUTE_MARKS=Yes 16, MASK_BITS=16
#
#
# From 5.0.0 onward, the default value of MASK_BITS is 8, the default value
# of PROVIDER_BITS, TC_BITS, MASK_BITS and PROVIDER_OFFSET is 8.
#
ZONE_BITS=0
#
# ZONE_BITS=[number]
#
# Added in Shorewall 4.4.26. When non-zero, enables automatic packet marking
# by source zone and determines the number of bits in the 32-bit packet mark
# to be used for the zone mark. Default value is 0.
#
shorewall6-5.2.3.4/Samples6/one-interface/shorewall6.conf 0000664 0000000 0000000 00000012135 13531060406 021617 0 ustar root root ###############################################################################
#
# Shorewall Version 5 -- /etc/shorewall6/shorewall6.conf
# Copyright (C) 2012-2015 by the Shorewall Team
#
# For information about the settings in this file, type "man shorewall6.conf"
#
# Manpage also online at
# http://www.shorewall.net/manpages6/shorewall6.conf.html
###############################################################################
# S T A R T U P E N A B L E D
###############################################################################
STARTUP_ENABLED=No
###############################################################################
# V E R B O S I T Y
###############################################################################
VERBOSITY=1
###############################################################################
# P A G E R
###############################################################################
PAGER=
###############################################################################
# F I R E W A L L
###############################################################################
FIREWALL=
###############################################################################
# L O G G I N G
###############################################################################
LOG_LEVEL="info"
BLACKLIST_LOG_LEVEL=
INVALID_LOG_LEVEL=
LOG_BACKEND=
LOG_VERBOSITY=2
LOG_ZONE=Both
LOGALLNEW=
LOGFILE=
LOGFORMAT="%s %s "
LOGLIMIT="s:1/sec:10"
LOGTAGONLY=No
MACLIST_LOG_LEVEL="$LOG_LEVEL"
RELATED_LOG_LEVEL=
RPFILTER_LOG_LEVEL="$LOG_LEVEL"
SFILTER_LOG_LEVEL="$LOG_LEVEL"
SMURF_LOG_LEVEL="$LOG_LEVEL"
STARTUP_LOG=/var/log/shorewall6-init.log
TCP_FLAGS_LOG_LEVEL="$LOG_LEVEL"
UNTRACKED_LOG_LEVEL=
###############################################################################
# L O C A T I O N O F F I L E S A N D D I R E C T O R I E S
###############################################################################
CONFIG_PATH=":${CONFDIR}/shorewall6:/usr/share/shorewall6:${SHAREDIR}/shorewall"
GEOIPDIR=/usr/share/xt_geoip/LE
IP6TABLES=
IP=
IPSET=
LOCKFILE=
MODULESDIR=
NFACCT=
PERL=/usr/bin/perl
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
RESTOREFILE=restore
SHOREWALL_SHELL=/bin/sh
SUBSYSLOCK=
TC=
###############################################################################
# D E F A U L T A C T I O N S / M A C R O S
###############################################################################
ACCEPT_DEFAULT="none"
BLACKLIST_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP),dropNotSyn:$LOG_LEVEL,dropInvalid:$LOG_LEVEL,DropDNSrep:$LOG_LEVEL"
DROP_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)"
NFQUEUE_DEFAULT="none"
QUEUE_DEFAULT="none"
REJECT_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)"
###############################################################################
# R S H / R C P C O M M A N D S
###############################################################################
RCP_COMMAND='scp ${files} ${root}@${system}:${destination}'
RSH_COMMAND='ssh ${root}@${system} ${command}'
###############################################################################
# F I R E W A L L O P T I O N S
###############################################################################
ACCOUNTING=Yes
ACCOUNTING_TABLE=filter
ADMINISABSENTMINDED=Yes
AUTOCOMMENT=Yes
AUTOHELPERS=Yes
AUTOMAKE=Yes
BALANCE_PROVIDERS=No
BASIC_FILTERS=No
BLACKLIST="NEW,INVALID,UNTRACKED"
CLAMPMSS=No
CLEAR_TC=No
COMPLETE=No
DEFER_DNS_RESOLUTION=Yes
DELETE_THEN_ADD=Yes
DONT_LOAD=
DYNAMIC_BLACKLIST=Yes
EXPAND_POLICIES=Yes
EXPORTMODULES=Yes
FASTACCEPT=No
FORWARD_CLEAR_MARK=Yes
HELPERS=
IGNOREUNKNOWNVARIABLES=No
IMPLICIT_CONTINUE=No
IPSET_WARNINGS=Yes
IP_FORWARDING=Keep
KEEP_RT_TABLES=Yes
MACLIST_TABLE=filter
MACLIST_TTL=
MANGLE_ENABLED=Yes
MARK_IN_FORWARD_CHAIN=No
MINIUPNPD=No
MUTEX_TIMEOUT=60
OPTIMIZE=All
OPTIMIZE_ACCOUNTING=No
PERL_HASH_SEED=0
REJECT_ACTION=
RENAME_COMBINED=Yes
REQUIRE_INTERFACE=No
RESTART=restart
RESTORE_DEFAULT_ROUTE=Yes
RESTORE_ROUTEMARKS=Yes
SAVE_IPSETS=No
TC_ENABLED=Shared
TC_EXPERT=No
TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2"
TRACK_PROVIDERS=Yes
TRACK_RULES=No
USE_DEFAULT_RT=Yes
USE_NFLOG_SIZE=No
USE_PHYSICAL_NAMES=No
USE_RT_NAMES=No
VERBOSE_MESSAGES=Yes
WARNOLDCAPVERSION=Yes
WORKAROUNDS=No
ZERO_MARKS=No
ZONE2ZONE=-
###############################################################################
# P A C K E T D I S P O S I T I O N
###############################################################################
BLACKLIST_DISPOSITION=DROP
INVALID_DISPOSITION=CONTINUE
MACLIST_DISPOSITION=REJECT
RELATED_DISPOSITION=ACCEPT
SFILTER_DISPOSITION=DROP
RPFILTER_DISPOSITION=DROP
SMURF_DISPOSITION=DROP
TCP_FLAGS_DISPOSITION=DROP
UNTRACKED_DISPOSITION=CONTINUE
################################################################################
# P A C K E T M A R K L A Y O U T
################################################################################
TC_BITS=
PROVIDER_BITS=
PROVIDER_OFFSET=
MASK_BITS=
ZONE_BITS=0
shorewall6-5.2.3.4/Samples6/one-interface/params 0000664 0000000 0000000 00000001444 13531060406 020071 0 ustar root root #
# Shorewall - Sample Params File for one-interface configuration.
# Copyright (C) 2006-2017 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------------------------------------
# For information on entries in this file, type "man shorewall-params"
######################################################################################################################################################################################################
shorewall6-5.2.3.4/Samples6/LICENSE 0000664 0000000 0000000 00000063465 13531060406 015164 0 ustar root root GNU LESSER GENERAL PUBLIC LICENSE
Version 2.1, February 1999
Copyright (C) 1991, 1999 Free Software Foundation, Inc.
51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
[This is the first released version of the Lesser GPL. It also counts
as the successor of the GNU Library Public License, version 2, hence
the version number 2.1.]
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
Licenses are intended to guarantee your freedom to share and change
free software--to make sure the software is free for all its users.
This license, the Lesser General Public License, applies to some
specially designated software packages--typically libraries--of the
Free Software Foundation and other authors who decide to use it. You
can use it too, but we suggest you first think carefully about whether
this license or the ordinary General Public License is the better
strategy to use in any particular case, based on the explanations below.
When we speak of free software, we are referring to freedom of use,
not price. Our General Public Licenses are designed to make sure that
you have the freedom to distribute copies of free software (and charge
for this service if you wish); that you receive source code or can get
it if you want it; that you can change the software and use pieces of
it in new free programs; and that you are informed that you can do
these things.
To protect your rights, we need to make restrictions that forbid
distributors to deny you these rights or to ask you to surrender these
rights. These restrictions translate to certain responsibilities for
you if you distribute copies of the library or if you modify it.
For example, if you distribute copies of the library, whether gratis
or for a fee, you must give the recipients all the rights that we gave
you. You must make sure that they, too, receive or can get the source
code. If you link other code with the library, you must provide
complete object files to the recipients, so that they can relink them
with the library after making changes to the library and recompiling
it. And you must show them these terms so they know their rights.
We protect your rights with a two-step method: (1) we copyright the
library, and (2) we offer you this license, which gives you legal
permission to copy, distribute and/or modify the library.
To protect each distributor, we want to make it very clear that
there is no warranty for the free library. Also, if the library is
modified by someone else and passed on, the recipients should know
that what they have is not the original version, so that the original
author's reputation will not be affected by problems that might be
introduced by others.
Finally, software patents pose a constant threat to the existence of
any free program. We wish to make sure that a company cannot
effectively restrict the users of a free program by obtaining a
restrictive license from a patent holder. Therefore, we insist that
any patent license obtained for a version of the library must be
consistent with the full freedom of use specified in this license.
Most GNU software, including some libraries, is covered by the
ordinary GNU General Public License. This license, the GNU Lesser
General Public License, applies to certain designated libraries, and
is quite different from the ordinary General Public License. We use
this license for certain libraries in order to permit linking those
libraries into non-free programs.
When a program is linked with a library, whether statically or using
a shared library, the combination of the two is legally speaking a
combined work, a derivative of the original library. The ordinary
General Public License therefore permits such linking only if the
entire combination fits its criteria of freedom. The Lesser General
Public License permits more lax criteria for linking other code with
the library.
We call this license the "Lesser" General Public License because it
does Less to protect the user's freedom than the ordinary General
Public License. It also provides other free software developers Less
of an advantage over competing non-free programs. These disadvantages
are the reason we use the ordinary General Public License for many
libraries. However, the Lesser license provides advantages in certain
special circumstances.
For example, on rare occasions, there may be a special need to
encourage the widest possible use of a certain library, so that it becomes
a de-facto standard. To achieve this, non-free programs must be
allowed to use the library. A more frequent case is that a free
library does the same job as widely used non-free libraries. In this
case, there is little to gain by limiting the free library to free
software only, so we use the Lesser General Public License.
In other cases, permission to use a particular library in non-free
programs enables a greater number of people to use a large body of
free software. For example, permission to use the GNU C Library in
non-free programs enables many more people to use the whole GNU
operating system, as well as its variant, the GNU/Linux operating
system.
Although the Lesser General Public License is Less protective of the
users' freedom, it does ensure that the user of a program that is
linked with the Library has the freedom and the wherewithal to run
that program using a modified version of the Library.
The precise terms and conditions for copying, distribution and
modification follow. Pay close attention to the difference between a
"work based on the library" and a "work that uses the library". The
former contains code derived from the library, whereas the latter must
be combined with the library in order to run.
GNU LESSER GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License Agreement applies to any software library or other
program which contains a notice placed by the copyright holder or
other authorized party saying it may be distributed under the terms of
this Lesser General Public License (also called "this License").
Each licensee is addressed as "you".
A "library" means a collection of software functions and/or data
prepared so as to be conveniently linked with application programs
(which use some of those functions and data) to form executables.
The "Library", below, refers to any such software library or work
which has been distributed under these terms. A "work based on the
Library" means either the Library or any derivative work under
copyright law: that is to say, a work containing the Library or a
portion of it, either verbatim or with modifications and/or translated
straightforwardly into another language. (Hereinafter, translation is
included without limitation in the term "modification".)
"Source code" for a work means the preferred form of the work for
making modifications to it. For a library, complete source code means
all the source code for all modules it contains, plus any associated
interface definition files, plus the scripts used to control compilation
and installation of the library.
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running a program using the Library is not restricted, and output from
such a program is covered only if its contents constitute a work based
on the Library (independent of the use of the Library in a tool for
writing it). Whether that is true depends on what the Library does
and what the program that uses the Library does.
1. You may copy and distribute verbatim copies of the Library's
complete source code as you receive it, in any medium, provided that
you conspicuously and appropriately publish on each copy an
appropriate copyright notice and disclaimer of warranty; keep intact
all the notices that refer to this License and to the absence of any
warranty; and distribute a copy of this License along with the
Library.
You may charge a fee for the physical act of transferring a copy,
and you may at your option offer warranty protection in exchange for a
fee.
2. You may modify your copy or copies of the Library or any portion
of it, thus forming a work based on the Library, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) The modified work must itself be a software library.
b) You must cause the files modified to carry prominent notices
stating that you changed the files and the date of any change.
c) You must cause the whole of the work to be licensed at no
charge to all third parties under the terms of this License.
d) If a facility in the modified Library refers to a function or a
table of data to be supplied by an application program that uses
the facility, other than as an argument passed when the facility
is invoked, then you must make a good faith effort to ensure that,
in the event an application does not supply such function or
table, the facility still operates, and performs whatever part of
its purpose remains meaningful.
(For example, a function in a library to compute square roots has
a purpose that is entirely well-defined independent of the
application. Therefore, Subsection 2d requires that any
application-supplied function or table used by this function must
be optional: if the application does not supply it, the square
root function must still compute square roots.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Library,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Library, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote
it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Library.
In addition, mere aggregation of another work not based on the Library
with the Library (or with a work based on the Library) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may opt to apply the terms of the ordinary GNU General Public
License instead of this License to a given copy of the Library. To do
this, you must alter all the notices that refer to this License, so
that they refer to the ordinary GNU General Public License, version 2,
instead of to this License. (If a newer version than version 2 of the
ordinary GNU General Public License has appeared, then you can specify
that version instead if you wish.) Do not make any other change in
these notices.
Once this change is made in a given copy, it is irreversible for
that copy, so the ordinary GNU General Public License applies to all
subsequent copies and derivative works made from that copy.
This option is useful when you wish to copy part of the code of
the Library into a program that is not a library.
4. You may copy and distribute the Library (or a portion or
derivative of it, under Section 2) in object code or executable form
under the terms of Sections 1 and 2 above provided that you accompany
it with the complete corresponding machine-readable source code, which
must be distributed under the terms of Sections 1 and 2 above on a
medium customarily used for software interchange.
If distribution of object code is made by offering access to copy
from a designated place, then offering equivalent access to copy the
source code from the same place satisfies the requirement to
distribute the source code, even though third parties are not
compelled to copy the source along with the object code.
5. A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled or
linked with it, is called a "work that uses the Library". Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.
However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.
When a "work that uses the Library" uses material from a header file
that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not.
Whether this is true is especially significant if the work can be
linked without the Library, or if the work is itself a library. The
threshold for this to be true is not precisely defined by law.
If such an object file uses only numerical parameters, data
structure layouts and accessors, and small macros and small inline
functions (ten lines or less in length), then the use of the object
file is unrestricted, regardless of whether it is legally a derivative
work. (Executables containing this object code plus portions of the
Library will still fall under Section 6.)
Otherwise, if the work is a derivative of the Library, you may
distribute the object code for the work under the terms of Section 6.
Any executables containing that work also fall under Section 6,
whether or not they are linked directly with the Library itself.
6. As an exception to the Sections above, you may also combine or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications.
You must give prominent notice with each copy of the work that the
Library is used in it and that the Library and its use are covered by
this License. You must supply a copy of this License. If the work
during execution displays copyright notices, you must include the
copyright notice for the Library among them, as well as a reference
directing the user to the copy of this License. Also, you must do one
of these things:
a) Accompany the work with the complete corresponding
machine-readable source code for the Library including whatever
changes were used in the work (which must be distributed under
Sections 1 and 2 above); and, if the work is an executable linked
with the Library, with the complete machine-readable "work that
uses the Library", as object code and/or source code, so that the
user can modify the Library and then relink to produce a modified
executable containing the modified Library. (It is understood
that the user who changes the contents of definitions files in the
Library will not necessarily be able to recompile the application
to use the modified definitions.)
b) Use a suitable shared library mechanism for linking with the
Library. A suitable mechanism is one that (1) uses at run time a
copy of the library already present on the user's computer system,
rather than copying library functions into the executable, and (2)
will operate properly with a modified version of the library, if
the user installs one, as long as the modified version is
interface-compatible with the version that the work was made with.
c) Accompany the work with a written offer, valid for at
least three years, to give the same user the materials
specified in Subsection 6a, above, for a charge no more
than the cost of performing this distribution.
d) If distribution of the work is made by offering access to copy
from a designated place, offer equivalent access to copy the above
specified materials from the same place.
e) Verify that the user has already received a copy of these
materials or that you have already sent this user a copy.
For an executable, the required form of the "work that uses the
Library" must include any data and utility programs needed for
reproducing the executable from it. However, as a special exception,
the materials to be distributed need not include anything that is
normally distributed (in either source or binary form) with the major
components (compiler, kernel, and so on) of the operating system on
which the executable runs, unless that component itself accompanies
the executable.
It may happen that this requirement contradicts the license
restrictions of other proprietary libraries that do not normally
accompany the operating system. Such a contradiction means you cannot
use both them and the Library together in an executable that you
distribute.
7. You may place library facilities that are a work based on the
Library side-by-side in a single library together with other library
facilities not covered by this License, and distribute such a combined
library, provided that the separate distribution of the work based on
the Library and of the other library facilities is otherwise
permitted, and provided that you do these two things:
a) Accompany the combined library with a copy of the same work
based on the Library, uncombined with any other library
facilities. This must be distributed under the terms of the
Sections above.
b) Give prominent notice with the combined library of the fact
that part of it is a work based on the Library, and explaining
where to find the accompanying uncombined form of the same work.
8. You may not copy, modify, sublicense, link with, or distribute
the Library except as expressly provided under this License. Any
attempt otherwise to copy, modify, sublicense, link with, or
distribute the Library is void, and will automatically terminate your
rights under this License. However, parties who have received copies,
or rights, from you under this License will not have their licenses
terminated so long as such parties remain in full compliance.
9. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Library or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Library (or any work based on the
Library), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Library or works based on it.
10. Each time you redistribute the Library (or any work based on the
Library), the recipient automatically receives a license from the
original licensor to copy, distribute, link with or modify the Library
subject to these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties with
this License.
11. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Library at all. For example, if a patent
license would not permit royalty-free redistribution of the Library by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Library.
If any portion of this section is held invalid or unenforceable under any
particular circumstance, the balance of the section is intended to apply,
and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
12. If the distribution and/or use of the Library is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Library under this License may add
an explicit geographical distribution limitation excluding those countries,
so that distribution is permitted only in or among countries not thus
excluded. In such case, this License incorporates the limitation as if
written in the body of this License.
13. The Free Software Foundation may publish revised and/or new
versions of the Lesser General Public License from time to time.
Such new versions will be similar in spirit to the present version,
but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Library
specifies a version number of this License which applies to it and
"any later version", you have the option of following the terms and
conditions either of that version or of any later version published by
the Free Software Foundation. If the Library does not specify a
license version number, you may choose any version ever published by
the Free Software Foundation.
14. If you wish to incorporate parts of the Library into other free
programs whose distribution conditions are incompatible with these,
write to the author to ask for permission. For software which is
copyrighted by the Free Software Foundation, write to the Free
Software Foundation; we sometimes make exceptions for this. Our
decision will be guided by the two goals of preserving the free status
of all derivatives of our free software and of promoting the sharing
and reuse of software generally.
NO WARRANTY
15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY
KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME
THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY
AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU
FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF
SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Libraries
If you develop a new library, and you want it to be of the greatest
possible use to the public, we recommend making it free software that
everyone can redistribute and change. You can do so by permitting
redistribution under these terms (or, alternatively, under the terms of the
ordinary General Public License).
To apply these terms, attach the following notices to the library. It is
safest to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least the
"copyright" line and a pointer to where the full notice is found.
Copyright (C)
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
Also add information on how to contact you by electronic and paper mail.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the library, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the
library `Frob' (a library for tweaking knobs) written by James Random Hacker.
, 1 April 1990
Ty Coon, President of Vice
That's all there is to it!
shorewall6-5.2.3.4/changelog.txt 0000664 0000000 0000000 00000011765 13531077635 015165 0 ustar root root Changes in 5.2.3.4
1) Update release documents.
2) Correct handling of multi-queue NFQUEUE as a policy.
3) Correct handling of multi-queue NFQUEUE as a macro parameter.
4) Make 'AUTOMAKE=No' the update default.
5) Correct the description of the 'bypass' NFQUEUE option in
shorewall-rules(5).
Changes in 5.2.3.3
1) Update release documents.
2) Document fix for an ipset in the SPORT column.
Changes in 5.2.3.2
1) Update release documents.
2) Document fix for masq file auto-update.
Changes in 5.2.3.1
1) Update release documents.
2) Correct issue with policy file zone exclusion.
Changes in 5.2.3 Final
1) Update release documents.
2) Correct problem corrected (mention helper).
Changes in 5.2.3 RC 1
1) Update release documents.
2) Delete pre-2.6.20 modules from the helpers file
3) Delete modules* during install
Changes in 5.2.3 Beta 2
1) Update release documents.
2) Remove LOAD_HELPERS_ONLY option.
Changes in 5.2.3 Beta 1
1) Update release documents.
2) Support zone exclusion in the policy file.
3) Deprecate all/any[+]-.
4) Document 'test' argument to compiler.pl
Changes in 5.2.2 Final
1) Update release documents.
2) Increase the 'wait' interface option setting limit.
2Changes in 5.2.2 RC 1
1) Update release documents.
2) Allow inline matches in the conntrack file.
3) Tighten check for early matches.
4) Support '+' in INLINE() accounting rules.
Changes in 5.2.2 Beta 2
1) Update release documents.
2) Add comments to the Provider, Zones and Misc Perl modules.
3) Add NetManager gateway detection.
Changes in 5.2.2 Beta 1
1) Update release documents.
2) New macros from Vincas Dargis.
3) Config.pm cleanup.
4) Deprecate ULOG.
Changes in 5.2.1.4
1) Update release documents.
2) Correct chain name in log messages out of RELATED chains.
3) Remove dead/silly code in Shorewall::Chains::use_input_chain() and
Shorewall::Chains::use_output_chain(). Combine the two into a
single function.
4) Correct handling of netmask in the RATE column when both a
source and dest rate are specified.
Changes in 5.2.1.3
1) Update release documents.
2) Make 'status -i' work correctly with optional interfaces and no
providers.
Changes in 5.2.1.2
1) Update release documents.
2) Fix an assertion failure during 'check -r' when DOCKER=Yes.
3) Implement SWCONFDIR upport.
4) Correct HELPER requires message.
5) Don't attempt to load ipt_ULOG.
Changes in 5.2.1.1
1) Update release documents.
2) Handle emacs issue with generated script.
3) Correct ip6tables-restore failure message.
4) Additional fix for 'linkdown' routes.
5) Accommodate Docker version 18.03.1-ce
Changes in 5.2.1 Final
1) Update release documents.
2) Add Eric Teeter's Cockpit macro.
3) Avoid bad code generation with using SNAT(detect).
Changes in 5.2.1 RC 1
1) Update release documents.
2) Apply rate limiting in the nat table rather than in the filter
table.
3) Apply fix for Perl 5.23.
Changes in 5.2.1 Beta 3
1) Update release documents.
2) Corrected broken links in manpages.
3) Corrected source interface exclusion.
4) Correct rate limiting.
5) Allow shared interfaces to work with statistical load balancing.
6) Disallow shared optional providers.
Changes in 5.2.1 Beta 2
1) Update release documents.
2) Correct typo ( 'fatal-error' => 'fatal_error' ).
3) Increase verbosity in 'remote-*' operations.
4) Update version in Shorewall-core to 5.2.
5) Allow specification of VLSM in the RATE columns.
6) Allow specification of hash-table buckets and max entries in RATE
column.
7) Correct typo in configuration-basics doc.
Changes in 5.2.1 Beta 1
1) Update release documents.
2) Add IPFS macros by Răzvan Sandu.
3) New manpages
4) Allow interface exclusion.
5) Allow marking in the NAT table.
6) Allow more mark/mask freedom with TC_EXPERT=Yes.
Changes in 5.2.0.1
1) Update release documents.
2) Merge IfEvent fix from 5.1.12.4.
3) remote_* changes.
4) Fix syntax error in the ipdecimal command.
Changes in 5.2.0 Final
1) Update release documents.
Changes in 5.2.0 RC 2
1) Update release documents.
2) Up the INCLUDE depth limit to 20.
3) Make &lo work correctly.
4) Drop support for the 'masq' file.
5) Implement getcaps, getrc, and 'show rc'.
Changes in 5.2.0 RC 1
1) Update release documents.
2) Allow AUTOMAKE=
Changes in 5.2.0 Beta 2
1) Update release documents.
2) Correct two-chain case with LOG_ZONE != 'Both'.
3) Implement RENAME_COMBINED.
4) Replace ${VARDIR}/firewall with $g_firewall throughout CLI.
5) Reverse the order of optimize 8 and optimize 16 application.
Changes in 5.2.0 Beta 1
1) Update release documents.
2) Remove the MAPOLDACTIONS option.
3) Remove INLINE_MATCHES.
4) Remove the 'refresh' command.
5) Remove deprecated actions and macros.
6) Update DROP_DEFAULT and REJECT_DEFAULT if Drop and Reject
respectively.
7) Convert ';' to ';;' in INLINE and IP[6]TABLES rules.
8) Add 'show saves' command.
9) Add shorewallrc.sandbox
10) Implement LOG_ZONE.
shorewall6-5.2.3.4/tunnel 0000775 0000000 0000000 00000010471 13531060406 013705 0 ustar root root #!/bin/sh
RCDLINKS="2,S45 3,S45 6,K45"
################################################################################
# Script to create a gre or ipip tunnel -- Shorewall 4
#
# Modified - Steve Cowles 5/9/2000
# Incorporated init {start|stop} syntax and iproute2 usage
#
# This program is under GPL [http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt]
#
# (c) 2000,2001,2002,2003,2004,2005 - Tom Eastep (teastep@shorewall.net)
#
# This program is part of Shorewall.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by the
# Free Software Foundation, either version 2 of the license or, at your
# option, any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, see ] [ ]"
echo "where is one of"
echo " -h"
echo " -v"
echo " -n"
exit $1
}
#
# Change to the directory containing this script
#
cd "$(dirname $0)"
if [ -f shorewall.service ]; then
PRODUCT=shorewall
Product=Shorewall
else
PRODUCT=shorewall6
Product=Shorewall6
fi
#
# Source common functions
#
. ./lib.uninstaller || { echo "ERROR: Can not load common functions." >&2; exit 1; }
#
# Parse the run line
#
finished=0
configure=1
while [ $finished -eq 0 ]; do
option=$1
case "$option" in
-*)
option=${option#-}
while [ -n "$option" ]; do
case $option in
h)
usage 0
;;
v)
echo "$Product Firewall Uninstaller Version $VERSION"
exit 0
;;
n*)
configure=0
option=${option#n}
;;
*)
usage 1
;;
esac
done
shift
;;
*)
finished=1
;;
esac
done
#
# Read the RC file
#
if [ $# -eq 0 ]; then
if [ -f ./shorewallrc ]; then
. ./shorewallrc || fatal_error "Can not load the RC file: ./shorewallrc"
elif [ -f ~/.shorewallrc ]; then
. ~/.shorewallrc || fatal_error "Can not load the RC file: ~/.shorewallrc"
elif [ -f /usr/share/shorewall/shorewallrc ]; then
. /usr/share/shorewall/shorewallrc || fatal_error "Can not load the RC file: /usr/share/shorewall/shorewallrc"
else
fatal_error "No configuration file specified and /usr/share/shorewall/shorewallrc not found"
fi
elif [ $# -eq 1 ]; then
file=$1
case $file in
/*|.*)
;;
*)
file=./$file || exit 1
;;
esac
. $file || fatal_error "Can not load the RC file: $file"
else
usage 1
fi
if [ -f ${SHAREDIR}/$PRODUCT/version ]; then
INSTALLED_VERSION="$(cat ${SHAREDIR}/$PRODUCT/version)"
if [ "$INSTALLED_VERSION" != "$VERSION" ]; then
echo "WARNING: $Product Version $INSTALLED_VERSION is installed"
echo " and this is the $VERSION uninstaller."
VERSION="$INSTALLED_VERSION"
fi
else
echo "WARNING: $Product Version $VERSION is not installed"
VERSION=""
fi
echo "Uninstalling $Product $VERSION"
[ -n "$SANDBOX" ] && configure=0
if [ $configure -eq 1 ]; then
if qt iptables -L shorewall -n && [ ! -f ${SBINDIR}/shorewall-lite ]; then
${SBINDIR}/$PRODUCT clear
elif qt ip6tables -L shorewall6 -n && [ ! -f ${SBINDIR}/shorewall6-lite ]; then
${SBINDIR}/$PRODUCT clear
fi
fi
remove_file ${SBINDIR}/$PRODUCT
if [ -h ${SHAREDIR}/$PRODUCT/init ]; then
FIREWALL=$(readlink -m -q ${SHAREDIR}/$PRODUCT/init)
elif [ -n "$INITFILE" ]; then
FIREWALL=${INITDIR}/${INITFILE}
fi
if [ -f "$FIREWALL" ]; then
if [ $configure -eq 1 ]; then
if mywhich insserv ; then
insserv -r $FIREWALL
elif mywhich update-rc.d ; then
update-rc.d ${PRODUCT} remove
elif mywhich chkconfig ; then
chkconfig --del $(basename $FIREWALL)
fi
fi
remove_file $FIREWALL
fi
[ -z "${SERVICEDIR}" ] && SERVICEDIR="$SYSTEMD"
if [ -n "$SERVICEDIR" ]; then
[ $configure -eq 1 ] && systemctl disable ${PRODUCT}.service
remove_file $SERVICEDIR/${PRODUCT}.service
fi
remove_file ${SHAREDIR}/$PRODUCT/version
remove_directory ${CONFDIR}/$PRODUCT
if [ -n "$SYSCONFDIR" ]; then
[ -n "$SYSCONFFILE" ] && remove_file ${SYSCONFDIR}/${PRODUCT}
fi
remove_directory ${VARDIR}
[ ${LIBEXECDIR} = ${SHAREDIR} ] || remove_directory ${LIBEXECDIR}/$PRODUCT
remove_directory ${SHAREDIR}/$PRODUCT/configfiles
remove_file_with_wildcard ${SHAREDIR}/$PRODUCT/module\*
remove_file ${SHAREDIR}/$PRODUCT/helpers
remove_file_with_wildcard ${SHAREDIR}/$PRODUCT/action\*
remove_file_with_wildcard ${SHAREDIR}/$PRODUCT/macro.\*
if [ $PRODUCT = shorewall ]; then
remove_file_with_wildcard ${PERLLIBDIR}/$Product/\*
remove_directory ${SHAREDIR}/$PRODUCT/Samples
remove_directory ${SHAREDIR}/$PRODUCT/$Product
remove_file ${SHAREDIR}/$PRODUCT/lib.cli-std
remove_file ${SHAREDIR}/$PRODUCT/lib.runtime
remove_file ${SHAREDIR}/$PRODUCT/compiler.pl
remove_file_with_wildcard ${SHAREDIR}/$PRODUCT/prog.\*
remove_file ${SHAREDIR}/$PRODUCT/init
else
remove_directory ${SHAREDIR}/$PRODUCT
fi
for f in ${MANDIR}/man5/${PRODUCT}* ${MANDIR}/man8/${PRODUCT}*; do
case $f in
shorewall[6]-lite*)
;;
*)
remove_file $f
;;
esac
done
remove_file ${CONFDIR}/logrotate.d/$PRODUCT
[ -n "$SYSTEMD" ] && remove_file ${SYSTEMD}/${PRODUCT}.service
#
# Report Success
#
echo "$Product $VERSION Uninstalled"
shorewall6-5.2.3.4/init.slackware.shorewall6.sh 0000775 0000000 0000000 00000002051 13531060406 020007 0 ustar root root #!/bin/sh
#
# /etc/rc.d/rc.shorewall6: start/stop/restart IPv6 rules of Shorewall
#
# This should be started from rc.firewall.
# This script only affect the IPv6 rules and configuration located
# in /etc/shorewall6
#
# http://rafb.net/p/1gsyye11.html
OPTIONS=""
# Use /etc/default shorewall6 to specify $OPTIONS and STARTOPTIONS to
# run at startup, however this this might prevent shorewall6 from
# starting. use at your own risk
if [ -f /etc/default/shorewall6 ] ; then
. /etc/default/shorewall6
fi
start() {
echo "Starting IPv6 shorewall rules..."
exec /sbin/shorewall -6 $OPTIONS start $STARTOPTIONS
}
stop() {
echo "Stopping IPv6 shorewall rules..."
exec /sbin/shorewall -6 stop
}
restart() {
echo "Restarting IPv6 shorewall rules..."
exec /sbin/shorewall -6 restart $RESTARTOPTIONS
}
status() {
exec /sbin/shorewall -6 status
}
case "$1" in
'start')
start
;;
'stop')
stop
;;
'reload'|'restart')
restart
;;
'status')
status
;;
*)
echo "Usage: $0 start|stop|reload|restart|status"
;;
esac
exit 0
# All done
shorewall6-5.2.3.4/shorewallrc.alt 0000664 0000000 0000000 00000004026 13531077635 015514 0 ustar root root #
# ALT/BaseALT/ALTLinux Shorewall 5.2 rc file
#
BUILD= #Default is to detect the build system
HOST=alt
PREFIX=/usr #Top-level directory for shared files, libraries, etc.
SHAREDIR=${PREFIX}/share #Directory for arch-neutral files.
LIBEXECDIR=${PREFIX}/libexec #Directory for executable scripts.
PERLLIBDIR=${SHAREDIR}/perl5 #Directory to install Shorewall Perl module directory
CONFDIR=/etc #Directory where subsystem configurations are installed
SBINDIR=/sbin #Directory where system administration programs are installed
MANDIR=${SHAREDIR}/man #Directory where manpages are installed.
INITDIR=${CONFDIR}/rc.d/init.d #Directory where SysV init scripts are installed.
INITFILE=$PRODUCT #Name of the product's installed SysV init script
INITSOURCE=init.alt.sh #Name of the distributed file to be installed as the SysV init script
ANNOTATED= #If non-zero, annotated configuration files are installed
SERVICEDIR=/lib/systemd/system #Directory where .service files are installed (systems running systemd only)
SYSCONFFILE=sysconfig #Name of the distributed file to be installed as $SYSCONFDIR/$PRODUCT
SERVICEFILE= #Name of the file to install in $SYSTEMD. Default is $PRODUCT.service
SYSCONFDIR=/etc/sysconfig/ #Directory where SysV init parameter files are installed
SERVICEDIR=/lib/systemd/system #Directory where .service files are installed (systems running systemd only)
SPARSE= #If non-empty, only install $PRODUCT/$PRODUCT.conf in $CONFDIR
VARLIB=/var/lib #Directory where product variable data is stored.
VARDIR=${VARLIB}/$PRODUCT #Directory where product variable data is stored.
DEFAULT_PAGER=/usr/bin/less #Pager to use if none specified in shorewall[6].conf
shorewall6-5.2.3.4/default.debian.sysvinit 0000664 0000000 0000000 00000001774 13531060406 017137 0 ustar root root # prevent startup with default configuration
# set the following variable to 1 in order to allow Shorewall6 to start
startup=0
# if your Shorewall6 configuration requires detection of the ip address of a
# ppp interface, you must list such interfaces in "wait_interface" to get
# Shorewall6 to wait until the interface is configured. Otherwise the script
# will fail because it won't be able to detect the IP address.
#
# Example:
# wait_interface="ppp0"
# or
# wait_interface="ppp0 ppp1"
# or, if you have defined in /etc/shorewall6/params
# wait_interface=
#
# Global start/restart/reload/stop options
#
OPTIONS=""
#
# Start options
#
STARTOPTIONS=""
#
# Restart options
#
RESTARTOPTIONS=""
#
# Reload options
#
RELOADOPTIONS=""
#
# Stop options
#
STOPOPTIONS=""
#
# Init Log -- if /dev/null, use the STARTUP_LOG defined in shorewall.conf
#
INITLOG=/dev/null
#
# Set this to 1 to cause '/etc/init.d/shorewall6 stop' to place the firewall in
# a safe state rather than to open it
#
SAFESTOP=0
# EOF
shorewall6-5.2.3.4/shorewallrc.cygwin 0000664 0000000 0000000 00000002374 13531077635 016240 0 ustar root root #
# Cygwin Shorewall 5.2 rc file
#
BUILD=cygwin
HOST=cygwin
PREFIX=/usr #Top-level directory for shared files, libraries, etc.
SHAREDIR=${PREFIX}/share #Directory for arch-neutral files.
LIBEXECDIR=${PREFIX}/share #Directory for executable scripts.
PERLLIBDIR=${PREFIX}/share/shorewall #Directory to install Shorewall Perl module directory
CONFDIR=/etc #Directory where subsystem configurations are installed
SBINDIR=/bin #Directory where system administration programs are installed
MANDIR=${SHAREDIR}/man #Directory where manpages are installed.
INITDIR=/etc/init.d #Unused on Cygwin
INITFILE= #Unused on Cygwin
INITSOURCE= #Unused on Cygwin
ANNOTATED= #Unused on Cygwin
SERVICEDIR= #Unused on Cygwin
SERVICEFILE= #Unused on Cygwin
SYSCONFDIR= #Unused on Cygwin
SPARSE=Yes #Only install $PRODUCT/$PRODUCT.conf in $CONFDIR.
VARLIB=/var/lib #Unused on Cygwin
DEFAULT_PAGER= #Pager to use if none specified in shorewall[6].conf
shorewall6-5.2.3.4/shorewallrc.slackware 0000664 0000000 0000000 00000003766 13531077635 016722 0 ustar root root #
# Slackware Shorewall 5.2 rc file
#
BUILD=slackware
HOST=slackware
PREFIX=/usr #Top-level directory for shared files, libraries, etc.
SHAREDIR=${PREFIX}/share #Directory for arch-neutral files.
LIBEXECDIR=${PREFIX}/share #Directory for executable scripts.
PERLLIBDIR=${PREFIX}/share/shorewall #Directory to install Shorewall Perl module directory
CONFDIR=/etc #Directory where subsystem configurations are installed
SBINDIR=/sbin #Directory where system administration programs are installed
MANDIR=${PREFIX}/man #Directory where manpages are installed.
INITDIR=/etc/rc.d #Directory where SysV init scripts are installed.
AUXINITSOURCE=init.slackware.firewall.sh #Name of the distributed file to be installed as the SysV init script
AUXINITFILE=rc.firewall #Name of the product's installed SysV init script
INITSOURCE=init.slackware.$PRODUCT.sh #Name of the distributed file to be installed as a second SysV init script
INITFILE=rc.$PRODUCT #Name of the product's installed second init script
SERVICEDIR= #Name of the directory where .service files are installed (systems running systemd only)
SERVICEFILE= #Name of the file to install in $SYSTEMD. Default is $PRODUCT.service
SYSCONFFILE= #Name of the distributed file to be installed in $SYSCONFDIR
SYSCONFDIR= #Name of the directory where SysV init parameter files are installed.
ANNOTATED= #If non-empty, install annotated configuration files
VARLIB=/var/lib #Directory where product variable data is stored.
VARDIR=${VARLIB}/$PRODUCT #Directory where product variable data is stored.
DEFAULT_PAGER= #Pager to use if none specified in shorewall[6].conf
shorewall6-5.2.3.4/shorewall6.spec 0000664 0000000 0000000 00000034777 13531077635 015447 0 ustar root root %define name shorewall6
%define version 5.2.3
%define release 4
Summary: Shoreline Firewall 6 is an ip6tables-based firewall for Linux systems.
Name: %{name}
Version: %{version}
Release: %{release}
License: GPLv2
Packager: Tom Eastep
Group: Networking/Utilities
Source: %{name}-%{version}.tgz
URL: http://www.shorewall.org/
BuildArch: noarch
BuildRoot: %{_tmppath}/%{name}-%{version}-root
Requires: iptables iproute shorewall >= 4.5.0-0
Provides: shoreline_firewall = %{version}-%{release}
%description
The Shoreline Firewall 6, more commonly known as "Shorewall6", is a Netfilter
(ip6tables) based IPv6 firewall that can be used on a dedicated firewall system,
a multi-function gateway/ router/server or on a standalone GNU/Linux system.
%prep
%setup
%build
%install
./configure.pl --host=%{_vendor} \
--prefix=%{_prefix} \
--tmpdir=%{_tmpdir} \
--perllibdir=%{perl_vendorlib} \
--libexecdir=%{_libexecdir} \
--sbindir=%{_sbindir}
DESTDIR=%{buildroot} ./install.sh
touch %{buildroot}/etc/shorewall6/isusable
touch %{buildroot}/etc/shorewall6/notrack
%clean
rm -rf $RPM_BUILD_ROOT
%post
if [ $1 -eq 1 ]; then
if [ -x %{_sbindir}/systemctl ]; then
%{_sbindir}/systemctl enable shorewall6
elif [ -x /usr/bin/systemctl ]; then
/usr/bin/systemctl enable shorewall6
elif [ -x %{_sbindir}/insserv ]; then
%{_sbindir}/insserv /etc/rc.d/shorewall6
elif [ -x %{_sbindir}/chkconfig ]; then
%{_sbindir}/chkconfig --add shorewall6;
fi
fi
%preun
if [ $1 = 0 ]; then
if [ -x %{_sbindir}/systemctl ]; then
%{_sbindir}/systemctl disable shorewall6
elif [ -x /usr/bin/systemctl ]; then
/usr/bin/systemctl disable shorewall6
elif [ -x %{_sbindir}/insserv ]; then
%{_sbindir}/insserv -r %{_initddir}/shorewall6
elif [ -x %{_sbindir}/chkconfig ]; then
%{_sbindir}/chkconfig --del shorewall6
fi
rm -f /etc/shorewall/startup_disabled
fi
%files
%defattr(0644,root,root,0755)
%attr(0644,root,root) /usr/lib/systemd/system/shorewall6.service
%attr(0755,root,root) %dir /etc/shorewall6
%ghost %(attr 0644,root,root) /etc/shorewall6/isusable
%ghost %(attr 0644,root,root) /etc/shorewall6/masq
%attr(0755,root,root) %dir /usr/share/shorewall6
%attr(0755,root,root) %dir /usr/share/shorewall6/configfiles
%attr(0755,root,root) %dir /usr/share/shorewall6/deprecated
%attr(0700,root,root) %dir /var/lib/shorewall6
%attr(0600,root,root) %config(noreplace) /etc/shorewall6/*
%attr(0755,root,root) %dir /etc/sysconfig/
%attr(0600,root,root) %config(noreplace) /etc/sysconfig/shorewall6
%attr(0644,root,root) /etc/logrotate.d/shorewall6
%attr(- ,root,root) %{_sbindir}/shorewall6
%attr(0644,root,root) /usr/share/shorewall6/version
%attr(0644,root,root) /usr/share/shorewall6/actions.std
%attr(0644,root,root) /usr/share/shorewall6/action.mangletemplate
%attr(0644,root,root) /usr/share/shorewall6/action.template
%attr(- ,root,root) /usr/share/shorewall6/functions
%attr(0644,root,root) /usr/share/shorewall6/lib.base
%attr(0644,root,root) /usr/share/shorewall6/macro.*
%attr(0644,root,root) /usr/share/shorewall6/helpers
%attr(0644,root,root) /usr/share/shorewall6/configpath
%attr(0644,root,root) /usr/share/shorewall6/configfiles/*
%attr(0644,root,root) %{_mandir}/man5/*
%attr(0644,root,root) %{_mandir}/man8/*
%doc COPYING INSTALL changelog.txt releasenotes.txt tunnel ipsecvpn ipv6 Samples6
%changelog
* Sun Aug 25 2019 Tom Eastep
- Updated to 5.2.3-4
* Thu Apr 11 2019 Tom Eastep tom@shorewall.net
- Updated to 5.2.3-3
* Sun Mar 17 2019 Tom Eastep tom@shorewall.net
- Updated to 5.2.3-2
* Tue Feb 26 2019 Tom Eastep tom@shorewall.net
- Updated to 5.2.3-1
* Mon Feb 11 2019 Tom Eastep tom@shorewall.net
- Updated to 5.2.3-0base
* Wed Feb 06 2019 Tom Eastep tom@shorewall.net
- Updated to 5.2.3-0RC1
* Sun Feb 03 2019 Tom Eastep tom@shorewall.net
- Updated to 5.2.3-0Beta2
* Tue Jan 22 2019 Tom Eastep tom@shorewall.net
- Updated to 5.2.3-0Beta1
* Wed Jan 16 2019 Tom Eastep tom@shorewall.net
- Updated to 5.2.2-0base
* Tue Jan 08 2019 Tom Eastep tom@shorewall.net
- Updated to 5.2.2-0RC1
* Fri Jan 04 2019 Tom Eastep tom@shorewall.net
- Updated to 5.2.2-0Beta2
* Tue Oct 02 2018 Tom Eastep tom@shorewall.net
- Updated to 5.2.2-0Beta1
* Fri Sep 28 2018 Tom Eastep tom@shorewall.net
- Updated to 5.2.1-0base
* Thu Aug 23 2018 Tom Eastep tom@shorewall.net
- Updated to 5.2.1-0RC1
* Tue Jul 03 2018 Tom Eastep tom@shorewall.net
- Updated to 5.2.1-0Beta3
* Mon Jul 02 2018 Tom Eastep tom@shorewall.net
- Updated to 5.2.1-0Beta2
* Sat Apr 21 2018 Tom Eastep tom@shorewall.net
- Updated to 5.2.1-0Beta1
* Wed Apr 11 2018 Tom Eastep tom@shorewall.net
- Updated to 5.2.0-1
* Wed Mar 28 2018 Tom Eastep tom@shorewall.net
- Updated to 5.2.0-0base
* Mon Mar 26 2018 Tom Eastep tom@shorewall.net
- Updated to 5.2.0-0RC2
* Tue Feb 27 2018 Tom Eastep tom@shorewall.net
- Updated to 5.2.0-0RC1
* Wed Feb 21 2018 Tom Eastep tom@shorewall.net
- Updated to 5.2.0-0Beta2
* Wed Jan 24 2018 Tom Eastep tom@shorewall.net
- Updated to 5.2.0-0Beta1
* Tue Jan 23 2018 Tom Eastep tom@shorewall.net
- Updated to 5.1.12-0Beta2
* Wed Jan 17 2018 Tom Eastep tom@shorewall.net
- Updated to 5.1.12-0Beta1
* Wed Jan 10 2018 Tom Eastep tom@shorewall.net
- Updated to 5.1.11-0base
* Fri Jan 05 2018 Tom Eastep tom@shorewall.net
- Updated to 5.1.11-0RC1
* Sun Dec 31 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.11-0Beta2
* Tue Dec 26 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.11-0Beta1
* Sat Dec 23 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.10-0base
* Mon Dec 18 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.10-0RC2
* Sat Dec 09 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.10-0RC1
* Fri Dec 01 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.10-0Beta2
* Wed Nov 22 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.10-0Beta1
* Wed Nov 15 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.9-0base
* Sat Nov 11 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.9-0RC1
* Fri Nov 03 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.9-0Beta2
* Thu Oct 19 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.9-0Beta1
* Sun Oct 15 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.8-0base
* Tue Oct 10 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.8-0RC1
* Sat Oct 07 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.8-0Beta2
* Mon Sep 18 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.8-0Beta1
* Mon Sep 18 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.7-0base
* Sun Sep 17 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.7-0RC2
* Fri Sep 01 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.7-0RC1
* Wed Aug 23 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.7-0Beta2
* Tue Aug 22 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.7-0Beta1
* Wed Aug 16 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.6-0base
* Tue Aug 15 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.6-0RC2
* Tue Aug 15 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.6-0RC1
* Wed Aug 09 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.6-0RC1
* Thu Aug 03 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.6-0Beta2
* Thu Jul 20 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.6-0Beta1
* Mon Jun 26 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.5-0base
* Wed Jun 21 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.5-0RC1
* Fri Jun 16 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.5-0Beta2
* Thu May 11 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.5-0Beta1
* Fri May 05 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.4-0base
* Mon Apr 24 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.4-0RC1
* Fri Mar 24 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.4-0Beta2
* Mon Mar 13 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.4-0Beta1
* Mon Mar 13 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.3-0base
* Sun Mar 12 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.3-0RC2
* Fri Mar 10 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.3-0RC1
* Mon Mar 06 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.3-0Beta2
* Wed Feb 22 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.3-0Beta1
* Fri Feb 17 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.2-0RC1
* Fri Feb 10 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.2-0Beta2
* Wed Jan 25 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.2-0Beta1
* Tue Jan 24 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.1-0base
* Thu Jan 19 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.1-0RC1
* Tue Jan 17 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.1-0Beta2
* Wed Jan 11 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.1-0Beta1
* Tue Jan 10 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.0-1
* Wed Jan 04 2017 Tom Eastep tom@shorewall.net
- Updated to 5.1.0-0base
* Wed Dec 28 2016 Tom Eastep tom@shorewall.net
- Updated to 5.1.0-0RC2
* Tue Dec 20 2016 Tom Eastep tom@shorewall.net
- Updated to 5.1.0-0RC1
* Mon Dec 12 2016 Tom Eastep tom@shorewall.net
- Updated to 5.1.0-0Beta2
* Sun Dec 04 2016 Tom Eastep tom@shorewall.net
- Updated to 5.1.0-0Beta1
* Fri Dec 02 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.15-0base
* Thu Dec 01 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.15-0RC2
* Sun Nov 27 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.15-0RC1
* Thu Nov 17 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.15-0Beta2
* Sun Nov 06 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.15-0Beta1
* Mon Oct 31 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.14-0RC3
* Sat Oct 29 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.14-0RC2
* Thu Oct 27 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.14-0RC1
* Tue Oct 25 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.14-0Beta2
* Sun Oct 16 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.14-0Beta1
* Sun Oct 16 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.13-0base
* Sun Oct 16 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.13-0RC2
* Sun Oct 09 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.13-0RC1
* Tue Oct 04 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.13-0Beta2
* Sun Oct 02 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.13-0Beta1
* Sat Oct 01 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.12-0base
* Sat Oct 01 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.12-0RC3
* Tue Sep 27 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.12-0RC2
* Tue Sep 20 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.12-0RC1
* Tue Sep 13 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.12-0Beta2
* Sat Aug 13 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.12-0Beta1
* Sat Aug 06 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.11-0base
* Sat Jul 30 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.11-0RC1
* Wed Jul 27 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.11-0Beta2
* Tue Jul 19 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.11-0Beta1
* Fri Jul 08 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.10-1
* Sat Jun 25 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.10-0base
* Tue Jun 21 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.10-0RC1
* Tue Jun 14 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.10-0Beta2
* Mon Jun 06 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.10-0Beta1
* Thu May 12 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.9-0base
* Thu May 05 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.9-0RC1
* Thu Apr 28 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.9-0Beta2
* Mon Apr 18 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.9-0Beta1
* Fri Apr 15 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.8-0RC2
* Mon Apr 11 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.8-0RC1
* Thu Apr 07 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.8-0Beta4
* Sat Apr 02 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.8-0Beta3
* Fri Apr 01 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.8-0Beta2
* Sun Mar 27 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.8-0Beta1
* Thu Mar 24 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.7-0base
* Fri Mar 18 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.7-0RC1
* Sun Mar 13 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.7-0Beta4
* Sun Mar 13 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.7-0Beta3
* Tue Mar 08 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.7-0Beta2
* Sat Mar 05 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.7-0Beta1
* Fri Mar 04 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.6-0Beta6
* Fri Mar 04 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.6-0Beta5
* Thu Mar 03 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.6-0Beta4
- Updated to 5.0.6-0RC1
* Sat Feb 27 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.6-0Beta3
* Sun Feb 21 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.6-0Beta2
* Fri Feb 19 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.6-0Beta1
* Wed Feb 17 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.5-0base
* Mon Feb 15 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.5-0RC2
* Wed Feb 03 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.5-0RC1
* Fri Jan 29 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.5-0Beta2
* Wed Jan 20 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.5-0Beta1
* Wed Jan 20 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.4-0base
* Tue Jan 19 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.4-0RC2
* Mon Jan 11 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.4-0RC1
* Tue Jan 05 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.4-0Beta2
* Sat Jan 02 2016 Tom Eastep tom@shorewall.net
- Updated to 5.0.4-0Beta1
* Sun Dec 27 2015 Tom Eastep tom@shorewall.net
- Updated to 5.0.3-0base
* Thu Dec 24 2015 Tom Eastep tom@shorewall.net
- Updated to 5.0.3-0RC2
* Sun Dec 13 2015 Tom Eastep tom@shorewall.net
- Updated to 5.0.3-0RC1
* Sat Dec 05 2015 Tom Eastep tom@shorewall.net
- Updated to 5.0.3-0Beta2
* Sat Nov 28 2015 Tom Eastep tom@shorewall.net
- Updated to 5.0.3-0Beta1
* Sat Nov 21 2015 Tom Eastep tom@shorewall.net
- Updated to 5.0.2-1
* Sat Nov 07 2015 Tom Eastep tom@shorewall.net
- Updated to 5.0.2-0base
* Sun Nov 01 2015 Tom Eastep tom@shorewall.net
- Updated to 5.0.2-0RC1
* Mon Oct 26 2015 Tom Eastep tom@shorewall.net
- Updated to 5.0.2-0Beta2
* Mon Oct 26 2015 Tom Eastep tom@shorewall.net
- Updated to 5.0.2-0Beta1
* Tue Oct 13 2015 Tom Eastep tom@shorewall.net
- Updated to 5.0.1-1
* Mon Oct 12 2015 Tom Eastep tom@shorewall.net
- Updated to 5.0.1-0base
* Sat Oct 03 2015 Tom Eastep tom@shorewall.net
- Updated to 5.0.0-0base
* Mon Sep 21 2015 Tom Eastep tom@shorewall.net
- Updated to 5.0.0-0RC1
* Thu Sep 10 2015 Tom Eastep tom@shorewall.net
- Updated to 5.0.0-0Beta2
* Mon Jul 27 2015 Tom Eastep tom@shorewall.net
- Updated to 5.0.0-0Beta1
shorewall6-5.2.3.4/shorewallrc.archlinux 0000664 0000000 0000000 00000003415 13531077635 016732 0 ustar root root #
# Arch Linux Shorewall 5.2 rc file
#
BUILD= #Default is to detect the build system
HOST=archlinux
PREFIX=/usr #Top-level directory for shared files, libraries, etc.
SHAREDIR=${PREFIX}/share #Directory for arch-neutral files.
LIBEXECDIR=${PREFIX}/share #Directory for executable scripts.
PERLLIBDIR=${PREFIX}/share/shorewall #Directory to install Shorewall Perl module directory
CONFDIR=/etc #Directory where subsystem configurations are installed
SBINDIR=/usr/bin #Directory where system administration programs are installed
MANDIR=${SHAREDIR}/man #Directory where manpages are installed.
INITDIR= #Directory where SysV init scripts are installed.
INITFILE= #Name of the product's installed SysV init script
INITSOURCE= #Name of the distributed file to be installed as the SysV init script
ANNOTATED= #If non-zero, annotated configuration files are installed
SYSCONFDIR= #Directory where SysV init parameter files are installed
SERVICEDIR=/usr/lib/systemd/system #Directory where .service files are installed (systems running systemd only)
SERVICEFILE= #Name of the file to install in $SYSTEMD. Default is $PRODUCT.service
SPARSE= #If non-empty, only install $PRODUCT/$PRODUCT.conf in $CONFDIR
VARLIB=/var/lib #Directory where product variable data is stored.
VARDIR=${VARLIB}/$PRODUCT #Directory where product variable data is stored.
DEFAULT_PAGER= #Pager to use if none specified in shorewall[6].conf
shorewall6-5.2.3.4/shorewallrc.redhat 0000664 0000000 0000000 00000003601 13531077635 016201 0 ustar root root #
# RedHat/FedoraShorewall 5.2 rc file
#
BUILD= #Default is to detect the build system
HOST=redhat
PREFIX=/usr #Top-level directory for shared files, libraries, etc.
SHAREDIR=${PREFIX}/share #Directory for arch-neutral files.
LIBEXECDIR=${PREFIX}/libexec #Directory for executable scripts.
PERLLIBDIR=/usr/share/perl5/vendor_perl #Directory to install Shorewall Perl module directory
CONFDIR=/etc #Directory where subsystem configurations are installed
SBINDIR=/sbin #Directory where system administration programs are installed
MANDIR=${SHAREDIR}/man #Directory where manpages are installed.
INITDIR=/etc/rc.d/init.d #Directory where SysV init scripts are installed.
INITFILE=$PRODUCT #Name of the product's installed SysV init script
INITSOURCE=init.fedora.sh #Name of the distributed file to be installed as the SysV init script
ANNOTATED= #If non-zero, annotated configuration files are installed
SERVICEDIR=/lib/systemd/system #Directory where .service files are installed (systems running systemd only)
SYSCONFFILE=sysconfig #Name of the distributed file to be installed as $SYSCONFDIR/$PRODUCT
SERVICEFILE= #Name of the file to install in $SYSTEMD. Default is $PRODUCT.service
SYSCONFDIR=/etc/sysconfig/ #Directory where SysV init parameter files are installed
SPARSE= #If non-empty, only install $PRODUCT/$PRODUCT.conf in $CONFDIR
VARLIB=/var/lib #Directory where product variable data is stored.
VARDIR=${VARLIB}/$PRODUCT #Directory where product variable data is stored.
DEFAULT_PAGER= #Pager to use if none specified in shorewall[6].conf
shorewall6-5.2.3.4/ipv6 0000775 0000000 0000000 00000011005 13531060406 013256 0 ustar root root #!/bin/sh
#
# (c) 1999,2000,2001,2002,2003,2004,2005,2014 - Tom Eastep (teastep@shorewall.net)
#
# On most distributions, this file should be called /etc/init.d/shorewall.
#
# Complete documentation is available at http://shorewall.net
#
# This program is part of Shorewall.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by the
# Free Software Foundation, either version 2 of the license or, at your
# option, any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, see ] [ ]"
echo "where is one of"
echo " -h"
echo " -v"
echo " -s"
echo " -a"
echo " -p"
echo " -n"
exit $1
}
run_install()
{
if ! install $*; then
echo
echo "ERROR: Failed to install $*" >&2
exit 1
fi
}
install_file() # $1 = source $2 = target $3 = mode
{
run_install $T $OWNERSHIP -m $3 $1 ${2}
}
#
# Change to the directory containing this script
#
cd "$(dirname $0)"
if [ -f shorewall.service ]; then
PRODUCT=shorewall
Product=Shorewall
else
PRODUCT=shorewall6
Product=Shorewall6
fi
#
# Source common functions
#
. ./lib.installer || { echo "ERROR: Can not load common functions." >&2; exit 1; }
#
# Parse the run line
#
#
T="-T"
INSTALLD='-D'
finished=0
configure=1
while [ $finished -eq 0 ]; do
option=$1
case "$option" in
-*)
option=${option#-}
while [ -n "$option" ]; do
case $option in
h)
usage 0
;;
v)
echo "$Product Firewall Installer Version $VERSION"
exit 0
;;
s*)
SPARSE=Yes
option=${option#s}
;;
a*)
ANNOTATED=Yes
option=${option#a}
;;
p*)
ANNOTATED=
option=${option#p}
;;
n*)
configure=0
option=${option#n}
;;
*)
usage 1
;;
esac
done
shift
;;
*)
finished=1
;;
esac
done
#
# Read the RC file
#
if [ $# -eq 0 ]; then
if [ -f ./shorewallrc ]; then
file=./shorewallrc
. $file || fatal_error "Can not load the RC file: $file"
elif [ -f ~/.shorewallrc ]; then
file=~/.shorewallrc
. $file || fatal_error "Can not load the RC file: $file"
elif [ -f /usr/share/shorewall/shorewallrc ]; then
file=/usr/share/shorewall/shorewallrc
. $file || fatal_error "Can not load the RC file: $file"
else
fatal_error "No configuration file specified and /usr/share/shorewall/shorewallrc not found"
fi
elif [ $# -eq 1 ]; then
file=$1
case $file in
/*|.*)
;;
*)
file=./$file || exit 1
;;
esac
. $file || fatal_error "Can not load the RC file: $file"
else
usage 1
fi
if [ -z "${VARLIB}" ]; then
VARLIB=${VARDIR}
VARDIR=${VARLIB}/${PRODUCT}
elif [ -z "${VARDIR}" ]; then
VARDIR=${VARLIB}/${PRODUCT}
fi
for var in SHAREDIR LIBEXECDIR PERLLIBDIR CONFDIR SBINDIR VARLIB VARDIR; do
require $var
done
[ -n "${INITFILE}" ] && require INITSOURCE && require INITDIR
[ -n "$SANDBOX" ] && configure=0
if [ -z "$BUILD" ]; then
case $(uname) in
cygwin*|CYGWIN*)
BUILD=cygwin
;;
Darwin)
BUILD=apple
;;
*)
if [ -f /etc/os-release ]; then
eval $(cat /etc/os-release | grep ^ID)
case $ID in
fedora|rhel|centos|foobar)
BUILD=redhat
;;
debian)
BUILD=debian
;;
gentoo)
BUILD=gentoo
;;
opensuse)
BUILD=suse
;;
alt|basealt|altlinux)
BUILD=alt
;;
*)
BUILD="$ID"
;;
esac
elif [ -f /etc/debian_version ]; then
BUILD=debian
elif [ -f /etc/gentoo-release ]; then
BUILD=gentoo
elif [ -f /etc/altlinux-release ]; then
BUILD=alt
elif [ -f /etc/redhat-release ]; then
BUILD=redhat
elif [ -f /etc/slackware-version ] ; then
BUILD=slackware
elif [ -f /etc/SuSE-release ]; then
BUILD=suse
elif [ -f /etc/arch-release ] ; then
BUILD=archlinux
elif [ -f ${CONFDIR}/openwrt_release ] ; then
BUILD=openwrt
else
BUILD=linux
fi
;;
esac
fi
case $BUILD in
cygwin*)
OWNER=$(id -un)
GROUP=$(id -gn)
;;
apple)
[ -z "$OWNER" ] && OWNER=root
[ -z "$GROUP" ] && GROUP=wheel
INSTALLD=
T=
;;
*)
[ -z "$OWNER" ] && OWNER=root
[ -z "$GROUP" ] && GROUP=root
;;
esac
OWNERSHIP="-o $OWNER -g $GROUP"
case "$HOST" in
cygwin)
echo "Installing Cygwin-specific configuration..."
;;
apple)
echo "Installing Mac-specific configuration...";
;;
debian)
echo "Installing Debian-specific configuration..."
;;
gentoo)
echo "Installing Gentoo-specific configuration..."
;;
redhat)
echo "Installing Redhat/Fedora-specific configuration..."
;;
suse)
echo "Installing SuSE-specific configuration...";
;;
slackware)
echo "Installing Slackware-specific configuration..."
;;
archlinux)
echo "Installing ArchLinux-specific configuration..."
;;
openwrt)
echo "Installing OpenWRT-specific configuration..."
;;
alt)
echo "Installing ALT-specific configuration...";
;;
linux)
;;
*)
fatal_error "Unknown HOST \"$HOST\""
;;
esac
if [ ${PRODUCT} = shorewall ]; then
if [ -n "$DIGEST" ]; then
#
# The user specified which digest to use
#
if [ "$DIGEST" != SHA ]; then
if [ "$BUILD" = "$HOST" ] && ! eval perl -e \'use Digest::$DIGEST\;\' 2> /dev/null ; then
fatal_error "Perl compilation with Digest::$DIGEST failed"
fi
cp -af Perl/Shorewall/Chains.pm Perl/Shorewall/Chains.pm.bak
cp -af Perl/Shorewall/Config.pm Perl/Shorewall/Config.pm.bak
eval sed -i \'s/Digest::SHA/Digest::$DIGEST/\' Perl/Shorewall/Chains.pm
eval sed -i \'s/Digest::SHA/Digest::$DIGEST/\' Perl/Shorewall/Config.pm
fi
elif [ "$BUILD" = "$HOST" ]; then
#
# Fix up 'use Digest::' if SHA1 is installed
#
DIGEST=SHA
if ! perl -e 'use Digest::SHA;' 2> /dev/null ; then
if perl -e 'use Digest::SHA1;' 2> /dev/null ; then
cp -af Perl/Shorewall/Chains.pm Perl/Shorewall/Chains.pm.bak
cp -af Perl/Shorewall/Config.pm Perl/Shorewall/Config.pm.bak
sed -i 's/Digest::SHA/Digest::SHA1/' Perl/Shorewall/Chains.pm
sed -i 's/Digest::SHA/Digest::SHA1/' Perl/Shorewall/Config.pm
DIGEST=SHA1
else
fatal_error "Shorewall $VERSION requires either Digest::SHA or Digest::SHA1"
fi
fi
fi
if [ "$BUILD" = "$HOST" ]; then
#
# Verify that Perl and all required modules are installed
#
echo "Compiling the Shorewall Perl Modules with Digest::$DIGEST"
if ! perl -c Perl/compiler.pl; then
echo "ERROR: $Product $VERSION requires Perl which either is not installed or is not able to compile the Shorewall Perl code" >&2
echo " Try perl -c $PWD/Perl/compiler.pl" >&2
exit 1
fi
else
echo "Using Digest::$DIGEST"
fi
fi
if [ $BUILD != cygwin ]; then
if [ `id -u` != 0 ] ; then
echo "Not setting file owner/group permissions, not running as root."
OWNERSHIP=""
fi
fi
run_install -d $OWNERSHIP -m 0755 ${DESTDIR}${SBINDIR}
[ -n "${INITFILE}" ] && run_install -d $OWNERSHIP -m 0755 ${DESTDIR}${INITDIR}
if [ -z "$DESTDIR" -a ${PRODUCT} != shorewall ]; then
[ -x ${LIBEXECDIR}/shorewall/compiler.pl ] || fatal_error "Shorewall >= 4.5.0 is not installed"
fi
echo "Installing $Product Version $VERSION"
#
# Check for /usr/share/${PRODUCT}/version
#
if [ -f ${DESTDIR}${SHAREDIR}/${PRODUCT}/version ]; then
first_install=""
else
first_install="Yes"
fi
if [ -z "${DESTDIR}" -a ${PRODUCT} = shorewall -a ! -f ${SHAREDIR}/shorewall/coreversion ]; then
echo "Shorewall $VERSION requires Shorewall Core which does not appear to be installed"
exit 1
fi
#
# Install the Firewall Script
#
if [ -n "$INITFILE" ]; then
if [ -f "${INITSOURCE}" ]; then
initfile="${DESTDIR}${INITDIR}/${INITFILE}"
install_file $INITSOURCE "$initfile" 0544
[ "${SHAREDIR}" = /usr/share ] || eval sed -i \'s\|/usr/share/\|${SHAREDIR}/\|\' "$initfile"
echo "SysV init script $INITSOURCE installed in $initfile"
fi
fi
#
# Create /etc/${PRODUCT} and other directories
#
make_parent_directory ${DESTDIR}${CONFDIR}/${PRODUCT} 0755
make_parent_directory ${DESTDIR}${LIBEXECDIR}/${PRODUCT} 0755
make_parent_directory ${DESTDIR}${PERLLIBDIR}/Shorewall 0755
make_parent_directory ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles 0755
make_parent_directory ${DESTDIR}${SHAREDIR}/${PRODUCT}/deprecated 0755
make_parent_directory ${DESTDIR}${VARDIR} 0755
chmod 0755 ${DESTDIR}${SHAREDIR}/${PRODUCT}
[ -n "$DESTDIR" ] && make_parent_directory ${DESTDIR}${CONFDIR}/logrotate.d 0755
#
# Install the .service file
#
if [ -z "${SERVICEDIR}" ]; then
SERVICEDIR="$SYSTEMD"
fi
if [ -n "$SERVICEDIR" ]; then
make_parent_directory ${DESTDIR}${SERVICEDIR} 0755
[ -z "$SERVICEFILE" ] && SERVICEFILE=${PRODUCT}.service
run_install $OWNERSHIP -m 0644 $SERVICEFILE ${DESTDIR}${SERVICEDIR}/${PRODUCT}.service
[ ${SBINDIR} != /sbin ] && eval sed -i \'s\|/sbin/\|${SBINDIR}/\|\' ${DESTDIR}${SERVICEDIR}/${PRODUCT}.service
echo "Service file $SERVICEFILE installed as ${DESTDIR}${SERVICEDIR}/${PRODUCT}.service"
fi
if [ -z "$first_install" ]; then
#
# These use absolute path names since the files that they are removing existed
# prior to the use of directory variables
#
delete_file ${DESTDIR}/usr/share/${PRODUCT}/compiler
delete_file ${DESTDIR}/usr/share/${PRODUCT}/lib.accounting
delete_file ${DESTDIR}/usr/share/${PRODUCT}/lib.actions
delete_file ${DESTDIR}/usr/share/${PRODUCT}/lib.dynamiczones
delete_file ${DESTDIR}/usr/share/${PRODUCT}/lib.maclist
delete_file ${DESTDIR}/usr/share/${PRODUCT}/lib.nat
delete_file ${DESTDIR}/usr/share/${PRODUCT}/lib.providers
delete_file ${DESTDIR}/usr/share/${PRODUCT}/lib.proxyarp
delete_file ${DESTDIR}/usr/share/${PRODUCT}/lib.tc
delete_file ${DESTDIR}/usr/share/${PRODUCT}/lib.tcrules
delete_file ${DESTDIR}/usr/share/${PRODUCT}/lib.tunnels
if [ ${PRODUCT} = shorewall6 ]; then
delete_file ${DESTDIR}/usr/share/shorewall6/lib.cli
delete_file ${DESTDIR}/usr/share/shorewall6/lib.common
delete_file ${DESTDIR}/usr/share/shorewall6/wait4ifup
fi
delete_file ${DESTDIR}/usr/share/${PRODUCT}/prog.header6
delete_file ${DESTDIR}/usr/share/${PRODUCT}/prog.footer6
#
# Delete obsolete config files and manpages
#
delete_file ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/tos
delete_file ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/tcrules
delete_file ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/stoppedrules
delete_file ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/notrack
delete_file ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/blacklist
delete_file ${DESTDIR}${MANDIR}/man5/${PRODUCT}/${PRODUCT}-tos
delete_file ${DESTDIR}${MANDIR}/man5/${PRODUCT}/${PRODUCT}-tcrules
delete_file ${DESTDIR}${MANDIR}/man5/${PRODUCT}/${PRODUCT}-stoppedrules
delete_file ${DESTDIR}${MANDIR}/man5/${PRODUCT}/${PRODUCT}-notrack
delete_file ${DESTDIR}${MANDIR}/man5/${PRODUCT}/${PRODUCT}-blacklist
if [ ${PRODUCT} = shorewall ]; then
#
# Delete deprecated macros and actions
#
delete_file ${DESTDIR}${SHAREDIR}/shorewall/macro.SNMPTrap
delete_file ${DESTDIR}${SHAREDIR}/shorewall/action.A_REJECT
delete_file ${DESTDIR}${SHAREDIR}/shorewall/action.Drop
delete_file ${DESTDIR}${SHAREDIR}/shorewall/action.Reject
delete_file ${DESTDIR}${SHAREDIR}/shorewall/action.A_Drop
delete_file ${DESTDIR}${SHAREDIR}/shorewall/action.A_Reject
delete_file ${DESTDIR}${SHAREDIR}/shorewall/action.A_AllowICMPs
else
delete_file ${DESTDIR}${SHAREDIR}/shorewall6/action.A_AllowICMPs
delete_file ${DESTDIR}${SHAREDIR}/shorewall6/action.AllowICMPs
delete_file ${DESTDIR}${SHAREDIR}/shorewall6/action.Broadcast
delete_file ${DESTDIR}${SHAREDIR}/shorewall6/action.Multicast
fi
fi
#
# Install the Module Helpers file
#
run_install $OWNERSHIP -m 0644 helpers ${DESTDIR}${SHAREDIR}/${PRODUCT}/helpers
echo "Helper modules file installed as ${DESTDIR}${SHAREDIR}/${PRODUCT}/helpers"
#
# Install the default config path file
#
install_file configpath ${DESTDIR}${SHAREDIR}/${PRODUCT}/configpath 0644
echo "Default config path file installed as ${DESTDIR}${SHAREDIR}/${PRODUCT}/configpath"
#
# Install the Standard Actions file
#
install_file actions.std ${DESTDIR}${SHAREDIR}/${PRODUCT}/actions.std 0644
echo "Standard actions file installed as ${DESTDIR}${SHAREDIR}/${PRODUCT}/actions.std"
cd configfiles
if [ -n "$ANNOTATED" ]; then
suffix=.annotated
else
suffix=
fi
#
# Install the config file
#
fix_config() {
if [ $HOST = archlinux ] ; then
sed -e 's!LOGFILE=/var/log/messages!LOGFILE=/var/log/messages.log!' -i $1
elif [ $HOST = debian ]; then
perl -p -w -i -e 's|^STARTUP_ENABLED=.*|STARTUP_ENABLED=Yes|;' $1
elif [ $HOST = gentoo ]; then
# Adjust SUBSYSLOCK path (see https://bugs.gentoo.org/show_bug.cgi?id=459316)
perl -p -w -i -e "s|^SUBSYSLOCK=.*|SUBSYSLOCK=/run/lock/${PRODUCT}|;" $1
fi
}
run_install $OWNERSHIP -m 0644 $PRODUCT.conf ${DESTDIR}${SHAREDIR}/$PRODUCT/configfiles/
fix_config ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/${PRODUCT}.conf
if [ ${PRODUCT} = shorewall ]; then
run_install $OWNERSHIP -m 0644 shorewall.conf.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
fix_config ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/${PRODUCT}.conf.annotated
fi
if [ ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/${PRODUCT}.conf ]; then
run_install $OWNERSHIP -m 0600 ${PRODUCT}.conf${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/${PRODUCT}.conf
fix_config ${DESTDIR}${CONFDIR}/${PRODUCT}/${PRODUCT}.conf
echo "Config file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/${PRODUCT}.conf"
fi
#
# Install the init file
#
run_install $OWNERSHIP -m 0644 init ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/init
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/init ]; then
run_install $OWNERSHIP -m 0600 init ${DESTDIR}${CONFDIR}/${PRODUCT}/init
echo "Init file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/init"
fi
#
# Install the zones file
#
run_install $OWNERSHIP -m 0644 zones ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
run_install $OWNERSHIP -m 0644 zones.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/zones ]; then
run_install $OWNERSHIP -m 0600 zones${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/zones
echo "Zones file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/zones"
fi
#
# Install the policy file
#
run_install $OWNERSHIP -m 0644 policy ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
run_install $OWNERSHIP -m 0644 policy.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/policy ]; then
run_install $OWNERSHIP -m 0600 policy${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/policy
echo "Policy file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/policy"
fi
#
# Install the interfaces file
#
run_install $OWNERSHIP -m 0644 interfaces ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
run_install $OWNERSHIP -m 0644 interfaces.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/interfaces ]; then
run_install $OWNERSHIP -m 0600 interfaces${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/interfaces
echo "Interfaces file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/interfaces"
fi
#
# Install the hosts file
#
run_install $OWNERSHIP -m 0644 hosts ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
run_install $OWNERSHIP -m 0644 hosts.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/hosts ]; then
run_install $OWNERSHIP -m 0600 hosts${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/hosts
echo "Hosts file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/hosts"
fi
#
# Install the rules file
#
run_install $OWNERSHIP -m 0644 rules ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
run_install $OWNERSHIP -m 0644 rules.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/rules ]; then
run_install $OWNERSHIP -m 0600 rules${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/rules
echo "Rules file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/rules"
fi
if [ -f nat ]; then
#
# Install the NAT file
#
run_install $OWNERSHIP -m 0644 nat ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles
run_install $OWNERSHIP -m 0644 nat.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/nat ]; then
run_install $OWNERSHIP -m 0600 nat${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/nat
echo "NAT file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/nat"
fi
fi
#
# Install the NETMAP file
#
run_install $OWNERSHIP -m 0644 netmap ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles
run_install $OWNERSHIP -m 0644 netmap.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/netmap ]; then
run_install $OWNERSHIP -m 0600 netmap${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/netmap
echo "NETMAP file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/netmap"
fi
#
# Install the Parameters file
#
run_install $OWNERSHIP -m 0644 params ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
run_install $OWNERSHIP -m 0644 params.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -f ${DESTDIR}${CONFDIR}/${PRODUCT}/params ]; then
chmod 0644 ${DESTDIR}${CONFDIR}/${PRODUCT}/params
else
case "$SPARSE" in
[Vv]ery)
;;
*)
run_install $OWNERSHIP -m 0600 params${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/params
echo "Parameter file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/params"
;;
esac
fi
if [ ${PRODUCT} = shorewall ]; then
#
# Install the proxy ARP file
#
run_install $OWNERSHIP -m 0644 proxyarp ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles
run_install $OWNERSHIP -m 0644 proxyarp.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/proxyarp ]; then
run_install $OWNERSHIP -m 0600 proxyarp${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/proxyarp
echo "Proxy ARP file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/proxyarp"
fi
else
#
# Install the Proxyndp file
#
run_install $OWNERSHIP -m 0644 proxyndp ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
run_install $OWNERSHIP -m 0644 proxyndp.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/proxyndp ]; then
run_install $OWNERSHIP -m 0600 proxyndp${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/proxyndp
echo "Proxyndp file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/proxyndp"
fi
fi
#
# Install the Stopped Rules file
#
run_install $OWNERSHIP -m 0644 stoppedrules ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
run_install $OWNERSHIP -m 0644 stoppedrules.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/stoppedrules ]; then
run_install $OWNERSHIP -m 0600 stoppedrules${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/stoppedrules
echo "Stopped Rules file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/stoppedrules"
fi
#
# Install the Mac List file
#
run_install $OWNERSHIP -m 0644 maclist ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
run_install $OWNERSHIP -m 0644 maclist.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/maclist ]; then
run_install $OWNERSHIP -m 0600 maclist${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/maclist
echo "mac list file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/maclist"
fi
#
# Install the SNAT file
#
run_install $OWNERSHIP -m 0644 snat ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles
run_install $OWNERSHIP -m 0644 snat.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/snat ]; then
run_install $OWNERSHIP -m 0600 snat${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/snat
echo "SNAT file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/snat"
fi
if [ -f arprules ]; then
#
# Install the ARP rules file
#
run_install $OWNERSHIP -m 0644 arprules ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles
run_install $OWNERSHIP -m 0644 arprules.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/arprules ]; then
run_install $OWNERSHIP -m 0600 arprules${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/arprules
echo "ARP rules file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/arprules"
fi
fi
#
# Install the Conntrack file
#
run_install $OWNERSHIP -m 0644 conntrack ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles
run_install $OWNERSHIP -m 0644 conntrack.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles
case "$SPARSE" in
[Vv]ery)
;;
*)
if [ ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/conntrack ]; then
run_install $OWNERSHIP -m 0600 conntrack${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/conntrack
echo "Conntrack file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/conntrack"
fi
;;
esac
#
# Install the Mangle file
#
run_install $OWNERSHIP -m 0644 mangle ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
run_install $OWNERSHIP -m 0644 mangle.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/mangle ]; then
run_install $OWNERSHIP -m 0600 mangle${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/mangle
echo "Mangle file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/mangle"
fi
#
# Install the TC Interfaces file
#
run_install $OWNERSHIP -m 0644 tcinterfaces ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
run_install $OWNERSHIP -m 0644 tcinterfaces.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/tcinterfaces ]; then
run_install $OWNERSHIP -m 0600 tcinterfaces${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/tcinterfaces
echo "TC Interfaces file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/tcinterfaces"
fi
#
# Install the TC Priority file
#
run_install $OWNERSHIP -m 0644 tcpri ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
run_install $OWNERSHIP -m 0644 tcpri.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/tcpri ]; then
run_install $OWNERSHIP -m 0600 tcpri${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/tcpri
echo "TC Priority file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/tcpri"
fi
#
# Install the Tunnels file
#
run_install $OWNERSHIP -m 0644 tunnels ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
run_install $OWNERSHIP -m 0644 tunnels.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/tunnels ]; then
run_install $OWNERSHIP -m 0600 tunnels${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/tunnels
echo "Tunnels file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/tunnels"
fi
#
# Install the blacklist rules file
#
run_install $OWNERSHIP -m 0644 blrules ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
run_install $OWNERSHIP -m 0644 blrules.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/blrules ]; then
run_install $OWNERSHIP -m 0600 blrules${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/blrules
echo "Blrules file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/blrules"
fi
if [ -f findgw ]; then
#
# Install the findgw file
#
run_install $OWNERSHIP -m 0644 findgw ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/findgw ]; then
run_install $OWNERSHIP -m 0600 findgw ${DESTDIR}${CONFDIR}/${PRODUCT}
echo "Find GW file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/findgw"
fi
fi
#
# Delete the Limits Files
#
delete_file ${DESTDIR}${SHAREDIR}/${PRODUCT}/action.Limit
delete_file ${DESTDIR}${SHAREDIR}/${PRODUCT}/Limit
#
# Delete the xmodules file
#
delete_file ${DESTDIR}${SHAREDIR}/${PRODUCT}/xmodules
#
# Install the Providers file
#
run_install $OWNERSHIP -m 0644 providers ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
run_install $OWNERSHIP -m 0644 providers.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/providers ]; then
run_install $OWNERSHIP -m 0600 providers${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/providers
echo "Providers file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/providers"
fi
#
# Install the Route Rules file
#
run_install $OWNERSHIP -m 0644 rtrules ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
run_install $OWNERSHIP -m 0644 rtrules.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -f ${DESTDIR}${CONFDIR}/${PRODUCT}/route_rules -a ! ${DESTDIR}${CONFDIR}/${PRODUCT}/rtrules ]; then
mv -f ${DESTDIR}${CONFDIR}/${PRODUCT}/route_rules ${DESTDIR}${CONFDIR}/${PRODUCT}/rtrules
echo "${DESTDIR}${CONFDIR}/${PRODUCT}/route_rules has been renamed ${DESTDIR}${CONFDIR}/${PRODUCT}/rtrules"
elif [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/rtrules ]; then
run_install $OWNERSHIP -m 0600 rtrules${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/rtrules
echo "Routing rules file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/rtrules"
fi
#
# Install the tcclasses file
#
run_install $OWNERSHIP -m 0644 tcclasses ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
run_install $OWNERSHIP -m 0644 tcclasses.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/tcclasses ]; then
run_install $OWNERSHIP -m 0600 tcclasses${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/tcclasses
echo "TC Classes file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/tcclasses"
fi
#
# Install the tcdevices file
#
run_install $OWNERSHIP -m 0644 tcdevices ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
run_install $OWNERSHIP -m 0644 tcdevices.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/tcdevices ]; then
run_install $OWNERSHIP -m 0600 tcdevices${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/tcdevices
echo "TC Devices file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/tcdevices"
fi
#
# Install the tcfilters file
#
run_install $OWNERSHIP -m 0644 tcfilters ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
run_install $OWNERSHIP -m 0644 tcfilters.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/tcfilters ]; then
run_install $OWNERSHIP -m 0600 tcfilters${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/tcfilters
echo "TC Filters file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/tcfilters"
fi
#
# Install the secmarks file
#
run_install $OWNERSHIP -m 0644 secmarks ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles
run_install $OWNERSHIP -m 0644 secmarks.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/secmarks ]; then
run_install $OWNERSHIP -m 0600 secmarks${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/secmarks
echo "Secmarks file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/secmarks"
fi
#
# Install the init file
#
run_install $OWNERSHIP -m 0644 init ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/init ]; then
run_install $OWNERSHIP -m 0600 init ${DESTDIR}${CONFDIR}/${PRODUCT}
echo "Init file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/init"
fi
if [ -f initdone ]; then
#
# Install the initdone file
#
run_install $OWNERSHIP -m 0644 initdone ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/initdone ]; then
run_install $OWNERSHIP -m 0600 initdone ${DESTDIR}${CONFDIR}/${PRODUCT}
echo "Initdone file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/initdone"
fi
fi
#
# Install the start file
#
run_install $OWNERSHIP -m 0644 start ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/start
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/start ]; then
run_install $OWNERSHIP -m 0600 start ${DESTDIR}${CONFDIR}/${PRODUCT}/start
echo "Start file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/start"
fi
#
# Install the stop file
#
run_install $OWNERSHIP -m 0644 stop ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/stop
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/stop ]; then
run_install $OWNERSHIP -m 0600 stop ${DESTDIR}${CONFDIR}/${PRODUCT}/stop
echo "Stop file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/stop"
fi
#
# Install the stopped file
#
run_install $OWNERSHIP -m 0644 stopped ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/stopped
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/stopped ]; then
run_install $OWNERSHIP -m 0600 stopped ${DESTDIR}${CONFDIR}/${PRODUCT}/stopped
echo "Stopped file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/stopped"
fi
if [ -f ecn ]; then
#
# Install the ECN file
#
run_install $OWNERSHIP -m 0644 ecn ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles
run_install $OWNERSHIP -m 0644 ecn.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/ecn ]; then
run_install $OWNERSHIP -m 0600 ecn${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/ecn
echo "ECN file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/ecn"
fi
fi
#
# Install the Accounting file
#
run_install $OWNERSHIP -m 0644 accounting ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
run_install $OWNERSHIP -m 0644 accounting.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/accounting ]; then
run_install $OWNERSHIP -m 0600 accounting${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/accounting
echo "Accounting file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/accounting"
fi
#
# Install the private library file
#
run_install $OWNERSHIP -m 0644 lib.private ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/lib.private ]; then
run_install $OWNERSHIP -m 0600 lib.private ${DESTDIR}${CONFDIR}/${PRODUCT}
echo "Private library file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/lib.private"
fi
#
# Install the Started file
#
run_install $OWNERSHIP -m 0644 started ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/started
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/started ]; then
run_install $OWNERSHIP -m 0600 started ${DESTDIR}${CONFDIR}/${PRODUCT}/started
echo "Started file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/started"
fi
#
# Install the Restored file
#
run_install $OWNERSHIP -m 0644 restored ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/restored
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/restored ]; then
run_install $OWNERSHIP -m 0600 restored ${DESTDIR}${CONFDIR}/${PRODUCT}/restored
echo "Restored file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/restored"
fi
#
# Install the Clear file
#
run_install $OWNERSHIP -m 0644 clear ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/clear
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/clear ]; then
run_install $OWNERSHIP -m 0600 clear ${DESTDIR}${CONFDIR}/${PRODUCT}/clear
echo "Clear file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/clear"
fi
#
# Install the Isusable file
#
run_install $OWNERSHIP -m 0644 isusable ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/isusable
#
# Install the Refresh file
#
run_install $OWNERSHIP -m 0644 refresh ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/refresh
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/refresh ]; then
run_install $OWNERSHIP -m 0600 refresh ${DESTDIR}${CONFDIR}/${PRODUCT}/refresh
echo "Refresh file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/refresh"
fi
#
# Install the Refreshed file
#
run_install $OWNERSHIP -m 0644 refreshed ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/refreshed
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/refreshed ]; then
run_install $OWNERSHIP -m 0600 refreshed ${DESTDIR}${CONFDIR}/${PRODUCT}/refreshed
echo "Refreshed file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/refreshed"
fi
#
# Install the Tcclear file
#
run_install $OWNERSHIP -m 0644 tcclear ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/tcclear ]; then
run_install $OWNERSHIP -m 0600 tcclear ${DESTDIR}${CONFDIR}/${PRODUCT}/tcclear
echo "Tcclear file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/tcclear"
fi
#
# Install the Scfilter file
#
run_install $OWNERSHIP -m 0644 scfilter ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/scfilter
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/scfilter ]; then
run_install $OWNERSHIP -m 0600 scfilter ${DESTDIR}${CONFDIR}/${PRODUCT}/scfilter
echo "Scfilter file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/scfilter"
fi
#
# Install the Actions file
#
run_install $OWNERSHIP -m 0644 actions ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
run_install $OWNERSHIP -m 0644 actions.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/actions ]; then
run_install $OWNERSHIP -m 0600 actions${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/actions
echo "Actions file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/actions"
fi
#
# Install the Routes file
#
run_install $OWNERSHIP -m 0644 routes ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
run_install $OWNERSHIP -m 0644 routes.annotated ${DESTDIR}${SHAREDIR}/${PRODUCT}/configfiles/
if [ -z "$SPARSE" -a ! -f ${DESTDIR}${CONFDIR}/${PRODUCT}/routes ]; then
run_install $OWNERSHIP -m 0600 routes${suffix} ${DESTDIR}${CONFDIR}/${PRODUCT}/routes
echo "Routes file installed as ${DESTDIR}${CONFDIR}/${PRODUCT}/routes"
fi
cd ..
#
# Install the Action files
#
cd Actions
for f in action.* ; do
case $f in
*.deprecated)
install_file $f ${DESTDIR}${SHAREDIR}/${PRODUCT}/deprecated/${f%.*} 0644
echo "Action ${f#*.} file installed as ${DESTDIR}${SHAREDIR}/${PRODUCT}/deprecated/${f%.*}"
;;
*)
install_file $f ${DESTDIR}${SHAREDIR}/${PRODUCT}/$f 0644
echo "Action ${f#*.} file installed as ${DESTDIR}${SHAREDIR}/${PRODUCT}/$f"
;;
esac
done
#
# Now the Macros
#
cd ../Macros
for f in macro.* ; do
case $f in
*.deprecated)
install_file $f ${DESTDIR}${SHAREDIR}/${PRODUCT}/deprecated/${f%.*} 0644
echo "Macro ${f#*.} file installed as ${DESTDIR}${SHAREDIR}/${PRODUCT}/deprecated/${f%.*}"
;;
*)
install_file $f ${DESTDIR}${SHAREDIR}/${PRODUCT}/$f 0644
echo "Macro ${f#*.} file installed as ${DESTDIR}${SHAREDIR}/${PRODUCT}/$f"
;;
esac
done
cd ..
#
# Install the libraries
#
for f in lib.* Perl/lib.*; do
if [ -f $f ]; then
case $f in
*installer)
;;
*)
install_file $f ${DESTDIR}${SHAREDIR}/${PRODUCT}/$(basename $f) 0644
echo "Library ${f#*.} file installed as ${DESTDIR}${SHAREDIR}/${PRODUCT}/$f"
;;
esac
fi
done
if [ ${PRODUCT} = shorewall6 ]; then
#
# Symbolically link 'functions' to lib.base
#
ln -sf lib.base ${DESTDIR}${SHAREDIR}/${PRODUCT}/functions
#
# And create a symbolic link for the CLI
#
ln -sf shorewall ${DESTDIR}${SBINDIR}/shorewall6
fi
if [ -d Perl ]; then
#
# ${SHAREDIR}/${PRODUCT}/$Product if needed
#
make_parent_directory ${DESTDIR}${SHAREDIR}/${PRODUCT}/$Product 0755
#
# Install the Compiler
#
cd Perl
install_file compiler.pl ${DESTDIR}${LIBEXECDIR}/${PRODUCT}/compiler.pl 0755
echo
echo "Compiler installed in ${DESTDIR}${LIBEXECDIR}/${PRODUCT}/compiler.pl"
#
# Install the params file helper
#
install_file getparams ${DESTDIR}${LIBEXECDIR}/${PRODUCT}/getparams 0755
[ $SHAREDIR = /usr/share ] || eval sed -i \'s\|/usr/share/\|${SHAREDIR}/\|\' ${DESTDIR}${LIBEXECDIR}/${PRODUCT}/getparams
echo
echo "Params file helper installed in ${DESTDIR}${LIBEXECDIR}/${PRODUCT}/getparams"
#
# Install the Perl modules
#
for f in $Product/*.pm ; do
install_file $f ${DESTDIR}${PERLLIBDIR}/$f 0644
echo "Module ${f%.*} installed as ${DESTDIR}${PERLLIBDIR}/$f"
done
[ -f Perl/Shorewall/Chains.pm.bak ] && mv Perl/Shorewall/Chains.pm.bak Perl/Shorewall/Chains.pm
[ -f Perl/Shorewall/Config.pm.bak ] && mv Perl/Shorewall/Config.pm.bak Perl/Shorewall/Config.pm
#
# Install the program skeleton files
#
for f in prog.* ; do
install_file $f ${DESTDIR}${SHAREDIR}/${PRODUCT}/$f 0644
echo "Program skeleton file ${f#*.} installed as ${DESTDIR}${SHAREDIR}/${PRODUCT}/$f"
done
cd ..
if [ -z "$DESTDIR" ]; then
rm -rf ${SHAREDIR}/${PRODUCT}-perl
rm -rf ${SHAREDIR}/${PRODUCT}-shell
[ "$PERLLIBDIR" != ${SHAREDIR}/${PRODUCT} ] && rm -rf ${SHAREDIR}/${PRODUCT}/$Product
fi
fi
#
# Create the version file
#
echo "$VERSION" > ${DESTDIR}${SHAREDIR}/${PRODUCT}/version
chmod 0644 ${DESTDIR}${SHAREDIR}/${PRODUCT}/version
#
# Remove and create the symbolic link to the init script
#
if [ -z "${DESTDIR}" -a -n "${INITFILE}" ]; then
rm -f ${SHAREDIR}/${PRODUCT}/init
ln -s ${INITDIR}/${INITFILE} ${SHAREDIR}/${PRODUCT}/init
fi
#
# Install the Man Pages
#
if [ -n "$MANDIR" ]; then
cd manpages
if [ ${PRODUCT} = shorewall ]; then
[ -n "$INSTALLD" ] || make_parent_directory ${DESTDIR}${MANDIR}/man5 0755
for f in *.5; do
gzip -9c $f > $f.gz
run_install $INSTALLD -m 0644 $f.gz ${DESTDIR}${MANDIR}/man5/$f.gz
echo "Man page $f.gz installed to ${DESTDIR}${MANDIR}/man5/$f.gz"
done
fi
if [ ${PRODUCT} = shorewall6 ]; then
make_parent_directory ${DESTDIR}${MANDIR}/man5 0755
rm -f ${DESTDIR}${MANDIR}/man5/shorewall6*
for f in \
shorewall-accounting.5 shorewall-ipsets.5 shorewall-providers.5 shorewall-tcclasses.5 \
shorewall-actions.5 shorewall-maclist.5 shorewall-tcdevices.5 \
shorewall-mangle.5 shorewall-proxyndp.5 shorewall-tcfilters.5 \
shorewall-blacklist.5 shorewall-masq.5 shorewall-routes.5 shorewall-tcinterfaces.5 \
shorewall-blrules.5 shorewall-modules.5 shorewall-routestopped.5 shorewall-tcpri.5 \
shorewall-conntrack.5 shorewall-nat.5 shorewall-rtrules.5 shorewall-tcrules.5 \
shorewall-nesting.5 shorewall-rules.5 shorewall-tos.5 \
shorewall-exclusion.5 shorewall-netmap.5 shorewall-secmarks.5 shorewall-tunnels.5 \
shorewall-hosts.5 shorewall-params.5 shorewall-snat.5 shorewall-vardir.5 \
shorewall-interfaces.5 shorewall-policy.5 shorewall-stoppedrules.5 shorewall-zones.5
do
f6=shorewall6-${f#*-}
echo ".so man5/$f" > ${DESTDIR}${MANDIR}/man5/$f6
done
echo ".so man5/shorewall.conf.5" > ${DESTDIR}${MANDIR}/man5/shorewall6.conf.5
fi
[ -n "$INSTALLD" ] || make_parent_directory ${DESTDIR}${MANDIR}/man8 0755
for f in *.8; do
gzip -9c $f > $f.gz
run_install $INSTALLD -m 0644 $f.gz ${DESTDIR}${MANDIR}/man8/$f.gz
echo "Man page $f.gz installed to ${DESTDIR}${MANDIR}/man8/$f.gz"
done
cd ..
echo "Man Pages Installed"
fi
if [ -d ${DESTDIR}${CONFDIR}/logrotate.d ]; then
run_install $OWNERSHIP -m 0644 logrotate ${DESTDIR}${CONFDIR}/logrotate.d/${PRODUCT}
echo "Logrotate file installed as ${DESTDIR}${CONFDIR}/logrotate.d/${PRODUCT}"
fi
#
# Note -- not all packages will have the SYSCONFFILE so we need to check for its existance here
#
if [ -n "$SYSCONFFILE" -a -f "$SYSCONFFILE" -a ! -f ${DESTDIR}${SYSCONFDIR}/${PRODUCT} ]; then
if [ ${DESTDIR} ]; then
make_parent_directory ${DESTDIR}${SYSCONFDIR} 0755
fi
run_install $OWNERSHIP -m 0644 ${SYSCONFFILE} ${DESTDIR}${SYSCONFDIR}/${PRODUCT}
echo "$SYSCONFFILE file installed in ${DESTDIR}${SYSCONFDIR}/${PRODUCT}"
fi
#
# Remove deleted actions and macros
#
if [ $PRODUCT = shorewall ]; then
rm -f ${DESTDIR}${SHAREDIR}/${PRODUCT}/deprecated/action.A_AllowICMPs
rm -f ${DESTDIR}${SHAREDIR}/${PRODUCT}/deprecated/action.A_Drop
rm -f ${DESTDIR}${SHAREDIR}/${PRODUCT}/deprecated/action.A_Reject
rm -f ${DESTDIR}${SHAREDIR}/${PRODUCT}/deprecated/action.Drop
rm -f ${DESTDIR}${SHAREDIR}/${PRODUCT}/deprecated/action.Reject
rm -f ${DESTDIR}${SHAREDIR}/${PRODUCT}/deprecated/macro.SMTPTraps
fi
#
# Remove unneeded modules files
#
if [ -n "$first_install" ]; then
rm -f ${DESTDIR}${SHAREDIR}/${PRODUCT}/modules*
fi
if [ $configure -eq 1 -a -z "$DESTDIR" -a -n "$first_install" -a -z "${cygwin}${mac}" ]; then
if [ -n "$SERVICEDIR" ]; then
if systemctl enable ${PRODUCT}.service; then
echo "$Product will start automatically at boot"
fi
elif mywhich insserv; then
if insserv ${CONFDIR}/init.d/${PRODUCT} ; then
echo "${PRODUCT} will start automatically at boot"
if [ $HOST = debian ]; then
echo "Set startup=1 in ${CONFDIR}/default/${PRODUCT} to enable"
touch /var/log/${PRODUCT}-init.log
perl -p -w -i -e 's/^STARTUP_ENABLED=No/STARTUP_ENABLED=Yes/;s/^IP_FORWARDING=On/IP_FORWARDING=Keep/;s/^SUBSYSLOCK=.*/SUBSYSLOCK=/;' ${CONFDIR}/${PRODUCT}/${PRODUCT}.conf
else
echo "Set STARTUP_ENABLED=Yes in ${CONFDIR}/${PRODUCT}/${PRODUCT}.conf to enable"
fi
else
cant_autostart
fi
elif mywhich chkconfig; then
if chkconfig --add ${PRODUCT} ; then
echo "${PRODUCT} will start automatically in run levels as follows:"
echo "Set STARTUP_ENABLED=Yes in ${CONFDIR}/${PRODUCT}/${PRODUCT}.conf to enable"
chkconfig --list ${PRODUCT}
else
cant_autostart
fi
elif mywhich update-rc.d ; then
echo "${PRODUCT} will start automatically at boot"
echo "Set startup=1 in ${CONFDIR}/default/${PRODUCT} to enable"
touch /var/log/${PRODUCT}-init.log
perl -p -w -i -e 's/^STARTUP_ENABLED=No/STARTUP_ENABLED=Yes/;s/^IP_FORWARDING=On/IP_FORWARDING=Keep/;s/^SUBSYSLOCK=.*/SUBSYSLOCK=/;' ${CONFDIR}/${PRODUCT}/${PRODUCT}.conf
update-rc.d ${PRODUCT} enable
elif mywhich rc-update ; then
if rc-update add ${PRODUCT} default; then
echo "${PRODUCT} will start automatically at boot"
if [ $HOST = debian ]; then
echo "Set startup=1 in ${CONFDIR}/default/${PRODUCT} to enable"
touch /var/log/${PRODUCT}-init.log
perl -p -w -i -e 's/^STARTUP_ENABLED=No/STARTUP_ENABLED=Yes/;s/^IP_FORWARDING=On/IP_FORWARDING=Keep/;s/^SUBSYSLOCK=.*/SUBSYSLOCK=/;' ${CONFDIR}/${PRODUCT}/${PRODUCT}.conf
else
echo "Set STARTUP_ENABLED=Yes in ${CONFDIR}/${PRODUCT}/${PRODUCT}.conf to enable"
fi
else
cant_autostart
fi
elif [ "$INITFILE" != rc.f ]; then #Slackware starts this automatically
cant_autostart
fi
fi
#
# Report Success
#
echo "$Product Version $VERSION Installed"
shorewall6-5.2.3.4/shorewallrc.suse 0000664 0000000 0000000 00000004167 13531077635 015721 0 ustar root root #
# SuSE Shorewall 5.2 rc file
#
BUILD= #Default is to detect the build system
HOST=suse
PREFIX=/usr #Top-level directory for shared files, libraries, etc.
CONFDIR=/etc #Directory where subsystem configurations are installed
SHAREDIR=${PREFIX}/share #Directory for arch-neutral files.
LIBEXECDIR=${PREFIX}/lib #Directory for executable scripts.
PERLLIBDIR=${PREFIX}/lib/perl5/site-perl #Directory to install Shorewall Perl module directory
SBINDIR=/usr/sbin #Directory where system administration programs are installed
MANDIR=${SHAREDIR}/man/ #Directory where manpages are installed.
INITDIR=/etc/init.d #Directory where SysV init scripts are installed.
INITFILE= #Name of the product's SysV init script
INITSOURCE=init.suse.sh #Name of the distributed file to be installed as the SysV init script
ANNOTATED= #If non-zero, annotated configuration files are installed
SERVICEDIR=/usr/lib/systemd/system #Directory where .service files are installed (systems running systemd only)
SERVICEFILE=$PRODUCT.service #Name of the file to install in $SYSTEMD. Default is $PRODUCT.service
SYSCONFFILE=sysconfig #Name of the distributed file to be installed in $SYSCONFDIR
SYSCONFDIR=/etc/sysconfig/ #Directory where SysV init parameter files are installed
SPARSE= #If non-empty, only install $PRODUCT/$PRODUCT.conf in $CONFDIR
VARLIB=/var/lib #Directory where persistent product data is stored.
VARDIR=${VARLIB}/$PRODUCT #Directory where product variable data is stored.
DEFAULT_PAGER= #Pager to use if none specified in shorewall[6].conf
shorewall6-5.2.3.4/Actions/ 0000775 0000000 0000000 00000000000 13531060406 014047 5 ustar root root shorewall6-5.2.3.4/Actions/action.template 0000664 0000000 0000000 00000001461 13531060406 017063 0 ustar root root #
# Shorewall6 -- /usr/share/shorewall6/action.template
#
# Action Template
#
# This file is a template for files with names of the form
# /etc/shorewall/action. where is an
# ACTION defined in /etc/shorewall/actions.
#
# To define a new action:
#
# 1. Add the to /etc/shorewall/actions
# 2. Copy this file to /etc/shorewall/action.
# 3. Add the desired rules to that file.
#
# Please see http://shorewall.net/Actions.html for additional information.
#
# Columns are the same as in /etc/shorewall6/rules.
#
##############################################################################################################################################################
#ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST RATE USER MARK CONNLIMIT TIME HEADERS SWITCH HELPER
shorewall6-5.2.3.4/Actions/action.mangletemplate 0000664 0000000 0000000 00000001524 13531060406 020247 0 ustar root root #
# Shorewall6 -- /usr/share/shorewall6/action.mangletemplate
#
# This file is a template for files with names of the form
# /etc/shorewall/action. where is an
# ACTION defined with the mangle option in /etc/shorewall/actions.
#
# To define a new action:
#
# 1. Add the to /etc/shorewall6/actions with the mangle option
# 2. Copy this file to /etc/shorewall6/action.
# 3. Add the desired rules to that file.
#
# Please see http://shorewall.net/Actions.html for additional information.
#
# Columns are the same as in /etc/shorewall6/mangle.
#
############################################################################################################################################################
#ACTION SOURCE DEST PROTO DPORT SPORT USER TEST LENGTH TOS CONNBYTES HELPER HEADERS PROBABILITY DSCP
shorewall6-5.2.3.4/logrotate 0000664 0000000 0000000 00000000122 13531060406 014365 0 ustar root root /var/log/shorewall6-init.log {
missingok
notifempty
create 0600 root root
}
shorewall6-5.2.3.4/ipsecvpn 0000664 0000000 0000000 00000015540 13531060406 014226 0 ustar root root #!/bin/sh
################################################################################
#
# ipsecvpn -- script for use on a roadwarrior to start/stop a tunnel-mode
# IPSEC connection
#
# (c) 2004,2005,2014 - Tom Eastep (teastep@shorewall.net)
#
# This program is part of Shorewall.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by the
# Free Software Foundation, either version 2 of the license or, at your
# option, any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, see
#
# where number is the SPI of the SA used to encrypt/decrypt packets.
#
# proto=ah|esp|ipcomp
#
# IPSEC Encapsulation Protocol
#
# mss=number
#
# sets the MSS field in TCP packets
#
# mode=transport|tunnel
#
# IPSEC mode
#
# 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
#
# yes
#
# When used by itself, causes all traffic that will be encrypted/
# encapsulated to match the rule.
#
# MARK - [!]value[/mask][:C]
#
# Defines a test on the existing packet or connection mark. The rule will
# match only if the test returns true.
#
# If you don't want to define a test but need to specify anything in the
# following columns, place a "-" in this field.
#
# !
#
# Inverts the test (not equal)
#
# value
#
# Value of the packet or connection mark.
#
# mask
#
# A mask to be applied to the mark before testing.
#
# :C
#
# Designates a connection mark. If omitted, the packet mark's value is
# tested.
#
# USER (Optional) - [!][user-name-or-number][:group-name-or-number][+program-name
# ]
#
# This column was formerly labelled USER/GROUP.
#
# Only locally-generated connections will match if this column is non-empty.
#
# When this column is non-empty, the rule matches only if the program
# generating the output is running under the effective user and/or group
# specified (or is NOT running under that id if "!" is given).
#
# Examples:
#
# joe
#
# program must be run by joe
#
# :kids
#
# program must be run by a member of the 'kids' group
#
# !:kids
#
# program must not be run by a member of the 'kids' group
#
# +upnpd
#
# #program named upnpd
#
# Important
#
# The ability to specify a program name was removed from Netfilter in
# kernel version 2.6.14.
#
# SWITCH - [!]switch-name[={0|1}]
#
# Added in Shorewall 4.5.1 and allows enabling and disabling the rule without
# requiring shorewall restart.
#
# The rule is enabled if the value stored in /proc/net/nf_condition/
# switch-name is 1. The rule is disabled if that file contains 0 (the
# default). If '!' is supplied, the test is inverted such that the rule is
# enabled if the file contains 0.
#
# Within the switch-name, '@0' and '@{0}' are replaced by the name of the
# chain to which the rule is a added. The switch-name (after '@...'
# expansion) must begin with a letter and be composed of letters, decimal
# digits, underscores or hyphens. Switch names must be 30 characters or less
# in length.
#
# Switches are normally off. To turn a switch on:
#
# echo 1 > /proc/net/nf_condition/switch-name
#
# To turn it off again:
#
# echo 0 > /proc/net/nf_condition/switch-name
#
# Switch settings are retained over shorewall restart.
#
# Beginning with Shorewall 4.5.10, when the switch-name is followed by =0 or
# =1, then the switch is initialized to off or on respectively by the start
# command. Other commands do not affect the switch setting.
#
# ORIGDEST - [-|address[,address]...[exclusion]|exclusion]
#
# (Optional) Added in Shorewall 4.5.6. This column may be included and may
# contain one or more addresses (host or network) separated by commas.
# Address ranges are not allowed. When this column is supplied, rules are
# generated that require that the original destination address matches one of
# the listed addresses. It is useful for specifying that SNAT should occur
# only for connections that were acted on by a DNAT when they entered the
# firewall.
#
# This column was formerly labelled ORIGINAL DEST.
#
# PROBABILITY - [probability]
#
# Added in Shorewall 5.0.0. When non-empty, requires the Statistics Match
# capability in your kernel and ip6tables and causes the rule to match
# randomly but with the given probability. The probability is a number 0 <
# probability <= 1 and may be expressed at up to 8 decimal points of
# precision.
#
# Examples
#
# IPv4 Example 1:
#
# You have a simple masquerading setup where eth0 connects to a DSL or cable
# modem and eth1 connects to your local network with subnet 192.168.0.0/24.
#
# Your entry in the file will be:
#
# #ACTION SOURCE DEST
# MASQUERADE 192.168.0.0/24 eth0
#
# IPv4 Example 2:
#
# You add a router to your local network to connect subnet 192.168.1.0/24
# which you also want to masquerade. You then add a second entry for eth0 to
# this file:
#
# #ACTION SOURCE DEST
# MASQUERADE 192.168.0.0/24 eth0
# MASQUERADE 192.168.1.0/24 eth0
#
# IPv4 Example 3:
#
# You want all outgoing traffic from 192.168.1.0/24 through eth0 to use
# source address 206.124.146.176 which is NOT the primary address of eth0.
# You want 206.124.146.176 to be added to eth0 with name eth0:0.
#
# #ACTION SOURCE DEST
# SNAT(206.124.146.176) 192.168.1.0/24 eth0:0
#
# IPv4 Example 4:
#
# You want all outgoing SMTP traffic entering the firewall from 172.20.1.0/29
# to be sent from eth0 with source IP address 206.124.146.177. You want all
# other outgoing traffic from 172.20.1.0/29 to be sent from eth0 with source
# IP address 206.124.146.176.
#
# #INTERFACE SOURCE ADDRESS PROTO DPORT
# eth0 172.20.1.0/29 206.124.146.177 tcp smtp
# eth0 172.20.1.0/29 206.124.146.176
#
# #ACTION SOURCE DEST PROTO PORT
# SNAT(206.124.146.177) 172.20.1.0/29 eth0 tcp smtp
# SNAT(206.124.146.176) 172.20.1.0/29 eth0
#
# Warning
#
# The order of the above two rules is significant!
#
# IPv4 Example 5:
#
# Connections leaving on eth0 and destined to any host defined in the ipset
# myset should have the source IP address changed to 206.124.146.177.
#
# #ACTION SOURCE DEST
# SNAT(206.124.146.177) - eth0:+myset[dst]
#
# IPv4 Example 6:
#
# SNAT outgoing connections on eth0 from 192.168.1.0/24 in round-robin
# fashion between addresses 1.1.1.1, 1.1.1.3, and 1.1.1.9 (Shorewall 4.5.9
# and later).
#
# /etc/shorewall/tcrules:
#
# #ACTION SOURCE DEST PROTO DPORT SPORT USER TEST
# 1-3:CF 192.168.1.0/24 eth0 ; state=NEW
#
# /etc/shorewall/snat:
#
# #ACTION SOURCE DEST
# SNAT(1.1.1.1) 192.168.1.0/24 eth0 { mark=1:C }
# SNAT(1.1.1.3) 192.168.1.0/24 eth0 { mark=2:C }
# SNAT(1.1.1.9) 192.168.1.0/24 eth0 { mark=3:C }
#
# IPv6 Example 1:
#
# You have a simple 'masquerading' setup where eth0 connects to a DSL or
# cable modem and eth1 connects to your local network with subnet
# 2001:470:b:787::0/64
#
# Your entry in the file will be:
#
# #ACTION SOURCE DEST
# MASQUERADE 2001:470:b:787::0/64 eth0
#
# IPv6 Example 2:
#
# Your sit1 interface has two public IP addresses: 2001:470:a:227::1 and
# 2001:470:b:227::1. You want to use the iptables statistics match to
# masquerade outgoing connections evenly between these two addresses.
#
# /etc/shorewall/snat:
#
# #ACTION SOURCE DEST
# SNAT(2001:470:a:227::1) ::/0 sit1 { probability=0.50 }
# SNAT(2001:470:a:227::2) ::/0 sit
#
###########################################################################################################################################
#ACTION SOURCE DEST PROTO PORT IPSEC MARK USER SWITCH ORIGDEST PROBABILITY
shorewall6-5.2.3.4/configfiles/zones 0000664 0000000 0000000 00000000523 13531060406 016020 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/zones
#
# For information about this file, type "man shorewall6-zones"
#
# The manpage is also online at
# http://www.shorewall.net/manpages6/shorewall6-zones.html
#
###############################################################################
#ZONE TYPE OPTIONS IN_OPTIONS OUT_OPTIONS
fw firewall
shorewall6-5.2.3.4/configfiles/init 0000664 0000000 0000000 00000000524 13531060406 015626 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/init
#
# Add commands below that you want to be executed at the beginning of
# a "shorewall6 start" or "shorewall6 restart" command.
#
# For additional information, see
# http://shorewall.net/shorewall_extension_scripts.htm
#
###############################################################################
shorewall6-5.2.3.4/configfiles/routes.annotated 0000664 0000000 0000000 00000003315 13531077646 020177 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/routes
#
# For information about entries in this file, type "man shorewall6-routes"
#
# For additional information, see http://www.shorewall.net/MultiISP.html
#
###############################################################################
#
# This file was added in Shorewall 4.4.15 and is used to define routes to be
# added to provider routing tables.
#
# The columns in the file are as follows.
#
# PROVIDER
#
# The name or number of a provider defined in shorewall-providers (5).
# Beginning with Shorewall 4.5.14, you may also enter main in this column to
# add routes to the main routing table.
#
# DEST
#
# Destination host address or network address.
#
# GATEWAY (Optional)
#
# If specified, gives the IP address of the gateway to the DEST.
#
# Beginning with Shorewall 4.5.14, you may specify blackhole in this column
# to create a blackhole route.
#
# Beginning with Shorewall 4.5.15, you may specify prohibit or unreachable in
# this column to create a prohibit or unreachable route respectively.
#
# DEVICE (Optional)
#
# Specifies the device route. If neither DEVICE nor GATEWAY is given, then
# the INTERFACE specified for the PROVIDER in shorewall-providers (5). This
# column must be omitted if blackhole, prohibit or unreachable is specified
# in the GATEWAY column.
#
# OPTIONS (Optional)
#
# Added in Shorewall 5.0.2.
#
# Allowed options are:
#
# persistent
#
# If specified, the route remains in the provider's routing table even
# when the provider is disabled.
#
###############################################################################
#PROVIDER DEST GATEWAY DEVICE OPTIONS
shorewall6-5.2.3.4/configfiles/stoppedrules 0000664 0000000 0000000 00000000702 13531060406 017412 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/stoppedrules
#
# For information about entries in this file,
# type "man shorewall6-stoppedrules"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall6-stoppedrules.html
#
# See http://shorewall.net/starting_and_stopping_shorewall.htm for additional
# information.
#
###############################################################################
#ACTION SOURCE DEST PROTO DPORT SPORT
shorewall6-5.2.3.4/configfiles/zones.annotated 0000664 0000000 0000000 00000020647 13531077654 020022 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/zones
#
# For information about this file, type "man shorewall6-zones"
#
# The manpage is also online at
# http://www.shorewall.net/manpages6/shorewall6-zones.html
#
###############################################################################
#
# The /etc/shorewall/zones file declares your network zones. You specify the
# hosts in each zone through entries in /etc/shorewall/interfaces or /etc/
# shorewall/hosts.
#
# The columns in the file are as follows (where the column name is followed by a
# different name in parentheses, the different name is used in the alternate
# specification syntax).
#
# ZONE - zone[:parent-zone[,parent-zone]...]
#
# Name of the zone. Must start with a letter and consist of letters, digits
# or '_'. The names "all", "none", "any", "SOURCE" and "DEST" are reserved
# and may not be used as zone names. The maximum length of a zone name is
# determined by the setting of the LOGFORMAT option in shorewall.conf(5).
# With the default LOGFORMAT, zone names can be at most 5 characters long.
#
# The maximum length of an iptables log prefix is 29 bytes. As explained
# in shorewall.conf (5), the legacy default LOGPREFIX formatting string
# is “Shorewall:%s:%s:” where the first %s is replaced by the chain name
# and the second is replaced by the disposition.
#
# ☆ The "Shorewall:%s:%s:" formatting string has 12 fixed characters
# ("Shorewall" and three colons).
#
# ☆ The longest of the standard dispositions are ACCEPT and REJECT
# which have 6 characters each.
#
# ☆ The canonical name for the chain containing the rules for traffic
# going from zone 1 to zone 2 is "2" or "-
# ".
#
# ☆ So if M is the maximum zone name length, such chains can have
# length 2*M + 1.
#
# 12 + 6 + 2*M + 1 = 29 which reduces to
# 2*M = 29 - 12 - 6 - 1 = 10 or
# M = 5
#
# In Shorewall 5.1.0, the LOGFORMAT in the default and sample
# shorewall.conf files was changed to "%s:%s ".
#
# ☆ That formatting string has 2 fixed characters (":" and a space).
#
# ☆ So the maximum zone name length M is calculated as:
#
# 2 + 6 + 2*M + 1 = 29
# 2M = 29 - 2 - 6 - 1 = 20
# M = 10
#
# The order in which Shorewall matches addresses from packets to zones is
# determined by the order of zone declarations. Where a zone is nested in one
# or more other zones, you may either ensure that the nested zone precedes
# its parents in this file, or you may follow the (sub)zone name by ":" and a
# comma-separated list of the parent zones. The parent zones must have been
# declared in earlier records in this file. See shorewall-nesting(5) for
# additional information.
#
# Example:
#
# #ZONE TYPE OPTIONS IN OPTIONS OUT OPTIONS
# a ip
# b ip
# c:a,b ip
#
# Currently, Shorewall uses this information to reorder the zone list so that
# parent zones appear after their subzones in the list. The IMPLICIT_CONTINUE
# option in shorewall.conf(5) can also create implicit CONTINUE policies to/
# from the subzone.
#
# Where an ipsec zone is explicitly included as a child of an ip zone, the
# ruleset allows CONTINUE policies (explicit or implicit) to work as
# expected.
#
# In the future, Shorewall may make additional use of nesting information.
#
# TYPE
#
# ip
#
# This is the standard Shorewall zone type and is the default if you
# leave this column empty or if you enter "-" in the column.
# Communication with some zone hosts may be encrypted. Encrypted hosts
# are designated using the 'ipsec' option in shorewall-hosts(5). For
# clarity, this zone type may be specified as ipv4 in IPv4 configurations
# and ipv6 in IPv6 configurations.
#
# ipsec
#
# Communication with all zone hosts is encrypted. Your kernel and
# iptables must include policy match support. For clarity, this zone type
# may be specified as ipsec4 in IPv4 configurations and ipsec6 in IPv6
# configurations.
#
# firewall
#
# Designates the firewall itself. You must have exactly one 'firewall'
# zone. No options are permitted with a 'firewall' zone. The name that
# you enter in the ZONE column will be stored in the shell variable $FW
# which you may use in other configuration files to designate the
# firewall zone.
#
# bport
#
# The zone is associated with one or more ports on a single bridge. For
# clarity, this zone type may be specified as bport4 in IPv4
# configurations and bport6 in IPv6 configurations.
#
# vserver
#
# Added in Shorewall 4.4.11 Beta 2 - A zone composed of Linux-vserver
# guests. The zone contents must be defined in shorewall-hosts (5).
#
# Vserver zones are implicitly handled as subzones of the firewall zone.
#
# loopback
#
# Added in Shorewall 4.5.17.
#
# Normally, Shorewall treats the loopback interface (lo) in the following
# way:
#
# ☆ By default, all traffic through the interface is ACCEPTed.
#
# ☆ If a $FW -> $FW policy is defined or $FW -> $FW rules are defined,
# they are placed in a chain named ${FW}2${F2} or ${FW}-${FW} (e.g.,
# 'fw2fw' or 'fw-fw' ) depending on the ZONE2ZONE setting in
# shorewall.conf(5).
#
# ☆ $FW -> $FW traffic is only filtered in the OUTPUT chain.
#
# By defining a loopback zone and associating it with the loopback
# interface in shorewall-interfaces(5), you can effect a slightly
# different model. Suppose that the loopback zone name is 'local'; then:
#
# ☆ Both $FW -> local and local -> $FW chains are created.
#
# ☆ The $FW -> local and local -> $FW policies may be different.
#
# ☆ Both $FW -> local and local -> $FW rules may be specified.
#
# Rules to/from the loopback zone and any zone other than the firewall
# zone are ignored with a warning.
#
# loopback zones may be nested within other loopback zones.
#
# local
#
# Added in Shorewall 4.5.17. local is the same as ipv4 with the exception
# that the zone is only accessible from the firewall and vserver zones.
#
# OPTIONS, IN OPTIONS and OUT OPTIONS (options, in_options, out_options) - [
# option[,option]...]
#
# A comma-separated list of options. With the exception of the mss and
# blacklist options, these only apply to TYPE ipsec zones.
#
# dynamic_shared
#
# Added in Shorewall 4.5.9. May only be specified in the OPTIONS column
# and indicates that only a single ipset should be created for this zone
# if it has multiple dynamic entries in shorewall-hosts(5). Without this
# option, a separate ipset is created for each interface.
#
# reqid=number
#
# where number is specified using setkey(8) using the 'unique:number
# option for the SPD level.
#
# spi=
#
# where number is the SPI of the SA used to encrypt/decrypt packets.
#
# proto=ah|esp|ipcomp
#
# IPSEC Encapsulation Protocol
#
# mss=number
#
# sets the MSS field in TCP packets. If you supply this option, you
# should also set FASTACCEPT=No in shorewall.conf(5) to insure that both
# the SYN and SYN,ACK packets have their MSS field adjusted.
#
# mode=transport|tunnel
#
# IPSEC mode
#
# 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
#
# 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 "-".
#
###############################################################################
#ZONE TYPE OPTIONS IN_OPTIONS OUT_OPTIONS
fw firewall
shorewall6-5.2.3.4/configfiles/nat.annotated 0000664 0000000 0000000 00000011432 13531077643 017434 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/nat
#
# For information about entries in this file, type "man shorewall6-nat"
#
# The manpage is also online at
# http://www.shorewall.net/manpages6/shorewall6-nat.html
#
###############################################################################
#
# This file is used to define one-to-one Network Address Translation (NAT).
#
# Warning
#
# If all you want to do is simple port forwarding, do NOT use this file. See
# http://www.shorewall.net/FAQ.htm#faq1. Also, in many cases, Proxy ARP (
# shorewall-proxyarp(5)) or Proxy-NDP(shorewall6-proxyndp(5)) is a better
# solution that one-to-one NAT.
#
# The columns in the file are as follows (where the column name is followed by a
# different name in parentheses, the different name is used in the alternate
# specification syntax).
#
# EXTERNAL - {address|?COMMENT}
#
# External IP Address - this should NOT be the primary IP address of the
# interface named in the next column and must not be a DNS Name.
#
# If you put ?COMMENT in this column, the rest of the line will be attached
# as a comment to the Netfilter rule(s) generated by the following entries in
# the file. The comment will appear delimited by "/* ... */" in the output of
# "shorewall show nat"
#
# To stop the comment from being attached to further rules, simply include ?
# COMMENT on a line by itself.
#
# INTERFACE - interfacelist[:[digit]]
#
# Interfaces that have the EXTERNAL address. If ADD_IP_ALIASES=Yes in
# shorewall.conf(5), Shorewall will automatically add the EXTERNAL address to
# this interface. Also if ADD_IP_ALIASES=Yes, you may follow the interface
# name with ":" and a digit to indicate that you want Shorewall to add the
# alias with this name (e.g., "eth0:0"). That allows you to see the alias
# with ifconfig. That is the only thing that this name is good for -- you
# cannot use it anywhere else in your Shorewall configuration.
#
# Each interface must match an entry in shorewall-interfaces(5). Shorewall
# allows loose matches to wildcard entries in shorewall-interfaces(5). For
# example, ppp0 in this file will match a shorewall-interfaces(5) entry that
# defines ppp+.
#
# If you want to override ADD_IP_ALIASES=Yes for a particular entry, follow
# the interface name with ":" and no digit (e.g., "eth0:").
#
# INTERNAL - address
#
# Internal Address (must not be a DNS Name).
#
# ALLINTS - [Yes|No]
#
# If Yes or yes, NAT will be effective from all hosts. If No or no (or left
# empty) then NAT will be effective only through the interface named in the
# INTERFACE column.
#
# This column was formerly labelled ALL INTERFACES.
#
# LOCAL - [Yes|No]
#
# If Yes or yes, NAT will be effective from the firewall system
#
# RESTRICTIONS
#
# DNAT rules always preempt one-to-one NAT rules. This has subtile consequences
# when there are sub-zones on an interface. Consider the following:
#
# /etc/shorewall/zones:
#
# #ZONE TYPE OPTIONS IN OUT
# # OPTIONS OPTIONS
# fw firewall
# net ipv4
# loc ipv4
# smc:net ipv4
#
# /etc/shorewall/interfaces:
#
# #ZONE INTERFACE OPTIONS
# net eth0 dhcp,tcpflags,nosmurfs,routefilter,logmartians,sourceroute=0
# loc eth1 tcpflags,nosmurfs,routefilter,logmartians
#
# /etc/shorewall/hosts:
#
# #ZONE HOST(S) OPTIONS
# smc eth0:10.1.10.0/24
#
# /etc/shorewall/nat:
#
# #EXTERNAL INTERFACE INTERNAL ALLINTS LOCAL
# 10.1.10.100 eth0 172.20.1.100
#
# Note that the EXTERNAL address is in the smc zone.
#
# /etc/shorewall/rules:
#
# #ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST RATE USER MARK CONNLIMIT TIME HEADERS SWITCH HELPER
# ?SECTION ALL
# ?SECTION ESTABLISHED
# ?SECTION RELATED
# ?SECTION INVALID
# ?SECTION UNTRACKED
# ?SECTION NEW
# ...
# DNAT net loc:172.20.1.4 tcp 80
#
# For the one-to-one NAT to work correctly in this configuration, one of two
# approaches can be taken:
#
# 1. Define a CONTINUE policy with smc as the SOURCE zone (preferred):
#
# #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
# smc $FW CONTINUE
# loc net ACCEPT
# net all DROP info
# # THE FOLLOWING POLICY MUST BE LAST
# all all REJECT info
#
# 2. Set IMPLICIT_CONTINUE=Yes in shorewall.conf(5).
#
###############################################################################
#EXTERNAL INTERFACE INTERNAL ALLINTS LOCAL
shorewall6-5.2.3.4/configfiles/snat 0000664 0000000 0000000 00000000641 13531060406 015630 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/snat
#
# For information about entries in this file, type "man shorewall6-snat"
#
# See http://shorewall.net/manpages6/shorewall6-snat.html for more information
#
###########################################################################################################################################
#ACTION SOURCE DEST PROTO PORT IPSEC MARK USER SWITCH ORIGDEST PROBABILITY
shorewall6-5.2.3.4/configfiles/scfilter 0000664 0000000 0000000 00000000461 13531060406 016476 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/scfilter
#
# Replace the 'cat' command below to filter the output of
# 'show connections'.
#
# See http://shorewall.net/shorewall_extension_scripts.htm for additional
# information.
#
###############################################################################
cat -
shorewall6-5.2.3.4/configfiles/restored 0000664 0000000 0000000 00000000502 13531060406 016506 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/restored
#
# Add commands below that you want to be executed after shorewall6 has
# completed a 'restore' command.
#
# See http://shorewall.net/shorewall_extension_scripts.htm for additional
# information.
#
###############################################################################
shorewall6-5.2.3.4/configfiles/interfaces.annotated 0000664 0000000 0000000 00000060574 13531077641 021006 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/interfaces
#
# For information about entries in this file, type "man shorewall6-interfaces"
#
# The manpage is also online at
# http://www.shorewall.net/manpages6/shorewall6-interfaces.html
#
?FORMAT 2
###############################################################################
#
# The interfaces file serves to define the firewall's network interfaces to
# Shorewall. The order of entries in this file is not significant in determining
# zone composition.
#
# Beginning with Shorewall 4.5.3, the interfaces file supports two different
# formats:
#
# FORMAT 1 (default - deprecated)
#
# There is a BROADCAST column which can be used to specify the broadcast
# address associated with the interface.
#
# FORMAT 2
#
# The BROADCAST column is omitted.
#
# The format is specified by a line as follows:
#
# ?FORMAT {1|2}
#
# The columns in the file are as follows.
#
# ZONE - zone-name
#
# Zone for this interface. Must match the name of a zone declared in /etc/
# shorewall/zones. You may not list the firewall zone in this column.
#
# If the interface serves multiple zones that will be defined in the
# shorewall-hosts(5) file, you should place "-" in this column.
#
# If there are multiple interfaces to the same zone, you must list them in
# separate entries.
#
# Example:
#
# #ZONE INTERFACE BROADCAST
# loc eth1 -
# loc eth2 -
#
# INTERFACE - interface[:port]
#
# Logical name of interface. Each interface may be listed only once in this
# file. You may NOT specify the name of a "virtual" interface (e.g., eth0:0)
# here; see http://www.shorewall.net/FAQ.htm#faq18. If the physical option is
# not specified, then the logical name is also the name of the actual
# interface.
#
# You may use wildcards here by specifying a prefix followed by the plus sign
# ("+"). For example, if you want to make an entry that applies to all PPP
# interfaces, use 'ppp+'; that would match ppp0, ppp1, ppp2, …
#
# When using Shorewall versions before 4.1.4, care must be exercised when
# using wildcards where there is another zone that uses a matching specific
# interface. See shorewall-nesting(5) for a discussion of this problem.
#
# Shorewall allows '+' as an interface name, but that usage is deprecated. A
# better approach is to specify 'physical=+' in the OPTIONS column (see
# below).
#
# There is no need to define the loopback interface (lo) in this file.
#
# If a port is given, then the interface must have been defined previously
# with the bridge option. The OPTIONS column may not contain the following
# options when a port is given.
#
# arp_filter
# arp_ignore
# bridge
# log_martians
# mss
# optional
# proxyarp
# required
# routefilter
# sourceroute
# upnp
# wait
#
# Beginning with Shorewall 4.5.17, if you specify a zone for the 'lo'
# interface, then that zone must be defined as type local in shorewall6-zones
# (5).
#
# BROADCAST (Optional) - {-|detect|address[,address]...}
#
# Only available if FORMAT 1.
#
# If you use the special value detect, Shorewall will detect the broadcast
# address(es) for you if your iptables and kernel include Address Type Match
# support.
#
# If your iptables and/or kernel lack Address Type Match support then you may
# list the broadcast address(es) for the network(s) to which the interface
# belongs. For P-T-P interfaces, this column is left blank. If the interface
# has multiple addresses on multiple subnets then list the broadcast
# addresses as a comma-separated list.
#
# If you don't want to give a value for this column but you want to enter a
# value in the OPTIONS column, enter - in this column.
#
# OPTIONS (Optional) - [option[,option]...]
#
# A comma-separated list of options from the following list. The order in
# which you list the options is not significant but the list should have no
# embedded white-space.
#
# accept_ra[={0|1|2}]
#
# IPv6 only; added in Shorewall 4.5.16. Values are:
#
# 0
#
# Do not accept Router Advertisements.
#
# 1
#
# Accept Route Advertisements if forwarding is disabled.
#
# 2
#
# Overrule forwarding behavior. Accept Route Advertisements even if
# forwarding is enabled.
#
# If the option is specified without a value, then the value 1 is
# assumed.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# arp_filter[={0|1}]
#
# IPv4 only. If specified, this interface will only respond to ARP
# who-has requests for IP addresses configured on the interface. If not
# specified, the interface can respond to ARP who-has requests for IP
# addresses on any of the firewall's interface. The interface must be up
# when Shorewall is started.
#
# Only those interfaces with the arp_filter option will have their
# setting changed; the value assigned to the setting will be the value
# specified (if any) or 1 if no value is given.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# arp_ignore[=number]
#
# IPv4 only. If specified, this interface will respond to arp requests
# based on the value of number (defaults to 1).
#
# 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 the sender's IP address is part from same
# subnet on this interface's address
#
# 3 - do not reply for local addresses configured with scope host, only
# resolutions for global and link
#
# 4-7 - reserved
#
# 8 - do not reply for all local addresses
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# Warning
#
# Do not specify arp_ignore for any interface involved in Proxy ARP.
#
# blacklist
#
# Checks packets arriving on this interface against the
# shorewall-blacklist(5) file.
#
# Beginning with Shorewall 4.4.13:
#
# ☆ If a zone is given in the ZONES column, then the behavior is as if
# blacklist had been specified in the IN_OPTIONS column of
# shorewall-zones(5).
#
# ☆ Otherwise, the option is ignored with a warning:
#
# WARNING: The 'blacklist' option is ignored on multi-zone
# interfaces
#
# bridge
#
# Designates the interface as a bridge. Beginning with Shorewall 4.4.7,
# setting this option also sets routeback.
#
# Note
#
# If you have a bridge that you don't intend to define bport zones on,
# then it is best to omit this option and simply specify routeback.
#
# dbl={none|src|dst|src-dst}
#
# Added in Shorewall 5.0.10. This option defined whether or not dynamic
# blacklisting is applied to packets entering the firewall through this
# interface and whether the source address and/or destination address is
# to be compared against the ipset-based dynamic blacklist
# (DYNAMIC_BLACKLIST=ipset... in shorewall.conf(5)). The default is
# determine by the setting of DYNAMIC_BLACKLIST:
#
# DYNAMIC_BLACKLIST=No
#
# Default is none (e.g., no dynamic blacklist checking).
#
# DYNAMIC_BLACKLIST=Yes
#
# Default is src (e.g., the source IP address is checked).
#
# DYNAMIC_BLACKLIST=ipset[-only]
#
# Default is src.
#
# DYNAMIC_BLACKLIST=ipset[-only],src-dst...
#
# Default is src-dst (e.g., the source IP addresses in checked
# against the ipset on input and the destination IP address is
# checked against the ipset on packets originating from the firewall
# and leaving through this interface).
#
# The normal setting for this option will be dst or none for internal
# interfaces and src or src-dst for Internet-facing interfaces.
#
# destonly
#
# Added in Shorewall 4.5.17. Causes the compiler to omit rules to handle
# traffic from this interface.
#
# dhcp
#
# Specify this option when any of the following are true:
#
# 1. the interface gets its IP address via DHCP
#
# 2. the interface is used by a DHCP server running on the firewall
#
# 3. the interface has a static IP but is on a LAN segment with lots of
# DHCP clients.
#
# 4. the interface is a simple bridge with a DHCP server on one port and
# DHCP clients on another port.
#
# Note
#
# If you use Shorewall-perl for firewall/bridging, then you need to
# include DHCP-specific rules in shorewall-rules(5). DHCP uses UDP
# ports 67 and 68.
#
# This option allows DHCP datagrams to enter and leave the interface.
#
# forward[={0|1}]
#
# IPv6 only Sets the /proc/sys/net/ipv6/conf/interface/forwarding option
# to the specified value. If no value is supplied, then 1 is assumed.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# ignore[=1]
#
# When specified, causes the generated script to ignore up/down events
# from Shorewall-init for this device. Additionally, the option exempts
# the interface from hairpin filtering. When '=1' is omitted, the ZONE
# column must contain '-' and ignore must be the only OPTION.
#
# Beginning with Shorewall 4.5.5, may be specified as 'ignore=1' which
# only causes the generated script to ignore up/down events from
# Shorewall-init; hairpin filtering is still applied. In this case, the
# above restrictions on the ZONE and OPTIONS columns are lifted.
#
# loopback
#
# Added in Shorewall 4.6.6. Designates the interface as the loopback
# interface. This option is assumed if the interface's physical name is
# 'lo'. Only one interface man have the loopback option specified.
#
# logmartians[={0|1}]
#
# IPv4 only. Turn on kernel martian logging (logging of packets with
# impossible source addresses. It is strongly suggested that if you set
# routefilter on an interface that you also set logmartians. Even if you
# do not specify the routefilter option, it is a good idea to specify
# logmartians because your distribution may have enabled route filtering
# without you knowing it.
#
# Only those interfaces with the logmartians option will have their
# setting changed; the value assigned to the setting will be the value
# specified (if any) or 1 if no value is given.
#
# To find out if route filtering is set on a given interface, check the
# contents of /proc/sys/net/ipv4/conf/interface/rp_filter - a non-zero
# value indicates that route filtering is enabled.
#
# Example:
#
# teastep@lists:~$ cat /proc/sys/net/ipv4/conf/eth0/rp_filter
# 1
# teastep@lists:~$
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# This option may also be enabled globally in the shorewall.conf(5)
# file.
#
# maclist
#
# Connection requests from this interface are compared against the
# contents of shorewall-maclist(5). If this option is specified, the
# interface must be an Ethernet NIC and must be up before Shorewall is
# started.
#
# mss=number
#
# Added in Shorewall 4.0.3. Causes forwarded TCP SYN packets entering or
# leaving on this interface to have their MSS field set to the specified
# number.
#
# nets=(net[,...])
#
# Limit the zone named in the ZONE column to only the listed networks.
# The parentheses may be omitted if only a single net is given (e.g.,
# nets=192.168.1.0/24). Limited broadcast to the zone is supported.
# Beginning with Shorewall 4.4.1, multicast traffic to the zone is also
# supported.
#
# nets=dynamic
#
# Defines the zone as dynamic. Requires ipset match support in your
# iptables and kernel. See http://www.shorewall.net/Dynamic.html for
# further information.
#
# nodbl
#
# Added in Shorewall 5.0.8. When specified, dynamic blacklisting is
# disabled on the interface. Beginning with Shorewall 5.0.10, nodbl is
# equivalent to dbl=none.
#
# nosmurfs
#
# IPv4 only. Filter packets for smurfs (packets with a broadcast address
# as the source).
#
# Smurfs will be optionally logged based on the setting of
# SMURF_LOG_LEVEL in shorewall.conf(5). After logging, the packets are
# dropped.
#
# optional
#
# When optional is specified for an interface, Shorewall will be silent
# when:
#
# ☆ a /proc/sys/net/ipv[46]/conf/ entry for the interface cannot be
# modified (including for proxy ARP or proxy NDP).
#
# ☆ The first address of the interface cannot be obtained.
#
# May not be specified with required.
#
# physical=name
#
# Added in Shorewall 4.4.4. When specified, the interface or port name in
# the INTERFACE column is a logical name that refers to the name given in
# this option. It is useful when you want to specify the same wildcard
# port name on two or more bridges. See http://www.shorewall.net/
# bridge-Shorewall-perl.html#Multiple.
#
# If the interface name is a wildcard name (ends with '+'), then the
# physical name must also end in '+'. The physical name may end in '+'
# (or be exactly '+') when the interface name is not a wildcard name.
#
# If physical is not specified, then it's value defaults to the interface
# name.
#
# proxyarp[={0|1}]
#
# IPv4 only. Sets /proc/sys/net/ipv4/conf/interface/proxy_arp. Do NOT use
# this option if you are employing Proxy ARP through entries in
# shorewall-proxyarp(5). This option is intended solely for use with
# Proxy ARP sub-networking as described at: http://tldp.org/HOWTO/
# Proxy-ARP-Subnet/index.html.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# Only those interfaces with the proxyarp option will have their setting
# changed; the value assigned to the setting will be the value specified
# (if any) or 1 if no value is given.
#
# proxyndp[={0|1}]
#
# IPv6 only. Sets /proc/sys/net/ipv6/conf/interface/proxy_ndp.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# Only those interfaces with the proxyndp option will have their setting
# changed; the value assigned to the setting will be the value specified
# (if any) or 1 if no value is given.
#
# required
#
# Added in Shorewall 4.4.10. If this option is set, the firewall will
# fail to start if the interface is not usable. May not be specified
# together with optional.
#
# routeback[={0|1}]
#
# If specified, indicates that Shorewall should include rules that allow
# traffic arriving on this interface to be routed back out that same
# interface. This option is also required when you have used a wildcard
# in the INTERFACE column if you want to allow traffic between the
# interfaces that match the wildcard.
#
# Beginning with Shorewall 4.4.20, if you specify this option, then you
# should also specify either sfilter (see below) or routefilter on all
# interfaces (see below).
#
# Beginning with Shorewall 4.5.18, you may specify this option to
# explicitly reset (e.g., routeback=0). This can be used to override
# Shorewall's default setting for bridge devices which is routeback=1.
#
# routefilter[={0|1|2}]
#
# IPv4 only. Turn on kernel route filtering for this interface
# (anti-spoofing measure).
#
# Only those interfaces with the routefilter option will have their
# setting changes; the value assigned to the setting will be the value
# specified (if any) or 1 if no value is given.
#
# The value 2 is only available with Shorewall 4.4.5.1 and later when the
# kernel version is 2.6.31 or later. It specifies a loose form of reverse
# path filtering.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# This option can also be enabled globally via the ROUTE_FILTER option in
# the shorewall.conf(5) file.
#
# Important
#
# If ROUTE_FILTER=Yes in shorewall.conf(5), or if your distribution sets
# net.ipv4.conf.all.rp_filter=1 in /etc/sysctl.conf, then setting
# routefilter=0 in an interface entry will not disable route filtering on
# that interface! The effective setting for an interface is the maximum
# of the contents of /proc/sys/net/ipv4/conf/all/rp_filter and the
# routefilter setting specified in this file (/proc/sys/net/ipv4/conf/
# interface/rp_filter).
#
# Note
#
# There are certain cases where routefilter cannot be used on an
# interface:
#
# ☆ If USE_DEFAULT_RT=Yes in shorewall.conf(5) and the interface is
# listed in shorewall-providers(5).
#
# ☆ If there is an entry for the interface in shorewall-providers(5)
# that doesn't specify the balance option.
#
# ☆ If IPSEC is used to allow a road-warrior to have a local address,
# then any interface through which the road-warrior might connect
# cannot specify routefilter.
#
# Beginning with Shorewall 5.1.1, when routefilter is set to a non-zero
# value, the logmartians option is also implicitly set. If you actually
# want route filtering without logging, then you must also specify
# logmartians=0 after routefilter.
#
# rpfilter
#
# Added in Shorewall 4.5.7. This is an anti-spoofing measure that
# requires the 'RPFilter Match' capability in your iptables and kernel.
# It provides a more efficient alternative to the sfilter option below.
# It performs a function similar to routefilter (see above) but works
# with Multi-ISP configurations that do not use balanced routes.
#
# sfilter=(net[,...])
#
# Added in Shorewall 4.4.20. This option provides an anti-spoofing
# alternative to routefilter on interfaces where that option cannot be
# used, but where the routeback option is required (on a bridge, for
# example). On these interfaces, sfilter should list those local networks
# that are connected to the firewall through other interfaces.
#
# sourceroute[={0|1}]
#
# If this option is not specified for an interface, then source-routed
# packets will not be accepted from that interface unless it has been
# explicitly enabled via sysconf. Only set this option to 1 (enable
# source routing) if you know what you are doing. This might represent a
# security risk and is usually unneeded.
#
# Only those interfaces with the sourceroute option will have their
# setting changed; the value assigned to the setting will be the value
# specified (if any) or 1 if no value is given.
#
# Note
#
# This option does not work with a wild-card physical name (e.g.,
# eth0.+). Beginning with Shorewall 5.1.10, If this option is specified,
# a warning is issued and the option is ignored.
#
# tcpflags[={0|1}]
#
# Packets arriving on this interface are checked for certain illegal
# combinations of TCP flags. Packets found to have such a combination of
# flags are handled according to the setting of TCP_FLAGS_DISPOSITION
# after having been logged according to the setting of
# TCP_FLAGS_LOG_LEVEL.
#
# Beginning with Shorewall 4.6.0, tcpflags=1 is the default. To disable
# this option, specify tcpflags=0.
#
# unmanaged
#
# Added in Shorewall 4.5.18. Causes all traffic between the firewall and
# hosts on the interface to be accepted. When this option is given:
#
# ☆ The ZONE column must contain '-'.
#
# ☆ Only the following other options are allowed with unmanaged:
#
# arp_filter
# arp_ignore
# ignore
# routefilter
# optional
# physical
# routefilter
# proxyarp
# proxyudp
# sourceroute
#
# upnp
#
# Incoming requests from this interface may be remapped via UPNP (upnpd).
# See http://www.shorewall.net/UPnP.html. Supported in IPv4 and in IPv6
# in Shorewall 5.1.4 and later.
#
# upnpclient
#
# This option is intended for laptop users who always run Shorewall on
# their system yet need to run UPnP-enabled client apps such as
# Transmission (BitTorrent client). The option causes Shorewall to detect
# the default gateway through the interface and to accept UDP packets
# from that gateway. Note that, like all aspects of UPnP, this is a
# security hole so use this option at your own risk. Supported in IPv4
# and in IPv6 in Shorewall 5.1.4 and later.
#
# wait=seconds
#
# Added in Shorewall 4.4.10. Causes the generated script to wait up to
# seconds seconds for the interface to become usable before applying the
# required or optional options.
#
# Example
#
# IPv4 Example 1:
#
# Suppose you have eth0 connected to a DSL modem and eth1 connected to your
# local network and that your local subnet is 192.168.1.0/24. The interface
# gets its IP address via DHCP from subnet 206.191.149.192/27. You have a DMZ
# with subnet 192.168.2.0/24 using eth2. Your iptables and/or kernel do not
# support "Address Type Match" and you prefer to specify broadcast addresses
# explicitly rather than having Shorewall detect them.
#
# Your entries for this setup would look like:
#
# ?FORMAT 1
# #ZONE INTERFACE BROADCAST OPTIONS
# net eth0 206.191.149.223 dhcp
# loc eth1 192.168.1.255
# dmz eth2 192.168.2.255
#
# Example 2:
#
# The same configuration without specifying broadcast addresses is:
#
# ?FORMAT 2
# #ZONE INTERFACE OPTIONS
# net eth0 dhcp
# loc eth1
# dmz eth2
#
# Example 3:
#
# You have a simple dial-in system with no Ethernet connections.
#
# ?FORMAT 2
# #ZONE INTERFACE OPTIONS
# net ppp0 -
#
# Example 4 (Shorewall 4.4.9 and later):
#
# You have a bridge with no IP address and you want to allow traffic through
# the bridge.
#
# ?FORMAT 2
# #ZONE INTERFACE OPTIONS
# - br0 bridge
#
###############################################################################
#ZONE INTERFACE OPTIONS
shorewall6-5.2.3.4/configfiles/routes 0000664 0000000 0000000 00000000475 13531060406 016211 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/routes
#
# For information about entries in this file, type "man shorewall6-routes"
#
# For additional information, see http://www.shorewall.net/MultiISP.html
#
###############################################################################
#PROVIDER DEST GATEWAY DEVICE OPTIONS
shorewall6-5.2.3.4/configfiles/providers.annotated 0000664 0000000 0000000 00000032544 13531077645 020700 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/providers
#
# For information about entries in this file, type "man shorewall6-providers"
#
# For additional information, see http://shorewall.net/MultiISP.html
#
############################################################################################
#
# This file is used to define additional routing tables. You will want to define
# an additional table if:
#
# • You have connections to more than one ISP or multiple connections to the
# same ISP
#
# • You run Squid as a transparent proxy on a host other than the firewall.
#
# • You have other requirements for policy routing.
#
# Each entry in the file defines a single routing table.
#
# If you wish to omit a column entry but want to include an entry in the next
# column, use "-" for the omitted entry.
#
# The columns in the file are as follows.
#
# NAME - name
#
# The provider name. Must be a valid shell variable name. The names 'local',
# 'main', 'default' and 'unspec' are reserved and may not be used as provider
# names.
#
# NUMBER - number
#
# The provider number -- a number between 1 and 15. Each provider must be
# assigned a unique value.
#
# MARK (Optional) - value
#
# A FWMARK value used in your shorewall-mangle(5) file to direct packets to
# this provider.
#
# If PROVIDER_OFFSET is non-zero in shorewall.conf(5), then the value must be
# a multiple of 2^^PROVIDER_OFFSET. In all cases, the number of significant
# bits may not exceed PROVIDER_OFFSET + PROVIDER_BITS.
#
# DUPLICATE - routing-table-name
#
# The name of an existing table to duplicate to create this routing table.
# May be main or the name of a previously listed provider. You may select
# only certain entries from the table to copy by using the COPY column below.
# This column should contain a dash ("-') when USE_DEFAULT_RT=Yes in
# shorewall.conf(5).
#
# INTERFACE - interface[:address]
#
# The name of the network interface to the provider. Must be listed in
# shorewall-interfaces(5). In general, that interface should not have the
# proxyarp or proxyndp option specified unless loose is given in the OPTIONS
# column of this entry.
#
# Important
#
# For IPv6, if the interface is an Ethernet device and an IP address is
# supplied, it should be the upstream router's link-level address, not its
# global address.
#
# Where more than one provider is serviced through a single interface, the
# interface must be followed by a colon and the IP address of the interface
# that is supplied by the associated provider.
#
# GATEWAY - {-|address[,mac]|detect|none}
#
# The IP address of the provider's gateway router. Beginning with Shorewall
# 4.6.2, you may also specify the MAC address of the gateway when there are
# multiple providers serviced through the same interface. When the MAC is not
# specified, Shorewall will detect the MAC during firewall start or restart.
#
# You can enter detect here and Shorewall will attempt to detect the gateway
# automatically.
#
# Beginning with Shorewall 5.0.6, you may also enter none. This causes
# creation of a routing table with no default route in it.
#
# For PPP devices, you may omit this column.
#
# OPTIONS (Optional) - [-|option[,option]...]
#
# A comma-separated list selected from the following. The order of the
# options is not significant but the list may contain no embedded
# white-space.
#
# autosrc
#
# Added in Shorewall 4.5.17. Causes a host route to the provider's
# gateway router to be added to the provider's routing table. This is the
# default behavior unless overridden by a following noautosrc option.
#
# track
#
# If specified, inbound connections on this interface are to be tracked
# so that responses may be routed back out this same interface.
#
# You want to specify track if internet hosts will be connecting to local
# servers through this provider.
#
# Beginning with Shorewall 4.4.3, track defaults to the setting of the
# TRACK_PROVIDERS option in shorewall.conf (5). If you set
# TRACK_PROVIDERS=Yes and want to override that setting for an individual
# provider, then specify notrack (see below).
#
# balance[=weight]
#
# The providers that have balance specified will get outbound traffic
# load-balanced among them. By default, all interfaces with balance
# specified will have the same weight (1). You can change the weight of
# an interface by specifying balance=weight where weight is the weight of
# the route out of this interface.
#
# Prior to Shorewall 5.1.1, when USE_DEFAULT_RT=Yes, balance=1 is assumed
# unless the fallback, loose, load or tproxy option is specified.
# Beginning with Shorewall 5.1.1, when BALANCE_PROVIDERS=Yes, balance=1
# is assumed unless the fallback, loose, load or tproxy option is
# specified.I
#
# Caution
#
# In IPV6, the balance option does not cause balanced default routes to
# be created; it rather causes a sequence of default routes with
# different metrics to be created.
#
# loose
#
# Shorewall normally adds a routing rule for each IP address on an
# interface which forces traffic whose source is that IP address to be
# sent using the routing table for that interface. Setting loose prevents
# creation of such rules on this interface.
#
# load=probability
#
# Added in Shorewall 4.6.0. This option provides an alternative method of
# load balancing based on probabilities. Providers to be balanced are
# given a probability (a number 0 > n >= 1) with up to 8 digits to the
# right of the decimal point. Beginning with Shorewall 4.6.10, a warning
# is issued if the sum of the probabilities is not 1.00000000.
#
# noautosrc
#
# Added in Shorewall 4.5.17. Prevents the addition of a host route to the
# provider's gateway router from being added to the provider's routing
# table. This option must be used with caution as it can cause start and
# restart failures.
#
# notrack
#
# Added in Shorewall 4.4.3. When specified, turns off track.
#
# optional (deprecated for use with providers that do not share an interface)
#
# If the interface named in the INTERFACE column is not up and configured
# with an IPv4 address then ignore this provider. If not specified, the
# value of the optional option for the INTERFACE in shorewall-interfaces
# (5) is assumed. Use of that option is preferred to this one, unless an
# address is provider in the INTERFACE column.
#
# primary
#
# Added in Shorewall 4.6.6, primary is equivalent to balance=1 and is
# preferred when the remaining providers specify fallback or tproxy.
#
# src=source-address
#
# Specifies the source address to use when routing to this provider and
# none is known (the local client has bound to the 0 address). May not be
# specified when an address is given in the INTERFACE column. If this
# option is not used, Shorewall substitutes the primary IP address on the
# interface named in the INTERFACE column.
#
# mtu=number
#
# Specifies the MTU when forwarding through this provider. If not given,
# the MTU of the interface named in the INTERFACE column is assumed.
#
# fallback[=weight]
#
# Indicates that a default route through the provider should be added to
# the default routing table (table 253). If a weight is given, a balanced
# route is added with the weight of this provider equal to the specified
# weight. If the option is given without a weight, an separate default
# route is added through the provider's gateway; the route has a metric
# equal to the provider's NUMBER.
#
# Prior to Shorewall 4.4.24, the option is ignored with a warning message
# if USE_DEFAULT_RT=Yes in shorewall.conf.
#
# Caution
#
# In IPV6, specifying the fallback option on multiple providers does not
# cause balanced fallback routes to be created; it rather causes a
# sequence of fallback routes with different metrics to be created.
#
# tproxy
#
# Added in Shorewall 4.5.4. Used for supporting the TPROXY action in
# shorewall-mangle(5). See http://www.shorewall.net/
# Shorewall_Squid_Usage.html. When specified, the MARK, DUPLICATE and
# GATEWAY columns should be empty, INTERFACE should be set to 'lo' and
# tproxy should be the only OPTION. Only one tproxy provider is allowed.
#
# hostroute
#
# Added in Shorewall 4.5.21. This is the default behavior that results in
# a host route to the defined GATEWAY being inserted into the main
# routing table and into the provider's routing table. hostroute is
# required for older distributions but nohostroute (below) is appropriate
# for recent distributions. hostroute may interfere with Zebra's ability
# to add routes on some distributions such as Debian 7. This option
# defaults to on when BALANCE_PROVIDERS=Yes, in shorewall.conf(5).
#
# nohostroute
#
# Added in Shorewall 4.5.21. nohostroute inhibits addition of a host
# route to the defined GATEWAY being inserted into the main routing table
# and into the provider's routing table. nohostroute is not appropriate
# for older distributions but is appropriate for recent distributions.
# nohostroute allows Zebra's to correctly add routes on some
# distributions such as Debian 7. This option defaults to off when
# BALANCE_PROVIDERS=Yes, in shorewall.conf(5).
#
# persistent
#
# Added in Shorewall 5.0.2 and alters the behavior of the disable
# command:
#
# ☆ The provider's routing table still contains the apprioriate default
# route.
#
# ☆ Unless the noautosrc option is specified, routing rules are
# generated to route traffic from the interfaces address(es) out of
# the provider's routing table.
#
# ☆ Persistent routing rules in shorewall-rtrules(5) are present.
#
# Note
#
# The generated script will attempt to reenable a disabled persistent
# provider during execution of the start, restart and reload commands.
# When persistent is not specified, only the enable and reenable commands
# can reenable the provider.
#
# Important
#
# RESTORE_DEFAULT_ROUTE=Yes in shorewall[6].conf is not recommended when
# the persistent option is used, as restoring default routes to the main
# routing table can prevent link status monitors such as foolsm from
# correctly detecting non-working providers.
#
# COPY - [{none|interface[,interface]...}]
#
# A comma-separated list of other interfaces on your firewall. Wildcards
# specified using an asterisk ("*") are permitted (e.g., tun* ). Usually used
# only when DUPLICATE is main. Only copy routes through INTERFACE and through
# interfaces listed here. If you only wish to copy routes through INTERFACE,
# enter none in this column.
#
# Beginning with Shorewall 4.5.17, blackhole, unreachable and prohibit routes
# are no longer copied by default but may be copied by including blackhole,
# unreachable and prohibit respectively in the COPY list.
#
# Examples
#
# IPv4 Example 1:
#
# You run squid in your DMZ on IP address 192.168.2.99. Your DMZ interface is
# eth2
#
# #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS
# Squid 1 1 - eth2 192.168.2.99 -
#
# IPv4 Example 2:
#
# eth0 connects to ISP 1. The IP address of eth0 is 206.124.146.176 and the
# ISP's gateway router has IP address 206.124.146.254.
#
# eth1 connects to ISP 2. The IP address of eth1 is 130.252.99.27 and the
# ISP's gateway router has IP address 130.252.99.254.
#
# eth2 connects to a local network.
#
# #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY
# ISP1 1 1 main eth0 206.124.146.254 track,balance eth2
# ISP2 2 2 main eth1 130.252.99.254 track,balance eth2
#
# IPv6 Example 1:
#
# You run squid in your DMZ on IP address 2002:ce7c:92b4:1::2. Your DMZ
# interface is eth2
#
# #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS
# Squid 1 1 - eth2 2002:ce7c:92b4:1::2 -
#
# IPv6 Example 2:
#
# eth0 connects to ISP 1. The ISP's gateway router has IP address
# 2001:ce7c:92b4:1::2.
#
# eth1 connects to ISP 2. The ISP's gateway router has IP address
# 2001:d64c:83c9:12::8b.
#
# eth2 connects to a local network.
#
# #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY
# ISP1 1 1 main eth0 2001:ce7c:92b4:1::2 track eth2
# ISP2 2 2 main eth1 2001:d64c:83c9:12::8b track eth2
#
############################################################################################
#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY
shorewall6-5.2.3.4/configfiles/actions.annotated 0000664 0000000 0000000 00000013530 13531077637 020316 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/actions
#
# For information about entries in this file, type "man shorewall6-actions"
#
# Please see http://shorewall.net/Actions.html for additional information.
#
# Place '# ' below the 'C' in COMMENT followed by a comment describing
# the action.
#
###############################################################################
#
# This file allows you to define new ACTIONS for use in rules (see
# shorewall-rules(5)). You define the iptables rules to be performed in an ACTION
# in /etc/shorewall/action.action-name.
#
# Columns are:
#
# NAME
#
# The name of the action. ACTION names should begin with an upper-case letter
# to distinguish them from Shorewall-generated chain names and be composed of
# letters, digits or numbers. If you intend to log from the action then the
# name must be no longer than 11 characters in length if you use the standard
# LOGFORMAT.
#
# OPTIONS
#
# Added in Shorewall 4.5.10. Available options are:
#
# audit
#
# Added in Shorewall 5.0.7. When this option is specified, the action is
# expected to have at least two parameters; the first is a target and the
# second is either 'audit' or omitted. If the second is 'audit', then the
# first must be an auditable target (ACCEPT, DROP or REJECT).
#
# builtin
#
# Added in Shorewall 4.5.16. Defines the action as a rule target that is
# supported by your iptables but is not directly supported by Shorewall.
# The action may be used as the rule target in an INLINE rule in
# shorewall-rules(5).
#
# Beginning with Shorewall 4.6.0, the Netfilter table(s) in which the
# builtin can be used may be specified: filter, nat, mangle and raw. If
# no table name(s) are given, then filter is assumed. The table names
# follow builtin and are separated by commas; for example, "FOOBAR
# builtin,filter,mangle" would specify FOOBAR as a builtin target that
# can be used in the filter and mangle tables.
#
# Beginning with Shorewall 4.6.4, you may specify the terminating option
# with builtin to indicate to the Shorewall optimizer that the action is
# terminating (the current packet will not be passed to the next rule in
# the chain).
#
# inline
#
# Causes the action body (defined in action.action-name) to be expanded
# in-line like a macro rather than in its own chain. You can list
# Shorewall Standard Actions in this file to specify the inline option.
#
# Caution
#
# Some of the Shorewall standard actions cannot be used in-line and will
# generate a warning and the compiler will ignore inline if you try to
# use them that way:
#
# DropSmurfs
# IfEvent
# Invalid (Prior to Shorewall 4.5.13)
# NotSyn (Prior to Shorewall 4.5.13)
# RST (Prior to Shorewall 4.5.13)
# TCPFlags
#
# logjump
#
# Added in Shorewall 5.0.8. Performs the same function as nolog (below),
# with the addition that the jump to the actions chain is logged if a log
# level is specified on the action invocation. For inline actions, this
# option is identical to nolog.
#
# mangle
#
# Added in Shorewall 5.0.7. Specifies that this action is to be used in
# shorewall-mangle(5) rather than shorewall-rules(5).
#
# nat
#
# Added in Shorewall 5.0.13. Specifies that this action is to be used in
# shorewall-snat(5) rather than shorewall-rules(5). The mangle and nat
# options are mutually exclusive.
#
# noinline
#
# Causes any later inline option for the same action to be ignored with a
# warning.
#
# nolog
#
# Added in Shorewall 4.5.11. When this option is specified, the compiler
# does not automatically apply the log level and/or tag from the
# invocation of the action to all rules inside of the action. Rather, it
# simply sets the $_loglevel and $_logtag shell variables which can be
# used within the action body to apply those logging options only to a
# subset of the rules.
#
# proto=protocol
#
# Added in Shorewall 5.1.10. Specifies that the action is only usable
# with the specified protocol (name or number). When the action is
# invoked with no protocol specified in the PROTO column, or if the
# action is used as a Policy Action, the named protocol will be assumed.
# If a protocol is specified in the PROTO column of an invocation, then
# it must match the named protocol.
#
# The proto option has no effect if the inline or builtin option is
# specified. A warning is issued if proto is specified along with
# builtin.
#
# section
#
# Added in Shorewall 5.1.1. When specified, this option causes the rules
# file section name and a comma to be prepended to the parameters passed
# to the action (if any). Note that this means that the first parameter
# passed to the action by the user is actually the second parameter to
# the action. If the action is invoked out of the blrules file,
# 'BLACKLIST' is used as the section name.
#
# Given that neither the snat nor the mangle file is sectioned, this
# parameter has no effect when mangle or nat is specified.
#
# state={UNTRACKED|NEW|ESTABLISHED|RELATED|INVALID}
#
# Added in Shorewall 5.0.7. Reserved for use by Shorewall in actions.std.
#
# terminating
#
# Added in Shorewall 4.6.4. When used with builtin, indicates that the
# built-in action is termiating (i.e., if the action is jumped to, the
# next rule in the chain is not evaluated).
#
###############################################################################
#ACTION OPTIONS COMMENT
shorewall6-5.2.3.4/configfiles/policy.annotated 0000664 0000000 0000000 00000024662 13531077644 020163 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/policy
#
# For information about entries in this file, type "man shorewall6-policy"
#
# The manpage is also online at
# http://www.shorewall.net/manpages6/shorewall6-policy.html
#
###############################################################################
#
# This file defines the high-level policy for connections between zones defined
# in shorewall-zones(5).
#
# Important
#
# The order of entries in this file is important
#
# This file determines what to do with a new connection request if we don't get a
# match from the shorewall-blrules(5) or shorewall-rules(5) files. For each
# source/destination pair, the file is processed in order until a match is found
# ("all" will match any source or destination).
#
# Important
#
# Intra-zone policies are pre-defined
#
# For $FW and for all of the zones defined in shorewall-zones(5), the POLICY for
# connections from the zone to itself is ACCEPT (with no logging or TCP
# connection rate limiting) but may be overridden by an entry in this file. The
# overriding entry must be explicit (specifying the zone name in both SOURCE and
# DEST) or it must use "all+" (Shorewall 4.5.17 or later).
#
# Similarly, if you have IMPLICIT_CONTINUE=Yes in shorewall.conf(5), then the
# implicit policy to/from any sub-zone is CONTINUE. These implicit CONTINUE
# policies may also be overridden by an explicit entry in this file.
#
# The columns in the file are as follows (where the column name is followed by a
# different name in parentheses, the different name is used in the alternate
# specification syntax).
#
# SOURCE - zone[,...[+]]|$FW|all[+][!ezone[,...]]
#
# Source zone. Must be the name of a zone defined in shorewall-zones(5), $FW,
# "all" or "all+".
#
# Support for all+ was added in Shorewall 4.5.17. all does not override the
# implicit intra-zone ACCEPT policy while all+ does.
#
# Beginning with Shorewall 5.0.12, multiple zones may be listed separated by
# commas. As above, if '+' is specified after two or more zone names, then
# the policy overrides the implicit intra-zone ACCEPT policy if the same zone
# appears in both the SOURCE and DEST columns.
#
# Beginning with Shorewall 5.2.3, a comma-separated list of excluded zones
# preceded by "!" may follow all or all+.
#
# DEST - zone[,...[+]]|$FW|all[+][!ezone[,...]]
#
# Destination zone. Must be the name of a zone defined in shorewall-zones(5),
# $FW, "all" or "all+". If the DEST is a bport zone, then the SOURCE must be
# "all", "all+", another bport zone associated with the same bridge, or it
# must be an ipv4 zone that is associated with only the same bridge.
#
# Support for "all+" was added in Shorewall 4.5.17. "all" does not override
# the implicit intra-zone ACCEPT policy while "all+" does.
#
# Beginning with Shorewall 5.0.12, multiple zones may be listed separated by
# commas. As above, if '+' is specified after two or more zone names, then
# the policy overrides the implicit intra-zone ACCEPT policy if the same zone
# appears in both the SOURCE and DEST columns.
#
# Beginning with Shorewall 5.2.3, a comma-separated list of excluded zones
# preceded by "!" may follow all or all+.
#
# POLICY - {ACCEPT|DROP|REJECT|BLACKLIST|CONTINUE|QUEUE|NFQUEUE[(queuenumber1[:
# queuenumber2])]|NONE}[:{[+]policy-action[:level][,...]|None}]
#
# Policy if no match from the rules file is found.
#
# If the policy is neither CONTINUE nor NONE then the policy may be followed
# by ":" and one of the following:
#
# a. The word "None" or "none". This causes any default action defined in
# shorewall.conf(5) to be omitted for this policy.
#
# b. The name of an action with optional parameters enclosed in parentheses.
# The action will be invoked before the policy is enforced.
#
# Actions can have parameters specified.
#
# Beginning with Shorewall 4.5.10, the action name can be followed optionally
# by a colon and a log level. The level will be applied to each rule in the
# action or body that does not already have a log level.
#
# Beginning with Shorewall 5.1.2, multiple action[:level] specification may
# be listeded, separated by commas. The actions are invoked in the order
# listed. Also beginning with Shorewall 5.1.2, the policy-action list can be
# prefixed with a plus sign ("+") indicating that the listed actions are in
# addition to those listed in the related _DEFAULT setting in shorewall.conf
# (5).
#
# Possible policies are:
#
# ACCEPT
#
# Accept the connection.
#
# DROP
#
# Ignore the connection request.
#
# REJECT
#
# For TCP, send RST. For all other, send an "unreachable" ICMP.
#
# BLACKLIST
#
# Added in Shorewall 5.1.1 and requires that the DYNAMIC_BLACKLIST
# setting in shorewall.conf(5) specifies ipset-based dynamic
# blacklisting. The SOURCE IP address is added to the blacklist ipset and
# the connection request is ignored.
#
# QUEUE
#
# Queue the request for a user-space application such as Snort-inline.
#
# NFQUEUE
#
# Queue the request for a user-space application using the
# nfnetlink_queue mechanism. If a queuenumber1 is not given, queue zero
# (0) is assumed. Beginning with Shorewall 4.6.10, a second queue number
# (queuenumber2) may be given. This specifies a range of queues to use.
# Packets are then balanced across the given queues. This is useful for
# multicore systems: start multiple instances of the userspace program on
# queues x, x+1, .. x+n and use "x:x+n". Packets belonging to the same
# connection are put into the same nfqueue.
#
# CONTINUE
#
# Pass the connection request past any other rules that it might also
# match (where the source or destination zone in those rules is a
# superset of the SOURCE or DEST in this policy). See shorewall-nesting
# (5) for additional information.
#
# NONE
#
# Assume that there will never be any packets from this SOURCE to this
# DEST. Shorewall will not create any infrastructure to handle such
# packets and you may not have any rules with this SOURCE and DEST in the
# /etc/shorewall/rules file. If such a packet is received, the result is
# undefined. NONE may not be used if the SOURCE or DEST columns contain
# the firewall zone ($FW) or "all".
#
# LOGLEVEL (loglevel) - [log-level|ULOG|NFLOG]
#
# Optional - if supplied, each connection handled under the default POLICY is
# logged at that level. If not supplied, no log message is generated. See
# syslog.conf(5) for a description of log levels.
#
# You may also specify ULOG or NFLOG (must be in upper case). This will log
# to the ULOG or NFLOG target and will send to a separate log through use of
# ulogd (http://www.netfilter.org/projects/ulogd/index.html).
#
# For a description of logging, see shorewall-logging(5).
#
# If you don't want to log but need to specify the following column, place
# "-" here.
#
# RATE (rate) - [-|limit]
#
# where limit is one of:
#
# [-|[{s|d}[/vlsm]:[[name][(ht-buckets,ht-max)]:]]]rate/{sec|min|hour|day}[:
# burst]
# [name1:]rate1/{sec|min|hour|day}[:burst1],[name2:]rate2/{sec|min|hour|day}
# [:burst2]
#
# If passed, specifies the maximum TCP connection rate and the size of an
# acceptable burst. If not specified, TCP connections are not limited. If the
# burst parameter is omitted, a value of 5 is assumed.
#
# When s: or d: is specified, the rate applies per source IP address or per
# destination IP address respectively. The name may be chosen by the user and
# specifies a hash table to be used to count matching connections. If not
# give, the name shorewall is assumed. Where more than one POLICY or rule
# specifies the same name, the connections counts for the policies are
# aggregated and the individual rates apply to the aggregated count.
# Beginning with Shorewall 5.2.1, the s or d may be followed by a slash ("/")
# and an integer vlsm. When a vlsm is specified, all source or destination
# addresses encountered will be grouped according to the given prefix length
# and the so-created subnet will be subject to the rate limit.
#
# Beginning with Shorewall 4.6.5, two limits may be specified, separated by a
# comma. In this case, the first limit (name1, rate1, burst1) specifies the
# per-source IP limit and the second limit specifies the per-destination IP
# limit.
#
# Example: client:10/sec:20,:60/sec:100
#
# Beginning with Shorewall 5.2.1, the table name, if any, may be followed by
# two integers separated by commas and enclosed in parentheses. The first
# integer (ht-buckets) specifies the number of buckets in the generated hash
# table. The second integer (ht-max) specifies the maximum number of entries
# in the hash table.
#
# Example: s:client(1024,65536):10/sec
#
# CONNLIMIT - limit[:mask]
#
# May be used to limit the number of simultaneous connections from each
# individual host to limit connections. While the limit is only checked on
# connections to which this policy could apply, the number of current
# connections is calculated over all current connections from the SOURCE
# host. By default, the limit is applied to each host individually but can be
# made to apply to networks of hosts by specifying a mask. The mask specifies
# the width of a VLSM mask to be applied to the source address; the number of
# current connections is then taken over all hosts in the subnet
# source-address/mask.
#
# Example
#
# a. All connections from the local network to the internet are allowed
#
# b. All connections from the internet are ignored but logged at syslog level
# KERNEL.INFO.
#
# c. All other connection requests are rejected and logged at level KERNEL.INFO.
#
# #SOURCE DEST POLICY LOG BURST:LIMIT
# # LEVEL
# loc net ACCEPT
# net all DROP info
# #
# # THE FOLLOWING POLICY MUST BE LAST
# #
# all all REJECT info
#
###############################################################################
#SOURCE DEST POLICY LOGLEVEL RATE CONNLIMIT
shorewall6-5.2.3.4/configfiles/blrules 0000664 0000000 0000000 00000000732 13531060406 016334 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/blrules
#
# For information about entries in this file, type "man shorewall6-blrules"
#
# Please see http://shorewall.net/blacklisting_support.htm for additional
# information.
#
##############################################################################################################################################################
#ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST RATE USER MARK CONNLIMIT TIME HEADERS SWITCH HELPER
shorewall6-5.2.3.4/configfiles/tcinterfaces 0000664 0000000 0000000 00000000531 13531060406 017333 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/tcinterfaces
#
# For information about entries in this file,
# type "man shorewall6-tcinterfaces"
#
# See http://shorewall.net/simple_traffic_shaping.htm for additional
# information.
#
###############################################################################
#INTERFACE TYPE IN_BANDWIDTH OUT_BANDWIDTH
shorewall6-5.2.3.4/configfiles/tcinterfaces.annotated 0000664 0000000 0000000 00000007451 13531077653 021333 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/tcinterfaces
#
# For information about entries in this file,
# type "man shorewall6-tcinterfaces"
#
# See http://shorewall.net/simple_traffic_shaping.htm for additional
# information.
#
###############################################################################
#
# This file lists the interfaces that are subject to simple traffic shaping.
# Simple traffic shaping is enabled by setting TC_ENABLED=Simple in
# shorewall.conf(5).
#
# A note on the bandwidth definition used in this file:
#
# • don't use a space between the integer value and the unit: 30kbit is valid
# while 30 kbit is not.
#
# • you can use one of the following units:
#
# kbps
#
# Kilobytes per second.
#
# mbps
#
# Megabytes per second.
#
# kbit
#
# Kilobits per second.
#
# mbit
#
# Megabits per second.
#
# bps or number
#
# Bytes per second.
#
# k or kb
#
# Kilo bytes.
#
# m or mb
#
# Megabytes.
#
# • Only whole integers are allowed.
#
# The columns in the file are as follows (where the column name is followed by a
# different name in parentheses, the different name is used in the alternate
# specification syntax).
#
# INTERFACE
#
# The logical name of an interface. If you run both IPv4 and IPv6 Shorewall
# firewalls, a given interface should only be listed in one of the two
# configurations.
#
# TYPE - [external|internal]
#
# Optional. If given specifies whether the interface is external (facing
# toward the Internet) or internal (facing toward a local network) and
# enables SFQ flow classification.
#
# IN-BANDWIDTH (in_bandwidth) - {-|bandwidth[:burst]|~bandwidth[:interval:
# decay_interval]}
#
# The incoming bandwidth of that interface. Please note that you are not able
# to do traffic shaping on incoming traffic, as the traffic is already
# received before you could do so. But this allows you to define the maximum
# traffic allowed for this interface in total, if the rate is exceeded, the
# packets are dropped. You want this mainly if you have a DSL or Cable
# connection to avoid queuing at your providers side.
#
# If you don't want any traffic to be dropped, set this to a value to zero in
# which case Shorewall will not create an ingress qdisc.Must be set to zero
# if the REDIRECTED INTERFACES column is non-empty.
#
# The optional burst option was added in Shorewall 4.4.18. The default burst
# is 10kb. A larger burst can help make the bandwidth more accurate; often
# for fast lines, the enforced rate is well below the specified bandwidth.
#
# What is described above creates a rate/burst policing filter. Beginning
# with Shorewall 4.4.25, a rate-estimated policing filter may be configured
# instead. Rate-estimated filters should be used with Ethernet adapters that
# have Generic Receive Offload enabled by default. See Shorewall FAQ 97a.
#
# To create a rate-estimated filter, precede the bandwidth with a tilde
# ("~"). The optional interval and decay_interval determine how often the
# rate is estimated and how many samples are retained for estimating. Please
# see http://ace-host.stuart.id.au/russell/files/tc/doc/estimators.txt for
# details. If not specified, the default interval is 250ms and the default
# decay_interval is 4sec.
#
# OUT-BANDWIDTH (out_bandwidth) - [rate[:[burst][:[latency][:[peek][:[minburst
# ]]]]]]
#
# Added in Shorewall 4.4.13. The terms are defined in tc-tbf(8).
#
# Shorewall provides defaults as follows:
#
# burst - 10kb
# latency - 200ms
#
# The remaining options are defaulted by tc(8).
#
###############################################################################
#INTERFACE TYPE IN_BANDWIDTH OUT_BANDWIDTH
shorewall6-5.2.3.4/configfiles/disabled 0000664 0000000 0000000 00000000607 13531060406 016434 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/disabled
#
# Add commands below that you want executed when an optional
# interface is successfully disabled using the 'disable' command
#
# When the commands are invoked:
#
# $1 contains the physical name of the interface
# $2 contains the logical name of the interface
# $3 contains the name of the provider associated with the interface,
if any
shorewall6-5.2.3.4/configfiles/lib.private 0000664 0000000 0000000 00000000576 13531060406 017111 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/lib.private
#
# Use this file to declare shell functions to be called in the other
# run-time extension scripts. The file will be copied into the generated
# firewall script.
#
# See http://shorewall.net/shorewall_extension_scripts.htm for additional
# information.
#
###############################################################################
shorewall6-5.2.3.4/configfiles/rules.annotated 0000664 0000000 0000000 00000162522 13531077647 020017 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/rules
#
# For information on the settings in this file, type "man shorewall6-rules"
#
# The manpage is also online at
# http://www.shorewall.net/manpages6/shorewall6-rules.html
#
##############################################################################################################################################################
#
# Entries in this file govern connection establishment by defining exceptions to
# the policies laid out in shorewall-policy(5). By default, subsequent requests
# and responses are automatically allowed using connection tracking. For any
# particular (source,dest) pair of zones, the rules are evaluated in the order in
# which they appear in this file and the first terminating match is the one that
# determines the disposition of the request. All rules are terminating except LOG
# and COUNT rules.
#
# Warning
#
# If you masquerade or use SNAT from a local system to the internet, you cannot
# use an ACCEPT rule to allow traffic from the internet to that system. You must
# use a DNAT rule instead.
#
# The rules file is divided into sections. Each section is introduced by a
# "Section Header" which is a line beginning with ?SECTION and followed by the
# section name.
#
# Sections are as follows and must appear in the order listed:
#
# ALL
#
# This section was added in Shorewall 4.4.23. Rules in this section are
# applied, regardless of the connection tracking state of the packet and are
# applied before rules in the other sections.
#
# ESTABLISHED
#
# Packets in the ESTABLISHED state are processed by rules in this section.
#
# The only ACTIONs allowed in this section are ACCEPT, DROP, REJECT, LOG,
# NFLOG, NFQUEUE and QUEUE
#
# There is an implicit ACCEPT rule inserted at the end of this section.
#
# RELATED
#
# Packets in the RELATED state are processed by rules in this section.
#
# The only ACTIONs allowed in this section are ACCEPT, DROP, REJECT, LOG,
# NFLOG, NFQUEUE and QUEUE
#
# There is an implicit rule added at the end of this section that invokes the
# RELATED_DISPOSITION (shorewall.conf(5)).
#
# INVALID
#
# Added in Shorewall 4.5.13. Packets in the INVALID state are processed by
# rules in this section.
#
# The only Actions allowed in this section are ACCEPT, DROP, REJECT, LOG,
# NFLOG, NFQUEUE and QUEUE.
#
# There is an implicit rule added at the end of this section that invokes the
# INVALID_DISPOSITION (shorewall.conf(5)).
#
# UNTRACKED
#
# Added in Shorewall 4.5.13. Packets in the UNTRACKED state are processed by
# rules in this section.
#
# The only Actions allowed in this section are ACCEPT, DROP, REJECT, LOG,
# NFLOG, NFQUEUE and QUEUE.
#
# There is an implicit rule added at the end of this section that invokes the
# UNTRACKED_DISPOSITION (shorewall.conf(5)).
#
# NEW
#
# Packets in the NEW state are processed by rules in this section. If the
# INVALID and/or UNTRACKED sections are empty or not included, then the
# packets in the corresponding state(s) are also processed in this section.
#
# Note
#
# If you are not familiar with Netfilter to the point where you are comfortable
# with the differences between the various connection tracking states, then it is
# suggested that you place all of your rules in the NEW section (That's after the
# line that reads ?SECTION NEW').
#
# Warning
#
# If you specify FASTACCEPT=Yes in shorewall.conf(5) then the ALL, ESTABLISHED
# and RELATED sections must be empty.
#
# An exception is made if you are running Shorewall 4.4.27 or later and you have
# specified a non-default value for RELATED_DISPOSITION or RELATED_LOG_LEVEL. In
# that case, you may have rules in the RELATED section of this file.
#
# You may omit any section that you don't need. If no Section Headers appear in
# the file then all rules are assumed to be in the NEW section.
#
# When defining rules that rewrite the destination IP address and/or port number
# (namely DNAT and REDIRECT rules), it is important to keep straight which
# columns in the file specify the packet before rewriting and which specify how
# the packet will look after rewriting.
#
# • The DEST column specifies the final destination for the packet after
# rewriting and can include the final IP address and/or port number.
#
# • The remaining columns specify characteristics of the packet before
# rewriting. In particular, the ORIGDEST column gives the original
# destination IP address of the packet and the DPORT column give the original
# destination port(s).
#
# The columns in the file are as follows (where the column name is followed by a
# different name in parentheses, the different name is used in the alternate
# specification syntax).
#
# ACTION - target[:{log-level|none}[!][:tag]]
#
# Specifies the action to be taken if the connection request matches the
# rule. target must be one of the following.
#
# ACCEPT
#
# Allow the connection request.
#
# ACCEPT+
#
# like ACCEPT but also excludes the connection from any subsequent
# matching DNAT[-] or REDIRECT[-] rules. Use with IPv6 requires Shorewall
# 4.5.14 or later.
#
# ACCEPT!
#
# like ACCEPT but exempts the rule from being suppressed by OPTIMIZE=1 in
# shorewall.conf(5).
#
# action
#
# The name of an action declared in shorewall-actions(5) or in /usr/share
# /shorewall[6]/actions.std.
#
# ADD(ipset:flags[:timeout])
#
# Added in Shorewall 4.4.12. Causes addresses and/or port numbers to be
# added to the named ipset. The flags specify the address or tuple to be
# added to the set and must match the type of ipset involved. For
# example, for an iphash ipset, either the SOURCE or DESTINATION address
# can be added using flags src or dst respectively (see the -A command in
# ipset (8)).
#
# Beginning with Shorewall 5.0.3, an optional timeout can be specified.
# This is the number of seconds that the new entry in the ipset is to
# remain valid and overrides any timeout specified when the ipset was
# created.
#
# ADD is non-terminating. Even if a packet matches the rule, it is passed
# on to the next rule.
#
# AUDIT[(accept|drop|reject)]
#
# Added in Shorewall 4.5.10. Audits the packet with the specified type;
# if the type is omitted, then drop is assumed. Require AUDIT_TARGET
# support in the kernel and iptables.
#
# A_ACCEPT, A_ACCEPT+ and A_ACCEPT!
#
# Added in Shorewall 4.4.20. Audited versions of ACCEPT, ACCEPT+ and
# ACCEPT! respectively. Require AUDIT_TARGET support in the kernel and
# iptables. A_ACCEPT+ with IPv6 requires Shorewall 4.5.14 or later.
#
# A_DROP and A_DROP!
#
# Added in Shorewall 4.4.20. Audited versions of DROP and DROP!
# respectively. Require AUDIT_TARGET support in the kernel and iptables.
#
# A_REJECT AND A_REJECT!
#
# Added in Shorewall 4.4.20. Audited versions of REJECT and REJECT!
# respectively. Require AUDIT_TARGET support in the kernel and iptables.
#
# ?COMMENT
#
# the rest of the line will be attached as a comment to the Netfilter
# rule(s) generated by the following entries. The comment will appear
# delimited by "/* ... */" in the output of "shorewall show ". To
# stop the comment from being attached to further rules, simply include ?
# COMMENT on a line by itself.
#
# CONMARK({mark})
#
# Added in Shorewall 5.0.7, CONNMARK is identical to MARK with the
# exception that the mark is assigned to connection to which the packet
# belongs is marked rather than to the packet itself.
#
# CONTINUE
#
# For experts only.
#
# Do not process any of the following rules for this (source
# zone,destination zone). If the source and/or destination IP address
# falls into a zone defined later in shorewall-zones(5) or in a parent
# zone of the source or destination zones, then this connection request
# will be passed to the rules defined for that (those) zone(s). See
# shorewall-nesting(5) for additional information.
#
# CONTINUE!
#
# like CONTINUE but exempts the rule from being suppressed by OPTIMIZE=1
# in shorewall.conf(5).
#
# COUNT
#
# Simply increment the rule's packet and byte count and pass the packet
# to the next rule.
#
# DEL(ipset:flags)
#
# Added in Shorewall 4.4.12. Causes an entry to be deleted from the named
# ipset. The flags specify the address or tuple to be deleted from the
# set and must match the type of ipset involved. For example, for an
# iphash ipset, either the SOURCE or DESTINATION address can be deleted
# using flags src or dst respectively (see the -D command in ipset (8)).
#
# DEL is non-terminating. Even if a packet matches the rule, it is passed
# on to the next rule.
#
# DNAT
#
# Forward the request to another system (and optionally another port).
# Use with IPv6 requires Shorewall 4.5.14 or later.
#
# DNAT-
#
# Advanced users only.
#
# Like DNAT but only generates the DNAT iptables rule and not the
# companion ACCEPT rule. Use with IPv6 requires Shorewall 4.5.14 or
# later.
#
# DROP
#
# Ignore the request.
#
# DROP!
#
# like DROP but exempts the rule from being suppressed by OPTIMIZE=1 in
# shorewall.conf(5).
#
# HELPER
#
# Added in Shorewall 4.5.7. This action requires that the HELPER column
# contains the name of the Netfilter helper to be associated with
# connections matching this connection. May only be specified in the NEW
# section and is useful for being able to specify a helper when the
# applicable policy is ACCEPT. No destination zone should be specified in
# HELPER rules.
#
# INLINE[(action)]
#
# Added in Shorewall 4.5.16. This action allows you to construct most of
# the rule yourself using iptables syntax. The part that you specify must
# follow two semicolons (';;') and is completely free-form. If the target
# of the rule (the part following 'j') is something that Shorewall
# supports in the ACTION column, then you may enclose it in parentheses
# (e.g., INLINE(ACCEPT)). Otherwise, you can include it after the
# semicolon(s). In this case, you must declare the target as a builtin
# action in shorewall-actions(5).
#
# Some considerations when using INLINE:
#
# ☆ The p, s, d, i, o, policy, and state match (state or conntrack
# --ctstate) matches will always appear in the front of the rule in
# that order.
#
# ☆ When multiple matches are specified, the compiler will keep them in
# the order in which they appear (excluding the above listed ones),
# but they will not necessarily be at the end of the generated rule.
# For example, if addresses are specified in the SOURCE and/or DEST
# columns, their generated matches will appear after those specified
# using ';;' or ';'.
#
# IPTABLES({iptables-target [option ...])
#
# IPv4 only. This action allows you to specify an iptables target with
# options (e.g., 'IPTABLES(MARK --set-xmark 0x01/0xff)'. If the
# iptables-target is not one recognized by Shorewall, the following error
# message will be issued:
#
# ERROR: Unknown target (iptables-target)
#
# This error message may be eliminated by adding the iptables-target as a
# builtin action in shorewall-actions(5).
#
# Important
#
# If you specify REJECT as the iptables-target, the target of the rule
# will be the iptables REJECT target and not Shorewall's builtin 'reject'
# chain which is used when REJECT (see below) is specified as the target
# in the ACTION column.
#
# IP6TABLES({ip6tables-target [option ...])
#
# IPv6 only. This action allows you to specify an ip6tables target with
# options (e.g., 'IPTABLES(MARK --set-xmark 0x01/0xff)'. If the
# ip6tables-target is not one recognized by Shorewall, the following
# error message will be issued:
#
# ERROR: Unknown target (ip6tables-target)
#
# This error message may be eliminated by adding the ip6tables-target as
# a builtin action in shorewall-actions(5).
#
# Important
#
# If you specify REJECT as the ip6tables-target, the target of the rule
# will be the i6ptables REJECT target and not Shorewall's builtin
# 'reject' chain which is used when REJECT (see below) is specified as
# the target in the ACTION column.
#
# LOG:level
#
# Simply log the packet and continue with the next rule.
#
# macro[(macrotarget)]
#
# The name of a macro defined in a file named macro.macro. If the macro
# accepts an action parameter (Look at the macro source to see if it has
# PARAM in the TARGET column) then the macro name is followed by the
# parenthesized macrotarget (ACCEPT, DROP, REJECT, ...) to be substituted
# for the parameter.
#
# Example: FTP(ACCEPT).
#
# The older syntax where the macro name and the target are separated by a
# slash (e.g. FTP/ACCEPT) is still allowed but is deprecated.
#
# MARK({mark})
#
# where mark is a packet mark value.
#
# Added in Shorewall 5.0.7, MARK requires "Mark in filter table" support
# in your kernel and iptables.
#
# Normally will set the mark value of the current packet. If preceded by
# a vertical bar ("|"), the mark value will be logically ORed with the
# current mark value to produce a new mark value. If preceded by an
# ampersand ("&"), will be logically ANDed with the current mark value to
# produce a new mark value.
#
# Both "|" and "&" require Extended MARK Target support in your kernel
# and iptables.
#
# The mark value may be optionally followed by "/" and a mask value (used
# to determine those bits of the connection mark to actually be set).
# When a mask is specified, the result of logically ANDing the mark value
# with the mask must be the same as the mark value.
#
# NFLOG[(nflog-parameters)]
#
# Added in Shorewall 4.5.9.3. Queues matching packets to a back end
# logging daemon via a netlink socket then continues to the next rule.
# See http://www.shorewall.net/shorewall_logging.html.
#
# The nflog-parameters are a comma-separated list of up to 3 numbers:
#
# ☆ The first number specifies the netlink group (0-65535). If omitted
# (e.g., NFLOG(,0,10)) then a value of 0 is assumed.
#
# ☆ The second number specifies the maximum number of bytes to copy. If
# omitted, 0 (no limit) is assumed.
#
# ☆ The third number specifies the number of log messages that should
# be buffered in the kernel before they are sent to user space. The
# default is 1.
#
# NFLOG is similar to LOG:NFLOG[(nflog-parameters)], except that the log
# level is not changed when this ACTION is used in an action or macro
# body and the invocation of that action or macro specifies a log level.
#
# NFQUEUE[([queuenumber1[:queuenumber2[c]][,bypass]]|bypass)]
#
# Queues the packet to a user-space application using the nfnetlink_queue
# mechanism. If a queuenumber1 is not specified, queue zero (0) is
# assumed. Beginning with Shorewall 4.6.10, the keyword bypass can be
# given. By default, if no userspace program is listening on an NFQUEUE,
# then all packets that are to be queued are dropped. When this option is
# used, the NFQUEUE rule behaves like ACCEPT instead. Also beginning in
# Shorewall 4.6.10, a second queue number (queuenumber2) may be
# specified. This specifies a range of queues to use. Packets are then
# balanced across the given queues. This is useful for multicore systems:
# start multiple instances of the userspace program on queues x, x+1, ..
# x+n and use "x:x+n". Packets belonging to the same connection are put
# into the same nfqueue.
#
# Beginning with Shorewall 5.1.0, queuenumber2 may be followed by the
# letter 'c' to indicate that the CPU ID will be used as an index to map
# packets to the queues. The idea is that you can improve performance if
# there's a queue per CPU. Requires the NFQUEUE CPU Fanout capability in
# your kernel and iptables.
#
# NFQUEUE![([queuenumber1[:queuenumber2[c]][,bypass]]|bypass)]
#
# like NFQUEUE but exempts the rule from being suppressed by OPTIMIZE=1
# in shorewall.conf(5).
#
# NONAT
#
# Excludes the connection from any subsequent DNAT[-] or REDIRECT[-]
# rules but doesn't generate a rule to accept the traffic. Use with IPv6
# requires Shorewall 4.5.14 or later.
#
# QUEUE
#
# Queue the packet to a user-space application such as ftwall (http://
# p2pwall.sf.net). The application may reinsert the packet for further
# processing.
#
# QUEUE!
#
# like QUEUE but exempts the rule from being suppressed by OPTIMIZE=1 in
# shorewall.conf(5).
#
# REJECT[(option)]
#
# disallow the request and return an icmp-unreachable or an RST packet.
# If no option is passed, Shorewall selects the appropriate option based
# on the protocol of the packet.
#
# Beginning with Shorewall 5.0.8, the type of reject may be specified in
# the option paramater. Valid IPv4 option values are:
#
# icmp-net-unreachable
# icmp-host-unreachable
# icmp-port-unreachable
# icmp-proto-unreachable
# icmp-net-prohibited
# icmp-host-prohibited
# icmp-admin-prohibited
# icmp-tcp-reset (the PROTO column must specify TCP). Beginning with
# Shorewall 5.1.3, this option may also be specified as tcp-reset.
#
# Valid IPv6 option values are:
#
# icmp6-no-route
# no-route
# icmp6-adm-prohibited
# adm-prohibited
# icmp6-addr-unreachable
# addr-unreach
# icmp6-port-unreachable
# tcp-reset (the PROTO column must specify TCP)
#
# REJECT!
#
# like REJECT but exempts the rule from being suppressed by OPTIMIZE=1 in
# shorewall.conf(5).
#
# REDIRECT
#
# Redirect the request to a server running on the firewall. Use with IPv6
# requires Shorewall 4.5.14 or later.
#
# REDIRECT-
#
# Advanced users only.
#
# Like REDIRECT but only generates the REDIRECT iptables rule and not the
# companion ACCEPT rule. Use with IPv6 requires Shorewall 4.5.14 or
# later.
#
# TARPIT [(tarpit | honeypot | reset)]
#
# Added in Shorewall 4.6.6.
#
# TARPIT captures and holds incoming TCP connections using no local
# per-connection resources.
#
# TARPIT only works with the PROTO column set to tcp (6), and is totally
# application agnostic. This module will answer a TCP request and play
# along like a listening server, but aside from sending an ACK or RST, no
# data is sent. Incoming packets are ignored and dropped. The attacker
# will terminate the session eventually. This module allows the initial
# packets of an attack to be captured by other software for inspection.
# In most cases this is sufficient to determine the nature of the attack.
#
# This offers similar functionality to LaBrea
#
# where number is the SPI of the SA used to encrypt/decrypt packets.
#
# proto=ah|esp|ipcomp
#
# IPSEC Encapsulation Protocol
#
# mss=number
#
# sets the MSS field in TCP packets
#
# mode=transport|tunnel
#
# IPSEC mode
#
# 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
#
# yes or ipsec
#
# When used by itself, causes all traffic that will be encrypted/
# encapsulated or has been decrypted/un-encapsulated to match the rule.
#
# no or none
#
# When used by itself, causes all traffic that will not be encrypted/
# encapsulated or has been decrypted/un-encapsulated to match the rule.
#
# in
#
# May only be used in the FORWARD section and must be the first or the
# only item the list. Indicates that matching packets have been decrypted
# in input.
#
# out
#
# May only be used in the FORWARD section and must be the first or the
# only item in the list. Indicates that matching packets will be
# encrypted on output.
#
# If this column is non-empty and sections are not used, then:
#
# □ A chain NAME appearing in the ACTION column must be a chain branched
# either directly or indirectly from the accipsecin or accipsecout chain.
#
# □ The CHAIN column must contain either accipsecin or accipsecout or a
# chain branched either directly or indirectly from those chains.
#
# □ These rules will NOT appear in the accounting chain.
#
# In all of the above columns except ACTION and CHAIN, the values -, any and all
# may be used as wildcard'gs. Omitted trailing columns are also treated as
# wildcard'g.
#
###############################################################################################################
#ACTION CHAIN SOURCE DEST PROTO DPORT SPORT USER MARK IPSEC HEADERS
shorewall6-5.2.3.4/configfiles/tcdevices.annotated 0000664 0000000 0000000 00000014576 13531077652 020637 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/tcdevices
#
# For information about entries in this file, type "man shorewall6-tcdevices"
#
# See http://shorewall.net/traffic_shaping.htm for additional information.
#
###############################################################################
#
# Entries in this file define the bandwidth for interfaces on which you want
# traffic shaping to be enabled.
#
# If you do not plan to use traffic shaping for a device, don't put it in here as
# it limits the throughput of that device to the limits you set here.
#
# A note on the bandwidth definitions used in this file:
#
# • don't use a space between the integer value and the unit: 30kbit is valid
# while 30 kbit is not.
#
# • you can use one of the following units:
#
# kbps
#
# Kilobytes per second.
#
# mbps
#
# Megabytes per second.
#
# kbit
#
# Kilobits per second.
#
# mbit
#
# Megabits per second.
#
# bps or number
#
# Bytes per second.
#
# • Only whole integers are allowed.
#
# The columns in the file are as follows (where the column name is followed by a
# different name in parentheses, the different name is used in the alternate
# specification syntax).
#
# INTERFACE - [number:]interface
#
# Name of interface. Each interface may be listed only once in this file. You
# may NOT specify the name of an alias (e.g., eth0:0) here; see http://
# www.shorewall.net/FAQ.htm#faq18
#
# You may NOT specify wildcards here, e.g. if you have multiple ppp
# interfaces, you need to put them all in here!
#
# If the device doesn't exist, a warning message will be issued during
# "shorewall [re]start" and "shorewall reload" and traffic shaping
# configuration will be skipped for that device.
#
# Shorewall assigns a sequential interface number to each interface (the
# first entry in the file is interface 1, the second is interface 2 and so
# on) You can explicitly specify the interface number by prefixing the
# interface name with the number and a colon (":"). Example: 1:eth0.
#
# IN-BANDWIDTH (in_bandwidth) - {-|bandwidth[:burst]|~bandwidth[:interval:
# decay_interval]}
#
# The incoming bandwidth of that interface. Please note that you are not able
# to do traffic shaping on incoming traffic, as the traffic is already
# received before you could do so. But this allows you to define the maximum
# traffic allowed for this interface in total, if the rate is exceeded, the
# packets are dropped. You want this mainly if you have a DSL or Cable
# connection to avoid queuing at your providers side.
#
# If you don't want any traffic to be dropped, set this to a value to zero in
# which case Shorewall will not create an ingress qdisc.Must be set to zero
# if the REDIRECTED INTERFACES column is non-empty.
#
# The optional burst option was added in Shorewall 4.4.18. The default burst
# is 10kb. A larger burst can help make the bandwidth more accurate; often
# for fast lines, the enforced rate is well below the specified bandwidth.
#
# What is described above creates a rate/burst policing filter. Beginning
# with Shorewall 4.4.25, a rate-estimated policing filter may be configured
# instead. Rate-estimated filters should be used with Ethernet adapters that
# have Generic Receive Offload enabled by default. See Shorewall FAQ 97a.
#
# To create a rate-estimated filter, precede the bandwidth with a tilde
# ("~"). The optional interval and decay_interval determine how often the
# rate is estimated and how many samples are retained for estimating. Please
# see http://ace-host.stuart.id.au/russell/files/tc/doc/estimators.txt for
# details. If not specified, the default interval is 250ms and the default
# decay_interval is 4sec.
#
# OUT-BANDWIDTH (out_bandwidth) - bandwidth
#
# The outgoing bandwidth of that interface. This is the maximum speed your
# connection can handle. It is also the speed you can refer as "full" if you
# define the tc classes in shorewall-tcclasses(5). Outgoing traffic above
# this rate will be dropped.
#
# OPTIONS - {-|{classify|htb|hfsc|linklayer={ethernet|atm|adsl}|tsize=tsize|mtu=
# mtu|mpu=mpu|overhead=overhead} ,...}
#
# classify ― When specified, Shorewall will not generate tc or Netfilter
# rules to classify traffic based on packet marks. You must do all
# classification using CLASSIFY rules in shorewall-mangle(5).
#
# htb - Use the Hierarchical Token Bucket queuing discipline. This is the
# default.
#
# hfsc - Shorewall normally uses the Hierarchical Token Bucket queuing
# discipline. When hfsc is specified, the Hierarchical Fair Service Curves
# discipline is used instead (see tc-hfsc (7)).
#
# linklayer - Added in Shorewall 4.5.6. Type of link (ethernet, atm, adsl).
# When specified, causes scheduler packet size manipulation as described in
# tc-stab (8). When this option is given, the following options may also be
# given after it:
#
# mtu=mtu - The device MTU; default 2048 (will be rounded up to a power
# of two)
#
# mpu=mpubytes - Minimum packet size used in calculations. Smaller
# packets will be rounded up to this size
#
# tsize=tablesize - Size table entries; default is 512
#
# overhead=overheadbytes - Number of overhead bytes per packet.
#
# REDIRECTED INTERFACES (redirect)- [interface[,interface]...]
#
# May only be specified if the interface in the INTERFACE column is an
# Intermediate Frame Block (IFB) device. Causes packets that enter each
# listed interface to be passed through the egress filters defined for this
# device, thus providing a form of incoming traffic shaping. When this column
# is non-empty, the classify option is assumed.
#
# Examples
#
# Example 1:
#
# Suppose you are using PPP over Ethernet (DSL) and ppp0 is the interface for
# this. The device has an outgoing bandwidth of 500kbit and an incoming
# bandwidth of 6000kbit
#
# #INTERFACE IN-BANDWIDTH OUT-BANDWIDTH OPTIONS REDIRECTED
# # INTERFACES
# 1:ppp0 6000kbit 500kbit
#
###############################################################################
#INTERFACE IN_BANDWITH OUT_BANDWIDTH OPTIONS REDIRECT
shorewall6-5.2.3.4/configfiles/init.annotated 0000664 0000000 0000000 00000006141 13531077641 017614 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/init
#
# Add commands below that you want to be executed at the beginning of
# a "shorewall6 start" or "shorewall6 restart" command.
#
# For additional information, see
# http://shorewall.net/shorewall_extension_scripts.htm
#
###############################################################################
#
# Shorewall-init is an optional package (added in Shorewall 4.4.10) that can be
# installed along with Shorewall, Shorewall6, Shorewall-lite and/or
# Shorewall6-lite. It provides two key features:
#
# 1. It can close (stop) the firewall during boot prior to starting the network.
# This can prevent unwanted connections from being accepted after the network
# comes up but before the firewall is started.
#
# 2. It can interface with your distribution's ifup/ifdown scripts and/or
# NetworkManager to allow firewall actions when an interface starts or stops.
#
# These two capabilities can be enabled separately.
#
# After you install the shorewall-init package, you can activate it by modifying
# the Shorewall-init configuration file:
#
# • On Debian-based system, the file is /etc/default/shorewall-init.
#
# • On other systems, the file is /etc/sysconfig/shorewall-init.
#
# To activate the safe boot feature, edit the configuration file and set PRODUCTS
# to a space-separated list of Shorewall products that you want to be closed
# before networking starts.
#
# Example:
#
# PRODUCTS="shorewall shorewall6"
#
# You also must insure that the compiled scripts for the listed products are
# compiled using Shorewall 4.4.10 or later.
#
# Shorewall
#
# shorewall compile
#
# Shorewall6
#
# shorewall6 compile
#
# Shorewall-lite
#
# On the administrative system, enter the command shorewall export firewall
# from the firewall's configuration directory.
#
# Shorewall6-lite
#
# On the administrative system, enter the command shorewall6 export firewall
# from the firewall's configuration directory.
#
# The second feature (ifup/ifdown and NetworkManager integration) should only be
# activated on systems that do not use a link status monitor line swping or LSM.
#
# • Edit the configuration file and set IFUPDOWN=1
#
# For NetworkManager integration, you will want to disable firewall startup at
# boot and delay it to when your interface comes up. For this to work correctly,
# you must set the required or the optional option on at least one interface
# then:
#
# • On Debian-based systems, edit /etc/default/product for each product listed
# in the PRODUCTS setting and set startup=0.
#
# • On other systems, use the distribution's service control tool (insserv,
# chkconfig, etc.) to disable startup of the products listed in the PRODUCTS
# setting.
#
# On a laptop with both Ethernet and wireless interfaces, you will want to make
# both interfaces optional and set the REQUIRE_INTERFACE option to Yes in
# shorewall.conf (5) or shorewall6.conf (5). This causes the firewall to remain
# stopped until at least one of the interfaces comes up.
#
###############################################################################
shorewall6-5.2.3.4/configfiles/policy 0000664 0000000 0000000 00000000524 13531060406 016162 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/policy
#
# For information about entries in this file, type "man shorewall6-policy"
#
# The manpage is also online at
# http://www.shorewall.net/manpages6/shorewall6-policy.html
#
###############################################################################
#SOURCE DEST POLICY LOGLEVEL RATE CONNLIMIT
shorewall6-5.2.3.4/configfiles/mangle.annotated 0000664 0000000 0000000 00000122230 13531077642 020113 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/mangle
#
# For information about entries in this file, type "man shorewall6-mangle"
#
# See http://shorewall.net/traffic_shaping.htm for additional information.
# For usage in selecting among multiple ISPs, see
# http://shorewall.net/MultiISP.html
#
# See http://shorewall.net/PacketMarking.html for a detailed description of
# the Netfilter/Shorewall packet marking mechanism.
#
######################################################################################################################################################################
#
# This file was introduced in Shorewall 4.6.0 and replaces shorewall-tcrules(5).
# This file is only processed by the compiler if:
#
# Entries in this file cause packets to be marked as a means of classifying them
# for traffic control or policy routing.
#
# Important
#
# Unlike rules in the shorewall-rules(5) file, evaluation of rules in this file
# will continue after a match. So the final mark for each packet will be the one
# assigned by the LAST tcrule that matches.
#
# If you use multiple internet providers with the 'track' option, in /etc/
# shorewall/providers be sure to read the restrictions at http://
# www.shorewall.net/MultiISP.html.
#
# The columns in the file are as follows (where the column name is followed by a
# different name in parentheses, the different name is used in the alternate
# specification syntax).
#
# ACTION - command[(parameters)][:chain-designator]
#
# The chain-designator indicates the Netfilter chain that the entry applies
# to and may be one of the following:
#
# P
#
# PREROUTING chain.
#
# F
#
# FORWARD chain.
#
# T
#
# POSTROUTING chain.
#
# I
#
# INPUT chain.
#
# NP
#
# PREROUTING chain in the nat table.
#
# NI
#
# INPUT chain in the nat table.
#
# NO
#
# OUTPUT chain in the nat table.
#
# NT
#
# POSTROUTING chain in the nat table.
#
# The nat table designators were added in Shorewall 5.2.1. When a nat table
# designator is given, only the CONNMARK, MARK, SAVE and RESTORE commands may
# be used.
#
# Unless otherwise specified for the particular command, the default chain is
# PREROUTING when MARK_IN_FORWARD_CHAIN=No in shorewall.conf(5), and FORWARD
# when MARK_IN_FORWARD_CHAIN=Yes.
#
# A chain-designator may not be specified if the SOURCE or DEST columns begin
# with '$FW'. When the SOURCE is $FW, the generated rule is always placed in
# the OUTPUT chain. If DEST is '$FW', then the rule is placed in the INPUT
# chain. Additionally, a chain-designator may not be specified in an action
# body.
#
# Where a command takes parameters, those parameters are enclosed in
# parentheses ("(....)") and separated by commas.
#
# The command may be one of the following.
#
# action[([param[,...])]
#
# Added in Shorewall 5.0.7. action must be an action declared with the
# mangle option in shorewall-actions(5). If the action accepts
# parameters, they are specified as a comma-separated list within
# parentheses following the action name.
#
# ADD(ipset:flags)
#
# Added in Shorewall 4.6.7. Causes addresses and/or port numbers to be
# added to the named ipset. The flags specify the address or tuple to be
# added to the set and must match the type of ipset involved. For
# example, for an iphash ipset, either the SOURCE or DESTINATION address
# can be added using flags src or dst respectively (see the -A command in
# ipset (8)).
#
# ADD is non-terminating. Even if a packet matches the rule, it is passed
# on to the next rule.
#
# CHECKSUM
#
# Compute and fill in the checksum in a packet that lacks a checksum.
# This is particularly useful if you need to work around old
# applications, such as dhcp clients, that do not work well with checksum
# offloads, but you don't want to disable checksum offload in your
# device.
#
# Requires 'Checksum Target' support in your kernel and iptables.
#
# CLASSIFY(classid)
#
# A classification Id (classid) is of the form major:minor where major
# and minor are integers. Corresponds to the 'class' specification in
# these traffic shaping modules:
#
# atm
# cbq
# dsmark
# pfifo_fast
# htb
# prio
#
# Classification occurs in the POSTROUTING chain except when the SOURCE
# is $FW[:address] in which case classification occurs in the OUTPUT
# chain.
#
# When using Shorewall's built-in traffic shaping tool, the major class
# is the device number (the first device in shorewall-tcdevices(5) is
# major class 1, the second device is major class 2, and so on) and the
# minor class is the class's MARK value in shorewall-tcclasses(5)
# preceded by the number 1 (MARK 1 corresponds to minor class 11, MARK 5
# corresponds to minor class 15, MARK 22 corresponds to minor class 122,
# etc.).
#
# ?COMMENT
#
# The rest of the line will be attached as a comment to the Netfilter
# rule(s) generated by the following entries. The comment will appear
# delimited by "/* ... */" in the output of shorewall show mangle
#
# To stop the comment from being attached to further rules, simply
# include ?COMMENT on a line by itself.
#
# CONMARK({mark|range})
#
# Identical to MARK with the exception that the mark is assigned to
# connection to which the packet belongs is marked rather than to the
# packet itself.
#
# CONTINUE
#
# Don't process any more marking rules in the table.
#
# Currently, CONTINUE may not be used with exclusion (see the SOURCE and
# DEST columns below); that restriction will be removed when iptables/
# Netfilter provides the necessary support.
#
# DEL(ipset:flags)
#
# Added in Shorewall 4.6.7. Causes an entry to be deleted from the named
# ipset. The flags specify the address or tuple to be deleted from the
# set and must match the type of ipset involved. For example, for an
# iphash ipset, either the SOURCE or DESTINATION address can be deleted
# using flags src or dst respectively (see the -D command in ipset (8)).
#
# DEL is non-terminating. Even if a packet matches the rule, it is passed
# on to the next rule.
#
# DIVERT
#
# Two DIVERT rule should precede the TPROXY rule and should select DEST
# PORT tcp 80 and SOURCE PORT tcp 80 respectively (assuming that tcp port
# 80 is being proxied). DIVERT avoids sending packets to the TPROXY
# target once a socket connection to Squid3 has been established by
# TPROXY. DIVERT marks the packet with a unique mark and exempts it from
# any rules that follow.
#
# DIVERTHA
#
# Added in Shorewall 5.0.4. To setup the HAProxy configuration described
# at http://www.loadbalancer.org/blog/
# setting-up-haproxy-with-transparent-mode-on-centos-6-x, place this
# entry in shorewall-providers(5):
#
# #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY
# TProxy 1 - - lo - tproxy
#
# and use this DIVERTHA entry:
#
# #ACTION SOURCE DEST PROTO DPORT SPORT USER TEST LENGTH TOS CONNBYTES HELPER PROBABILITY DSCP
# DIVERTHA - - tcp
#
# DROP
#
# Causes matching packets to be discarded.
#
# DSCP(dscp)
#
# Sets the Differentiated Services Code Point field in the IP header. The
# dscp value may be given as an even number (hex or decimal) or as the
# name of a DSCP class. Valid class names and their associated hex
# numeric values are:
#
# CS0 => 0x00
# CS1 => 0x08
# CS2 => 0x10
# CS3 => 0x18
# CS4 => 0x20
# CS5 => 0x28
# CS6 => 0x30
# CS7 => 0x38
# BE => 0x00
# AF11 => 0x0a
# AF12 => 0x0c
# AF13 => 0x0e
# AF21 => 0x12
# AF22 => 0x14
# AF23 => 0x16
# AF31 => 0x1a
# AF32 => 0x1c
# AF33 => 0x1e
# AF41 => 0x22
# AF42 => 0x24
# AF43 => 0x26
# EF => 0x2e
#
# To indicate more than one class, add their hex values together and
# specify the result. By default, DSCP rules are placed in the
# POSTROUTING chain.
#
# ECN
#
# Added in Shorewall 5.0.6 as an alternative to entries in shorewall-ecn
# (5). If a PROTO is specified, it must be 'tcp' (6). If no PROTO is
# supplied, TCP is assumed. This action causes all ECN bits in the TCP
# header to be cleared.
#
# IMQ(number)
#
# Specifies that the packet should be passed to the IMQ identified by
# number. Requires IMQ Target support in your kernel and iptables.
#
# INLINE[(action)]
#
# Allows you to place your own ip[6]tables matches at the end of the line
# following a semicolon (";") (deprecated) or two semicolons (";;")
# (preferred since Shoreall 5.0.0). If an action is specified, the
# compiler proceeds as if that action had been specified in this column.
# If no action is specified, then you may include your own jump ("-j
# target [option] ...") after any matches specified at the end of the
# rule. If the target is not one known to Shorewall, then it must be
# defined as a builtin action in shorewall-actions (5).
#
# The following rules are equivalent:
#
# 2:P eth0 - tcp 22
# INLINE(MARK(2)):P eth0 - tcp 22
# INLINE(MARK(2)):P eth0 - ;; -p tcp
# INLINE eth0 - tcp 22 ;; -j MARK --set-mark 2
# INLINE eth0 - ;; -p tcp -j MARK --set-mark 2
#
# IPMARK
#
# Assigns a mark to each matching packet based on the either the source
# or destination IP address. By default, it assigns a mark value equal to
# the low-order 8 bits of the source address. Default values are:
#
# src
# mask1 = 0xFF
# mask2 = 0x00
# shift = 0
#
# 'src' and 'dst' specify whether the mark is to be based on the source
# or destination address respectively. The selected address is first
# shifted to the right by shift bits. The result is then LANDed with
# mask1 then LORed with mask2.
#
# In a sense, the IPMARK target is more like an IPCLASSIFY target in that
# the mark value is later interpreted as a class ID. A packet mark is 32
# bits wide; so is a class ID. The class occupies the high-order
# 16 bits and the class occupies the low-order 16 bits. So the
# class ID 1:4ff (remember that class IDs are always in hex) is
# equivalent to a mark value of 0x104ff. Remember that Shorewall uses the
# interface number as the number where the first interface in
# tcdevices has number 1, the second has number 2, and so
# on.
#
# The IPMARK target assigns a mark to each matching packet based on the
# either the source or destination IP address. By default, it assigns a
# mark value equal to the low-order 8 bits of the source address. The
# syntax is as follows:
#
# IPMARK[([{src|dst}][,[mask1][,[mask2][,[shift]]]])]
#
# Default values are:
#
# src
# mask1 = 0xFF
# mask2 = 0x00
# shift = 0
#
# src and dst specify whether the mark is to be based on the source or
# destination address respectively. The selected address is first shifted
# right by shift, then LANDed with mask1 and then LORed with mask2. The
# shift argument is intended to be used primarily with IPv6 addresses.
#
# Example:
#
# IPMARK(src,0xff,0x10100)
#
# Suppose that the source IP address is 192.168.4.3 = 0xc0a80403;
# then
# 0xc0a80403 >> 0 = 0xc0a80403
# 0xc0a80403 LAND 0xFF = 0x03
# 0x03 LOR 0x10100 = 0x10103 or class ID 1:103
#
# It is important to realize that, while class IDs are composed of a
# major and a minor value, the set of values must be unique. That is, the
# same numeric value cannot be used as both a major and a minor number
# for the same interface unless class nesting occurs (which is not
# currently possible with Shorewall). You should keep this in mind when
# deciding how to map IP addresses to class IDs.
#
# For example, suppose that your internal network is 192.168.1.0/29 (host
# IP addresses 192.168.1.1 - 192.168.1.6). Your first notion might be to
# use IPMARK(src,0xFF,0x10000) so as to produce class IDs 1:1 through
# 1:6. But 1:1 is an invalid class ID since the major and minor classes
# are equal. So you might choose instead to use IPMARK(src,0xFF,0x10100)
# as in the example above so that all of your minor classes will have a
# value > 256.
#
# IP6TABLES({target [option ...])
#
# IPv6 only.
#
# This action allows you to specify an iptables target with options
# (e.g., 'IP6TABLES(MARK --set-xmark 0x01/0xff)'. If the target is not
# one recognized by Shorewall, the following error message will be
# issued:
#
# ERROR: Unknown target (target)
#
# This error message may be eliminated by adding the target as a builtin
# action in shorewall-actions(5).
#
# IPTABLES({target [option ...])
#
# IPv4 only.
#
# This action allows you to specify an iptables target with options
# (e.g., 'IPTABLES(MARK --set-xmark 0x01/0xff)'. If the target is not one
# recognized by Shorewall, the following error message will be issued:
#
# ERROR: Unknown target (target)
#
# This error message may be eliminated by adding the target as a builtin
# action in shorewall-actions(5).
#
# MARK({mark|range})
#
# where mark is a packet mark value.
#
# Normally will set the mark value. If preceded by a vertical bar ("|"),
# the mark value will be logically ORed with the current mark value to
# produce a new mark value. If preceded by an ampersand ("&"), will be
# logically ANDed with the current mark value to produce a new mark
# value.
#
# Both "|" and "&" require Extended MARK Target support in your kernel
# and iptables.
#
# The mark value may be optionally followed by "/" and a mask value (used
# to determine those bits of the connection mark to actually be set).
# When a mask is specified, the result of logically ANDing the mark value
# with the mask must be the same as the mark value.
#
# A mark range is a pair of integers separated by a dash ("-").
#
# May be optionally followed by a slash ("/") and a mask and requires the
# Statistics Match capability in iptables and kernel. Marks in the
# specified range are assigned to packets on a round-robin fashion.
#
# When a mask is specified, the result of logically ANDing each mark
# value with the mask must be the same as the mark value. The least
# significant bit in the mask is used as an increment. For example, if
# '0x200-0x400/0xff00' is specified, then the assigned mark values are
# 0x200, 0x300 and 0x400 in equal proportions. If no mask is specified,
# then ( 2 ** MASK_BITS ) - 1 is assumed (MASK_BITS is set in
# shorewall.conf(5)).
#
# NFLOG[(nflog-parameters)]
#
# Added in Shorewall 5.0.9. Logs matching packets using NFLOG. The
# nflog-parameters are a comma-separated list of up to 3 numbers:
#
# ☆ The first number specifies the netlink group (0-65535). If omitted
# (e.g., NFLOG(,0,10)) then a value of 0 is assumed.
#
# ☆ The second number specifies the maximum number of bytes to copy. If
# omitted, 0 (no limit) is assumed.
#
# ☆ The third number specifies the number of log messages that should
# be buffered in the kernel before they are sent to user space. The
# default is 1.
#
# RESTORE[(mask)]
#
# Restore the packet's mark from the connection's mark using the supplied
# mask if any. Your kernel and iptables must include CONNMARK support.
#
# SAME[(timeout)]
#
# Some websites run applications that require multiple connections from a
# client browser. Where multiple 'balanced' providers are configured,
# this can lead to problems when some of the connections are routed
# through one provider and some through another. The SAME target allows
# you to work around that problem. SAME may be used in the PREROUTING and
# OUTPUT chains. When used in PREROUTING, it causes matching connections
# from an individual local system to all use the same provider. For
# example:
#
# #ACTION SOURCE DEST PROTO DPORT
# SAME:P 192.168.1.0/24 0.0.0.0/0 tcp 80,443
#
# If a host in 192.168.1.0/24 attempts a connection on TCP port 80 or 443
# and it has sent a packet on either of those ports in the last five
# minutes then the new connection will use the same provider as the
# connection over which that last packet was sent.
#
# When used in the OUTPUT chain, it causes all matching connections to an
# individual remote system to all use the same provider. For example:
#
# #ACTION SOURCE DEST PROTO DPORT
# SAME $FW 0.0.0.0/0 tcp 80,443
#
# The optional timeout parameter was added in Shorewall 4.6.7 and
# specifies a number of seconds . When not specified, a value of 300
# seconds (5 minutes) is assumed. If the firewall attempts a connection
# on TCP port 80 or 443 and it has sent a packet on either of those ports
# in the last timeout seconds to the same remote system then the new
# connection will use the same provider as the connection over which that
# last packet was sent.
#
# SAVE[(mask)]
#
# Save the packet's mark to the connection's mark using the supplied mask
# if any. Your kernel and iptables must include CONNMARK support.
#
# TCPMSS([mss[,ipsec]])
#
# Added in Shorewall 5.1.9. This target only applies to TCP traffic and
# alters the MSS value in SYN packets. It may be used in the FORWARD and
# POSTROUTING chains; the default is FORWARD.
#
# The mss parameter may be either pmtu or an integer in the range
# 500:65533. The value pmtu automatically clamps the MSS value to
# (path_MTU - 40 for IPv4; -60 for IPv6). This may not function as
# desired where asymmetric routes with differing path MTU exist — the
# kernel uses the path MTU which it would use to send packets from itself
# to the source and destination IP addresses. Prior to Linux 2.6.25, only
# the path MTU to the destination IP address was considered by this
# option; subsequent kernels also consider the path MTU to the source IP
# address. If an integer is given, the MSS option is set to the specified
# value. If the MSS of the packet is already lower than mss, it will not
# be increased (from Linux 2.6.25 onwards) to avoid more problems with
# hosts relying on a proper MSS. If mss is omitted, pmtu is assumed.
#
# The ipsec parameter determines whether the rule applies to IPSEC
# traffic (ipsec is passed), non-IPSEC traffic (none is passed) or both
# (all is passed). If omitted, all is assumed.
#
# TOS(tos[/mask])
#
# Sets the Type of Service field in the IP header. The tos value may be
# given as an number (hex or decimal) or as the name of a TOS type. Valid
# type names and their associated hex numeric values are:
#
# Minimize-Delay => 0x10,
# Maximize-Throughput => 0x08,
# Maximize-Reliability => 0x04,
# Minimize-Cost => 0x02,
# Normal-Service => 0x00
#
# To indicate more than one class, add their hex values together and
# specify the result.
#
# When tos is given as a number, it may be optionally followed by '/' and
# a mask. When no mask is given, the value 0xff is assumed. When tos is
# given as a type name, the mask 0x3f is assumed.
#
# The action performed is to zero out the bits specified by the mask,
# then set the bits specified by tos.
#
# TPROXY([port[,address]])
#
# Transparently redirects a packet without altering the IP header.
# Requires a tproxy provider to be defined in shorewall-providers(5).
#
# There are three parameters to TPROXY - neither is required:
#
# ☆ port - the port on which the proxy server is listening. If omitted,
# the original destination port.
#
# ☆ address - a local (to the firewall) IP address on which the proxy
# server is listening. If omitted, the IP address of the interface on
# which the request arrives.
#
# TTL([-|+]number)
#
# If + is included, packets matching the rule will have their TTL
# incremented by number. Similarly, if - is included, matching packets
# have their TTL decremented by number. If neither + nor - is given, the
# TTL of matching packets is set to number. The valid range of values for
# number is 1-255.
#
# SOURCE - {-|source-spec[,...]}
#
# where source-spec is one of:
#
# [!]interface
#
# where interface is the logical name of an interface defined in
# shorewall-interfaces(5). Matches packets entering the firewall from the
# named interface. May not be used in CLASSIFY rules or in rules using
# the :T chain qualifier.
#
# Beginning with Shorweall 5.2.1, the interface may be preceded with '!'
# which matches all interfaces except the one specified.
#
# address[,...][exclusion]
#
# where address is:
#
# A host or network IP address.
#
# The name of an ipset preceded by a plus sign ("+").
#
# A MAC address in Shorewall format (preceded by a tilde ("~") and
# using dash ("-") as a separator (e.g., ~00-A0-C9-15-39-78).
#
# Matches traffic whose source IP address matches one of the listed
# addresses and that does not match an address listed in the exclusion
# (see shorewall-exclusion(5)).
#
# This form will not match traffic that originates on the firewall itself
# unless either or the :T chain qualifier is used in the
# ACTION column.
#
# [!]interface:address,[...][exclusion]
#
# This form combines the preceding two forms and matches when both the
# incoming interface and source IP address match.
#
# Beginning with Shorweall 5.2.1, the interface may be preceded with '!'
# which matches all interfaces except the one specified.
#
# [!]interface:exclusion
#
# This form matches packets arriving through the named interface and
# whose source IP address does not match any of the addresses in the
# exclusion.
#
# Beginning with Shorweall 5.2.1, the interface may be preceded with '!'
# which matches all interfaces except the one specified.
#
# $FW
#
# Matches packets originating on the firewall system. May not be used
# with a chain qualifier (:P, :F, etc.) in the ACTION column.
#
# $FW:address[,...][exclusion]
#
# where address is as above (MAC addresses are not permitted). Matches
# packets originating on the firewall and whose source IP address matches
# one of the listed addresses and does not match any address listed in
# the exclusion. May not be used with a chain qualifier (:P, :F, etc.) in
# the ACTION column.
#
# $FW:exclusion
#
# Matches traffic originating on the firewall, provided that the source
# IP address does not match any address listed in the exclusion.
#
# Beginning with Shorewall 5.1.0, multiple source_specs, separated by commas,
# may be given provided that the following alternative forms are used:
#
# (address[,...][exclusion])
#
# interface:(address[,...][exclusion])
#
# interface:(exclusion)
#
# $FW:(address[,...][exclusion])
#
# $FW:(exclusion)
#
# DEST - {-|dest-spec[,...]}
#
# where dest-spec is one of:
#
# interface
#
# where interface is the logical name of an interface defined in
# shorewall-interfaces(5). Matches packets leaving the firewall through
# the named interface. May not be used in the PREROUTING chain (:P in the
# mark column or no chain qualifier and MARK_IN_FORWARD_CHAIN=No in
# shorewall.conf (5)).
#
# address[,...][exclusion]
#
# where address is:
#
# A host or network IP address.
#
# The name of an ipset preceded by a plus sign ("+").
#
# A MAC address in Shorewall format (preceded by a tilde ("~") and
# using dash ("-") as a separator (e.g., ~00-A0-C9-15-39-78).
#
# Matches traffic whose destination IP address matches one of the listed
# addresses and that does not match an address listed in the exclusion
# (see shorewall-exclusion(5)).
#
# interface:address,[...][exclusion]
#
# This form combines the preceding two forms and matches when both the
# outgoing interface and destination IP address match. May not be used in
# the PREROUTING chain (:P in the mark column or no chain qualifier and
# MARK_IN_FORWARD_CHAIN=No in shorewall.conf (5)).
#
# interface:exclusion
#
# This form matches packets leaving through the named interface and whose
# destination IP address does not match any of the addresses in the
# exclusion. May not be used in the PREROUTING chain (:P in the mark
# column or no chain qualifier and MARK_IN_FORWARD_CHAIN=No in
# shorewall.conf (5)).
#
# $FW
#
# Matches packets originating on the firewall system. May not be used
# with a chain qualifier (:P, :F, etc.) in the ACTION column.
#
# $FW:address[,...][exclusion]
#
# where address is as above (MAC addresses are not permitted). Matches
# packets destined for the firewall and whose destination IP address
# matches one of the listed addresses and does not match any address
# listed in the exclusion. May not be used with a chain qualifier (:P,
# :F, etc.) in the ACTION column.
#
# $FW:exclusion
#
# Matches traffic destined for the firewall, provided that the
# destination IP address does not match any address listed in the
# exclusion.
#
# Beginning with Shorewall 5.1.0, multiple dest_specs, separated by commas,
# may be given provided that the following alternative forms are used:
#
# (address[,...][exclusion])
#
# interface:(address[,...][exclusion])
#
# interface:(exclusion)
#
# $FW:(address[,...][exclusion])
#
# $FW:(exclusion)
#
# PROTO - {-|{tcp:[!]syn|ipp2p|ipp2p:udp|ipp2p:all|protocol-number|protocol-name|
# all}[,...]}
#
# See shorewall-rules(5) for details.
#
# Beginning with Shorewall 4.5.12, this column can accept a comma-separated
# list of protocols.
#
# DPORT- {-|port-name-number-or-range[,port-name-number-or-range]...|+ipset}
#
# Optional destination Ports. A comma-separated list of Port names (from
# services(5)), port numbers or port ranges; if the protocol is icmp, this
# column is interpreted as the destination icmp-type(s). ICMP types may be
# specified as a numeric type, a numeric type and code separated by a slash
# (e.g., 3/4), or a typename. See http://www.shorewall.net/
# configuration_file_basics.htm#ICMP.
#
# If the protocol is ipp2p, this column is interpreted as an ipp2p option
# without the leading "--" (example bit for bit-torrent). If no PORT is
# given, ipp2p is assumed.
#
# An entry in this field requires that the PROTO column specify icmp (1), tcp
# (6), udp (17), sctp (132) or udplite (136). Use '-' if any of the following
# field is supplied.
#
# Beginning with Shorewall 4.6.0, an ipset name can be specified in this
# column. This is intended to be used with bitmap:port ipsets.
#
# This column was formerly named DEST PORT(S).
#
# SPORT - {-|port-name-number-or-range[,port-name-number-or-range]...|+ipset}
#
# Optional source port(s). If omitted, any source port is acceptable.
# Specified as a comma-separated list of port names, port numbers or port
# ranges.
#
# An entry in this field requires that the PROTO column specify tcp (6), udp
# (17), sctp (132) or udplite (136). Use '-' if any of the following fields
# is supplied.
#
# Beginning with Shorewall 4.5.15, you may place '=' in this column, provided
# that the DPORT column is non-empty. This causes the rule to match when
# either the source port or the destination port in a packet matches one of
# the ports specified in DEST PORTS(S). Use of '=' requires multi-port match
# in your iptables and kernel.
#
# Beginning with Shorewall 4.6.0, an ipset name can be specified in this
# column. This is intended to be used with bitmap:port ipsets.
#
# This column was formerly labelled SOURCE PORT(S).
#
# USER - [!][user-name-or-number][:group-name-or-number][+program-name]
#
# This optional column may only be non-empty if the SOURCE is the firewall
# itself.
#
# When this column is non-empty, the rule applies only if the program
# generating the output is running under the effective user and/or group
# specified (or is NOT running under that id if "!" is given).
#
# Examples:
#
# joe
#
# program must be run by joe
#
# :kids
#
# program must be run by a member of the 'kids' group
#
# !:kids
#
# program must not be run by a member of the 'kids' group
#
# +upnpd
#
# #program named upnpd
#
# Important
#
# The ability to specify a program name was removed from Netfilter in
# kernel version 2.6.14.
#
# TEST - [!]value[/mask][:C]
#
# Optional - Defines a test on the existing packet or connection mark. The
# rule will match only if the test returns true.
#
# If you don't want to define a test but need to specify anything in the
# following columns, place a "-" in this field.
#
# !
#
# Inverts the test (not equal)
#
# value
#
# Value of the packet or connection mark.
#
# mask
#
# A mask to be applied to the mark before testing.
#
# :C
#
# Designates a connection mark. If omitted, the packet mark's value is
# tested.
#
# LENGTH - [length|[min]:[max]]
#
# Optional - packet payload length. This field, if present allow you to match
# the length of a packet payload (Layer 4 data ) against a specific value or
# range of values. You must have iptables length support for this to work. A
# range is specified in the form min:max where either min or max (but not
# both) may be omitted. If min is omitted, then 0 is assumed; if max is
# omitted, than any packet that is min or longer will match.
#
# TOS - tos
#
# Type of service. Either a standard name, or a numeric value to match.
#
# Minimize-Delay (16)
# Maximize-Throughput (8)
# Maximize-Reliability (4)
# Minimize-Cost (2)
# Normal-Service (0)
#
# CONNBYTES - [!]min:[max[:{O|R|B}[:{B|P|A}]]]
#
# Optional connection Bytes; defines a byte or packet range that the
# connection must fall within in order for the rule to match.
#
# A packet matches if the the packet/byte count is within the range defined
# by min and max (unless ! is given in which case, a packet matches if the
# packet/byte count is not within the range). min is an integer which defines
# the beginning of the byte/packet range. max is an integer which defines the
# end of the byte/packet range; if omitted, only the beginning of the range
# is checked. The first letter gives the direction which the range refers to:
#
# O - The original direction of the connection.
#
# - The opposite direction from the original connection.
#
# B - The total of both directions.
#
# If omitted, B is assumed.
#
# The second letter determines what the range refers to.
#
# B - Bytes
#
# P - Packets
#
# A - Average packet size.
#
# If omitted, B is assumed.
#
# HELPER - helper
#
# Names a Netfilter protocol helper module such as ftp, sip, amanda, etc. A
# packet will match if it was accepted by the named helper module.
#
# Example: Mark all FTP data connections with mark 4:
#
# #ACTION SOURCE DEST PROTO DPORT SPORT USER TEST LENGTH TOS CONNBYTES HELPER
# 4:T 0.0.0.0/0 0.0.0.0/0 TCP - - - - - - - ftp
#
# PROBABILITY - [probability]
#
# Added in Shorewall 4.5.0. When non-empty, requires the Statistics Match
# capability in your kernel and ip6tables and causes the rule to match
# randomly but with the given probability. The probability is a number 0 <
# probability <= 1 and may be expressed at up to 8 decimal points of
# precision.
#
# DSCP - [[!]dscp]
#
# Added in Shorewall 4.5.1. When non-empty, match packets whose
# Differentiated Service Code Point field matches the supplied value (when '!
# ' is given, the rule matches packets whose DSCP field does not match the
# supplied value). The dscp value may be given as an even number (hex or
# decimal) or as the name of a DSCP class. Valid class names and their
# associated hex numeric values are:
#
# CS0 => 0x00
# CS1 => 0x08
# CS2 => 0x10
# CS3 => 0x18
# CS4 => 0x20
# CS5 => 0x28
# CS6 => 0x30
# CS7 => 0x38
# BE => 0x00
# AF11 => 0x0a
# AF12 => 0x0c
# AF13 => 0x0e
# AF21 => 0x12
# AF22 => 0x14
# AF23 => 0x16
# AF31 => 0x1a
# AF32 => 0x1c
# AF33 => 0x1e
# AF41 => 0x22
# AF42 => 0x24
# AF43 => 0x26
# EF => 0x2e
#
# STATE -- {NEW|RELATED|ESTABLISHED|INVALID} [,...]
#
# The rule will only match if the packet's connection is in one of the listed
# states.
#
# TIME - timeelement[&timeelement...]
#
# Added in Shorewall 4.6.2.
#
# May be used to limit the rule to a particular time period each day, to
# particular days of the week or month, or to a range defined by dates and
# times. Requires time match support in your kernel and ip6tables.
#
# timeelement may be:
#
# timestart=hh:mm[:ss]
#
# Defines the starting time of day.
#
# timestop=hh:mm[:ss]
#
# Defines the ending time of day.
#
# contiguous
#
# Added in Shoreawll 5.0.12. When timestop is smaller than timestart
# value, match this as a single time period instead of distinct
# intervals.
#
# utc
#
# Times are expressed in Greenwich Mean Time.
#
# localtz
#
# Deprecated by the Netfilter team in favor of kerneltz. Times are
# expressed in Local Civil Time (default).
#
# kerneltz
#
# Added in Shorewall 4.5.2. Times are expressed in Local Kernel Time
# (requires iptables 1.4.12 or later).
#
# weekdays=ddd[,ddd]...
#
# where ddd is one of Mon, Tue, Wed, Thu, Fri, Sat or Sun
#
# monthdays=dd[,dd],...
#
# where dd is an ordinal day of the month
#
# datestart=yyyy[-mm[-dd[Thh[:mm[:ss]]]]]
#
# Defines the starting date and time.
#
# datestop=yyyy[-mm[-dd[Thh[:mm[:ss]]]]]
#
# Defines the ending date and time.
#
# SWITCH - [!]switch-name[={0|1}]
#
# Added in Shorewall 5.1.0 and allows enabling and disabling the rule without
# requiring shorewall restart.
#
# The rule is enabled if the value stored in /proc/net/nf_condition/
# switch-name is 1. The rule is disabled if that file contains 0 (the
# default). If '!' is supplied, the test is inverted such that the rule is
# enabled if the file contains 0.
#
# Within the switch-name, '@0' and '@{0}' are replaced by the name of the
# chain to which the rule is a added. The switch-name (after '@...'
# expansion) must begin with a letter and be composed of letters, decimal
# digits, underscores or hyphens. Switch names must be 30 characters or less
# in length.
#
# Switches are normally off. To turn a switch on:
#
# echo 1 > /proc/net/nf_condition/switch-name
#
# To turn it off again:
#
# echo 0 > /proc/net/nf_condition/switch-name
#
# Switch settings are retained over shorewall restart.
#
# When the switch-name is followed by =0 or =1, then the switch is
# initialized to off or on respectively by the start command. Other commands
# do not affect the switch setting.
#
# Example
#
# IPv4 Example 1:
#
# Mark all ICMP echo traffic with packet mark 1. Mark all peer to peer
# traffic with packet mark 4.
#
# This is a little more complex than otherwise expected. Since the ipp2p
# module is unable to determine all packets in a connection are P2P packets,
# we mark the entire connection as P2P if any of the packets are determined
# to match.
#
# We assume packet/connection mark 0 means unclassified.
#
# #ACTION SOURCE DEST PROTO DPORT SPORT USER TEST
# MARK(1):T 0.0.0.0/0 0.0.0.0/0 icmp echo-request
# MARK(1):T 0.0.0.0/0 0.0.0.0/0 icmp echo-reply
# RESTORE:T 0.0.0.0/0 0.0.0.0/0 all - - - 0
# CONTINUE:T 0.0.0.0/0 0.0.0.0/0 all - - - !0
# MARK(4):T 0.0.0.0/0 0.0.0.0/0 ipp2p:all
# SAVE:T 0.0.0.0/0 0.0.0.0/0 all - - - !0
#
# If a packet hasn't been classified (packet mark is 0), copy the connection
# mark to the packet mark. If the packet mark is set, we're done. If the
# packet is P2P, set the packet mark to 4. If the packet mark has been set,
# save it to the connection mark.
#
# IPv4 Example 2:
#
# SNAT outgoing connections on eth0 from 192.168.1.0/24 in round-robin
# fashion between addresses 1.1.1.1, 1.1.1.3, and 1.1.1.9 (Shorewall 4.5.9
# and later).
#
# /etc/shorewall/mangle:
#
# #ACTION SOURCE DEST PROTO DPORT SPORT USER TEST
# CONNMARK(1-3):F 192.168.1.0/24 eth0 ; state=NEW
#
# /etc/shorewall/snat:
#
# #ACTION SOURCE DEST ...
# SNAT(1.1.1.1) eth0:192.168.1.0/24 - { mark=1:C }
# SNAT(1.1.1.3) eth0:192.168.1.0/24 - { mark=2:C }
# SNAT(1.1.1.4) eth0:192.168.1.0/24 - { mark=3:C }
#
# IPv6 Example 1:
#
# Mark all ICMP echo traffic with packet mark 1. Mark all peer to peer
# traffic with packet mark 4.
#
# This is a little more complex than otherwise expected. Since the ipp2p
# module is unable to determine all packets in a connection are P2P packets,
# we mark the entire connection as P2P if any of the packets are determined
# to match.
#
# We assume packet/connection mark 0 means unclassified.
#
# #ACTION SOURCE DEST PROTO DPORT SPORT USER TEST
# MARK(1):T ::/0 ::/0 icmp echo-request
# MARK(1):T ::/0 ::/0 icmp echo-reply
# RESTORE:T ::/0 ::/0 all - - - 0
# CONTINUE:T ::/0 ::/0 all - - - !0
# MARK(4):T ::/0 ::/0 ipp2p:all
# SAVE:T ::/0 ::/0 all - - - !0
#
# If a packet hasn't been classified (packet mark is 0), copy the connection
# mark to the packet mark. If the packet mark is set, we're done. If the
# packet is P2P, set the packet mark to 4. If the packet mark has been set,
# save it to the connection mark.
#
######################################################################################################################################################################
#ACTION SOURCE DEST PROTO DPORT SPORT USER TEST LENGTH TOS CONNBYTES HELPER HEADERS PROBABILITY DSCP SWITCH
shorewall6-5.2.3.4/configfiles/refresh 0000664 0000000 0000000 00000000504 13531060406 016317 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/refresh
#
# Add commands below that you want to be executed before Shorewall6 has
# processed the 'refresh' command.
#
# See http://shorewall.net/shorewall_extension_scripts.htm for additional
# information.
#
###############################################################################
shorewall6-5.2.3.4/configfiles/proxyndp 0000664 0000000 0000000 00000000507 13531060406 016547 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/proxyndp
#
# For information about entries in this file, type "man shorewall6-proxyndp"
#
# See http://shorewall.net/ProxyARP.htm for additional information.
#
##################################################################################
#ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT
shorewall6-5.2.3.4/configfiles/netmap 0000664 0000000 0000000 00000000532 13531060406 016146 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/netmap
#
# For information about entries in this file, type "man shorewall-netmap"
#
# See http://shorewall.net/netmap.html for an example and usage
# information.
#
#############################################################################################
#TYPE NET1 INTERFACE NET2 NET3 PROTO DPORT SPORT
shorewall6-5.2.3.4/configfiles/tcclasses 0000664 0000000 0000000 00000000504 13531060406 016645 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/tcclasses
#
# For information about entries in this file, type "man shorewall6-tcclasses"
#
# See http://shorewall.net/traffic_shaping.htm for additional information.
#
###############################################################################
#INTERFACE MARK RATE CEIL PRIO OPTIONS
shorewall6-5.2.3.4/configfiles/enabled 0000664 0000000 0000000 00000000604 13531060406 016254 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/enabled
#
# Add commands below that you want executed when an optional
# interface is successfully enabled using the 'enable' command
#
# When the commands are invoked:
#
# $1 contains the physical name of the interface
# $2 contains the logical name of the interface
# $3 contains the name of the provider associated with the interface,
if any
shorewall6-5.2.3.4/configfiles/params.annotated 0000664 0000000 0000000 00000003610 13531077644 020135 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/params
#
# Assign any variables that you need here.
#
# It is suggested that variable names begin with an upper case letter
# to distinguish them from variables used internally within the
# Shorewall6 programs
#
# Example:
#
# NET_IF=eth0
# NET_OPTIONS=dhcp,nosmurfs
#
# Example (/etc/shorewall6/interfaces record):
#
# net $NET_IF - $NET_OPTIONS
#
# The result will be the same as if the record had been written
#
# net eth0 - dhcp,nosmurfs
#
###############################################################################
#
# Assign any shell variables that you need in this file. The file is always
# processed by /bin/sh so the full range of shell capabilities may be used.
#
# It is suggested that variable names begin with an upper case letter to
# distinguish them from variables used internally within the Shorewall programs
#
# The following variable names must be avoided. Those in bold font must be
# avoided in all Shorewall versions; those in regular font must be avoided in
# versions prior to 4.4.8.
#
# Any option from shorewall.conf (5)
# COMMAND
# CONFDIR
# DEBUG
# ECHO_E
# ECHO_N
# EXPORT
# FAST
# FILEMODE
# HOSTNAME
# IPT_OPTIONS
# NOROUTES
# PREVIEW
# PRODUCT
# PROFILE
# PURGE
# RECOVERING
# RESTOREPATH
# RING_BELL
# SHAREDIR
# Any name beginning with SHOREWALL_ or SW_
# STOPPING
# TEST
# TIMESTAMP
# USE_VERBOSITY
# VARDIR
# VERBOSE
# VERBOSE_OFFSET
# VERSION
#
# Example params file:
#
# NET_IF=eth0
# NET_BCAST=130.252.100.255
# NET_OPTIONS=routefilter
#
# Example shorewall-interfaces(5) file.
#
# ZONE INTERFACE BROADCAST OPTIONS
# net $NET_IF $NET_BCAST $NET_OPTIONS
#
# This is the same as if the interfaces file had contained:
#
# ZONE INTERFACE BROADCAST OPTIONS
# net eth0 130.252.100.255 routefilter
#
###############################################################################
shorewall6-5.2.3.4/configfiles/rtrules.annotated 0000664 0000000 0000000 00000010046 13531077646 020355 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/rtrules
#
# For information about entries in this file, type "man shorewall6-rtrules"
#
# For additional information, see http://www.shorewall.net/MultiISP.html
#
####################################################################################
#
# Entries in this file cause traffic to be routed to one of the providers listed
# in shorewall-providers(5).
#
# The columns in the file are as follows.
#
# SOURCE (Optional) - {-|[&]interface|address|interface:address}
#
# An ip address (network or host) that matches the source IP address in a
# packet. May also be specified as an interface name optionally followed by
# ":" and an address. If the device lo is specified, the packet must
# originate from the firewall itself.
#
# Beginning with Shorewall 4.5.0, you may specify &interface in this column
# to indicate that the source is the primary IP address of the named
# interface.
#
# Beginning with Shorewall 4.6.8, you may specify a comma-separated list of
# addresses in this column.
#
# DEST (Optional) - {-|address}
#
# An ip address (network or host) that matches the destination IP address in
# a packet.
#
# If you choose to omit either SOURCE or DEST, place "-" in that column. Note
# that you may not omit both SOURCE and DEST.
#
# Beginning with Shorewall 4.6.8, you may specify a comma-separated list of
# addresses in this column.
#
# PROVIDER - {provider-name|provider-number|main}
#
# The provider to route the traffic through. May be expressed either as the
# provider name or the provider number. May also be main or 254 for the main
# routing table. This can be used in combination with VPN tunnels, see
# example 2 below.
#
# PRIORITY - priority[!]
#
# The rule's numeric priority which determines the order in which the rules
# are processed. Rules with equal priority are applied in the order in which
# they appear in the file.
#
# 1000-1999
#
# Before Shorewall-generated 'MARK' rules
#
# 11000-11999
#
# After 'MARK' rules but before Shorewall-generated rules for ISP
# interfaces.
#
# 26000-26999
#
# After ISP interface rules but before 'default' rule.
#
# Beginning with Shorewall 5.0.2, the priority may be followed optionally by
# an exclaimation mark ("!"). This causes the rule to remain in place if the
# interface is disabled.
#
# Caution
#
# Be careful when using rules of the same PRIORITY as some unexpected
# behavior can occur when multiple rules have the same SOURCE. For example,
# in the following rules, the second rule overwrites the first unless the
# priority in the second is changed to 19001 or higher:
#
# 10.10.0.0/24 192.168.5.6 provider1 19000
# 10.10.0.0/24 - provider2 19000
#
# MARK - {-|mark[/mask]}
#
# Optional -- added in Shorewall 4.4.25. For this rule to be applied to a
# packet, the packet's mark value must match the mark when logically anded
# with the mask. If a mask is not supplied, Shorewall supplies a suitable
# provider mask.
#
# Examples
#
# Example 1:
#
# You want all traffic coming in on eth1 to be routed to the ISP1 provider.
#
# #SOURCE DEST PROVIDER PRIORITY MASK
# eth1 - ISP1 1000
#
# IPv4 Example 2:
#
# You use OpenVPN (routed setup /tunX) in combination with multiple
# providers. In this case you have to set up a rule to ensure that the
# OpenVPN traffic is routed back through the tunX interface(s) rather than
# through any of the providers. 10.8.0.0/24 is the subnet chosen in your
# OpenVPN configuration (server 10.8.0.0 255.255.255.0).
#
# #SOURCE DEST PROVIDER PRIORITY MASK
# - 10.8.0.0/24 main 1000
#
####################################################################################
#SOURCE DEST PROVIDER PRIORITY MASK
shorewall6-5.2.3.4/configfiles/tunnels.annotated 0000664 0000000 0000000 00000021227 13531077654 020347 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/tunnels
#
# For information about entries in this file, type "man shorewall6-tunnels"
#
# The manpage is also online at
# http://www.shorewall.net/manpages6/shorewall6-tunnels.html
#
###############################################################################
#
# The tunnels file is used to define rules for encapsulated (usually encrypted)
# traffic to pass between the Shorewall system and a remote gateway. Traffic
# flowing through the tunnel is handled using the normal zone/policy/rule
# mechanism. See http://www.shorewall.net/VPNBasics.html for details.
#
# The columns in the file are as follows.
#
# TYPE - {ipsec[:{noah|ah}]|ipsecnat|ipip|gre|l2tp|pptpclient|pptpserver|?COMMENT
# |{openvpn|openvpnclient|openvpnserver}[:{tcp|udp}][:port]|generic:protocol[
# :port]}
#
# Types are as follows:
#
# 6to4 or 6in4 - 6to4 or 6in4 tunnel. The 6in4 synonym was added in 4.4.24.
# ipsec - IPv4 IPSEC
# ipsecnat - IPv4 IPSEC with NAT Traversal (UDP port 4500 encapsulation)
# ipip - IPv4 encapsulated in IPv4 (Protocol 4)
# gre - Generalized Routing Encapsulation (Protocol 47)
# l2tp - Layer 2 Tunneling Protocol (UDP port 1701)
# pptpclient - PPTP Client runs on the firewall
# pptpserver - PPTP Server runs on the firewall
# openvpn - OpenVPN in point-to-point mode
# openvpnclient - OpenVPN client runs on the firewall
# openvpnserver - OpenVPN server runs on the firewall
# generic - Other tunnel type
# tinc - TINC (added in Shorewall 4.6.6)
#
# If the type is ipsec, it may be followed by :ah to indicate that the
# Authentication Headers protocol (51) is used by the tunnel (the default is
# :noah which means that protocol 51 is not used). NAT traversal is only
# supported with ESP (protocol 50) so ipsecnat tunnels don't allow the ah
# option (ipsecnat:noah may be specified but is redundant).
#
# If type is openvpn, openvpnclient or openvpnserver it may optionally be
# followed by ":" and tcp or udp to specify the protocol to be used. If not
# specified, udp is assumed.
#
# If type is openvpn, openvpnclient or openvpnserver it may optionally be
# followed by ":" and the port number used by the tunnel. if no ":" and port
# number are included, then the default port of 1194 will be used. . Where
# both the protocol and port are specified, the protocol must be given first
# (e.g., openvpn:tcp:4444).
#
# If type is generic, it must be followed by ":" and a protocol name (from /
# etc/protocols) or a protocol number. If the protocol is tcp or udp (6 or
# 17), then it may optionally be followed by ":" and a port number.
#
# Comments may be attached to Netfilter rules generated from entries in this
# file through the use of /COMMENT lines. These lines begin with ?COMMENT;
# the remainder of the line is treated as a comment which is attached to
# subsequent rules until another ?COMMENT line is found or until the end of
# the file is reached. To stop adding comments to rules, use a line
# containing only ?COMMENT.
#
# Note
#
# Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT and is
# preferred.
#
# ZONE - zone
#
# The zone of the physical interface through which tunnel traffic passes.
# This is normally your internet zone.
#
# GATEWAY(S) (gateway or gateways) - address-or-range [ , ... ]
#
# The IP address of the remote tunnel gateway. If the remote gateway has no
# fixed address (Road Warrior) then specify the gateway as 0.0.0.0/0. May be
# specified as a network address and if your kernel and iptables include
# iprange match support then IP address ranges are also allowed.
#
# Beginning with Shorewall 4.5.3, a list of addresses or ranges may be given.
# Exclusion (shorewall-exclusion (5) ) is not supported.
#
# GATEWAY ZONES (gateway_zone or gateway_zones) - [zone[,zone]...]
#
# Optional. If the gateway system specified in the third column is a
# standalone host then this column should contain a comma-separated list of
# the names of the zones that the host might be in. This column only applies
# to IPSEC tunnels where it enables ISAKMP traffic to flow through the tunnel
# to the remote gateway(s).
#
# Example
#
# IPv4 Example 1:
#
# IPSec tunnel.
#
# The remote gateway is 4.33.99.124 and the remote subnet is 192.168.9.0/24.
# The tunnel does not use the AH protocol
#
# #TYPE ZONE GATEWAY
# ipsec:noah net 4.33.99.124
#
# IPv4 Example 2:
#
# Road Warrior (LapTop that may connect from anywhere) where the "gw" zone is
# used to represent the remote LapTop
#
# #TYPE ZONE GATEWAY GATEWAY ZONES
# ipsec net 0.0.0.0/0 gw
#
# IPv4 Example 3:
#
# Host 4.33.99.124 is a standalone system connected via an ipsec tunnel to
# the firewall system. The host is in zone gw.
#
# #TYPE ZONE GATEWAY GATEWAY ZONES
# ipsec net 4.33.99.124 gw
#
# IPv4 Example 4:
#
# Road Warriors that may belong to zones vpn1, vpn2 or vpn3. The FreeS/Wan
# _updown script will add the host to the appropriate zone using the
# shorewall add command on connect and will remove the host from the zone at
# disconnect time.
#
# #TYPE ZONE GATEWAY GATEWAY ZONES
# ipsec net 0.0.0.0/0 vpn1,vpn2,vpn3
#
# IPv4 Example 5:
#
# You run the Linux PPTP client on your firewall and connect to server
# 192.0.2.221.
#
# #TYPE ZONE GATEWAY GATEWAY ZONES
# pptpclient net 192.0.2.221
#
# IPv4 Example 6:
#
# You run a PPTP server on your firewall.
#
# #TYPE ZONE GATEWAY GATEWAY ZONES
# pptpserver net 0.0.0.0/0
#
# Example 7:
#
# OPENVPN tunnel. The remote gateway is 4.33.99.124 and openvpn uses port
# 7777.
#
# #TYPE ZONE GATEWAY GATEWAY ZONES
# openvpn:7777 net 4.33.99.124
#
# IPv4 Example 8:
#
# You have a tunnel that is not one of the supported types. Your tunnel uses
# UDP port 4444. The other end of the tunnel is 4.3.99.124.
#
# #TYPE ZONE GATEWAY GATEWAY ZONES
# generic:udp:4444 net 4.3.99.124
#
# IPv4 Example 9:
#
# TINC tunnel where the remote gateways are not specified. If you wish to
# specify a list of gateways, you can do so in the GATEWAY column.
#
# #TYPE ZONE GATEWAY GATEWAY ZONES
# tinc net 0.0.0.0/0
#
# IPv6 Example 1:
#
# IPSec tunnel.
#
# The remote gateway is 2001:cec792b4:1::44. The tunnel does not use the AH
# protocol
#
# #TYPE ZONE GATEWAY
# ipsec:noah net 2002:cec792b4:1::44
#
# IPv6 Example 2:
#
# Road Warrior (LapTop that may connect from anywhere) where the "gw" zone is
# used to represent the remote LapTop
#
# #TYPE ZONE GATEWAY GATEWAY ZONES
# ipsec net ::/0 gw
#
# IPv6 Example 3:
#
# Host 2001:cec792b4:1::44 is a standalone system connected via an ipsec
# tunnel to the firewall system. The host is in zone gw.
#
# #TYPE ZONE GATEWAY GATEWAY ZONES
# ipsec net 2001:cec792b4:1::44 gw
#
# IPv6 Example 4:
#
# OPENVPN tunnel. The remote gateway is 2001:cec792b4:1::44 and openvpn uses
# port 7777.
#
# #TYPE ZONE GATEWAY GATEWAY ZONES
# openvpn:7777 net 2001:cec792b4:1::44
#
# IPv6 Example 8:
#
# You have a tunnel that is not one of the supported types. Your tunnel uses
# UDP port 4444. The other end of the tunnel is 2001:cec792b4:1::44.
#
# #TYPE ZONE GATEWAY GATEWAY ZONES
# generic:udp:4444 net 2001:cec792b4:1::44
#
# IPv6 Example 9:
#
# TINC tunnel where the remote gateways are not specified. If you wish to
# specify a list of gateways, you can do so in the GATEWAY column.
#
# #TYPE ZONE GATEWAY GATEWAY ZONES
# tinc net ::/0
#
###############################################################################
#TYPE ZONE GATEWAY GATEWAY_ZONE
shorewall6-5.2.3.4/configfiles/tunnels 0000664 0000000 0000000 00000000516 13531060406 016354 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/tunnels
#
# For information about entries in this file, type "man shorewall6-tunnels"
#
# The manpage is also online at
# http://www.shorewall.net/manpages6/shorewall6-tunnels.html
#
###############################################################################
#TYPE ZONE GATEWAY GATEWAY_ZONE
shorewall6-5.2.3.4/configfiles/stoppedrules.annotated 0000664 0000000 0000000 00000007472 13531077651 021413 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/stoppedrules
#
# For information about entries in this file,
# type "man shorewall6-stoppedrules"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall6-stoppedrules.html
#
# See http://shorewall.net/starting_and_stopping_shorewall.htm for additional
# information.
#
###############################################################################
#
# This file is used to define the hosts that are accessible when the firewall is
# stopped or is being stopped.
#
# Warning
#
# Changes to this file do not take effect until after the next shorewall start,
# shorewall reload, shorewall restart, or shorewall compile command.
#
# The columns in the file are as follows (where the column name is followed by a
# different name in parentheses, the different name is used in the alternate
# specification syntax).
#
# ACTION - ACCEPT|NOTRACK|DROP
#
# Determines the disposition of the packet.
#
# ACCEPT means that the packet will be accepted.
#
# NOTRACK indicates that no conntrack entry should be created for the packet.
# NOTRACK does not imply ACCEPT.
#
# DROP was added in Shorewall 4.6.0 and causes the packet to be dropped in
# the raw table's PREROUTING chain.
#
# SOURCE - [-|[$FW|interface]|[{$FW|interface}[:address[,address]...]]|[address[,
# address]...]
#
# $FW matches packets originating on the firewall itself, while interface
# specifies packets arriving on the named interface.
#
# This column may also include a comma-separated list of IP/subnet addresses.
# If your kernel and iptables include iprange match support, IP address
# ranges are also allowed. Ipsets and exclusion are also supported. When $FW
# or interface are specified, the list must be preceded by a colon (":").
#
# If left empty or supplied as "-", 0.0.0.0/0 is assumed.
#
# DEST - [-|[$FW|interface]|[{$FW|interface}[:address[,address]...]]|[address[,
# address]...]
#
# $FW matches packets addressed the firewall itself, while interface
# specifies packets arriving on the named interface. Neither may be specified
# if the target is NOTRACK or DROP.
#
# This column may also include a comma-separated list of IP/subnet addresses.
# If your kernel and iptables include iprange match support, IP address
# ranges are also allowed. Ipsets and exclusion are also supported. When $FW
# or interface are specified, the list must be preceded by a colon (":").
#
# If left empty or supplied as "-", 0.0.0.0/0 is assumed.
#
# PROTO (Optional) ‒ protocol-name-or-number[,...]
#
# Protocol.
#
# Beginning with Shorewall 4.5.12, this column can accept a comma-separated
# list of protocols.
#
# DPORT ‒ service-name/port-number-list
#
# Optional. A comma-separated list of port numbers and/or service names from
# /etc/services. May also include port ranges of the form low-port:high-port
# if your kernel and iptables include port range support.
#
# This column was formerly labelled DEST PORT(S).
#
# SPORT ‒ service-name/port-number-list
#
# Optional. A comma-separated list of port numbers and/or service names from
# /etc/services. May also include port ranges of the form low-port:high-port
# if your kernel and iptables include port range support.
#
# Beginning with Shorewall 4.5.15, you may place '=' in this column, provided
# that the DPORT column is non-empty. This causes the rule to match when
# either the source port or the destination port in a packet matches one of
# the ports specified in DEST PORTS(S). Use of '=' requires multi-port match
# in your iptables and kernel.
#
# This column was formerly labelled SOURCE PORT(S).
#
###############################################################################
#ACTION SOURCE DEST PROTO DPORT SPORT
shorewall6-5.2.3.4/configfiles/proxyndp.annotated 0000664 0000000 0000000 00000004103 13531077645 020534 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/proxyndp
#
# For information about entries in this file, type "man shorewall6-proxyndp"
#
# See http://shorewall.net/ProxyARP.htm for additional information.
#
##################################################################################
#
# This file was added in Shorewall 4.4.16 and is used to define Proxy NDP. There
# is one entry in this file for each IPv6 address to be proxied.
#
# The columns in the file are as follows.
#
# ADDRESS - address
#
# IPv6 Address.
#
# INTERFACE - interface (Optional)
#
# Local interface where system with the ip address in ADDRESS is connected.
# Only required when the HAVEROUTE column is left empty or is set to no or No
# .
#
# EXTERNAL - interface
#
# External Interface to be used to access this system from the Internet.
#
# HAVEROUTE - [-|Yes|No]
#
# If there is already a route from the firewall to the host whose address is
# given, enter Yes or yes in this column. Otherwise, enter no or No or leave
# the column empty and Shorewall will add the route for you. If Shorewall6
# adds the route, its persistence depends on the value of thePERSISTENT
# column contains Yes; otherwise, shorewall6 stop or shorewall clear6 will
# delete the route.
#
# PERSISTENT - [-|Yes|No]
#
# If HAVEROUTE is No or no, then the value of this column determines if the
# route added by Shorewall persists after a shorewall6 stop or a shorewall6
# clear. If this column contains Yes or yes then the route persists; If the
# column is empty or contains No or no then the route is deleted by
# shorewall6 stop or shorewall6 clear.
#
# Example
#
# Example 1:
#
# Host with IPv6 2001:470:b:227::44 is connected to interface eth1 and we
# want hosts attached via eth0 to be able to access it using that address.
#
# #ADDRESS INTERFACE EXTERNAL
# 2001:470:b:227::44 eth1 eth0
#
##################################################################################
#ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT
shorewall6-5.2.3.4/configfiles/accounting 0000664 0000000 0000000 00000000661 13531060406 017017 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/accounting
#
# For information about entries in this file, type "man shorewall6-accounting"
#
# Please see http://shorewall.net/Accounting.html for examples and
# additional information about how to use this file.
#
###############################################################################################################
#ACTION CHAIN SOURCE DEST PROTO DPORT SPORT USER MARK IPSEC HEADERS
shorewall6-5.2.3.4/configfiles/interfaces 0000664 0000000 0000000 00000000526 13531060406 017010 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/interfaces
#
# For information about entries in this file, type "man shorewall6-interfaces"
#
# The manpage is also online at
# http://www.shorewall.net/manpages6/shorewall6-interfaces.html
#
?FORMAT 2
###############################################################################
#ZONE INTERFACE OPTIONS
shorewall6-5.2.3.4/configfiles/tcclear 0000664 0000000 0000000 00000000511 13531060406 016274 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/tcclear
#
# Add commands below that you want to be executed before Shorewall6 clears
# the traffic shaping configuration.
#
# See http://shorewall.net/shorewall_extension_scripts.htm for additional
# information.
#
###############################################################################
shorewall6-5.2.3.4/configfiles/shorewall6.conf.annotated 0000664 0000000 0000000 00000234135 13531077650 021671 0 ustar root root ###############################################################################
#
# Shorewall Version 5 -- /etc/shorewall6/shorewall6.conf
#
# For information about the settings in this file, type "man shorewall6.conf"
#
# Manpage also online at
# http://www.shorewall.net/manpages6/shorewall6.conf.html
###############################################################################
# S T A R T U P E N A B L E D
###############################################################################
#
# OPTIONS
#
# Many options have as their value a log-level. Log levels are a method of
# describing to syslog (8) the importance of a message and a number of parameters
# in this file have log levels as their value.
#
# These levels are defined by syslog and are used to determine the destination of
# the messages through entries in /etc/syslog.conf (5). The syslog documentation
# refers to these as "priorities"; Netfilter calls them "levels" and Shorewall
# also uses that term.
#
# Valid levels are:
#
# 7 debug
# 6 info
# 5 notice
# 4 warning
# 3 err
# 2 crit
# 1 alert
# 0 emerg
#
# For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall log
# messages are generated by NetFilter and are logged using facility 'kern' and
# the level that you specify. If you are unsure of the level to choose, 6 (info)
# is a safe bet. You may specify levels by name or by number.
#
# If you have built your kernel with ULOG (IPv4 only) and/or NFLOG target
# support, you may also specify a log level of ULOG and/or NFLOG (must be all
# caps). Rather than log its messages to syslogd, Shorewall will direct netfilter
# to log the messages via the ULOG or NFLOG target which will send them to a
# process called 'ulogd'. ulogd is available with most Linux distributions
# (although it probably isn't installed by default).
#
# Note
#
# If you want to specify parameters to ULOG or NFLOG (e.g., NFLOG(1,0,1)), then
# you must quote the setting.
#
# Example:
#
STARTUP_ENABLED=No
#
# STARTUP_ENABLED={Yes|No}
#
# Determines if Shorewall is allowed to start. As released from
# shorewall.net, this option is set to No. When set to Yes or yes, Shorewall
# may be started. Used as a guard against Shorewall being accidentally
# started before it has been configured.
#
###############################################################################
# V E R B O S I T Y
###############################################################################
VERBOSITY=1
#
# VERBOSITY=[number]
#
# Shorewall has traditionally been very noisy (produced lots of output). You
# may set the default level of verbosity using the VERBOSITY OPTION.
#
# Values are:
#
# 0 - Silent. You may make it more verbose using the -v option
# 1 - Major progress messages displayed
# 2 - All progress messages displayed (pre Shorewall-3.2.0 behavior)
#
# If not specified, then 2 is assumed.
#
###############################################################################
# P A G E R
###############################################################################
PAGER=
#
# PAGER=pathname
#
# Added in Shorewall 5.0.6. Specifies a path name of a pager program like
# less or more. When PAGER is given, the output of verbose status commands
# and the dump command are piped through the named program when the output
# file is a terminal.
#
# Beginning with Shorewall 5.0.12, the default value of this option is the
# DEFAULT_PAGER setting in shorewallrc.
#
###############################################################################
# F I R E W A L L
###############################################################################
FIREWALL=
#
# FIREWALL=[dnsname-or-ip-address]
#
# This option was added in Shorewall 5.0.13 and may be used on an
# administrative system in directories containing the configurations of
# remote firewalls. The contents of the variable are the default value for
# the system parameter to the remote-start, remote-reload and remote-restart
# commands.
#
###############################################################################
# L O G G I N G
###############################################################################
LOG_LEVEL="info"
#
# LOG_LEVEL=log-level[:log-tag]
#
# Added in Shorewall 5.1.2. Beginning with that release, the sample
# configurations use this as the default log level and changing it will
# change all packet logging done by the configuration. In any configuration
# file (except shorewall-params(5)), $LOG_LEVEL will expand to this value.
#
BLACKLIST_LOG_LEVEL=
#
# BLACKLIST_LOG_LEVEL=[log-level[:log-tag]]
#
# Formerly named BLACKLIST_LOGLEVEL. This parameter determines if packets
# from blacklisted hosts are logged and it determines the syslog level that
# they are to be logged at. Its value is a syslog level (Example:
# BLACKLIST_LOG_LEVEL=debug). If you do not assign a value or if you assign
# an empty value then packets from blacklisted hosts are not logged. The
# setting determines the log level of packets sent to the blacklog target of
# shorewall-blrules(5).
#
INVALID_LOG_LEVEL=
#
# INVALID_LOG_LEVEL=log-level[:log-tag]
#
# Added in Shorewall 4.5.13. Packets in the INVALID state that do not match
# any rule in the INVALID section of shorewall-rules (5) are logged at this
# level. The default value is empty which means no logging is performed.
#
LOG_BACKEND=
#
# LOG_BACKEND=[backend]
#
# Added in Shorewall 4.6.4. LOG_BACKEND determines the logging backend to be
# used for the iptrace command (see shorewall(8)).
#
# backend is one of:
#
# LOG
#
# Use standard kernel logging.
#
# ULOG
#
# IPv4 only.
#
# Use ULOG logging to ulogd.
#
# netlink
#
# Use netlink logging to ulogd version 2 or later.
#
LOG_VERBOSITY=2
#
# LOG_VERBOSITY=[number]
#
# This option controls the amount of information logged to the file specified
# in the STARTUP_LOG option.
#
# Values are:
#
# -1 - Logging is disabled
# 0 - Silent. Only error messages are logged.
# 1 - Major progress messages logged.
# 2 - All progress messages logged
#
# If not specified, then -1 is assumed.
#
LOG_ZONE=Both
#
# LOG_ZONE=[src|dst|both]
#
# Added in Shorewall 5.2.0. When a log message is issued from a chain that
# relates to a pair of zones (e.g, 'fw-net'), the chain name normally appears
# in the log message (unless LOGTAGONLY=Yes and a log tag is specified). This
# can prevent OPTIMIZE category 8 from combining chains which are identical
# except for the names of the zones involved. LOG_ZONE allows for only the
# source or destination zone to appear in the messages by setting LOG_ZONE to
# src or dest respectively. If LOG_ZONE=both (the default), then the full
# chain name is included in log messages.
#
LOGALLNEW=
#
# LOGALLNEW=[log-level]
#
# This option is intended for use as a debugging aid. When set to a log
# level, this option causes Shorewall to generate a logging rule as the first
# rule in each builtin chain.
#
# □ The table name is used as the chain name in the log prefix.
#
# □ The chain name is used as the target in the log prefix.
#
# For example, using the default LOGFORMAT, the log prefix for logging
# from the nat table's PREROUTING chain is as follows in versions prior
# to 5.1.0:
#
# Shorewall:nat:PREROUTING
#
#
# In Shorewall 5.1.0 and later releases, the log prefix is:
#
# nat:PREROUTING
#
#
# Important
#
# To help insure that all packets in the NEW state are logged, rate
# limiting (LOGLIMIT) should be disabled when using LOGALLNEW. Use
# LOGALLNEW at your own risk; it may cause high CPU and disk utilization
# and you may not be able to control your firewall after you enable this
# option.
#
# Caution
#
# Do not use this option if the resulting log messages will be sent to
# another system.
#
LOGFILE=/var/log/messages
#
# LOGFILE=[pathname|systemd]
#
# This parameter tells the /sbin/shorewall program where to look for
# Shorewall messages when processing the dump, logwatch, show log, and hits
# commands. If not assigned or if assigned an empty value, /var/log/messages
# is assumed. For further information, see shorewall-logging(8). Beginning
# with Shorewall 5.0.10.1, you may specify systemd to use journelctl -r to
# read the log.
#
LOGFORMAT="%s %s "
#
# LOGFORMAT=["formattemplate"]
#
# The value of this variable generate the --log-prefix setting for Shorewall
# logging rules. It contains a “printf” formatting template which accepts
# three arguments (the chain name, logging rule number (optional) and the
# disposition). To use LOGFORMAT with fireparse, set it as:
#
# LOGFORMAT="fp=%s:%d a=%s "
#
# If the LOGFORMAT value contains the substring “%d” then the logging rule
# number is calculated and formatted in that position; if that substring is
# not included then the rule number is not included. If not supplied or
# supplied as empty (LOGFORMAT="") then “Shorewall:%s:%s:” is assumed.
#
# Note
#
# The setting of LOGFORMAT has an effect of the permitted length of zone
# names. See shorewall-zones (5).
#
# Caution
#
# Beginning with Shorewall 5.1.0, the default and sample shorewall[6].conf
# files set LOGFORMAT="%s %s ".
#
# Regardless of the LOGFORMAT setting, Shorewall IPv4 log messages that use
# this LOGFORMAT can be uniquely identified using the following regular
# expression:
#
# 'IN=.* OUT=.* SRC=.*\..* DST='
#
# and Shorewall IPv6 log messages can be uniquely identified using the
# following regular expression:
#
# 'IN=.* OUT=.* SRC=.*:.* DST='
#
# To match all Netfilter log messages (Both IPv4 and IPv6 and regardless of
# the LOGFORMAT setting), use:
#
# 'IN=.* OUT=.* SRC=.* DST='
#
LOGLIMIT="s:1/sec:10"
#
# LOGLIMIT=[[{s|d}:]rate/{sec|second|min|minute|hour|day}[:burst]]
#
# Added in Shorewall 4.4.12. Limits the logging rate, either overall, or by
# source or destination IP address.
#
# If the value starts with 's:' then logging is limited per source IP. If the
# value starts with 'd:', then logging is limited per destination IP.
# Otherwise, the overall logging rate is limited.
#
# If burst is not specified, then a value of 5 is assumed.
#
# The keywords second and minute are accepted beginning with Shorewall
# 4.6.13.
#
LOGTAGONLY=No
#
# LOGTAGONLY=[Yes|No]
#
# Using LOGFORMAT=“Shorewall:%s:%s:”, chain names may not exceed 5 characters
# or truncation of the log prefix may occur. Longer chain names may be used
# with log tags if you set LOGTAGONLY=Yes. With LOGTAGONLY=Yes, if a log tag
# is specified then the tag is included in the log prefix in place of the
# chain name.
#
# Beginning with Shorewall 4.5.12, when LOGTAGONLY=Yes, you have more control
# over the generated log prefix. Beginning with that release, the tag is
# interpreted as a chain name and a disposition separated by a comma. So this
# rule:
#
# #ACTION SOURCE DEST
# LOG:info:foo,bar net fw
#
# would generate the following log prefix when using LOGFORMAT=
# “Shorewall:%s:%s:”:
#
# Shorewall:foo:bar:
#
# Similarly,
#
# #ACTION SOURCE DEST
# LOG:info:,bar net fw
#
# would generate
#
# Shorewall:net2fw:bar:
#
MACLIST_LOG_LEVEL="$LOG_LEVEL"
#
# MACLIST_LOG_LEVEL=[log-level[:log-tag]]
#
# Determines the syslog level for logging connection requests that fail MAC
# Verification. The value must be a valid syslogd log level. If you don't
# want to log these connection requests, set to the empty value (e.g.,
# MACLIST_LOG_LEVEL="").
#
RELATED_LOG_LEVEL=
#
# RELATED_LOG_LEVEL=log-level[:log-tag]
#
# Added in Shorewall 4.4.27. Packets in the related state that do not match
# any rule in the RELATED section of shorewall-rules (5) are logged at this
# level. The default value is empty which means no logging is performed.
#
RPFILTER_LOG_LEVEL="$LOG_LEVEL"
#
# RPFILTER_LOG_LEVEL=log-level[:log-tag]
#
# Added in shorewall 4.5.7. Determines the logging of packets disposed via
# the RPFILTER_DISPOSITION. The default value is info.
#
SFILTER_LOG_LEVEL="$LOG_LEVEL"
#
# SFILTER_LOG_LEVEL=log-level[:log-tag]
#
# Added on Shorewall 4.4.20. Determines the logging of packets matching the
# sfilter option (see shorewall-interfaces(5)) and of hairpin packets on
# interfaces without the routeback option.^[2] The default is info. If you
# don't wish for these packets to be logged, use SFILTER_LOG_LEVEL=none.
#
SMURF_LOG_LEVEL="$LOG_LEVEL"
#
# SMURF_LOG_LEVEL=[log-level[:log-tag]]
#
# Specifies the logging level for smurf packets (see the nosmurfs option in
# shorewall-interfaces(5)). If set to the empty value ( SMURF_LOG_LEVEL="" )
# then smurfs are not logged.
#
STARTUP_LOG=/var/log/shorewall6-init.log
#
# STARTUP_LOG=[pathname]
#
# If specified, determines where Shorewall will log the details of each start
# , reload, restart, try, and safe-* command. Logging verbosity is determined
# by the setting of LOG_VERBOSITY above.
#
TCP_FLAGS_LOG_LEVEL="$LOG_LEVEL"
#
# TCP_FLAGS_LOG_LEVEL=[log-level[:log-tag]]
#
# Determines the syslog level for logging packets that fail the checks
# enabled by the tcpflags interface option. The value must be a valid syslogd
# log level. If you don't want to log these packets, set to the empty value
# (e.g., TCP_FLAGS_LOG_LEVEL="").
#
UNTRACKED_LOG_LEVEL=
#
# UNTRACKED_LOG_LEVEL=log-level[:log-tag]
#
# Added in Shorewall 4.5.13. Packets in the UNTRACKED state that do not match
# any rule in the UNTRACKED section of shorewall-rules (5) are logged at this
# level. The default value is empty which means no logging is performed.
#
###############################################################################
# L O C A T I O N O F F I L E S A N D D I R E C T O R I E S
###############################################################################
CONFIG_PATH=":${CONFDIR}/shorewall6:/usr/share/shorewall6:${SHAREDIR}/shorewall"
#
# CONFIG_PATH=[[:]directory[:directory]...]
#
# Specifies where configuration files other than shorewall[6].conf may be
# found. CONFIG_PATH is specifies as a list of directory names separated by
# colons (":"). When looking for a configuration file:
#
# □ If the command is "try" or a "" was specified
# in the command (e.g., shorewall [-6] check ./gateway) then the
# directory given in the command is searched first.
#
# □ Next, each directory in the CONFIG_PATH setting is searched in
# sequence.
#
# If CONFIG_PATH is not given or if it is set to the empty value then the
# contents of /usr/share/shorewall/configpath are used. As released from
# shorewall.net, that file sets the CONFIG_PATH to /etc/shorewall:/usr/share/
# shorewall but your particular distribution may set it differently. See the
# output of shorewall show config for the default on your system.
#
# Beginning with Shorewall 5.1.10, the CONFIG_PATH setting may begin with a
# colon (":"), to signal that the first directory listed will be skipped if
# the user performing a compilation is not root or if the configuration is
# being compiled for export (-e option specified or if running one of the
# remote-* commands) . This prevents the compiler from looking in /etc/
# shorewall[6]/ when compilation is being done by a non-root user or if the
# generated script is to be sent to a remote firewall system.
#
GEOIPDIR=/usr/share/xt_geoip/LE
#
# GEOIPDIR=[pathname]
#
# Added in Shorewall 4.5.4. Specifies the pathname of the directory
# containing the GeoIP Match database. See http://www.shorewall.net/
# ISO-3661.html. If not specified, the default value is /usr/share/xt_geoip/
# LE which is the default location of the little-endian database.
#
IP6TABLES=
#
# IP6TABLES=[pathname]
#
# IPv6 only.
#
# This parameter names the ip6tables executable to be used by Shorewall6. If
# not specified or if specified as a null value, then the ip6tables
# executable located using the PATH option is used.
#
# Regardless of how the ip6tables utility is located (specified via IP6TABLES
# = or located via PATH), Shorewall6 uses the ip6tables-restore and
# ip6tables-save utilities from that same directory.
#
IP=
#
# IP=[pathname]
#
# If specified, gives the pathname of the 'ip' executable. If not specified,
# 'ip' is assumed and the utility will be located using the current PATH
# setting.
#
IPSET=
#
# IPSET=[pathname]
#
# If specified, gives the pathname of the 'ipset' executable. If not
# specified, 'ipset' is assumed and the utility will be located using the
# current PATH setting.
#
LOCKFILE=
#
# LOCKFILE=[pathname]
#
# Specifies the name of the Shorewall[6] lock file, used to prevent
# simultaneous state-changing commands. If not specified, ${VARDIR}/shorewall
# [6]/lock is assumed (${VARDIR} is normally /var/lib but can be changed when
# Shorewall-core is installed -- see the output of shorewall show vardir).
#
MODULESDIR=
#
# MODULESDIR=[[+]pathname[:pathname]...]
#
# This parameter specifies the directory/directories where your kernel
# netfilter modules may be found. If you leave the variable empty, Shorewall
# will supply the value "/lib/modules/$uname/kernel/net/ipv${g_family}/
# netfilter:/lib/modules/$uname/kernel/net/netfilter:/lib/modules/$uname/
# kernel/net/sched:/lib/modules/$uname/extra:/lib/modules/$uname/extra/ipset"
# where uname holds the output of 'uname -r' and g_family holds '4' in IPv4
# configurations and '6' in IPv6 configurations.
#
# The option plus sign ('+') was added in Shorewall 5.0.3 and causes the
# listed pathnames to be appended to the default list above.
#
NFACCT=
#
# NFACCT=[pathname]
#
# Added in Shorewall 4.5.7. Specifies the pathname of the nfacct utility. If
# not specified, Shorewall will use the PATH setting to find the program.
#
PERL=/usr/bin/perl
#
# PERL=pathname
#
# Added in Shorewall 4.4.11 RC1. Specifies the path name of the Perl
# executable. Default is /usr/bin/perl. If the pathname specified by this
# option does not exist or the named file is not executable, then Shorewall
# falls back to /usr/bin/perl
#
PATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin"
#
# PATH=pathname[:pathname]...
#
# Determines the order in which Shorewall searches directories for executable
# files.
#
RESTOREFILE=restore
#
# RESTOREFILE=filename
#
# Specifies the simple name of a file in /var/lib/shorewall to be used as the
# default restore script in the shorewall [-6] save, shorewall [-6] restore,
# shorewall [-6] forget and shorewall [6] -f start commands.
#
SHOREWALL_SHELL=/bin/sh
#
# SHOREWALL_SHELL=[pathname]
#
# This option is used to specify the shell program to be used to interpret
# the compiled script. If not specified or specified as a null value, /bin/sh
# is assumed. Using a light-weight shell such as ash or dash can
# significantly improve performance.
#
SUBSYSLOCK=/var/lock/subsys/shorewall6
#
# SUBSYSLOCK=[pathname]
#
# This parameter should be set to the name of a file that the firewall should
# create if it starts successfully and remove when it stops. Creating and
# removing this file allows Shorewall to work with your distribution's
# initscripts. For OpenSuSE, this should be set to /var/lock/subsys/shorewall
# (var/lock/subsys/shorewall-lite if building for export). For Gentoo, it
# should be set to /run/lock/shorewall (/run/lock/shorewall-lite). For Redhat
# and derivatives as well as Debian and derivatives, the pathname should be
# omitted.
#
# Important
#
# Beginning with Shorewall 5.1.0, this setting is ignored when SERVICEDIR is
# non-empty in ${SHAREDIR}/shorewall/shorewallrc (usually /usr/share/
# shorewall/shorewallrc).
#
TC=
#
# TC=[pathname]
#
# If specified, gives the pathname of the 'tc' executable. If not specified,
# 'tc' is assumed and the utility will be located using the current PATH
# setting.
#
###############################################################################
# D E F A U L T A C T I O N S / M A C R O S
###############################################################################
ACCEPT_DEFAULT="none"
#
# ACCEPT_DEFAULT={action[(parameters)][:level][,...]|none}
#
BLACKLIST_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP),dropNotSyn:$LOG_LEVEL,dropInvalid:$LOG_LEVEL,DropDNSrep:$LOG_LEVEL"
#
# BLACKLIST_DEFAULT={action[(parameters)][:level][,...]|none}
#
DROP_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)"
#
# DROP_DEFAULT={action[(parameters)][:level][,...]|none}
#
NFQUEUE_DEFAULT="none"
#
# NFQUEUE_DEFAULT={action[(parameters)][:level][,...]|none}
#
QUEUE_DEFAULT="none"
#
# QUEUE_DEFAULT={action[(parameters)][:level][,...]|none}
#
REJECT_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)"
#
# REJECT_DEFAULT={action[(parameters)][:level][,...]|none}
#
# In earlier Shorewall versions, a "default action" for DROP and REJECT
# policies was specified in the file /usr/share/shorewall/actions.std.
#
# In Shorewall 4.4.0, the DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT,
# QUEUE_DEFAULT and NFQUEUE_DEFAULT options were added.
#
# 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
# three are similar for ACCEPT, QUEUE and NFQUEUE policies.
#
# The value applied to these may be:
#
# a) The name of an action. The name may optionally be followed by a
# comma-separated list of parameters enclosed in parentheses if the specified
# action accepts parameters (e.g., 'Drop(audit)').
# c) None or none
#
# Prior to Shorewall 5.1.2, the default values are:
#
# DROP_DEFAULT="Drop"
# REJECT_DEFAULT="Reject"
# BLACKLIST_DEFAULT="Drop" (added in Shorewall 5.1.1)
# ACCEPT_DEFAULT="none"
# QUEUE_DEFAULT="none"
# NFQUEUE_DEFAULT="none"
#
# Beginning with Shorewall 5.1.2, the default value is 'none' for all of
# these. Note that the sample configuration files do, however, provide
# settings for DROP_DEFAULT, BLACKLIST_DEFAULT and REJECT_DEFAULT.
#
# 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
# shorewall-policy(5).
#
# You can pass parameters to the specified action (e.g., myaction(audit,DROP)
# ).
#
# Beginning with Shorewall 4.5.10, the action name can be followed optionally
# by a colon and a log level. The level will be applied to each rule in the
# action or body that does not already have a log level.
#
# Beginning with Shorewall 5.1.2, multiple action[(parameters)][:level]
# specifications may be listed, separated by commas.
#
###############################################################################
# R S H / R C P C O M M A N D S
###############################################################################
RCP_COMMAND='scp ${files} ${root}@${system}:${destination}'
#
# RCP_COMMAND="command"
#
RSH_COMMAND='ssh ${root}@${system} ${command}'
#
# RSH_COMMAND="command"
#
# Earlier generations of Shorewall Lite required that remote root login via
# ssh be enabled in order to use the load and reload commands. Beginning with
# release 3.9.5, you may define an alternative means for accessing the remote
# firewall system. In that release, two new options were added to
# shorewall.conf:
#
# RSH_COMMAND
# RCP_COMMAND
#
# The default values for these are as follows:
#
# RSH_COMMAND: ssh ${root}@${system} ${command}
# RCP_COMMAND: scp ${files} ${root}@${system}:${destination}
#
# Shell variables that will be set when the commands are invoked are as
# follows:
#
# root - root user. Normally root but may be overridden using the '-r' option.
# system - The name/IP address of the remote firewall system.
# command - For RSH_COMMAND, the command to be executed on the firewall system.
# files - For RCP_COMMAND, a space-separated list of files to be copied to the remote firewall system.
# destination - The directory on the remote system that the files are to be copied into.
#
###############################################################################
# F I R E W A L L O P T I O N S
###############################################################################
ACCOUNTING=Yes
#
# ACCOUNTING=[Yes|No]
#
# Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting is enabled
# (see shorewall-accounting(5)). If not specified or set to the empty value,
# ACCOUNTING=Yes is assumed.
#
ACCOUNTING_TABLE=filter
#
# ACCOUNTING_TABLE=[filter|mangle]
#
# Added in Shorewall 4.4.20. This setting determines which Netfilter table
# the accounting rules are added in. By default, ACCOUNTING_TABLE=filter is
# assumed. See also shorewall-accounting(5).
#
ADMINISABSENTMINDED=Yes
#
# ADMINISABSENTMINDED=[Yes|No]
#
# The value of this variable affects Shorewall's stopped state. The behavior
# differs depending on whether shorewall-routestopped(5) or
# shorewall-stoppedrules(5) is used:
#
# routestopped
#
# When ADMINISABSENTMINDED=No, only traffic to/from those addresses
# listed in routestopped is accepted when Shorewall is stopped. When
# ADMINISABSENTMINDED=Yes, in addition to traffic to/from addresses in
# routestopped, connections that were active when Shorewall stopped
# continue to work and all new connections from the firewall system
# itself are allowed.
#
# Note that the routestopped file is not supported in Shorewall 5.0 and
# later versions.
#
# stoppedrules
#
# All existing connections continue to work. To sever all existing
# connections when the firewall is stopped, install the conntrack utility
# and place the command conntrack -F in the stopped user exit (/etc/
# shorewall/stopped).
#
# If ADMINISABSENTMINDED=No, only new connections matching entries in
# stoppedrules are accepted when Shorewall is stopped. Response packets
# and related connections are automatically accepted.
#
# If ADMINISABSENTMINDED=Yes, in addition to connections matching entries
# in stoppedrules, all new connections from the firewall system itself
# are allowed when the firewall is stopped. Response packets and related
# connections are automatically accepted.
#
# If this variable is not set or is given the empty value then
# ADMINISABSENTMINDED=No is assumed.
#
AUTOCOMMENT=Yes
#
# AUTOCOMMENT=[Yes|No]
#
# Formerly named AUTO_COMMENT. If set, if there is not a current comment when
# a macro is invoked, the behavior is as if the first line of the macro file
# was "COMMENT ". If not specified, the AUTO_COMMENT option has a
# default value of 'Yes'.
#
AUTOHELPERS=Yes
#
# AUTOHELPERS=[Yes|No]
#
# Added in Shorewall 4.5.7. When set to Yes (the default), the generated
# ruleset will automatically associate helpers with applications that require
# them (FTP, IRC, etc.). When configuring your firewall on systems running
# kernel 3.5 or later, it is recommended that you:
#
# 1. Set AUTOHELPERS=No.
#
# 2. Modify the HELPERS setting (see below) to list the helpers that you
# need.
#
# 3. Either:
#
# a. Modify shorewall-conntrack (5) to only apply helpers where they are
# required; or
#
# b. Specify the appropriate helper in the HELPER column in
# shorewall-rules (5).
#
# Note
#
# The macros for those applications requiring a helper automatically
# specify the appropriate HELPER where required.
#
AUTOMAKE=Yes
#
# AUTOMAKE=[Yes|No|recursive|depth]
#
# If set, the behavior of the start, reload and restart commands are changed;
# if no files in CONFIG_PATH (see below) have been changed since the last
# successful start, reload or restart command, then the compilation step is
# skipped and the compiled script that executed the last start, reload or
# restart command is used. If not specified, the default is AUTOMAKE=No.
#
# The setting of the AUTOMAKE option is ignored if the start, reload or
# restart command includes a directory name (e.g., shorewall restart /etc/
# shorewall.new).
#
# When AUTOMAKE=Yes, each directory in the CONFIG_PATH was originally
# searched recursively for files newer than the compiled script. That was
# changed in Shorewall 5.1.10.2 such that only the listed directories
# themselves were searched. That broke some configurations that played tricks
# with embedded SHELL such as "SHELL cat /etc/shorewall/rules.d/loc/*.rules".
# Prior to 5.1.10.2, a change to a file in or adding a file to /etc/shorewall
# /rules.d/loc/ would trigger recompilation. Beginning with 5.1.10.2, such
# changes would not trigger recompilation. Beginning with Shorewall 5.2.0,
# the pre-5.1.10.2 behavior can be obtained by setting AUTOMAKE=recursive.
#
# Also beginning with Shorewall 5.2.0, AUTOMAKE may be set to a numeric depth
# which specifies how deeply each listed directory is to be searched.
# AUTOMAKE=1 only searches each directory itself and is equivalent to
# AUTOMAKE=Yes. AUTOMAKE=2 will search each directory and its immediate
# sub-directories; AUTOMAKE=3 will search each directory, each of its
# immediate sub-directories, and each of their immediate sub-directories,
# etc.
#
BALANCE_PROVIDERS=No
#
# BALANCE_PROVIDERS=[Yes|No]
#
# Added in Shorewall 5.1.1. When USE_DEFAULT_RT=Yes, this option determines
# whether the balance provider option (see shorewall-providers(5)) is the
# default. When BALANCE_PROVIDERS=Yes, then the balance option is assumed
# unless the fallback, loose, load or tproxy option is specified. If this
# option is not set or is set to the empty value, then the default value is
# the value of USE_DEFAULT_RT.
#
BASIC_FILTERS=No
#
# BASIC_FILTERS=[Yes|No]
#
# Added in Shorewall-4.6.0. When set to Yes, causes entries in
# shorewall-tcfilters(5) to generate a basic filter rather than a u32 filter.
# This setting requires the Basic Ematch capability in your kernel and
# iptables.
#
# Note
#
# One of the advantages of basic filters is that ipset matches are supported
# in newer iproute2 and kernel versions. Because Shorewall cannot reliably
# detect this capability, use of basic filters is controlled by this option.
#
# The default value is No which causes u32 filters to be generated.
#
BLACKLIST="NEW,INVALID,UNTRACKED"
#
# BLACKLIST=[{ALL|state[,...]}]
#
# where state is one of NEW, ESTABLISHED, RELATED, INVALID,or UNTRACKED.
#
# Added in Shorewall 4.5.13 to replace the BLACKLISTNEWONLY option. Specifies
# the connection tracking states that are to be subject to blacklist
# screening. If BLACKLIST is not specified then the states subject to
# blacklisting are NEW,ESTABLISHED,INVALID,UNTRACKED.
#
# ALL sends all packets through the blacklist chains.
#
# Note: The ESTABLISHED state may not be specified if FASTACCEPT=Yes is
# specified.
#
CLAMPMSS=No
#
# CLAMPMSS=[Yes|No|value]
#
# This parameter enables the TCP Clamp MSS to PMTU feature of Netfilter and
# is usually required when your internet connection is through PPPoE or PPTP.
# If set to Yes or yes, the feature is enabled. If left blank or set to No or
# no, the feature is not enabled.
#
# Important: This option requires CONFIG_IP_NF_TARGET_TCPMSS in your kernel.
#
# You may also set CLAMPMSS to a numeric value (e.g., CLAMPMSS=1400). This
# will set the MSS field in TCP SYN packets going through the firewall to the
# value that you specify.
#
CLEAR_TC=No
#
# CLEAR_TC=[Yes|No]
#
# If this option is set to No then Shorewall won't clear the current traffic
# control rules during [re]start or reload. This setting is intended for use
# by people who prefer to configure traffic shaping when the network
# interfaces come up rather than when the firewall is started. If that is
# what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not supply
# an /etc/shorewall/tcstart file. That way, your traffic shaping rules can
# still use the “fwmark” classifier based on packet marking defined in
# shorewall-tcrules(5). If not specified, CLEAR_TC=Yes is assumed.
#
# Warning
#
# When you specify TC_ENABLED=shared (see below), then you should also
# specify CLEAR_TC=No.
#
COMPLETE=No
#
# COMPLETE=[Yes|No]
#
# Added in Shorewall 4.4.12. When you set this option to Yes, you are
# asserting that the configuration is complete so that your set of zones
# encompasses any hosts that can send or receive traffic to/from/through the
# firewall. This causes Shorewall to omit the rules that catch packets in
# which the source or destination IP address is outside of any of your zones.
# Default is No. It is recommended that this option only be set to Yes if:
#
# □ You have defined an interface whose effective physical setting is '+'.
#
# □ That interface is assigned to a zone.
#
# □ You have no CONTINUE policies or rules.
#
DEFER_DNS_RESOLUTION=Yes
#
# DEFER_DNS_RESOLUTION=[Yes|No]
#
# Added in Shorewall 4.5.12. When set to 'Yes' (the default), DNS names are
# validated in the compiler and then passed on to the generated script where
# they are resolved by ip[6]tables-restore. This is an advantage if you use
# AUTOMAKE=Yes and the IP address associated with the DNS name is subject to
# change. When DEFER_DNS_RESOLUTION=No, DNS names are converted into IP
# addresses by the compiler. This has the advantage that when AUTOMAKE=Yes,
# the start, reload and restart commands will succeed even if no DNS server
# is reachable (assuming that the configuration hasn't changed since the
# compiled script was last generated).
#
# Important
#
# When DEFER_DNS_RESOLUTION=No and AUTOMAKE=Yes and a DNS change makes it
# necessary to recompile an existing firewall script, the -c option must be
# used with the reload or restart command to force recompilation.
#
DELETE_THEN_ADD=Yes
#
# DELETE_THEN_ADD={Yes|No}
#
# If set to Yes (the default value), entries in the /etc/shorewall[6]/rtrules
# files cause an 'ip rule del' command to be generated in addition to an 'ip
# rule add' command. Setting this option to No, causes the 'ip rule del'
# command to be omitted.
#
DONT_LOAD=
#
# DONT_LOAD=[module[,module]...]
#
# Causes Shorewall to not load the listed kernel modules.
#
DYNAMIC_BLACKLIST=Yes
#
# DYNAMIC_BLACKLIST={Yes|No||ipset[-only][,option[,...]][:[setname][:log_level|:l
# og_tag]]]}
#
# Added in Shorewall 4.4.7. When set to No or no, chain-based dynamic
# blacklisting using shorewall [-6] [-l] drop, shorewall [-6] [-l] reject,
# shorewall logdrop and shorewall [-6] [-l] logreject is disabled. Default is
# Yes. Beginning with Shorewall 5.0.8, ipset-based dynamic blacklisting using
# the shorewall blacklist command is also supported. The name of the set (
# setname) and the level (log_level), if any, at which blacklisted traffic is
# to be logged may also be specified. The default IPv4 set name is SW_DBL4
# and the default IPv6 set name is SW_DBL6. The default log level is none (no
# logging). If ipset-only is given, then chain-based dynamic blacklisting is
# disabled just as if DYNAMIC_BLACKLISTING=No had been specified.
#
# Possible options are:
#
# src-dst
#
# Normally, only packets whose source address matches an entry in the
# ipset are dropped. If src-dst is included, then packets whose
# destination address matches an entry in the ipset are also dropped.
#
# disconnect
#
# The disconnect option was added in Shorewall 5.0.13 and requires that
# the conntrack utility be installed on the firewall system. When an
# address is blacklisted using the blacklist command, all connections
# originating from that address are disconnected. if the src-dst option
# was also specified, then all connections to that address are also
# disconnected.
#
# timeout=seconds
#
# Added in Shorewall 5.0.13. Normally, Shorewall creates the dynamic
# blacklisting ipset with timeout 0 which means that entries are
# permanent. If you want entries in the set that are not accessed for a
# period of time to be deleted from the set, you may specify that period
# using this option. Note that the blacklist command can override the
# ipset's timeout setting.
#
# Important
#
# Once the dynamic blacklisting ipset has been created, changing this
# option setting requires a complete restart of the firewall; shorewall
# [-6] restart if RESTART=restart, otherwise shorewall [-6] [-l] stop &&
# shorewall [-6] [-l] start
#
# When ipset-based dynamic blacklisting is enabled, the contents of the
# blacklist will be preserved over stop/reboot/start sequences if SAVE_IPSETS
# =Yes, SAVE_IPSETS=ipv4 or if setname is included in the list of sets to be
# saved in SAVE_IPSETS.
#
EXPAND_POLICIES=Yes
#
# EXPAND_POLICIES={Yes|No}
#
# Normally, when the SOURCE or DEST columns in shorewall-policy(5) contains
# 'all', a single policy chain is created and thes policy is enforced in that
# chain. For example, if the policy entry is
#
# #SOURCE DEST POLICY LOG
# # LEVEL
# net all DROP info
#
# then the chain name is 'net-all' ('net2all if ZONE2ZONE=2) which is also
# the chain named in Shorewall log messages generated as a result of the
# policy. If EXPAND_POLICIES=Yes, then Shorewall will create a separate chain
# for each pair of zones covered by the policy. This makes the resulting log
# messages easier to interpret since the chain in the messages will have a
# name of the form 'a2b' where 'a' is the SOURCE zone and 'b' is the DEST
# zone.
#
EXPORTMODULES=Yes
#
# EXPORTMODULES=[Yes|No]
#
# Added in Shorewall 4.4.17. When set to Yes when compiling for use by
# Shorewall Lite (shorewall [-6] remote-start, shorewall [-6] remote-reload,
# shorewall [-6] remote-restart or shorewall [-6] export commands), the
# compiler will copy the modules or helpers file from the administrative
# system into the script. When set to No or not specified, the compiler will
# not copy the modules or helpers file from /usr/share/shorewall[6] but will
# copy those found in another location on the CONFIG_PATH.
#
# When compiling for direct use by Shorewall, causes the contents of the
# local module or helpers file to be copied into the compiled script. When
# set to No or not set, the compiled script reads the file itself.
#
FASTACCEPT=No
#
# FASTACCEPT={Yes|No}
#
# 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 'loc-net' or 'loc2net'
# chain, depending on the setting of ZONE2ZONE (see below).
#
# If you set FASTACCEPT=Yes, then ESTABLISHED/RELATED 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
# shorewall-rules(5).
#
FORWARD_CLEAR_MARK=Yes
#
# FORWARD_CLEAR_MARK={Yes|No}
#
# Added in Shorewall 4.4.11. Traditionally, Shorewall has cleared the packet
# mark in the first rule in the mangle FORWARD chain. This behavior is
# maintained with the default setting of this option (FORWARD_CLEAR_MARK=
# Yes). If FORWARD_CLEAR_MARK is set to 'No', packet marks set in the mangle
# PREROUTING chain are retained in the FORWARD chains.
#
HELPERS=
#
# HELPERS=[helper[,helper...]]
#
# Added in Shorewall 4.5.7. This option specifies a comma-separated list
# naming the Netfilter application helpers that are to be enabled. If not
# specified, the default is to enable all helpers.
#
# Possible values for helper are:
#
# □ amanda
#
# □ ftp
#
# □ h323
#
# □ irc
#
# □ netbios-ns
#
# □ none - This special value was added in Shorewall 4.5.16 and indicates
# that no helpers are to be enabled. It also prevents the compiler for
# probing for helper support; such probing generates messages on the
# system log of the form "xt_CT: No such helper XXX" where XXX is the
# helper name. When used, none must be the only helper specified.
#
# □ pptp
#
# □ sane
#
# □ sip
#
# □ snmp
#
# □ tftp
#
# When HELPERS is specified on a system running Kernel 3.5.0 or later,
# automatic association of helpers to connections is disabled.
#
IGNOREUNKNOWNVARIABLES=No
#
# IGNOREUNKNOWNVARIABLES=[Yes|No]
#
# Added in Shorewall 4.5.11. Normally, if an unknown shell variable is
# encountered in a configuration file (except in ?IF and ?ELSIF directives),
# the compiler raises a fatal error. If IGNOREUNKNOWNVARIABLES is set to Yes,
# then such variables simply expand to an empty string. Default is No.
#
IMPLICIT_CONTINUE=No
#
# IMPLICIT_CONTINUE={Yes|No}
#
# When this option is set to Yes, it causes subzones to be treated
# differently with respect to policies.
#
# Subzones are defined by following their name with ":" and a list of parent
# zones (in shorewall-zones(5)). Normally, you want to have a set of special
# rules for the subzone and if a connection doesn't match any of those
# subzone-specific rules then you want the parent zone rules and policies to
# be applied; see shorewall-nesting(5). With IMPLICIT_CONTINUE=Yes, that
# happens automatically.
#
# If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set, then subzones
# are not subject to this special treatment. With IMPLICIT_CONTINUE=Yes, an
# implicit CONTINUE policy may be overridden by including an explicit policy
# (one that does not specify "all" in either the SOURCE or the DEST columns).
#
IPSET_WARNINGS=Yes
#
# IPSET_WARNINGS={Yes|No}
#
# Added in Shorewall 4.5.2. Default is Yes. When set, causes the rules
# compiler to issue a warning when:
#
# □ The compiler is being run by root and an ipset specified in the
# configuration does not exists. Only one warning is issued for each
# missing ipset.
#
# □ When [src] is specified in a destination column and when [dst] is
# specified in a source column.
#
IP_FORWARDING=Keep
#
# IP_FORWARDING=[On|Off|Keep]
#
# This IPv4 parameter determines whether Shorewall enables or disables IPv4
# Packet Forwarding (/proc/sys/net/ipv4/ip_forward). In an IPv6
# configuration, this parameter determines the setting of /proc/sys/net/ipv6/
# config/all/ip_forwarding.
#
# Possible values are:
#
# On or on
#
# packet forwarding will be enabled.
#
# Off or off
#
# packet forwarding will be disabled.
#
# Keep or keep
#
# Shorewall will neither enable nor disable packet forwarding.
#
# If this variable is not set or is given an empty value (IP_FORWARD="") then
# IP_FORWARD=On is assumed.
#
KEEP_RT_TABLES=Yes
#
# KEEP_RT_TABLES={Yes|No}
#
# IPv4:
#
# When set to Yes, this option prevents generated scripts from altering
# the /etc/iproute2/rt_tables database when there are entries in /etc/
# shorewall/providers. If you set this option to Yes while Shorewall
# (Shorewall-lite) is running, you should remove the file /var/lib/
# shorewall/rt_tables (/var/lib/shorewall-lite/rt_tables) before your
# next stop, restore, reload or restart command.
#
# IPv6:
#
# When set to Yes, this option prevents scripts generated by Shorewall6
# from altering the /etc/iproute2/rt_tables database when there are
# entries in /etc/shorewall6/providers. If you set this option to Yes
# while Shorewall6 (Shorewall6-lite) is running, you should remove the
# file /var/lib/shorewall6/rt_tables (/var/lib/shorewall6-lite/rt_tables)
# before your next stop, restore, reload or restart command.
#
# Important
#
# When both IPv4 and IPv6 Shorewall configurations are present,
# KEEP_RT_TABLES=No should be specified in only one of the two configurations
# unless the two provider configurations are identical with respect to
# interface and provider names and numbers.
#
# The default is KEEP_RT_TABLES=No.
#
MACLIST_TABLE=filter
#
# MACLIST_TABLE=[filter|mangle]
#
# Normally, MAC verification occurs in the filter table (INPUT and FORWARD)
# chains. When forwarding a packet from an interface with MAC verification to
# a bridge interface, that doesn't work.
#
# This problem can be worked around by setting MACLIST_TABLE=mangle which
# will cause Mac verification to occur out of the PREROUTING chain. Because
# REJECT isn't available in that environment, you may not specify
# MACLIST_DISPOSITION=REJECT or MACLIST_DISPOSITION=A_REJECT with
# MACLIST_TABLE=mangle.
#
MACLIST_TTL=
#
# MACLIST_TTL=[number]
#
# The performance of configurations with a large numbers of entries in
# shorewall-maclist(5) can be improved by setting the MACLIST_TTL variable in
# shorewall[6].conf(5).
#
# If your iptables and kernel support the "Recent Match" (see the output of
# "shorewall check" near the top), you can cache the results of a 'maclist'
# file lookup and thus reduce the overhead associated with MAC Verification.
#
# When a new connection arrives from a 'maclist' interface, the packet passes
# through then list of entries for that interface in shorewall-maclist(5). If
# there is a match then the source IP address is added to the 'Recent' set
# for that interface. Subsequent connection attempts from that IP address
# occurring within $MACLIST_TTL seconds will be accepted without having to
# scan all of the entries. After $MACLIST_TTL from the first accepted
# connection request from an IP address, the next connection request from
# that IP address will be checked against the entire list.
#
# If MACLIST_TTL is not specified or is specified as empty (e.g, MACLIST_TTL=
# "" or is specified as zero then 'maclist' lookups will not be cached).
#
MANGLE_ENABLED=Yes
#
# MANGLE_ENABLED=[Yes|No]
#
# Determines whether Shorewall will generate rules in the Netfilter mangle
# table. Setting MANGLE_ENABLED=No disables all Shorewall features that
# require the mangle table. The default is MANGLE_ENABLED=Yes.
#
MARK_IN_FORWARD_CHAIN=No
#
# MARK_IN_FORWARD_CHAIN=[Yes|No]
#
# If your kernel has a FORWARD chain in the mangle table, you may set
# MARK_IN_FORWARD_CHAIN=Yes to cause the marking specified in the tcrules
# file to occur in that chain rather than in the PREROUTING chain. This
# permits you to mark inbound traffic based on its destination address when
# DNAT is in use. To determine if your kernel has a FORWARD chain in the
# mangle table, use the shorewall [-6] show mangle command; if a FORWARD
# chain is displayed then your kernel will support this option. If this
# option is not specified or if it is given the empty value (e.g.,
# MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed.
#
MINIUPNPD=No
#
# MINIUPNPD=[Yes|No]
#
# Added in Shorewall 5.0.8. If set to Yes, Shorewall will create a chain in
# the nat table named MINIUPNPD-POSTROUTING and will add jumps from
# POSTROUTING to that chain for each interface with the upnpd option
# specified. Default is No.
#
MUTEX_TIMEOUT=60
#
# MUTEX_TIMEOUT=[seconds]
#
# The value of this variable determines the number of seconds that programs
# will wait for exclusive access to the Shorewall[6] lock file. After the
# number of seconds corresponding to the value of this variable, programs
# will assume that the last program to hold the lock died without releasing
# the lock.
#
# If not set or set to the empty value, a value of 60 (60 seconds) is
# assumed.
#
# An appropriate value for this parameter would be twice the length of time
# that it takes your firewall system to process a shorewall [-6] restart
# command.
#
OPTIMIZE=All
#
# OPTIMIZE=[value]
#
# The specified value enables certain optimizations. Each optimization
# category is associated with a power of two. To enable multiple optimization
# categories, simply add their corresponding numbers together.
#
# Beginning with Shorewall 4.5.20, you may specify OPTIMIZE=All to enable all
# optimization categories, and you may also specify OPTIMIZE=None to disable
# optimization.
#
# □ Optimization category 1 - Traditionally, Shorewall has created rules
# for the complete matrix of host groups defined by the zones, interfaces
# and hosts files. Any traffic that didn't correspond to an element of
# that matrix was rejected in one of the built-in chains. When the matrix
# is sparse, this results in lots of largely useless rules.
#
# These extra rules can be eliminated by setting the 1 bit in OPTIMIZE.
#
# The 1 bit setting also controls the suppression of redundant wildcard
# rules (those specifying "all" in the SOURCE or DEST column). A wildcard
# rule is considered to be redundant when it has the same ACTION and Log
# Level as the applicable policy.
#
# Note
#
# Optimization level 1 is ignored when optimization level 4 is also
# selected, since level 4 performs similar optimizations in a more robust
# way.
#
# □ Optimization category 2 - Added in Shorewall 4.4.7. When set,
# suppresses superfluous ACCEPT rules in a policy chain that implements
# an ACCEPT policy. Any ACCEPT rules that immediately precede the final
# blanket ACCEPT rule in the chain are now omitted.
#
# □ Optimization category 4 - Added in Shorewall 4.4.7. When set, causes
# short chains (those with less than 2 rules) to be optimized away. The
# following chains are excluded from optimization:
#
# ☆ accounting chains (unless OPTIMIZE_ACCOUNTING=Yes)
#
# ☆ action chains (user-defined)
#
# ☆ 'blacklst' chain
#
# ☆ dynamic
#
# ☆ forwardUPnP
#
# ☆ UPnP (nat table)
#
# Additionally:
#
# ☆ If a built-in chain has a single rule that branches to a second
# chain, then the rules from the second chain are moved to the
# built-in chain and the target chain is omitted.
#
# ☆ Chains with no references are deleted.
#
# ☆ Accounting chains are subject to optimization if the
# OPTIMIZE_ACCOUNTING option is set to 'Yes'.
#
# ☆ If a chain ends with an unconditional branch to a second chain
# (other than to 'reject'), then the branch is deleted from the first
# chain and the rules from the second chain are appended to it.
#
# An additional optimization was added in Shorewall 4.5.4. If the last
# rule in a chain is an unqualified jump to a simple target, then all
# immediately preceding rules with the same simple target are omitted.
#
# For example, consider this chain:
#
# -A fw-net -p udp --dport 67:68 -j ACCEPT
# -A fw-net -p udp --sport 1194 -j ACCEPT
# -A fw-net -p 41 -j ACCEPT
# -A fw-net -j ACCEPT
#
# Since all of the rules are jumps to the simple target ACCEPT, this
# chain is totally optimized away and jumps to the chain are replace with
# jumps to ACCEPT.
#
# □ Optimization category 8 - Added in Shorewall 4.4.9. When set, causes
# chains with identical rules to be collapsed into a single chain.
#
# Warning
#
# While Optimization category 8 can significantly reduce the size of the
# generated iptables ruleset, it can also take significant system
# resources during compilation. If you find that compilation takes an
# unreasonably long time, try disabling this category by setting OPTIMIZE
# =23.
#
# □ Optimization category 16 - Added in Shorewall 4.4.26. When set, causes
# sequences of compatible rules to be combined into a single rule. Rules
# are considered compatible if they differ only in their destination
# ports and comments.
#
# A sequence of compatible rules is often generated when macros are
# invoked in sequence.
#
# The ability to combine adjacent rules is limited by two factors:
#
# ☆ Destination port lists may only be combined up to a maximum of 15
# ports, where a port-pair counts as two ports.
#
# ☆ Rules may only be combined until the length of their concatenated
# comment reaches 255 characters.
#
# When either of these limits would be exceeded, the current combined
# rule is emitted and the compiler attempts to combine rules beginning
# with the one that would have exceeded the limit. Adjacent combined
# comments are separated by ', '. Empty comments at the front of a group
# of combined comments are replaced by 'Others and'. Empty comments at
# the end of a group of combined comments are replaced by 'and others'.
#
# Beginning in Shorewall 4.5.10, this option also suppresses duplicate
# adjacent rules and duplicate non-adjacent rules that don't include mark
# , connmark, dscp, ecn, set, tos or u32 matches.
#
# Example 1:
#
# Rules with comments "FOO", and "BAR" would result in the
# combined comment "FOO and others, BAR".
#
# Example 2:
#
# Rules with comments , "FOO" and "BAR" would result in the
# combined comment "Others and FOO, BAR". Note: Optimize level 16
# requires "Extended Multi-port Match" in your iptables and kernel.
#
# In versions prior to 5.1.0, the default value is zero which disables all
# optimizations. Beginning with Shorewall 5.1.0, the default value is All
# which enables all optimizations.
#
OPTIMIZE_ACCOUNTING=No
#
# OPTIMIZE_ACCOUNTING=[Yes|No]
#
# Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting changes are
# subject to optimization (OPTIMIZE=4,5,6 or 7). If not specified or set to
# the empty value, OPTIMIZE_ACCOUNTING=No is assumed.
#
PERL_HASH_SEED=0
#
# PERL_HASH_SEED=seed|random
#
# Added in Shorewall 5.1.4. Sets the Perl hash seed (an integer in the range
# 0-99999) when running the Shorewall rules compiler. If not specified, the
# value 0 is assumed. If random is specified, a random seed will be chosed by
# Perl. See perlsec(1) for additional information.
#
REJECT_ACTION=
#
# REJECT_ACTION=action
#
# Added in Shorewall 4.5.21. When a REJECT target is specified, Shorewall
# normally handles the response as follows:
#
# □ If the destination address of the packet is a broadcast or multicast
# address, the packet is dropped.
#
# □ if the protocol is ICMP (2) then the packet is dropped.
#
# □ if the protocol is TCP (6) then the packet is rejected with an RST.
#
# □ if the protocol is UDP (17) then the packet is rejected with an
# 'port-unreachable' ICMP.
#
# □ if the protocol is ICMP (1) then the packet is rejected with a
# 'host-unreachable' ICMP.
#
# □ if the protocol is ICMP6 (1) then the packet is rejected with a
# 'icmp6-addr-unreachable' ICMP6.
#
# □ otherwise, the packet is rejected with a 'host-prohibited' ICMP.
#
# You can modify this behavior by implementing your own action that handles
# REJECT and specifying it's name in this option. The nolog and noinline
# options will automatically be assumed for the specified action.
#
# The following action implements the default reject action:
#
# ?format 2
# #TARGET SOURCE DEST PROTO
# Broadcast(DROP) - - -
# DROP - - 2
# INLINE - - 6 ;; -j REJECT --reject-with tcp-reset
# ?if __ENHANCED_REJECT
# INLINE - - 17 ;; -j REJECT
# ?if __IPV4
# INLINE - - 1 ;; -j REJECT --reject-with icmp-host-unreachable
# INLINE - - - ;; -j REJECT --reject-with icmp-host-prohibited
# ?else
# INLINE - - 58 ;; -j REJECT --reject-with icmp6-addr-unreachable
# INLINE - - - ;; -j REJECT --reject-with icmp6-adm-prohibited
# ?endif
# ?else
# INLINE - - - ;; -j REJECT
# ?endif
#
RENAME_COMBINED=Yes
#
# RENAME_COMBINED=[Yes|No]
#
# Added in Shorewall 5.2.0. Traditionally, when OPTIMIZE category 8 is
# enabled, identical chains are combined under a name beginning with '~comb'
# or '~blacklist'. This behavior is maintained under the default setting
# RENAME_COMBINED=Yes. If RENAMED_COMBINED=No, the chains are combined under
# the original name of one of the chains.
#
REQUIRE_INTERFACE=No
#
# REQUIRE_INTERFACE=[Yes|No]
#
# Added in Shorewall 4.4.10. The default is No. If set to Yes, at least one
# optional interface must be up in order for the firewall to be in the
# started state. Intended to be used with the Shorewall Init Package.
#
RESTART=restart
#
# RESTART=[restart|reload]
#
# Added in Shorewall 5.0.1 to replace LEGACY_RESTART which was added in
# Shorewall 5.0.0. In that release, the reload command was redefined to do
# what restart had done in earlier releases and restart became a true restart
# (equivalent to stop followed by start). When RESTART=reload, the restart
# command performs the same operation as the reload command making it
# compatible with earlier releases. If not specified, RESTART=reload is
# assumed.
#
RESTORE_DEFAULT_ROUTE=Yes
#
# RESTORE_DEFAULT_ROUTE=[Yes|No]
#
# This option determines whether to restore the default route saved when here
# are 'balance' providers defined but all of them are down.
#
# The default is RESTORE_DEFAULT_ROUTE=Yes which preserves the pre-4.2.6
# behavior.
#
# RESTORE_DEFAULT_ROUTE=No is appropriate when you don't want a default route
# in the main table (USE_DEFAULT_RT=No) or in the default table
# (USE_DEFAULT_RT=Yes) when there are no balance providers available. In that
# case, RESTORE_DEFAULT_ROUTE=No will cause any default route in the relevant
# table to be deleted.
#
RESTORE_ROUTEMARKS=Yes
#
# RESTORE_ROUTEMARKS=[Yes|No]
#
# Added in Shorewall 4.5.9. When set to Yes (the default), provider marks are
# restored unconditionally at the top of the mangle OUTPUT and PREROUTING
# chains, even if the saved mark is zero. When this option is set to No, the
# mark is restored only if it is non-zero. If you have problems with IPSEC
# ESP packets not being routed correctly on output, try setting this option
# to No.
#
SAVE_IPSETS=No
#
# SAVE_IPSETS={Yes|No|ipv4|setlist}
#
# Re-enabled in Shorewall 4.4.6. If SAVE_IPSETS=Yes, then the current
# contents of your ipsets will be saved by the shorewall stop and shorewall
# save commands and restored by the shorewall start and shorewall restore
# commands.
#
# Beginning with Shorewall 4.6.4, you can restrict the set of ipsets saved by
# specifying a setlist (a comma-separated list of ipv4 ipset names). You may
# also restrict the saved sets to just the ipv4 ones by specifying ipv4.
#
TC_ENABLED=Shared
#
# TC_ENABLED=[Yes|No|Internal|Simple|Shared]
#
# If you say Yes or yes here, Shorewall will use a script that you supply to
# configure traffic shaping. The script must be named 'tcstart' and must be
# placed in a directory on your CONFIG_PATH.
#
# If you say No or no then traffic shaping is not enabled.
#
# If you set TC_ENABLED=Simple (Shorewall 4.4.6 and later), simple traffic
# shaping using shorewall-tcinterfaces(5) and shorewall-tcpri(5) is enabled.
#
# If you set TC_ENABLED=Internal or internal or leave the option empty then
# Shorewall will use its builtin traffic shaper (tc4shorewall written by Arne
# Bernin.
#
# Beginning with Shorewall 4.4.15, you can set TC_ENABLED=Shared. This allows
# you to configure the tcdevices and tcclasses in your Shorewall6
# configuration yet make them available to the compiler when compiling your
# Shorewall configuration. In addition to setting TC_ENABLED=Shared, you need
# to create symbolic links from your Shorewall configuration directory
# (normally /etc/shorewall/) to the tcdevices and tcclasses files in your
# Shorewall6 configuration directory (normally /etc/shorewall6/).
#
TC_EXPERT=No
#
# TC_EXPERT={Yes|No}
#
# Normally, Shorewall tries to protect users from themselves by preventing
# PREROUTING and OUTPUT tcrules from being applied to packets that have been
# marked by the 'track' option in shorewall-providers(5).
#
# If you know what you are doing, you can set TC_EXPERT=Yes and Shorewall
# will not include these cautionary checks.
#
TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2"
#
# TC_PRIOMAP=map
#
# Added in Shorewall 4.4.6. Determines the mapping of a packet's TOS field to
# priority bands. See shorewall-tcpri(5). The map consists of 16
# space-separated digits with values 1, 2 or 3. A value of 1 corresponds to
# Linux priority 0, 2 to Linux priority 1, and 3 to Linux Priority 2. The
# first entry gives the priority of TOS value 0, the second of TOS value 1,
# and so on. See tc-prio(8) for additional information.
#
# The default setting is TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2".
#
TRACK_PROVIDERS=Yes
#
# TRACK_PROVIDERS={Yes|No}
#
# Added in Shorewall 4.4.3. When set to Yes, causes the track option to be
# assumed on all providers defined in shorewall-providers(5). May be
# overridden on an individual provider through use of the notrack option. The
# default value is 'No'.
#
# Beginning in Shorewall 4.4.6, setting this option to 'Yes' also simplifies
# PREROUTING rules in shorewall-tcrules(5). Previously, when TC_EXPERT=No,
# packets arriving through 'tracked' provider interfaces were unconditionally
# passed to the PREROUTING tcrules. This was done so that tcrules could reset
# the packet mark to zero, thus allowing the packet to be routed using the
# 'main' routing table. Using the main table allowed dynamic routes (such as
# those added for VPNs) to be effective. The rtrules file was created to
# provide a better alternative to clearing the packet mark. As a consequence,
# passing these packets to PREROUTING complicates things without providing
# any real benefit. Beginning with Shorewall 4.4.6, when TRACK_PROVIDERS=Yes
# and TC_EXPERT=No, packets arriving through 'tracked' interfaces will not be
# passed to the PREROUTING rules. Since TRACK_PROVIDERS was just introduced
# in 4.4.3, this change should be transparent to most, if not all, users.
#
TRACK_RULES=No
#
# TRACK_RULES={Yes|No|File}
#
# Added in Shorewall 4.5.20. If set to Yes, causes the compiler to add a
# comment to iptables rules to indicate the file name and line number of the
# configuration entry that generated the rule. If set to No (the default),
# then no such comments are added.
#
# Setting this option to Yes requires the Comments capability in iptables and
# kernel.
#
# Beginning with Shorewall 5.0.5, the option may also be set to File. That
# setting causes similar comments to be added to the .iptables-restore-input
# file, which is normally created in /var/lib/shorewall.
#
USE_DEFAULT_RT=Yes
#
# USE_DEFAULT_RT=[Yes|No]
#
# When set to 'Yes', this option causes the Shorewall multi-ISP feature to
# create a set of routing rules which are resilient to changes in the main
# routing table. Such changes can occur for a number of reasons, VPNs going
# up and down being an example. The idea is to send packets through the main
# table prior to applying any of the Shorewall-generated routing rules. So
# changes to the main table will affect the routing of packets by default.
#
# When USE_DEFAULT_RT=Yes:
#
# 1. Both the DUPLICATE and the COPY columns in providers(5) file must
# remain empty (or contain "-").
#
# 2. The default route is added to the the 'default' table rather than to
# the main table.
#
# 3. If running Shorewall 5.1.0 or earlier or if BALANCE_PROVIDERS=Yes
# (Shorewall 5.1.1 or later), then the balance provider option is assumed
# unless the fallback, loose, load or tproxy option is specified.
#
# 4. Packets are sent through the main routing table by a rule with priority
# 999. In shorewall-rtrules(5), the range 1-998 may be used for inserting
# rules that bypass the main table.
#
# 5. All provider gateways must be specified explicitly in the GATEWAY
# column. detect may not be specified.
#
# Note
#
# detect may be specified for interfaces whose configuration is managed
# by dhcpcd. Shorewall will use dhcpcd's database to find the interface's
# gateway.
#
# 6. You should disable all default route management outside of Shorewall.
# If a default route is added to the main table while Shorewall is
# started, then all policy routing will stop working (except for those
# routing rules in the priority range 1-998).
#
# Prior to Shorewall 4.6.0, if USE_DEFAULT_RT was not set or if it was set to
# the empty string then USE_DEFAULT_RT=No was assumed. Beginning with
# Shorewall 4.6.0, the default is USE_DEFAULT_RT=Yes and use of
# USE_DEFAULT_RT=No is deprecated.
#
# Warning
#
# The enable, disable and reenable commands do not work correctly when
# USE_DEFAULT_RT=No.
#
USE_NFLOG_SIZE=No
#
# USE_NFLOG_SIZE=[Yes|No]
#
# Added in Shorewall 5.1.5. The second parameter to the NFLOG target
# specifies how many bytes of the packet to copy to the log; if omitted or if
# supplied as zero, the entire packet is copied. This feature has
# traditionally been implemented using the --nflog-range option to the NFLOG
# iptables target. Unfortuntely, the --nflog-range option never worked (the
# entire packet was always copied). To deal with this issue, the Netfilter
# team:
#
# □ Added a warning message when --nflog-range is used
#
# □ Added --nflog-size which works like --nflog-range was intended to work.
#
# When USE_NFLOG_SIZE=Yes, Shorewall will attempt to use the new --nflog-size
# feature. If that feature is not available in the running kernel and ip[6]
# tables, an error is raised.
#
# When USE_NFLOG_SIZE is not supplied, USE_NFLOG_SIZE=No is assumed. When
# USE_NFLOG_SIZE is added by shorewall update, it is added with setting No.
#
USE_PHYSICAL_NAMES=No
#
# USE_PHYSICAL_NAMES=[Yes|No]
#
# Added in Shorewall 4.4.27. Normally, when Shorewall creates a Netfilter
# chain that relates to an interface, it uses the interface's logical name as
# the base of the chain name. For example, if the logical name for an
# interface is OAKLAND, then the input chain for traffic arriving on that
# interface would be 'OAKLAND_in'. If this option is set to Yes, then the
# physical name of the interface will be used the base of the chain name.
#
USE_RT_NAMES=No
#
# USE_RT_NAMES=[Yes|No]
#
# Added in Shorewall 4.5.15. When set to 'Yes', Shorewall will use routing
# table (provider) names in the generated script rather than table numbers.
# When set to 'No' (the default), routing table numbers will be used.
#
# Caution
#
# If you set USE_RT_NAMES=Yes and KEEP_RT_TABLES=Yes, then you must insure
# that all of your providers have entries in /etc/iproute2/rt_tables as well
# as the following entries:
#
# 255 local
# 254 main
# 253 default
# 250 balance
# 0 unspec
#
# Without these entries, the firewall will fail to start.
#
VERBOSE_MESSAGES=Yes
#
# VERBOSE_MESSAGES=[Yes|No]
#
# Added in Shorewall 5.0.9. When Yes (the default), messages produced by the
# ?INFO and ?WARNING directives include the filename and linenumber of the
# directive. When set to No, that additional information is omitted. The
# setting may be overridden on a directive by directive basis by following ?
# INFO or ?WARNING with '!' (no intervening white space).
#
WARNOLDCAPVERSION=Yes
#
# WARNOLDCAPVERSION=[Yes|No]
#
# Added in Shorewall 4.5.12. When set to Yes (the default), the compiler
# issues a warning when it finds a capabilities file that doesn't specify all
# of the capabilities supported by the compiler. When WARNOLDCAPVERSION is
# set to No, no warning is issued.
#
WORKAROUNDS=No
#
# WORKAROUNDS=[Yes|No]
#
# Added in Shorewall 4.6.11. Over time, there have been a number of changes
# in Shorewall that work around defects in other products such as iptables
# and ipset. When WORKAROUNDS=Yes, these workarounds are enabled; when
# WORKAROUNDS=No, they are disabled. If not specified or if specified as
# empty, WORKAROUNDS=Yes is assumed.
#
# Warning
#
# Do not set WORKAROUNDS=Yes if you need to be able to use
# Shorewall-generated scripts (such as created by the save command) built by
# Shorewall 4.4.7 or older.
#
ZERO_MARKS=No
#
# ZERO_MARKS=[Yes|No]
#
# Added in Shorewall 5.0.12, this is a workaround for an issue where packet
# marks are not zeroed by the kernel. It should be set to No (the default)
# unless you find that incoming packets are being mis-routed for no apparent
# reasons.
#
# Caution
#
# Do not set this option to Yes if you have IPSEC software running on the
# firewall system.
#
ZONE2ZONE=-
#
# ZONE2ZONE=[2|-]
#
# Added in Shorewall 4.4.4. This option determines how Shorewall constructs
# chain names involving zone names and/or 'all'. Beginning with Shorewall
# 4.6.0, the default is '-' (e.g., fw-net); prior to that release, the
# default was '2' (e.g., fw2net).
#
###############################################################################
# P A C K E T D I S P O S I T I O N
###############################################################################
BLACKLIST_DISPOSITION=DROP
#
# BLACKLIST_DISPOSITION=[DROP|A_DROP|REJECT|A_REJECT]
#
# This parameter determines the disposition of packets from blacklisted
# hosts. It may have the value DROP if the packets are to be dropped or
# REJECT if the packets are to be replied with an ICMP port unreachable reply
# or a TCP RST (tcp only). If you do not assign a value or if you assign an
# empty value then DROP is assumed.
#
# A_DROP and A_REJECT are audited versions of DROP and REJECT respectively
# and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel
# and iptables.
#
# The BLACKLIST_DISPOSITION setting determines the disposition of packets
# sent to the blacklog target of shorewall-blrules (5), but otherwise does
# not affect entries in that file.
#
INVALID_DISPOSITION=CONTINUE
#
# INVALID_DISPOSITION=[A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
#
# Added in Shorewall 4.5.13. Shorewall has traditionally passed INVALID
# packets through the NEW section of shorewall-rules (5). When a packet in
# INVALID state fails to match any rule in the INVALID section, the packet is
# disposed of based on this setting. The default value is CONTINUE for
# compatibility with earlier versions.
#
MACLIST_DISPOSITION=REJECT
#
# MACLIST_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]
#
# Determines the disposition of connections requests that fail MAC
# Verification and must have the value ACCEPT (accept the connection request
# anyway), REJECT (reject the connection request) or DROP (ignore the
# connection request). If not set or if set to the empty value (e.g.,
# MACLIST_DISPOSITION="") then MACLIST_DISPOSITION=REJECT is assumed.
#
# A_DROP and A_REJECT are audited versions of DROP and REJECT respectively
# and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel
# and ip[6]tables.
#
RELATED_DISPOSITION=ACCEPT
#
# RELATED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
#
# Added in Shorewall 4.4.27. Shorewall has traditionally ACCEPTed RELATED
# packets that don't match any rule in the RELATED section of shorewall-rules
# (5). Concern about the safety of this practice resulted in the addition of
# this option. When a packet in RELATED state fails to match any rule in the
# RELATED section, the packet is disposed of based on this setting. The
# default value is ACCEPT for compatibility with earlier versions.
#
SFILTER_DISPOSITION=DROP
#
# SFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]
#
# Added in Shorewall 4.4.20. Determines the disposition of packets matching
# the sfilter option (see shorewall-interfaces(5)) and of hairpin packets on
# interfaces without the routeback option.^[1]
#
RPFILTER_DISPOSITION=DROP
#
# RPFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]
#
# Added in Shorewall 4.5.7. Determines the disposition of packets entering
# from interfaces the rpfilter option (see shorewall-interfaces(5)). Packets
# disposed of by this option are those whose response packets would not be
# sent through the same interface receiving the packet.
#
SMURF_DISPOSITION=DROP
#
# SMURF_DISPOSITION=[DROP|A_DROP]
#
# Added in Shorewall 4.4.20. The default setting is DROP which causes smurf
# packets (see the nosmurfs option in shorewall-interfaces(5)) to be dropped.
# A_DROP causes the packets to be audited prior to being dropped and requires
# AUDIT_TARGET support in the kernel and iptables.
#
TCP_FLAGS_DISPOSITION=DROP
#
# TCP_FLAGS_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]
#
# Determines the disposition of TCP packets that fail the checks enabled by
# the tcpflags interface option (see shorewall-interfaces(5)) and must have a
# value of ACCEPT (accept the packet), REJECT (send an RST response) or DROP
# (ignore the packet). If not set or if set to the empty value (e.g.,
# TCP_FLAGS_DISPOSITION="") then TCP_FLAGS_DISPOSITION=DROP is assumed.
#
# A_DROP and A_REJECT are audited versions of DROP and REJECT respectively
# and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel
# and iptables.
#
UNTRACKED_DISPOSITION=CONTINUE
#
# UNTRACKED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]
#
# Added in Shorewall 4.5.13. Shorewall has traditionally passed UNTRACKED
# packets through the NEW section of shorewall-rules (5). When a packet in
# UNTRACKED state fails to match any rule in the UNTRACKED section, the
# packet is disposed of based on this setting. The default value is CONTINUE
# for compatibility with earlier versions.
#
################################################################################
# P A C K E T M A R K L A Y O U T
################################################################################
TC_BITS=
#
# TC_BITS=[number]
#
# The number of bits at the low end of the 32-bit packet mark to be used for
# traffic shaping marking. May be zero. See MASK_BITS above for default
# value.
#
PROVIDER_BITS=
#
# PROVIDER_BITS=[number]
#
# Added in Shorewall 4.4.26. The number of bits in the 32-bit packet mark to
# be used for provider numbers. May be zero. See MASK_BITS above for default
# value.
#
PROVIDER_OFFSET=
#
# PROVIDER_OFFSET=[number]If
#
# Added in Shorewall 4.4.26. The offset from the right (low-order end) of the
# provider number field in the 32-bit packet mark. If non-zero, must be >=
# TC_BITS (Shorewall automatically adjusts PROVIDER_OFFSET's value).
# PROVIDER_OFFSET + PROVIDER_BITS + ZONE_BITS must be < 32. See MASK_BITS
# above for default value.
#
MASK_BITS=
#
# MASK_BITS=[number]
#
# Added in Shorewall 4.4.26. Number of bits on the right of the 32-bit packet
# mark to be masked when clearing the traffic shaping mark. Must be >=
# TC_BITS and <= PROVIDER_OFFSET (if PROVIDER_OFFSET > 0). Prior to Shorewall
# 5.0.0, default value and the default values of the other mark layout
# options is determined as follows:
#
# Table 1. Default Packet Mark Layout
#
# WIDE_TC_MARKS=No, TC_BITS=8, PROVIDER_BITS=8, PROVIDER_OFFSET=
# HIGH_ROUTE_MARKS=No 0, MASK_BITS=8
# WIDE_TC_MARKS=No, TC_BITS=8, PROVIDER_BITS=8, PROVIDER_OFFSET=
# HIGH_ROUTE_MARKS=Yes 8, MASK_BITS=8
# WIDE_TC_MARKS=Yes, TC_BITS=14, PROVIDER_BITS=8, PROVIDER_OFFSET=
# HIGH_ROUTE_MARKS=No 0, MASK_BITS=16
# WIDE_TC_MARKS=Yes, TC_BITS=14, PROVIDER_BITS=8, PROVIDER_OFFSET=
# HIGH_ROUTE_MARKS=Yes 16, MASK_BITS=16
#
#
# From 5.0.0 onward, the default value of MASK_BITS is 8, the default value
# of PROVIDER_BITS, TC_BITS, MASK_BITS and PROVIDER_OFFSET is 8.
#
ZONE_BITS=0
#
# ZONE_BITS=[number]
#
# Added in Shorewall 4.4.26. When non-zero, enables automatic packet marking
# by source zone and determines the number of bits in the 32-bit packet mark
# to be used for the zone mark. Default value is 0.
#
#LAST LINE -- DO NOT REMOVE
shorewall6-5.2.3.4/configfiles/shorewall6.conf 0000664 0000000 0000000 00000012133 13531060406 017674 0 ustar root root ###############################################################################
#
# Shorewall Version 5 -- /etc/shorewall6/shorewall6.conf
#
# For information about the settings in this file, type "man shorewall6.conf"
#
# Manpage also online at
# http://www.shorewall.net/manpages6/shorewall6.conf.html
###############################################################################
# S T A R T U P E N A B L E D
###############################################################################
STARTUP_ENABLED=No
###############################################################################
# V E R B O S I T Y
###############################################################################
VERBOSITY=1
###############################################################################
# P A G E R
###############################################################################
PAGER=
###############################################################################
# F I R E W A L L
###############################################################################
FIREWALL=
###############################################################################
# L O G G I N G
###############################################################################
LOG_LEVEL="info"
BLACKLIST_LOG_LEVEL=
INVALID_LOG_LEVEL=
LOG_BACKEND=
LOG_VERBOSITY=2
LOG_ZONE=Both
LOGALLNEW=
LOGFILE=/var/log/messages
LOGFORMAT="%s %s "
LOGLIMIT="s:1/sec:10"
LOGTAGONLY=No
MACLIST_LOG_LEVEL="$LOG_LEVEL"
RELATED_LOG_LEVEL=
RPFILTER_LOG_LEVEL="$LOG_LEVEL"
SFILTER_LOG_LEVEL="$LOG_LEVEL"
SMURF_LOG_LEVEL="$LOG_LEVEL"
STARTUP_LOG=/var/log/shorewall6-init.log
TCP_FLAGS_LOG_LEVEL="$LOG_LEVEL"
UNTRACKED_LOG_LEVEL=
###############################################################################
# L O C A T I O N O F F I L E S A N D D I R E C T O R I E S
###############################################################################
CONFIG_PATH=":${CONFDIR}/shorewall6:/usr/share/shorewall6:${SHAREDIR}/shorewall"
GEOIPDIR=/usr/share/xt_geoip/LE
IP6TABLES=
IP=
IPSET=
LOCKFILE=
MODULESDIR=
NFACCT=
PERL=/usr/bin/perl
PATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin"
RESTOREFILE=restore
SHOREWALL_SHELL=/bin/sh
SUBSYSLOCK=/var/lock/subsys/shorewall6
TC=
###############################################################################
# D E F A U L T A C T I O N S / M A C R O S
###############################################################################
ACCEPT_DEFAULT="none"
BLACKLIST_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP),dropNotSyn:$LOG_LEVEL,dropInvalid:$LOG_LEVEL,DropDNSrep:$LOG_LEVEL"
DROP_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)"
NFQUEUE_DEFAULT="none"
QUEUE_DEFAULT="none"
REJECT_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)"
###############################################################################
# R S H / R C P C O M M A N D S
###############################################################################
RCP_COMMAND='scp ${files} ${root}@${system}:${destination}'
RSH_COMMAND='ssh ${root}@${system} ${command}'
###############################################################################
# F I R E W A L L O P T I O N S
###############################################################################
ACCOUNTING=Yes
ACCOUNTING_TABLE=filter
ADMINISABSENTMINDED=Yes
AUTOCOMMENT=Yes
AUTOHELPERS=Yes
AUTOMAKE=Yes
BALANCE_PROVIDERS=No
BASIC_FILTERS=No
BLACKLIST="NEW,INVALID,UNTRACKED"
CLAMPMSS=No
CLEAR_TC=No
COMPLETE=No
DEFER_DNS_RESOLUTION=Yes
DELETE_THEN_ADD=Yes
DONT_LOAD=
DYNAMIC_BLACKLIST=Yes
EXPAND_POLICIES=Yes
EXPORTMODULES=Yes
FASTACCEPT=No
FORWARD_CLEAR_MARK=Yes
HELPERS=
IGNOREUNKNOWNVARIABLES=No
IMPLICIT_CONTINUE=No
IPSET_WARNINGS=Yes
IP_FORWARDING=Keep
KEEP_RT_TABLES=Yes
MACLIST_TABLE=filter
MACLIST_TTL=
MANGLE_ENABLED=Yes
MARK_IN_FORWARD_CHAIN=No
MINIUPNPD=No
MUTEX_TIMEOUT=60
OPTIMIZE=All
OPTIMIZE_ACCOUNTING=No
PERL_HASH_SEED=0
REJECT_ACTION=
RENAME_COMBINED=Yes
REQUIRE_INTERFACE=No
RESTART=restart
RESTORE_DEFAULT_ROUTE=Yes
RESTORE_ROUTEMARKS=Yes
SAVE_IPSETS=No
TC_ENABLED=Shared
TC_EXPERT=No
TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2"
TRACK_PROVIDERS=Yes
TRACK_RULES=No
USE_DEFAULT_RT=Yes
USE_NFLOG_SIZE=No
USE_PHYSICAL_NAMES=No
USE_RT_NAMES=No
VERBOSE_MESSAGES=Yes
WARNOLDCAPVERSION=Yes
WORKAROUNDS=No
ZERO_MARKS=No
ZONE2ZONE=-
###############################################################################
# P A C K E T D I S P O S I T I O N
###############################################################################
BLACKLIST_DISPOSITION=DROP
INVALID_DISPOSITION=CONTINUE
MACLIST_DISPOSITION=REJECT
RELATED_DISPOSITION=ACCEPT
SFILTER_DISPOSITION=DROP
RPFILTER_DISPOSITION=DROP
SMURF_DISPOSITION=DROP
TCP_FLAGS_DISPOSITION=DROP
UNTRACKED_DISPOSITION=CONTINUE
################################################################################
# P A C K E T M A R K L A Y O U T
################################################################################
TC_BITS=
PROVIDER_BITS=
PROVIDER_OFFSET=
MASK_BITS=
ZONE_BITS=0
#LAST LINE -- DO NOT REMOVE
shorewall6-5.2.3.4/configfiles/masq 0000664 0000000 0000000 00000000566 13531060406 015632 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/masq
#
# For information about entries in this file, type "man shorewall6-masq"
#
# The manpage is also online at
# http://www.shorewall.net/manpages6/shorewall6-masq.html
#
######################################################################################################
#INTERFACE SOURCE ADDRESS PROTO PORT IPSEC MARK USER SWITCH
shorewall6-5.2.3.4/configfiles/params 0000664 0000000 0000000 00000001060 13531060406 016142 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/params
#
# Assign any variables that you need here.
#
# It is suggested that variable names begin with an upper case letter
# to distinguish them from variables used internally within the
# Shorewall6 programs
#
# Example:
#
# NET_IF=eth0
# NET_OPTIONS=dhcp,nosmurfs
#
# Example (/etc/shorewall6/interfaces record):
#
# net $NET_IF - $NET_OPTIONS
#
# The result will be the same as if the record had been written
#
# net eth0 - dhcp,nosmurfs
#
###############################################################################
shorewall6-5.2.3.4/configfiles/blrules.annotated 0000664 0000000 0000000 00000013030 13531077637 020321 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/blrules
#
# For information about entries in this file, type "man shorewall6-blrules"
#
# Please see http://shorewall.net/blacklisting_support.htm for additional
# information.
#
##############################################################################################################################################################
#
# This file is used to perform blacklisting and whitelisting.
#
# Rules in this file are applied depending on the setting of BLACKLIST in
# shorewall.conf(5).
#
# The format of rules in this file is the same as the format of rules in
# shorewall-rules (5). The difference in the two files lies in the ACTION (first)
# column.
#
# ACTION- {ACCEPT|BLACKLIST|blacklog|CONTINUE|DROP|A_DROP|REJECT|A_REJECT|
# WHITELIST|LOG|QUEUE|NFQUEUE[(queuenumber)]|[?]COMMENT|action|macro[(target)
# ]}[:{log-level|none}[!][:tag]]
#
# Specifies the action to be taken if the packet matches the rule. Must be
# one of the following.
#
# BLACKLIST
#
# Added in Shorewall 4.5.3. This is actually a macro that expands as
# follows:
#
# ☆ If BLACKLIST_LOGLEVEL is specified in shorewall.conf(5), then the
# macro expands to blacklog.
#
# ☆ Otherwise it expands to the action specified for
# BLACKLIST_DISPOSITION in shorewall.conf(5).
#
# blacklog
#
# May only be used if BLACKLIST_LOGLEVEL is specified in shorewall.conf
# (5). Logs, audits (if specified) and applies the BLACKLIST_DISPOSITION
# specified in shorewall.conf (5).
#
# ACCEPT|CONTINUE|WHITELIST
#
# Exempt the packet from the remaining rules in this file.
#
# DROP
#
# Ignore the packet.
#
# A_DROP
#
# Audited version of DROP. Requires AUDIT_TARGET support in the kernel
# and ip6tables.
#
# REJECT
#
# disallow the packet and return an icmp-unreachable or an RST packet.
#
# A_REJECT
#
# Audited versions of REJECT. Require AUDIT_TARGET support in the kernel
# and ip6tables.
#
# LOG
#
# Simply log the packet and continue with the next rule.
#
# QUEUE
#
# Queue the packet to a user-space application such as ftwall (http://
# p2pwall.sf.net). The application may reinsert the packet for further
# processing.
#
# NFLOG[(nflog-parameters)]
#
# queues matching packets to a back end logging daemon via a netlink
# socket then continues to the next rule. See shorewall-logging(5).
#
# NFQUEUE
#
# Queues the packet to a user-space application using the nfnetlink_queue
# mechanism. If a queuenumber is not specified, queue zero (0) is
# assumed.
#
# ?COMMENT
#
# The rest of the line will be attached as a comment to the Netfilter
# rule(s) generated by the following entries. The comment will appear
# delimited by "/* ... */" in the output of "shorewall show ". To
# stop the comment from being attached to further rules, simply include ?
# COMMENT on a line by itself.
#
# action
#
# The name of an action declared in shorewall-actions(5) or in /usr/share
# /shorewall/actions.std.
#
# macro
#
# The name of a macro defined in a file named macro.macro. If the macro
# accepts an action parameter (Look at the macro source to see if it has
# PARAM in the TARGET column) then the macro name is followed by the
# parenthesized target (ACCEPT, DROP, REJECT, ...) to be substituted for
# the parameter.
#
# Example: FTP(ACCEPT).
#
# The ACTION may optionally be followed by ":" and a syslog log level (e.g,
# REJECT:info or Web(ACCEPT):debug). This causes the packet to be logged at
# the specified level.
#
# If the ACTION names an action declared in shorewall-actions(5) or in /usr/
# share/shorewall/actions.std then:
#
# □ If the log level is followed by "!' then all rules in the action are
# logged at the log level.
#
# □ If the log level is not followed by "!" then only those rules in the
# action that do not specify logging are logged at the specified level.
#
# □ The special log level none! suppresses logging by the action.
#
# You may also specify NFLOG (must be in upper case) as a log level.This will
# log to the NFLOG target for routing to a separate log through use of ulogd
# (shorewall-logging.htm).
#
# Actions specifying logging may be followed by a log tag (a string of
# alphanumeric characters) which is appended to the string generated by the
# LOGPREFIX (in shorewall.conf(5)).
#
# For the remaining columns, see shorewall-rules (5).
#
# Examples
#
# IPv4 Example 1:
#
# Drop 6to4 packets from the net.
#
# DROP net:192.88.99.1 all
#
# IPv4 Example 2:
#
# Don't subject packets from 70.90.191.120/29 to the remaining rules in the
# file.
#
# WHITELIST net:70.90.191.120/29 all
#
# IPv6 Example 1:
#
# Drop Teredo packets from the net.
#
# DROP net:[2001::/32] all
#
# IPv6 Example 2:
#
# Don't subject packets from 2001:DB8::/64 to the remaining rules in the
# file.
#
# WHITELIST net:[2001:DB8::/64] all
#
##############################################################################################################################################################
#ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST RATE USER MARK CONNLIMIT TIME HEADERS SWITCH HELPER
shorewall6-5.2.3.4/configfiles/tcpri 0000664 0000000 0000000 00000000510 13531060406 015777 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/tcpri
#
# For information about entries in this file, type "man shorewall6-tcpri"
#
# See http://shorewall.net/simple_traffic_shaping.htm for additional
# information.
#
###############################################################################
#BAND PROTO PORT ADDRESS INTERFACE HELPER
shorewall6-5.2.3.4/configfiles/tcclasses.annotated 0000664 0000000 0000000 00000045243 13531077651 020644 0 ustar root root #
# Shorewall6 -- /etc/shorewall6/tcclasses
#
# For information about entries in this file, type "man shorewall6-tcclasses"
#
# See http://shorewall.net/traffic_shaping.htm for additional information.
#
###############################################################################
#
# A note on the rate/bandwidth definitions used in this file:
#
# • don't use a space between the integer value and the unit: 30kbit is valid
# while 30 kbit is NOT.
#
# • you can use one of the following units:
#
# kpbs
#
# Kilobytes per second.
#
# mbps
#
# Megabytes per second.
#
# kbit
#
# Kilobits per second.
#
# mbit
#
# Megabits per second.
#
# bps or number
#
# Bytes per second.
#
# • if you want the values to be calculated for you depending on the output
# bandwidth setting defined for an interface in tcdevices, you can use
# expressions like the following:
#
# full/3
#
# causes the bandwidth to be calculated as 1/3 of the full outgoing speed
# that is defined.
#
# full*9/10
#
# will set this bandwidth to 9/10 of the full bandwidth
#
# Note that in a sub-class (a class that has a specified parent class), full
# refers to the RATE or CEIL of the parent class rather than to the
# OUT-BANDWIDTH of the device.
#
# DO NOT add a unit to the rate if it is calculated !
#
# The columns in the file are as follows.
#
# INTERFACE - interface[[:parent]:class]
#
# Name of interface.
#
# You may specify the interface number rather than the interface name. If the
# classify option is given for the interface in shorewall-tcdevices(5), then
# you must also specify an interface class (an integer that must be unique
# within classes associated with this interface). If the classify option is
# not given, you may still specify a class or you may have Shorewall generate
# a class number from the MARK value. Interface numbers and class numbers are
# always assumed to be specified in hex and class number 1 is reserved as the
# root class of the queuing discipline.
#
# You may NOT specify wildcards here, e.g. if you have multiple ppp
# interfaces, you need to put them all in here!
#
# Please note that you can only use interface names in here that have a
# bandwidth defined in the shorewall-tcdevices(5) file.
#
# Normally, all classes defined here are sub-classes of a root class that is
# implicitly defined from the entry in shorewall-tcdevices(5). You can
# establish a class hierarchy by specifying a parent class -- the number of a
# class that you have previously defined. The sub-class may borrow unused
# bandwidth from its parent.
#
# MARK - {-|value[:priority]}
#
# The mark value which is an integer in the range 1-255. You set mark values
# in the shorewall-mangle(5) file, marking the traffic you want to fit in the
# classes defined in here. You can use the same marks for different
# interfaces.
#
# The priority, if specified, is an integer in the range 1-65535 and
# determines the relative order in which the tc mark classification filter
# for this class is to be applied to packets being sent on the interface.
# Filters are applied in ascending numerical order. If not supplied, the
# value is derived from the class priority (PRIORITY column value below): (
# class priority << 8) | 20.
#
# RATE - {-|rate[:dmax[:umax]]}
#
# The minimum bandwidth this class should get, when the traffic load rises.
# If the sum of the rates in this column exceeds the INTERFACE's
# OUT-BANDWIDTH, then the OUT-BANDWIDTH limit may not be honored. Similarly,
# if the sum of the rates of sub-classes of a class exceed the CEIL of the
# parent class, things don't work well.
#
# When using the HFSC queuing discipline, this column specify the real-time
# (RT) service curve. leaf classes may specify dmax, the maximum delay in
# milliseconds that the first queued packet for this class should experience.
# May be expressed as an integer, optionally followed by 'ms' with no
# intervening white-space (e.g., 10ms).
#
# HFSC leaf classes may also specify umax, the largest packet expected in
# this class. May be expressed as an integer. The unit of measure is bytes
# and the integer may be optionally followed by 'b' with no intervening
# white-space (e.g., 800b). umax may only be given if dmax is also given.
#
# Beginning with Shorewall 4.5.6, HFSC classes may omit this column (e.g, '-'
# in the column), provided that an lsrate is specified (see CEIL below).
# These rates are used to arbitrate between classes of the same priority.
#
# CEIL - [lsrate:]rate
#
# The maximum bandwidth this class is allowed to use when the link is idle.
# Useful if you have traffic which can get full speed when more needed
# services (e.g. ssh) are not used.
#
# You can use the value full in here for setting the maximum bandwidth to the
# RATE of the parent class, or the OUT-BANDWIDTH of the device if there is no
# parent class.
#
# Beginning with Shorewall 4.5.6, you can also specify an lsrate (link
# sharing rate).
#
# PRIORITY - priority
#
# For HTB:
#
# The priority in which classes will be serviced by the packet shaping
# scheduler and also the priority in which bandwidth in excess of the
# rate will be given to each class.
#
# Higher priority classes will experience less delay since they are
# serviced first. Priority values are serviced in ascending order (e.g. 0
# is higher priority than 1).
#
# Classes may be set to the same priority, in which case they will be
# serviced as equals.
#
# For both HTB and HFSC, the priority is used to calculate the priority of
# following Shorewall-generated classification filters that refer to the
# class:
#
# □ Packet MARK
#
# □ tcp-ack and the tos options (see below)
#
# The rules for classes with lower numeric priorities will appear before
# those with higher numeric priorities.
#
# Beginning with Shorewall 4.5.8, the PRIORITY may be omitted from an HFSC
# class if you do not use the MARK column or the tcp-ack or tos options. If
# you use any of those features and omit the PRIORITY, then you must specify
# a priority along with the MARK or option.
#
# OPTIONS (Optional) - [option[,option]...]
#
# A comma-separated list of options including the following:
#
# default
#
# This is the default class for that interface where all traffic should
# go, that is not classified otherwise.
#
# Note
#
# You must define default for exactly one class per interface.
#
# tos=0xvalue[/0xmask][:priority] (mask defaults to 0xff)
#
# This lets you define a classifier for the given value/mask combination
# of the IP packet's TOS/Precedence/DiffSrv octet (aka the TOS byte).
#
# Beginning with Shorewall 4.5.8, the value/mask may be followed by a
# colon (":") and a priority. This priority determines the order in which
# filter rules are processed during packet classification. If not
# specified, the value (class priority << 8) | 15) is used.
#
# tos-tosname[:priority]
#
# Aliases for the following TOS octet value and mask encodings. TOS
# encodings of the "TOS byte" have been deprecated in favor of diffserve
# classes, but programs like ssh, rlogin, and ftp still use them.
#
# Beginning with Shorewall 4.5.8, the tos-name may be followed by a colon
# (":") and a priority. This priority determines the order in which
# filter rules are processed during packet classification. If not
# specified, the value (class priority << 8) | 15) is used.
#
# tos-minimize-delay 0x10/0x10
# tos-maximize-throughput 0x08/0x08
# tos-maximize-reliability 0x04/0x04
# tos-minimize-cost 0x02/0x02
# tos-normal-service 0x00/0x1e
#
# Note
#
# Each of these options is only valid for ONE class per interface.
#
# tcp-ack[:priority]
#
# If defined, causes a tc filter to be created that puts all tcp ack
# packets on that interface that have a size of <=64 Bytes to go in this
# class. This is useful for speeding up downloads. Please note that the
# size of the ack packets is limited to 64 bytes because we want only
# packets WITHOUT payload to match.
#
# Beginning with Shorewall 4.5.8, the tcp-ack may be followed by a colon
# (":") and a priority. This priority determines the order in which
# filter rules are processed during packet classification. If not
# specified, the value (class priority << 8) | 10) is used.
#
# Note
#
# This option is only valid for ONE class per interface.
#
# occurs=number
#
# Typically used with an IPMARK entry in tcrules. Causes the rule to be
# replicated for a total of number rules. Each rule has a successively
# class number and mark value.
#
# When 'occurs' is used:
#
# ☆ The associated device may not have the 'classify' option.
#
# ☆ The class may not be the default class.
#
# ☆ The class may not have any 'tos=' options (including 'tcp-ack').
#
# ☆ The class should not specify a MARK value. If one is specified, it
# will be ignored with a warning message.
#
# The 'RATE' and 'CEIL' parameters apply to each instance of the class.
# So the total RATE represented by an entry with 'occurs' will be the
# listed RATE multiplied by number. For additional information, see
# shorewall-tcrules (5).
#
# flow=keys
#
# Shorewall attaches an SFQ queuing discipline to each leaf HTB class.
# SFQ ensures that each flow gets equal access to the interface. The
# default definition of a flow corresponds roughly to a Netfilter
# connection. So if one internal system is running BitTorrent, for
# example, it can have lots of 'flows' and can thus take up a larger
# share of the bandwidth than a system having only a single active
# connection. The flow classifier (module cls_flow) works around this by
# letting you define what a 'flow' is. The classifier must be used
# carefully or it can block off all traffic on an interface! The flow
# option can be specified for an HTB leaf class (one that has no
# sub-classes). We recommend that you use the following:
#
# Shaping internet-bound traffic: flow=nfct-src
# Shaping traffic bound for your local net: flow=dst
#
# These will cause a 'flow' to consists of the traffic to/from each
# internal system.
#
# When more than one key is give, they must be enclosed in parenthesis
# and separated by commas.
#
# To see a list of the possible flow keys, run this command:
#
# tc filter add flow help
#
# Those that begin with "nfct-" are Netfilter connection tracking fields.
# As shown above, we recommend flow=nfct-src; that means that we want to
# use the source IP address before NAT as the key.
#
# pfifo
#
# When specified for a leaf class, the pfifo queuing discipline is
# applied to the class rather than the sfq queuing discipline.
#
# limit=number
#
# Added in Shorewall 4.4.3. When specified for a leaf class, determines
# the maximum number of packets that may be queued within the class. The
# number must be > 2 and <=128. If not specified, the value 127 is
# assumed.
#
# red=(redoption=value, ...)
#
# Added in Shorewall 4.5.6. When specified on a leaf class, causes the
# class to use the RED (Random Early Detection) queuing discipline rather
# than SFQ. See tc-red (8) for additional information.
#
# Allowable redoptions are:
#
# min min
#
# Average queue size at which marking becomes a possibility.
#
# max max
#
# At this average queue size, the marking probability is maximal.
# Must be at least twice min to prevent synchronous retransmits,
# higher for low min.
#
# probability probability
#
# Maximum probability for marking, specified as a floating point
# number from 0.0 to 1.0. Suggested values are 0.01 or 0.02 (1 or 2%,
# respectively).
#
# limit limit
#
# Hard limit on the real (not average) queue size in bytes. Further
# packets are dropped. Should be set higher than max+burst. It is
# advised to set this a few times higher than max. Shorewall requires
# that limit be at least twice min.
#
# burst burst
#
# Used for determining how fast the average queue size is influenced
# by the real queue size. Larger values make the calculation more
# sluggish, allowing longer bursts of traffic before marking starts.
# Real life experiments support the following guide‐line: (min+min+
# max)/(3*avpkt).
#
# avpkt avpkt
#
# Optional. Specified in bytes. Used with burst to determine the time
# constant for average queue size calculations. 1000 is a good value
# and is the Shorewall default.
#
# bandwidth bandwidth
#
# Optional. This rate is used for calculating the average queue size
# after some idle time. Should be set to the bandwidth of your
# interface. Does not mean that RED will shape for you!
#
# ecn
#
# RED can either 'mark' or 'drop'. Explicit Congestion Notification
# allows RED to notify remote hosts that their rate exceeds the
# amount of bandwidth available. Non-ECN capable hosts can only be
# notified by dropping a packet. If this parameter is specified,
# packets which indicate that their hosts honor ECN will only be
# marked and not dropped, unless the queue size hits limit bytes.
# Recommended.
#
# fq_codel[=(codeloption=value, ...)]
#
# Added in Shorewall 4.5.12. When specified for a leaf class, causes the
# class to use the FQ_CODEL (Fair-queuing Controlled Delay) queuing
# discipline rather than SFQ. See tc-fq_codel (8) for additional
# information.
#
# Allowable codeloptions are:
#
# limit
#
# hard limit on the real queue size. When this limit is reached,
# incoming packets are dropped. If the value is lowered, packets are
# dropped so that the new limit is met. Default is 1000 packets.
#
# flows
#
# is the number of flows into which the incoming packets are
# classified. Due to the stochastic nature of hashing, multiple flows
# may end up being hashed into the same slot. Newer flows have
# priority over older ones. This parameter can be set only at load
# time since memory has to be allocated for the hash table. Default
# value is 1024.
#
# target
#
# is the acceptable minimum standing/persistent queue delay. This
# minimum delay is identified by tracking the local minimum queue
# delay that packets experience. Default and recommended value is
# 5ms.
#
# interval
#
# is used to ensure that the measured minimum delay does not become
# too stale. The minimum delay must be experienced in the last epoch
# of length interval. It should be set on the order of the worst-case
# RTT through the bottleneck to give endpoints sufficient time to
# react. Default value is 100ms.
#
# quantum
#
# is the number of bytes used as 'deficit' in the fair queuing
# algorithm. Default is set to 1514 bytes which corresponds to the
# Ethernet MTU plus the hardware header length of 14 bytes.
#
# ecn | noecn
#
# can be used to mark packets instead of dropping them. If ecn has
# been enabled, noecn can be used to turn it off and vice-versa. By
# default, ecn is enabled.
#
# Examples
#
# Example 1:
#
# Suppose you are using PPP over Ethernet (DSL) and ppp0 is the interface for
# this. You have 4 classes here, the first you can use for voice over IP
# traffic, the second interactive traffic (e.g. ssh/telnet but not scp), the
# third will be for all unclassified traffic, and the forth is for low
# priority traffic (e.g. peer-to-peer).
#
# The voice traffic in the first class will be guaranteed a minimum of
# 100kbps and always be serviced first (because of the low priority number,
# giving less delay) and will be granted excess bandwidth (up to 180kbps, the
# class ceiling) first, before any other traffic. A single VoIP stream,
# depending upon codecs, after encapsulation, can take up to 80kbps on a
# PPPoE/DSL link, so we pad a little bit just in case. (TOS byte values 0xb8
# and 0x68 are DiffServ classes EF and AFF3-1 respectively and are often used
# by VOIP devices).
#
# Interactive traffic (tos-minimum-delay) and TCP acks (and ICMP echo traffic
# if you use the example in tcrules) and any packet with a mark of 2 will be
# guaranteed 1/4 of the link bandwidth, and may extend up to full speed of
# the link.
#
# Unclassified traffic and packets marked as 3 will be guaranteed 1/4th of
# the link bandwidth, and may extend to the full speed of the link.
#
# Packets marked with 4 will be treated as low priority packets. (The tcrules
# example marks p2p traffic as such.) If the link is congested, they're only
# guaranteed 1/8th of the speed, and even if the link is empty, can only
# expand to 80% of link bandwidth just as a precaution in case there are
# upstream queues we didn't account for. This is the last class to get
# additional bandwidth and the last to get serviced by the scheduler because
# of the low priority.
#
# #INTERFACE MARK RATE CEIL PRIORITY OPTIONS
# ppp0 1 100kbit 180kbit 1 tos=0x68/0xfc,tos=0xb8/0xfc
# ppp0 2 full/4 full 2 tcp-ack,tos-minimize-delay
# ppp0 3 full/4 full 3 default
# ppp0 4 full/8 full*8/10 4
#
###############################################################################
#INTERFACE MARK RATE CEIL PRIO OPTIONS
shorewall6-5.2.3.4/helpers 0000664 0000000 0000000 00000002547 13531060406 014044 0 ustar root root #
# Shorewall6 version 5 - Helpers File
#
# /usr/share/shorewall6/helpers
#
# This file loads the modules that may be needed by the firewall.
#
# THE ORDER OF THE COMMANDS BELOW IS IMPORTANT!!!!!! You MUST load in
# dependency order. i.e., if M2 depends on M1 then you must load M1
# before you load M2.
#
# If you need to modify this file, copy it to /etc/shorewall and modify the
# copy.
#
###############################################################################
#
# Helpers
#
loadmodule nf_conntrack_amanda
loadmodule nf_conntrack_ftp
loadmodule nf_conntrack_h323
loadmodule nf_conntrack_irc
loadmodule nf_conntrack_netbios_ns
loadmodule nf_conntrack_netbios_ns
loadmodule nf_conntrack_netlink
loadmodule nf_conntrack_pptp
loadmodule nf_conntrack_proto_sctp
loadmodule nf_conntrack_proto_udplite
loadmodule nf_conntrack_sane
loadmodule nf_conntrack_sip sip_direct_media=0
loadmodule nf_conntrack_pptp
loadmodule nf_conntrack_proto_gre
loadmodule nf_conntrack_proto_sctp
loadmodule nf_conntrack_sip
loadmodule nf_conntrack_tftp
loadmodule nf_conntrack_sane
#
# While not actually helpers, these are included here so that
# LOG_BACKEND can work correctly. Not all of them will be
# loaded, since at least one of them will be an alias on any
# given system.
#
loadmodule ip6t_LOG
loadmodule nf_log_ipv6
loadmodule xt_LOG
loadmodule xt_NFLOG
loadmodule nfnetlink_log