From 2cbb02649c983b91adc2ac9fd9d5ada9d0ca4960 Mon Sep 17 00:00:00 2001 From: teastep Date: Wed, 20 Dec 2006 17:22:23 +0000 Subject: [PATCH] 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 --- Samples/one-interface/shorewall.conf | 821 +----------------------- Samples/three-interfaces/shorewall.conf | 821 +----------------------- Samples/two-interfaces/shorewall.conf | 821 +----------------------- 3 files changed, 18 insertions(+), 2445 deletions(-) diff --git a/Samples/one-interface/shorewall.conf b/Samples/one-interface/shorewall.conf index 897affffb..25656e6b8 100644 --- a/Samples/one-interface/shorewall.conf +++ b/Samples/one-interface/shorewall.conf @@ -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 2, 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 diff --git a/Samples/three-interfaces/shorewall.conf b/Samples/three-interfaces/shorewall.conf index 766dfaa47..3f699aa28 100644 --- a/Samples/three-interfaces/shorewall.conf +++ b/Samples/three-interfaces/shorewall.conf @@ -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 2, 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 diff --git a/Samples/two-interfaces/shorewall.conf b/Samples/two-interfaces/shorewall.conf index ee260affc..324d193c5 100644 --- a/Samples/two-interfaces/shorewall.conf +++ b/Samples/two-interfaces/shorewall.conf @@ -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 2, 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