File: commands.html

package info (click to toggle)
firehol 1.231-2sarge1
links: PTS
area: main
in suites: sarge
size: 1,096 kB
ctags: 389
sloc: sh: 9,783; makefile: 55
file content (1650 lines) | stat: -rw-r--r-- 91,814 bytes
parent folder | download | duplicates (2)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<link rel="stylesheet" type="text/css" href="css.css">
<TITLE>FireHOL, Configuration commands</TITLE>
<meta name="author" content="Costa Tsaousis">
<meta name="description" content="

Home for FireHOL, an iptables stateful packet filtering firewall builder for Linux (kernel 2.4),
supporting NAT, SNAT, DNAT, REDIRECT, MASQUERADE, DMZ, dual-homed, multi-homed and router setups,
protecting and securing hosts and LANs in all kinds of topologies. Configuration is done using
simple client and server statements while it can detect (and produce) its configuration
automatically. FireHOL is extremely easy to understand, configure and audit.

">

<meta name="keywords" content="iptables, netfilter, filter, firewall, stateful, port, secure, security, NAT, DMZ, DNAT, DSL, SNAT, redirect, router, rule, rules, automated, bash, block, builder, cable, complex, configuration, dual-homed, easy, easy configuration, example, fast, features, flexible, forward, free, gpl, helpme mode, human, intuitive, language, linux, masquerade, modem, multi-homed, open source, packet, panic mode, protect, script, service, system administration, wizard">
<meta http-equiv="Expires" content="Wed, 19 Mar 2003 00:00:01 GMT">
</HEAD>

<BODY bgcolor="#FFFFFF">

<center>
<script type="text/javascript"><!--
google_ad_client = "pub-4254040714325099";
google_ad_width = 728;
google_ad_height = 90;
google_ad_format = "728x90_as";
google_ad_channel ="";
google_page_url = document.location;
google_color_border = "336699";
google_color_bg = "FFFFFF";
google_color_link = "0000FF";
google_color_url = "008000";
google_color_text = "000000";
//--></script>
<script type="text/javascript"
  src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>
</center>
<p>


<center><a name="contents"><h2>Table of Contents</h2></a></center>
<ul>
	<li><a href="#primary_commands">Primary Commands</a>
		<ul>
			<li><a href="#interface">interface</a>, control what the firewall host can do
			<li><a href="#router">router</a>, control what traffic can pass through the firewall host
		</ul>
		&nbsp;
	</li>
	<li><a href="#subcommands">Sub-Commands</a>
		<ul>
			<li><a href="#policy">policy</a>, set the default action for unmatched packets of an
				<a href="#interface">interface</a>
			</li>
			<li><a href="#protection">protection</a>, add extra protections to
				<a href="#interface">interfaces</a> and <a href="#router">routers</a>
			</li>
			<li><a href="#server">server</a>, accept requests to some <a href="services.html">service</a>
			</li>
			<li><a href="#client">client</a>, accept replies to some <a href="services.html">service</a>
			</li>
			<li><a href="#route">route</a>, route traffic
			</li>
			<li><a href="#group_cmd">group</a>, group a number of services with common optional rule parameters
			</li>
		</ul>
		&nbsp;
	</li>
	<li><a href="#helpers">Helper commands</a>
		<ul>
			<li><a href="#blacklist">blacklist</a>, setup a unidirectional or bidirectional blacklist</li>
			<li><a href="#dnat">dnat</a>, setup a Destination NAT rule for routed traffic</li>
			<li><a href="#dscp">dscp</a>, set the DSCP field in the packet header, to a raw value or a DiffServ class</li>
			<li><a href="#ecn_shame">ecn_shame</a>, disable ECN for all hosts in the ECN Shame list</li>
			<li><a href="#iptables">iptables</a>, add some custom iptables commands to the firewall
			<li><a href="#mac">mac</a>, setup a source mac address with IP match</li>
			<li><a href="#mark">mark</a>, mark traffic for traffic shapping tools</li>
			<li><a href="#masquerade">masquerade</a>, setup masquerading (NAT) to the output of a network interface</li>
			<li><a href="#nat">nat</a>, setup a NAT rule for routed traffic</li>
			<li><a href="#redirect">redirect</a>, setup a port redirection rule</li>
			<li><a href="#snat">snat</a>, setup a Source NAT rule for routed traffic</li>
			<li><a href="#tcpmss">tcpmss</a>, set the MSS of TCP SYN packets for routers</li>
			<li><a href="#tos">tos</a>, set the Type of Service (TOS) field in the packet header</li>
			<li><a href="#transparent_proxy">transparent_proxy</a>, setup a transparent TCP proxy running on the firewall host</li>
			<li><a href="#transparent_squid">transparent_squid</a>, setup a transparent web proxy running on the firewall host</li>
			<li><a href="#version">version</a>, require a specific version of FireHOL
		</ul>
		&nbsp;
	</li>
	<li><a href="#actions">Actions</a>
		<ul>
			<li><a href="#accept">accept</a>, allow the traffic to reach its destination</li>
			<li><a href="#reject">reject</a>, don't allow the traffic to pass, but send a rejection message to the sender</li>
			<li><a href="#drop">drop</a>, discard the traffic without sending anything back to the sender</li>
			<li><a href="#deny">deny</a>, an alias for <a href="#drop">drop</a></li>
			<li><a href="#return">return</a>, return to processing the parent flow of rules</li>
			<li><a href="#mirror">mirror</a>, send the traffic back to the sender at the port of the destination</li>
			<li><a href="#redirect">redirect</a>, redirect the traffic to another port on the local host</li>
		</ul>
		&nbsp;
	</li>
	<li><a href="#parameters">Optional Rule Parameters</a>
		<ul>
			<li><a href="#src">src</a>, match the source of traffic</li>
			<li><a href="#dst">dst</a>, match the destination of traffic</li>
			<li><a href="#inface">inface</a>, match the network interface traffic is received via</li>
			<li><a href="#outface">outface</a>, match the network interface traffic is send via</li>
			<li><a href="#physin">physin</a>, match the physical network interface (for bridges) traffic is received via</li>
			<li><a href="#physout">physout</a>, match the physical network interface (for bridges) traffic is send via</li>
			<li><a href="#custom">custom</a>, pass a few custom parameters to the generated iptables statements</li>
			<li><a href="#log">log</a>, write something to the syslog when traffic is matched</li>
			<li><a href="#loglimit">loglimit</a>, write (limited) something to the syslog when traffic is matched</li>
			<li><a href="#proto">proto</a>, match a specific protocol</li>
			<li><a href="#limit">limit</a>, limit the frequency traffic is matched</li>
			<li><a href="#sport">sport</a>, match the source ports</li>
			<li><a href="#dport">dport</a>, match the destination ports</li>
			<li><a href="#uid">uid, user</a>, match the users sending this traffic</li>
			<li><a href="#gid">gid, group</a>, match the user groups sending this traffic</li>
			<li><a href="#pid">pid, process</a>, match the process IDs sending this traffic</li>
			<li><a href="#sid">sid, session</a>, match the process session IDs sending this traffic</li>
			<li><a href="#cmd">cmd, command</a>, match the command name sending this traffic</li>
			<li><a href="#mac_param">mac</a>, match the source MAC address of packets.</li>
			<li><a href="#mark_param">mark</a>, match the MARK ID of packets.</li>
			<li><a href="#tos_param">tos</a>, match the Type of Service (TOS) of packets.</li>
			<li><a href="#dscp_param">dscp</a>, match the DSCP raw value or DiffServ class value of packets.</li>
			
		</ul>
		&nbsp;
	</li>
	<li><a href="#control_variables">Variables that control FireHOL</a><br>&nbsp;</li>
	<li><a href="#use_variables">Variables FireHOL offers</a><br>&nbsp;</li>
</ul>

<table border=0 cellpadding=10 cellspacing=0 width="100%"><tr bgcolor="#777777"><td align=center><font color="white"><b><big><a name="primary_commands">Primary Commands</a></td</tr></table>
<small>
Primary commands form groups of rules within a FireHOL firewall.
The optional rule parameters given to the primary commands are <b>indirectly</b> applied to all sub-commands given within this primary command.
</small>
<p>

	<a name="interface"><h3><b>interface</b> <font color="red">&lt;real interface&gt;</font> <font color="red">&lt;name&gt;</font> <b>[optional rule parameters]</b></h3></a>
	<H4>Description</H4>
	The <b>interface</b> command creates a firewall for protecting the host the firewall is running, from the given interface.
	<br>The default interface policy is <b>drop</b>, so that if no subcommands are given, the
	firewall will just drop all incoming <b>and outgoing</b> traffic using this interface.
	<p>
	INPORTANT<br>
	Note that unlike ipchains, in <b>iptables</b> traffic passing through the firewall
	host (FORWARDed traffic) does not pass through the INPUT/OUTPUT chains of the firewall and
	therefore the <b>interface</b> rules in FireHOL never match it.
	To match the traffic passing through (even if DNATed) you have to place
	the filtering rules in <b>router</b> statements. <b>Interface</b>
	statements filter traffic <b>only from/to the firewall host</b>. Nothing else.
	<p>
	<H4>Parameters</H4>
	<ul>
		<li>	<b>real interface</b> is the interface name as shown by <b>ip link show</b>.
			Generally anything iptables accepts, including the pattern character + (the plus sign), is valid.
			<br>The plus sign after some text will match all interfaces that start with this text.
			<br>It is allowed to use more than one interfaces separated by spaces, but all of them should be
			given within one quoted argument:
			<br>Example: <b>interface "eth0 eth1 ppp0" myname</b>
			<br>&nbsp;
			</li>

		<li>	<b>name</b> is a name for this interface.
			<br>Generally you should use short names (10 characters max) without spaces or other symbols.
			<br>You should not use the same name more than once in FireHOL primary commands.
			<br>&nbsp;
			</li>
			
		<li>	<b>optional rule parameters</b> is a set of rules that allow further restriction of the traffic that
			gets matched for this interface. See <a href="#parameters">Optional Rules Parameters</a> for more information.
			<br>Example 1: <b>interface eth0 intranet src 10.0.0.0/16</b>
			<br>Example 2: <b>interface eth0 internet src not "$UNROUTABLE_IPS"</b>
			(note: UNROUTABLE_IPS is a variable defined by FireHOL that includes all IPs that should not be routable
			by the Internet).
			<br>&nbsp;
			</li>
		</ul>
	<p>

<hr noshade size=1 width="100%">

	<a name="router"><h3><b>router</b> <font color="red">&lt;name&gt;</font> <b>[optional rule parameters]</b></h3></a>
	<H4>Description</H4>
	The <b>router</b> command creates a firewall for the traffic passing through the host running the firewall.
	The only acceptable policy on all <b>router</b> commands is <b>return</b> and therefore the policy subcommand
	cannot be used on routers. This means that no packets are dropped in a router. Packets not matched by any
	<b>router</b> command will be dropped at the end of the firewall.
	<p>
	INPORTANT<br>
	Note that unlike ipchains, in <b>iptables</b> traffic passing through the firewall
	host (FORWARDed traffic) does not pass through the INPUT/OUTPUT chains of the firewall and
	therefore the <b>interface</b> rules in FireHOL never match it.
	To match the traffic passing through (even if DNATed) you have to place
	the filtering rules in <b>router</b> statements. <b>Interface</b>
	statements filter traffic <b>only from/to the firewall host</b>.
	<b>Router</b> statements filter traffic <b>that passes through the
	firewall host.</b>
	<p>
	<H4>Parameters</H4>
	<ul>
		<li>	<b>name</b> is a name for this router.
			<br>The same restrictions of <b>interface</b> names apply here too.
			<br>&nbsp;
			</li>
			
		<li>	<b>optional rule parameters</b> is a set of rules that allow further restriction of the traffic that
			gets matched for this router. See <a href="#parameters">Optional Rules Parameters</a> for more information.
			<br>&nbsp;
			</li>
		</ul>
	
	Router statements produce similar iptables commands the interface statements produce.
	For each router statement an <b>in_<font color="red">&lt;name&gt;</font></b> and an
	<b>out_<font color="red">&lt;name&gt;</font></b> chain are produced to match the traffic
	in both directions of the router.
	<br>
	To match some client or server traffic the administrator has to specify the input/output
	interface or the source/destination of the request.
	All inface/outface, src/dst optional rule parameters can be given either on the <b>router</b>
	statement in which case will be applied to all subcommands for this <i>router</i>,
	or on each subcommand within a <b>router</b>.
	Both are valid.
	<br>
	For example:
	<pre>
		router mylan inface ppp+ outface eth0
			server http accept
			client smtp accept
	</pre>
	The above says: Define a router that matches all <u>requests</u> that originate from some PPP interface and go out to eth0.<br>
	There is an HTTP server in eth0 that client from the PPP interfaces are allowed to reach.<br>
	Clients on eth0 are allowed to get SMTP traffic from the PPP interfaces.<br>
	<br>
	While:
	<pre>
		router mylan
			server http accept inface ppp+ outface eth0
			server smtp accept inface eth0 outface ppp+
	</pre>
	The above says: Define a router that matches any kind of forwarded traffic.<br>
	For HTTP traffic the clients are on a PPP interface and the servers on eth0.<br>
	For SMTP traffic the clients are on a eth0 interface and the servers o a PPP interface.
	<p>
	Please note that in the second example the SMTP traffic is matched again with a <b>server</b> subcommand,
	not a <b>client</b> (as in the first example).
	<p>
	The <b>client</b> subcommand <u>reverses</u> all the optional rules that are applied <u>indirectly</u> to it.
	Indirect rule parameters are those that are inherited from the parent command (<b>router</b> in this case).
	<br>
	To make it simple, for FireHOL a <b>client</b> is: "a <b>server</b> with all the implicit optional rule parameters reversed".
	<p>
	So, in the first example, the <b>client</b> simply flipped the inface and outface rules defined at the <b>router</b>
	and became an SMTP <b>server</b>.
	<br>In the second example there is nothing to be flipped, so <b>server</b> and <b>client</b>
	are exactly the same.<p>
	I suggest to use <b>client</b> subcommands in routers only if you have inface/outface or src/dst in the <b>router</b> statements.
	If you are building routers like the second example, don't use <b>client</b>, it is confusing.
	<p>
	Older versions of FireHOL did not allow server and client subcommands in routers.
	Only the <b>route</b> subcommand was allowed. Today, <b>route</b> is just an alias for <b>server</b> and can be
	used only in routers, not interfaces.
	<p>
	Any number of <b>router</b> statements can exist. Since the policy is RETURN on all of them, any traffic
	not matched by a <i>router</i> will continue to be checked against the second.
	<p>

<table border=0 cellpadding=10 cellspacing=0 width="100%"><tr bgcolor="#777777"><td align=center><font color="white"><b><big><a name="subcommands">Sub-Commands</a></td</tr></table>
<small>
Subcommands must be given within <a href="#primary_commands">Primary commands</a>.
</small>

	<a name="policy"><h3><b>policy</b> <font color="red">&lt;action&gt;</font></h3></a>
	<H4>Description</H4>
	The <b>policy</b> subcommand defines the default policy for an <b>interface</b>.
	<p>
	This directive accepts all the actions specified in <a href="#actions">Actions</a>.
	<p>
	<b>Please note that FireHOL is only useful for "DROP/REJECT EVERYTHING, ALLOW EXPLICITLY" type of firewalls.
	By changing the policy to accept, you <u>CANNOT</u> create valid "ACCEPT EVERYTHING, DROP EXPLICITLY" firewalls.</b><br>
	The policy should be set to accept only if you <u>really trust</u> the hosts that can reach the machine via this interface.
	For information about this, see: <a href="https://sourceforge.net/tracker/index.php?func=detail&aid=927532&group_id=58425&atid=487692">Bug 927532</a>.
	<p>
	The policy of routers cannot be changed and is always RETURN.
	<p>

<hr noshade size=1 width="100%">

	<a name="protection"><h3><b>protection</b> [reverse] <font color="red">&lt;type&gt;</font> [requests/sec [burst]]</h3></a>
	<H4>Description</H4>
	The <b>protection</b> subcommand sets a number of protection rules on an <b>interface</b>.
	<p>
	In router configurations, <b>protections</b> are setup on <b>inface</b>. The <b>reverse</b> keyword will make the
	protections setup on <b>outface</b>. Please note that the <b>reverse</b> keyword must be the first given.
	Otherwise it will not work.
	<p>
	<b>type</b> can be: <br>
	<ul><b>strong</b>, or <b>full</b>, or <b>all</b>
	<br>turns on all the possible protections.
	</ul>
	<ul><b>invalid</b>
	<br>Drops all incoming INVALID packets. Invalid packets are those that are matched by "-m state --state INVALID", so they are all those
	packets that the iptables connection tracker believes are INVALID.
	<br>
	There is also the <a href="#FIREHOL_DROP_INVALID">FIREHOL_DROP_INVALID</a> variable which controls the same function globally, for the
	whole firewall.
	</ul>
	<ul><b>fragments</b>
	<br>Drops all packet fragments. Please note that most probably this rule will never match anything since
	iptables reconstructs all packets automatically, before the iptables firewall rules are processed, when its connection tracker is running.
	<br>I left this here for psychological reasons and in case some one finds some use for it.
	</ul>
	<ul><b>new-tcp-w/o-syn</b>
	<br>Drops all TCP packets that initiate a socket but have no the SYN bit set.
	</ul>
	<ul><b>syn-floods</b>
	<br>Allows only a certain amount of new TCP connections per second. The optional two arguments [requests/sec] and [burst]
	are used by this rule in order to provide control on the number of connections to be allowed.
	The default is 100 connections per second that can match 50 (it was 4 in v1.38 and before) packets initially
	(this is implemented using the <b>limit</b> module of iptables: see <b>man iptables</b> for more).
	<br>Note that this rule applies to all connections attempted regardless of their final result (rejected, dropped, established, etc).
	Therefore it might not be a good idea to set it too low.
	</ul>
	<ul><b>icmp-floods</b>
	<br>Allows only a certain amount of ICMP echo requests per second. The optional two arguments [requests/sec] and [burst]
	are used by this rule in order to provide control on the number of connections to be allowed.
	The default is 100 connections per second that can match 50 (it was 4 in v1.38 and before) packets initially
	(this is implemented using the <b>limit</b> module of iptables: see <b>man iptables</b> for more).
	</ul>
	<ul><b>malformed-xmas</b>
	<br>Drops all TCP packets that have all the TCP flags set.
	</ul>
	<ul><b>malformed-null</b>
	<br>Drops all TCP packets that have all the TCP flags unset.
	</ul>
	<ul><b>malformed-bad</b>
	<br>Drops all TCP packets that have illegal combinations of TCP flags set.
	</ul>
	<p>

<hr noshade size=1 width="100%">
	
	<a name="server"><h3><b>server</b> <font color="red">&lt;service&gt;</font> <font color="red">&lt;action&gt;</font> [optional rule parameters]</h3></a>
	<H4>Description</H4>
	The <b>server</b> subcommand defines a server of a service. For FireHOL a server is the destination of a request,
	and even if this is more complex for multi-socket services, <u>for FireHOL a server always accepts requests</u>.
	<p>
	The optional rule parameters given to the parent primary command (interface or router) are inherited by the <b>server</b> as they have been given.
	<p>
	<br>This subcommand can be used on both interfaces and routers.
	<p>
	<H4>Parameters</H4>
	<ul>
		<li>	<b>service</b> is one of the supported service names.
			<br>The command accepts more than one services in the same argument if they are separated by space
			and quoted as a single argument.
			<br>Example 1: <b>server smtp accept</b>
			<br>Example 2: <b>server "smtp pop3 imap" accept</b>
			<br>&nbsp;
			</li>

		<li>	<b>action</b> tells FireHOL what to do with the traffic matching this rule.
			<p>FireHOL supports the actions defined in the section <a href="#actions">Actions</a>.
			<br>&nbsp;
			</li>
			
		<li>	<b>optional rule parameters</b> is a set of rules that allow further restriction of the traffic that
			gets matched by this rule. See <a href="#parameters">Optional Rules Parameters</a> for more information.
			<br>Example 1: <b>server smtp accept src 1.2.3.4</b>
			<br>Example 2: <b>server smtp accept log "its mail" src 1.2.3.4</b>
			<br>&nbsp;
			</li>
		</ul>
	<p>
	
<hr noshade size=1 width="100%">
	
	<a name="client"><h3><b>client</b> <font color="red">&lt;service&gt;</font> <font color="red">&lt;action&gt;</font> [optional rule parameters]</h3></a>
	The <b>client</b> subcommand defines a client of a service. For FireHOL a client is the source of a request.
	FireHOL follows this simple rule even on multi-socket complex protocols, so that <u>for FireHOL a client always sends requests</u>.
	<br>The parameters are exactly the same with the <a href="#server">server</a> subcommand.
	<p>
	The optional rule parameters given to the parent primary command (interface or router) are inherited by the <b>client</b>, but they are reversed.
	For an explanation of this please refer to the documentation of the <a href="#router">router</a> primary command.
	<p>
	<br>This subcommand can be used on both interfaces and routers.
	<p>

<hr noshade size=1 width="100%">
	
	<a name="route"><h3><b>route</b> <font color="red">&lt;service&gt;</font> <font color="red">&lt;action&gt;</font> [optional rule parameters]</h3></a>
	The <b>route</b> subcommand is an alias for the <b>server</b> command that can be used only on routers, not interfaces.
	<p>

<hr noshade size=1 width="100%">
	
	<a name="group_cmd"><h3><b>group</b> with [optional rule parameters]</h3>
	<h3><b>group</b> end</h3></a>
	
	The <b>group</b> subcommand allows grouping for <a href="#server">server</a> and <a href="#client">client</a>
	subcommands that share common optional rule parameters.
	<p>
	There is only one reason for using groups: Optimization of the generated firewall rules.
	With groups, all the optional rule parameters are checked only once, while entering the
	group, and then each service is applied without extra processing.
	<p>
	For example:
<center><table border=0 cellpadding=15 cellspacing=20 width="70%">
<tr><td bgcolor="#F0F0F0">
<b><pre>

	interface any world
		server http accept
		
		# trusted services
		group with src "1.2.3.4 5.6.7.8"
			server ssh	accept
			server telnet	accept
		group end
		
		client all accept
</pre></b>
</td></tr>
</table>
</center>
	The above will be optimal compared with <b>server "ssh telnet" accept src "1.2.3.4 5.6.7.8"</b>.
	<p>
	FireHOL supports nested groups.
	<p>


<table border=0 cellpadding=10 cellspacing=0 width="100%"><tr bgcolor="#777777"><td align=center><font color="white"><b><big><a name="helpers">Helper Commands</a></td</tr></table>
<small>Helper commands provide shortcuts for common functions not handled by the core of FireHOL's logic.</small>
<p>

	<a name="blacklist"><h3><b>blacklist</b> [option] <font color="red">&lt;IPs&gt;</font></h3></a>
	The <b>blacklist</b> helper creates a blacklist for the <b>IP</b> addresses given. It supports two modes of operation
	based on the option given (or the absence of it).
	<p>
	The option can be:
	<ul>
		<li>one of the words <b>them, him, her, it, this, these, input</b> in which case it will generate a unidirectional
		statefull blacklist, meaning that you will be able to ask (initiate connections) anything from them,
		but they will not be able to ask (initiate connections) anything from you or the remote hosts you protect (routing).
		<br>&nbsp;
		</li>
		<li>one of the words <b>all, full</b> or ommitted (no option given), in which case FireHOL will create bidirectional
		stateless rules that will DROP all traffic comming in from these IPs and will REJECT all traffic going to them.
		</li>
		<p>
	</ul>
	The blacklist helper affects both interfaces and routers and can be used as many times as needed, but before the first interface statement.
	The blacklist helper accepts multiple IPs both as one quoted and space separated list and as separate arguments.
	<p>
	
	Example 1: <b>blacklist this "195.97.5.202 10.1.1.1"</b> # please note the quotes<br>
	Example 2: <b>blacklist full 195.97.5.202 10.1.1.1</b> # please note the absence of quotes<br>
	<p>
	
<hr noshade size=1 width="100%">
	
	<a name="dnat"><h3><b>dnat</b> [to] <font color="red">&lt;target&gt;</font> [optional rule parameters]</h3></a>
	The <b>dnat</b> helper sets up a Destination NAT rule for routed traffic, by calling<br>
	<b>nat to-destination &lt;target&gt [optional rule parameters]</b>
	<p>
	See the <a href="#nat">nat</a> helper.
	<p>
	Example: <b>dnat to 1.1.1.1 inface eth0 src 2.2.2.2 dst 3.3.3.3</b>
	<p>
	
<hr noshade size=1 width="100%">
	
	<a name="dscp"><h3><b>dscp</b> <font color="red">&lt;NUMBER&gt;</font> <font color="red">&lt;WHERE&gt;</font> [optional rule parameters]</h3>
	<br><h3><b>dscp</b> class <font color="red">&lt;CLASSID&gt;</font> <font color="red">&lt;WHERE&gt;</font> [optional rule parameters]</h3></a>
	The <b>dscp</b> helper sets the DSCP field in the header of the packets matching the optional rule parameters.
	
	<H4>Parameters</H4>
	<ul>
		<li>	<b>NUMBER</b> is a decimal or hex (0xNN) number to set the DSCP field to.
			<br>&nbsp;
			</li>

		<li>	<b>CLASSID</b> is any of the iptables supported DiffServ class values (EF, BE, CSxx, AFxx - check <b>iptables -j DSCP --help</b> for more information).
			<br>&nbsp;
			</li>

		<li>	<b>WHERE</b> tells FireHOL where to search for the specific traffic to be marked.
			<br>Currently, WHERE can be one of the build-in iptables chains attached to table <b>mangle</b>.
			(for example: INPUT, FORWARD, OUTPUT, PREROUTING, POSTROUTING - case does matter here).
			<br>&nbsp;
			</li>
			
		<li>	<b>optional rule parameters</b> is a set of rules that allow further restriction of the traffic that
			gets matched by this rule. See <a href="#parameters">Optional Rules Parameters</a> for more information.
			<br>&nbsp;
			</li>
		</ul>
	<br>Example 1: <b>dscp 32 OUTPUT</b>, will set the DSCP field to 32 of all packets sent by the local machine.
	<br>Example 2: <b>dscp 0x20 FORWARD</b>, will set DCSP to 0x20 (32) of all packets passing through the local machine.
	<br>Example 3: <b>dscp class EF FORWARD proto tcp dport 25 dst 1.1.1.1 src 2.2.2.2</b>, will set DSCP to DeffServ class EF
	for all packets sent by 2.2.2.2, passing through the local machine and targeting port TCP/25 of host 1.1.1.1.
	<p>

<hr noshade size=1 width="100%">
	
	<a name="ecn_shame"><h3><b>ecn_shame</b></h3></a>
	The <b>ecn_shame</b> helper checks if <a href="http://urchin.earth.li/ecn/">Explicit Congestion Notification (ECN)</a> is enabled in the kernel, and if it is, it fetches
	the <a href="http://urchin.earth.li/cgi-bin/ecn.pl?output=ip">ECN Hall of Shame</a> list and disables ECN for all hosts present in the list.
	<p>

<hr noshade size=1 width="100%">
	
	<a name="iptables"><h3><b>iptables</b> <font color="red">&lt;arguments&gt;</font></h3></a>
	<H4>Description</H4>
	The <b>iptables</b> command passes all its arguments to the real iptables command, during run-time.
	<p>
	You should not use in FireHOL configurations <b>/sbin/iptables</b> or other means to alter a FireHOL firewall.
	If you do, your commands will be run <u>before</u> FireHOL activates its firewall and while the <u>previous</u>
	firewall is still running. Also, since FireHOL will delete all <u>previous</u> firewall rules in order to
	activate the new firewall, any changes you will make, will be deleted too.
	<p>
	Always use the <b>iptables</b> directive to hook iptables commands in a FireHOL firewall. Nothing else.
	<p>

<hr noshade size=1 width="100%">
	
	<a name="mac"><h3><b>mac</b> <font color="red">&lt;IP&gt;</font> <font color="red">&lt;MAC&gt;</font></h3></a>
	The <b>mac</b> helper verifies that all traffic <b>comming in</b> with source the <b>IP</b> address, comes from the
	<b>MAC</b> address. The helper applies its rules to filter/INPUT and filter/FORWARD and checks the source IP address
	in combination with the source MAC address.
	<p>
	The same MAC address is allowed to use other IPs; only the specific IP is required to be used with the specified MAC
	address.
	<p>
	Packets with the given IP address but with wrong MAC address will be DROPped and a log (as in <A HREF="#loglimit">loglimit</a>)
	with label "MAC MISSMATCH" will appear in the system logs.
	<p>
	This helper has to be used before all interface or router statements. Of course, you can use as many mac statements as you wish.
	<p>
	Example: <b>mac 195.97.5.202 00:02:8a:21:a9:d8</b>
	<p>

<hr noshade size=1 width="100%">
	
	<a name="mark"><h3><b>mark</b> <font color="red">&lt;NUMBER&gt;</font> <font color="red">&lt;WHERE&gt;</font> [optional rule parameters]</h3></a>
	The <b>mark</b> helper marks the traffic with a specific mark NUMBER that can be matched by traffic shapping tools
	for controlling the traffic.
	
	<H4>Parameters</H4>
	<ul>
		<li>	<b>NUMBER</b> is a number to mark the packets with.
			<br>&nbsp;
			</li>

		<li>	<b>WHERE</b> tells FireHOL where to search for the specific traffic to be marked.
			<br>Currently, WHERE can be one of the build-in iptables chains attached to table <b>mangle</b>.
			(for example: INPUT, FORWARD, OUTPUT, PREROUTING, POSTROUTING - case does matter here).
			<br>&nbsp;
			</li>
			
		<li>	<b>optional rule parameters</b> is a set of rules that allow further restriction of the traffic that
			gets matched by this rule. See <a href="#parameters">Optional Rules Parameters</a> for more information.
			<br>&nbsp;
			</li>
		</ul>
	<br>Example 1: <b>mark 1 OUTPUT</b>, will mark with 1 all packets send by the local machine.
	<br>Example 2: <b>mark 2 FORWARD</b>, will mark with 2 all packets passing through the local machine.
	<br>Example 3: <b>mark 3 FORWARD proto tcp dport 25 dst 1.1.1.1 src 2.2.2.2</b>, will match with 3
	all packets sent by 2.2.2.2, passing through the local machine and targeting port TCP/25 of host 1.1.1.1.
	<p>

<hr noshade size=1 width="100%">
	
	<a name="masquerade"><h3><b>masquerade</b> [reverse | interface] [optional rule parameters]</h3></a>
	Masquerading is a special from of SNAT (Source NAT) that changes the source of requests when they go out and replaces their original source when replies come in.
	This way a Linux box can become an internet router for a LAN of clients having unroutable IP addresses. Masquerading takes care to re-map IP addresses and ports as
	required.
	<p>
	Masquerading is "expensive" compared to SNAT because it checks the IP address of the ougoing interface every time for every packet, and therefore it is suggested that
	if you connect to the internet with a static IP address, to prefer SNAT.
	<p>
	The <b>masquerade</b> helper sets up masquerading on the output of a network interface (not the <a href="#interface">interface</a> command, but a real network interface).
	<br>
	<br>If the <b>masquerade</b> command is placed within an <a href="#interface">interface</a> command, its network interface(s) will be used.
	<br>If the <b>masquerade</b> command is placed within a <a href="#router">router</a> command that has an <a href="#outface">outface</a> defined, then the <a href="#outface">outface</a> network interface(s) will be used.
	<br>If placed within a <a href="#router">router</a> command but the keyword <b>reverse</b> is specified and the <a href="#router">router</a> command has an <a href="#inface">inface</a> defined, then the <a href="#inface">inface</a> network interface(s) will be used.
	<br>If placed outside and before all <a href="#primary_commands">primary commands</a>, an interface (or list of space separated interfaces, within double quotes) can be specified on the <b>masquerade</b> command.
	<p>
	In all cases, <b>masquerade</b> will setup itself on the <b>output</b> of the given interface(s).
	<p>
	Please note that if <b>masquerade</b> is used within some <a href="#interface">interface</a> or <a href="#router">router</a>, it does not respect the optional rule parameters
	given to this interface or router command. <b>Masquerade</b> uses <u>only</u> its own <a href="#parameters">optional rule parameters</a>.
	<p>
	<a href="#inface">inface</a> and <a href="#outface">outface</a> should not be given as parameters to <b>masquerade</b> (inface because iptables does not support this
	in the POSTROUTING chain, and outface because it will be overwritten by the interface(s) mentioned above).
	<p>
	Finally, the <b>masquerade</b> helper will turn on <a href="#FIREHOL_NAT">FIREHOL_NAT</a> and instruct the kernel to do packet forwarding (like the <a href="#router">router</a>
	commands do).
	<p>
	Example 1: before the first interface or router: <b>masquerade eth0 src 10.0.0.0/8 dst not 10.0.0.0/8</b>
	<br>Example 2: within an interface: <b>masquerade</b>, to masquerade on the output of this interface
	<br>Example 3: within a router: <b>masquerade reverse</b>, to masquerade on the output of the router's inface.
	<p>
	
<hr noshade size=1 width="100%">
	
	<a name="nat"><h3><b>nat</b> <font color="red">&lt;type&gt; &lt;target&gt;</font> [optional rule parameters]</h3></a>
	The <b>nat</b> helper sets up a NAT rule for routed traffic.
	<p>
	The <b>type</b> parameter can be:
	<ul>
		<li><b>to-source</b>, to define a Source NAT (created in NAT/POSTROUTING).
		<br>The <b>target</b> in this case is the source address to be set in packets matching the
		optional rule parameters (if no optional rule parameters, all forwarded traffic will be matched).
		<b>target</b> accepts all <b>--to-source</b> values <b>iptables</b> accepts (see <b>iptables -j SNAT --help</b>).
		Multiple --to-source values can be given, if separated by space and quoted as a single argument.
		<p>
		<a href="#inface">inface</a> should not be used in SNAT, because iptables does not provide this information
		at this point.
		<p>
		<b>YOU HAVE TO MAKE SURE THAT THE SOURCE ADDRESS YOU SPECIFY IS SUCH THAT THE REPLIES WILL BE SEND BACK
		TO THE HOST DOING THE NAT.</b> If the traffic does not get back to this host, then SNAT will simply not work.
		<p>
		THE PACKET FILTERING MECHANISM WILL <b>NOT KNOW</b> THE CHANGE OF THE SOURCE ADDRESS. For packet filtering
		(client, server, route statements in interfaces and routers), the
		traffic will flow in both directions with its <b>real</b> source address (i.e. real = as it is, before SNATed).
		For the host doing the NAT, <b>real</b> is "where do I have to really send it?"
		<br>&nbsp;
		</li>
		<li><b>to-destination</b>, to define a Destination NAT (created in NAT/PREROUTING).
		<br>The <b>target</b> in this case is the destination address to be set in packets matching the
		optional rule parameters (if no optional rule parameters, all forwarded traffic will be matched).
		<b>target</b> accepts all <b>--to-destination</b> values <b>iptables</b> accepts (see <b>iptables -j DNAT --help</b>).
		Multiple --to-destination values can be given, if separated by space and quoted as a single argument (in
		which case DNAT becomes a load-balancer).
		<p>
		<a href="#outface">outface</a> should not be used in DNAT, because iptables does not provide this information
		at this point.
		<p>
		THE PACKET FILTERING MECHANISM WILL <b>KNOW</b> THE CHANGE OF THE DESTINATION ADDRESS. For packet filtering
		(client, server, route statements in interfaces and routers), the
		traffic will flow in both directions with its <b>real</b> destination address (i.e. real = as it is, after DNATed).
		For the host doing the NAT, <b>real</b> is "where do I have to really send it?"
		<br>&nbsp;
		</li>
		<li><b>redirect-to</b>, to catch traffic comming in and send it to the local machine (created in NAT/PREROUTING).
		<br>The <b>target</b> in this case is a port or a range of ports (XXX-YYY) that packets matching the rule
		will be redirected to (if no optional rule parameters are given, all incomming traffic will be matched).
		<b>target</b> accepts all <b>--to-ports</b> values <b>iptables</b> accepts (see <b>iptables -j REDIRECT --help</b>).
		<p>
		<a href="#outface">outface</a> should not be used in REDIRECT, because iptables does not provide this information
		at this point.
		<p>
		THE PACKET FILTERING MECHANISM WILL <b>KNOW</b> THE CHANGE OF THE DESTINATION PORT. For packet filtering
		(client, server statements in interfaces), the
		traffic will flow in both directions with its <b>real</b> destination port (i.e. real = as it is, after REDIRECTed).
		For the host doing the NAT, <b>real</b> is "where do I have to really send it?"
		<br>&nbsp;
		</li>
	</ul>
	Please understand that the <b>optional rule parameters</b> are used only to limit the traffic to be matched.
	Consider these examples:
	<p>
	<center>
	<table border=0 cellpadding=5 cellspacing=1 width="80%">
	<tr bgcolor=black><th><font color=white>Command</th><th><font color=white>Description</th></tr>
	<tr>	<td nowrap align=center valign=middle>nat to-destination 1.1.1.1</td>
		<td>Sends to 1.1.1.1 all traffic comming in or passing trhough the firewall host.</td>
		</tr>
	<tr bgcolor="#F0F0F0">	<td nowrap align=center valign=middle>nat to-destination 1.1.1.1 dst 2.2.2.2</td>
		<td>Redirects to 1.1.1.1 all traffic comming in or passing through, and going to 2.2.2.2.</td>
		</tr>
	<tr>	<td nowrap align=center valign=middle>nat to-destination 1.1.1.1 proto tcp dst 2.2.2.2</td>
		<td>Redirects to 1.1.1.1 all TCP traffic comming in or passing through and going to 2.2.2.2.</td>
		</tr>
	<tr bgcolor="#F0F0F0">	<td nowrap align=center valign=middle>nat to-destination 1.1.1.1 proto tcp dport 25 dst 2.2.2.2</td>
		<td>Redirects to 1.1.1.1 all traffic comming in or passing through and going to 2.2.2.2 to port tcp/25.</td>
		</tr>
	<tr bgcolor="#F0F0F0">	<td nowrap align=center valign=middle>nat to-destination 1.1.1.1 proto tcp dport 25 dst 2.2.2.2 src 3.3.3.3</td>
		<td>Redirects to 1.1.1.1 all traffic comming in or passing through from 3.3.3.3 and going to 2.2.2.2 to port tcp/25.</td>
		</tr>
	</table>
	</center>
	<p>
	Example 1: <b>nat to-source 1.1.1.1 outface eth0 src 2.2.2.2 dst 3.3.3.3</b>
	<br>Example 2: <b>nat to-destination 4.4.4.4 inface eth0 src 5.5.5.5 dst 6.6.6.6</b>
	<br>Example 3: <b>nat redirect-to 8080 inface eth0 src 2.2.2.0/24 proto tcp dport 80</b>
	<p>
	
<hr noshade size=1 width="100%">

	<a name="redirect"><h3><b>redirect</b> [to] <font color="red">&lt;target&gt;</font> [optional rule parameters]</h3></a>
	The <b>redirect</b> helper catches all incomming traffic matching the optional rule parameters given and
	redirects it to ports on the local host, by calling<br>
	<b>nat redirect-to &lt;target&gt [optional rule parameters]</b>
	<p>
	See the <a href="#nat">nat</a> helper.
	<p>
	Example: <b>redirect to 8080 inface eth0 src 2.2.2.0/24 proto tcp dport 80</b>
	<p>

<hr noshade size=1 width="100%">
	
	<a name="snat"><h3><b>snat</b> [to] <font color="red">&lt;target&gt;</font> [optional rule parameters]</h3></a>
	The <b>snat</b> helper sets up a Source NAT rule for routed traffic, by calling<br>
	<b>nat to-source &lt;target&gt [optional rule parameters]</b>
	<p>
	See the <a href="#nat">nat</a> helper.
	<p>
	Example: <b>snat to 1.1.1.1 outface eth0 src 2.2.2.2 dst 3.3.3.3</b>
	<p>
	
<hr noshade size=1 width="100%">
	
	<a name="tcpmss"><h3><b>tcpmss</b> <font color="red">&lt;what&gt;</font></h3></a>
	The <b>tcpmss</b> helper sets the MSS (Maximum Segment Size) of TCP SYN packets routed through the firewall.
	Its purpose is to overcome situations where Path MTU Discovery is not working and packet
	fragmentation is not possible.
	<p>
	Within FireHOL, it can be defined either before any primary command, in which case it is applied to all
	traffic passing through the firewall, or to any <b>router</b>, in which case it is applied to traffic
	matched by the router. In both cases, TCP SYN packets in both directions (in/out) are altered.
	<p>
	The argument can either be the word <b>auto</b> or a number:
	<ul>
		<li>	The word <b>auto</b> will make the TCP connections have MSS equal to the MTU of the
			outgoing intefrace minus 40 (clamp-mss-to-pmtu).</li>
		<li>	A numeric argument will make the TCP connections have MSS equal to the number given.</li>
	</ul>
	<p>
	See also <a href="http://lartc.org/howto/lartc.cookbook.mtu-mss.html">Circumventing Path MTU Discovery issues with MSS Clamping (for ADSL, cable, PPPoE & PPtP users)</a>
	in the <a href="http://lartc.org/howto/">Linux Advanced Routing & Traffic Control HOWTO</a>.
	<p>
	Example 1: <b>tcpmss auto</b>
	<br>Example 2: <b>tcpmss 500</b>
	<p>

<hr noshade size=1 width="100%">
	
	<a name="tos"><h3><b>tos</b> <font color="red">&lt;NUMBER&gt;</font> <font color="red">&lt;WHERE&gt;</font> [optional rule parameters]</h3></a>
	The <b>tos</b> helper sets the Type of Service (TOS) in packets.
	
	<H4>Parameters</H4>
	<ul>
		<li>	<b>NUMBER</b> is a number to set TOS to. FireHOL supports decimal numbers, hex numbers and the
			descriptive values iptables supports. For more information see <b>iptables -j TOS --help</b>.
			<br>&nbsp;
			</li>

		<li>	<b>WHERE</b> tells FireHOL where to search for the specific traffic to be marked.
			<br>Currently, WHERE can be one of the build-in iptables chains attached to table <b>mangle</b>.
			(for example: INPUT, FORWARD, OUTPUT, PREROUTING, POSTROUTING - case does matter here).
			<br>&nbsp;
			</li>
			
		<li>	<b>optional rule parameters</b> is a set of rules that allow further restriction of the traffic that
			gets matched by this rule. See <a href="#parameters">Optional Rules Parameters</a> for more information.
			<br>&nbsp;
			</li>
		</ul>
	<br>Example 1: <b>tos 16 OUTPUT</b>, will set TOS to 16 for all packets sent by the local machine.
	<br>Example 2: <b>tos 0x10 FORWARD</b>, will set TOS to 0x10 (16) for all packets passing through the local machine.
	<br>Example 3: <b>tos Maximize-Throughput FORWARD proto tcp dport 25 dst 1.1.1.1 src 2.2.2.2</b>, will set TOS to Maximize-Throughput (8)
	for all packets sent by 2.2.2.2, passing through the local machine and targeting port TCP/25 of host 1.1.1.1.
	<p>

<hr noshade size=1 width="100%">
	
	<a name="transparent_proxy"><h3><b>transparent_proxy</b> <font color="red">&lt;service&gt; &lt;port&gt; &lt;user&gt;</font> [optional rule parameters]</h3></a>
	The <b>transparent_proxy</b> helper sets up trasparent proxy server for TCP traffic.
	The proxy is assumed to be running on the firewall host at port <b>port</b>, with the credentials of the local user <b>user</b> serving TCP port's <b>service</b> requests.
	<p>
	The <b>transparent_proxy</b> helper can be used for two kinds of traffic:
	<ul>
		<li>Incomming TCP traffic, either targeted to the firewall host or passing through the firewall host.
		<br>The optional rule parameters can be used to specify which kind of <b>incomming</b> traffic to be catched
		(by using <a href="#inface">inface</a>, <a href="#src">src</a>, <a href="#dst">dst</a>, etc --
		<a href="#outface">outface</a> should not be used here, because the rules generated are placed before
		the routing decision and therefore the outgoing interface is not yet known).
		<p>
		If no optional rule parameters are given, then the transparent
		proxy will be setup on <b>all network interfaces for all TCP traffic</b> (use this with care since you are
		risking to serve requests from the internet using your proxy).
		<br>&nbsp;
		</li>
		<li>Locally generated outgoing TCP traffic, except TCP traffic generated by processes running as the <b>user</b> argument.
		The optional rule parameters <a href="#inface">inface</a>, <a href="#outface">outface</a> and <a href="#src">src</a> are
		ignored for this type of traffic.
		<p>
		This kind of matching makes it possible to support transparent proxying for clients running on the firewall
		host, as far as they do not run as the user excluded. More than one users can be specified by space-separating
		and enclosing them in double quotes.
		<p>
		This rule can be disabled by specifing as user the empty string: <b>""</b>
		<br>&nbsp;
		</li>
	</ul>
	<p>
	Of course, make sure that your firewall allows requests to reach your proxy server.
	<p>
	Example 1: <b>transparent_proxy 80 3128 squid inface eth0 src 10.0.0.0/8</b> to redirect all tcp/80 requests coming in from eth0 (10.0.0.0/8) to your local web caching proxy server listening at port 3128 and running as user squid.
	<br>Example 2: <b>transparent_proxy "80 3128 8080" 8080 "squid privoxy root bin" inface not "ppp+ ipsec+" dst not "a.not.proxied.server"</b>
	to redirect all web and proxy requests (tcp: 80, 3128, 8080) coming in from all interfaces except ppp+ and ipsec+ to your local squid server listening at tcp/8080 except those requests generated by the local users squid, privoxy, root and bin, and all matching traffic that is targeting host 'a.not.proxied.server'.
	<p>

<hr noshade size=1 width="100%">
	
	<a name="transparent_squid"><h3><b>transparent_squid</b> <font color="red">&lt;port&gt; &lt;user&gt;</font> [optional rule parameters]</h3></a>
	The <b>transparent_squid</b> helper sets up trasparent caching for HTTP traffic.
	It is equivalent to:<p>
	
	<a href="#transparent_proxy">transparent_proxy</a> 80 &lt;port&gt; &lt;user&gt; [optional rule parameters]
	
	<p>     
	Example 1: <b>transparent_squid 3128 squid inface eth0 src 10.0.0.0/8</b>
	<br>Example 2: <b>transparent_squid 8080 "squid privoxy root bin" inface not "ppp+ ipsec+" dst not "a.not.proxied.server"</b>
	<p>

<hr noshade size=1 width="100%">
	
	<a name="version"><h3><b>version</b> <font color="red">&lt;number&gt;</font></h3></a>
	<H4>Description</H4>
	The <b>version</b> command states the FireHOL <u>release</u> the configuration file was
	created for. In case the configuration file is newer than FireHOL, FireHOL will deny
	to run it.
	<p>
	This command is here to allow you or anyone else design and distribute FireHOL configuration files, while
	ensuring that the correct FireHOL version is going to run them.
	<p>
	Since FireHOL configurations are BASH script, it is relatively easy to use FireHOL configurations as small
	scripts that dynamically process rules stored in a database, in a file system as separate files, or elsewhere.
	This directive will help the developers of FireHOL configurations to control the required version of
	FireHOL.
	<p>
	The FireHOL release is increased every time the format of the configuration file and the internals of FireHOL are changed.
	<p>
	Since FireHOL v1.67 <b>version</b> is not required to be present in every configuration file.
	<p>
	
<table border=0 cellpadding=10 cellspacing=0 width="100%"><tr bgcolor="#777777"><td align=center><font color="white"><b><big><a name="actions">Actions</a></td</tr></table>
<small>
Actions are the actions to be taken on services and traffic described by other commands and functions.
Please note that normally, FireHOL will pass-through to the generated iptables statements all the possible actions iptables accepts, but only the ones defined here can be used
with lower case letters and currently it will be impossible to pass arguments to some unknown action. Also, keep in mind that the iptables action LOG is a FireHOL optional rule
parameter (see <a href="#log">log</a> and <a href="#loglimit">loglimit</a>) that can be defined together with one of the following actions and FireHOL will actually produce
multiple iptables statements to achieve both the logging and the action.
</small>
<p>

	<a name="accept"><h3><b>accept</b> [with limit &lt;frequency&gt; &lt;burst&gt; [overflow &lt;action&gt;]]</h3></a>
	<h3><b>accept</b> [with knock &lt;name&gt;]</h3>
	<b>accept</b> allows the traffic matching the rules to reach its destination.
	<p>
	<b>with limit</b><br>
	The optional parameter <b>with limit</b> offers control over the allowed frequency of NEW connections. <b>frequency</b> and <b>burst</b> have the same syntax of the <a href="#limit">limit</a>
	optional rule parameter.
	<p>
	The overflow <b>action</b> offers control over the overflowed NEW connections. The default is to REJECT overflowed connections (not DROP them, since DROP produces timeouts
	on the otherwise valid service clients). Also, the REJECT overflow action, will reject TCP connections with <b>tcp-reset</b> and all others with <b>icmp-host-unreachable</b>.
	<br>
	The overflowed NEW connection attempts will be logged with a <b>OVERFLOW</b> message, with the options the <a href="#loglimit">loglimit</a> parameter works.
	<p>
	<b>with knock</b><br>
	The optional parameter <b>with knock</b> allows easy integration with <a href="http://www.zeroflux.org/knock/">knockd</a>, a server that allows you to control access to services, by sending certain packets to "knock" the
	door, before the door is open for service.<br>
	This parameter accepts just a name. This name is used to build a special chain <b>knock_&lt;name&gt;</b> which will contain just the rules to allow established connections to work,
	but it prevent any new connections from taking place. In case, knockd has not allowed new connections, this traffic entering this chain will just return back
	and continue to match against the other rules until the end of the firewall.
	<p>
	How to use it: lets say that you want to allow https traffic based on a knock. In FireHOL you write:
	<p>
	<pre>server https accept with knock hidden</pre>
	<p>
	and you configure knockd so that it runs:
	<p>
	<pre>iptables -A knock_hidden -s %IP% -j ACCEPT</pre>
	<p>
	to enable the https service (notice that there is no need to match anything else than the IP. FireHOL already matches everything needed for its rules to work), and:
	<p>
	<pre>iptables -D knock_hidden -s %IP% -j ACCEPT</pre>
	<p>
	to disable this service for the given IP.
	<p>
	You can use the same knock name in more than one FireHOL services to enable/disable all the services together, without any extra effort in knockd configuration (just one ACCEPT row like above
	- i.e. the same knock as far as knockd is concerned - will allow all the FireHOL services with the same knock name to serve requests for the given IP).
	Check also <a href="https://sourceforge.net/forum/forum.php?thread_id=1199404&forum_id=196547">this forum post</a>.
	<p>
	Example 1: <b>server smtp accept</b>, to allow SMTP requests and their replies to flow.<br>
	Example 2: <b>server smtp accept with limit 10/s 100</b>, to allow SMTP requests to come at 10/second max, with a burst of 100, and their replies to flow back.<br>
	Example 3: <b>server smtp accept with limit 10/s 100 overflow drop</b>, to allow SMTP requests to come at 10/second max, with a burst of 100, and their replies to flow back. The overflow requests will be dropped.<br>
	Example 4: <b>server smtp accept with limit 10/s 100 src "1.2.3.4 5.6.7.8"</b>, same as example 2, but the only valid clients are given as argument to <b>src</b>
	<p>

<hr noshade size=1 width="100%">

	<a name="reject"><h3><b>reject</b> [with &lt;message&gt;]</h3></a>
	<b>reject</b> discards the matching traffic but sends a rejecting message back to the sender.
	<p>
	<b>with</b> is used to offer control on the message to be returned to the sender.
	<b>with</b> accepts all the arguments the <b>--reject-with</b> iptables expression accepts. For an updated list
	of these messages type <b>iptables -j REJECT --help</b>. Bellow you can find the list my system accepts.
	<p>
	By default (no <b>with</b> argument given), <b>reject</b> will send an <b>icmp-port-unreachable</b> on all protocols
	except TCP, for which it will send a <b>tcp-reset</b>.
	<p>
	<center>
	<table border=0 cellpadding=3 cellspacing=5 width="70%">
	<tr><th bgcolor="#000000"><font color="white">Message</th><th bgcolor="#000000"><font color="white">Alias</th><th bgcolor="#000000"><font color="white">Description</th><th bgcolor="#000000"><font color="white">Reference</th></tr>
	<tr>	<td align="center"><b>icmp-net-unreachable</td>
		<td align="center"><b>net-unreach</td>
		<td><b>ICMP network unreachable</b>
		<p><small><b><font color="gray">From RFC 1812 section 5.2.7.1</font></b></small><br>
		Generated by a router if a forwarding path (route) to the destination network is not available.
		<p><small><b><font color="gray">Notes</font></b></small><br>
		Use this with care. The sender and the routers between you and the sender may conclude that
		the whole network your host resides in, is unreachable and prevent other traffic from
		reaching you.
		</td>
		<td align="center"><a href="http://www.ietf.org/rfc/rfc1812.txt?number=1812">RFC 1812</a>
		<a href="http://www.ietf.org/rfc/rfc0792.txt?number=792">RFC 792</a></td>
		</tr>
	<tr bgcolor="#F0F0F0">	<td align="center"><b>icmp-host-unreachable</td>
		<td align="center"><b>host-unreach</td>
		<td><b>ICMP host unreachable</b>
		<p><small><b><font color="gray">From RFC 1812 section 5.2.7.1</font></b></small><br>
		Generated by a router if a forwarding path (route) to the destination host on a directly connected network
		is not available (does not respond to ARP).
		<p><small><b><font color="gray">Notes</font></b></small><br>
		Use this with care. The sender and the routers between you and the sender may conclude that
		your server is unreachable and prevent the transmission of other traffic to you.
		</td>
		<td align="center"><a href="http://www.ietf.org/rfc/rfc1812.txt?number=1812">RFC 1812</a>
		<a href="http://www.ietf.org/rfc/rfc0792.txt?number=792">RFC 792</a></td>
		</tr>
	<tr>	<td align="center"><b>icmp-proto-unreachable</td>
		<td align="center"><b>proto-unreach</td>
		<td><b>ICMP protocol unreachable</b>
		<p><small><b><font color="gray">From RFC 1812 section 5.2.7.1</font></b></small><br>
		Generated if the transport protocol designated in a datagram is not supported in the transport layer
		of the final destination.
		</td>
		<td align="center"><a href="http://www.ietf.org/rfc/rfc1812.txt?number=1812">RFC 1812</a>
		<a href="http://www.ietf.org/rfc/rfc0792.txt?number=792">RFC 792</a></td>
		</tr>
	<tr bgcolor="#F0F0F0">	<td align="center"><b>icmp-port-unreachable</td>
		<td align="center"><b>port-unreach</td>
		<td><b>ICMP port unreachable</b> (default)
		<p><small><b><font color="gray">From RFC 1812 section 5.2.7.1</font></b></small><br>
		Generated if the designated transport protocol (e.g. TCP, UDP, etc) is unable to demultiplex the
		datagram in the transport layer of the final destination but has no protocol mechanism to inform
		the sender.
		<p><small><b><font color="gray">In other words</font></b></small><br>
		Generated by hosts to indicate that the required port is not active.</td>
		<td align="center"><a href="http://www.ietf.org/rfc/rfc1812.txt?number=1812">RFC 1812</a>
		<a href="http://www.ietf.org/rfc/rfc0792.txt?number=792">RFC 792</a></td>
		</tr>
	<tr>	<td align="center"><b>icmp-net-prohibited</td>
		<td align="center"><b>net-prohib</td>
		<td><b>ICMP communication with destination network administratively prohibited</b>
		<p><small><b><font color="gray">From RFC 1812 section 5.2.7.1</font></b></small><br>
		This code was intended for use by end-to-end encryption devices used by U.S military agencies.
		Routers SHOULD use the newly defined Code 13 (Communication Administratively Prohibited) if they
		administratively filter packets.
		<p><small><b><font color="gray">In other words</font></b></small><br>
		Use it, but don't expect that this will be widely understood.
		</td>
		<td align="center"><a href="http://www.ietf.org/rfc/rfc1812.txt?number=1812">RFC 1812</a>
		<a href="http://www.ietf.org/rfc/rfc1122.txt?number=1122">RFC 1122</a></td>
		</tr>
	<tr bgcolor="#F0F0F0">	<td align="center"><b>icmp-host-prohibited</td>
		<td align="center"><b>host-prohib</td>
		<td><b>ICMP communication with destination host administratively prohibited</b>
		<p><small><b><font color="gray">From RFC 1812 section 5.2.7.1</font></b></small><br>
		This code was intended for use by end-to-end encryption devices used by U.S military agencies.
		Routers SHOULD use the newly defined Code 13 (Communication Administratively Prohibited) if they
		administratively filter packets.
		<p><small><b><font color="gray">In other words</font></b></small><br>
		Use it, but don't expect that this will be widely understood.
		</td>
		<td align="center"><a href="http://www.ietf.org/rfc/rfc1812.txt?number=1812">RFC 1812</a>
		<a href="http://www.ietf.org/rfc/rfc1122.txt?number=1122">RFC 1122</a></td>
		</tr>
	<tr>	<td align="center"><b>tcp-reset</td>
		<td align="center"><b>tcp-reset</td>
		<td><b>TCP RST</b>
		<p>
		This is the port unreachable message of the TCP stack. It is useful when you want to prevent
		timeouts on rejected TCP services when the client is badly written to ignore ICMP port unreachable
		messages.
		<p>
		I suggest to use this for rejecting idents:<br><b>server ident reject with tcp-reset</b>.
		</td>
		<td align="center"><a href="http://www.ietf.org/rfc/rfc1122.txt?number=1122">RFC 1122</a></td>
		</tr>
	</table>
	</center>
	<br>
	<br>Example 1: <b>policy reject with host-unreach</b>
	<br>Example 2: <b>server ident reject with tcp-reset</b>
	<br>Example 3: <b>UNMATCHED_INPUT_POLICY="reject with host-prohib"</b>
	<p>
	
<hr noshade size=1 width="100%">

	<a name="drop"><h3><b>drop</b></h3></a>
	<b>drop</b> silently discards the matching traffic.
	The fact that the traffic is silently discarded makes the sender timeout in order to conclude that it is not
	possible to use the wanted service.
	<p>
	Example: <b>server smtp drop</b>, to silently discard SMTP requests and their replies.
	<p>
	
<hr noshade size=1 width="100%">

	<a name="deny"><h3><b>deny</b></h3></a>
	<b>deny</b> is just an alias for <a href="#drop">drop</a>, made for those who are used to ipchains terminology.
	<p>
	Example: <b>server smtp deny</b>, to silently discard SMTP requests and their replies.
	<p>

<hr noshade size=1 width="100%">

	<a name="return"><h3><b>return</b></h3></a>
	<b>return</b> will return the flow of processing to the parent of the current command.
	Currently, it has meaning to specify the action <b>return</b> only as a <a href="#policy">policy</a> to some <a href="#interface">interface</a>.
	<p>
	Example: <b>policy return</b>, to have traffic not matched by any rule within an <a href="#interface">interface</a> to continue traveling through the
	firewall and possibly matched by other <a href="#interface">interfaces</a> bellow.
	<p>
	
<hr noshade size=1 width="100%">

	<a name="mirror"><h3><b>mirror</b></h3></a>
	<b>mirror</b> will return the traffic to the wanted port, back to the sending host.
	Use this with care, and only if you understand what you doing.
	Keep also in mind that FireHOL will apply this action to both requests and replies comming in or passing through,
	and will replace it with REJECT for traffic generated by the local host.
	<p>
	
<hr noshade size=1 width="100%">

	<a name="redirect"><h3><b>redirect</b> [to-port port]</h3></a>
	<b>redirect</b> is used internally by FireHOL <a href="#helpers">Helper Commands</a> to redirect traffic to ports on the local host.
	Unless you are a developer, you will never need to use this directly.
	<p>


<table border=0 cellpadding=10 cellspacing=0 width="100%"><tr bgcolor="#777777"><td align=center><font color="white"><b><big><a name="parameters">Optional Rule Parameters</a></td</tr></table>
<small>
Optional rule parameters are accepted by many commands to narrow the match they do by default.
The parameters described bellow are all that FireHOL supports. You should check the documentation of each command to find which parameters should not be used with it.
Normally, all FireHOL commands are designed so that if you specify a parameters that is also used internally, the internal one will overwrite the one given in the configuration file. In such a case,
FireHOL will present you a warning with the old and the new value.<p>
Not all parameters should be used in all cases. For example <a href="#sport">sport</a> and <a href="#dport">dport</a> should not be used in normal <a href="#server">server</a> and
<a href="#client">client</a> commands since such ports are internally defined by the <a href="services.html">services</a> themselves. In any case, FireHOL will complain
about optional rule parameters that should not be used in certain commands.
</small>
<p>

	<a name="src"><h3><b>src</b> [not] <font color="red">&lt;host&gt;</font></h3></a>
	<H4>Description</H4>
	<b>src</b> defines the source IP address of the <u>REQUEST</u>. If <b>src</b> is defined on a <b>server</b> statement it matches the
	source of the request which is the remote host, while if it is defined on a <b>client</b> statement it matches <u>again</u>
	the source of the request, but this time it is the local host. <b>Focus on the REQUEST!!!</b> Forget the reply.
	<p>
	<H4>Parameters</H4>
	<ul>
		<li>	<b>not</b> is an optional argument that reverses the match. When defined, the rule will match all hosts
			except the ones defined.
			<br>Example: <b>server smtp accept src not 1.2.3.4</b>
			<br>&nbsp;
			</li>

		<li>	<b>host</b> can be an IP address, a hostname, or a subnet.
			<br>Multiple hosts/networks can be defined if separated by space and quoted as a single argument.
			<br>Example 1: <b>server smtp accept src 1.2.3.4</b>
			<br>Example 2: <b>server smtp accept src not "1.2.3.0/24 5.6.7.8 badhost.example.com"</b>
			<br>&nbsp;
			</li>
		</ul>
	<p>

<hr noshade size=1 width="100%">

	<a name="dst"><h3><b>dst</b> [not] <font color="red">&lt;host&gt;</font></h3></a>
	<H4>Description</H4>
	<b>dst</b> defines the destination of the <u>REQUEST</u>. If <b>dst</b> is defined on a <b>server</b> statement it matches the
	destination of the request which is the local host, while if it is defined on a <b>client</b> statement it matches <u>again</u>
	the destination of the request, but this time it is the remote host. <b>Focus on the REQUEST!!!</b> Forget the reply.
	<p>
	<b>dst</b> accepts the same parameters as <b>src</b>
	<p>
	
<hr noshade size=1 width="100%">

	<a name="inface"><h3><b>inface</b> [not] <font color="red">&lt;interface&gt;</font></h3></a>
	<H4>Description</H4>
	<b>inface</b> defines the interface the <u>REQUEST</u> is received via.
	<b>inface</b> cannot be used in <b>interface</b> commands.
	<p>
	<H4>Parameters</H4>
	<ul>
		<li>	<b>not</b> is an optional argument that reverses the match. When defined, the rule will match all interfaces
			except the ones defined.
			<br>Example: <b>server smtp accept inface not eth0</b>
			<br>&nbsp;
			</li>

		<li>	<b>interface</b> if an interface name in the same format the <b>interface</b> command accepts.
			<br>Multiple interfaces can be defined if separated by space and quoted as a single argument.
			<br>Example 1: <b>server smtp accept inface not eth0</b>
			<br>Example 2: <b>server smtp accept inface not "eth0 eth1"</b>
			<br>&nbsp;
			</li>
		</ul>
	<p>

<hr noshade size=1 width="100%">

	<a name="outface"><h3><b>outface</b> [not] <font color="red">&lt;interface&gt;</font></h3></a>
	<H4>Description</H4>
	<b>outface</b> defines the interface the <u>REQUEST</u> is send via.
	<b>outface</b> cannot be used in <b>interface</b> commands.
	<p>
	<b>outface</b> accepts the same parameters as <b>inface</b>.
	<p>

<hr noshade size=1 width="100%">

	<a name="physin"><h3><b>physin</b> [not] <font color="red">&lt;interface&gt;</font></h3></a>
	<H4>Description</H4>
	<b>physin</b> defines the physical interface the <u>REQUEST</u> is received via and is used in cases where <b>inface</b> is defined as
	a virtual interface (such as a bridge interface). In such cases, the <b>physdev</b> iptables module (which is used by <b>physin</b>)
	can be used to match the physical network interface the REQUEST is recieved via.
	<p>
	<b>physin</b> accepts the same parameters as <b>inface</b>.
	<p>

<hr noshade size=1 width="100%">

	<a name="physout"><h3><b>physout</b> [not] <font color="red">&lt;interface&gt;</font></h3></a>
	<H4>Description</H4>
	<b>physout</b> defines the physical interface the <u>REQUEST</u> is send via and is used in cases where <b>outface</b> is defined as
	a virtual interface (such as a bridge interface). In such cases, the <b>physdev</b> iptables module (which is used by <b>physout</b>)
	can be used to match the physical network interface the REQUEST is send via.
	<p>
	<b>physout</b> accepts the same parameters as <b>outface</b>.
	<p>

<hr noshade size=1 width="100%">

	<a name="custom"><h3><b>custom</b> "<font color="red">parameters</font>"</h3></a>
	<H4>Description</H4>
	<b>custom</b> passes its arguments to the generated iptables commands.
	<p>It is required to quote all the parameters given to <b>custom</b>. If the parameters include a space character
	between some text that is required to be given to iptables as one argument, it is required to escape another set of
	quotes in order. Another way is to use double quotes externally and single quotes internally.
	<br>
	<br>Example 1: <b>server smtp accept custom "--some-iptables-option and_its_value"</b>
	<br>Example 2: <b>server smtp accept custom "--some-iptables-option 'one_value another_value'"</b>
	<p>

<hr noshade size=1 width="100%">

	<a name="log"><h3><b>log</b> <font color="red">"&lt;some text&gt;"</font> [<b>level</b> a_level]</h3></a>
	<H4>Description</H4>
	<b>log</b> will log the matching packets to syslog. Note that this is not an action (in iptables it is).
	FireHOL will actually produce multiple iptables commands to accomplish both the action for the rule and the logging.
	You can control how logging works, by altering the variables <a href="#FIREHOL_LOG_MODE">FIREHOL_LOG_MODE</a>, <a href="#FIREHOL_LOG_OPTIONS">FIREHOL_LOG_OPTIONS</a> and
	<a href="#FIREHOL_LOG_LEVEL">FIREHOL_LOG_LEVEL</a>. You can also change the level of just one rule by using the
	<b>level</b> argument of the <b>log</b> parameter (only when FIREHOL_LOG_MODE=LOG).
	<p>
	FireHOL logs traffic, exactly the same way iptables does. Many users have complained about packet logs appearing at
	their console. To avoid this you will have to:
	<ul>
		<li>setup <b>klogd</b> to log only more important traffic</li>
		<li>change <a href="#FIREHOL_LOG_LEVEL">FIREHOL_LOG_LEVEL</a> to log at a not so important log-level</li>
	</ul>
	Actually <b>klogd</b>'s -c option and <b>iptables</b>' --log-level option are the same thing (iptables accepts also
	the numeric values klogd accepts). If iptables logs at a
	higher priority than klogd is configured to use, then your packets will appear in the console too.
	<p>
	In most kernels klogd is by default configured to log everything, so if you don't also change <b>klogd</b>'s -c option,
	the --log-level setting of iptables has no effect. Use the table bellow to match klogd options with --log-level options:
	
	<center>
	<table border=0 cellpadding=3 cellspacing=5 width="70%">
	<tr><th bgcolor="#000000"><font color="white">Priority</th><th bgcolor="#000000"><font color="white">klogd</th><th bgcolor="#000000"><font color="white">iptables</th><th bgcolor="#000000"><font color="white">Description</th></tr>
	<tr>	<td align="center"><b>0</td>
		<td align="center">0</td>
		<td align="center">emerg</td>
		<td>system is unusable</td>
		</tr>
	<tr bgcolor="#F0F0F0">	<td align="center"><b>1</td>
		<td align="center">1</td>
		<td align="center">alert</td>
		<td>action must be taken immediately</td>
		</tr>
	<tr>	<td align="center"><b>2</td>
		<td align="center">2</td>
		<td align="center">crit</td>
		<td>critical conditions</td>
		</tr>
	<tr bgcolor="#F0F0F0">	<td align="center"><b>3</td>
		<td align="center">3</td>
		<td align="center">error</td>
		<td>error conditions</td>
		</tr>
	<tr>	<td align="center"><b>4</td>
		<td align="center">4</td>
		<td align="center">warning (default)</td>
		<td>warning conditions</td>
		</tr>
	<tr bgcolor="#F0F0F0">	<td align="center"><b>5</td>
		<td align="center">5</td>
		<td align="center">notice</td>
		<td>normal but significant condition</td>
		</tr>
	<tr>	<td align="center"><b>6</td>
		<td align="center">6</td>
		<td align="center">info</td>
		<td>informational</td>
		</tr>
	<tr bgcolor="#F0F0F0">	<td align="center"><b>7</td>
		<td align="center">7 (default)</td>
		<td align="center">debug</td>
		<td>debug-level messages</td>
		</tr>
	</table>
	</center><p>
	To prevent packet logs appearing to the console, <b>klogd</b> option must be LOWER than the one iptables uses.
	<p>
	On <a href="http://www.redhat.com">RedHat</a> systems, you can configure <b>klogd</b> by changing
	<b>/etc/sysconfig/syslog</b> and adding to <b>KLOGD_OPTIONS</b> the required -c level.
	<p>
	
<hr noshade size=1 width="100%">

	<a name="loglimit"><h3><b>loglimit</b> <font color="red">"&lt;some text&gt;"</font></h3></a>
	<H4>Description</H4>
	<b>loglimit</b> is the same with <b>log</b> but limits the frequency of logging according to the setting of
	<a href="#FIREHOL_LOG_FREQUENCY">FIREHOL_LOG_FREQUENCY</a> and <a href="#FIREHOL_LOG_BURST">FIREHOL_LOG_BURST</a>.
	<p>

<hr noshade size=1 width="100%">

	<a name="proto"><h3><b>proto</b> [not] <font color="red">&lt;protocol&gt;</font></h3></a>
	<H4>Description</H4>
	<b>proto</b> sets the required protocol for the traffic. This command accepts anything iptables accepts as
	protocols.
	<p>

<hr noshade size=1 width="100%">

	<a name="limit"><h3><b>limit</b> <font color="red">&lt;frequency&gt; &lt;burst&gt;</font></h3></a>
	<H4>Description</H4>
	<b>limit</b> will limit the match in both directions of the traffic (request and reply). This is used internally by FireHOL and its effects has not been tested in the high level
	configuration file directives.
	<p>

<hr noshade size=1 width="100%">

	<a name="sport"><h3><b>sport</b> <font color="red">&lt;port&gt;</font></h3></a>
	<H4>Description</H4>
	<b>sport</b> defines the source port of a request. It accepts port names, port numbers, port ranges (FROM:TO) and multiple ports (or ranges) seperated by spaces and quoted as a single argument.
	This parameter should not be used in normal <a href="services.html">services</a> definitions (<a href="#client">client</a> and <a href="#server">server</a> commands) or
	<a href="#interface">interface</a> and <a href="#router">router</a> definitions, unless you really understand what you are doing.
	<p>

<hr noshade size=1 width="100%">

	<a name="dport"><h3><b>dport</b> <font color="red">&lt;port&gt;</font></h3></a>
	<H4>Description</H4>
	<b>dport</b> defines the destination port of a request. It accepts port names, port numbers, port ranges (FROM:TO) and multiple ports (or ranges) seperated by spaces and quoted as a single argument.
	This parameter should not be used in normal <a href="services.html">services</a> definitions (<a href="#client">client</a> and <a href="#server">server</a> commands) or
	<a href="#interface">interface</a> and <a href="#router">router</a> definitions, unless you really understand what you are doing.
	<p>

<hr noshade size=1 width="100%">

	<a name="uid"><h3><b>uid</b> [not] <font color="red">&lt;user&gt;</font></h3></a>
	<a name="user"><h3><b>user</b> [not] <font color="red">&lt;user&gt;</font></h3></a>
	<H4>Description</H4>
	<b>uid</b> or <b>user</b> define the operating system user sending this traffic. The parameter can be a username, a user number or a list of these two, seperated by spaces and quoted as
	a single argument.<p>
	This parameter can be used only in services (<a href="#client">client</a> and <a href="#server">server</a> commands) defined within <a href="#interface">interfaces</a>, not <a href="#router">routers</a>.
	FireHOL is "smart" enough to apply this parameter only to traffic send by the localhost, i.e. the replies of <a href="#server">servers</a> and requests of <a href="#clients">clients</a>.
	It is not possible, and FireHOL will simply ignore this parameter, on traffic coming in or passign through the firewall host.
	<p>
	<br>Example 1: <b>client "pop3 imap" accept user not "user1 user2 user3" dst mymailer.example.com</b>
	<br>The above will allow local users except user1, user2 and user3 to use POP3 and IMAP services on mymailer.example.com.
	You can use this, for example, to allow only a few of the local users use the fetchmail program to fetch their mail from the mail server.
	<p>
	<br>Example 2: <b>server http accept user apache</b>
	<br>The above will allow all HTTP to reach the local http server, but only if the web server is running as user apache the replies will be send back to the HTTP client.
	<p>
	
<hr noshade size=1 width="100%">

	<a name="gid"><h3><b>gid</b> <font color="red">&lt;group&gt;</font></h3></a>
	<a name="group"><h3><b>group</b> <font color="red">&lt;group&gt;</font></h3></a>
	<H4>Description</H4>
	<b>gid</b> or <b>group</b> define the operating system user group sending this traffic. The parameter can be a group name, a group number or a list of these two, seperated by spaces and quoted as
	a single argument.<p>
	This parameter can be used only in services (<a href="#client">client</a> and <a href="#server">server</a> commands) defined within <a href="#interface">interfaces</a>, not <a href="#router">routers</a>.
	FireHOL is "smart" enough to apply this parameter only to traffic send by the localhost, i.e. the replies of <a href="#server">servers</a> and requests of <a href="#clients">clients</a>.
	It is not possible, and FireHOL will simply ignore this parameter, on traffic coming in or passign through the firewall host.
	<p>
	
<hr noshade size=1 width="100%">

	<a name="pid"><h3><b>pid</b> <font color="red">&lt;process&gt;</font></h3></a>
	<a name="process"><h3><b>process</b> <font color="red">&lt;process&gt;</font></h3></a>
	<H4>Description</H4>
	<b>pid</b> or <b>process</b> define the operating system process ID (or PID) sending this traffic. The parameter can be a PID or a list of PIDs, seperated by spaces and quoted as
	a single argument.<p>
	This parameter can be used only in services (<a href="#client">client</a> and <a href="#server">server</a> commands) defined within <a href="#interface">interfaces</a>, not <a href="#router">routers</a>.
	FireHOL is "smart" enough to apply this parameter only to traffic send by the localhost, i.e. the replies of <a href="#server">servers</a> and requests of <a href="#clients">clients</a>.
	It is not possible, and FireHOL will simply ignore this parameter, on traffic coming in or passign through the firewall host.
	<p>

<hr noshade size=1 width="100%">

	<a name="sid"><h3><b>sid</b> <font color="red">&lt;session&gt;</font></h3></a>
	<a name="session"><h3><b>session</b> <font color="red">&lt;session&gt;</font></h3></a>
	<H4>Description</H4>
	<b>sid</b> or <b>session</b> define the operating system session ID of the process sending this traffic (The session ID of a process is the process group ID of the session leader).
	The parameter can be a list of such IDs, seperated by spaces and quoted as a single argument.<p>
	This parameter can be used only in services (<a href="#client">client</a> and <a href="#server">server</a> commands) defined within <a href="#interface">interfaces</a>, not <a href="#router">routers</a>.
	FireHOL is "smart" enough to apply this parameter only to traffic send by the localhost, i.e. the replies of <a href="#server">servers</a> and requests of <a href="#clients">clients</a>.
	It is not possible, and FireHOL will simply ignore this parameter, on traffic coming in or passign through the firewall host.
	<p>

<hr noshade size=1 width="100%">

	<a name="cmd"><h3><b>cmd</b> <font color="red">&lt;name&gt;</font></h3></a>
	<a name="command"><h3><b>command</b> <font color="red">&lt;name&gt;</font></h3></a>
	<H4>Description</H4>
	<b>cmd</b> or <b>command</b> define the operating system command name of the process sending this traffic.
	The parameter can be a list of such command names, seperated by spaces and quoted as a single argument.<p>
	This parameter can be used only in services (<a href="#client">client</a> and <a href="#server">server</a> commands) defined within <a href="#interface">interfaces</a>, not <a href="#router">routers</a>.
	FireHOL is "smart" enough to apply this parameter only to traffic send by the localhost, i.e. the replies of <a href="#server">servers</a> and requests of <a href="#clients">clients</a>.
	It is not possible, and FireHOL will simply ignore this parameter, on traffic coming in or passign through the firewall host.
	<p>

<hr noshade size=1 width="100%">

	<a name="mac_param"><h3><b>mac</b> [not] <font color="red">&lt;address&gt;</font></h3></a>
	<H4>Description</H4>
	<b>mac</b> matches the source MAC address of packets comming into the firewall. The mac parameter does nothing for outgoing traffic.
	<br>
	For interfaces, the mac parameter matches against all traffic that comes into the firewall, whether it is <a href="#server">server</a>
	or <a href="#client">client</a> traffic.
	<br>
	For routers, the mac parameter matches also against all traffic comming into the firewall, but firehol considers the router
	input differently based on the command given. For <a href="#server">server</a> or <a href="#route">route</a> statements,
	the mac parameter matches the MAC address of the client (the host sending the request),
	while for <a href="#client">client</a> statements it matches the source MAC address of the server (the host accepting requests).
	<p>
	In principle, the mac parameter behaves the same for both interfaces and routers and this is why:
	The mac parameter matches the source MAC address of what FireHOL considers the "remote" host, not the one that FireHOL considers the "protected" one.
	For interfaces, this is simple, because always the "remote" host is a remote host and the "protected" host is the one running the
	firewall. For routers though, the command chosen (client or server) defines what the firewall protects. Therefore, a client statement
	protects the client making the "remote" host the server, while a server statement protects the server and therefore the "remote"
	host is the client.
	<p>
	More than one MAC addresses can be given if separated by spaces and enclosed in quotes as a single argument to the mac parameter.
	<p>
	The <b>not</b> argument will reverse the match. In case there are many MAC addresses defined, positive expressions are ORed
	(either address should be matched), while negative expressions are ANDed (none of the addresses should be matched).
	<p>

<hr noshade size=1 width="100%">

	<a name="mark_param"><h3><b>mark</b> [not] <font color="red">&lt;ID&gt;</font></h3></a>
	<H4>Description</H4>
	<b>mark</b> matches the traffic against the given IDs. This command accepts anything iptables accepts as MARKs (see <b>iptables -m mark --help</b>).
	<p>
	More than one MARK IDs can be given if separated by spaces and enclosed in quotes as a single argument to the mark parameter.
	<p>

<hr noshade size=1 width="100%">

	<a name="tos_param"><h3><b>tos</b> [not] <font color="red">&lt;ID&gt;</font></h3></a>
	<H4>Description</H4>
	<b>tos</b> matches the traffic against the given IDs. This command accepts anything iptables accepts as TOS (see <b>iptables -m tos --help</b>).
	<p>
	More than one IDs can be given if separated by spaces and enclosed in quotes as a single argument to the tos parameter.
	<p>

<hr noshade size=1 width="100%">

	<a name="dscp_param"><h3><b>dscp</b> [not] <font color="red">&lt;ID&gt;</font></h3>
	<br><h3><b>dscp</b> [not] class <font color="red">&lt;ID&gt;</font></h3></a>
	<H4>Description</H4>
	<b>dscp</b> matches the traffic against the given DSCP IDs. This command accepts anything iptables accepts as DSCP (see <b>iptables -m dscp --help</b>).
	<p>
	More than one IDs can be given if separated by spaces and enclosed in quotes as a single argument.
	<p>

<table border=0 cellpadding=10 cellspacing=0 width="100%"><tr bgcolor="#777777"><td align=center><font color="white"><b><big><a name="control_variables">Variables that control FireHOL</a></td</tr></table>
<p>
	<a name="DEFAULT_INTERFACE_POLICY"><h3><b>DEFAULT_INTERFACE_POLICY</b></h3></a>
	<H4>Description</H4>
	DEFAULT_INTERFACE_POLICY controls the default action to be taken on traffic not matched by any rule within an interface.
	Actually, this is a global setting for what <a href="#policy">policy</a> does for an <a href="#interface">interface</a>.
	<p>
	All packets that reach the end of an interface are logged only if the action is <b>not</b> <a href="#return">return</a> or <a href="#accept">accept</a>.
	You can control the frequency of this logging by altering the frequency <a href="#loglimit">loglimit</a> uses.
	<p>
	Default: <b>DEFAULT_INTERFACE_POLICY="DROP"</b><br>
	<br>
	Example: <b>DEFAULT_INTERFACE_POLICY="REJECT"</b>
	<p>

<hr noshade size=1 width="100%">

	<a name="UNMATCHED_INPUT_POLICY"><h3><b>UNMATCHED_INPUT_POLICY</b></h3></a>
	<a name="UNMATCHED_OUTPUT_POLICY"><h3><b>UNMATCHED_OUTPUT_POLICY</b></h3></a>
	<a name="UNMATCHED_ROUTER_POLICY"><h3><b>UNMATCHED_ROUTER_POLICY</b></h3></a>
	<H4>Description</H4>
	UNMATCHED_INPUT_POLICY controls the default action to be taken for incoming traffic not matched by any interface command.
	<br>UNMATCHED_OUTPUT_POLICY controls the default action to be taken for outgoing traffic not matched by any interface command.
	<br>UNMATCHED_ROUTER_POLICY controls the default action to be taken for forwarded traffic not matched by any router command.
	<p>
	All variables accept all the <a href="#actions">Actions</a> FireHOL supports.
	<p>
	All packets that reach the end of firewall in all three chains are logged (always, regardless of these settings).
	You can control the frequency of this logging by altering the frequency <a href="#loglimit">loglimit</a> uses.
	<p>
	Default: <b>UNMATCHED_INPUT_POLICY="DROP"</b><br>
	Default: <b>UNMATCHED_OUTPUT_POLICY="DROP"</b><br>
	Default: <b>UNMATCHED_ROUTER_POLICY="DROP"</b><br>
	<br>
	Example: <b>UNMATCHED_INPUT_POLICY="REJECT"</b><br>
	Example: <b>UNMATCHED_OUTPUT_POLICY="REJECT"</b><br>
	Example: <b>UNMATCHED_ROUTER_POLICY="REJECT"</b>
	<p>
	
<hr noshade size=1 width="100%">

	<a name="FIREHOL_INPUT_ACTIVATION_POLICY"><h3><b>FIREHOL_INPUT_ACTIVATION_POLICY</b></h3></a>
	<a name="FIREHOL_OUTPUT_ACTIVATION_POLICY"><h3><b>FIREHOL_OUTPUT_ACTIVATION_POLICY</b></h3></a>
	<a name="FIREHOL_FORWARD_ACTIVATION_POLICY"><h3><b>FIREHOL_FORWARD_ACTIVATION_POLICY</b></h3></a>
	<H4>Description</H4>
	All these variables have been added in v1.133
	<p>
	FIREHOL_INPUT_ACTIVATION_POLICY controls the default action to be taken for incoming traffic during firewall activation.
	<br>FIREHOL_OUTPUT_ACTIVATION_POLICY controls the default action to be taken for outgoing traffic during firewall activation.
	<br>FIREHOL_FORWARD_ACTIVATION_POLICY controls the default action to be taken for forwarded traffic during firewall activation.
	<p>
	All variables accept either <b>ACCEPT</b>, <b>DROP</b> or <b>REJECT</b>.
	<p>
	The default is ACCEPT in order to prevent a denial of service during a firewall restart. This is by design correct,
	since FireHOL will block all invalid connections after the firewall is fully activated (remember that FireHOL allows
	specific traffic to pass in both directions of the firewall).
	<p>
	Default: <b>FIREHOL_INPUT_ACTIVATION_POLICY="ACCEPT"</b><br>
	Default: <b>FIREHOL_OUTPUT_ACTIVATION_POLICY="ACCEPT"</b><br>
	Default: <b>FIREHOL_FORWARD_ACTIVATION_POLICY="ACCEPT"</b><br>
	<br>
	Example: <b>FIREHOL_INPUT_ACTIVATION_POLICY="REJECT"</b><br>
	Example: <b>FIREHOL_OUTPUT_ACTIVATION_POLICY="REJECT"</b><br>
	Example: <b>FIREHOL_FORWARD_ACTIVATION_POLICY="REJECT"</b>
	<p>
	
<hr noshade size=1 width="100%">

	<a name="FIREHOL_LOG_MODE"><h3><b>FIREHOL_LOG_MODE</b></h3></a>
	<a name="FIREHOL_LOG_LEVEL"><h3><b>FIREHOL_LOG_LEVEL</b></h3></a>
	<a name="FIREHOL_LOG_OPTIONS"><h3><b>FIREHOL_LOG_OPTIONS</b></h3></a>
	<a name="FIREHOL_LOG_FREQUENCY"><h3><b>FIREHOL_LOG_FREQUENCY</b></h3></a>
	<a name="FIREHOL_LOG_BURST"><h3><b>FIREHOL_LOG_BURST</b></h3></a>
	<H4>Description</H4>
	FIREHOL_LOG_MODE controls the method of logging used by FireHOL. Currently,
	two modes are supported: <b>LOG</b> and <b>ULOG</b>.
	FIREHOL_LOG_LEVEL controls the level at which iptables will log things to the syslog.
	For a description of the possible values supported and for per-rule control of log level,
	see the <a href="#log">log</a> optional rule parameter. FIREHOL_LOG_LEVEL is ignored when FIREHOL_LOG_MODE=ULOG.
	<p>
	FIREHOL_LOG_OPTIONS controls the way iptables will log things to the syslog.
	The value of this variable is passed as is to iptables, so use exact iptables parameters.
	This variable can have special arguments for the LOG or ULOG actions of iptables.
	<p>
	FIREHOL_LOG_FREQUENCY and FIREHOL_LOG_BURST (added in v1.39 of FireHOL) control the frequency at each each logging
	rule will write packets to the syslog. FIREHOL_LOG_FREQUENCY is set to the maximum average
	frequency and FIREHOL_LOG_BURST specifies the maximum initial number of packets to match.
	<p>
	Default: <b>FIREHOL_LOG_MODE="LOG"</b><br>
	Default: <b>FIREHOL_LOG_OPTIONS="--log-level warning"</b><br>
	Default: <b>FIREHOL_LOG_FREQUENCY="1/second"</b><br>
	Default: <b>FIREHOL_LOG_BURST="5"</b><br>
	<br>
	Example: <b>FIREHOL_LOG_OPTIONS="--log-level info --log-tcp-options --log-ip-options"</b><br>
	Example: <b>FIREHOL_LOG_FREQUENCY="30/minute"</b><br>
	Example: <b>FIREHOL_LOG_BURST="2"</b><br>
	<br>
	To see the available iptables log options, run <b>/sbin/iptables -j LOG --help</b> or <b>/sbin/iptables -j ULOG --help</b> (depending on FIREHOL_LOG_MODE)<br>
	To see what iptables accepts as frequencies and bursts run, <b>/sbin/iptables -m limit --help</b></br>
	You can also check <b>man iptables</b>.
	<p>
	
<hr noshade size=1 width="100%">

	<a name="FIREHOL_DROP_INVALID"><h3><b>FIREHOL_DROP_INVALID</b></h3></a>
	<H4>Description</H4>
	If FIREHOL_DROP_INVALID is set to 1, FireHOL will drop all packets that are matched by the INVALID state of the
	iptables connection tracker. The default in versions prior to v1.183 was to drop all those packers. The new default
	is not to drop those packets globally, but only as part of the <a href="#protection">protection</a> statement.
	<p>
	See also <a href="https://sourceforge.net/tracker/index.php?func=detail&aid=927509&group_id=58425&atid=487692">Bug 927509</a> that discusses the effects of globally dropping invalid packets.
	<p>
	Default: <b>FIREHOL_DROP_INVALID="0"</b>
	<br>
	Example: <b>FIREHOL_DROP_INVALID="1"</b>
	<p>

<hr noshade size=1 width="100%">

	<a name="DEFAULT_CLIENT_PORTS"><h3><b>DEFAULT_CLIENT_PORTS</b></h3></a>
	<H4>Description</H4>
	DEFAULT_CLIENT_PORTS controls the port range to be used when a remote client is specified.
	For localhost clients, FireHOL finds the exact client ports by querying the kernel options.
	<p>
	Default: <b>DEFAULT_CLIENT_PORTS="1024:65535"</b>
	<br>
	Example: <b>DEFAULT_CLIENT_PORTS="0:65535"</b>
	<p>

<hr noshade size=1 width="100%">

	<a name="FIREHOL_NAT"><h3><b>FIREHOL_NAT</b></h3></a>
	<H4>Description</H4>
	If FIREHOL_NAT is set to 1, FireHOL will load NAT kernel modules for those services that they are require such.
	FireHOL sets this to 1 automatically if you use the <a href="#helpers">Helper Commands</a> that do NAT.
	<p>
	Default: <b>FIREHOL_NAT="0"</b>
	<br>
	Example: <b>FIREHOL_NAT="1"</b>
	<p>

<hr noshade size=1 width="100%">

	<a name="FIREHOL_AUTOSAVE"><h3><b>FIREHOL_AUTOSAVE</b></h3></a>
	<H4>Description</H4>
	FIREHOL_AUTOSAVE controls the file that will be created when FireHOL is called with the <b>save</b> command line argument.
	If this variable is empty (the default), FireHOL will try to detect where to save the file. Currently, the RedHat way
	(/etc/sysconfig/iptables) and the Debian way (/var/lib/iptables/autosave) are automatically detected (in the order given here)
	based on the existance of the directory this file should be created in.
	<p>
	Default: <b>FIREHOL_AUTOSAVE=""</b>
	<br>
	Example: <b>FIREHOL_AUTOSAVE="/tmp/firehol-saved.txt"</b>
	<p>

<hr noshade size=1 width="100%">

	<a name="FIREHOL_LOAD_KERNEL_MODULES"><h3><b>FIREHOL_LOAD_KERNEL_MODULES</b></h3></a>
	<H4>Description</H4>
	FIREHOL_LOAD_KERNEL_MODULES controls the way FireHOL handles required kernel modules.
	If set to 0 (zero), FireHOL will not attempt to load kernel modules at all. Set this to 0 (zero)
	if you have compiled a kernel that has all the modules build into it.
	<p>
	Since v1.165 of the FireHOL this feature is almost useless.
	FireHOL now tries to find the .config file of your kernel
	(in <b>/proc/config</b> or <b>/lib/modules/`uname -r`/build/.config</b>
	or <b>/usr/src/linux/.config</b>, in this order) and figures out which kernel modules are compiled
	build-in and which are modules.
	<br>
	So, this variable is only used in cases where FireHOL has no access at all to kernel configuration.
	<p>
	Keep in mind, that FireHOL is able to detect the <b>ip_tables</b> and <b>ip_conntrack</b> modules
	by examining the relative entries in /proc, so it can detect whether these are loaded without the
	need for the kernel configuration.
	<p>
	Default: <b>FIREHOL_LOAD_KERNEL_MODULES=1</b>
	<br>
	Example: <b>FIREHOL_LOAD_KERNEL_MODULES=0</b>
	<p>

<hr noshade size=1 width="100%">

	<a name="FIREHOL_TRUST_LOOPBACK"><h3><b>FIREHOL_TRUST_LOOPBACK</b></h3></a>
	<H4>Description</H4>
	FIREHOL_TRUST_LOOPBACK allows you to choose if FireHOL will trust the <b>lo</b> interface and
	accept all traffic to or from it (although not FORWARD, it matches only INPUT and OUTPUT).
	<p>
	The default is to accept all traffic from/to <b>lo</b>. If however you need to control what
	the local system users can use on the local machine, you can set this to anything other than 1
	allowing you to setup the firewall as you will.
	<p>
	<b>IMPORTANT: If you choose not to trust interface lo and you don't specifically setup the lo
	interface in firehol.conf, no local process will be able to communicate to any other local process,
	which most likely will break several things. Be sure you know what you are doing.</b>
	<p>
	This option appeared in FireHOL version 1.195.
	<p>
	Default: <b>FIREHOL_TRUST_LOOPBACK=1</b>
	<br>
	Example: <b>FIREHOL_TRUST_LOOPBACK=0</b>
	<p>

<table border=0 cellpadding=10 cellspacing=0 width="100%"><tr bgcolor="#777777"><td align=center><font color="white"><b><big><a name="use_variables">Variables that FireHOL offers</a></td</tr></table>
<p>
	<a name="RESERVED_IPS"><h3><b>RESERVED_IPS</b></h3></a>
	<H4>Description</H4>
	This variable includes all the IP addresses defined as <b>IANA - Reserved</b> by <a href="http://www.iana.org">IANA</a>.
	The supplied <b>get-iana.sh</b> script creates this variable by directly fetching <a href="http://www.iana.org/assignments/ipv4-address-space">this</a> document.
	<p>
	Example: <b>interface eth0 internet src not "${RESERVED_IPS}"</b>
	<p>
	
<hr noshade size=1 width="100%">

	<a name="PRIVATE_IPS"><h3><b>PRIVATE_IPS</b></h3></a>
	<H4>Description</H4>
	This variable includes all the IP addresses defined as <b>Private</b> or <b>Test</b> by <a href="http://www.ietf.org/rfc/rfc3330.txt?number=3330">RFC 3330</a>.
	<p>
	Example: <b>interface eth0 internet src not "${PRIVATE_IPS}"</b>
	<p>
	
<hr noshade size=1 width="100%">

	<a name="UNROUTABLE_IPS"><h3><b>UNROUTABLE_IPS</b></h3></a>
	<H4>Description</H4>
	This variable is both RESERVED_IPS and PRIVATE_IPS together. I suggest to use this variable on interfaces and routers
	accepting Internet traffic.
	<p>
	Example: <b>interface eth0 internet src not "${UNROUTABLE_IPS}"</b>
	<p>
	

<p>
<hr noshade size=1>
<table border=0 width="100%">
<tr><td align=center valign=middle>
	<A href="http://sourceforge.net"><IMG src="http://sourceforge.net/sflogo.php?group_id=58425&amp;type=5" width="210" height="62" border="0" alt="SourceForge Logo"></A>
</td><td align=center valign=middle>
	<small>$Id: commands.html,v 1.62 2005/01/24 22:19:43 ktsaou Exp $</small>
	<p>
	<b>FireHOL</b>, a firewall for humans...<br>
	&copy; Copyright 2004
	Costa Tsaousis <a href="mailto: costa@tsaousis.gr">&lt;costa@tsaousis.gr&gt</a>
</body>
</html>