Subsections

Zone access

The access rules are the central rules in the zone. These defines access between other zones and the firewall itself. All zone access rules are arrays, which are processed sequentially. It is highly recommended to have an catch all rule as the last rule, specifying a default policy for packets not covered by previous rules.

Input rules

The input rules control access from machines located in the zone to the firewall itself. Input rules are specified as an array named INPUT:
\begin{grammar}
<input> ::= <policy> <proto_ip>
\end{grammar}
The policy defines whether to drop, reject or accept connections that matches this rule.

Example

INPUT[0]="ACCEPT tcp 25,80,443,22 0.0.0.0/0=>0.0.0.0/0"
INPUT[1]="DROP ALL 0.0.0.0/0=>0.0.0.0/0"
This will accept only http, https, smtp (mail transfer) and ssh access to the firewall itself. Any other packet originating from the zone destined to the firewall itself will be discarded.

Output rules

The output rules determines access from the firewall to machines located in the zone. Output rules are specified as an array named FORWARD:
\begin{grammar}
<output> ::= <policy> <proto_ip>
\end{grammar}
The policy defines whether to drop, reject or accept connections that matches this rule.

Example

OUTPUT[0]="ACCEPT tcp 22 0.0.0.0/0=>0.0.0.0/0"
OUTPUT[1]="REJECT ALL 0.0.0.0/0=>0.0.0.0/0"
This will allow the firewall only to initiate ssh communication to machines located within the zone. All other communication initiated by the firewall to machines in this zone is prohibited, and packets are blocked.

Forward rules

The forward rules restricts access from machines located in other zones to this zone. Forward rules are specified as an array named FORWARD:
\begin{grammar}
<forward> ::= <zone> <policy> <proto_ip>
\end{grammar}
The first argument specifies the source zone of the connection. The policy defines whether to drop, reject or accept connections that matches this rule.

Example

FORWARD[0]="ALL ACCEPT tcp 22 0.0.0.0/0=>0.0.0.0/0"
FORWARD[1]="DROP ALL 0.0.0.0/0=>0.0.0.0/0"
Machines located in other zones are only allowed to initiate ssh communication to machines located in this zone. Any other communication initiated by machines in zones different from this zone to machines in the present zone are silently dropped.

Reply rules

Reply rules specifies a special response to connection attempts to the firewall itself, before dropping the connection. The responses usually mean that a port or protocol is not available on the system.


\begin{grammar}
\par
<reply> ::= <zone> <icmp_type> <proto_ip>
\alt <zone> 'tcp-reset' 'tcp' <port> <src_dst_ip>
\end{grammar}
The first argument specifies the response to the connection attempt. The 2. argument serves as conditions of the rule. A special 'tcp-reset' can be used, only if the protocol is specified as tcp.

Example

REPLY_AUTH="EXT tcp-reset tcp auth 0.0.0.0/0=>0.0.0.0/0"
This example specifies that queries to the auth daemon should be responded by tcp-reset. Many services on the Internet makes an auth request on hosts that makes use of the services. The first line speeds this process up by resetting the connection, instead of silently dropping packets.

Limit rules

Limit rules serves as an supplement to input and forward rules. Linux rules allows only limited acceptance of packets, used in order to avoid Denial of service attacks. The rules are on the form <limit>, as given below.


\begin{grammar}
<rate> ::= <int> <rate_opt>
\par
<rate_opt> ::= '/second' \vert...
...= <int>
\par
<limit> ::= <zone> <policy> <rate> <burst> <proto_ip>
\end{grammar}
The <rate> and <policy> specifies the maximum average matching rate, and the initial packets to match. The <zone> specifies the source zone for packets that can be matched by this rule. If the source zone equals that zone for which the rule is specified, then the rule is applied for requests to the firewall itself.

Example

LIMIT_PING="EXT DROP 1/second 3 icmp echo-request \
0.0.0.0/0=>0.0.0.0/0"
This example will drop ping's arriving faster than one per second, with a maximum of three.

Anders Peter Fugmann 2011-03-20