############################################################################### # # Shorewall Version 5 -- /etc/shorewall6/shorewall6.conf # Copyright (C) 2012-2015 by the Shorewall Team # # For information about the settings in this file, type "man shorewall6.conf" # # Manpage also online at # http://www.shorewall.net/manpages6/shorewall6.conf.html ############################################################################### # S T A R T U P E N A B L E D ############################################################################### # # OPTIONS # # Many options have as their value a log-level. Log levels are a method of # describing to syslog (8) the importance of a message and a number of parameters # in this file have log levels as their value. # # These levels are defined by syslog and are used to determine the destination of # the messages through entries in /etc/syslog.conf (5). The syslog documentation # refers to these as "priorities"; Netfilter calls them "levels" and Shorewall # also uses that term. # # Valid levels are: # # 7 debug # 6 info # 5 notice # 4 warning # 3 err # 2 crit # 1 alert # 0 emerg # # For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall log # messages are generated by NetFilter and are logged using facility 'kern' and # the level that you specify. If you are unsure of the level to choose, 6 (info) # is a safe bet. You may specify levels by name or by number. # # If you have built your kernel with ULOG (IPv4 only) and/or NFLOG target # support, you may also specify a log level of ULOG and/or NFLOG (must be all # caps). Rather than log its messages to syslogd, Shorewall will direct netfilter # to log the messages via the ULOG or NFLOG target which will send them to a # process called 'ulogd'. ulogd is available with most Linux distributions # (although it probably isn't installed by default). # # Note # # If you want to specify parameters to ULOG or NFLOG (e.g., NFLOG(1,0,1)), then # you must quote the setting. # # Example: # STARTUP_ENABLED=No # # STARTUP_ENABLED={Yes|No} # # Determines if Shorewall is allowed to start. As released from # shorewall.net, this option is set to No. When set to Yes or yes, Shorewall # may be started. Used as a guard against Shorewall being accidentally # started before it has been configured. # ############################################################################### # V E R B O S I T Y ############################################################################### VERBOSITY=1 # # VERBOSITY=[number] # # Shorewall has traditionally been very noisy (produced lots of output). You # may set the default level of verbosity using the VERBOSITY OPTION. # # Values are: # # 0 - Silent. You may make it more verbose using the -v option # 1 - Major progress messages displayed # 2 - All progress messages displayed (pre Shorewall-3.2.0 behavior) # # If not specified, then 2 is assumed. # ############################################################################### # P A G E R ############################################################################### PAGER= # # PAGER=pathname # # Added in Shorewall 5.0.6. Specifies a path name of a pager program like # less or more. When PAGER is given, the output of verbose status commands # and the dump command are piped through the named program when the output # file is a terminal. # # Beginning with Shorewall 5.0.12, the default value of this option is the # DEFAULT_PAGER setting in shorewallrc. # ############################################################################### # F I R E W A L L ############################################################################### FIREWALL= # # FIREWALL=[dnsname-or-ip-address] # # This option was added in Shorewall 5.0.13 and may be used on an # administrative system in directories containing the configurations of # remote firewalls. The contents of the variable are the default value for # the system parameter to the remote-start, remote-reload and remote-restart # commands. # ############################################################################### # L O G G I N G ############################################################################### LOG_LEVEL="info" # # LOG_LEVEL=log-level[:log-tag] # # Added in Shorewall 5.1.2. Beginning with that release, the sample # configurations use this as the default log level and changing it will # change all packet logging done by the configuration. In any configuration # file (except shorewall-params(5)), $LOG_LEVEL will expand to this value. # BLACKLIST_LOG_LEVEL= # # BLACKLIST_LOG_LEVEL=[log-level[:log-tag]] # # Formerly named BLACKLIST_LOGLEVEL. This parameter determines if packets # from blacklisted hosts are logged and it determines the syslog level that # they are to be logged at. Its value is a syslog level (Example: # BLACKLIST_LOG_LEVEL=debug). If you do not assign a value or if you assign # an empty value then packets from blacklisted hosts are not logged. The # setting determines the log level of packets sent to the blacklog target of # shorewall-blrules(5). # INVALID_LOG_LEVEL= # # INVALID_LOG_LEVEL=log-level[:log-tag] # # Added in Shorewall 4.5.13. Packets in the INVALID state that do not match # any rule in the INVALID section of shorewall-rules (5) are logged at this # level. The default value is empty which means no logging is performed. # LOG_BACKEND= # # LOG_BACKEND=[backend] # # Added in Shorewall 4.6.4. LOG_BACKEND determines the logging backend to be # used for the iptrace command (see shorewall(8)). # # backend is one of: # # LOG # # Use standard kernel logging. # # ULOG # # IPv4 only. # # Use ULOG logging to ulogd. # # netlink # # Use netlink logging to ulogd version 2 or later. # LOG_VERBOSITY=2 # # LOG_VERBOSITY=[number] # # This option controls the amount of information logged to the file specified # in the STARTUP_LOG option. # # Values are: # # -1 - Logging is disabled # 0 - Silent. Only error messages are logged. # 1 - Major progress messages logged. # 2 - All progress messages logged # # If not specified, then -1 is assumed. # LOG_ZONE=Both # # LOG_ZONE=[src|dst|both] # # Added in Shorewall 5.2.0. When a log message is issued from a chain that # relates to a pair of zones (e.g, 'fw-net'), the chain name normally appears # in the log message (unless LOGTAGONLY=Yes and a log tag is specified). This # can prevent OPTIMIZE category 8 from combining chains which are identical # except for the names of the zones involved. LOG_ZONE allows for only the # source or destination zone to appear in the messages by setting LOG_ZONE to # src or dest respectively. If LOG_ZONE=both (the default), then the full # chain name is included in log messages. # LOGALLNEW= # # LOGALLNEW=[log-level] # # This option is intended for use as a debugging aid. When set to a log # level, this option causes Shorewall to generate a logging rule as the first # rule in each builtin chain. # # â¡ The table name is used as the chain name in the log prefix. # # â¡ The chain name is used as the target in the log prefix. # # For example, using the default LOGFORMAT, the log prefix for logging # from the nat table's PREROUTING chain is as follows in versions prior # to 5.1.0: # # Shorewall:nat:PREROUTING # # # In Shorewall 5.1.0 and later releases, the log prefix is: # # nat:PREROUTING # # # Important # # To help insure that all packets in the NEW state are logged, rate # limiting (LOGLIMIT) should be disabled when using LOGALLNEW. Use # LOGALLNEW at your own risk; it may cause high CPU and disk utilization # and you may not be able to control your firewall after you enable this # option. # # Caution # # Do not use this option if the resulting log messages will be sent to # another system. # LOGFILE= # # LOGFILE=[pathname|systemd] # # This parameter tells the /sbin/shorewall program where to look for # Shorewall messages when processing the dump, logwatch, show log, and hits # commands. If not assigned or if assigned an empty value, /var/log/messages # is assumed. For further information, see shorewall-logging(8). Beginning # with Shorewall 5.0.10.1, you may specify systemd to use journelctl -r to # read the log. # LOGFORMAT="%s %s " # # LOGFORMAT=["formattemplate"] # # The value of this variable generate the --log-prefix setting for Shorewall # logging rules. It contains a âprintfâ formatting template which accepts # three arguments (the chain name, logging rule number (optional) and the # disposition). To use LOGFORMAT with fireparse, set it as: # # LOGFORMAT="fp=%s:%d a=%s " # # If the LOGFORMAT value contains the substring â%dâ then the logging rule # number is calculated and formatted in that position; if that substring is # not included then the rule number is not included. If not supplied or # supplied as empty (LOGFORMAT="") then âShorewall:%s:%s:â is assumed. # # Note # # The setting of LOGFORMAT has an effect of the permitted length of zone # names. See shorewall-zones (5). # # Caution # # Beginning with Shorewall 5.1.0, the default and sample shorewall[6].conf # files set LOGFORMAT="%s %s ". # # Regardless of the LOGFORMAT setting, Shorewall IPv4 log messages that use # this LOGFORMAT can be uniquely identified using the following regular # expression: # # 'IN=.* OUT=.* SRC=.*\..* DST=' # # and Shorewall IPv6 log messages can be uniquely identified using the # following regular expression: # # 'IN=.* OUT=.* SRC=.*:.* DST=' # # To match all Netfilter log messages (Both IPv4 and IPv6 and regardless of # the LOGFORMAT setting), use: # # 'IN=.* OUT=.* SRC=.* DST=' # LOGLIMIT="s:1/sec:10" # # LOGLIMIT=[[{s|d}:]rate/{sec|second|min|minute|hour|day}[:burst]] # # Added in Shorewall 4.4.12. Limits the logging rate, either overall, or by # source or destination IP address. # # If the value starts with 's:' then logging is limited per source IP. If the # value starts with 'd:', then logging is limited per destination IP. # Otherwise, the overall logging rate is limited. # # If burst is not specified, then a value of 5 is assumed. # # The keywords second and minute are accepted beginning with Shorewall # 4.6.13. # LOGTAGONLY=No # # LOGTAGONLY=[Yes|No] # # Using LOGFORMAT=âShorewall:%s:%s:â, chain names may not exceed 5 characters # or truncation of the log prefix may occur. Longer chain names may be used # with log tags if you set LOGTAGONLY=Yes. With LOGTAGONLY=Yes, if a log tag # is specified then the tag is included in the log prefix in place of the # chain name. # # Beginning with Shorewall 4.5.12, when LOGTAGONLY=Yes, you have more control # over the generated log prefix. Beginning with that release, the tag is # interpreted as a chain name and a disposition separated by a comma. So this # rule: # # #ACTION SOURCE DEST # LOG:info:foo,bar net fw # # would generate the following log prefix when using LOGFORMAT= # âShorewall:%s:%s:â: # # Shorewall:foo:bar: # # Similarly, # # #ACTION SOURCE DEST # LOG:info:,bar net fw # # would generate # # Shorewall:net2fw:bar: # MACLIST_LOG_LEVEL="$LOG_LEVEL" # # MACLIST_LOG_LEVEL=[log-level[:log-tag]] # # Determines the syslog level for logging connection requests that fail MAC # Verification. The value must be a valid syslogd log level. If you don't # want to log these connection requests, set to the empty value (e.g., # MACLIST_LOG_LEVEL=""). # RELATED_LOG_LEVEL= # # RELATED_LOG_LEVEL=log-level[:log-tag] # # Added in Shorewall 4.4.27. Packets in the related state that do not match # any rule in the RELATED section of shorewall-rules (5) are logged at this # level. The default value is empty which means no logging is performed. # RPFILTER_LOG_LEVEL="$LOG_LEVEL" # # RPFILTER_LOG_LEVEL=log-level[:log-tag] # # Added in shorewall 4.5.7. Determines the logging of packets disposed via # the RPFILTER_DISPOSITION. The default value is info. # SFILTER_LOG_LEVEL="$LOG_LEVEL" # # SFILTER_LOG_LEVEL=log-level[:log-tag] # # Added on Shorewall 4.4.20. Determines the logging of packets matching the # sfilter option (see shorewall-interfaces(5)) and of hairpin packets on # interfaces without the routeback option.^[2] The default is info. If you # don't wish for these packets to be logged, use SFILTER_LOG_LEVEL=none. # SMURF_LOG_LEVEL="$LOG_LEVEL" # # SMURF_LOG_LEVEL=[log-level[:log-tag]] # # Specifies the logging level for smurf packets (see the nosmurfs option in # shorewall-interfaces(5)). If set to the empty value ( SMURF_LOG_LEVEL="" ) # then smurfs are not logged. # STARTUP_LOG=/var/log/shorewall6-init.log # # STARTUP_LOG=[pathname] # # If specified, determines where Shorewall will log the details of each start # , reload, restart, try, and safe-* command. Logging verbosity is determined # by the setting of LOG_VERBOSITY above. # TCP_FLAGS_LOG_LEVEL="$LOG_LEVEL" # # TCP_FLAGS_LOG_LEVEL=[log-level[:log-tag]] # # Determines the syslog level for logging packets that fail the checks # enabled by the tcpflags interface option. The value must be a valid syslogd # log level. If you don't want to log these packets, set to the empty value # (e.g., TCP_FLAGS_LOG_LEVEL=""). # UNTRACKED_LOG_LEVEL= # # UNTRACKED_LOG_LEVEL=log-level[:log-tag] # # Added in Shorewall 4.5.13. Packets in the UNTRACKED state that do not match # any rule in the UNTRACKED section of shorewall-rules (5) are logged at this # level. The default value is empty which means no logging is performed. # ############################################################################### # L O C A T I O N O F F I L E S A N D D I R E C T O R I E S ############################################################################### CONFIG_PATH=":${CONFDIR}/shorewall6:/usr/share/shorewall6:${SHAREDIR}/shorewall" # # CONFIG_PATH=[[:]directory[:directory]...] # # Specifies where configuration files other than shorewall[6].conf may be # found. CONFIG_PATH is specifies as a list of directory names separated by # colons (":"). When looking for a configuration file: # # â¡ If the command is "try" or a "<configuration directory>" was specified # in the command (e.g., shorewall [-6] check ./gateway) then the # directory given in the command is searched first. # # â¡ Next, each directory in the CONFIG_PATH setting is searched in # sequence. # # If CONFIG_PATH is not given or if it is set to the empty value then the # contents of /usr/share/shorewall/configpath are used. As released from # shorewall.net, that file sets the CONFIG_PATH to /etc/shorewall:/usr/share/ # shorewall but your particular distribution may set it differently. See the # output of shorewall show config for the default on your system. # # Beginning with Shorewall 5.1.10, the CONFIG_PATH setting may begin with a # colon (":"), to signal that the first directory listed will be skipped if # the user performing a compilation is not root or if the configuration is # being compiled for export (-e option specified or if running one of the # remote-* commands) . This prevents the compiler from looking in /etc/ # shorewall[6]/ when compilation is being done by a non-root user or if the # generated script is to be sent to a remote firewall system. # GEOIPDIR=/usr/share/xt_geoip/LE # # GEOIPDIR=[pathname] # # Added in Shorewall 4.5.4. Specifies the pathname of the directory # containing the GeoIP Match database. See http://www.shorewall.net/ # ISO-3661.html. If not specified, the default value is /usr/share/xt_geoip/ # LE which is the default location of the little-endian database. # IP6TABLES= # # IP6TABLES=[pathname] # # IPv6 only. # # This parameter names the ip6tables executable to be used by Shorewall6. If # not specified or if specified as a null value, then the ip6tables # executable located using the PATH option is used. # # Regardless of how the ip6tables utility is located (specified via IP6TABLES # = or located via PATH), Shorewall6 uses the ip6tables-restore and # ip6tables-save utilities from that same directory. # IP= # # IP=[pathname] # # If specified, gives the pathname of the 'ip' executable. If not specified, # 'ip' is assumed and the utility will be located using the current PATH # setting. # IPSET= # # IPSET=[pathname] # # If specified, gives the pathname of the 'ipset' executable. If not # specified, 'ipset' is assumed and the utility will be located using the # current PATH setting. # LOCKFILE= # # LOCKFILE=[pathname] # # Specifies the name of the Shorewall[6] lock file, used to prevent # simultaneous state-changing commands. If not specified, ${VARDIR}/shorewall # [6]/lock is assumed (${VARDIR} is normally /var/lib but can be changed when # Shorewall-core is installed -- see the output of shorewall show vardir). # MODULESDIR= # # MODULESDIR=[[+]pathname[:pathname]...] # # This parameter specifies the directory/directories where your kernel # netfilter modules may be found. If you leave the variable empty, Shorewall # will supply the value "/lib/modules/$uname/kernel/net/ipv${g_family}/ # netfilter:/lib/modules/$uname/kernel/net/netfilter:/lib/modules/$uname/ # kernel/net/sched:/lib/modules/$uname/extra:/lib/modules/$uname/extra/ipset" # where uname holds the output of 'uname -r' and g_family holds '4' in IPv4 # configurations and '6' in IPv6 configurations. # # The option plus sign ('+') was added in Shorewall 5.0.3 and causes the # listed pathnames to be appended to the default list above. # NFACCT= # # NFACCT=[pathname] # # Added in Shorewall 4.5.7. Specifies the pathname of the nfacct utility. If # not specified, Shorewall will use the PATH setting to find the program. # PERL=/usr/bin/perl # # PERL=pathname # # Added in Shorewall 4.4.11 RC1. Specifies the path name of the Perl # executable. Default is /usr/bin/perl. If the pathname specified by this # option does not exist or the named file is not executable, then Shorewall # falls back to /usr/bin/perl # PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin # # PATH=pathname[:pathname]... # # Determines the order in which Shorewall searches directories for executable # files. # RESTOREFILE=restore # # RESTOREFILE=filename # # Specifies the simple name of a file in /var/lib/shorewall to be used as the # default restore script in the shorewall [-6] save, shorewall [-6] restore, # shorewall [-6] forget and shorewall [6] -f start commands. # SHOREWALL_SHELL=/bin/sh # # SHOREWALL_SHELL=[pathname] # # This option is used to specify the shell program to be used to interpret # the compiled script. If not specified or specified as a null value, /bin/sh # is assumed. Using a light-weight shell such as ash or dash can # significantly improve performance. # SUBSYSLOCK= # # SUBSYSLOCK=[pathname] # # This parameter should be set to the name of a file that the firewall should # create if it starts successfully and remove when it stops. Creating and # removing this file allows Shorewall to work with your distribution's # initscripts. For OpenSuSE, this should be set to /var/lock/subsys/shorewall # (var/lock/subsys/shorewall-lite if building for export). For Gentoo, it # should be set to /run/lock/shorewall (/run/lock/shorewall-lite). For Redhat # and derivatives as well as Debian and derivatives, the pathname should be # omitted. # # Important # # Beginning with Shorewall 5.1.0, this setting is ignored when SERVICEDIR is # non-empty in ${SHAREDIR}/shorewall/shorewallrc (usually /usr/share/ # shorewall/shorewallrc). # TC= # # TC=[pathname] # # If specified, gives the pathname of the 'tc' executable. If not specified, # 'tc' is assumed and the utility will be located using the current PATH # setting. # ############################################################################### # D E F A U L T A C T I O N S / M A C R O S ############################################################################### ACCEPT_DEFAULT="none" # # ACCEPT_DEFAULT={action[(parameters)][:level][,...]|none} # BLACKLIST_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP),dropNotSyn:$LOG_LEVEL,dropInvalid:$LOG_LEVEL,DropDNSrep:$LOG_LEVEL" # # BLACKLIST_DEFAULT={action[(parameters)][:level][,...]|none} # DROP_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)" # # DROP_DEFAULT={action[(parameters)][:level][,...]|none} # NFQUEUE_DEFAULT="none" # # NFQUEUE_DEFAULT={action[(parameters)][:level][,...]|none} # QUEUE_DEFAULT="none" # # QUEUE_DEFAULT={action[(parameters)][:level][,...]|none} # REJECT_DEFAULT="AllowICMPs,Broadcast(DROP),Multicast(DROP)" # # REJECT_DEFAULT={action[(parameters)][:level][,...]|none} # # In earlier Shorewall versions, a "default action" for DROP and REJECT # policies was specified in the file /usr/share/shorewall/actions.std. # # In Shorewall 4.4.0, the DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT, # QUEUE_DEFAULT and NFQUEUE_DEFAULT options were added. # # DROP_DEFAULT describes the rules to be applied before a connection request # is dropped by a DROP policy; REJECT_DEFAULT describes the rules to be # applied if a connection request is rejected by a REJECT policy. The other # three are similar for ACCEPT, QUEUE and NFQUEUE policies. # # The value applied to these may be: # # a) The name of an action. The name may optionally be followed by a # comma-separated list of parameters enclosed in parentheses if the specified # action accepts parameters (e.g., 'Drop(audit)'). # c) None or none # # Prior to Shorewall 5.1.2, the default values are: # # DROP_DEFAULT="Drop" # REJECT_DEFAULT="Reject" # BLACKLIST_DEFAULT="Drop" (added in Shorewall 5.1.1) # ACCEPT_DEFAULT="none" # QUEUE_DEFAULT="none" # NFQUEUE_DEFAULT="none" # # Beginning with Shorewall 5.1.2, the default value is 'none' for all of # these. Note that the sample configuration files do, however, provide # settings for DROP_DEFAULT, BLACKLIST_DEFAULT and REJECT_DEFAULT. # # If you set the value of either option to "None" then no default action will # be used and the default action or macro must be specified in # shorewall-policy(5). # # You can pass parameters to the specified action (e.g., myaction(audit,DROP) # ). # # Beginning with Shorewall 4.5.10, the action name can be followed optionally # by a colon and a log level. The level will be applied to each rule in the # action or body that does not already have a log level. # # Beginning with Shorewall 5.1.2, multiple action[(parameters)][:level] # specifications may be listed, separated by commas. # ############################################################################### # R S H / R C P C O M M A N D S ############################################################################### RCP_COMMAND='scp ${files} ${root}@${system}:${destination}' # # RCP_COMMAND="command" # RSH_COMMAND='ssh ${root}@${system} ${command}' # # RSH_COMMAND="command" # # Earlier generations of Shorewall Lite required that remote root login via # ssh be enabled in order to use the load and reload commands. Beginning with # release 3.9.5, you may define an alternative means for accessing the remote # firewall system. In that release, two new options were added to # shorewall.conf: # # RSH_COMMAND # RCP_COMMAND # # The default values for these are as follows: # # RSH_COMMAND: ssh ${root}@${system} ${command} # RCP_COMMAND: scp ${files} ${root}@${system}:${destination} # # Shell variables that will be set when the commands are invoked are as # follows: # # root - root user. Normally root but may be overridden using the '-r' option. # system - The name/IP address of the remote firewall system. # command - For RSH_COMMAND, the command to be executed on the firewall system. # files - For RCP_COMMAND, a space-separated list of files to be copied to the remote firewall system. # destination - The directory on the remote system that the files are to be copied into. # ############################################################################### # F I R E W A L L O P T I O N S ############################################################################### ACCOUNTING=Yes # # ACCOUNTING=[Yes|No] # # Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting is enabled # (see shorewall-accounting(5)). If not specified or set to the empty value, # ACCOUNTING=Yes is assumed. # ACCOUNTING_TABLE=filter # # ACCOUNTING_TABLE=[filter|mangle] # # Added in Shorewall 4.4.20. This setting determines which Netfilter table # the accounting rules are added in. By default, ACCOUNTING_TABLE=filter is # assumed. See also shorewall-accounting(5). # ADMINISABSENTMINDED=Yes # # ADMINISABSENTMINDED=[Yes|No] # # The value of this variable affects Shorewall's stopped state. The behavior # differs depending on whether shorewall-routestopped(5) or # shorewall-stoppedrules(5) is used: # # routestopped # # When ADMINISABSENTMINDED=No, only traffic to/from those addresses # listed in routestopped is accepted when Shorewall is stopped. When # ADMINISABSENTMINDED=Yes, in addition to traffic to/from addresses in # routestopped, connections that were active when Shorewall stopped # continue to work and all new connections from the firewall system # itself are allowed. # # Note that the routestopped file is not supported in Shorewall 5.0 and # later versions. # # stoppedrules # # All existing connections continue to work. To sever all existing # connections when the firewall is stopped, install the conntrack utility # and place the command conntrack -F in the stopped user exit (/etc/ # shorewall/stopped). # # If ADMINISABSENTMINDED=No, only new connections matching entries in # stoppedrules are accepted when Shorewall is stopped. Response packets # and related connections are automatically accepted. # # If ADMINISABSENTMINDED=Yes, in addition to connections matching entries # in stoppedrules, all new connections from the firewall system itself # are allowed when the firewall is stopped. Response packets and related # connections are automatically accepted. # # If this variable is not set or is given the empty value then # ADMINISABSENTMINDED=No is assumed. # AUTOCOMMENT=Yes # # AUTOCOMMENT=[Yes|No] # # Formerly named AUTO_COMMENT. If set, if there is not a current comment when # a macro is invoked, the behavior is as if the first line of the macro file # was "COMMENT <macro name>". If not specified, the AUTO_COMMENT option has a # default value of 'Yes'. # AUTOHELPERS=Yes # # AUTOHELPERS=[Yes|No] # # Added in Shorewall 4.5.7. When set to Yes (the default), the generated # ruleset will automatically associate helpers with applications that require # them (FTP, IRC, etc.). When configuring your firewall on systems running # kernel 3.5 or later, it is recommended that you: # # 1. Set AUTOHELPERS=No. # # 2. Modify the HELPERS setting (see below) to list the helpers that you # need. # # 3. Either: # # a. Modify shorewall-conntrack (5) to only apply helpers where they are # required; or # # b. Specify the appropriate helper in the HELPER column in # shorewall-rules (5). # # Note # # The macros for those applications requiring a helper automatically # specify the appropriate HELPER where required. # AUTOMAKE=Yes # # AUTOMAKE=[Yes|No|recursive|depth] # # If set, the behavior of the start, reload and restart commands are changed; # if no files in CONFIG_PATH (see below) have been changed since the last # successful start, reload or restart command, then the compilation step is # skipped and the compiled script that executed the last start, reload or # restart command is used. If not specified, the default is AUTOMAKE=No. # # The setting of the AUTOMAKE option is ignored if the start, reload or # restart command includes a directory name (e.g., shorewall restart /etc/ # shorewall.new). # # When AUTOMAKE=Yes, each directory in the CONFIG_PATH was originally # searched recursively for files newer than the compiled script. That was # changed in Shorewall 5.1.10.2 such that only the listed directories # themselves were searched. That broke some configurations that played tricks # with embedded SHELL such as "SHELL cat /etc/shorewall/rules.d/loc/*.rules". # Prior to 5.1.10.2, a change to a file in or adding a file to /etc/shorewall # /rules.d/loc/ would trigger recompilation. Beginning with 5.1.10.2, such # changes would not trigger recompilation. Beginning with Shorewall 5.2.0, # the pre-5.1.10.2 behavior can be obtained by setting AUTOMAKE=recursive. # # Also beginning with Shorewall 5.2.0, AUTOMAKE may be set to a numeric depth # which specifies how deeply each listed directory is to be searched. # AUTOMAKE=1 only searches each directory itself and is equivalent to # AUTOMAKE=Yes. AUTOMAKE=2 will search each directory and its immediate # sub-directories; AUTOMAKE=3 will search each directory, each of its # immediate sub-directories, and each of their immediate sub-directories, # etc. # BALANCE_PROVIDERS=No # # BALANCE_PROVIDERS=[Yes|No] # # Added in Shorewall 5.1.1. When USE_DEFAULT_RT=Yes, this option determines # whether the balance provider option (see shorewall-providers(5)) is the # default. When BALANCE_PROVIDERS=Yes, then the balance option is assumed # unless the fallback, loose, load or tproxy option is specified. If this # option is not set or is set to the empty value, then the default value is # the value of USE_DEFAULT_RT. # BASIC_FILTERS=No # # BASIC_FILTERS=[Yes|No] # # Added in Shorewall-4.6.0. When set to Yes, causes entries in # shorewall-tcfilters(5) to generate a basic filter rather than a u32 filter. # This setting requires the Basic Ematch capability in your kernel and # iptables. # # Note # # One of the advantages of basic filters is that ipset matches are supported # in newer iproute2 and kernel versions. Because Shorewall cannot reliably # detect this capability, use of basic filters is controlled by this option. # # The default value is No which causes u32 filters to be generated. # BLACKLIST="NEW,INVALID,UNTRACKED" # # BLACKLIST=[{ALL|state[,...]}] # # where state is one of NEW, ESTABLISHED, RELATED, INVALID,or UNTRACKED. # # Added in Shorewall 4.5.13 to replace the BLACKLISTNEWONLY option. Specifies # the connection tracking states that are to be subject to blacklist # screening. If BLACKLIST is not specified then the states subject to # blacklisting are NEW,ESTABLISHED,INVALID,UNTRACKED. # # ALL sends all packets through the blacklist chains. # # Note: The ESTABLISHED state may not be specified if FASTACCEPT=Yes is # specified. # CLAMPMSS=No # # CLAMPMSS=[Yes|No|value] # # This parameter enables the TCP Clamp MSS to PMTU feature of Netfilter and # is usually required when your internet connection is through PPPoE or PPTP. # If set to Yes or yes, the feature is enabled. If left blank or set to No or # no, the feature is not enabled. # # Important: This option requires CONFIG_IP_NF_TARGET_TCPMSS in your kernel. # # You may also set CLAMPMSS to a numeric value (e.g., CLAMPMSS=1400). This # will set the MSS field in TCP SYN packets going through the firewall to the # value that you specify. # CLEAR_TC=No # # CLEAR_TC=[Yes|No] # # If this option is set to No then Shorewall won't clear the current traffic # control rules during [re]start or reload. This setting is intended for use # by people who prefer to configure traffic shaping when the network # interfaces come up rather than when the firewall is started. If that is # what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not supply # an /etc/shorewall/tcstart file. That way, your traffic shaping rules can # still use the âfwmarkâ classifier based on packet marking defined in # shorewall-tcrules(5). If not specified, CLEAR_TC=Yes is assumed. # # Warning # # When you specify TC_ENABLED=shared (see below), then you should also # specify CLEAR_TC=No. # COMPLETE=No # # COMPLETE=[Yes|No] # # Added in Shorewall 4.4.12. When you set this option to Yes, you are # asserting that the configuration is complete so that your set of zones # encompasses any hosts that can send or receive traffic to/from/through the # firewall. This causes Shorewall to omit the rules that catch packets in # which the source or destination IP address is outside of any of your zones. # Default is No. It is recommended that this option only be set to Yes if: # # â¡ You have defined an interface whose effective physical setting is '+'. # # â¡ That interface is assigned to a zone. # # â¡ You have no CONTINUE policies or rules. # DEFER_DNS_RESOLUTION=Yes # # DEFER_DNS_RESOLUTION=[Yes|No] # # Added in Shorewall 4.5.12. When set to 'Yes' (the default), DNS names are # validated in the compiler and then passed on to the generated script where # they are resolved by ip[6]tables-restore. This is an advantage if you use # AUTOMAKE=Yes and the IP address associated with the DNS name is subject to # change. When DEFER_DNS_RESOLUTION=No, DNS names are converted into IP # addresses by the compiler. This has the advantage that when AUTOMAKE=Yes, # the start, reload and restart commands will succeed even if no DNS server # is reachable (assuming that the configuration hasn't changed since the # compiled script was last generated). # # Important # # When DEFER_DNS_RESOLUTION=No and AUTOMAKE=Yes and a DNS change makes it # necessary to recompile an existing firewall script, the -c option must be # used with the reload or restart command to force recompilation. # DELETE_THEN_ADD=Yes # # DELETE_THEN_ADD={Yes|No} # # If set to Yes (the default value), entries in the /etc/shorewall[6]/rtrules # files cause an 'ip rule del' command to be generated in addition to an 'ip # rule add' command. Setting this option to No, causes the 'ip rule del' # command to be omitted. # DONT_LOAD= # # DONT_LOAD=[module[,module]...] # # Causes Shorewall to not load the listed kernel modules. # DYNAMIC_BLACKLIST=Yes # # DYNAMIC_BLACKLIST={Yes|No||ipset[-only][,option[,...]][:[setname][:log_level|:l # og_tag]]]} # # Added in Shorewall 4.4.7. When set to No or no, chain-based dynamic # blacklisting using shorewall [-6] [-l] drop, shorewall [-6] [-l] reject, # shorewall logdrop and shorewall [-6] [-l] logreject is disabled. Default is # Yes. Beginning with Shorewall 5.0.8, ipset-based dynamic blacklisting using # the shorewall blacklist command is also supported. The name of the set ( # setname) and the level (log_level), if any, at which blacklisted traffic is # to be logged may also be specified. The default IPv4 set name is SW_DBL4 # and the default IPv6 set name is SW_DBL6. The default log level is none (no # logging). If ipset-only is given, then chain-based dynamic blacklisting is # disabled just as if DYNAMIC_BLACKLISTING=No had been specified. # # Possible options are: # # src-dst # # Normally, only packets whose source address matches an entry in the # ipset are dropped. If src-dst is included, then packets whose # destination address matches an entry in the ipset are also dropped. # # disconnect # # The disconnect option was added in Shorewall 5.0.13 and requires that # the conntrack utility be installed on the firewall system. When an # address is blacklisted using the blacklist command, all connections # originating from that address are disconnected. if the src-dst option # was also specified, then all connections to that address are also # disconnected. # # timeout=seconds # # Added in Shorewall 5.0.13. Normally, Shorewall creates the dynamic # blacklisting ipset with timeout 0 which means that entries are # permanent. If you want entries in the set that are not accessed for a # period of time to be deleted from the set, you may specify that period # using this option. Note that the blacklist command can override the # ipset's timeout setting. # # Important # # Once the dynamic blacklisting ipset has been created, changing this # option setting requires a complete restart of the firewall; shorewall # [-6] restart if RESTART=restart, otherwise shorewall [-6] [-l] stop && # shorewall [-6] [-l] start # # When ipset-based dynamic blacklisting is enabled, the contents of the # blacklist will be preserved over stop/reboot/start sequences if SAVE_IPSETS # =Yes, SAVE_IPSETS=ipv4 or if setname is included in the list of sets to be # saved in SAVE_IPSETS. # EXPAND_POLICIES=Yes # # EXPAND_POLICIES={Yes|No} # # Normally, when the SOURCE or DEST columns in shorewall-policy(5) contains # 'all', a single policy chain is created and thes policy is enforced in that # chain. For example, if the policy entry is # # #SOURCE DEST POLICY LOG # # LEVEL # net all DROP info # # then the chain name is 'net-all' ('net2all if ZONE2ZONE=2) which is also # the chain named in Shorewall log messages generated as a result of the # policy. If EXPAND_POLICIES=Yes, then Shorewall will create a separate chain # for each pair of zones covered by the policy. This makes the resulting log # messages easier to interpret since the chain in the messages will have a # name of the form 'a2b' where 'a' is the SOURCE zone and 'b' is the DEST # zone. # EXPORTMODULES=Yes # # EXPORTMODULES=[Yes|No] # # Added in Shorewall 4.4.17. When set to Yes when compiling for use by # Shorewall Lite (shorewall [-6] remote-start, shorewall [-6] remote-reload, # shorewall [-6] remote-restart or shorewall [-6] export commands), the # compiler will copy the modules or helpers file from the administrative # system into the script. When set to No or not specified, the compiler will # not copy the modules or helpers file from /usr/share/shorewall[6] but will # copy those found in another location on the CONFIG_PATH. # # When compiling for direct use by Shorewall, causes the contents of the # local module or helpers file to be copied into the compiled script. When # set to No or not set, the compiled script reads the file itself. # FASTACCEPT=No # # FASTACCEPT={Yes|No} # # Normally, Shorewall defers accepting ESTABLISHED/RELATED packets until # these packets reach the chain in which the original connection was # accepted. So for packets going from the 'loc' zone to the 'net' zone, # ESTABLISHED/RELATED packets are ACCEPTED in the 'loc-net' or 'loc2net' # chain, depending on the setting of ZONE2ZONE (see below). # # If you set FASTACCEPT=Yes, then ESTABLISHED/RELATED packets are accepted # early in the INPUT, FORWARD and OUTPUT chains. If you set FASTACCEPT=Yes # then you may not include rules in the ESTABLISHED or RELATED sections of # shorewall-rules(5). # FORWARD_CLEAR_MARK=Yes # # FORWARD_CLEAR_MARK={Yes|No} # # Added in Shorewall 4.4.11. Traditionally, Shorewall has cleared the packet # mark in the first rule in the mangle FORWARD chain. This behavior is # maintained with the default setting of this option (FORWARD_CLEAR_MARK= # Yes). If FORWARD_CLEAR_MARK is set to 'No', packet marks set in the mangle # PREROUTING chain are retained in the FORWARD chains. # HELPERS= # # HELPERS=[helper[,helper...]] # # Added in Shorewall 4.5.7. This option specifies a comma-separated list # naming the Netfilter application helpers that are to be enabled. If not # specified, the default is to enable all helpers. # # Possible values for helper are: # # â¡ amanda # # â¡ ftp # # â¡ h323 # # â¡ irc # # â¡ netbios-ns # # â¡ none - This special value was added in Shorewall 4.5.16 and indicates # that no helpers are to be enabled. It also prevents the compiler for # probing for helper support; such probing generates messages on the # system log of the form "xt_CT: No such helper XXX" where XXX is the # helper name. When used, none must be the only helper specified. # # â¡ pptp # # â¡ sane # # â¡ sip # # â¡ snmp # # â¡ tftp # # When HELPERS is specified on a system running Kernel 3.5.0 or later, # automatic association of helpers to connections is disabled. # IGNOREUNKNOWNVARIABLES=No # # IGNOREUNKNOWNVARIABLES=[Yes|No] # # Added in Shorewall 4.5.11. Normally, if an unknown shell variable is # encountered in a configuration file (except in ?IF and ?ELSIF directives), # the compiler raises a fatal error. If IGNOREUNKNOWNVARIABLES is set to Yes, # then such variables simply expand to an empty string. Default is No. # IMPLICIT_CONTINUE=No # # IMPLICIT_CONTINUE={Yes|No} # # When this option is set to Yes, it causes subzones to be treated # differently with respect to policies. # # Subzones are defined by following their name with ":" and a list of parent # zones (in shorewall-zones(5)). Normally, you want to have a set of special # rules for the subzone and if a connection doesn't match any of those # subzone-specific rules then you want the parent zone rules and policies to # be applied; see shorewall-nesting(5). With IMPLICIT_CONTINUE=Yes, that # happens automatically. # # If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set, then subzones # are not subject to this special treatment. With IMPLICIT_CONTINUE=Yes, an # implicit CONTINUE policy may be overridden by including an explicit policy # (one that does not specify "all" in either the SOURCE or the DEST columns). # IPSET_WARNINGS=Yes # # IPSET_WARNINGS={Yes|No} # # Added in Shorewall 4.5.2. Default is Yes. When set, causes the rules # compiler to issue a warning when: # # â¡ The compiler is being run by root and an ipset specified in the # configuration does not exists. Only one warning is issued for each # missing ipset. # # â¡ When [src] is specified in a destination column and when [dst] is # specified in a source column. # IP_FORWARDING=Keep # # IP_FORWARDING=[On|Off|Keep] # # This IPv4 parameter determines whether Shorewall enables or disables IPv4 # Packet Forwarding (/proc/sys/net/ipv4/ip_forward). In an IPv6 # configuration, this parameter determines the setting of /proc/sys/net/ipv6/ # config/all/ip_forwarding. # # Possible values are: # # On or on # # packet forwarding will be enabled. # # Off or off # # packet forwarding will be disabled. # # Keep or keep # # Shorewall will neither enable nor disable packet forwarding. # # If this variable is not set or is given an empty value (IP_FORWARD="") then # IP_FORWARD=On is assumed. # KEEP_RT_TABLES=Yes # # KEEP_RT_TABLES={Yes|No} # # IPv4: # # When set to Yes, this option prevents generated scripts from altering # the /etc/iproute2/rt_tables database when there are entries in /etc/ # shorewall/providers. If you set this option to Yes while Shorewall # (Shorewall-lite) is running, you should remove the file /var/lib/ # shorewall/rt_tables (/var/lib/shorewall-lite/rt_tables) before your # next stop, restore, reload or restart command. # # IPv6: # # When set to Yes, this option prevents scripts generated by Shorewall6 # from altering the /etc/iproute2/rt_tables database when there are # entries in /etc/shorewall6/providers. If you set this option to Yes # while Shorewall6 (Shorewall6-lite) is running, you should remove the # file /var/lib/shorewall6/rt_tables (/var/lib/shorewall6-lite/rt_tables) # before your next stop, restore, reload or restart command. # # Important # # When both IPv4 and IPv6 Shorewall configurations are present, # KEEP_RT_TABLES=No should be specified in only one of the two configurations # unless the two provider configurations are identical with respect to # interface and provider names and numbers. # # The default is KEEP_RT_TABLES=No. # MACLIST_TABLE=filter # # MACLIST_TABLE=[filter|mangle] # # Normally, MAC verification occurs in the filter table (INPUT and FORWARD) # chains. When forwarding a packet from an interface with MAC verification to # a bridge interface, that doesn't work. # # This problem can be worked around by setting MACLIST_TABLE=mangle which # will cause Mac verification to occur out of the PREROUTING chain. Because # REJECT isn't available in that environment, you may not specify # MACLIST_DISPOSITION=REJECT or MACLIST_DISPOSITION=A_REJECT with # MACLIST_TABLE=mangle. # MACLIST_TTL= # # MACLIST_TTL=[number] # # The performance of configurations with a large numbers of entries in # shorewall-maclist(5) can be improved by setting the MACLIST_TTL variable in # shorewall[6].conf(5). # # If your iptables and kernel support the "Recent Match" (see the output of # "shorewall check" near the top), you can cache the results of a 'maclist' # file lookup and thus reduce the overhead associated with MAC Verification. # # When a new connection arrives from a 'maclist' interface, the packet passes # through then list of entries for that interface in shorewall-maclist(5). If # there is a match then the source IP address is added to the 'Recent' set # for that interface. Subsequent connection attempts from that IP address # occurring within $MACLIST_TTL seconds will be accepted without having to # scan all of the entries. After $MACLIST_TTL from the first accepted # connection request from an IP address, the next connection request from # that IP address will be checked against the entire list. # # If MACLIST_TTL is not specified or is specified as empty (e.g, MACLIST_TTL= # "" or is specified as zero then 'maclist' lookups will not be cached). # MANGLE_ENABLED=Yes # # MANGLE_ENABLED=[Yes|No] # # Determines whether Shorewall will generate rules in the Netfilter mangle # table. Setting MANGLE_ENABLED=No disables all Shorewall features that # require the mangle table. The default is MANGLE_ENABLED=Yes. # MARK_IN_FORWARD_CHAIN=No # # MARK_IN_FORWARD_CHAIN=[Yes|No] # # If your kernel has a FORWARD chain in the mangle table, you may set # MARK_IN_FORWARD_CHAIN=Yes to cause the marking specified in the tcrules # file to occur in that chain rather than in the PREROUTING chain. This # permits you to mark inbound traffic based on its destination address when # DNAT is in use. To determine if your kernel has a FORWARD chain in the # mangle table, use the shorewall [-6] show mangle command; if a FORWARD # chain is displayed then your kernel will support this option. If this # option is not specified or if it is given the empty value (e.g., # MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed. # MINIUPNPD=No # # MINIUPNPD=[Yes|No] # # Added in Shorewall 5.0.8. If set to Yes, Shorewall will create a chain in # the nat table named MINIUPNPD-POSTROUTING and will add jumps from # POSTROUTING to that chain for each interface with the upnpd option # specified. Default is No. # MUTEX_TIMEOUT=60 # # MUTEX_TIMEOUT=[seconds] # # The value of this variable determines the number of seconds that programs # will wait for exclusive access to the Shorewall[6] lock file. After the # number of seconds corresponding to the value of this variable, programs # will assume that the last program to hold the lock died without releasing # the lock. # # If not set or set to the empty value, a value of 60 (60 seconds) is # assumed. # # An appropriate value for this parameter would be twice the length of time # that it takes your firewall system to process a shorewall [-6] restart # command. # OPTIMIZE=All # # OPTIMIZE=[value] # # The specified value enables certain optimizations. Each optimization # category is associated with a power of two. To enable multiple optimization # categories, simply add their corresponding numbers together. # # Beginning with Shorewall 4.5.20, you may specify OPTIMIZE=All to enable all # optimization categories, and you may also specify OPTIMIZE=None to disable # optimization. # # â¡ Optimization category 1 - Traditionally, Shorewall has created rules # for the complete matrix of host groups defined by the zones, interfaces # and hosts files. Any traffic that didn't correspond to an element of # that matrix was rejected in one of the built-in chains. When the matrix # is sparse, this results in lots of largely useless rules. # # These extra rules can be eliminated by setting the 1 bit in OPTIMIZE. # # The 1 bit setting also controls the suppression of redundant wildcard # rules (those specifying "all" in the SOURCE or DEST column). A wildcard # rule is considered to be redundant when it has the same ACTION and Log # Level as the applicable policy. # # Note # # Optimization level 1 is ignored when optimization level 4 is also # selected, since level 4 performs similar optimizations in a more robust # way. # # â¡ Optimization category 2 - Added in Shorewall 4.4.7. When set, # suppresses superfluous ACCEPT rules in a policy chain that implements # an ACCEPT policy. Any ACCEPT rules that immediately precede the final # blanket ACCEPT rule in the chain are now omitted. # # â¡ Optimization category 4 - Added in Shorewall 4.4.7. When set, causes # short chains (those with less than 2 rules) to be optimized away. The # following chains are excluded from optimization: # # â accounting chains (unless OPTIMIZE_ACCOUNTING=Yes) # # â action chains (user-defined) # # â 'blacklst' chain # # â dynamic # # â forwardUPnP # # â UPnP (nat table) # # Additionally: # # â If a built-in chain has a single rule that branches to a second # chain, then the rules from the second chain are moved to the # built-in chain and the target chain is omitted. # # â Chains with no references are deleted. # # â Accounting chains are subject to optimization if the # OPTIMIZE_ACCOUNTING option is set to 'Yes'. # # â If a chain ends with an unconditional branch to a second chain # (other than to 'reject'), then the branch is deleted from the first # chain and the rules from the second chain are appended to it. # # An additional optimization was added in Shorewall 4.5.4. If the last # rule in a chain is an unqualified jump to a simple target, then all # immediately preceding rules with the same simple target are omitted. # # For example, consider this chain: # # -A fw-net -p udp --dport 67:68 -j ACCEPT # -A fw-net -p udp --sport 1194 -j ACCEPT # -A fw-net -p 41 -j ACCEPT # -A fw-net -j ACCEPT # # Since all of the rules are jumps to the simple target ACCEPT, this # chain is totally optimized away and jumps to the chain are replace with # jumps to ACCEPT. # # â¡ Optimization category 8 - Added in Shorewall 4.4.9. When set, causes # chains with identical rules to be collapsed into a single chain. # # Warning # # While Optimization category 8 can significantly reduce the size of the # generated iptables ruleset, it can also take significant system # resources during compilation. If you find that compilation takes an # unreasonably long time, try disabling this category by setting OPTIMIZE # =23. # # â¡ Optimization category 16 - Added in Shorewall 4.4.26. When set, causes # sequences of compatible rules to be combined into a single rule. Rules # are considered compatible if they differ only in their destination # ports and comments. # # A sequence of compatible rules is often generated when macros are # invoked in sequence. # # The ability to combine adjacent rules is limited by two factors: # # â Destination port lists may only be combined up to a maximum of 15 # ports, where a port-pair counts as two ports. # # â Rules may only be combined until the length of their concatenated # comment reaches 255 characters. # # When either of these limits would be exceeded, the current combined # rule is emitted and the compiler attempts to combine rules beginning # with the one that would have exceeded the limit. Adjacent combined # comments are separated by ', '. Empty comments at the front of a group # of combined comments are replaced by 'Others and'. Empty comments at # the end of a group of combined comments are replaced by 'and others'. # # Beginning in Shorewall 4.5.10, this option also suppresses duplicate # adjacent rules and duplicate non-adjacent rules that don't include mark # , connmark, dscp, ecn, set, tos or u32 matches. # # Example 1: # # Rules with comments "FOO", <empty> and "BAR" would result in the # combined comment "FOO and others, BAR". # # Example 2: # # Rules with comments <empty>, "FOO" and "BAR" would result in the # combined comment "Others and FOO, BAR". Note: Optimize level 16 # requires "Extended Multi-port Match" in your iptables and kernel. # # In versions prior to 5.1.0, the default value is zero which disables all # optimizations. Beginning with Shorewall 5.1.0, the default value is All # which enables all optimizations. # OPTIMIZE_ACCOUNTING=No # # OPTIMIZE_ACCOUNTING=[Yes|No] # # Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting changes are # subject to optimization (OPTIMIZE=4,5,6 or 7). If not specified or set to # the empty value, OPTIMIZE_ACCOUNTING=No is assumed. # PERL_HASH_SEED=0 # # PERL_HASH_SEED=seed|random # # Added in Shorewall 5.1.4. Sets the Perl hash seed (an integer in the range # 0-99999) when running the Shorewall rules compiler. If not specified, the # value 0 is assumed. If random is specified, a random seed will be chosed by # Perl. See perlsec(1) for additional information. # REJECT_ACTION= # # REJECT_ACTION=action # # Added in Shorewall 4.5.21. When a REJECT target is specified, Shorewall # normally handles the response as follows: # # â¡ If the destination address of the packet is a broadcast or multicast # address, the packet is dropped. # # â¡ if the protocol is ICMP (2) then the packet is dropped. # # â¡ if the protocol is TCP (6) then the packet is rejected with an RST. # # â¡ if the protocol is UDP (17) then the packet is rejected with an # 'port-unreachable' ICMP. # # â¡ if the protocol is ICMP (1) then the packet is rejected with a # 'host-unreachable' ICMP. # # â¡ if the protocol is ICMP6 (1) then the packet is rejected with a # 'icmp6-addr-unreachable' ICMP6. # # â¡ otherwise, the packet is rejected with a 'host-prohibited' ICMP. # # You can modify this behavior by implementing your own action that handles # REJECT and specifying it's name in this option. The nolog and noinline # options will automatically be assumed for the specified action. # # The following action implements the default reject action: # # ?format 2 # #TARGET SOURCE DEST PROTO # Broadcast(DROP) - - - # DROP - - 2 # INLINE - - 6 ;; -j REJECT --reject-with tcp-reset # ?if __ENHANCED_REJECT # INLINE - - 17 ;; -j REJECT # ?if __IPV4 # INLINE - - 1 ;; -j REJECT --reject-with icmp-host-unreachable # INLINE - - - ;; -j REJECT --reject-with icmp-host-prohibited # ?else # INLINE - - 58 ;; -j REJECT --reject-with icmp6-addr-unreachable # INLINE - - - ;; -j REJECT --reject-with icmp6-adm-prohibited # ?endif # ?else # INLINE - - - ;; -j REJECT # ?endif # RENAME_COMBINED=Yes # # RENAME_COMBINED=[Yes|No] # # Added in Shorewall 5.2.0. Traditionally, when OPTIMIZE category 8 is # enabled, identical chains are combined under a name beginning with '~comb' # or '~blacklist'. This behavior is maintained under the default setting # RENAME_COMBINED=Yes. If RENAMED_COMBINED=No, the chains are combined under # the original name of one of the chains. # REQUIRE_INTERFACE=No # # REQUIRE_INTERFACE=[Yes|No] # # Added in Shorewall 4.4.10. The default is No. If set to Yes, at least one # optional interface must be up in order for the firewall to be in the # started state. Intended to be used with the Shorewall Init Package. # RESTART=restart # # RESTART=[restart|reload] # # Added in Shorewall 5.0.1 to replace LEGACY_RESTART which was added in # Shorewall 5.0.0. In that release, the reload command was redefined to do # what restart had done in earlier releases and restart became a true restart # (equivalent to stop followed by start). When RESTART=reload, the restart # command performs the same operation as the reload command making it # compatible with earlier releases. If not specified, RESTART=reload is # assumed. # RESTORE_DEFAULT_ROUTE=Yes # # RESTORE_DEFAULT_ROUTE=[Yes|No] # # This option determines whether to restore the default route saved when here # are 'balance' providers defined but all of them are down. # # The default is RESTORE_DEFAULT_ROUTE=Yes which preserves the pre-4.2.6 # behavior. # # RESTORE_DEFAULT_ROUTE=No is appropriate when you don't want a default route # in the main table (USE_DEFAULT_RT=No) or in the default table # (USE_DEFAULT_RT=Yes) when there are no balance providers available. In that # case, RESTORE_DEFAULT_ROUTE=No will cause any default route in the relevant # table to be deleted. # RESTORE_ROUTEMARKS=Yes # # RESTORE_ROUTEMARKS=[Yes|No] # # Added in Shorewall 4.5.9. When set to Yes (the default), provider marks are # restored unconditionally at the top of the mangle OUTPUT and PREROUTING # chains, even if the saved mark is zero. When this option is set to No, the # mark is restored only if it is non-zero. If you have problems with IPSEC # ESP packets not being routed correctly on output, try setting this option # to No. # SAVE_IPSETS=No # # SAVE_IPSETS={Yes|No|ipv4|setlist} # # Re-enabled in Shorewall 4.4.6. If SAVE_IPSETS=Yes, then the current # contents of your ipsets will be saved by the shorewall stop and shorewall # save commands and restored by the shorewall start and shorewall restore # commands. # # Beginning with Shorewall 4.6.4, you can restrict the set of ipsets saved by # specifying a setlist (a comma-separated list of ipv4 ipset names). You may # also restrict the saved sets to just the ipv4 ones by specifying ipv4. # TC_ENABLED=Shared # # TC_ENABLED=[Yes|No|Internal|Simple|Shared] # # If you say Yes or yes here, Shorewall will use a script that you supply to # configure traffic shaping. The script must be named 'tcstart' and must be # placed in a directory on your CONFIG_PATH. # # If you say No or no then traffic shaping is not enabled. # # If you set TC_ENABLED=Simple (Shorewall 4.4.6 and later), simple traffic # shaping using shorewall-tcinterfaces(5) and shorewall-tcpri(5) is enabled. # # If you set TC_ENABLED=Internal or internal or leave the option empty then # Shorewall will use its builtin traffic shaper (tc4shorewall written by Arne # Bernin. # # Beginning with Shorewall 4.4.15, you can set TC_ENABLED=Shared. This allows # you to configure the tcdevices and tcclasses in your Shorewall6 # configuration yet make them available to the compiler when compiling your # Shorewall configuration. In addition to setting TC_ENABLED=Shared, you need # to create symbolic links from your Shorewall configuration directory # (normally /etc/shorewall/) to the tcdevices and tcclasses files in your # Shorewall6 configuration directory (normally /etc/shorewall6/). # TC_EXPERT=No # # TC_EXPERT={Yes|No} # # Normally, Shorewall tries to protect users from themselves by preventing # PREROUTING and OUTPUT tcrules from being applied to packets that have been # marked by the 'track' option in shorewall-providers(5). # # If you know what you are doing, you can set TC_EXPERT=Yes and Shorewall # will not include these cautionary checks. # TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2" # # TC_PRIOMAP=map # # Added in Shorewall 4.4.6. Determines the mapping of a packet's TOS field to # priority bands. See shorewall-tcpri(5). The map consists of 16 # space-separated digits with values 1, 2 or 3. A value of 1 corresponds to # Linux priority 0, 2 to Linux priority 1, and 3 to Linux Priority 2. The # first entry gives the priority of TOS value 0, the second of TOS value 1, # and so on. See tc-prio(8) for additional information. # # The default setting is TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2". # TRACK_PROVIDERS=Yes # # TRACK_PROVIDERS={Yes|No} # # Added in Shorewall 4.4.3. When set to Yes, causes the track option to be # assumed on all providers defined in shorewall-providers(5). May be # overridden on an individual provider through use of the notrack option. The # default value is 'No'. # # Beginning in Shorewall 4.4.6, setting this option to 'Yes' also simplifies # PREROUTING rules in shorewall-tcrules(5). Previously, when TC_EXPERT=No, # packets arriving through 'tracked' provider interfaces were unconditionally # passed to the PREROUTING tcrules. This was done so that tcrules could reset # the packet mark to zero, thus allowing the packet to be routed using the # 'main' routing table. Using the main table allowed dynamic routes (such as # those added for VPNs) to be effective. The rtrules file was created to # provide a better alternative to clearing the packet mark. As a consequence, # passing these packets to PREROUTING complicates things without providing # any real benefit. Beginning with Shorewall 4.4.6, when TRACK_PROVIDERS=Yes # and TC_EXPERT=No, packets arriving through 'tracked' interfaces will not be # passed to the PREROUTING rules. Since TRACK_PROVIDERS was just introduced # in 4.4.3, this change should be transparent to most, if not all, users. # TRACK_RULES=No # # TRACK_RULES={Yes|No|File} # # Added in Shorewall 4.5.20. If set to Yes, causes the compiler to add a # comment to iptables rules to indicate the file name and line number of the # configuration entry that generated the rule. If set to No (the default), # then no such comments are added. # # Setting this option to Yes requires the Comments capability in iptables and # kernel. # # Beginning with Shorewall 5.0.5, the option may also be set to File. That # setting causes similar comments to be added to the .iptables-restore-input # file, which is normally created in /var/lib/shorewall. # USE_DEFAULT_RT=Yes # # USE_DEFAULT_RT=[Yes|No] # # When set to 'Yes', this option causes the Shorewall multi-ISP feature to # create a set of routing rules which are resilient to changes in the main # routing table. Such changes can occur for a number of reasons, VPNs going # up and down being an example. The idea is to send packets through the main # table prior to applying any of the Shorewall-generated routing rules. So # changes to the main table will affect the routing of packets by default. # # When USE_DEFAULT_RT=Yes: # # 1. Both the DUPLICATE and the COPY columns in providers(5) file must # remain empty (or contain "-"). # # 2. The default route is added to the the 'default' table rather than to # the main table. # # 3. If running Shorewall 5.1.0 or earlier or if BALANCE_PROVIDERS=Yes # (Shorewall 5.1.1 or later), then the balance provider option is assumed # unless the fallback, loose, load or tproxy option is specified. # # 4. Packets are sent through the main routing table by a rule with priority # 999. In shorewall-rtrules(5), the range 1-998 may be used for inserting # rules that bypass the main table. # # 5. All provider gateways must be specified explicitly in the GATEWAY # column. detect may not be specified. # # Note # # detect may be specified for interfaces whose configuration is managed # by dhcpcd. Shorewall will use dhcpcd's database to find the interface's # gateway. # # 6. You should disable all default route management outside of Shorewall. # If a default route is added to the main table while Shorewall is # started, then all policy routing will stop working (except for those # routing rules in the priority range 1-998). # # Prior to Shorewall 4.6.0, if USE_DEFAULT_RT was not set or if it was set to # the empty string then USE_DEFAULT_RT=No was assumed. Beginning with # Shorewall 4.6.0, the default is USE_DEFAULT_RT=Yes and use of # USE_DEFAULT_RT=No is deprecated. # # Warning # # The enable, disable and reenable commands do not work correctly when # USE_DEFAULT_RT=No. # USE_NFLOG_SIZE=No # # USE_NFLOG_SIZE=[Yes|No] # # Added in Shorewall 5.1.5. The second parameter to the NFLOG target # specifies how many bytes of the packet to copy to the log; if omitted or if # supplied as zero, the entire packet is copied. This feature has # traditionally been implemented using the --nflog-range option to the NFLOG # iptables target. Unfortuntely, the --nflog-range option never worked (the # entire packet was always copied). To deal with this issue, the Netfilter # team: # # â¡ Added a warning message when --nflog-range is used # # â¡ Added --nflog-size which works like --nflog-range was intended to work. # # When USE_NFLOG_SIZE=Yes, Shorewall will attempt to use the new --nflog-size # feature. If that feature is not available in the running kernel and ip[6] # tables, an error is raised. # # When USE_NFLOG_SIZE is not supplied, USE_NFLOG_SIZE=No is assumed. When # USE_NFLOG_SIZE is added by shorewall update, it is added with setting No. # USE_PHYSICAL_NAMES=No # # USE_PHYSICAL_NAMES=[Yes|No] # # Added in Shorewall 4.4.27. Normally, when Shorewall creates a Netfilter # chain that relates to an interface, it uses the interface's logical name as # the base of the chain name. For example, if the logical name for an # interface is OAKLAND, then the input chain for traffic arriving on that # interface would be 'OAKLAND_in'. If this option is set to Yes, then the # physical name of the interface will be used the base of the chain name. # USE_RT_NAMES=No # # USE_RT_NAMES=[Yes|No] # # Added in Shorewall 4.5.15. When set to 'Yes', Shorewall will use routing # table (provider) names in the generated script rather than table numbers. # When set to 'No' (the default), routing table numbers will be used. # # Caution # # If you set USE_RT_NAMES=Yes and KEEP_RT_TABLES=Yes, then you must insure # that all of your providers have entries in /etc/iproute2/rt_tables as well # as the following entries: # # 255 local # 254 main # 253 default # 250 balance # 0 unspec # # Without these entries, the firewall will fail to start. # VERBOSE_MESSAGES=Yes # # VERBOSE_MESSAGES=[Yes|No] # # Added in Shorewall 5.0.9. When Yes (the default), messages produced by the # ?INFO and ?WARNING directives include the filename and linenumber of the # directive. When set to No, that additional information is omitted. The # setting may be overridden on a directive by directive basis by following ? # INFO or ?WARNING with '!' (no intervening white space). # WARNOLDCAPVERSION=Yes # # WARNOLDCAPVERSION=[Yes|No] # # Added in Shorewall 4.5.12. When set to Yes (the default), the compiler # issues a warning when it finds a capabilities file that doesn't specify all # of the capabilities supported by the compiler. When WARNOLDCAPVERSION is # set to No, no warning is issued. # WORKAROUNDS=No # # WORKAROUNDS=[Yes|No] # # Added in Shorewall 4.6.11. Over time, there have been a number of changes # in Shorewall that work around defects in other products such as iptables # and ipset. When WORKAROUNDS=Yes, these workarounds are enabled; when # WORKAROUNDS=No, they are disabled. If not specified or if specified as # empty, WORKAROUNDS=Yes is assumed. # # Warning # # Do not set WORKAROUNDS=Yes if you need to be able to use # Shorewall-generated scripts (such as created by the save command) built by # Shorewall 4.4.7 or older. # ZERO_MARKS=No # # ZERO_MARKS=[Yes|No] # # Added in Shorewall 5.0.12, this is a workaround for an issue where packet # marks are not zeroed by the kernel. It should be set to No (the default) # unless you find that incoming packets are being mis-routed for no apparent # reasons. # # Caution # # Do not set this option to Yes if you have IPSEC software running on the # firewall system. # ZONE2ZONE=- # # ZONE2ZONE=[2|-] # # Added in Shorewall 4.4.4. This option determines how Shorewall constructs # chain names involving zone names and/or 'all'. Beginning with Shorewall # 4.6.0, the default is '-' (e.g., fw-net); prior to that release, the # default was '2' (e.g., fw2net). # ############################################################################### # P A C K E T D I S P O S I T I O N ############################################################################### BLACKLIST_DISPOSITION=DROP # # BLACKLIST_DISPOSITION=[DROP|A_DROP|REJECT|A_REJECT] # # This parameter determines the disposition of packets from blacklisted # hosts. It may have the value DROP if the packets are to be dropped or # REJECT if the packets are to be replied with an ICMP port unreachable reply # or a TCP RST (tcp only). If you do not assign a value or if you assign an # empty value then DROP is assumed. # # A_DROP and A_REJECT are audited versions of DROP and REJECT respectively # and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel # and iptables. # # The BLACKLIST_DISPOSITION setting determines the disposition of packets # sent to the blacklog target of shorewall-blrules (5), but otherwise does # not affect entries in that file. # INVALID_DISPOSITION=CONTINUE # # INVALID_DISPOSITION=[A_DROP|A_REJECT|DROP|REJECT|CONTINUE] # # Added in Shorewall 4.5.13. Shorewall has traditionally passed INVALID # packets through the NEW section of shorewall-rules (5). When a packet in # INVALID state fails to match any rule in the INVALID section, the packet is # disposed of based on this setting. The default value is CONTINUE for # compatibility with earlier versions. # MACLIST_DISPOSITION=REJECT # # MACLIST_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT] # # Determines the disposition of connections requests that fail MAC # Verification and must have the value ACCEPT (accept the connection request # anyway), REJECT (reject the connection request) or DROP (ignore the # connection request). If not set or if set to the empty value (e.g., # MACLIST_DISPOSITION="") then MACLIST_DISPOSITION=REJECT is assumed. # # A_DROP and A_REJECT are audited versions of DROP and REJECT respectively # and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel # and ip[6]tables. # RELATED_DISPOSITION=ACCEPT # # RELATED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE] # # Added in Shorewall 4.4.27. Shorewall has traditionally ACCEPTed RELATED # packets that don't match any rule in the RELATED section of shorewall-rules # (5). Concern about the safety of this practice resulted in the addition of # this option. When a packet in RELATED state fails to match any rule in the # RELATED section, the packet is disposed of based on this setting. The # default value is ACCEPT for compatibility with earlier versions. # SFILTER_DISPOSITION=DROP # # SFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT] # # Added in Shorewall 4.4.20. Determines the disposition of packets matching # the sfilter option (see shorewall-interfaces(5)) and of hairpin packets on # interfaces without the routeback option.^[1] # RPFILTER_DISPOSITION=DROP # # RPFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT] # # Added in Shorewall 4.5.7. Determines the disposition of packets entering # from interfaces the rpfilter option (see shorewall-interfaces(5)). Packets # disposed of by this option are those whose response packets would not be # sent through the same interface receiving the packet. # SMURF_DISPOSITION=DROP # # SMURF_DISPOSITION=[DROP|A_DROP] # # Added in Shorewall 4.4.20. The default setting is DROP which causes smurf # packets (see the nosmurfs option in shorewall-interfaces(5)) to be dropped. # A_DROP causes the packets to be audited prior to being dropped and requires # AUDIT_TARGET support in the kernel and iptables. # TCP_FLAGS_DISPOSITION=DROP # # TCP_FLAGS_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT] # # Determines the disposition of TCP packets that fail the checks enabled by # the tcpflags interface option (see shorewall-interfaces(5)) and must have a # value of ACCEPT (accept the packet), REJECT (send an RST response) or DROP # (ignore the packet). If not set or if set to the empty value (e.g., # TCP_FLAGS_DISPOSITION="") then TCP_FLAGS_DISPOSITION=DROP is assumed. # # A_DROP and A_REJECT are audited versions of DROP and REJECT respectively # and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel # and iptables. # UNTRACKED_DISPOSITION=CONTINUE # # UNTRACKED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE] # # Added in Shorewall 4.5.13. Shorewall has traditionally passed UNTRACKED # packets through the NEW section of shorewall-rules (5). When a packet in # UNTRACKED state fails to match any rule in the UNTRACKED section, the # packet is disposed of based on this setting. The default value is CONTINUE # for compatibility with earlier versions. # ################################################################################ # P A C K E T M A R K L A Y O U T ################################################################################ TC_BITS= # # TC_BITS=[number] # # The number of bits at the low end of the 32-bit packet mark to be used for # traffic shaping marking. May be zero. See MASK_BITS above for default # value. # PROVIDER_BITS= # # PROVIDER_BITS=[number] # # Added in Shorewall 4.4.26. The number of bits in the 32-bit packet mark to # be used for provider numbers. May be zero. See MASK_BITS above for default # value. # PROVIDER_OFFSET= # # PROVIDER_OFFSET=[number]If # # Added in Shorewall 4.4.26. The offset from the right (low-order end) of the # provider number field in the 32-bit packet mark. If non-zero, must be >= # TC_BITS (Shorewall automatically adjusts PROVIDER_OFFSET's value). # PROVIDER_OFFSET + PROVIDER_BITS + ZONE_BITS must be < 32. See MASK_BITS # above for default value. # MASK_BITS= # # MASK_BITS=[number] # # Added in Shorewall 4.4.26. Number of bits on the right of the 32-bit packet # mark to be masked when clearing the traffic shaping mark. Must be >= # TC_BITS and <= PROVIDER_OFFSET (if PROVIDER_OFFSET > 0). Prior to Shorewall # 5.0.0, default value and the default values of the other mark layout # options is determined as follows: # # Table 1. Default Packet Mark Layout # # WIDE_TC_MARKS=No, TC_BITS=8, PROVIDER_BITS=8, PROVIDER_OFFSET= # HIGH_ROUTE_MARKS=No 0, MASK_BITS=8 # WIDE_TC_MARKS=No, TC_BITS=8, PROVIDER_BITS=8, PROVIDER_OFFSET= # HIGH_ROUTE_MARKS=Yes 8, MASK_BITS=8 # WIDE_TC_MARKS=Yes, TC_BITS=14, PROVIDER_BITS=8, PROVIDER_OFFSET= # HIGH_ROUTE_MARKS=No 0, MASK_BITS=16 # WIDE_TC_MARKS=Yes, TC_BITS=14, PROVIDER_BITS=8, PROVIDER_OFFSET= # HIGH_ROUTE_MARKS=Yes 16, MASK_BITS=16 # # # From 5.0.0 onward, the default value of MASK_BITS is 8, the default value # of PROVIDER_BITS, TC_BITS, MASK_BITS and PROVIDER_OFFSET is 8. # ZONE_BITS=0 # # ZONE_BITS=[number] # # Added in Shorewall 4.4.26. When non-zero, enables automatic packet marking # by source zone and determines the number of bits in the 32-bit packet mark # to be used for the zone mark. Default value is 0. #