Provided by: firehol_1.273-1_all bug

NAME

       firehol.conf - Configuration file for firehol(1)

DESCRIPTION

       firehol.conf is the configuration file for firehol(1), which creates an
       iptables firewall from the simple rules in this file.

       This file is parsed as a bash(1) script, so it’s no problem to use
       variables or complex bashisms.

Commands

       interface <real interface> <name> [optional rule parameters]

         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.

         Parameters

         · real interface
           This 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
           This 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
           This is a set of rules that allow further restriction of the
           traffic that gets matched for this interface. See section Optional
           Rules Parameters for more information. Examples:

             interface eth0 intranet src 10.0.0.0/16

             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]

         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.

         Parameters

         · name
           This is a name for this router. The same restrictions of interface
           names apply here too.

         · optional rule parameters
           This is a set of rules that allow further restriction of the
           traffic that gets matched for this router. See section Optional
           Rules Parameters for more information.

         Description

           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

       Subcommands must be given within Primary commands.

       policy <action>

         The policy subcommand defines the default policy for an interface.

         This directive accepts all the actions specified in the section
         Actions.

         The policy of routers cannot be changed and is always RETURN.

       protection [reverse] <type>

         The protection subcommand sets a number of protection rules on an
         interface.

         In router configurations, protections are setup on inface.

         Parameters

         reverse
           The reverse keyword will make the protections setup on outface.

         type
           One of the following values:

           strong, full or all
             Turns on all known 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.

           new-tcp-w/o-syn
             Drops all TCP packets that initiate a socket but have no the SYN
             bit set.

           syn-floods [requests/sec [burst]]
             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 [requests/sec [burst]]
             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 TCP flags set.

           malformed-null
             Drops all TCP packets that have all TCP flags unset.

           malformed-bad
             Drops all TCP packets that have illegal combinations of TCP flags
             set.

       server <service> <action> [optional rule parameters]

         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

         service
           This is one of the supported service names. The command accepts
           more than one services in the same argument if they are separated
           by space and quoted as a single argument. Example:

             server smtp accept

             server "smtp pop3 imap" accept

         action
           This tells FireHOL what to do with the traffic matching this rule.

           FireHOL supports the actions defined in the section Actions.

         optional rule parameters
           This is a set of rules that allow further restriction of the
           traffic that gets matched by this rule. See section Optional Rules
           Parameters for more information. Examples:

             server smtp accept src 1.2.3.4

             server smtp accept log "its mail" src 1.2.3.4

       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

       version <number>

         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.

         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.

       iptables <arguments>

         The iptables command passes all its arguments to the real iptables
         command, during run-time.

         You should not use /sbin/iptables directly to alter a FireHOL
         firewall in its configurations. 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.

       masquerade [reverseinterface] [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).

         Examples:

           Before the first interface or router:
             masquerade eth0 src 10.0.0.0/8 dst not 10.0.0.0/8

           Within an interface rule to masquerade on the output of this
           interface:
             masquerade

           Within a router rule to masquerade on the output of the router’s
           inface:
             masquerade reverse

       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 (port defaults to squid), with the credentials of
         the local user user (user defaults to squid).

         The transparent_squid helper can be used for two kinds of traffic:

         · Incoming HTTP traffic
           Incoming HTTP traffic, which is either targeted to the firewall
           host or passing through the firewall host.

           The optional rule parameters can be used to specify which kind of
           incoming 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 HTTP traffic
           Locally generated HTTP traffic except traffic generated by
           processes running as user user. 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 than 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: ""

         Examples:

           transparent_squid 3128 squid inface eth0 src 10.0.0.0/8

           transparent_squid 8080 "squid privoxy root bin" inface not "ppp+
           ipsec+" dst not "a.not.proxied.server"

       nat <type> <target> [optional rule parameters]

         The nat helper sets up a NAT rule for routed traffic.

         The type parameter can be:

         to-source
           Defines 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 provide
           this information at this point.

         to-destination
           Defines 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.

           outface should not be used in DNAT, because iptables does provide
           this information at this point.

         redirect-to
           Catches 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
           provide this information at this point.

         Please understand that the optional rule parameters are used only to
         limit the traffic to be matched. Consider these examples:

         Sends to 1.1.1.1 all traffic comming in or passing trhough the
         firewall host:
           nat to-destination 1.1.1.1

         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 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 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

         More examples:

           nat to-source 1.1.1.1 outface eth0 src 2.2.2.2 dst 3.3.3.3

           nat to-destination 4.4.4.4 inface eth0 src 5.5.5.5 dst 6.6.6.6

           nat 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

       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

       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:

           nat redirect-to 8080 inface eth0 src 2.2.2.0/24 proto tcp dport 80

Actions

       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.

         Examples:

           policy reject with host-unreach

           server ident reject with tcp-reset

           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
           Traffic not matched by any rule within an interface continues
           traveling through the firewall and is 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

       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>

         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
           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
           An IP address, a hostname, or a subnet. Multiple hosts/networks can
           be defined if separated by space and quoted as a single argument.
           Examples:
             server smtp accept src 1.2.3.4
             server smtp accept src not "1.2.3.0/24 5.6.7.8
           badhost.example.com"

       dst [not] <host>

         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>

         inface defines the interface the REQUEST is received via. inface
         cannot be used in interface commands.

         Parameters

         not
           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. Examples:
             server smtp accept inface not eth0
             server smtp accept inface not "eth0 eth1"

       outface [not] <interface>

         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>

         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.

         Examples:

           server smtp accept custom "--some-iptables-option and_its_value"

           server smtp accept custom "--some-iptables-option ’one_value another_value’

       log "<some text>" [level a_level]

         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.

       loglimit "<some text>"

         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>

         proto sets the required protocol for the traffic. This command
         accepts anything iptables accepts as protocols.

       limit <frequency> <burst>

         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>

         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>

         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> =head2 user [not] <user>

         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> =head2 group <group>

         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 passing through the firewall host.

       pid <process> =head2 process <process>

         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> =head2 session <session>

         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.

Variables that control FireHOL

       DEFAULT_INTERFACE_POLICY

         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

         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_LOG_LEVEL =head2 FIREHOL_LOG_OPTIONS =head2
       FIREHOL_LOG_FREQUENCY =head2 FIREHOL_LOG_BURST

         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

         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: 1000:65535

          Example: DEFAULT_CLIENT_PORTS="0:65535"

       FIREHOL_NAT

         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

         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"

Variables that FireHOL offers

       RESERVED_IPS

         This variable includes all the IP addresses defined as IANA -
         Reserved by IANA.

          Example: interface eth0 internet src not "${RESERVED_IPS}"

       PRIVATE_IPS

         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

         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}"

FILES

       /etc/firehol/firehol.conf

AUTHOR

       firehol written by Costa Tsaousis <costa@tsaousis.gr>.

       Man page written by Marc Brockschmidt <<marc@marcbrockschmidt.de>.

SEE ALSO

       firehol(1), iptables(8), bash(1)

                                  2003-06-09                   FIREHOL.CONF(5)