shorewall_code/Shorewall/shorewall.conf

906 lines
31 KiB
Plaintext
Raw Normal View History

###############################################################################
# /etc/shorewall/shorewall.conf V3.2 - Change the following variables to
# match your setup
#
# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm]
#
# This file should be placed in /etc/shorewall
#
# (c) 1999,2000,2001,2002,2003,2004,2005 - Tom Eastep (teastep@shorewall.net)
#
# >>>>>>>>>>>>> NOTE TO USERS UPGRADING FROM 2.x <<<<<<<<<<<<<<<<<<
#
# Most problems associated with upgrades come from two causes:
#
# - The user didn't read and follow the migration considerations in the
# release notes.
#
# - The user mis-handled the /etc/shorewall/shorewall.conf file during
# upgrade. Shorewall is designed to allow the default behavior of
# the product to evolve over time. To make this possible, the design
# assumes that you will not replace your current shorewall.conf file
# during upgrades. If you feel absolutely compelled to have the latest
# comments and options in your shorewall.conf then you must proceed
# carefully.
#
# The new/changed options in shorewall 3.0 are listed below. If you don't
# want to convert to the new 3.0 format for /etc/shorewall/zones and you
# don't want to replace your current rules that use 2.x builtin actions,
# then if you plan to use this copy of shorewall.conf file then you must
# change it as follows:
#
# - IPSECFILE
#
# This file has IPSECFILE=zones. You want to set it to IPSECFILE=ipsec.
# This will indicate that your /etc/shorewall/zones file is in the
# pre-3.0 format.
#
# - FW
#
# This file has FW undefined. If you have named your firewall zone
# something other than 'fw' then you must set FW accordingly.
#
# - MAPOLDACTIONS
#
# This file has MAPOLDACTIONS=No. You want to set it to
# MAPOLDACTIONS=Yes in order to permit rules that use the 2.x builtin
# actions such as AllowPing to continue to work.
###############################################################################
# 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.
#
# CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT string (up
# to but not including the first '%') to find log messages in the 'show log',
# 'status' and 'hits' commands. This part should not be omitted (the
# LOGFORMAT should not begin with "%") and the leading part should be
# sufficiently unique for /sbin/shorewall to identify Shorewall messages.
#
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).
#
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
#
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=
Large merge of function from EXPERIMENTAL to HEAD. 1) Elimination of the "shorewall monitor" command. 2) The /etc/shorewall/ipsec and /etc/shorewall/zones file are combined into a single /etc/shorewall/zones file. This is done in an upwardly-compatible way so that current users can continue to use their existing files. 3) Support has been added for the arp_ignore interface option. 4) DROPINVALID has been removed from shorewall.conf. Behavior is as if DROPINVALID=No was specified. 5) The 'nobogons' option and BOGON_LOG_LEVEL are removed. 6) Error and warning messages have been made easier to spot by using capitalization (e.g., ERROR: and WARNING:). 7) The /etc/shorewall/policy file now contains a new connection policy and a policy for ESTABLISHED packets. Useful for users of snort-inline who want to pass all packets to the QUEUE target. 8) A new 'critical' option has been added to /etc/shorewall/routestopped. Shorewall insures communication between the firewall and 'critical' hosts throughout start, restart, stop and clear. Useful for diskless firewall's with NFS-mounted file systems, LDAP servers, Crossbow, etc. 9) Macros. Macros are very similar to actions but are easier to use, allow parameter substitution and are more efficient. Almost all of the standard actions have been converted to macros in the EXPERIMENTAL branch. 10) The default value of ADD_IP_ALIASES in shorewall.conf is changed to No. 11) If you have 'make' installed on your firewall, then when you use the '-f' option to 'shorewall start' (as happens when you reboot), if your /etc/shorewall/ directory contains files that were modified after Shorewall was last restarted then Shorewall is started using the config files rather than using the saved configuration. git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2409 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2005-07-26 01:08:09 +02:00
#
# 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
Large merge of function from EXPERIMENTAL to HEAD. 1) Elimination of the "shorewall monitor" command. 2) The /etc/shorewall/ipsec and /etc/shorewall/zones file are combined into a single /etc/shorewall/zones file. This is done in an upwardly-compatible way so that current users can continue to use their existing files. 3) Support has been added for the arp_ignore interface option. 4) DROPINVALID has been removed from shorewall.conf. Behavior is as if DROPINVALID=No was specified. 5) The 'nobogons' option and BOGON_LOG_LEVEL are removed. 6) Error and warning messages have been made easier to spot by using capitalization (e.g., ERROR: and WARNING:). 7) The /etc/shorewall/policy file now contains a new connection policy and a policy for ESTABLISHED packets. Useful for users of snort-inline who want to pass all packets to the QUEUE target. 8) A new 'critical' option has been added to /etc/shorewall/routestopped. Shorewall insures communication between the firewall and 'critical' hosts throughout start, restart, stop and clear. Useful for diskless firewall's with NFS-mounted file systems, LDAP servers, Crossbow, etc. 9) Macros. Macros are very similar to actions but are easier to use, allow parameter substitution and are more efficient. Almost all of the standard actions have been converted to macros in the EXPERIMENTAL branch. 10) The default value of ADD_IP_ALIASES in shorewall.conf is changed to No. 11) If you have 'make' installed on your firewall, then when you use the '-f' option to 'shorewall start' (as happens when you reboot), if your /etc/shorewall/ directory contains files that were modified after Shorewall was last restarted then Shorewall is started using the config files rather than using the saved configuration. git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2409 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2005-07-26 01:08:09 +02:00
# 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.
#
Large merge of function from EXPERIMENTAL to HEAD. 1) Elimination of the "shorewall monitor" command. 2) The /etc/shorewall/ipsec and /etc/shorewall/zones file are combined into a single /etc/shorewall/zones file. This is done in an upwardly-compatible way so that current users can continue to use their existing files. 3) Support has been added for the arp_ignore interface option. 4) DROPINVALID has been removed from shorewall.conf. Behavior is as if DROPINVALID=No was specified. 5) The 'nobogons' option and BOGON_LOG_LEVEL are removed. 6) Error and warning messages have been made easier to spot by using capitalization (e.g., ERROR: and WARNING:). 7) The /etc/shorewall/policy file now contains a new connection policy and a policy for ESTABLISHED packets. Useful for users of snort-inline who want to pass all packets to the QUEUE target. 8) A new 'critical' option has been added to /etc/shorewall/routestopped. Shorewall insures communication between the firewall and 'critical' hosts throughout start, restart, stop and clear. Useful for diskless firewall's with NFS-mounted file systems, LDAP servers, Crossbow, etc. 9) Macros. Macros are very similar to actions but are easier to use, allow parameter substitution and are more efficient. Almost all of the standard actions have been converted to macros in the EXPERIMENTAL branch. 10) The default value of ADD_IP_ALIASES in shorewall.conf is changed to No. 11) If you have 'make' installed on your firewall, then when you use the '-f' option to 'shorewall start' (as happens when you reboot), if your /etc/shorewall/ directory contains files that were modified after Shorewall was last restarted then Shorewall is started using the config files rather than using the saved configuration. git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2409 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2005-07-26 01:08:09 +02:00
IPSECFILE=zones
###############################################################################
# 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.
#
Large merge of function from EXPERIMENTAL to HEAD. 1) Elimination of the "shorewall monitor" command. 2) The /etc/shorewall/ipsec and /etc/shorewall/zones file are combined into a single /etc/shorewall/zones file. This is done in an upwardly-compatible way so that current users can continue to use their existing files. 3) Support has been added for the arp_ignore interface option. 4) DROPINVALID has been removed from shorewall.conf. Behavior is as if DROPINVALID=No was specified. 5) The 'nobogons' option and BOGON_LOG_LEVEL are removed. 6) Error and warning messages have been made easier to spot by using capitalization (e.g., ERROR: and WARNING:). 7) The /etc/shorewall/policy file now contains a new connection policy and a policy for ESTABLISHED packets. Useful for users of snort-inline who want to pass all packets to the QUEUE target. 8) A new 'critical' option has been added to /etc/shorewall/routestopped. Shorewall insures communication between the firewall and 'critical' hosts throughout start, restart, stop and clear. Useful for diskless firewall's with NFS-mounted file systems, LDAP servers, Crossbow, etc. 9) Macros. Macros are very similar to actions but are easier to use, allow parameter substitution and are more efficient. Almost all of the standard actions have been converted to macros in the EXPERIMENTAL branch. 10) The default value of ADD_IP_ALIASES in shorewall.conf is changed to No. 11) If you have 'make' installed on your firewall, then when you use the '-f' option to 'shorewall start' (as happens when you reboot), if your /etc/shorewall/ directory contains files that were modified after Shorewall was last restarted then Shorewall is started using the config files rather than using the saved configuration. git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2409 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2005-07-26 01:08:09 +02:00
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
#
# Clear Traffic Shapping/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
#
# 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
Large merge of function from EXPERIMENTAL to HEAD. 1) Elimination of the "shorewall monitor" command. 2) The /etc/shorewall/ipsec and /etc/shorewall/zones file are combined into a single /etc/shorewall/zones file. This is done in an upwardly-compatible way so that current users can continue to use their existing files. 3) Support has been added for the arp_ignore interface option. 4) DROPINVALID has been removed from shorewall.conf. Behavior is as if DROPINVALID=No was specified. 5) The 'nobogons' option and BOGON_LOG_LEVEL are removed. 6) Error and warning messages have been made easier to spot by using capitalization (e.g., ERROR: and WARNING:). 7) The /etc/shorewall/policy file now contains a new connection policy and a policy for ESTABLISHED packets. Useful for users of snort-inline who want to pass all packets to the QUEUE target. 8) A new 'critical' option has been added to /etc/shorewall/routestopped. Shorewall insures communication between the firewall and 'critical' hosts throughout start, restart, stop and clear. Useful for diskless firewall's with NFS-mounted file systems, LDAP servers, Crossbow, etc. 9) Macros. Macros are very similar to actions but are easier to use, allow parameter substitution and are more efficient. Almost all of the standard actions have been converted to macros in the EXPERIMENTAL branch. 10) The default value of ADD_IP_ALIASES in shorewall.conf is changed to No. 11) If you have 'make' installed on your firewall, then when you use the '-f' option to 'shorewall start' (as happens when you reboot), if your /etc/shorewall/ directory contains files that were modified after Shorewall was last restarted then Shorewall is started using the config files rather than using the saved configuration. git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2409 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2005-07-26 01:08:09 +02:00
#
# 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
#
Large merge of function from EXPERIMENTAL to HEAD. 1) Elimination of the "shorewall monitor" command. 2) The /etc/shorewall/ipsec and /etc/shorewall/zones file are combined into a single /etc/shorewall/zones file. This is done in an upwardly-compatible way so that current users can continue to use their existing files. 3) Support has been added for the arp_ignore interface option. 4) DROPINVALID has been removed from shorewall.conf. Behavior is as if DROPINVALID=No was specified. 5) The 'nobogons' option and BOGON_LOG_LEVEL are removed. 6) Error and warning messages have been made easier to spot by using capitalization (e.g., ERROR: and WARNING:). 7) The /etc/shorewall/policy file now contains a new connection policy and a policy for ESTABLISHED packets. Useful for users of snort-inline who want to pass all packets to the QUEUE target. 8) A new 'critical' option has been added to /etc/shorewall/routestopped. Shorewall insures communication between the firewall and 'critical' hosts throughout start, restart, stop and clear. Useful for diskless firewall's with NFS-mounted file systems, LDAP servers, Crossbow, etc. 9) Macros. Macros are very similar to actions but are easier to use, allow parameter substitution and are more efficient. Almost all of the standard actions have been converted to macros in the EXPERIMENTAL branch. 10) The default value of ADD_IP_ALIASES in shorewall.conf is changed to No. 11) If you have 'make' installed on your firewall, then when you use the '-f' option to 'shorewall start' (as happens when you reboot), if your /etc/shorewall/ directory contains files that were modified after Shorewall was last restarted then Shorewall is started using the config files rather than using the saved configuration. git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2409 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2005-07-26 01:08:09 +02:00
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
###############################################################################
# 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