mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-08 00:34:04 +01:00
Strip documentation from the sample shorewall.conf files
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@5143 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep
parent
052158b6e9
commit
2cbb02649c
@ -9,388 +9,74 @@
|
||||
# version 2.1 of the License, or (at your option) any later version.
|
||||
#
|
||||
# See the file README.txt for further details.
|
||||
#
|
||||
# For information about the settings in this file, type "man shorewall.conf"
|
||||
#
|
||||
# Additional information is available at
|
||||
# http://www.shorewall.net/Documentation.htm#Conf
|
||||
###############################################################################
|
||||
# S T A R T U P E N A B L E D
|
||||
###############################################################################
|
||||
#
|
||||
# Once you have configured Shorewall, you may change the setting of
|
||||
# this variable to 'Yes'
|
||||
#
|
||||
|
||||
STARTUP_ENABLED=No
|
||||
|
||||
###############################################################################
|
||||
# V E R B O S I T Y
|
||||
###############################################################################
|
||||
#
|
||||
# Shorewall has traditionally been very noisy. You may now set the default
|
||||
# level of verbosity here.
|
||||
#
|
||||
# Values are:
|
||||
#
|
||||
# 0 -- Silent. You may make it more verbose using the -v option
|
||||
# 1 -- Major progress messages displayed
|
||||
# 2 -- All progress messages displayed (old default behavior)
|
||||
#
|
||||
# If not specified, then 2 is assumed
|
||||
|
||||
VERBOSITY=1
|
||||
|
||||
###############################################################################
|
||||
# L O G G I N G
|
||||
###############################################################################
|
||||
#
|
||||
# General note about log levels. 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 specifify. 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 target support, you may also
|
||||
# specify a log level of ULOG (must be all caps). Rather than log its
|
||||
# messages to syslogd, Shorewall will direct netfilter to log the messages
|
||||
# via the ULOG 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). Ulogd is also available from
|
||||
# http://www.gnumonks.org/projects/ulogd and can be configured to log all
|
||||
# Shorewall message to their own log file
|
||||
###############################################################################
|
||||
#
|
||||
# LOG FILE LOCATION
|
||||
#
|
||||
# This variable tells the /sbin/shorewall program where to look for Shorewall
|
||||
# log messages. If not set or set to an empty string (e.g., LOGFILE="") then
|
||||
# /var/log/messages is assumed.
|
||||
#
|
||||
# WARNING: The LOGFILE variable simply tells the 'shorewall' program where to
|
||||
# look for Shorewall messages.It does NOT control the destination for
|
||||
# these messages. For information about how to do that, see
|
||||
#
|
||||
# http://www.shorewall.net/shorewall_logging.html
|
||||
#
|
||||
|
||||
LOGFILE=/var/log/messages
|
||||
|
||||
#
|
||||
# LOG FORMAT
|
||||
#
|
||||
# Shell 'printf' Formatting template for the --log-prefix value in log messages
|
||||
# generated by Shorewall to identify Shorewall log messages. The supplied
|
||||
# template is expected to accept either two or three arguments; the first is
|
||||
# the chain name, the second (optional) is the logging rule number within that
|
||||
# chain and the third is the ACTION specifying the disposition of the packet
|
||||
# being logged. You must use the %d formatting type for the rule number; if
|
||||
# your template does not contain %d then the rule number will not be included.
|
||||
#
|
||||
# If you want to integrate Shorewall with fireparse, then set LOGFORMAT as:
|
||||
#
|
||||
# LOGFORMAT="fp=%s:%d a=%s "
|
||||
#
|
||||
# If not specified or specified as empty (LOGFORMAT="") then the value
|
||||
# "Shorewall:%s:%s:" is assumed.
|
||||
#
|
||||
# Beginning with Shorewall 3.3.3, The contents of LOGFORMAT determine the
|
||||
# maximum length of a Shorewall zone name. LOGFORMAT must produce a string no
|
||||
# longer than 29 bytes when passed the chain name, [rule number], and 'ACCEPT'.
|
||||
# Using the default LOGFORMAT, the name of a chain must be 11 characters or
|
||||
# less; since chain names are often of the form <zone1>2<zone2>, zone names are
|
||||
# limited to 5 characters using the default LOGFORMAT. In contrast, if
|
||||
# LOGFORMAT="FW:%s:%s:", then zone names can be as long as 8 characters.
|
||||
|
||||
LOGFORMAT="Shorewall:%s:%s:"
|
||||
|
||||
#
|
||||
# LOG FORMAT Continued
|
||||
#
|
||||
# Using the default LOGFORMAT, chain names may not exceed 11 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.
|
||||
#
|
||||
|
||||
LOGTAGONLY=No
|
||||
|
||||
#
|
||||
# LOG RATE LIMITING
|
||||
#
|
||||
# The next two variables can be used to control the amount of log output
|
||||
# generated. LOGRATE is expressed as a number followed by an optional
|
||||
# `/second', `/minute', `/hour', or `/day' suffix and specifies the maximum
|
||||
# rate at which a particular message will occur. LOGBURST determines the
|
||||
# maximum initial burst size that will be logged. If set empty, the default
|
||||
# value of 5 will be used.
|
||||
#
|
||||
# If BOTH variables are set empty then logging will not be rate-limited.
|
||||
#
|
||||
# Example:
|
||||
#
|
||||
# LOGRATE=10/minute
|
||||
# LOGBURST=5
|
||||
#
|
||||
# For each logging rule, the first time the rule is reached, the packet
|
||||
# will be logged; in fact, since the burst is 5, the first five packets
|
||||
# will be logged. After this, it will be 6 seconds (1 minute divided by
|
||||
# the rate of 10) before a message will be logged from the rule, regardless
|
||||
# of how many packets reach it. Also, every 6 seconds which passes without
|
||||
# matching a packet, one of the bursts will be regained; if no packets hit
|
||||
# the rule for 30 seconds, the burst will be fully recharged; back where
|
||||
# we started.
|
||||
#
|
||||
|
||||
LOGRATE=
|
||||
LOGBURST=
|
||||
|
||||
#
|
||||
# LOG ALL NEW
|
||||
#
|
||||
# This option should only be used when you are trying to analyze a problem.
|
||||
# It causes all packets in the Netfilter NEW state to be logged as the
|
||||
# first rule in each builtin chain. To use this option, set LOGALLNEW to
|
||||
# the log level that you want these packets logged at (e.g.,
|
||||
# LOGALLNEW=debug).
|
||||
#
|
||||
LOGBURST=
|
||||
|
||||
LOGALLNEW=
|
||||
|
||||
#
|
||||
# BLACKLIST LOG LEVEL
|
||||
#
|
||||
# Set this variable to the syslogd level that you want blacklist packets logged
|
||||
# (beware of DOS attacks resulting from such logging). If not set, no logging
|
||||
# of blacklist packets occurs.
|
||||
#
|
||||
# See the comment at the top of this section for a description of log levels
|
||||
#
|
||||
|
||||
BLACKLIST_LOGLEVEL=
|
||||
|
||||
#
|
||||
# MAC List Log Level
|
||||
#
|
||||
# Specifies the logging level for connection requests that fail MAC
|
||||
# verification. If set to the empty value (MACLIST_LOG_LEVEL="") then
|
||||
# such connection requests will not be logged.
|
||||
#
|
||||
# See the comment at the top of this section for a description of log levels
|
||||
#
|
||||
# If you wish to filter messages logged under this option, then supply
|
||||
# the /etc/shorewall/maclog extension script (you will have to create the
|
||||
# file yourself). That script will be copied into the compiled firewall
|
||||
# script at a point just before logging occurs. The shell variable CHAIN
|
||||
# will be set to the name of the chain where the logging rule will be
|
||||
# inserted.
|
||||
#
|
||||
# If you set MACLIST_TABLE=mangle later in this file, be sure that your
|
||||
# 'run_iptables' commands include '-t mangle'.
|
||||
#
|
||||
# See http://www.shorewall.net/shorewall_extension_scripts.htm for more
|
||||
# information about extension scripts.
|
||||
#
|
||||
|
||||
MACLIST_LOG_LEVEL=info
|
||||
|
||||
#
|
||||
# TCP FLAGS Log Level
|
||||
#
|
||||
# Specifies the logging level for packets that fail TCP Flags
|
||||
# verification. If set to the empty value (TCP_FLAGS_LOG_LEVEL="") then
|
||||
# such packets will not be logged.
|
||||
#
|
||||
# See the comment at the top of this section for a description of log levels
|
||||
#
|
||||
|
||||
TCP_FLAGS_LOG_LEVEL=info
|
||||
|
||||
#
|
||||
# RFC1918 Log Level
|
||||
#
|
||||
# Specifies the logging level for packets that fail RFC 1918
|
||||
# verification. If set to the empty value (RFC1918_LOG_LEVEL="") then
|
||||
# RFC1918_LOG_LEVEL=info is assumed.
|
||||
#
|
||||
# See the comment at the top of this section for a description of log levels
|
||||
#
|
||||
|
||||
RFC1918_LOG_LEVEL=info
|
||||
|
||||
#
|
||||
# SMURF Log Level
|
||||
#
|
||||
# Specifies the logging level for smurf packets dropped by the
|
||||
#'nosmurfs' interface option in /etc/shorewall/interfaces and in
|
||||
# /etc/shorewall/hosts. If set to the empty value ( SMURF_LOG_LEVEL=""
|
||||
# ) then dropped smurfs are not logged.
|
||||
#
|
||||
# See the comment at the top of this section for a description of log levels
|
||||
#
|
||||
|
||||
SMURF_LOG_LEVEL=info
|
||||
|
||||
#
|
||||
# MARTIAN LOGGING
|
||||
#
|
||||
# Setting LOG_MARTIANS=Yes will enable kernel logging of all received packets
|
||||
# that have impossible source IP addresses. This logging may be enabled
|
||||
# on individual interfaces by using the 'logmartians' option in
|
||||
# /etc/shorewall/interfaces.
|
||||
#
|
||||
|
||||
LOG_MARTIANS=No
|
||||
|
||||
###############################################################################
|
||||
# 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
|
||||
###############################################################################
|
||||
#
|
||||
# IPTABLES
|
||||
#
|
||||
# Full path to iptables executable Shorewall uses to build the firewall. If
|
||||
# not specified or if specified with an empty value (e.g., IPTABLES="") then
|
||||
# the iptables executable located via the PATH setting below is used.
|
||||
#
|
||||
|
||||
IPTABLES=
|
||||
|
||||
#
|
||||
# PATH - Change this if you want to change the order in which Shorewall
|
||||
# searches directories for executable files.
|
||||
#
|
||||
|
||||
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
|
||||
|
||||
#
|
||||
# SHELL
|
||||
#
|
||||
# The firewall script is normally interpreted by /bin/sh. If you wish to change
|
||||
# the shell used to interpret that script, specify the shell here.
|
||||
#
|
||||
|
||||
SHOREWALL_SHELL=/bin/sh
|
||||
|
||||
# SUBSYSTEM LOCK FILE
|
||||
#
|
||||
# Set this to the name of the lock file expected by your init scripts. For
|
||||
# RedHat, this should be /var/lock/subsys/shorewall. If your init scripts don't
|
||||
# use lock files, set this to "".
|
||||
#
|
||||
|
||||
SUBSYSLOCK=/var/lock/subsys/shorewall
|
||||
|
||||
#
|
||||
# KERNEL MODULE DIRECTORY
|
||||
#
|
||||
# If your netfilter kernel modules are in a directory other than
|
||||
# /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter then specify that
|
||||
# directory in this variable. Example: MODULESDIR=/etc/modules.
|
||||
#
|
||||
|
||||
MODULESDIR=
|
||||
|
||||
#
|
||||
# CONFIGURATION SEARCH PATH
|
||||
#
|
||||
# This option holds a list of directory names separated by colons
|
||||
# (":"). Shorewall will search each directory in turn when looking for a
|
||||
# configuration file. When processing a 'try' command or a command
|
||||
# containing the "-c" option or that specifies a configuration directory,
|
||||
# Shorewall will automatically add the directory specified in the command
|
||||
# to the front of this list.
|
||||
#
|
||||
# If not specified or specified as null ("CONFIG_PATH=""),
|
||||
# the default is distribution-defined. See the output of "shorewall show
|
||||
# config" to find the default value on your distribution.
|
||||
#
|
||||
|
||||
CONFIG_PATH=/etc/shorewall:/usr/share/shorewall
|
||||
|
||||
#
|
||||
# RESTORE SCRIPT
|
||||
#
|
||||
# This option determines the script to be run in the following cases:
|
||||
#
|
||||
# shorewall -f start
|
||||
# shorewall restore
|
||||
# shorewall save
|
||||
# shorewall forget
|
||||
# Failure of shorewall start or shorewall restart
|
||||
#
|
||||
# The value of the option must be the name of an executable file in the
|
||||
# directory /var/lib/shorewall. If this option is not set or if it is
|
||||
# set to the empty value (RESTOREFILE="") then RESTOREFILE=restore is
|
||||
# assumed.
|
||||
#
|
||||
|
||||
RESTOREFILE=
|
||||
|
||||
#
|
||||
# OLD ZONE FILE FORMAT
|
||||
#
|
||||
# Previous versions of Shorewall had both a 'zones' file and an 'ipsec' file.
|
||||
# Beginning with 2.5.0, those files were combined. For users who haven't
|
||||
# converted, we offer this variable that sets the name of the file for ipsec
|
||||
# information. This option must take the value "zones" or "ipsec". If the
|
||||
# option is not set or is set to the empty value (IPSECFILE="") then "ipsec"
|
||||
# is assumed.
|
||||
#
|
||||
|
||||
IPSECFILE=zones
|
||||
|
||||
###############################################################################
|
||||
# D E F A U L T A C T I O N S / M A C R O S
|
||||
###############################################################################
|
||||
#
|
||||
# In earlier Shorewall versions, a "default action" for DROP and REJECT
|
||||
# policies was specified in the file /usr/share/shorewall/actions.std.
|
||||
#
|
||||
# To allow for default rules to be applied when USE_ACTIONS=No, the
|
||||
# DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT and QUEUE_DEFAULT options have
|
||||
# been 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 two are
|
||||
# similar for ACCEPT and QUEUE policies.
|
||||
#
|
||||
# The value applied to these may be:
|
||||
#
|
||||
# a) The name of an action.
|
||||
# b) The name of a macro
|
||||
# c) 'None' or 'none'
|
||||
#
|
||||
# The default values are:
|
||||
#
|
||||
# DROP_DEFAULT="Drop"
|
||||
# REJECT_DEFAULT="Reject"
|
||||
# ACCEPT_DEFAULT="none"
|
||||
# QUEUE_DEFAULT="none"
|
||||
#
|
||||
# If USE_ACTIONS=Yes, then these values refer to action.Drop and action.Reject
|
||||
# respectively. If USE_ACTIONS=No, then these values refer to macro.Drop and
|
||||
# macro.Reject.
|
||||
#
|
||||
# If you set the value of either option to "None" then no default action
|
||||
# will be used and the default action or macro must be specified in
|
||||
# /etc/shorewall/policy
|
||||
|
||||
DROP_DEFAULT="Drop"
|
||||
REJECT_DEFAULT="Reject"
|
||||
@ -400,570 +86,75 @@ QUEUE_DEFAULT="none"
|
||||
###############################################################################
|
||||
# F I R E W A L L O P T I O N S
|
||||
###############################################################################
|
||||
#
|
||||
# WARNING: THE 'FW' OPTION HAS BEEN REMOVED FROM THIS FILE -- The firewall
|
||||
# zone is now declared in /etc/shorewall/zones.
|
||||
#
|
||||
|
||||
#
|
||||
# ENABLE IP FORWARDING
|
||||
#
|
||||
# If you say "On" or "on" here, IPV4 Packet Forwarding is enabled. If you
|
||||
# say "Off" or "off", packet forwarding will be disabled. You would only want
|
||||
# to disable packet forwarding if you are installing Shorewall on a
|
||||
# standalone system or if you want all traffic through the Shorewall system
|
||||
# to be handled by proxies.
|
||||
#
|
||||
# If you set this variable to "Keep" or "keep", Shorewall will neither
|
||||
# enable nor disable packet forwarding.
|
||||
#
|
||||
|
||||
IP_FORWARDING=On
|
||||
|
||||
#
|
||||
# AUTOMATICALLY ADD NAT IP ADDRESSES
|
||||
#
|
||||
# If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses
|
||||
# for each NAT external address that you give in /etc/shorewall/nat. If you say
|
||||
# "No" or "no", you must add these aliases youself.
|
||||
#
|
||||
# WARNING: Addresses added by ADD_IP_ALIASES=Yes are deleted and re-added
|
||||
# during processing of the "shorewall restart" command. As a consequence,
|
||||
# connections using those addresses may be severed.
|
||||
#
|
||||
|
||||
ADD_IP_ALIASES=Yes
|
||||
|
||||
#
|
||||
# AUTOMATICALLY ADD SNAT IP ADDRESSES
|
||||
#
|
||||
# If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses
|
||||
# for each SNAT external address that you give in /etc/shorewall/masq. If you
|
||||
# say "No" or "no", you must add these aliases youself. LEAVE THIS SET TO "No"
|
||||
# unless you are sure that you need it -- most people don't!!!
|
||||
#
|
||||
# WARNING: Addresses added by ADD_SNAT_ALIASES=Yes are deleted and re-added
|
||||
# during processing of the "shorewall restart" command. As a consequence,
|
||||
# connections using those addresses may be severed.
|
||||
#
|
||||
|
||||
ADD_SNAT_ALIASES=No
|
||||
|
||||
#
|
||||
# RETAIN EXISTING ALIASES/IP ADDRESSES
|
||||
#
|
||||
# Normally, when ADD_IP_ALIASES=Yes and/or ADD_SNAT_ALIASES=Yes then Shorewall
|
||||
# will first delete the address then re-add it. This is to ensure that the
|
||||
# address is added with the specified label. Unfortunately, this can cause
|
||||
# problems if it results in the deletion of the last IP address on an
|
||||
# interface because then all routes through the interface are automatically
|
||||
# removed.
|
||||
#
|
||||
# You can cause Shorewall to retain existing addresses by setting
|
||||
# RETAIN_ALIASES=Yes.
|
||||
#
|
||||
|
||||
RETAIN_ALIASES=No
|
||||
|
||||
#
|
||||
# ENABLE TRAFFIC SHAPING
|
||||
#
|
||||
# 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=Internal or internal or leave the option empty then
|
||||
# Shorewall will use its builtin traffic shaper (tc4shorewall written by
|
||||
# Arne Bernin).
|
||||
#
|
||||
# See http://shorewall.net/traffic_shaping.htm for more information.
|
||||
|
||||
TC_ENABLED=Internal
|
||||
|
||||
#
|
||||
# TRAFFIC SHAPING EXPERT
|
||||
#
|
||||
# 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 /etc/shorewall/providers.
|
||||
#
|
||||
# If you know what you are doing, you can set TC_EXPERT=Yes and Shorewall
|
||||
# will not include these cautionary checks.
|
||||
|
||||
TC_EXPERT=No
|
||||
|
||||
#
|
||||
# Clear Traffic Shaping/Control
|
||||
#
|
||||
# If this option is set to 'No' then Shorewall won't clear the current
|
||||
# traffic control rules during [re]start. This setting is intended
|
||||
# for use by people that 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=No 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 /etc/shorewall/tcrules.
|
||||
#
|
||||
# If omitted, CLEAR_TC=Yes is assumed.
|
||||
#
|
||||
|
||||
CLEAR_TC=Yes
|
||||
|
||||
#
|
||||
# Mark Packets in the forward chain
|
||||
#
|
||||
# When processing the tcrules file, Shorewall normally marks packets in the
|
||||
# PREROUTING chain. To cause Shorewall to use the FORWARD chain instead, set
|
||||
# this to "Yes". If not specified or if set to the empty value (e.g.,
|
||||
# MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed.
|
||||
#
|
||||
# Marking packets in the FORWARD chain has the advantage that inbound
|
||||
# packets destined for Masqueraded/SNATed local hosts have had their
|
||||
# destination address rewritten so they can be marked based on their
|
||||
# destination. When packets are marked in the PREROUTING chain, packets
|
||||
# destined for Masqueraded/SNATed local hosts still have a destination address
|
||||
# corresponding to the firewall's external interface.
|
||||
#
|
||||
# Note: Older kernels do not support marking packets in the FORWARD chain and
|
||||
# setting this variable to Yes may cause startup problems.
|
||||
#
|
||||
|
||||
MARK_IN_FORWARD_CHAIN=No
|
||||
|
||||
#
|
||||
# MSS CLAMPING
|
||||
#
|
||||
# Set this variable to "Yes" or "yes" if you want the TCP "Clamp MSS to PMTU"
|
||||
# option. This option is most commonly required when your internet
|
||||
# interface is some variant of PPP (PPTP or PPPoE). Your kernel must
|
||||
# have CONFIG_IP_NF_TARGET_TCPMSS set.
|
||||
#
|
||||
# [From the kernel help:
|
||||
#
|
||||
# This option adds a `TCPMSS' target, which allows you to alter the
|
||||
# MSS value of TCP SYN packets, to control the maximum size for that
|
||||
# connection (usually limiting it to your outgoing interface's MTU
|
||||
# minus 40).
|
||||
#
|
||||
# This is used to overcome criminally braindead ISPs or servers which
|
||||
# block ICMP Fragmentation Needed packets. The symptoms of this
|
||||
# problem are that everything works fine from your Linux
|
||||
# firewall/router, but machines behind it can never exchange large
|
||||
# packets:
|
||||
# 1) Web browsers connect, then hang with no data received.
|
||||
# 2) Small mail works fine, but large emails hang.
|
||||
# 3) ssh works fine, but scp hangs after initial handshaking.
|
||||
# ]
|
||||
#
|
||||
# If left blank, or set to "No" or "no", the option is not enabled.
|
||||
#
|
||||
# You may also set this option to a numeric value in which case Shorewall will
|
||||
# set up a rule to modify the MSS value in SYN packets to the value that
|
||||
# you specify.
|
||||
#
|
||||
# Example:
|
||||
#
|
||||
# CLAMPMSS=1400
|
||||
#
|
||||
|
||||
CLAMPMSS=No
|
||||
|
||||
#
|
||||
# ROUTE FILTERING
|
||||
#
|
||||
# Set this variable to "Yes" or "yes" if you want kernel route filtering on all
|
||||
# interfaces started while Shorewall is started (anti-spoofing measure).
|
||||
#
|
||||
# If this variable is not set or is set to the empty value, "No" is assumed.
|
||||
# Regardless of the setting of ROUTE_FILTER, you can still enable route
|
||||
# filtering on individual interfaces using the 'routefilter' option in the
|
||||
# /etc/shorewall/interfaces file.
|
||||
#
|
||||
|
||||
ROUTE_FILTER=No
|
||||
|
||||
#
|
||||
# DNAT IP ADDRESS DETECTION
|
||||
#
|
||||
# Normally when Shorewall encounters the following rule:
|
||||
#
|
||||
# DNAT net loc:192.168.1.3 tcp 80
|
||||
#
|
||||
# it will forward TCP port 80 connections from the net to 192.168.1.3
|
||||
# REGARDLESS OF THE ORIGINAL DESTINATION ADDRESS. This behavior is
|
||||
# convenient for two reasons:
|
||||
#
|
||||
# a) If the the network interface has a dynamic IP address, the
|
||||
# firewall configuration will work even when the address
|
||||
# changes.
|
||||
#
|
||||
# b) It saves having to configure the IP address in the rule
|
||||
# while still allowing the firewall to be started before the
|
||||
# internet interface is brought up.
|
||||
#
|
||||
# This default behavior can also have a negative effect. If the
|
||||
# internet interface has more than one IP address then the above
|
||||
# rule will forward connection requests on all of these addresses;
|
||||
# that may not be what is desired.
|
||||
#
|
||||
# By setting DETECT_DNAT_IPADDRS=Yes, rules such as the above will apply
|
||||
# only if the original destination address is the primary IP address of
|
||||
# one of the interfaces associated with the source zone. Note that this
|
||||
# requires all interfaces to the source zone to be up when the firewall
|
||||
# is [re]started.
|
||||
#
|
||||
|
||||
DETECT_DNAT_IPADDRS=No
|
||||
|
||||
#
|
||||
# MUTEX TIMEOUT
|
||||
#
|
||||
# The value of this variable determines the number of seconds that programs
|
||||
# will wait for exclusive access to the Shorewall 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 restart" command.
|
||||
#
|
||||
|
||||
MUTEX_TIMEOUT=60
|
||||
|
||||
#
|
||||
# FOR ADMINS THAT REPEATEDLY SHOOT THEMSELVES IN THE FOOT
|
||||
#
|
||||
# Normally, when a "shorewall stop" command is issued or an error occurs during
|
||||
# the execution of another shorewall command, Shorewall puts the firewall into
|
||||
# a state where only traffic to/from the hosts listed in
|
||||
# /etc/shorewall/routestopped is accepted.
|
||||
#
|
||||
# When performing remote administration on a Shorewall firewall, it is
|
||||
# therefore recommended that the IP address of the computer being used for
|
||||
# administration be added to the firewall's /etc/shorewall/routestopped file.
|
||||
#
|
||||
# Some administrators have a hard time remembering to do this with the result
|
||||
# that they get to drive across town in the middle of the night to restart
|
||||
# a remote firewall (or worse, they have to get someone out of bed to drive
|
||||
# across town to restart a very remote firewall).
|
||||
#
|
||||
# For those administrators, we offer ADMINISABSENTMINDED=Yes. With this
|
||||
# setting, when the firewall enters the 'stopped' state:
|
||||
#
|
||||
# All traffic that is part of or related to established connections is still
|
||||
# allowed and all OUTPUT traffic is allowed. This is in addition to traffic
|
||||
# to and from hosts listed in /etc/shorewall/routestopped.
|
||||
#
|
||||
# If this variable is not set or it is set to the null value then
|
||||
# ADMINISABSENTMINDED=No is assumed.
|
||||
#
|
||||
|
||||
ADMINISABSENTMINDED=Yes
|
||||
|
||||
#
|
||||
# BLACKLIST Behavior
|
||||
#
|
||||
# Shorewall offers two types of blacklisting:
|
||||
#
|
||||
# - static blacklisting through the /etc/shorewall/blacklist file
|
||||
# together with the 'blacklist' interface option.
|
||||
# - dynamic blacklisting using the 'drop', 'reject' and 'allow' commands.
|
||||
#
|
||||
# The following variable determines whether the blacklist is checked for each
|
||||
# packet or for each new connection.
|
||||
#
|
||||
# BLACKLISTNEWONLY=Yes Only consult blacklists for new connection
|
||||
# requests
|
||||
#
|
||||
# BLACKLISTNEWONLY=No Consult blacklists for all packets.
|
||||
#
|
||||
# If the BLACKLISTNEWONLY option is not set or is set to the empty value then
|
||||
# BLACKLISTNEWONLY=No is assumed.
|
||||
#
|
||||
|
||||
BLACKLISTNEWONLY=Yes
|
||||
|
||||
#
|
||||
# Users with a large blacklist find that "shorwall [re]start" takes a long
|
||||
# time and that new connections are disabled during that time. By setting
|
||||
# DELAYBLACKLISTLOAD=Yes, you can cause Shorewall to enable new connections
|
||||
# before loading the blacklist.
|
||||
#
|
||||
|
||||
DELAYBLACKLISTLOAD=No
|
||||
|
||||
# MODULE NAME SUFFIX
|
||||
#
|
||||
# When loading a module named in /etc/shorewall/modules, Shorewall normally
|
||||
# looks in the MODULES DIRECTORY (see MODULESDIR above) for files whose names
|
||||
# end in ".o", ".ko", ".gz", "o.gz" or "ko.gz" . If your distribution uses a
|
||||
# different naming convention then you can specify the suffix (extension) for
|
||||
# module names in this variable.
|
||||
#
|
||||
# To see what suffix is used by your distribution:
|
||||
#
|
||||
# ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter
|
||||
#
|
||||
# All of the file names listed should have the same suffix (extension). Set
|
||||
# MODULE_SUFFIX to that suffix.
|
||||
#
|
||||
# Examples:
|
||||
#
|
||||
# If all file names end with ".kzo" then set MODULE_SUFFIX="kzo"
|
||||
# If all file names end with ".kz.o" then set MODULE_SUFFIX="kz.o"
|
||||
#
|
||||
|
||||
MODULE_SUFFIX=
|
||||
|
||||
#
|
||||
# DISABLE IPV6
|
||||
#
|
||||
# Distributions (notably SUSE) are beginning to ship with IPV6
|
||||
# enabled. If you are not using IPV6, you are at risk of being
|
||||
# exploited by users who do. Setting DISABLE_IPV6=Yes will cause
|
||||
# Shorewall to disable IPV6 traffic to/from and through your
|
||||
# firewall system. This requires that you have ip6tables installed.
|
||||
|
||||
DISABLE_IPV6=Yes
|
||||
|
||||
#
|
||||
# BRIDGING
|
||||
#
|
||||
# If you wish to restrict connections through a bridge
|
||||
# (see http://bridge.sf.net), then set BRIDGING=Yes. Your kernel must have
|
||||
# the physdev match option enabled; that option is available at the above URL
|
||||
# for 2.4 kernels and is included as a standard part of the 2.6 series
|
||||
# kernels. If not specified or specified as empty (BRIDGING="") then "No" is
|
||||
# assumed.
|
||||
#
|
||||
|
||||
BRIDGING=No
|
||||
|
||||
#
|
||||
# DYNAMIC ZONES
|
||||
#
|
||||
# If you need to be able to add and delete hosts from zones dynamically then
|
||||
# set DYNAMIC_ZONES=Yes. Otherwise, set DYNAMIC_ZONES=No.
|
||||
|
||||
DYNAMIC_ZONES=No
|
||||
|
||||
#
|
||||
# USE PKTTYPE MATCH
|
||||
#
|
||||
# Some users have reported problems with the PKTTYPE match extension not being
|
||||
# able to match certain broadcast packets. If you set PKTTYPE=No then Shorewall
|
||||
# will use IP addresses to detect broadcasts rather than pkttype. If not given
|
||||
# or if given as empty (PKTTYPE="") then PKTTYPE=Yes is assumed.
|
||||
#
|
||||
|
||||
PKTTYPE=Yes
|
||||
|
||||
#
|
||||
# RFC 1918 BEHAVIOR
|
||||
#
|
||||
# Traditionally, the RETURN target in the 'rfc1918' file has caused 'norfc1918'
|
||||
# processing to cease for a packet if the packet's source IP address matches
|
||||
# the rule. Thus, if you have:
|
||||
#
|
||||
# SUBNETS TARGET
|
||||
# 192.168.1.0/24 RETURN
|
||||
#
|
||||
# then traffic from 192.168.1.4 to 10.0.3.9 will be accepted even though you
|
||||
# also have:
|
||||
#
|
||||
# SUBNETS TARGET
|
||||
# 10.0.0.0/8 logdrop
|
||||
#
|
||||
# Setting RFC1918_STRICT=Yes will cause such traffic to be logged and dropped
|
||||
# since while the packet's source matches the RETURN rule, the packet's
|
||||
# destination matches the 'logdrop' rule.
|
||||
#
|
||||
# If not specified or specified as empty (e.g., RFC1918_STRICT="") then
|
||||
# RFC1918_STRICT=No is assumed.
|
||||
#
|
||||
# WARNING: RFC1918_STRICT=Yes requires that your kernel and iptables support
|
||||
# 'conntrack state' match.
|
||||
#
|
||||
|
||||
RFC1918_STRICT=No
|
||||
|
||||
#
|
||||
# MAC List Table
|
||||
#
|
||||
# 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 with MACLIST_TABLE=mangle.
|
||||
|
||||
MACLIST_TABLE=filter
|
||||
|
||||
#
|
||||
# MACLIST caching
|
||||
#
|
||||
# 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
|
||||
# (/etc/shorewall/maclist).
|
||||
#
|
||||
# When a new connection arrives from a 'maclist' interface, the packet passes
|
||||
# through the list of entries for that interface in /etc/shorewall/maclist. 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 occuring
|
||||
# within $MACLIST_TTL seconds will be accepted without having to scan all of
|
||||
# the entries. After $MACLIST_TTL from the first accepted connection request,
|
||||
# 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.
|
||||
#
|
||||
|
||||
MACLIST_TTL=
|
||||
|
||||
#
|
||||
# Save/Restore IPSETS
|
||||
#
|
||||
# If SAVE_IPSETS=Yes then Shorewall will:
|
||||
#
|
||||
# Restore the last saved ipset contents during "shorewall [re]start"
|
||||
# Save the current ipset contents during "shorewall save"
|
||||
#
|
||||
# Regardless of the setting of SAVE_IPSETS, if ipset contents were
|
||||
# saved during a "shorewall save" then they will be restored during
|
||||
# a subsequent "shorewall restore".
|
||||
#
|
||||
|
||||
SAVE_IPSETS=No
|
||||
|
||||
#
|
||||
# Map Old Actions
|
||||
#
|
||||
# Previously, Shorewall included a large number of standard actions (AllowPing,
|
||||
# AllowFTP, ...). These have been replaced with parameterized macros. For
|
||||
# compatibility, Shorewall can map the old names into invocations of the new
|
||||
# macros if you set MAPOLDACTIONS=Yes. If this option is not set or is set to
|
||||
# the empty value (MAPOLDACTIONS="") then MAPOLDACTIONS=Yes is assumed
|
||||
#
|
||||
|
||||
MAPOLDACTIONS=No
|
||||
|
||||
#
|
||||
# Fast ESTABLISHED/RELATED handling
|
||||
#
|
||||
# Normally, Shorewall delays 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 'loc2net' chain.
|
||||
#
|
||||
# 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 and
|
||||
# RELATED sections of the rules file.
|
||||
|
||||
FASTACCEPT=No
|
||||
|
||||
#
|
||||
# Implicit CONTINUE policy for sub-zones
|
||||
#
|
||||
# When a zone is declared to be a subzone of one or more other zones, it
|
||||
# is typically the case that you want the rules for the parent zone(s) to
|
||||
# be applied to connections to/from the subzone that don't match any
|
||||
# subzone specific rules. That way, you don't have to duplicate the parent
|
||||
# zone's rules in order for them to also apply to the subzone(s). That is
|
||||
# the behavior with IMPLICIT_CONTINUE=Yes. If you don't want that behavior
|
||||
# and want the policies for the sub-zone to be determined by the standard
|
||||
# policy processing, set IMPLICIT_CONTINUE=No or IMPLICIT_CONTINUE=.
|
||||
#
|
||||
# Note that even with IMPLICIT_CONTINUE=Yes, you can override the implicit
|
||||
# CONTINUE policy by adding an explicit policy (one that does not contain
|
||||
# "all" in either the SOURCE or DEST columns).
|
||||
|
||||
IMPLICIT_CONTINUE=Yes
|
||||
|
||||
#
|
||||
# Use high mark values for policy routing
|
||||
#
|
||||
# Normally, Shorewall restricts the set of mark values to 1-255. If you set
|
||||
# HIGH_ROUTE_MARKS=Yes, Shorewall will rather restrict the set of routing
|
||||
# mark values (those specified in the /etc/shorewall/providers file) to
|
||||
# a multiple of 256 (256 to 65280) or their hexadecimal equivalents
|
||||
# (0x0100 to 0xff00, with the low-order byte of the value being zero).
|
||||
# This allows connection marks to be shared between traffic shaping and
|
||||
# policy routing. Traffic shaping marks are always restricted to 1-255.
|
||||
#
|
||||
# Setting HIGH_ROUTE_MARKS=Yes requires that your kernel and iptables support
|
||||
# both the extended CONNMARK target and the extended connmark match
|
||||
# capabilities (see the output of "shorewall show capabilities").
|
||||
|
||||
HIGH_ROUTE_MARKS=No
|
||||
|
||||
#
|
||||
# Use Actions
|
||||
#
|
||||
# While Shorewall Actions can be very useful, they also require a sizable
|
||||
# amount of code to implement. By setting USE_ACTIONS=No, you can omit
|
||||
# /usr/share/shorewall/lib/actions from your configuration.
|
||||
|
||||
USE_ACTIONS=Yes
|
||||
|
||||
#
|
||||
# Optimize Ruleset
|
||||
#
|
||||
# Traditionally, Shorewall has created rules for the complete matrix of
|
||||
# Networks 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 changes. When the matrix is sparse, this results in lots of
|
||||
# largely useless rules.
|
||||
#
|
||||
# These extra rules can be eliminated by setting OPTIMIZE=1 and included
|
||||
# by setting OPTIMIZE=0
|
||||
#
|
||||
|
||||
OPTIMIZE=1
|
||||
|
||||
###############################################################################
|
||||
# P A C K E T D I S P O S I T I O N
|
||||
###############################################################################
|
||||
#
|
||||
# BLACKLIST DISPOSITION
|
||||
#
|
||||
# Set this variable to the action that you want to perform on packets from
|
||||
# Blacklisted systems. Must be DROP or REJECT. If not set or set to empty,
|
||||
# DROP is assumed.
|
||||
#
|
||||
|
||||
BLACKLIST_DISPOSITION=DROP
|
||||
|
||||
#
|
||||
# MAC List Disposition
|
||||
#
|
||||
# This variable determines the disposition of connection requests arriving
|
||||
# on interfaces that have the 'maclist' option and that are from a device
|
||||
# that is not listed for that interface in /etc/shorewall/maclist. Valid
|
||||
# values are ACCEPT, DROP and REJECT. If not specified or specified as
|
||||
# empty (MACLIST_DISPOSITION="") then REJECT is assumed
|
||||
#
|
||||
|
||||
MACLIST_DISPOSITION=REJECT
|
||||
|
||||
#
|
||||
# TCP FLAGS Disposition
|
||||
#
|
||||
# This variable determins the disposition of packets having an invalid
|
||||
# combination of TCP flags that are received on interfaces having the
|
||||
# 'tcpflags' option specified in /etc/shorewall/interfaces or in
|
||||
# /etc/shorewall/hosts. If not specified or specified as empty
|
||||
# (TCP_FLAGS_DISPOSITION="") then DROP is assumed.
|
||||
#
|
||||
|
||||
TCP_FLAGS_DISPOSITION=DROP
|
||||
|
||||
#LAST LINE -- DO NOT REMOVE
|
||||
|
||||
@ -10,388 +10,74 @@
|
||||
# version 2.1 of the License, or (at your option) any later version.
|
||||
#
|
||||
# See the file README.txt for further details.
|
||||
#
|
||||
# For information about the settings in this file, type "man shorewall.conf"
|
||||
#
|
||||
# Additional information is available at
|
||||
# http://www.shorewall.net/Documentation.htm#Conf
|
||||
###############################################################################
|
||||
# S T A R T U P E N A B L E D
|
||||
###############################################################################
|
||||
#
|
||||
# Once you have configured Shorewall, you may change the setting of
|
||||
# this variable to 'Yes'
|
||||
#
|
||||
|
||||
STARTUP_ENABLED=No
|
||||
|
||||
###############################################################################
|
||||
# V E R B O S I T Y
|
||||
###############################################################################
|
||||
#
|
||||
# Shorewall has traditionally been very noisy. You may now set the default
|
||||
# level of verbosity here.
|
||||
#
|
||||
# Values are:
|
||||
#
|
||||
# 0 -- Silent. You may make it more verbose using the -v option
|
||||
# 1 -- Major progress messages displayed
|
||||
# 2 -- All progress messages displayed (old default behavior)
|
||||
#
|
||||
# If not specified, then 2 is assumed
|
||||
|
||||
VERBOSITY=1
|
||||
|
||||
###############################################################################
|
||||
# L O G G I N G
|
||||
###############################################################################
|
||||
#
|
||||
# General note about log levels. 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 specifify. 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 target support, you may also
|
||||
# specify a log level of ULOG (must be all caps). Rather than log its
|
||||
# messages to syslogd, Shorewall will direct netfilter to log the messages
|
||||
# via the ULOG 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). Ulogd is also available from
|
||||
# http://www.gnumonks.org/projects/ulogd and can be configured to log all
|
||||
# Shorewall message to their own log file
|
||||
###############################################################################
|
||||
#
|
||||
# LOG FILE LOCATION
|
||||
#
|
||||
# This variable tells the /sbin/shorewall program where to look for Shorewall
|
||||
# log messages. If not set or set to an empty string (e.g., LOGFILE="") then
|
||||
# /var/log/messages is assumed.
|
||||
#
|
||||
# WARNING: The LOGFILE variable simply tells the 'shorewall' program where to
|
||||
# look for Shorewall messages.It does NOT control the destination for
|
||||
# these messages. For information about how to do that, see
|
||||
#
|
||||
# http://www.shorewall.net/shorewall_logging.html
|
||||
#
|
||||
|
||||
LOGFILE=/var/log/messages
|
||||
|
||||
#
|
||||
# LOG FORMAT
|
||||
#
|
||||
# Shell 'printf' Formatting template for the --log-prefix value in log messages
|
||||
# generated by Shorewall to identify Shorewall log messages. The supplied
|
||||
# template is expected to accept either two or three arguments; the first is
|
||||
# the chain name, the second (optional) is the logging rule number within that
|
||||
# chain and the third is the ACTION specifying the disposition of the packet
|
||||
# being logged. You must use the %d formatting type for the rule number; if
|
||||
# your template does not contain %d then the rule number will not be included.
|
||||
#
|
||||
# If you want to integrate Shorewall with fireparse, then set LOGFORMAT as:
|
||||
#
|
||||
# LOGFORMAT="fp=%s:%d a=%s "
|
||||
#
|
||||
# If not specified or specified as empty (LOGFORMAT="") then the value
|
||||
# "Shorewall:%s:%s:" is assumed.
|
||||
#
|
||||
# Beginning with Shorewall 3.3.3, The contents of LOGFORMAT determine the
|
||||
# maximum length of a Shorewall zone name. LOGFORMAT must produce a string no
|
||||
# longer than 29 bytes when passed the chain name, [rule number], and 'ACCEPT'.
|
||||
# Using the default LOGFORMAT, the name of a chain must be 11 characters or
|
||||
# less; since chain names are often of the form <zone1>2<zone2>, zone names are
|
||||
# limited to 5 characters using the default LOGFORMAT. In contrast, if
|
||||
# LOGFORMAT="FW:%s:%s:", then zone names can be as long as 8 characters.
|
||||
|
||||
LOGFORMAT="Shorewall:%s:%s:"
|
||||
|
||||
#
|
||||
# LOG FORMAT Continued
|
||||
#
|
||||
# Using the default LOGFORMAT, chain names may not exceed 11 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.
|
||||
#
|
||||
|
||||
LOGTAGONLY=No
|
||||
|
||||
#
|
||||
# LOG RATE LIMITING
|
||||
#
|
||||
# The next two variables can be used to control the amount of log output
|
||||
# generated. LOGRATE is expressed as a number followed by an optional
|
||||
# `/second', `/minute', `/hour', or `/day' suffix and specifies the maximum
|
||||
# rate at which a particular message will occur. LOGBURST determines the
|
||||
# maximum initial burst size that will be logged. If set empty, the default
|
||||
# value of 5 will be used.
|
||||
#
|
||||
# If BOTH variables are set empty then logging will not be rate-limited.
|
||||
#
|
||||
# Example:
|
||||
#
|
||||
# LOGRATE=10/minute
|
||||
# LOGBURST=5
|
||||
#
|
||||
# For each logging rule, the first time the rule is reached, the packet
|
||||
# will be logged; in fact, since the burst is 5, the first five packets
|
||||
# will be logged. After this, it will be 6 seconds (1 minute divided by
|
||||
# the rate of 10) before a message will be logged from the rule, regardless
|
||||
# of how many packets reach it. Also, every 6 seconds which passes without
|
||||
# matching a packet, one of the bursts will be regained; if no packets hit
|
||||
# the rule for 30 seconds, the burst will be fully recharged; back where
|
||||
# we started.
|
||||
#
|
||||
|
||||
LOGRATE=
|
||||
LOGBURST=
|
||||
|
||||
#
|
||||
# LOG ALL NEW
|
||||
#
|
||||
# This option should only be used when you are trying to analyze a problem.
|
||||
# It causes all packets in the Netfilter NEW state to be logged as the
|
||||
# first rule in each builtin chain. To use this option, set LOGALLNEW to
|
||||
# the log level that you want these packets logged at (e.g.,
|
||||
# LOGALLNEW=debug).
|
||||
#
|
||||
LOGBURST=
|
||||
|
||||
LOGALLNEW=
|
||||
|
||||
#
|
||||
# BLACKLIST LOG LEVEL
|
||||
#
|
||||
# Set this variable to the syslogd level that you want blacklist packets logged
|
||||
# (beware of DOS attacks resulting from such logging). If not set, no logging
|
||||
# of blacklist packets occurs.
|
||||
#
|
||||
# See the comment at the top of this section for a description of log levels
|
||||
#
|
||||
|
||||
BLACKLIST_LOGLEVEL=
|
||||
|
||||
#
|
||||
# MAC List Log Level
|
||||
#
|
||||
# Specifies the logging level for connection requests that fail MAC
|
||||
# verification. If set to the empty value (MACLIST_LOG_LEVEL="") then
|
||||
# such connection requests will not be logged.
|
||||
#
|
||||
# See the comment at the top of this section for a description of log levels
|
||||
#
|
||||
# If you wish to filter messages logged under this option, then supply
|
||||
# the /etc/shorewall/maclog extension script (you will have to create the
|
||||
# file yourself). That script will be copied into the compiled firewall
|
||||
# script at a point just before logging occurs. The shell variable CHAIN
|
||||
# will be set to the name of the chain where the logging rule will be
|
||||
# inserted.
|
||||
#
|
||||
# If you set MACLIST_TABLE=mangle later in this file, be sure that your
|
||||
# 'run_iptables' commands include '-t mangle'.
|
||||
#
|
||||
# See http://www.shorewall.net/shorewall_extension_scripts.htm for more
|
||||
# information about extension scripts.
|
||||
#
|
||||
|
||||
MACLIST_LOG_LEVEL=info
|
||||
|
||||
#
|
||||
# TCP FLAGS Log Level
|
||||
#
|
||||
# Specifies the logging level for packets that fail TCP Flags
|
||||
# verification. If set to the empty value (TCP_FLAGS_LOG_LEVEL="") then
|
||||
# such packets will not be logged.
|
||||
#
|
||||
# See the comment at the top of this section for a description of log levels
|
||||
#
|
||||
|
||||
TCP_FLAGS_LOG_LEVEL=info
|
||||
|
||||
#
|
||||
# RFC1918 Log Level
|
||||
#
|
||||
# Specifies the logging level for packets that fail RFC 1918
|
||||
# verification. If set to the empty value (RFC1918_LOG_LEVEL="") then
|
||||
# RFC1918_LOG_LEVEL=info is assumed.
|
||||
#
|
||||
# See the comment at the top of this section for a description of log levels
|
||||
#
|
||||
|
||||
RFC1918_LOG_LEVEL=info
|
||||
|
||||
#
|
||||
# SMURF Log Level
|
||||
#
|
||||
# Specifies the logging level for smurf packets dropped by the
|
||||
#'nosmurfs' interface option in /etc/shorewall/interfaces and in
|
||||
# /etc/shorewall/hosts. If set to the empty value ( SMURF_LOG_LEVEL=""
|
||||
# ) then dropped smurfs are not logged.
|
||||
#
|
||||
# See the comment at the top of this section for a description of log levels
|
||||
#
|
||||
|
||||
SMURF_LOG_LEVEL=info
|
||||
|
||||
#
|
||||
# MARTIAN LOGGING
|
||||
#
|
||||
# Setting LOG_MARTIANS=Yes will enable kernel logging of all received packets
|
||||
# that have impossible source IP addresses. This logging may be enabled
|
||||
# on individual interfaces by using the 'logmartians' option in
|
||||
# /etc/shorewall/interfaces.
|
||||
#
|
||||
|
||||
LOG_MARTIANS=No
|
||||
|
||||
###############################################################################
|
||||
# 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
|
||||
###############################################################################
|
||||
#
|
||||
# IPTABLES
|
||||
#
|
||||
# Full path to iptables executable Shorewall uses to build the firewall. If
|
||||
# not specified or if specified with an empty value (e.g., IPTABLES="") then
|
||||
# the iptables executable located via the PATH setting below is used.
|
||||
#
|
||||
|
||||
IPTABLES=
|
||||
|
||||
#
|
||||
# PATH - Change this if you want to change the order in which Shorewall
|
||||
# searches directories for executable files.
|
||||
#
|
||||
|
||||
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
|
||||
|
||||
#
|
||||
# SHELL
|
||||
#
|
||||
# The firewall script is normally interpreted by /bin/sh. If you wish to change
|
||||
# the shell used to interpret that script, specify the shell here.
|
||||
#
|
||||
|
||||
SHOREWALL_SHELL=/bin/sh
|
||||
|
||||
# SUBSYSTEM LOCK FILE
|
||||
#
|
||||
# Set this to the name of the lock file expected by your init scripts. For
|
||||
# RedHat, this should be /var/lock/subsys/shorewall. If your init scripts don't
|
||||
# use lock files, set this to "".
|
||||
#
|
||||
|
||||
SUBSYSLOCK=/var/lock/subsys/shorewall
|
||||
|
||||
#
|
||||
# KERNEL MODULE DIRECTORY
|
||||
#
|
||||
# If your netfilter kernel modules are in a directory other than
|
||||
# /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter then specify that
|
||||
# directory in this variable. Example: MODULESDIR=/etc/modules.
|
||||
#
|
||||
|
||||
MODULESDIR=
|
||||
|
||||
#
|
||||
# CONFIGURATION SEARCH PATH
|
||||
#
|
||||
# This option holds a list of directory names separated by colons
|
||||
# (":"). Shorewall will search each directory in turn when looking for a
|
||||
# configuration file. When processing a 'try' command or a command
|
||||
# containing the "-c" option or that specifies a configuration directory,
|
||||
# Shorewall will automatically add the directory specified in the command
|
||||
# to the front of this list.
|
||||
#
|
||||
# If not specified or specified as null ("CONFIG_PATH=""),
|
||||
# the default is distribution-defined. See the output of "shorewall show
|
||||
# config" to find the default value on your distribution.
|
||||
#
|
||||
|
||||
CONFIG_PATH=/etc/shorewall:/usr/share/shorewall
|
||||
|
||||
#
|
||||
# RESTORE SCRIPT
|
||||
#
|
||||
# This option determines the script to be run in the following cases:
|
||||
#
|
||||
# shorewall -f start
|
||||
# shorewall restore
|
||||
# shorewall save
|
||||
# shorewall forget
|
||||
# Failure of shorewall start or shorewall restart
|
||||
#
|
||||
# The value of the option must be the name of an executable file in the
|
||||
# directory /var/lib/shorewall. If this option is not set or if it is
|
||||
# set to the empty value (RESTOREFILE="") then RESTOREFILE=restore is
|
||||
# assumed.
|
||||
#
|
||||
|
||||
RESTOREFILE=
|
||||
|
||||
#
|
||||
# OLD ZONE FILE FORMAT
|
||||
#
|
||||
# Previous versions of Shorewall had both a 'zones' file and an 'ipsec' file.
|
||||
# Beginning with 2.5.0, those files were combined. For users who haven't
|
||||
# converted, we offer this variable that sets the name of the file for ipsec
|
||||
# information. This option must take the value "zones" or "ipsec". If the
|
||||
# option is not set or is set to the empty value (IPSECFILE="") then "ipsec"
|
||||
# is assumed.
|
||||
#
|
||||
|
||||
IPSECFILE=zones
|
||||
|
||||
###############################################################################
|
||||
# D E F A U L T A C T I O N S / M A C R O S
|
||||
###############################################################################
|
||||
#
|
||||
# In earlier Shorewall versions, a "default action" for DROP and REJECT
|
||||
# policies was specified in the file /usr/share/shorewall/actions.std.
|
||||
#
|
||||
# To allow for default rules to be applied when USE_ACTIONS=No, the
|
||||
# DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT and QUEUE_DEFAULT options have
|
||||
# been 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 two are
|
||||
# similar for ACCEPT and QUEUE policies.
|
||||
#
|
||||
# The value applied to these may be:
|
||||
#
|
||||
# a) The name of an action.
|
||||
# b) The name of a macro
|
||||
# c) 'None' or 'none'
|
||||
#
|
||||
# The default values are:
|
||||
#
|
||||
# DROP_DEFAULT="Drop"
|
||||
# REJECT_DEFAULT="Reject"
|
||||
# ACCEPT_DEFAULT="none"
|
||||
# QUEUE_DEFAULT="none"
|
||||
#
|
||||
# If USE_ACTIONS=Yes, then these values refer to action.Drop and action.Reject
|
||||
# respectively. If USE_ACTIONS=No, then these values refer to macro.Drop and
|
||||
# macro.Reject.
|
||||
#
|
||||
# If you set the value of either option to "None" then no default action
|
||||
# will be used and the default action or macro must be specified in
|
||||
# /etc/shorewall/policy
|
||||
|
||||
DROP_DEFAULT="Drop"
|
||||
REJECT_DEFAULT="Reject"
|
||||
@ -401,570 +87,75 @@ QUEUE_DEFAULT="none"
|
||||
###############################################################################
|
||||
# F I R E W A L L O P T I O N S
|
||||
###############################################################################
|
||||
#
|
||||
# WARNING: THE 'FW' OPTION HAS BEEN REMOVED FROM THIS FILE -- The firewall
|
||||
# zone is now declared in /etc/shorewall/zones.
|
||||
#
|
||||
|
||||
#
|
||||
# ENABLE IP FORWARDING
|
||||
#
|
||||
# If you say "On" or "on" here, IPV4 Packet Forwarding is enabled. If you
|
||||
# say "Off" or "off", packet forwarding will be disabled. You would only want
|
||||
# to disable packet forwarding if you are installing Shorewall on a
|
||||
# standalone system or if you want all traffic through the Shorewall system
|
||||
# to be handled by proxies.
|
||||
#
|
||||
# If you set this variable to "Keep" or "keep", Shorewall will neither
|
||||
# enable nor disable packet forwarding.
|
||||
#
|
||||
|
||||
IP_FORWARDING=On
|
||||
|
||||
#
|
||||
# AUTOMATICALLY ADD NAT IP ADDRESSES
|
||||
#
|
||||
# If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses
|
||||
# for each NAT external address that you give in /etc/shorewall/nat. If you say
|
||||
# "No" or "no", you must add these aliases youself.
|
||||
#
|
||||
# WARNING: Addresses added by ADD_IP_ALIASES=Yes are deleted and re-added
|
||||
# during processing of the "shorewall restart" command. As a consequence,
|
||||
# connections using those addresses may be severed.
|
||||
#
|
||||
|
||||
ADD_IP_ALIASES=Yes
|
||||
|
||||
#
|
||||
# AUTOMATICALLY ADD SNAT IP ADDRESSES
|
||||
#
|
||||
# If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses
|
||||
# for each SNAT external address that you give in /etc/shorewall/masq. If you
|
||||
# say "No" or "no", you must add these aliases youself. LEAVE THIS SET TO "No"
|
||||
# unless you are sure that you need it -- most people don't!!!
|
||||
#
|
||||
# WARNING: Addresses added by ADD_SNAT_ALIASES=Yes are deleted and re-added
|
||||
# during processing of the "shorewall restart" command. As a consequence,
|
||||
# connections using those addresses may be severed.
|
||||
#
|
||||
|
||||
ADD_SNAT_ALIASES=No
|
||||
|
||||
#
|
||||
# RETAIN EXISTING ALIASES/IP ADDRESSES
|
||||
#
|
||||
# Normally, when ADD_IP_ALIASES=Yes and/or ADD_SNAT_ALIASES=Yes then Shorewall
|
||||
# will first delete the address then re-add it. This is to ensure that the
|
||||
# address is added with the specified label. Unfortunately, this can cause
|
||||
# problems if it results in the deletion of the last IP address on an
|
||||
# interface because then all routes through the interface are automatically
|
||||
# removed.
|
||||
#
|
||||
# You can cause Shorewall to retain existing addresses by setting
|
||||
# RETAIN_ALIASES=Yes.
|
||||
#
|
||||
|
||||
RETAIN_ALIASES=No
|
||||
|
||||
#
|
||||
# ENABLE TRAFFIC SHAPING
|
||||
#
|
||||
# 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=Internal or internal or leave the option empty then
|
||||
# Shorewall will use its builtin traffic shaper (tc4shorewall written by
|
||||
# Arne Bernin).
|
||||
#
|
||||
# See http://shorewall.net/traffic_shaping.htm for more information.
|
||||
|
||||
TC_ENABLED=Internal
|
||||
|
||||
#
|
||||
# TRAFFIC SHAPING EXPERT
|
||||
#
|
||||
# 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 /etc/shorewall/providers.
|
||||
#
|
||||
# If you know what you are doing, you can set TC_EXPERT=Yes and Shorewall
|
||||
# will not include these cautionary checks.
|
||||
|
||||
TC_EXPERT=No
|
||||
|
||||
#
|
||||
# Clear Traffic Shaping/Control
|
||||
#
|
||||
# If this option is set to 'No' then Shorewall won't clear the current
|
||||
# traffic control rules during [re]start. This setting is intended
|
||||
# for use by people that 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=No 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 /etc/shorewall/tcrules.
|
||||
#
|
||||
# If omitted, CLEAR_TC=Yes is assumed.
|
||||
#
|
||||
|
||||
CLEAR_TC=Yes
|
||||
|
||||
#
|
||||
# Mark Packets in the forward chain
|
||||
#
|
||||
# When processing the tcrules file, Shorewall normally marks packets in the
|
||||
# PREROUTING chain. To cause Shorewall to use the FORWARD chain instead, set
|
||||
# this to "Yes". If not specified or if set to the empty value (e.g.,
|
||||
# MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed.
|
||||
#
|
||||
# Marking packets in the FORWARD chain has the advantage that inbound
|
||||
# packets destined for Masqueraded/SNATed local hosts have had their
|
||||
# destination address rewritten so they can be marked based on their
|
||||
# destination. When packets are marked in the PREROUTING chain, packets
|
||||
# destined for Masqueraded/SNATed local hosts still have a destination address
|
||||
# corresponding to the firewall's external interface.
|
||||
#
|
||||
# Note: Older kernels do not support marking packets in the FORWARD chain and
|
||||
# setting this variable to Yes may cause startup problems.
|
||||
#
|
||||
|
||||
MARK_IN_FORWARD_CHAIN=No
|
||||
|
||||
#
|
||||
# MSS CLAMPING
|
||||
#
|
||||
# Set this variable to "Yes" or "yes" if you want the TCP "Clamp MSS to PMTU"
|
||||
# option. This option is most commonly required when your internet
|
||||
# interface is some variant of PPP (PPTP or PPPoE). Your kernel must
|
||||
# have CONFIG_IP_NF_TARGET_TCPMSS set.
|
||||
#
|
||||
# [From the kernel help:
|
||||
#
|
||||
# This option adds a `TCPMSS' target, which allows you to alter the
|
||||
# MSS value of TCP SYN packets, to control the maximum size for that
|
||||
# connection (usually limiting it to your outgoing interface's MTU
|
||||
# minus 40).
|
||||
#
|
||||
# This is used to overcome criminally braindead ISPs or servers which
|
||||
# block ICMP Fragmentation Needed packets. The symptoms of this
|
||||
# problem are that everything works fine from your Linux
|
||||
# firewall/router, but machines behind it can never exchange large
|
||||
# packets:
|
||||
# 1) Web browsers connect, then hang with no data received.
|
||||
# 2) Small mail works fine, but large emails hang.
|
||||
# 3) ssh works fine, but scp hangs after initial handshaking.
|
||||
# ]
|
||||
#
|
||||
# If left blank, or set to "No" or "no", the option is not enabled.
|
||||
#
|
||||
# You may also set this option to a numeric value in which case Shorewall will
|
||||
# set up a rule to modify the MSS value in SYN packets to the value that
|
||||
# you specify.
|
||||
#
|
||||
# Example:
|
||||
#
|
||||
# CLAMPMSS=1400
|
||||
#
|
||||
|
||||
CLAMPMSS=No
|
||||
|
||||
#
|
||||
# ROUTE FILTERING
|
||||
#
|
||||
# Set this variable to "Yes" or "yes" if you want kernel route filtering on all
|
||||
# interfaces started while Shorewall is started (anti-spoofing measure).
|
||||
#
|
||||
# If this variable is not set or is set to the empty value, "No" is assumed.
|
||||
# Regardless of the setting of ROUTE_FILTER, you can still enable route
|
||||
# filtering on individual interfaces using the 'routefilter' option in the
|
||||
# /etc/shorewall/interfaces file.
|
||||
#
|
||||
|
||||
ROUTE_FILTER=No
|
||||
|
||||
#
|
||||
# DNAT IP ADDRESS DETECTION
|
||||
#
|
||||
# Normally when Shorewall encounters the following rule:
|
||||
#
|
||||
# DNAT net loc:192.168.1.3 tcp 80
|
||||
#
|
||||
# it will forward TCP port 80 connections from the net to 192.168.1.3
|
||||
# REGARDLESS OF THE ORIGINAL DESTINATION ADDRESS. This behavior is
|
||||
# convenient for two reasons:
|
||||
#
|
||||
# a) If the the network interface has a dynamic IP address, the
|
||||
# firewall configuration will work even when the address
|
||||
# changes.
|
||||
#
|
||||
# b) It saves having to configure the IP address in the rule
|
||||
# while still allowing the firewall to be started before the
|
||||
# internet interface is brought up.
|
||||
#
|
||||
# This default behavior can also have a negative effect. If the
|
||||
# internet interface has more than one IP address then the above
|
||||
# rule will forward connection requests on all of these addresses;
|
||||
# that may not be what is desired.
|
||||
#
|
||||
# By setting DETECT_DNAT_IPADDRS=Yes, rules such as the above will apply
|
||||
# only if the original destination address is the primary IP address of
|
||||
# one of the interfaces associated with the source zone. Note that this
|
||||
# requires all interfaces to the source zone to be up when the firewall
|
||||
# is [re]started.
|
||||
#
|
||||
|
||||
DETECT_DNAT_IPADDRS=No
|
||||
|
||||
#
|
||||
# MUTEX TIMEOUT
|
||||
#
|
||||
# The value of this variable determines the number of seconds that programs
|
||||
# will wait for exclusive access to the Shorewall 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 restart" command.
|
||||
#
|
||||
|
||||
MUTEX_TIMEOUT=60
|
||||
|
||||
#
|
||||
# FOR ADMINS THAT REPEATEDLY SHOOT THEMSELVES IN THE FOOT
|
||||
#
|
||||
# Normally, when a "shorewall stop" command is issued or an error occurs during
|
||||
# the execution of another shorewall command, Shorewall puts the firewall into
|
||||
# a state where only traffic to/from the hosts listed in
|
||||
# /etc/shorewall/routestopped is accepted.
|
||||
#
|
||||
# When performing remote administration on a Shorewall firewall, it is
|
||||
# therefore recommended that the IP address of the computer being used for
|
||||
# administration be added to the firewall's /etc/shorewall/routestopped file.
|
||||
#
|
||||
# Some administrators have a hard time remembering to do this with the result
|
||||
# that they get to drive across town in the middle of the night to restart
|
||||
# a remote firewall (or worse, they have to get someone out of bed to drive
|
||||
# across town to restart a very remote firewall).
|
||||
#
|
||||
# For those administrators, we offer ADMINISABSENTMINDED=Yes. With this
|
||||
# setting, when the firewall enters the 'stopped' state:
|
||||
#
|
||||
# All traffic that is part of or related to established connections is still
|
||||
# allowed and all OUTPUT traffic is allowed. This is in addition to traffic
|
||||
# to and from hosts listed in /etc/shorewall/routestopped.
|
||||
#
|
||||
# If this variable is not set or it is set to the null value then
|
||||
# ADMINISABSENTMINDED=No is assumed.
|
||||
#
|
||||
|
||||
ADMINISABSENTMINDED=Yes
|
||||
|
||||
#
|
||||
# BLACKLIST Behavior
|
||||
#
|
||||
# Shorewall offers two types of blacklisting:
|
||||
#
|
||||
# - static blacklisting through the /etc/shorewall/blacklist file
|
||||
# together with the 'blacklist' interface option.
|
||||
# - dynamic blacklisting using the 'drop', 'reject' and 'allow' commands.
|
||||
#
|
||||
# The following variable determines whether the blacklist is checked for each
|
||||
# packet or for each new connection.
|
||||
#
|
||||
# BLACKLISTNEWONLY=Yes Only consult blacklists for new connection
|
||||
# requests
|
||||
#
|
||||
# BLACKLISTNEWONLY=No Consult blacklists for all packets.
|
||||
#
|
||||
# If the BLACKLISTNEWONLY option is not set or is set to the empty value then
|
||||
# BLACKLISTNEWONLY=No is assumed.
|
||||
#
|
||||
|
||||
BLACKLISTNEWONLY=Yes
|
||||
|
||||
#
|
||||
# Users with a large blacklist find that "shorwall [re]start" takes a long
|
||||
# time and that new connections are disabled during that time. By setting
|
||||
# DELAYBLACKLISTLOAD=Yes, you can cause Shorewall to enable new connections
|
||||
# before loading the blacklist.
|
||||
#
|
||||
|
||||
DELAYBLACKLISTLOAD=No
|
||||
|
||||
# MODULE NAME SUFFIX
|
||||
#
|
||||
# When loading a module named in /etc/shorewall/modules, Shorewall normally
|
||||
# looks in the MODULES DIRECTORY (see MODULESDIR above) for files whose names
|
||||
# end in ".o", ".ko", ".gz", "o.gz" or "ko.gz" . If your distribution uses a
|
||||
# different naming convention then you can specify the suffix (extension) for
|
||||
# module names in this variable.
|
||||
#
|
||||
# To see what suffix is used by your distribution:
|
||||
#
|
||||
# ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter
|
||||
#
|
||||
# All of the file names listed should have the same suffix (extension). Set
|
||||
# MODULE_SUFFIX to that suffix.
|
||||
#
|
||||
# Examples:
|
||||
#
|
||||
# If all file names end with ".kzo" then set MODULE_SUFFIX="kzo"
|
||||
# If all file names end with ".kz.o" then set MODULE_SUFFIX="kz.o"
|
||||
#
|
||||
|
||||
MODULE_SUFFIX=
|
||||
|
||||
#
|
||||
# DISABLE IPV6
|
||||
#
|
||||
# Distributions (notably SUSE) are beginning to ship with IPV6
|
||||
# enabled. If you are not using IPV6, you are at risk of being
|
||||
# exploited by users who do. Setting DISABLE_IPV6=Yes will cause
|
||||
# Shorewall to disable IPV6 traffic to/from and through your
|
||||
# firewall system. This requires that you have ip6tables installed.
|
||||
|
||||
DISABLE_IPV6=Yes
|
||||
|
||||
#
|
||||
# BRIDGING
|
||||
#
|
||||
# If you wish to restrict connections through a bridge
|
||||
# (see http://bridge.sf.net), then set BRIDGING=Yes. Your kernel must have
|
||||
# the physdev match option enabled; that option is available at the above URL
|
||||
# for 2.4 kernels and is included as a standard part of the 2.6 series
|
||||
# kernels. If not specified or specified as empty (BRIDGING="") then "No" is
|
||||
# assumed.
|
||||
#
|
||||
|
||||
BRIDGING=No
|
||||
|
||||
#
|
||||
# DYNAMIC ZONES
|
||||
#
|
||||
# If you need to be able to add and delete hosts from zones dynamically then
|
||||
# set DYNAMIC_ZONES=Yes. Otherwise, set DYNAMIC_ZONES=No.
|
||||
|
||||
DYNAMIC_ZONES=No
|
||||
|
||||
#
|
||||
# USE PKTTYPE MATCH
|
||||
#
|
||||
# Some users have reported problems with the PKTTYPE match extension not being
|
||||
# able to match certain broadcast packets. If you set PKTTYPE=No then Shorewall
|
||||
# will use IP addresses to detect broadcasts rather than pkttype. If not given
|
||||
# or if given as empty (PKTTYPE="") then PKTTYPE=Yes is assumed.
|
||||
#
|
||||
|
||||
PKTTYPE=Yes
|
||||
|
||||
#
|
||||
# RFC 1918 BEHAVIOR
|
||||
#
|
||||
# Traditionally, the RETURN target in the 'rfc1918' file has caused 'norfc1918'
|
||||
# processing to cease for a packet if the packet's source IP address matches
|
||||
# the rule. Thus, if you have:
|
||||
#
|
||||
# SUBNETS TARGET
|
||||
# 192.168.1.0/24 RETURN
|
||||
#
|
||||
# then traffic from 192.168.1.4 to 10.0.3.9 will be accepted even though you
|
||||
# also have:
|
||||
#
|
||||
# SUBNETS TARGET
|
||||
# 10.0.0.0/8 logdrop
|
||||
#
|
||||
# Setting RFC1918_STRICT=Yes will cause such traffic to be logged and dropped
|
||||
# since while the packet's source matches the RETURN rule, the packet's
|
||||
# destination matches the 'logdrop' rule.
|
||||
#
|
||||
# If not specified or specified as empty (e.g., RFC1918_STRICT="") then
|
||||
# RFC1918_STRICT=No is assumed.
|
||||
#
|
||||
# WARNING: RFC1918_STRICT=Yes requires that your kernel and iptables support
|
||||
# 'conntrack state' match.
|
||||
#
|
||||
|
||||
RFC1918_STRICT=No
|
||||
|
||||
#
|
||||
# MAC List Table
|
||||
#
|
||||
# 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 with MACLIST_TABLE=mangle.
|
||||
|
||||
MACLIST_TABLE=filter
|
||||
|
||||
#
|
||||
# MACLIST caching
|
||||
#
|
||||
# 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
|
||||
# (/etc/shorewall/maclist).
|
||||
#
|
||||
# When a new connection arrives from a 'maclist' interface, the packet passes
|
||||
# through the list of entries for that interface in /etc/shorewall/maclist. 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 occuring
|
||||
# within $MACLIST_TTL seconds will be accepted without having to scan all of
|
||||
# the entries. After $MACLIST_TTL from the first accepted connection request,
|
||||
# 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.
|
||||
#
|
||||
|
||||
MACLIST_TTL=
|
||||
|
||||
#
|
||||
# Save/Restore IPSETS
|
||||
#
|
||||
# If SAVE_IPSETS=Yes then Shorewall will:
|
||||
#
|
||||
# Restore the last saved ipset contents during "shorewall [re]start"
|
||||
# Save the current ipset contents during "shorewall save"
|
||||
#
|
||||
# Regardless of the setting of SAVE_IPSETS, if ipset contents were
|
||||
# saved during a "shorewall save" then they will be restored during
|
||||
# a subsequent "shorewall restore".
|
||||
#
|
||||
|
||||
SAVE_IPSETS=No
|
||||
|
||||
#
|
||||
# Map Old Actions
|
||||
#
|
||||
# Previously, Shorewall included a large number of standard actions (AllowPing,
|
||||
# AllowFTP, ...). These have been replaced with parameterized macros. For
|
||||
# compatibility, Shorewall can map the old names into invocations of the new
|
||||
# macros if you set MAPOLDACTIONS=Yes. If this option is not set or is set to
|
||||
# the empty value (MAPOLDACTIONS="") then MAPOLDACTIONS=Yes is assumed
|
||||
#
|
||||
|
||||
MAPOLDACTIONS=No
|
||||
|
||||
#
|
||||
# Fast ESTABLISHED/RELATED handling
|
||||
#
|
||||
# Normally, Shorewall delays 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 'loc2net' chain.
|
||||
#
|
||||
# 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 and
|
||||
# RELATED sections of the rules file.
|
||||
|
||||
FASTACCEPT=No
|
||||
|
||||
#
|
||||
# Implicit CONTINUE policy for sub-zones
|
||||
#
|
||||
# When a zone is declared to be a subzone of one or more other zones, it
|
||||
# is typically the case that you want the rules for the parent zone(s) to
|
||||
# be applied to connections to/from the subzone that don't match any
|
||||
# subzone specific rules. That way, you don't have to duplicate the parent
|
||||
# zone's rules in order for them to also apply to the subzone(s). That is
|
||||
# the behavior with IMPLICIT_CONTINUE=Yes. If you don't want that behavior
|
||||
# and want the policies for the sub-zone to be determined by the standard
|
||||
# policy processing, set IMPLICIT_CONTINUE=No or IMPLICIT_CONTINUE=.
|
||||
#
|
||||
# Note that even with IMPLICIT_CONTINUE=Yes, you can override the implicit
|
||||
# CONTINUE policy by adding an explicit policy (one that does not contain
|
||||
# "all" in either the SOURCE or DEST columns).
|
||||
|
||||
IMPLICIT_CONTINUE=Yes
|
||||
|
||||
#
|
||||
# Use high mark values for policy routing
|
||||
#
|
||||
# Normally, Shorewall restricts the set of mark values to 1-255. If you set
|
||||
# HIGH_ROUTE_MARKS=Yes, Shorewall will rather restrict the set of routing
|
||||
# mark values (those specified in the /etc/shorewall/providers file) to
|
||||
# a multiple of 256 (256 to 65280) or their hexadecimal equivalents
|
||||
# (0x0100 to 0xff00, with the low-order byte of the value being zero).
|
||||
# This allows connection marks to be shared between traffic shaping and
|
||||
# policy routing. Traffic shaping marks are always restricted to 1-255.
|
||||
#
|
||||
# Setting HIGH_ROUTE_MARKS=Yes requires that your kernel and iptables support
|
||||
# both the extended CONNMARK target and the extended connmark match
|
||||
# capabilities (see the output of "shorewall show capabilities").
|
||||
|
||||
HIGH_ROUTE_MARKS=No
|
||||
|
||||
#
|
||||
# Use Actions
|
||||
#
|
||||
# While Shorewall Actions can be very useful, they also require a sizable
|
||||
# amount of code to implement. By setting USE_ACTIONS=No, you can omit
|
||||
# /usr/share/shorewall/lib/actions from your configuration.
|
||||
|
||||
USE_ACTIONS=Yes
|
||||
|
||||
#
|
||||
# Optimize Ruleset
|
||||
#
|
||||
# Traditionally, Shorewall has created rules for the complete matrix of
|
||||
# Networks 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 changes. When the matrix is sparse, this results in lots of
|
||||
# largely useless rules.
|
||||
#
|
||||
# These extra rules can be eliminated by setting OPTIMIZE=1 and included
|
||||
# by setting OPTIMIZE=0
|
||||
#
|
||||
|
||||
OPTIMIZE=1
|
||||
|
||||
###############################################################################
|
||||
# P A C K E T D I S P O S I T I O N
|
||||
###############################################################################
|
||||
#
|
||||
# BLACKLIST DISPOSITION
|
||||
#
|
||||
# Set this variable to the action that you want to perform on packets from
|
||||
# Blacklisted systems. Must be DROP or REJECT. If not set or set to empty,
|
||||
# DROP is assumed.
|
||||
#
|
||||
|
||||
BLACKLIST_DISPOSITION=DROP
|
||||
|
||||
#
|
||||
# MAC List Disposition
|
||||
#
|
||||
# This variable determines the disposition of connection requests arriving
|
||||
# on interfaces that have the 'maclist' option and that are from a device
|
||||
# that is not listed for that interface in /etc/shorewall/maclist. Valid
|
||||
# values are ACCEPT, DROP and REJECT. If not specified or specified as
|
||||
# empty (MACLIST_DISPOSITION="") then REJECT is assumed
|
||||
#
|
||||
|
||||
MACLIST_DISPOSITION=REJECT
|
||||
|
||||
#
|
||||
# TCP FLAGS Disposition
|
||||
#
|
||||
# This variable determins the disposition of packets having an invalid
|
||||
# combination of TCP flags that are received on interfaces having the
|
||||
# 'tcpflags' option specified in /etc/shorewall/interfaces or in
|
||||
# /etc/shorewall/hosts. If not specified or specified as empty
|
||||
# (TCP_FLAGS_DISPOSITION="") then DROP is assumed.
|
||||
#
|
||||
|
||||
TCP_FLAGS_DISPOSITION=DROP
|
||||
|
||||
#LAST LINE -- DO NOT REMOVE
|
||||
|
||||
@ -9,388 +9,74 @@
|
||||
# version 2.1 of the License, or (at your option) any later version.
|
||||
#
|
||||
# See the file README.txt for further details.
|
||||
#
|
||||
# For information about the settings in this file, type "man shorewall.conf"
|
||||
#
|
||||
# Additional information is available at
|
||||
# http://www.shorewall.net/Documentation.htm#Conf
|
||||
###############################################################################
|
||||
# S T A R T U P E N A B L E D
|
||||
###############################################################################
|
||||
#
|
||||
# Once you have configured Shorewall, you may change the setting of
|
||||
# this variable to 'Yes'
|
||||
#
|
||||
|
||||
STARTUP_ENABLED=No
|
||||
|
||||
###############################################################################
|
||||
# V E R B O S I T Y
|
||||
###############################################################################
|
||||
#
|
||||
# Shorewall has traditionally been very noisy. You may now set the default
|
||||
# level of verbosity here.
|
||||
#
|
||||
# Values are:
|
||||
#
|
||||
# 0 -- Silent. You may make it more verbose using the -v option
|
||||
# 1 -- Major progress messages displayed
|
||||
# 2 -- All progress messages displayed (old default behavior)
|
||||
#
|
||||
# If not specified, then 2 is assumed
|
||||
|
||||
VERBOSITY=1
|
||||
|
||||
###############################################################################
|
||||
# L O G G I N G
|
||||
###############################################################################
|
||||
#
|
||||
# General note about log levels. 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 specifify. 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 target support, you may also
|
||||
# specify a log level of ULOG (must be all caps). Rather than log its
|
||||
# messages to syslogd, Shorewall will direct netfilter to log the messages
|
||||
# via the ULOG 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). Ulogd is also available from
|
||||
# http://www.gnumonks.org/projects/ulogd and can be configured to log all
|
||||
# Shorewall message to their own log file
|
||||
###############################################################################
|
||||
#
|
||||
# LOG FILE LOCATION
|
||||
#
|
||||
# This variable tells the /sbin/shorewall program where to look for Shorewall
|
||||
# log messages. If not set or set to an empty string (e.g., LOGFILE="") then
|
||||
# /var/log/messages is assumed.
|
||||
#
|
||||
# WARNING: The LOGFILE variable simply tells the 'shorewall' program where to
|
||||
# look for Shorewall messages.It does NOT control the destination for
|
||||
# these messages. For information about how to do that, see
|
||||
#
|
||||
# http://www.shorewall.net/shorewall_logging.html
|
||||
#
|
||||
|
||||
LOGFILE=/var/log/messages
|
||||
|
||||
#
|
||||
# LOG FORMAT
|
||||
#
|
||||
# Shell 'printf' Formatting template for the --log-prefix value in log messages
|
||||
# generated by Shorewall to identify Shorewall log messages. The supplied
|
||||
# template is expected to accept either two or three arguments; the first is
|
||||
# the chain name, the second (optional) is the logging rule number within that
|
||||
# chain and the third is the ACTION specifying the disposition of the packet
|
||||
# being logged. You must use the %d formatting type for the rule number; if
|
||||
# your template does not contain %d then the rule number will not be included.
|
||||
#
|
||||
# If you want to integrate Shorewall with fireparse, then set LOGFORMAT as:
|
||||
#
|
||||
# LOGFORMAT="fp=%s:%d a=%s "
|
||||
#
|
||||
# If not specified or specified as empty (LOGFORMAT="") then the value
|
||||
# "Shorewall:%s:%s:" is assumed.
|
||||
#
|
||||
# Beginning with Shorewall 3.3.3, The contents of LOGFORMAT determine the
|
||||
# maximum length of a Shorewall zone name. LOGFORMAT must produce a string no
|
||||
# longer than 29 bytes when passed the chain name, [rule number], and 'ACCEPT'.
|
||||
# Using the default LOGFORMAT, the name of a chain must be 11 characters or
|
||||
# less; since chain names are often of the form <zone1>2<zone2>, zone names are
|
||||
# limited to 5 characters using the default LOGFORMAT. In contrast, if
|
||||
# LOGFORMAT="FW:%s:%s:", then zone names can be as long as 8 characters.
|
||||
|
||||
LOGFORMAT="Shorewall:%s:%s:"
|
||||
|
||||
#
|
||||
# LOG FORMAT Continued
|
||||
#
|
||||
# Using the default LOGFORMAT, chain names may not exceed 11 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.
|
||||
#
|
||||
|
||||
LOGTAGONLY=No
|
||||
|
||||
#
|
||||
# LOG RATE LIMITING
|
||||
#
|
||||
# The next two variables can be used to control the amount of log output
|
||||
# generated. LOGRATE is expressed as a number followed by an optional
|
||||
# `/second', `/minute', `/hour', or `/day' suffix and specifies the maximum
|
||||
# rate at which a particular message will occur. LOGBURST determines the
|
||||
# maximum initial burst size that will be logged. If set empty, the default
|
||||
# value of 5 will be used.
|
||||
#
|
||||
# If BOTH variables are set empty then logging will not be rate-limited.
|
||||
#
|
||||
# Example:
|
||||
#
|
||||
# LOGRATE=10/minute
|
||||
# LOGBURST=5
|
||||
#
|
||||
# For each logging rule, the first time the rule is reached, the packet
|
||||
# will be logged; in fact, since the burst is 5, the first five packets
|
||||
# will be logged. After this, it will be 6 seconds (1 minute divided by
|
||||
# the rate of 10) before a message will be logged from the rule, regardless
|
||||
# of how many packets reach it. Also, every 6 seconds which passes without
|
||||
# matching a packet, one of the bursts will be regained; if no packets hit
|
||||
# the rule for 30 seconds, the burst will be fully recharged; back where
|
||||
# we started.
|
||||
#
|
||||
|
||||
LOGRATE=
|
||||
LOGBURST=
|
||||
|
||||
#
|
||||
# LOG ALL NEW
|
||||
#
|
||||
# This option should only be used when you are trying to analyze a problem.
|
||||
# It causes all packets in the Netfilter NEW state to be logged as the
|
||||
# first rule in each builtin chain. To use this option, set LOGALLNEW to
|
||||
# the log level that you want these packets logged at (e.g.,
|
||||
# LOGALLNEW=debug).
|
||||
#
|
||||
LOGBURST=
|
||||
|
||||
LOGALLNEW=
|
||||
|
||||
#
|
||||
# BLACKLIST LOG LEVEL
|
||||
#
|
||||
# Set this variable to the syslogd level that you want blacklist packets logged
|
||||
# (beware of DOS attacks resulting from such logging). If not set, no logging
|
||||
# of blacklist packets occurs.
|
||||
#
|
||||
# See the comment at the top of this section for a description of log levels
|
||||
#
|
||||
|
||||
BLACKLIST_LOGLEVEL=
|
||||
|
||||
#
|
||||
# MAC List Log Level
|
||||
#
|
||||
# Specifies the logging level for connection requests that fail MAC
|
||||
# verification. If set to the empty value (MACLIST_LOG_LEVEL="") then
|
||||
# such connection requests will not be logged.
|
||||
#
|
||||
# See the comment at the top of this section for a description of log levels
|
||||
#
|
||||
# If you wish to filter messages logged under this option, then supply
|
||||
# the /etc/shorewall/maclog extension script (you will have to create the
|
||||
# file yourself). That script will be copied into the compiled firewall
|
||||
# script at a point just before logging occurs. The shell variable CHAIN
|
||||
# will be set to the name of the chain where the logging rule will be
|
||||
# inserted.
|
||||
#
|
||||
# If you set MACLIST_TABLE=mangle later in this file, be sure that your
|
||||
# 'run_iptables' commands include '-t mangle'.
|
||||
#
|
||||
# See http://www.shorewall.net/shorewall_extension_scripts.htm for more
|
||||
# information about extension scripts.
|
||||
#
|
||||
|
||||
MACLIST_LOG_LEVEL=info
|
||||
|
||||
#
|
||||
# TCP FLAGS Log Level
|
||||
#
|
||||
# Specifies the logging level for packets that fail TCP Flags
|
||||
# verification. If set to the empty value (TCP_FLAGS_LOG_LEVEL="") then
|
||||
# such packets will not be logged.
|
||||
#
|
||||
# See the comment at the top of this section for a description of log levels
|
||||
#
|
||||
|
||||
TCP_FLAGS_LOG_LEVEL=info
|
||||
|
||||
#
|
||||
# RFC1918 Log Level
|
||||
#
|
||||
# Specifies the logging level for packets that fail RFC 1918
|
||||
# verification. If set to the empty value (RFC1918_LOG_LEVEL="") then
|
||||
# RFC1918_LOG_LEVEL=info is assumed.
|
||||
#
|
||||
# See the comment at the top of this section for a description of log levels
|
||||
#
|
||||
|
||||
RFC1918_LOG_LEVEL=info
|
||||
|
||||
#
|
||||
# SMURF Log Level
|
||||
#
|
||||
# Specifies the logging level for smurf packets dropped by the
|
||||
#'nosmurfs' interface option in /etc/shorewall/interfaces and in
|
||||
# /etc/shorewall/hosts. If set to the empty value ( SMURF_LOG_LEVEL=""
|
||||
# ) then dropped smurfs are not logged.
|
||||
#
|
||||
# See the comment at the top of this section for a description of log levels
|
||||
#
|
||||
|
||||
SMURF_LOG_LEVEL=info
|
||||
|
||||
#
|
||||
# MARTIAN LOGGING
|
||||
#
|
||||
# Setting LOG_MARTIANS=Yes will enable kernel logging of all received packets
|
||||
# that have impossible source IP addresses. This logging may be enabled
|
||||
# on individual interfaces by using the 'logmartians' option in
|
||||
# /etc/shorewall/interfaces.
|
||||
#
|
||||
|
||||
LOG_MARTIANS=No
|
||||
|
||||
###############################################################################
|
||||
# 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
|
||||
###############################################################################
|
||||
#
|
||||
# IPTABLES
|
||||
#
|
||||
# Full path to iptables executable Shorewall uses to build the firewall. If
|
||||
# not specified or if specified with an empty value (e.g., IPTABLES="") then
|
||||
# the iptables executable located via the PATH setting below is used.
|
||||
#
|
||||
|
||||
IPTABLES=
|
||||
|
||||
#
|
||||
# PATH - Change this if you want to change the order in which Shorewall
|
||||
# searches directories for executable files.
|
||||
#
|
||||
|
||||
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
|
||||
|
||||
#
|
||||
# SHELL
|
||||
#
|
||||
# The firewall script is normally interpreted by /bin/sh. If you wish to change
|
||||
# the shell used to interpret that script, specify the shell here.
|
||||
#
|
||||
|
||||
SHOREWALL_SHELL=/bin/sh
|
||||
|
||||
# SUBSYSTEM LOCK FILE
|
||||
#
|
||||
# Set this to the name of the lock file expected by your init scripts. For
|
||||
# RedHat, this should be /var/lock/subsys/shorewall. If your init scripts don't
|
||||
# use lock files, set this to "".
|
||||
#
|
||||
|
||||
SUBSYSLOCK=/var/lock/subsys/shorewall
|
||||
|
||||
#
|
||||
# KERNEL MODULE DIRECTORY
|
||||
#
|
||||
# If your netfilter kernel modules are in a directory other than
|
||||
# /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter then specify that
|
||||
# directory in this variable. Example: MODULESDIR=/etc/modules.
|
||||
#
|
||||
|
||||
MODULESDIR=
|
||||
|
||||
#
|
||||
# CONFIGURATION SEARCH PATH
|
||||
#
|
||||
# This option holds a list of directory names separated by colons
|
||||
# (":"). Shorewall will search each directory in turn when looking for a
|
||||
# configuration file. When processing a 'try' command or a command
|
||||
# containing the "-c" option or that specifies a configuration directory,
|
||||
# Shorewall will automatically add the directory specified in the command
|
||||
# to the front of this list.
|
||||
#
|
||||
# If not specified or specified as null ("CONFIG_PATH=""),
|
||||
# the default is distribution-defined. See the output of "shorewall show
|
||||
# config" to find the default value on your distribution.
|
||||
#
|
||||
|
||||
CONFIG_PATH=/etc/shorewall:/usr/share/shorewall
|
||||
|
||||
#
|
||||
# RESTORE SCRIPT
|
||||
#
|
||||
# This option determines the script to be run in the following cases:
|
||||
#
|
||||
# shorewall -f start
|
||||
# shorewall restore
|
||||
# shorewall save
|
||||
# shorewall forget
|
||||
# Failure of shorewall start or shorewall restart
|
||||
#
|
||||
# The value of the option must be the name of an executable file in the
|
||||
# directory /var/lib/shorewall. If this option is not set or if it is
|
||||
# set to the empty value (RESTOREFILE="") then RESTOREFILE=restore is
|
||||
# assumed.
|
||||
#
|
||||
|
||||
RESTOREFILE=
|
||||
|
||||
#
|
||||
# OLD ZONE FILE FORMAT
|
||||
#
|
||||
# Previous versions of Shorewall had both a 'zones' file and an 'ipsec' file.
|
||||
# Beginning with 2.5.0, those files were combined. For users who haven't
|
||||
# converted, we offer this variable that sets the name of the file for ipsec
|
||||
# information. This option must take the value "zones" or "ipsec". If the
|
||||
# option is not set or is set to the empty value (IPSECFILE="") then "ipsec"
|
||||
# is assumed.
|
||||
#
|
||||
|
||||
IPSECFILE=zones
|
||||
|
||||
###############################################################################
|
||||
# D E F A U L T A C T I O N S / M A C R O S
|
||||
###############################################################################
|
||||
#
|
||||
# In earlier Shorewall versions, a "default action" for DROP and REJECT
|
||||
# policies was specified in the file /usr/share/shorewall/actions.std.
|
||||
#
|
||||
# To allow for default rules to be applied when USE_ACTIONS=No, the
|
||||
# DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT and QUEUE_DEFAULT options have
|
||||
# been 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 two are
|
||||
# similar for ACCEPT and QUEUE policies.
|
||||
#
|
||||
# The value applied to these may be:
|
||||
#
|
||||
# a) The name of an action.
|
||||
# b) The name of a macro
|
||||
# c) 'None' or 'none'
|
||||
#
|
||||
# The default values are:
|
||||
#
|
||||
# DROP_DEFAULT="Drop"
|
||||
# REJECT_DEFAULT="Reject"
|
||||
# ACCEPT_DEFAULT="none"
|
||||
# QUEUE_DEFAULT="none"
|
||||
#
|
||||
# If USE_ACTIONS=Yes, then these values refer to action.Drop and action.Reject
|
||||
# respectively. If USE_ACTIONS=No, then these values refer to macro.Drop and
|
||||
# macro.Reject.
|
||||
#
|
||||
# If you set the value of either option to "None" then no default action
|
||||
# will be used and the default action or macro must be specified in
|
||||
# /etc/shorewall/policy
|
||||
|
||||
DROP_DEFAULT="Drop"
|
||||
REJECT_DEFAULT="Reject"
|
||||
@ -400,570 +86,75 @@ QUEUE_DEFAULT="none"
|
||||
###############################################################################
|
||||
# F I R E W A L L O P T I O N S
|
||||
###############################################################################
|
||||
#
|
||||
# WARNING: THE 'FW' OPTION HAS BEEN REMOVED FROM THIS FILE -- The firewall
|
||||
# zone is now declared in /etc/shorewall/zones.
|
||||
#
|
||||
|
||||
#
|
||||
# ENABLE IP FORWARDING
|
||||
#
|
||||
# If you say "On" or "on" here, IPV4 Packet Forwarding is enabled. If you
|
||||
# say "Off" or "off", packet forwarding will be disabled. You would only want
|
||||
# to disable packet forwarding if you are installing Shorewall on a
|
||||
# standalone system or if you want all traffic through the Shorewall system
|
||||
# to be handled by proxies.
|
||||
#
|
||||
# If you set this variable to "Keep" or "keep", Shorewall will neither
|
||||
# enable nor disable packet forwarding.
|
||||
#
|
||||
|
||||
IP_FORWARDING=On
|
||||
|
||||
#
|
||||
# AUTOMATICALLY ADD NAT IP ADDRESSES
|
||||
#
|
||||
# If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses
|
||||
# for each NAT external address that you give in /etc/shorewall/nat. If you say
|
||||
# "No" or "no", you must add these aliases youself.
|
||||
#
|
||||
# WARNING: Addresses added by ADD_IP_ALIASES=Yes are deleted and re-added
|
||||
# during processing of the "shorewall restart" command. As a consequence,
|
||||
# connections using those addresses may be severed.
|
||||
#
|
||||
|
||||
ADD_IP_ALIASES=Yes
|
||||
|
||||
#
|
||||
# AUTOMATICALLY ADD SNAT IP ADDRESSES
|
||||
#
|
||||
# If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses
|
||||
# for each SNAT external address that you give in /etc/shorewall/masq. If you
|
||||
# say "No" or "no", you must add these aliases youself. LEAVE THIS SET TO "No"
|
||||
# unless you are sure that you need it -- most people don't!!!
|
||||
#
|
||||
# WARNING: Addresses added by ADD_SNAT_ALIASES=Yes are deleted and re-added
|
||||
# during processing of the "shorewall restart" command. As a consequence,
|
||||
# connections using those addresses may be severed.
|
||||
#
|
||||
|
||||
ADD_SNAT_ALIASES=No
|
||||
|
||||
#
|
||||
# RETAIN EXISTING ALIASES/IP ADDRESSES
|
||||
#
|
||||
# Normally, when ADD_IP_ALIASES=Yes and/or ADD_SNAT_ALIASES=Yes then Shorewall
|
||||
# will first delete the address then re-add it. This is to ensure that the
|
||||
# address is added with the specified label. Unfortunately, this can cause
|
||||
# problems if it results in the deletion of the last IP address on an
|
||||
# interface because then all routes through the interface are automatically
|
||||
# removed.
|
||||
#
|
||||
# You can cause Shorewall to retain existing addresses by setting
|
||||
# RETAIN_ALIASES=Yes.
|
||||
#
|
||||
|
||||
RETAIN_ALIASES=No
|
||||
|
||||
#
|
||||
# ENABLE TRAFFIC SHAPING
|
||||
#
|
||||
# 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=Internal or internal or leave the option empty then
|
||||
# Shorewall will use its builtin traffic shaper (tc4shorewall written by
|
||||
# Arne Bernin).
|
||||
#
|
||||
# See http://shorewall.net/traffic_shaping.htm for more information.
|
||||
|
||||
TC_ENABLED=Internal
|
||||
|
||||
#
|
||||
# TRAFFIC SHAPING EXPERT
|
||||
#
|
||||
# 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 /etc/shorewall/providers.
|
||||
#
|
||||
# If you know what you are doing, you can set TC_EXPERT=Yes and Shorewall
|
||||
# will not include these cautionary checks.
|
||||
|
||||
TC_EXPERT=No
|
||||
|
||||
#
|
||||
# Clear Traffic Shaping/Control
|
||||
#
|
||||
# If this option is set to 'No' then Shorewall won't clear the current
|
||||
# traffic control rules during [re]start. This setting is intended
|
||||
# for use by people that 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=No 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 /etc/shorewall/tcrules.
|
||||
#
|
||||
# If omitted, CLEAR_TC=Yes is assumed.
|
||||
#
|
||||
|
||||
CLEAR_TC=Yes
|
||||
|
||||
#
|
||||
# Mark Packets in the forward chain
|
||||
#
|
||||
# When processing the tcrules file, Shorewall normally marks packets in the
|
||||
# PREROUTING chain. To cause Shorewall to use the FORWARD chain instead, set
|
||||
# this to "Yes". If not specified or if set to the empty value (e.g.,
|
||||
# MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed.
|
||||
#
|
||||
# Marking packets in the FORWARD chain has the advantage that inbound
|
||||
# packets destined for Masqueraded/SNATed local hosts have had their
|
||||
# destination address rewritten so they can be marked based on their
|
||||
# destination. When packets are marked in the PREROUTING chain, packets
|
||||
# destined for Masqueraded/SNATed local hosts still have a destination address
|
||||
# corresponding to the firewall's external interface.
|
||||
#
|
||||
# Note: Older kernels do not support marking packets in the FORWARD chain and
|
||||
# setting this variable to Yes may cause startup problems.
|
||||
#
|
||||
|
||||
MARK_IN_FORWARD_CHAIN=No
|
||||
|
||||
#
|
||||
# MSS CLAMPING
|
||||
#
|
||||
# Set this variable to "Yes" or "yes" if you want the TCP "Clamp MSS to PMTU"
|
||||
# option. This option is most commonly required when your internet
|
||||
# interface is some variant of PPP (PPTP or PPPoE). Your kernel must
|
||||
# have CONFIG_IP_NF_TARGET_TCPMSS set.
|
||||
#
|
||||
# [From the kernel help:
|
||||
#
|
||||
# This option adds a `TCPMSS' target, which allows you to alter the
|
||||
# MSS value of TCP SYN packets, to control the maximum size for that
|
||||
# connection (usually limiting it to your outgoing interface's MTU
|
||||
# minus 40).
|
||||
#
|
||||
# This is used to overcome criminally braindead ISPs or servers which
|
||||
# block ICMP Fragmentation Needed packets. The symptoms of this
|
||||
# problem are that everything works fine from your Linux
|
||||
# firewall/router, but machines behind it can never exchange large
|
||||
# packets:
|
||||
# 1) Web browsers connect, then hang with no data received.
|
||||
# 2) Small mail works fine, but large emails hang.
|
||||
# 3) ssh works fine, but scp hangs after initial handshaking.
|
||||
# ]
|
||||
#
|
||||
# If left blank, or set to "No" or "no", the option is not enabled.
|
||||
#
|
||||
# You may also set this option to a numeric value in which case Shorewall will
|
||||
# set up a rule to modify the MSS value in SYN packets to the value that
|
||||
# you specify.
|
||||
#
|
||||
# Example:
|
||||
#
|
||||
# CLAMPMSS=1400
|
||||
#
|
||||
|
||||
CLAMPMSS=No
|
||||
|
||||
#
|
||||
# ROUTE FILTERING
|
||||
#
|
||||
# Set this variable to "Yes" or "yes" if you want kernel route filtering on all
|
||||
# interfaces started while Shorewall is started (anti-spoofing measure).
|
||||
#
|
||||
# If this variable is not set or is set to the empty value, "No" is assumed.
|
||||
# Regardless of the setting of ROUTE_FILTER, you can still enable route
|
||||
# filtering on individual interfaces using the 'routefilter' option in the
|
||||
# /etc/shorewall/interfaces file.
|
||||
#
|
||||
|
||||
ROUTE_FILTER=No
|
||||
|
||||
#
|
||||
# DNAT IP ADDRESS DETECTION
|
||||
#
|
||||
# Normally when Shorewall encounters the following rule:
|
||||
#
|
||||
# DNAT net loc:192.168.1.3 tcp 80
|
||||
#
|
||||
# it will forward TCP port 80 connections from the net to 192.168.1.3
|
||||
# REGARDLESS OF THE ORIGINAL DESTINATION ADDRESS. This behavior is
|
||||
# convenient for two reasons:
|
||||
#
|
||||
# a) If the the network interface has a dynamic IP address, the
|
||||
# firewall configuration will work even when the address
|
||||
# changes.
|
||||
#
|
||||
# b) It saves having to configure the IP address in the rule
|
||||
# while still allowing the firewall to be started before the
|
||||
# internet interface is brought up.
|
||||
#
|
||||
# This default behavior can also have a negative effect. If the
|
||||
# internet interface has more than one IP address then the above
|
||||
# rule will forward connection requests on all of these addresses;
|
||||
# that may not be what is desired.
|
||||
#
|
||||
# By setting DETECT_DNAT_IPADDRS=Yes, rules such as the above will apply
|
||||
# only if the original destination address is the primary IP address of
|
||||
# one of the interfaces associated with the source zone. Note that this
|
||||
# requires all interfaces to the source zone to be up when the firewall
|
||||
# is [re]started.
|
||||
#
|
||||
|
||||
DETECT_DNAT_IPADDRS=No
|
||||
|
||||
#
|
||||
# MUTEX TIMEOUT
|
||||
#
|
||||
# The value of this variable determines the number of seconds that programs
|
||||
# will wait for exclusive access to the Shorewall 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 restart" command.
|
||||
#
|
||||
|
||||
MUTEX_TIMEOUT=60
|
||||
|
||||
#
|
||||
# FOR ADMINS THAT REPEATEDLY SHOOT THEMSELVES IN THE FOOT
|
||||
#
|
||||
# Normally, when a "shorewall stop" command is issued or an error occurs during
|
||||
# the execution of another shorewall command, Shorewall puts the firewall into
|
||||
# a state where only traffic to/from the hosts listed in
|
||||
# /etc/shorewall/routestopped is accepted.
|
||||
#
|
||||
# When performing remote administration on a Shorewall firewall, it is
|
||||
# therefore recommended that the IP address of the computer being used for
|
||||
# administration be added to the firewall's /etc/shorewall/routestopped file.
|
||||
#
|
||||
# Some administrators have a hard time remembering to do this with the result
|
||||
# that they get to drive across town in the middle of the night to restart
|
||||
# a remote firewall (or worse, they have to get someone out of bed to drive
|
||||
# across town to restart a very remote firewall).
|
||||
#
|
||||
# For those administrators, we offer ADMINISABSENTMINDED=Yes. With this
|
||||
# setting, when the firewall enters the 'stopped' state:
|
||||
#
|
||||
# All traffic that is part of or related to established connections is still
|
||||
# allowed and all OUTPUT traffic is allowed. This is in addition to traffic
|
||||
# to and from hosts listed in /etc/shorewall/routestopped.
|
||||
#
|
||||
# If this variable is not set or it is set to the null value then
|
||||
# ADMINISABSENTMINDED=No is assumed.
|
||||
#
|
||||
|
||||
ADMINISABSENTMINDED=Yes
|
||||
|
||||
#
|
||||
# BLACKLIST Behavior
|
||||
#
|
||||
# Shorewall offers two types of blacklisting:
|
||||
#
|
||||
# - static blacklisting through the /etc/shorewall/blacklist file
|
||||
# together with the 'blacklist' interface option.
|
||||
# - dynamic blacklisting using the 'drop', 'reject' and 'allow' commands.
|
||||
#
|
||||
# The following variable determines whether the blacklist is checked for each
|
||||
# packet or for each new connection.
|
||||
#
|
||||
# BLACKLISTNEWONLY=Yes Only consult blacklists for new connection
|
||||
# requests
|
||||
#
|
||||
# BLACKLISTNEWONLY=No Consult blacklists for all packets.
|
||||
#
|
||||
# If the BLACKLISTNEWONLY option is not set or is set to the empty value then
|
||||
# BLACKLISTNEWONLY=No is assumed.
|
||||
#
|
||||
|
||||
BLACKLISTNEWONLY=Yes
|
||||
|
||||
#
|
||||
# Users with a large blacklist find that "shorwall [re]start" takes a long
|
||||
# time and that new connections are disabled during that time. By setting
|
||||
# DELAYBLACKLISTLOAD=Yes, you can cause Shorewall to enable new connections
|
||||
# before loading the blacklist.
|
||||
#
|
||||
|
||||
DELAYBLACKLISTLOAD=No
|
||||
|
||||
# MODULE NAME SUFFIX
|
||||
#
|
||||
# When loading a module named in /etc/shorewall/modules, Shorewall normally
|
||||
# looks in the MODULES DIRECTORY (see MODULESDIR above) for files whose names
|
||||
# end in ".o", ".ko", ".gz", "o.gz" or "ko.gz" . If your distribution uses a
|
||||
# different naming convention then you can specify the suffix (extension) for
|
||||
# module names in this variable.
|
||||
#
|
||||
# To see what suffix is used by your distribution:
|
||||
#
|
||||
# ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter
|
||||
#
|
||||
# All of the file names listed should have the same suffix (extension). Set
|
||||
# MODULE_SUFFIX to that suffix.
|
||||
#
|
||||
# Examples:
|
||||
#
|
||||
# If all file names end with ".kzo" then set MODULE_SUFFIX="kzo"
|
||||
# If all file names end with ".kz.o" then set MODULE_SUFFIX="kz.o"
|
||||
#
|
||||
|
||||
MODULE_SUFFIX=
|
||||
|
||||
#
|
||||
# DISABLE IPV6
|
||||
#
|
||||
# Distributions (notably SUSE) are beginning to ship with IPV6
|
||||
# enabled. If you are not using IPV6, you are at risk of being
|
||||
# exploited by users who do. Setting DISABLE_IPV6=Yes will cause
|
||||
# Shorewall to disable IPV6 traffic to/from and through your
|
||||
# firewall system. This requires that you have ip6tables installed.
|
||||
|
||||
DISABLE_IPV6=Yes
|
||||
|
||||
#
|
||||
# BRIDGING
|
||||
#
|
||||
# If you wish to restrict connections through a bridge
|
||||
# (see http://bridge.sf.net), then set BRIDGING=Yes. Your kernel must have
|
||||
# the physdev match option enabled; that option is available at the above URL
|
||||
# for 2.4 kernels and is included as a standard part of the 2.6 series
|
||||
# kernels. If not specified or specified as empty (BRIDGING="") then "No" is
|
||||
# assumed.
|
||||
#
|
||||
|
||||
BRIDGING=No
|
||||
|
||||
#
|
||||
# DYNAMIC ZONES
|
||||
#
|
||||
# If you need to be able to add and delete hosts from zones dynamically then
|
||||
# set DYNAMIC_ZONES=Yes. Otherwise, set DYNAMIC_ZONES=No.
|
||||
|
||||
DYNAMIC_ZONES=No
|
||||
|
||||
#
|
||||
# USE PKTTYPE MATCH
|
||||
#
|
||||
# Some users have reported problems with the PKTTYPE match extension not being
|
||||
# able to match certain broadcast packets. If you set PKTTYPE=No then Shorewall
|
||||
# will use IP addresses to detect broadcasts rather than pkttype. If not given
|
||||
# or if given as empty (PKTTYPE="") then PKTTYPE=Yes is assumed.
|
||||
#
|
||||
|
||||
PKTTYPE=Yes
|
||||
|
||||
#
|
||||
# RFC 1918 BEHAVIOR
|
||||
#
|
||||
# Traditionally, the RETURN target in the 'rfc1918' file has caused 'norfc1918'
|
||||
# processing to cease for a packet if the packet's source IP address matches
|
||||
# the rule. Thus, if you have:
|
||||
#
|
||||
# SUBNETS TARGET
|
||||
# 192.168.1.0/24 RETURN
|
||||
#
|
||||
# then traffic from 192.168.1.4 to 10.0.3.9 will be accepted even though you
|
||||
# also have:
|
||||
#
|
||||
# SUBNETS TARGET
|
||||
# 10.0.0.0/8 logdrop
|
||||
#
|
||||
# Setting RFC1918_STRICT=Yes will cause such traffic to be logged and dropped
|
||||
# since while the packet's source matches the RETURN rule, the packet's
|
||||
# destination matches the 'logdrop' rule.
|
||||
#
|
||||
# If not specified or specified as empty (e.g., RFC1918_STRICT="") then
|
||||
# RFC1918_STRICT=No is assumed.
|
||||
#
|
||||
# WARNING: RFC1918_STRICT=Yes requires that your kernel and iptables support
|
||||
# 'conntrack state' match.
|
||||
#
|
||||
|
||||
RFC1918_STRICT=No
|
||||
|
||||
#
|
||||
# MAC List Table
|
||||
#
|
||||
# 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 with MACLIST_TABLE=mangle.
|
||||
|
||||
MACLIST_TABLE=filter
|
||||
|
||||
#
|
||||
# MACLIST caching
|
||||
#
|
||||
# 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
|
||||
# (/etc/shorewall/maclist).
|
||||
#
|
||||
# When a new connection arrives from a 'maclist' interface, the packet passes
|
||||
# through the list of entries for that interface in /etc/shorewall/maclist. 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 occuring
|
||||
# within $MACLIST_TTL seconds will be accepted without having to scan all of
|
||||
# the entries. After $MACLIST_TTL from the first accepted connection request,
|
||||
# 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.
|
||||
#
|
||||
|
||||
MACLIST_TTL=
|
||||
|
||||
#
|
||||
# Save/Restore IPSETS
|
||||
#
|
||||
# If SAVE_IPSETS=Yes then Shorewall will:
|
||||
#
|
||||
# Restore the last saved ipset contents during "shorewall [re]start"
|
||||
# Save the current ipset contents during "shorewall save"
|
||||
#
|
||||
# Regardless of the setting of SAVE_IPSETS, if ipset contents were
|
||||
# saved during a "shorewall save" then they will be restored during
|
||||
# a subsequent "shorewall restore".
|
||||
#
|
||||
|
||||
SAVE_IPSETS=No
|
||||
|
||||
#
|
||||
# Map Old Actions
|
||||
#
|
||||
# Previously, Shorewall included a large number of standard actions (AllowPing,
|
||||
# AllowFTP, ...). These have been replaced with parameterized macros. For
|
||||
# compatibility, Shorewall can map the old names into invocations of the new
|
||||
# macros if you set MAPOLDACTIONS=Yes. If this option is not set or is set to
|
||||
# the empty value (MAPOLDACTIONS="") then MAPOLDACTIONS=Yes is assumed
|
||||
#
|
||||
|
||||
MAPOLDACTIONS=No
|
||||
|
||||
#
|
||||
# Fast ESTABLISHED/RELATED handling
|
||||
#
|
||||
# Normally, Shorewall delays 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 'loc2net' chain.
|
||||
#
|
||||
# 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 and
|
||||
# RELATED sections of the rules file.
|
||||
|
||||
FASTACCEPT=No
|
||||
|
||||
#
|
||||
# Implicit CONTINUE policy for sub-zones
|
||||
#
|
||||
# When a zone is declared to be a subzone of one or more other zones, it
|
||||
# is typically the case that you want the rules for the parent zone(s) to
|
||||
# be applied to connections to/from the subzone that don't match any
|
||||
# subzone specific rules. That way, you don't have to duplicate the parent
|
||||
# zone's rules in order for them to also apply to the subzone(s). That is
|
||||
# the behavior with IMPLICIT_CONTINUE=Yes. If you don't want that behavior
|
||||
# and want the policies for the sub-zone to be determined by the standard
|
||||
# policy processing, set IMPLICIT_CONTINUE=No or IMPLICIT_CONTINUE=.
|
||||
#
|
||||
# Note that even with IMPLICIT_CONTINUE=Yes, you can override the implicit
|
||||
# CONTINUE policy by adding an explicit policy (one that does not contain
|
||||
# "all" in either the SOURCE or DEST columns).
|
||||
|
||||
IMPLICIT_CONTINUE=Yes
|
||||
|
||||
#
|
||||
# Use high mark values for policy routing
|
||||
#
|
||||
# Normally, Shorewall restricts the set of mark values to 1-255. If you set
|
||||
# HIGH_ROUTE_MARKS=Yes, Shorewall will rather restrict the set of routing
|
||||
# mark values (those specified in the /etc/shorewall/providers file) to
|
||||
# a multiple of 256 (256 to 65280) or their hexadecimal equivalents
|
||||
# (0x0100 to 0xff00, with the low-order byte of the value being zero).
|
||||
# This allows connection marks to be shared between traffic shaping and
|
||||
# policy routing. Traffic shaping marks are always restricted to 1-255.
|
||||
#
|
||||
# Setting HIGH_ROUTE_MARKS=Yes requires that your kernel and iptables support
|
||||
# both the extended CONNMARK target and the extended connmark match
|
||||
# capabilities (see the output of "shorewall show capabilities").
|
||||
|
||||
HIGH_ROUTE_MARKS=No
|
||||
|
||||
#
|
||||
# Use Actions
|
||||
#
|
||||
# While Shorewall Actions can be very useful, they also require a sizable
|
||||
# amount of code to implement. By setting USE_ACTIONS=No, you can omit
|
||||
# /usr/share/shorewall/lib/actions from your configuration.
|
||||
|
||||
USE_ACTIONS=Yes
|
||||
|
||||
#
|
||||
# Optimize Ruleset
|
||||
#
|
||||
# Traditionally, Shorewall has created rules for the complete matrix of
|
||||
# Networks 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 changes. When the matrix is sparse, this results in lots of
|
||||
# largely useless rules.
|
||||
#
|
||||
# These extra rules can be eliminated by setting OPTIMIZE=1 and included
|
||||
# by setting OPTIMIZE=0
|
||||
#
|
||||
|
||||
OPTIMIZE=1
|
||||
|
||||
###############################################################################
|
||||
# P A C K E T D I S P O S I T I O N
|
||||
###############################################################################
|
||||
#
|
||||
# BLACKLIST DISPOSITION
|
||||
#
|
||||
# Set this variable to the action that you want to perform on packets from
|
||||
# Blacklisted systems. Must be DROP or REJECT. If not set or set to empty,
|
||||
# DROP is assumed.
|
||||
#
|
||||
|
||||
BLACKLIST_DISPOSITION=DROP
|
||||
|
||||
#
|
||||
# MAC List Disposition
|
||||
#
|
||||
# This variable determines the disposition of connection requests arriving
|
||||
# on interfaces that have the 'maclist' option and that are from a device
|
||||
# that is not listed for that interface in /etc/shorewall/maclist. Valid
|
||||
# values are ACCEPT, DROP and REJECT. If not specified or specified as
|
||||
# empty (MACLIST_DISPOSITION="") then REJECT is assumed
|
||||
#
|
||||
|
||||
MACLIST_DISPOSITION=REJECT
|
||||
|
||||
#
|
||||
# TCP FLAGS Disposition
|
||||
#
|
||||
# This variable determins the disposition of packets having an invalid
|
||||
# combination of TCP flags that are received on interfaces having the
|
||||
# 'tcpflags' option specified in /etc/shorewall/interfaces or in
|
||||
# /etc/shorewall/hosts. If not specified or specified as empty
|
||||
# (TCP_FLAGS_DISPOSITION="") then DROP is assumed.
|
||||
#
|
||||
|
||||
TCP_FLAGS_DISPOSITION=DROP
|
||||
|
||||
#LAST LINE -- DO NOT REMOVE
|
||||
|
||||
Loading…
Reference in New Issue
Block a user