############################################################################## # /etc/shorewall/shorewall.conf V2.4 - Change the following variables to # match your setup # # This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] # # This file should be placed in /etc/shorewall # # (c) 1999,2000,2001,2002,2003,2004,2005 - Tom Eastep (teastep@shorewall.net) ############################################################################## # 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 ############################################################################## # L O G G I N G ############################################################################## # # General note about log levels. Log levels are a method of describing # to syslog (8) the importance of a message and a number of parameters # in this file have log levels as their value. # # These levels are defined by syslog and are used to determine the destination # of the messages through entries in /etc/syslog.conf (5). The syslog # documentation refers to these as "priorities"; Netfilter calls them "levels" # and Shorewall also uses that term. # # Valid levels are: # # 7 debug # 6 info # 5 notice # 4 warning # 3 err # 2 crit # 1 alert # 0 emerg # # For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall # log messages are generated by NetFilter and are logged using facility # 'kern' and the level that you specifify. If you are unsure of the level # to choose, 6 (info) is a safe bet. You may specify levels by name or by # number. # # If you have built your kernel with ULOG target support, you may also # specify a log level of ULOG (must be all caps). Rather than log its # messages to syslogd, Shorewall will direct netfilter to log the messages # via the ULOG target which will send them to a process called 'ulogd'. # ulogd is available with most Linux distributions (although it probably isn't # installed by default). Ulogd is also available from # http://www.gnumonks.org/projects/ulogd and can be configured to log all # Shorewall message to their own log file ################################################################################ # # LOG FILE LOCATION # # This variable tells the /sbin/shorewall program where to look for Shorewall # log messages. If not set or set to an empty string (e.g., LOGFILE="") then # /var/log/messages is assumed. # # WARNING: The LOGFILE variable simply tells the 'shorewall' program where to # look for Shorewall messages.It does NOT control the destination for # these messages. For information about how to do that, see # # http://www.shorewall.net/shorewall_logging.html LOGFILE=/var/log/messages # # LOG FORMAT # # Shell 'printf' Formatting template for the --log-prefix value in log messages # generated by Shorewall to identify Shorewall log messages. The supplied # template is expected to accept either two or three arguments; the first is # the chain name, the second (optional) is the logging rule number within that # chain and the third is the ACTION specifying the disposition of the packet # being logged. You must use the %d formatting type for the rule number; if your # template does not contain %d then the rule number will not be included. # # If you want to integrate Shorewall with fireparse, then set LOGFORMAT as: # # LOGFORMAT="fp=%s:%d a=%s " # # If not specified or specified as empty (LOGFORMAT="") then the value # "Shorewall:%s:%s:" is assumed. # # CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT string (up # to but not including the first '%') to find log messages in the 'show log', # 'status' and 'hits' commands. This part should not be omitted (the # LOGFORMAT should not begin with "%") and the leading part should be # sufficiently unique for /sbin/shorewall to identify Shorewall messages. LOGFORMAT="Shorewall:%s:%s:" # # LOG FORMAT Continued # # Using the default LOGFORMAT, chain names may not exceed 11 characters or # truncation of the log prefix may occur. Longer chain names may be used with # log tags if you set LOGTAGONLY=Yes. With LOGTAGONLY=Yes, if a log tag is # specified then the tag is included in the log prefix in place of the chain # name. # LOGTAGONLY=No # # LOG RATE LIMITING # # The next two variables can be used to control the amount of log output # generated. LOGRATE is expressed as a number followed by an optional # `/second', `/minute', `/hour', or `/day' suffix and specifies the maximum # rate at which a particular message will occur. LOGBURST determines the # maximum initial burst size that will be logged. If set empty, the default # value of 5 will be used. # # If BOTH variables are set empty then logging will not be rate-limited. # # Example: # # LOGRATE=10/minute # LOGBURST=5 # # For each logging rule, the first time the rule is reached, the packet # will be logged; in fact, since the burst is 5, the first five packets # will be logged. After this, it will be 6 seconds (1 minute divided by # the rate of 10) before a message will be logged from the rule, regardless # of how many packets reach it. Also, every 6 seconds which passes without # matching a packet, one of the bursts will be regained; if no packets hit # the rule for 30 seconds, the burst will be fully recharged; back where # we started. # LOGRATE= LOGBURST= # # LOG ALL NEW # # This option should only be used when you are trying to analyze a problem. # It causes all packets in the Netfilter NEW state to be logged as the # first rule in each builtin chain. To use this option, set LOGALLNEW to # the log level that you want these packets logged at (e.g., # LOGALLNEW=debug). # LOGALLNEW= # # BLACKLIST LOG LEVEL # # Set this variable to the syslogd level that you want blacklist packets logged # (beware of DOS attacks resulting from such logging). If not set, no logging # of blacklist packets occurs. # # See the comment at the top of this section for a description of log levels # BLACKLIST_LOGLEVEL= # # LOGGING 'New not SYN' rejects # # This variable only has an effect when NEWNOTSYN=No (see below). # # When a TCP packet that does not have the SYN flag set and the ACK and RST # flags clear then unless the packet is part of an established connection, # it will be rejected by the firewall. If you want these rejects logged, # then set LOGNEWNOTSYN to the syslog log level at which you want them logged. # # See the comment at the top of this section for a description of log levels # # Example: LOGNEWNOTSYN=debug LOGNEWNOTSYN=info # # MAC List Log Level # # Specifies the logging level for connection requests that fail MAC # verification. If set to the empty value (MACLIST_LOG_LEVEL="") then # such connection requests will not be logged. # # See the comment at the top of this section for a description of log levels # MACLIST_LOG_LEVEL=info # # TCP FLAGS Log Level # # Specifies the logging level for packets that fail TCP Flags # verification. If set to the empty value (TCP_FLAGS_LOG_LEVEL="") then # such packets will not be logged. # # See the comment at the top of this section for a description of log levels # TCP_FLAGS_LOG_LEVEL=info # # RFC1918 Log Level # # Specifies the logging level for packets that fail RFC 1918 # verification. If set to the empty value (RFC1918_LOG_LEVEL="") then # RFC1918_LOG_LEVEL=info is assumed. # # See the comment at the top of this section for a description of log levels # RFC1918_LOG_LEVEL=info # # SMURF Log Level # # Specifies the logging level for smurf packets dropped by the #'nosmurfs' interface option in /etc/shorewall/interfaces and in # /etc/shorewall/hosts. If set to the empty value ( SMURF_LOG_LEVEL="" # ) then dropped smurfs are not logged. # # See the comment at the top of this section for a description of log levels # SMURF_LOG_LEVEL=info # # BOGON Log Level # # Specifies the logging level for bogon packets dropped by the #'nobogons' interface option in /etc/shorewall/interfaces and in # /etc/shorewall/hosts. If set to the empty value # ( BOGON_LOG_LEVEL="" ) then packets whose TARGET is 'logdrop' # in /usr/share/shorewall/bogons are logged at the 'info' level. # # See the comment at the top of this section for a description of log levels # BOGON_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 # # SHOREWALL TEMPORARY STATE DIRECTORY # # This is the directory where the firewall maintains state information while # it is running # STATEDIR=/var/lib/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=""), # CONFIG_PATH=/etc/shorewall:/usr/share/shorewall is assumed. 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= ################################################################################ # F I R E W A L L O P T I O N S ################################################################################ # NAME OF THE FIREWALL ZONE # # Name of the firewall zone -- if not set or if set to an empty string, "fw" # is assumed. # FW=fw # # 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. # 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!!! # 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, Traffic Shaping is enabled in the firewall. If # you say "No" or "no" then traffic shaping is not enabled. If you enable traffic # shaping you must have iproute[2] installed (the "ip" and "tc" utilities). TC_ENABLED=No # # Clear Traffic Shapping/Control # # If this option is set to 'No' then Shorewall won't clear the current # traffic control rules during [re]start. This setting is intended # for use by people that prefer to configure traffic shaping when # the network interfaces come up rather than when the firewall # is started. If that is what you want to do, set TC_ENABLED=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 /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 # # NEWNOTSYN # # TCP connections are established using the familiar three-way "handshake": # # CLIENT SERVER # # SYN--------------------> # <------------------SYN,ACK # ACK--------------------> # # The first packet in that exchange (packet with the SYN flag on and the ACK # and RST flags off) is referred to in Netfilter terminology as a "syn" packet. # A packet is said to be NEW if it is not part of or related to an already # established connection. # # The NEWNOTSYN option determines the handling of non-SYN packets (those with # SYN off or with ACK or RST on) that are not associated with an already # established connection. # # If NEWNOTSYN is set to "No" or "no", then non-SYN packets that are not # part of an already established connection will be dropped by the # firewall. The setting of LOGNEWNOTSYN above determines if these packets are # logged before they are dropped. # # If NEWNOTSYN is set to "Yes" or "yes" then such packets will not be # dropped but will pass through the normal rule/policy processing. # # Users with a High-availability setup with two firewall's and one acting # as a backup should set NEWNOTSYN=Yes. Users with asymmetric routing may # also need to select NEWNOTSYN=Yes. # # The behavior of NEWNOTSYN=Yes may also be enabled on a per-interface basis # using the 'newnotsyn' option in /etc/shorewall/interfaces and on a # network or host basis using the same option in /etc/shorewall/hosts. # # I find that NEWNOTSYN=No tends to result in lots of "stuck" # connections because any network timeout during TCP session tear down # results in retries being dropped (Netfilter has removed the # connection from the conntrack table but the end-points haven't # completed shutting down the connection). I therefore have chosen # NEWNOTSYN=Yes as the default value. NEWNOTSYN=Yes # # 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 control traffic 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 # # DROP INVALID PACKETS # # Netfilter classifies packets relative to its connection tracking table into # four states: # # NEW - thes packet initiates a new connection # ESTABLISHED - thes packet is part of an established connection # RELATED - thes packet is related to an established connection; it may # establish a new connection # INVALID - the packet does not related to the table in any sensible way. # # Recent 2.6 kernels include code that evaluates TCP packets based on TCP # Window analysis. This can cause packets that were previously classified as # NEW or ESTABLISHED to be classified as INVALID. # # The new kernel code can be disabled by including this command in your # /etc/shorewall/init file: # # echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal # # Additional kernel logging about INVALID TCP packets may be obtained by # adding this command to /etc/shorewall/init: # # echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid # # Traditionally, Shorewall has dropped INVALID TCP packets early. The DROPINVALID # option allows INVALID packets to be passed through the normal rules chains by # setting DROPINVALID=No. # # If not specified or if specified as empty (e.g., DROPINVALID="") then # DROPINVALID=Yes is assumed. DROPINVALID=No # # 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 # # 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 then 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 # # CROSSBEAM SUPPORT # # If Shorewall is running in a Crossbeam System (www.crossbeamsystems.com) you need # to activate this directive if you don't want the CPM to think the system is down # and send a reset signal. Also Crossbeam has a backplane chassis that needs to be # configured in such a way that accepts all traffic. # # If CROSSBEAM=Yes, then during a Shorewall start, restart or clear instead of # setting the default policies to DROP and then activating established connections, # Shorewall will first set the default policies to ACCEPT, activate established # connections and then set the default policies to DROP. After that, Shorewall starts # generating the rules as usual. # # If CROSSBEAM=No, CROSSBEAM_BACKBONE is not used. If CROSSBEAM is set to Yes, # CROSSBEAM_BACKBONE will indicate the device used by the backbone. # # If not specified or if specified as empty (e.g., CROSSBEAM="") then # CROSSBEAM=No is assumed. CROSSBEAM=No CROSSBEAM_BACKBONE=eth0 ################################################################################ # 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