📄 shorewall.conf.5
字号:
.sp -1.IP \(bu 2.3.\}The chain name is used as the target in the log prefix\&..RE.RS 4For example, using the default LOGFORMAT, the log prefix for logging from the nat table\'s PREROUTING chain is:.sp.if n \{\.RS 4.\}.fam C.ps -1.nf.BB lightgray Shorewall:nat:PREROUTING .EB lightgray.fi.fam.ps +1.if n \{\.RE.\}.sp.if n \{\.sp.\}.RS 4.BM yellow.it 1 an-trap.nr an-no-space-flag 1.nr an-break-flag 1.br.ps +1\fBImportant\fR.ps -1.brTo help insure that all packets in the NEW state are logged, rate limiting (LOGBURST and LOGRATE) 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\&..sp .5v.EM yellow.RE.if n \{\.sp.\}.RS 4.BM yellow.it 1 an-trap.nr an-no-space-flag 1.nr an-break-flag 1.br.ps +1\fBCaution\fR.ps -1.brDo not use this option if the resulting log messages will be sent to another system\&..sp .5v.EM yellow.RE.RE.PP\fBLOGFILE=\fR[\fIpathname\fR].RS 4This parameter tells the /sbin/shorewall program where to look for Shorewall messages when processing the\fBdump\fR,\fBlogwatch\fR,\fBshow log\fR, and\fBhits\fRcommands\&. If not assigned or if assigned an empty value, /var/log/messages is assumed\&..RE.PP\fBLOGFORMAT=\fR[\fB"\fR\fIformattemplate\fR\fB"\fR].RS 4The value of this variable generate the \-\-log\-prefix setting for Shorewall logging rules\&. It contains a \(lqprintf\(rq formatting template which accepts three arguments (the chain name, logging rule number (optional) and the disposition)\&. To use LOGFORMAT with fireparse, set it as:.sp.if n \{\.RS 4.\}.fam C.ps -1.nf.BB lightgray LOGFORMAT="fp=%s:%d a=%s ".EB lightgray.fi.fam.ps +1.if n \{\.RE.\}.spIf the LOGFORMAT value contains the substring \(lq%d\(rq 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 \(lqShorewall:%s:%s:\(rq is assumed\&..RE.PP\fBLOGBURST=\fR[\fIburst\fR].RS 4.RE.PP\fBLOGRATE=\fR[\fIrate\fR/{\fBminute\fR|\fBsecond\fR}].RS 4These parameters set the match rate and initial burst size for logged packets\&. Please see iptables(8) for a description of the behavior of these parameters (the iptables option \-\-limit is set by LOGRATE and \-\-limit\-burst is set by LOGBURST)\&. If both parameters are set empty, no rate\-limiting will occur\&..spExample:.sp.if n \{\.RS 4.\}.fam C.ps -1.nf.BB lightgray LOGRATE=10/minute LOGBURST=5.EB lightgray.fi.fam.ps +1.if n \{\.RE.\}.spFor 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\&..RE.PP\fBLOGTAGONLY=\fR[\fBYes\fR|\fBNo\fR].RS 4Using 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\&..RE.PP\fBMACLIST_DISPOSITION=\fR[\fBACCEPT\fR|\fBDROP\fR|\fBREJECT\fR].RS 4Determines 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\&..RE.PP\fBMACLIST_LOG_LEVEL=\fR[\fIlog\-level\fR].RS 4Determines 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="")\&..RE.PP\fBMACLIST_TABLE=\fR[\fBfilter\fR|\fBmangle\fR].RS 4Normally, 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\&..spThis problem can be worked around by setting MACLIST_TABLE=mangle which will cause Mac verification to occur out of the PREROUTING chain\&. Because REJECT isn\'t available in that environment, you may not specify MACLIST_DISPOSITION=REJECT with MACLIST_TABLE=mangle\&..RE.PP\fBMACLIST_TTL=[\fR\fInumber\fR].RS 4The performance of configurations with a large numbers of entries in\m[blue]\fBshorewall\-maclist\fR\m[]\&\s-2\u[11]\d\s+2(5) can be improved by setting the MACLIST_TTL variable in\m[blue]\fBshorewall\&.conf\fR\m[]\&\s-2\u[12]\d\s+2(5)\&..spIf 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\&..spWhen a new connection arrives from a \'maclist\' interface, the packet passes through then list of entries for that interface in\m[blue]\fBshorewall\-maclist\fR\m[]\&\s-2\u[11]\d\s+2(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\&..spIf 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)\&..RE.PP\fBMAPOLDACTIONS=\fR[\fBYes\fR|\fBNo\fR].RS 4Previously, Shorewall included a large number of standard actions (AllowPing, AllowFTP, \&.\&.\&.)\&. These have been replaced with parameterized macros\&. For compatibility, Shorewall can map the old names into invocations of the new macros if you set MAPOLDACTIONS=Yes\&. If this option is not set or is set to the empty value (MAPOLDACTIONS="") then MAPOLDACTIONS=Yes is assumed\&..sp.if n \{\.sp.\}.RS 4.BM yellow.it 1 an-trap.nr an-no-space-flag 1.nr an-break-flag 1.br.ps +1\fBNote\fR.ps -1.brMAPOLDACTIONS=Yes is not supported by Shorewall\-perl\&. With Shorewall\-perl, if MAPOLDACTIONS is not set or is set to the ampty value then MAPOLDACTIONS=No is assumed\&..sp .5v.EM yellow.RE.RE.PP\fBMARK_IN_FORWARD_CHAIN=\fR[\fBYes\fR|\fBNo\fR].RS 4If 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\fB/sbin/shorewall show mangle\fRcommand; 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\&..RE.PP\fBMODULE_SUFFIX=\fR[\fB"\fR\fIextension\fR \&.\&.\&.\fB"\fR].RS 4The value of this option determines the possible file extensions of kernel modules\&. The default value is "o gz ko o\&.gz"\&..RE.PP\fBMODULESDIR=\fR[\fIpathname\fR[\fB:\fR\fIpathname\fR]\&.\&.\&.].RS 4This 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 \-r`/kernel/net/ipv4/netfilter" in versions of Shorewall prior to 3\&.2\&.4 and "/lib/modules/`uname \-r`/kernel/net/ipv4/netfilter:/lib/modules/`uname \-r`/kernel/net/ipv4/netfilter" in later versions\&..RE.PP\fBMULTICAST=\fR[\fBYes\fR|\fBNo\fR].RS 4This option will normally be set to \'No\' (the default)\&. It should be set to \'Yes\' under the following circumstances:.sp.RS 4.ie n \{\\h'-04' 1.\h'+01'\c.\}.el \{\.sp -1.IP " 1." 4.2.\}You have an interface that has parallel zones defined via /etc/shorewall/hosts\&..RE.sp.RS 4.ie n \{\\h'-04' 2.\h'+01'\c.\}.el \{\.sp -1.IP " 2." 4.2.\}You want to forward multicast packets to two or more of those parallel zones\&..RE.RS 4In such cases, you will configure a\fBdestonly\fRnetwork on each zone receiving multicasts\&..spThe MULTICAST option is only recognized by Shorewall\-perl and is ignored by Shorewall\-shell\&..RE.PP\fBMUTEX_TIMEOUT=\fR[\fIseconds\fR].RS 4The 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\&..spIf not set or set to the empty value, a value of 60 (60 seconds) is assumed\&..spAn appropriate value for this parameter would be twice the length of time that it takes your firewall system to process a\fBshorewall restart\fRcommand\&..RE.PP\fBOPTIMIZE=\fR[\fB0\fR|\fB1\fR].RS 4Traditionally, Shorewall has created rules for\m[blue]\fBthe complete matrix of host groups defined by the zones, interfaces and hosts files\fR\m[]\&\s-2\u[13]\d\s+2\&. 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\&..spThese extra rules can be eliminated by setting OPTIMIZE=1\&..spThe OPTIMIZE 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\&..RE.PP\fBPATH=\fR\fIpathname\fR[\fB:\fR\fIpathname\fR]\&.\&.\&..RS 4Determines the order in which Shorewall searches directories for executable files\&..RE.PP\fBPKTTYPE=\fR{\fBYes\fR|\fBNo\fR}.RS 4Normally Shorewall attempts to use the iptables packet type match extension to determine broadcast and multicast packets\&..sp.RS 4.ie n \{\\h'-04' 1.\h'+01'\c.\}.el \{\.sp -1.IP " 1." 4.2.\}This can cause a message to appear during shorewall start (modprobe: cant locate module ipt_pkttype)\&..RE.sp.RS 4.ie n \{\\h'-04' 2.\h'+01'\c.\}.el \{\.sp -1.IP " 2." 4.2.\}Some users have found problems with the packet match extension with the result that their firewall log is flooded with messages relating to broadcast packets\&..RE.RS 4If you are experiencing either of these problems, setting PKTTYPE=No will prevent Shorewall from trying to use the packet type match extension and to use IP address matching to determine which packets are broadcasts or multicasts\&..RE.PP\fBRCP_COMMAND="\fR\fIcommand\fR\fB"\fR.RS 4.RE.PP\fBRSH_COMMAND="\fR\fIcommand\fR\fB"\fR.RS 4Eariler generations of Shorewall Lite required that remote root login via ssh be enabled in order to use the\fBload\fRand\fBreload\fRcommands\&. 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:.RS 4RSH_COMMAND.RE.RS 4RCP_COMMAND.REThe default values for these are as follows:.RS 4RSH_COMMAND: ssh ${root}@${system} ${command}.RE.RS 4RCP_COMMAND: scp ${files} ${root}@${system}:${destination}.REShell variables that will be set when the commands are envoked are as follows:.RS 4\fIroot\fR \- root user\&. Normally \fBroot\fR but may be overridden using the \'\-r\' option\&..RE.RS 4\fIsystem\fR \- The name/IP address of the remote firewall system\&..RE.RS 4\fIcommand\fR \- For RSH_COMMAND, the command to be executed on the firewall system\&..RE.RS 4\fIfiles\fR \- For RCP_COMMAND, a space\-separated list of files to be copied to the remote firewall system\&..RE.RS 4\fIdestination\fR \- The directory on the remote system that the files are to be copied into\&..RE.RE.PP\fBRESTORE_DEFAULT_ROUTE=\fR[\fBYes\fR|\fBNo\fR].RS 4Added in Shorewall 4\&.2\&.6, this option determines whether to restore the default route saved when here are \'balance\' providers defined but all of them are down\&..spThe default is RESTORE_DEFAULT_ROUTE=Yes which preserves the pre\-4\&.2\&.6 behavior\&..spRESTORE_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\&..RE.PP\fBRESTOREFILE=\fR\fIfilename\fR.RS 4Specifies the simple name of a file in /var/lib/shorewall to be used as the default restore script in the\fBshorewall save\fR,\fBshorewall restore\fR,\fBshorewall forget \fRand\fBshorewall \-f start\fRcommands\&..RE.PP\fBRETAIN_ALIASES=\fR{\fBYes\fR|\fBNo\fR}.RS 4During\fBshorewall star\fRt, IP addresses to be added as a consequence of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes are quietly deleted when\m[blue]\fBshorewall\-nat\fR\m[]\&\s-2\u[2]\d\s+2(5) and\m[blue]\fBshorewall\-masq\fR\m[]\&\s-2\u[3]\d\s+2(5) are processed then are re\-added later\&. This is done to help ensure that the addresses can be added with the specified labels but can have the undesirable side effect of causing routes to be quietly deleted\&. When RETAIN_ALIASES is set to Yes, existing addresses will not be deleted\&. Regardless of the setting of RETAIN_ALIASES, addresses added during\fBshorewall start\fRare still deleted at a subsequent\fBshorewall stop\fRor\fBshorewall restart\fR\&..RE.PP\fBRFC1918_LOG_LEVEL=\fR[\fIlog\-level\fR].RS 4This parameter determines the level at which packets logged under the\fBnorfc1918\fRmechanism are logged\&. The value must be a valid syslog level and if no level is given, then info is assumed\&..RE.PP\fBRFC1918_STRICT=\fR[\fBYes\fR|\fBNo\fR].RS 4Traditionally, 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 this entry in\m[blue]\fBshorewall\-rfc1918\fR\m[]\&\s-2\u[14]\d\s+2(5):.sp.if n \{\.RS 4.\}.fam C.ps -1.nf.BB lightgray #SUBNETS TARGET 192\&.168\&.1\&.0/24 RETURN.EB lightgray.fi.fam.ps +1.if n \{\.RE
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -