Table of Contents
- Primary Commands
- interface, control what the firewall host can do
- router, control what traffic can pass through the firewall host
- Sub-Commands
- Helper commands
- blackilist, setup a unidirectional or bidirectional blacklist
- dnat, setup a Destination NAT rule for routed traffic
- iptables, add some custom iptables commands to the firewall
- mac, setup a source mac address with IP match
- mark, mark traffic for traffic shapping tools
- masquerade, setup masquerading (NAT) to the output of a network interface
- nat, setup a NAT rule for routed traffic
- redirect, setup a port redirection rule
- snat, setup a Source NAT rule for routed traffic
- transparent_squid, setup a transparent squid proxy running on the firewall host
- version, require a specific version of FireHOL
- Actions
- accept, allow the traffic to reach its destination
- reject, don't allow the traffic to pass, but send a rejection message to the sender
- drop, discard the traffic without sending anything back to the sender
- deny, an alias for drop
- return, return to processing the parent flow of rules
- mirror, send the traffic back to the sender at the port of the destination
- redirect, redirect the traffic to another port on the local host
- Optional Rule Parameters
- src, set the source of traffic
- dst, set the destination of traffic
- inface, set the network interface traffic is received via
- outface, set the network interface traffic is send via
- custom, pass a few custom parameters to the generated iptables
statements
- log, write something to the syslog when traffic is matched
- loglimit, write (limited) something to the syslog when traffic is matched
- proto, match a specific protocol
- limit, limit the frequency traffic is matched
- sport, set the source ports
- dport, set the destination ports
- uid, user, set the users sending this traffic
- gid, group, set the user groups sending this traffic
- pid, process, set the process IDs sending this traffic
- sid, session, set the process session IDs sending this traffic
- cmd, command, set the command name sending this traffic
- Variables that control FireHOL
- Variables FireHOL offers
Primary commands form groups of rules within a FireHOL firewall.
The optional rule parameters given to the primary commands are indirectly applied to all sub-commands given within this primary command.
interface <real interface> <name> [optional rule parameters]
Description
The interface command creates a firewall for protecting the host the firewall is running, from the given interface.
The default interface policy is drop, so that if no subcommands are given, the
firewall will just drop all incoming and outgoing traffic using this interface.
INPORTANT
Note that unlike ipchains, in iptables traffic passing through the firewall
host (FORWARDed traffic) does not pass through the INPUT/OUTPUT chains of the firewall and
therefore the interface rules in FireHOL never match it.
To match the traffic passing through (even if DNATed) you have to place
the filtering rules in router statements. Interface
statements filter traffic only from/to the firewall host. Nothing else.
Parameters
- real interface is the interface name as shown by ip link show.
Generally anything iptables accepts, including the pattern character + (the plus sign), is valid.
The plus sign after some text will match all interfaces that start with this text.
It is allowed to use more than one interfaces separated by spaces, but all of them should be
given within one quoted argument:
Example: interface "eth0 eth1 ppp0" myname
- name is a name for this interface.
Generally you should use short names (10 characters max) without spaces or other symbols.
You should not use the same name more than once in FireHOL primary commands.
- optional rule parameters is a set of rules that allow further restriction of the traffic that
gets matched for this interface. See Optional Rules Parameters for more information.
Example 1: interface eth0 intranet src 10.0.0.0/16
Example 2: interface eth0 internet src not "$UNROUTABLE_IPS"
(note: UNROUTABLE_IPS is a variable defined by FireHOL that includes all IPs that should not be routable
by the Internet).
router <name> [optional rule parameters]
Description
The router command creates a firewall for the traffic passing through the host running the firewall.
The only acceptable policy on all router commands is return 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
router command will be dropped at the end of the firewall.
INPORTANT
Note that unlike ipchains, in iptables traffic passing through the firewall
host (FORWARDed traffic) does not pass through the INPUT/OUTPUT chains of the firewall and
therefore the interface rules in FireHOL never match it.
To match the traffic passing through (even if DNATed) you have to place
the filtering rules in router statements. Interface
statements filter traffic only from/to the firewall host.
Router statements filter traffic that passes through the
firewall host.
Parameters
- name is a name for this router.
The same restrictions of interface names apply here too.
- optional rule parameters is a set of rules that allow further restriction of the traffic that
gets matched for this router. See Optional Rules Parameters for more information.
Router statements produce similar iptables commands the interface statements produce.
For each router statement an in_<name> and an
out_<name> chain are produced to match the traffic
in both directions of the router.
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 router
statement in which case will be applied to all subcommands for this router,
or on each subcommand within a router.
Both are valid.
For example:
router mylan inface ppp+ outface eth0
server http accept
client smtp accept
The above says: Define a router that matches all requests that originate from some PPP interface and go out to eth0.
There is an HTTP server in eth0 that client from the PPP interfaces are allowed to reach.
Clients on eth0 are allowed to get SMTP traffic from the PPP interfaces.
While:
router mylan
server http accept inface ppp+ outface eth0
server smtp accept inface eth0 outface ppp+
The above says: Define a router that matches any kind of forwarded traffic.
For HTTP traffic the clients are on a PPP interface and the servers on eth0.
For SMTP traffic the clients are on a eth0 interface and the servers o a PPP interface.
Please note that in the second example the SMTP traffic is matched again with a server subcommand,
not a client (as in the first example).
The client subcommand reverses all the optional rules that are applied indirectly to it.
Indirect rule parameters are those that are inherited from the parent command (router in this case).
To make it simple, for FireHOL a client is: "a server with all the implicit optional rule parameters reversed".
So, in the first example, the client simply flipped the inface and outface rules defined at the router
and became an SMTP server.
In the second example there is nothing to be flipped, so server and client
are exactly the same.
I suggest to use client subcommands in routers only if you have inface/outface or src/dst in the router statements.
If you are building routers like the second example, don't use client, it is confusing.
Older versions of FireHOL did not allow server and client subcommands in routers.
Only the route subcommand was allowed. Today, route is just an alias for server and can be
used only in routers, not interfaces.
Any number of router statements can exist. Since the policy is RETURN on all of them, any traffic
not matched by a router will continue to be checked against the second.
Subcommands must be given within Primary commands.
policy <action>
Description
The policy subcommand defines the default policy for an interface.
This directive accepts all the actions specified in Actions.
The policy of routers cannot be changed and is always RETURN.
protection [reverse] <type> [requests/sec [burst]]
Description
The protection subcommand sets a number of protection rules on an interface.
In router configurations, protections are setup on inface. The reverse keyword will make the
protections setup on outface.
type can be:
strong, or full, or all
turns on all the possible protections.
fragments
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.
I left this here for psychological reasons and in case some one finds some use for it.
new-tcp-w/o-syn
Drops all TCP packets that initiate a socket but have no the SYN bit set.
syn-floods
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 limit module of iptables: see man iptables for more).
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.
icmp-floods
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 limit module of iptables: see man iptables for more).
malformed-xmas
Drops all TCP packets that have all the TCP flags set.
malformed-null
Drops all TCP packets that have all the TCP flags unset.
malformed-bad
Drops all TCP packets that have illegal combinations of TCP flags set.
server <service> <action> [optional rule parameters]
Description
The server 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, for FireHOL a server always accepts requests.
The optional rule parameters given to the parent primary command (interface or router) are inherited by the server as they have been given.
This subcommand can be used on both interfaces and routers.
Parameters
client <service> <action> [optional rule parameters]
The client 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 for FireHOL a client always sends requests.
The parameters are exactly the same with the server subcommand.
The optional rule parameters given to the parent primary command (interface or router) are inherited by the client, but they are reversed.
For an explanation of this please refer to the documentation of the router primary command.
This subcommand can be used on both interfaces and routers.
route <service> <action> [optional rule parameters]
The route subcommand is an alias for the server command that can be used only on routers, not interfaces.
Helper commands provide shortcuts for common functions not handled by the core of FireHOL's logic.
blacklist [option] <IPs>
The blacklist helper creates a blacklist for the IP addresses given. It supports two modes of operation
based on the option given (or the absence of it).
The option can be:
- one of the words them, him, her, it, this, these, input 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).
- one of the words all, full 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.
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.
Example 1: blacklist this "195.97.5.202 10.1.1.1" # please note the quotes
Example 2: blacklist full 195.97.5.202 10.1.1.1 # please note the absence of quotes
dnat [to] <target> [optional rule parameters]
The dnat helper sets up a Destination NAT rule for routed traffic, by calling
nat to-destination <target> [optional rule parameters]
See the nat helper.
Example: dnat to 1.1.1.1 inface eth0 src 2.2.2.2 dst 3.3.3.3
iptables <arguments>
Description
The iptables command passes all its arguments to the real iptables command, during run-time.
You should not use in FireHOL configurations /sbin/iptables or other means to alter a FireHOL firewall.
If you do, your commands will be run before FireHOL activates its firewall and while the previous
firewall is still running. Also, since FireHOL will delete all previous firewall rules in order to
activate the new firewall, any changes you will make, will be deleted too.
Always use the iptables directive to hook iptables commands in a FireHOL firewall. Nothing else.
mac <IP> <MAC>
The mac helper verifies that all traffic comming in with source the IP address, comes from the
MAC 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.
The same MAC address is allowed to use other IPs; only the specific IP is required to be used with the specified MAC
address.
Packets with the given IP address but with wrong MAC address will be DROPped and a log (as in loglimit)
with label "MAC MISSMATCH" will appear in the system logs.
This helper has to be used before all interface or router statements. Of course, you can use as many mac statements as you wish.
Example: mac 195.97.5.202 00:02:8a:21:a9:d8
mark <NUMBER> <WHERE> [optional rule parameters]
The mark helper marks the traffic with a specific mark NUMBER that can be matched by traffic shapping tools
for controlling the traffic.
Parameters
- NUMBER is a number to mark the packets with.
- WHERE tells FireHOL where to search for the specific traffic to be marked.
Currently, WHERE can be one of the build-in iptables chains attached to table mangle.
(for example: INPUT, FORWARD, OUTPUT, PREROUTING, POSTROUTING - case does matter here).
- optional rule parameters is a set of rules that allow further restriction of the traffic that
gets matched by this rule. See Optional Rules Parameters for more information.
Example 1: mark 1 OUTPUT, will mark with 1 all packets send by the local machine.
Example 2: mark 2 FORWARD, will mark with 2 all packets passing through the local machine.
Example 3: mark 3 FORWARD proto tcp dport 25 dst 1.1.1.1 src 2.2.2.2, 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.
masquerade [reverse | interface] [optional rule parameters]
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.
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.
The masquerade helper sets up masquerading on the output of a network interface (not the interface command, but a real network interface).
If the masquerade command is placed within an interface command, its network interface(s) will be used.
If the masquerade command is placed within a router command that has an outface defined, then the outface network interface(s) will be used.
If placed within a router command but the keyword reverse is specified and the router command has an inface defined, then the inface network interface(s) will be used.
If placed outside and before all primary commands, an interface (or list of space separated interfaces, within double quotes) can be specified on the masquerade command.
In all cases, masquerade will setup itself on the output of the given interface(s).
Please note that if masquerade is used within some interface or router, it does not respect the optional rule parameters
given to this interface or router command. Masquerade uses only its own optional rule parameters.
inface and outface should not be given as parameters to masquerade (inface because iptables does not support this
in the POSTROUTING chain, and outface because it will be overwritten by the interface(s) mentioned above).
Finally, the masquerade helper will turn on FIREHOL_NAT and instruct the kernel to do packet forwarding (like the router
commands do).
Example 1: before the first interface or router: masquerade eth0 src 10.0.0.0/8 dst not 10.0.0.0/8
Example 2: within an interface: masquerade, to masquerade on the output of this interface
Example 3: within a router: masquerade reverse, to masquerade on the output of the router's inface.
nat <type> <target> [optional rule parameters]
The nat helper sets up a NAT rule for routed traffic.
The type parameter can be:
- to-source, to define a Source NAT (created in NAT/POSTROUTING).
The target 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).
target accepts all --to-source values iptables accepts (see iptables -j SNAT --help).
Multiple --to-source values can be given, if separated by space and quoted as a single argument.
inface should not be used in SNAT, because iptables does not provide this information
at this point.
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. If the traffic does not get back to this host, then SNAT will simply not work.
THE PACKET FILTERING MECHANISM WILL NOT KNOW 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 real source address (i.e. real = as it is, before SNATed).
For the host doing the NAT, real is "where do I have to really send it?"
- to-destination, to define a Destination NAT (created in NAT/PREROUTING).
The target 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).
target accepts all --to-destination values iptables accepts (see iptables -j DNAT --help).
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).
outface should not be used in DNAT, because iptables does not provide this information
at this point.
THE PACKET FILTERING MECHANISM WILL KNOW 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 real destination address (i.e. real = as it is, after DNATed).
For the host doing the NAT, real is "where do I have to really send it?"
- redirect-to, to catch traffic comming in and send it to the local machine (created in NAT/PREROUTING).
The target 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).
target accepts all --to-ports values iptables accepts (see iptables -j REDIRECT --help).
outface should not be used in REDIRECT, because iptables does not provide this information
at this point.
THE PACKET FILTERING MECHANISM WILL KNOW THE CHANGE OF THE DESTINATION PORT. For packet filtering
(client, server statements in interfaces), the
traffic will flow in both directions with its real destination port (i.e. real = as it is, after REDIRECTed).
For the host doing the NAT, real is "where do I have to really send it?"
Please understand that the optional rule parameters are used only to limit the traffic to be matched.
Consider these examples:
Command | Description |
nat to-destination 1.1.1.1 |
Sends to 1.1.1.1 all traffic comming in or passing trhough the firewall host. |
nat to-destination 1.1.1.1 dst 2.2.2.2 |
Redirects to 1.1.1.1 all traffic comming in or passing through, and going to 2.2.2.2. |
nat to-destination 1.1.1.1 proto tcp dst 2.2.2.2 |
Redirects to 1.1.1.1 all TCP traffic comming in or passing through and going to 2.2.2.2. |
nat to-destination 1.1.1.1 proto tcp dport 25 dst 2.2.2.2 |
Redirects to 1.1.1.1 all traffic comming in or passing through and going to 2.2.2.2 to port tcp/25. |
nat to-destination 1.1.1.1 proto tcp dport 25 dst 2.2.2.2 src 3.3.3.3 |
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. |
Example 1: nat to-source 1.1.1.1 outface eth0 src 2.2.2.2 dst 3.3.3.3
Example 2: nat to-destination 4.4.4.4 inface eth0 src 5.5.5.5 dst 6.6.6.6
Example 3: nat redirect-to 8080 inface eth0 src 2.2.2.0/24 proto tcp dport 80
redirect [to] <target> [optional rule parameters]
The redirect helper catches all incomming traffic matching the optional rule parameters given and
redirects it to ports on the local host, by calling
nat redirect-to <target> [optional rule parameters]
See the nat helper.
Example: redirect to 8080 inface eth0 src 2.2.2.0/24 proto tcp dport 80
snat [to] <target> [optional rule parameters]
The snat helper sets up a Source NAT rule for routed traffic, by calling
nat to-source <target> [optional rule parameters]
See the nat helper.
Example: snat to 1.1.1.1 outface eth0 src 2.2.2.2 dst 3.3.3.3
transparent_squid <port> <user> [optional rule parameters]
The transparent_squid helper sets up trasparent caching for HTTP traffic.
The squid proxy is assumed to be running on the firewall host at port port (normally port is squid), with the credentials of the local user user (normally user is squid).
The transparent_squid helper can be used for two kinds of traffic:
- Incomming HTTP traffic, either targeted to the firewall host or passing through the firewall host.
The optional rule parameters can be used to specify which kind of incomming traffic to be catched
(by using inface, src, dst, etc --
outface should not be used here, because the rules generated are placed before
the routing decision and therefore the outgoing interface is not yet known).
If no optional rule parameters are given, then the transparent
cache will be setup on all network interfaces for all HTTP traffic (use this with care since you are
risking to serve requests from the internet using your squid).
- Locally generated outgoing HTTP traffic, except HTTP traffic generated by processes running as the user argument.
The optional rule parameters inface, outface and src are
ignored for this type of traffic.
This kind of matching makes it possible to support transparent caching for WEB browsers running on the firewall
host, as far as they do not run as the user excluded. More that one users can be specified by space-separating
and enclosing them in double quotes.
This rule can be disabled by specifing as user the empty string: ""
Of course, make sure that your firewall allows requests to reach your proxy server.
Example 1: transparent_squid 3128 squid inface eth0 src 10.0.0.0/8
Example 2: transparent_squid 8080 "squid privoxy root bin" inface not "ppp+ ipsec+" dst not "a.not.proxied.server"
version <number>
Description
The version command states the FireHOL release the configuration file was
created for. In case the configuration file is newer than FireHOL, FireHOL will deny
to run it.
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.
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.
The FireHOL release is increased every time the format of the configuration file and the internals of FireHOL are changed.
Since FireHOL v1.67 version is not required to be present in every configuration file.
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 log and loglimit) 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.
accept
accept allows the traffic matching the rules to reach its destination.
Example: server smtp accept, to allow SMTP requests and their replies to flow.
reject [with message]
reject discards the matching traffic but sends a rejecting message back to the sender.
with is used to offer control on the message to be returned to the sender.
with accepts all the arguments the --reject-with iptables expression accepts. For an updated list
of these messages type iptables -j REJECT --help. Bellow you can find the list my system accepts.
By default (no with argument given), reject will send an icmp-port-unreachable on all protocols
except TCP, for which it will send a tcp-reset.
Message | Alias | Description | Reference |
icmp-net-unreachable |
net-unreach |
ICMP network unreachable
From RFC 1812 section 5.2.7.1
Generated by a router if a forwarding path (route) to the destination network is not available.
Notes
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.
|
RFC 1812
RFC 792 |
icmp-host-unreachable |
host-unreach |
ICMP host unreachable
From RFC 1812 section 5.2.7.1
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).
Notes
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.
|
RFC 1812
RFC 792 |
icmp-proto-unreachable |
proto-unreach |
ICMP protocol unreachable
From RFC 1812 section 5.2.7.1
Generated if the transport protocol designated in a datagram is not supported in the transport layer
of the final destination.
|
RFC 1812
RFC 792 |
icmp-port-unreachable |
port-unreach |
ICMP port unreachable (default)
From RFC 1812 section 5.2.7.1
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.
In other words
Generated by hosts to indicate that the required port is not active. |
RFC 1812
RFC 792 |
icmp-net-prohibited |
net-prohib |
ICMP communication with destination network administratively prohibited
From RFC 1812 section 5.2.7.1
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.
In other words
Use it, but don't expect that this will be widely understood.
|
RFC 1812
RFC 1122 |
icmp-host-prohibited |
host-prohib |
ICMP communication with destination host administratively prohibited
From RFC 1812 section 5.2.7.1
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.
In other words
Use it, but don't expect that this will be widely understood.
|
RFC 1812
RFC 1122 |
tcp-reset |
tcp-reset |
TCP RST
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.
I suggest to use this for rejecting idents: server ident reject with tcp-reset.
|
RFC 1122 |
Example 1: policy reject with host-unreach
Example 2: server ident reject with tcp-reset
Example 3: UNMATCHED_INPUT_POLICY="reject with host-prohib"
drop
drop 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.
Example: server smtp drop, to silently discard SMTP requests and their replies.
deny
deny is just an alias for drop, made for those who are used to ipchains terminology.
Example: server smtp deny, to silently discard SMTP requests and their replies.
return
return will return the flow of processing to the parent of the current command.
Currently, it has meaning to specify the action return only as a policy to some interface.
Example: policy return, to have traffic not matched by any rule within an interface to continue traveling through the
firewall and possibly matched by other interfaces bellow.
mirror
mirror 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.
redirect [to-port port]
redirect is used internally by FireHOL Helper Commands to redirect traffic to ports on the local host.
Unless you are a developer, you will never need to use this directly.
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.
Not all parameters should be used in all cases. For example sport and dport should not be used in normal server and
client commands since such ports are internally defined by the services themselves. In any case, FireHOL will complain
about optional rule parameters that should not be used in certain commands.
src [not] <host>
Description
src defines the source IP address of the REQUEST. If src is defined on a server statement it matches the
source of the request which is the remote host, while if it is defined on a client statement it matches again
the source of the request, but this time it is the local host. Focus on the REQUEST!!! Forget the reply.
Parameters
- not is an optional argument that reverses the match. When defined, the rule will match all hosts
except the ones defined.
Example: server smtp accept src not 1.2.3.4
- host can be an IP address, a hostname, or a subnet.
Multiple hosts/networks can be defined if separated by space and quoted as a single argument.
Example 1: server smtp accept src 1.2.3.4
Example 2: server smtp accept src not "1.2.3.0/24 5.6.7.8 badhost.example.com"
dst [not] <host>
Description
dst defines the destination of the REQUEST. If dst is defined on a server statement it matches the
destination of the request which is the local host, while if it is defined on a client statement it matches again
the destination of the request, but this time it is the remote host. Focus on the REQUEST!!! Forget the reply.
dst accepts the same parameters as src
inface [not] <interface>
Description
inface defines the interface the REQUEST is received via.
inface cannot be used in interface commands.
Parameters
- not is an optional argument that reverses the match. When defined, the rule will match all interfaces
except the ones defined.
Example: server smtp accept inface not eth0
- interface if an interface name in the same format the interface command accepts.
Multiple interfaces can be defined if separated by space and quoted as a single argument.
Example 1: server smtp accept inface not eth0
Example 2: server smtp accept inface not "eth0 eth1"
outface [not] <interface>
Description
outface defines the interface the REQUEST is send via.
outface cannot be used in interface commands.
outface accepts the same parameters as inface.
custom "parameters"
Description
custom passes its arguments to the generated iptables commands.
It is required to quote all the parameters given to custom. 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.
Example 1: server smtp accept custom "--some-iptables-option and_its_value"
Example 2: server smtp accept custom "--some-iptables-option 'one_value another_value'"
log "<some text>" [level a_level]
Description
log 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 FIREHOL_LOG_OPTIONS and
FIREHOL_LOG_LEVEL. You can also change the level of just one rule by using the
level argument of the log parameter.
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:
- setup klogd to log only more important traffic
- change FIREHOL_LOG_LEVEL to log at a not so important log-level
Actually klogd's -c option and iptables' --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.
In most kernels klogd is by default configured to log everything, so if you don't also change klogd's -c option,
the --log-level setting of iptables has no effect. Use the table bellow to match klogd options with --log-level options:
Priority | klogd | iptables | Description |
0 |
0 |
emerg |
system is unusable |
1 |
1 |
alert |
action must be taken immediately |
2 |
2 |
crit |
critical conditions |
3 |
3 |
error |
error conditions |
4 |
4 |
warning (default) |
warning conditions |
5 |
5 |
notice |
normal but significant condition |
6 |
6 |
info |
informational |
7 |
7 (default) |
debug |
debug-level messages |
To prevent packet logs appearing to the console, klogd option must be LOWER than the one iptables uses.
On RedHat systems, you can configure klogd by changing
/etc/sysconfig/syslog and adding to KLOGD_OPTIONS the required -c level.
loglimit "<some text>"
Description
loglimit is the same with log but limits the frequency of logging according to the setting of
FIREHOL_LOG_FREQUENCY and FIREHOL_LOG_BURST.
proto [not] <protocol>
Description
proto sets the required protocol for the traffic. This command accepts anything iptables accepts as
protocols.
limit <frequency> <burst>
Description
limit 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.
sport <port>
Description
sport 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 services definitions (client and server commands) or
interface and router definitions, unless you really understand what you are doing.
dport <port>
Description
dport 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 services definitions (client and server commands) or
interface and router definitions, unless you really understand what you are doing.
uid [not] <user>
user [not] <user>
Description
uid or user 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.
This parameter can be used only in services (client and server commands) defined within interfaces, not routers.
FireHOL is "smart" enough to apply this parameter only to traffic send by the localhost, i.e. the replies of servers and requests of clients.
It is not possible, and FireHOL will simply ignore this parameter, on traffic coming in or passign through the firewall host.
Example 1: client "pop3 imap" accept user not "user1 user2 user3" dst mymailer.example.com
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.
Example 2: server http accept user apache
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.
gid <group>
group <group>
Description
gid or group 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.
This parameter can be used only in services (client and server commands) defined within interfaces, not routers.
FireHOL is "smart" enough to apply this parameter only to traffic send by the localhost, i.e. the replies of servers and requests of clients.
It is not possible, and FireHOL will simply ignore this parameter, on traffic coming in or passign through the firewall host.
pid <process>
process <process>
Description
pid or process 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.
This parameter can be used only in services (client and server commands) defined within interfaces, not routers.
FireHOL is "smart" enough to apply this parameter only to traffic send by the localhost, i.e. the replies of servers and requests of clients.
It is not possible, and FireHOL will simply ignore this parameter, on traffic coming in or passign through the firewall host.
sid <session>
session <session>
Description
sid or session 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.
This parameter can be used only in services (client and server commands) defined within interfaces, not routers.
FireHOL is "smart" enough to apply this parameter only to traffic send by the localhost, i.e. the replies of servers and requests of clients.
It is not possible, and FireHOL will simply ignore this parameter, on traffic coming in or passign through the firewall host.
cmd <name>
command <name>
Description
cmd or command 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.
This parameter can be used only in services (client and server commands) defined within interfaces, not routers.
FireHOL is "smart" enough to apply this parameter only to traffic send by the localhost, i.e. the replies of servers and requests of clients.
It is not possible, and FireHOL will simply ignore this parameter, on traffic coming in or passign through the firewall host.
DEFAULT_INTERFACE_POLICY
Description
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 policy does for an interface.
All packets that reach the end of an interface are logged only if the action is not return or accept.
You can control the frequency of this logging by altering the frequency loglimit uses.
Default: DEFAULT_INTERFACE_POLICY="DROP"
Example: DEFAULT_INTERFACE_POLICY="REJECT"
UNMATCHED_INPUT_POLICY
UNMATCHED_OUTPUT_POLICY
UNMATCHED_FORWARD_POLICY
Description
UNMATCHED_INPUT_POLICY controls the default action to be taken for incoming traffic not matched by any interface command.
UNMATCHED_OUTPUT_POLICY controls the default action to be taken for outgoing traffic not matched by any interface command.
UNMATCHED_FORWARD_POLICY controls the default action to be taken for forwarded traffic not matched by any router command.
All variables accept all the Actions FireHOL supports.
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 loglimit uses.
Default: UNMATCHED_INPUT_POLICY="DROP"
Default: UNMATCHED_OUTPUT_POLICY="DROP"
Default: UNMATCHED_FORWARD_POLICY="DROP"
Example: UNMATCHED_INPUT_POLICY="REJECT"
Example: UNMATCHED_OUTPUT_POLICY="REJECT"
Example: UNMATCHED_FORWARD_POLICY="REJECT"
FIREHOL_INPUT_ACTIVATION_POLICY
FIREHOL_OUTPUT_ACTIVATION_POLICY
FIREHOL_FORWARD_ACTIVATION_POLICY
Description
All these variables have been added in v1.133
FIREHOL_INPUT_ACTIVATION_POLICY controls the default action to be taken for incoming traffic during firewall activation.
FIREHOL_OUTPUT_ACTIVATION_POLICY controls the default action to be taken for outgoing traffic during firewall activation.
FIREHOL_FORWARD_ACTIVATION_POLICY controls the default action to be taken for forwarded traffic during firewall activation.
All variables accept either ACCEPT, DROP or REJECT.
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).
Default: FIREHOL_INPUT_ACTIVATION_POLICY="ACCEPT"
Default: FIREHOL_OUTPUT_ACTIVATION_POLICY="ACCEPT"
Default: FIREHOL_FORWARD_ACTIVATION_POLICY="ACCEPT"
Example: FIREHOL_INPUT_ACTIVATION_POLICY="REJECT"
Example: FIREHOL_OUTPUT_ACTIVATION_POLICY="REJECT"
Example: FIREHOL_FORWARD_ACTIVATION_POLICY="REJECT"
FIREHOL_LOG_LEVEL
FIREHOL_LOG_OPTIONS
FIREHOL_LOG_FREQUENCY
FIREHOL_LOG_BURST
Description
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 log optional rule parameter.
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.
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.
Default: FIREHOL_LOG_OPTIONS="--log-level warning"
Default: FIREHOL_LOG_FREQUENCY="1/second"
Default: FIREHOL_LOG_BURST="5"
Example: FIREHOL_LOG_OPTIONS="--log-level info --log-tcp-options --log-ip-options"
Example: FIREHOL_LOG_FREQUENCY="30/minute"
Example: FIREHOL_LOG_BURST="2"
To see the available iptables log options, run /sbin/iptables -j LOG --help
To see what iptables accepts as frequencies and bursts run, /sbin/iptables -m limit --help
You can also check man iptables.
DEFAULT_CLIENT_PORTS
Description
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.
Default: DEFAULT_CLIENT_PORTS="1024:65535"
Example: DEFAULT_CLIENT_PORTS="0:65535"
FIREHOL_NAT
Description
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 Helper Commands that do NAT.
Default: FIREHOL_NAT="0"
Example: FIREHOL_NAT="1"
FIREHOL_AUTOSAVE
Description
FIREHOL_AUTOSAVE controls the file that will be created when FireHOL is called with the save 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.
Default: FIREHOL_AUTOSAVE=""
Example: FIREHOL_AUTOSAVE="/tmp/firehol-saved.txt"
FIREHOL_LOAD_KERNEL_MODULES
Description
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.
Default: FIREHOL_LOAD_KERNEL_MODULES=1
Example: FIREHOL_LOAD_KERNEL_MODULES=0
RESERVED_IPS
Description
This variable includes all the IP addresses defined as IANA - Reserved by IANA.
The supplied get-iana.sh script creates this variable by directly fetching this document.
Example: interface eth0 internet src not "${RESERVED_IPS}"
PRIVATE_IPS
Description
This variable includes all the IP addresses defined as Private or Test by RFC 3330.
Example: interface eth0 internet src not "${PRIVATE_IPS}"
UNROUTABLE_IPS
Description
This variable is both RESERVED_IPS and PRIVATE_IPS together. I suggest to use this variable on interfaces and routers
accepting Internet traffic.
Example: interface eth0 internet src not "${UNROUTABLE_IPS}"
|
$Id: commands.html,v 1.40 2003/09/18 20:54:27 ktsaou Exp $
FireHOL, a firewall for humans...
© Copyright 2003
Costa Tsaousis <costa@tsaousis.gr>
|