mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-12 18:54:25 +01:00
Removed shorewall.conf from one interface samples for consistancy
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@434 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
frannie
parent
62facaa1f5
commit
3f15670923
@ -1,526 +0,0 @@
|
||||
##############################################################################
|
||||
# /etc/shorewall/shorewall.conf V1.3 - 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 - Tom Eastep (teastep@shorewall.net)
|
||||
##############################################################################
|
||||
#
|
||||
# You should not have to change the variables in this section -- they are set
|
||||
# by the packager of your Shorewall distribution
|
||||
#
|
||||
SHARED_DIR=/usr/lib/shorewall
|
||||
#
|
||||
##############################################################################
|
||||
#
|
||||
# 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.
|
||||
#
|
||||
# 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 build 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 from http://www.gnumonks.org/projects/ulogd and can be
|
||||
# configured to log all Shorewall message to their own log file
|
||||
################################################################################
|
||||
#
|
||||
# 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
|
||||
|
||||
#
|
||||
# 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
|
||||
|
||||
#
|
||||
# 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. On Debian, it
|
||||
# should be /var/state/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
|
||||
|
||||
#
|
||||
# ALLOW RELATED CONNECTIONS
|
||||
#
|
||||
# Set this to "yes" or "Yes" if you want to accept all connection requests
|
||||
# that are related to already established connections. For example, you want
|
||||
# to accept FTP data connections. If you say "no" here, then to accept
|
||||
# these connections between particular zones or hosts, you must include
|
||||
# explicit "related" rules in /etc/shorewall/rules.
|
||||
#
|
||||
|
||||
ALLOWRELATED=yes
|
||||
|
||||
#
|
||||
# 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=
|
||||
|
||||
#
|
||||
# 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.
|
||||
#
|
||||
# Example:
|
||||
#
|
||||
# LOGRATE=10/minute
|
||||
# LOGBURST=5
|
||||
#
|
||||
# If BOTH variables are set empty then logging will not be rate-limited.
|
||||
#
|
||||
|
||||
LOGRATE=
|
||||
LOGBURST=
|
||||
|
||||
#
|
||||
# LEVEL AT WHICH TO LOG 'UNCLEAN' PACKETS
|
||||
#
|
||||
# This variable determines the level at which Mangled/Invalid packets are logged
|
||||
# under the 'dropunclean' interface option. If you set this variable to an
|
||||
# empty value (e.g., LOGUNCLEAN= ), Mangled/Invalid packets will be dropped
|
||||
# silently.
|
||||
#
|
||||
# The value of this variable also determines the level at which Mangled/Invalid
|
||||
# packets are logged under the 'logunclean' interface option. If the variable
|
||||
# is empty, these packets will still be logged at the 'info' level.
|
||||
#
|
||||
# See the comment at the top of this file for a description of log levels
|
||||
#
|
||||
|
||||
LOGUNCLEAN=info
|
||||
|
||||
#
|
||||
# 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/FAQ.htm#faq6
|
||||
|
||||
LOGFILE=/var/log/messages
|
||||
|
||||
#
|
||||
# ENABLE NAT SUPPORT
|
||||
#
|
||||
# You probally want yes here. Only gateways not doing NAT in any form, like
|
||||
# SNAT,DNAT masquerading, port forwading etc. should say "no" here.
|
||||
#
|
||||
NAT_ENABLED=Yes
|
||||
|
||||
#
|
||||
# ENABLE MANGLE SUPPORT
|
||||
#
|
||||
# If you say "no" here, Shorewall will ignore the /etc/shorewall/tos file
|
||||
# and will not initialize the mangle table when starting or stopping
|
||||
# your firewall. You must enable mangling if you want Traffic Shaping
|
||||
# (see TC_ENABLED below).
|
||||
#
|
||||
MANGLE_ENABLED=Yes
|
||||
|
||||
#
|
||||
# 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=Off
|
||||
|
||||
#
|
||||
# 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
|
||||
|
||||
#
|
||||
# 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) and
|
||||
# you must enable packet mangling above.
|
||||
#
|
||||
TC_ENABLED=No
|
||||
|
||||
#
|
||||
# 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
|
||||
|
||||
#
|
||||
# BLACKLIST LOG LEVEL
|
||||
#
|
||||
# Set this variable to the syslogd level that you want blacklist packets logged
|
||||
# (beward of DOS attacks resulting from such logging). If not set, no logging
|
||||
# of blacklist packets occurs.
|
||||
#
|
||||
# See the comment at the top of this file for a description of log levels
|
||||
#
|
||||
BLACKLIST_LOGLEVEL=
|
||||
|
||||
#
|
||||
# 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.
|
||||
#
|
||||
CLAMPMSS=No
|
||||
|
||||
#
|
||||
# ROUTE FILTERING
|
||||
#
|
||||
# Set this variable to "Yes" or "yes" if you want kernel route filtering on all
|
||||
# interfaces (anti-spoofing measure).
|
||||
#
|
||||
# If this variable is not set or is set to the empty value, "No" is assumed.
|
||||
# In that case, you can still enable route filtering on individual interfaces
|
||||
# in the /etc/shorewall/interfaces file.
|
||||
|
||||
ROUTE_FILTER=No
|
||||
|
||||
#
|
||||
# NAT BEFORE RULES
|
||||
#
|
||||
# Shorewall has traditionally processed static NAT rules before port forwarding
|
||||
# rules. If you would like to reverse the order, set this variable to "No".
|
||||
#
|
||||
# If this variable is not set or is set to the empty value, "Yes" is assumed.
|
||||
|
||||
NAT_BEFORE_RULES=Yes
|
||||
|
||||
# MULTIPORT support
|
||||
#
|
||||
# If your kernel includes the multiport match option
|
||||
# (CONFIG_IP_NF_MATCH_MULTIPORT), you may enable it's use here. When this
|
||||
# option is enabled by setting it's value to "Yes" or "yes":
|
||||
#
|
||||
# 1) If you list more that 15 ports in a comma-seperated list in
|
||||
# /etc/shorewall/rules, Shorewall will not use the multiport option
|
||||
# but will generate a separate rule for each element of each port
|
||||
# list.
|
||||
# 2) If you include a port range (<low port>:<high port>) in the
|
||||
# rule, Shorewall will not use the multiport option but will generate
|
||||
# a separate rule for each element of each port list.
|
||||
#
|
||||
# See the /etc/shorewall/rules file for additional information on this option.
|
||||
#
|
||||
# if this variable is not set or is set to the empty value, "No" is assumed.
|
||||
|
||||
MULTIPORT=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
|
||||
|
||||
#
|
||||
# MERGE HOSTS FILE
|
||||
#
|
||||
# The traditional behavior of the /etc/shorewall/hosts file has been that
|
||||
# if that file has ANY entry for a zone then the zone must be defined
|
||||
# entirely in the hosts file. This is counter-intuitive and has caused
|
||||
# people some problems.
|
||||
#
|
||||
# By setting MERGE_HOSTS=Yes, a more intuitive behavior of the hosts file
|
||||
# is enabled. With MERGE_HOSTS=Yes, the zone contents in the hosts file
|
||||
# are added to the contents described in the /etc/shorewall/interfaces file.
|
||||
#
|
||||
# Example: Suppose that we have the following interfaces and hosts files:
|
||||
#
|
||||
# Interfaces:
|
||||
#
|
||||
# net eth0
|
||||
# loc eth1
|
||||
# - ppp+
|
||||
#
|
||||
# Hosts:
|
||||
#
|
||||
# loc ppp+:192.168.1.0/24
|
||||
# wrk ppp+:!192.168.1.0/24
|
||||
#
|
||||
# With MERGE_HOSTS=No, the contents of the 'loc' zone would be just
|
||||
# ppp+:192.168.1.0/24. With MERGE_HOSTS=Yes, the contents would be
|
||||
# ppp+:192.168.1.0 and eth1:0.0.0.0/0
|
||||
#
|
||||
# If this variable is not set or is set to the empty value, "No" is assumed.
|
||||
|
||||
MERGE_HOSTS=Yes
|
||||
|
||||
#
|
||||
# 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
|
||||
|
||||
#
|
||||
# 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 file for a description of log levels
|
||||
#
|
||||
# Example: LOGNEWNOTSYN=debug
|
||||
|
||||
|
||||
LOGNEWNOTSYN=
|
||||
|
||||
#
|
||||
# Old Ping Handling
|
||||
#
|
||||
# If this option is set to "Yes" then Shorewall will use its old ping handling
|
||||
# facility including the FORWARDPING option in this file and the 'noping' and
|
||||
# 'filterping' interface options. If this option is set to 'No' then ping
|
||||
# is handled via policy and rules just like any other connection request.
|
||||
#
|
||||
# If you are a new Shorewall user DON'T CHANGE THE VALUE OF THIS OPTION AND
|
||||
# DON'T DELETE IT!!!!!!
|
||||
#
|
||||
OLD_PING_HANDLING=No
|
||||
|
||||
#
|
||||
# NEWNOTSYN
|
||||
#
|
||||
# If this variable is set to "No" or "no", then 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 dropped by the
|
||||
# firewall
|
||||
#
|
||||
# If this variable is set to "Yes" or "yes" then such packets will not be
|
||||
# dropped but will pass through the normal rule 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.
|
||||
|
||||
NEWNOTSYN=No
|
||||
|
||||
#
|
||||
# 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
|
||||
|
||||
#
|
||||
# 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 file for a description of log levels
|
||||
#
|
||||
|
||||
MACLIST_LOG_LEVEL=info
|
||||
|
||||
#
|
||||
# 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. If not specified
|
||||
# or specified as empty (TCP_FLAGS_DISPOSITION="") then DROP is assumed.
|
||||
|
||||
TCP_FLAGS_DISPOSITION=DROP
|
||||
|
||||
#
|
||||
# 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 file 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 file for a description of log levels
|
||||
#
|
||||
|
||||
RFC1918_LOG_LEVEL=info
|
||||
|
||||
#
|
||||
# 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
|
||||
|
||||
#
|
||||
# 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
|
||||
|
||||
#LAST LINE -- DO NOT REMOVE
|
||||
Loading…
Reference in New Issue
Block a user