1FIREHOL.CONF(5) File Formats Manual FIREHOL.CONF(5)
2
6 firehol.conf - Configuration file for firehol(1)
7
9 firehol.conf is the configuration file for firehol(1), which creates an
10 iptables firewall from the simple rules in this file.
11 This file is parsed as a bash(1) script, so it's no problem to use
13 variables or complex bashisms.
14
16 interface <real interface> <name> [optional rule parameters]
17 The interface command creates a firewall for protecting the host the
19 firewall is running, from the given interface. The default interface
20 policy is drop, so that if no subcommands are given, the firewall
21 will just drop all incoming and outgoing traffic using this inter‐
22 face.
23 Parameters
25 · real interface
27 This is the interface name as shown by ip link show. Generally any‐
28 thing iptables accepts, including the pattern character + (the plus
29 sign), is valid. The plus sign after some text will match all
30 interfaces that start with this text. It is allowed to use more
31 than one interfaces separated by spaces, but all of them should be
32 given within one quoted argument. Example:
33 interface "eth0 eth1 ppp0" myname
35 · name
37 This is a name for this interface. Generally you should use short
38 names (10 characters max) without spaces or other symbols. You
39 should not use the same name more than once in FireHOL primary com‐
40 mands.
41 · optional rule parameters
43 This is a set of rules that allow further restriction of the traf‐
44 fic that gets matched for this interface. See section Optional
45 Rules Parameters for more information. Examples:
46 interface eth0 intranet src 10.0.0.0/16
48 interface eth0 internet src not "$UNROUTABLE_IPS" (note:
50 UNROUTABLE_IPS is a variable defined by FireHOL that includes all
51 IPs that should not be routable by the Internet).
52 router <name> [optional rule parameters]
54 The router command creates a firewall for the traffic passing through
56 the host running the firewall. The only acceptable policy on all
57 router commands is return and therefore the policy subcommand cannot
58 be used on routers. This means that no packets are dropped in a
59 router. Packets not matched by any router command will be dropped at
60 the end of the firewall.
61 Parameters
63 · name
65 This is a name for this router. The same restrictions of interface
66 names apply here too.
67 · optional rule parameters
69 This is a set of rules that allow further restriction of the traf‐
70 fic that gets matched for this router. See section Optional Rules
71 Parameters for more information.
72 Description
74 Router statements produce similar iptables commands the interface
76 statements produce. For each router statement an in_name and an
77 out_name chain are produced to match the traffic in both directions
78 of the router.
79 To match some client or server traffic the administrator has to
81 specify the input/output interface or the source/destination of the
82 request. All inface/outface, src/dst optional rule parameters can
83 be given either on the router statement in which case will be
84 applied to all subcommands for this router, or on each subcommand
85 within a router. Both are valid.
86 For example:
88 router mylan inface ppp+ outface eth0
90 server http accept
91 client smtp accept
92 The above says: Define a router that matches all requests that
94 originate from some PPP interface and go out to eth0. There is an
95 HTTP server in eth0 that client from the PPP interfaces are allowed
96 to reach. Clients on eth0 are allowed to get SMTP traffic from the
97 PPP interfaces.
98 While:
100 router mylan
102 server http accept inface ppp+ outface eth0
103 server smtp accept inface eth0 outface ppp+
104 The above says: Define a router that matches any kind of forwarded
106 traffic. For HTTP traffic the clients are on a PPP interface and
107 the servers on eth0. For SMTP traffic the clients are on a eth0
108 interface and the servers o a PPP interface.
109 Please note that in the second example the SMTP traffic is matched
111 again with a server subcommand, not a client (as in the first exam‐
112 ple).
113 The client subcommand reverses all the optional rules that are
115 applied indirectly to it. Indirect rule parameters are those that
116 are inherited from the parent command (router in this case). To
117 make it simple, for FireHOL a client is: "a server with all the
118 implicit optional rule parameters reversed".
119 So, in the first example, the client simply flipped the inface and
121 outface rules defined at the router and became an SMTP server. In
122 the second example there is nothing to be flipped, so server and
123 client are exactly the same.
124 I suggest to use client subcommands in routers only if you have
126 inface/outface or src/dst in the router statements. If you are
127 building routers like the second example, don't use client, it is
128 confusing.
129 Older versions of FireHOL did not allow server and client subcom‐
131 mands in routers. Only the route subcommand was allowed. Today,
132 route is just an alias for server and can be used only in routers,
133 not interfaces.
134 Any number of router statements can exist. Since the policy is
136 RETURN on all of them, any traffic not matched by a router will
137 continue to be checked against the second.
138
140 Subcommands must be given within Primary commands.
141 policy <action>
143 The policy subcommand defines the default policy for an interface.
145 This directive accepts all the actions specified in the section
147 Actions.
148 The policy of routers cannot be changed and is always RETURN.
150 protection [reverse] <type>
152 The protection subcommand sets a number of protection rules on an
154 interface.
155 In router configurations, protections are setup on inface.
157 Parameters
159 reverse
161 The reverse keyword will make the protections setup on outface.
162 type
164 One of the following values:
165 strong, full or all
167 Turns on all known protections
168 fragments
170 Drops all packet fragments. Please note that most probably this
171 rule will never match anything since iptables reconstructs all
172 packets automatically, before the iptables firewall rules are
173 processed, when its connection tracker is running.
174 new-tcp-w/o-syn
176 Drops all TCP packets that initiate a socket but have no the SYN
177 bit set.
178 syn-floods [requests/sec [burst]]
180 Allows only a certain amount of new TCP connections per second.
181 The optional two arguments [requests/sec] and [burst] are used by
182 this rule in order to provide control on the number of connec‐
183 tions to be allowed. The default is 100 connections per second
184 that can match 50 (it was 4 in v1.38 and before) packets ini‐
185 tially (this is implemented using the limit module of iptables:
186 see man iptables for more). Note that this rule applies to all
187 connections attempted regardless of their final result (rejected,
188 dropped, established, etc). Therefore it might not be a good idea
189 to set it too low.
190 icmp-floods [requests/sec [burst]]
192 Allows only a certain amount of ICMP echo requests per second.
193 The optional two arguments [requests/sec] and [burst] are used by
194 this rule in order to provide control on the number of connec‐
195 tions to be allowed. The default is 100 connections per second
196 that can match 50 (it was 4 in v1.38 and before) packets ini‐
197 tially (this is implemented using the limit module of iptables:
198 see man iptables for more).
199 malformed-xmas
201 Drops all TCP packets that have all TCP flags set.
202 malformed-null
204 Drops all TCP packets that have all TCP flags unset.
205 malformed-bad
207 Drops all TCP packets that have illegal combinations of TCP flags
208 set.
209 server <service> <action> [optional rule parameters]
211 The server subcommand defines a server of a service. For FireHOL a
213 server is the destination of a request, and even if this is more com‐
214 plex for multi-socket services, for FireHOL a server always accepts
215 requests.
216 The optional rule parameters given to the parent primary command
218 (interface or router) are inherited by the server as they have been
219 given.
220 This subcommand can be used on both interfaces and routers.
222 Parameters
224 service
226 This is one of the supported service names. The command accepts
227 more than one services in the same argument if they are separated
228 by space and quoted as a single argument. Example:
229 server smtp accept
231 server "smtp pop3 imap" accept
233 action
235 This tells FireHOL what to do with the traffic matching this rule.
236 FireHOL supports the actions defined in the section Actions.
238 optional rule parameters
240 This is a set of rules that allow further restriction of the traf‐
241 fic that gets matched by this rule. See section Optional Rules
242 Parameters for more information. Examples:
243 server smtp accept src 1.2.3.4
245 server smtp accept log "its mail" src 1.2.3.4
247 client <service> <action> [optional rule parameters]
249 The client subcommand defines a client of a service. For FireHOL a
251 client is the source of a request. FireHOL follows this simple rule
252 even on multi-socket complex protocols, so that for FireHOL a client
253 always sends requests. The parameters are exactly the same with the
254 server subcommand.
255 The optional rule parameters given to the parent primary command
257 (interface or router) are inherited by the client, but they are
258 reversed. For an explanation of this please refer to the documenta‐
259 tion of the router primary command.
260 This subcommand can be used on both interfaces and routers.
262 route <service> <action> [optional rule parameters]
264 The route subcommand is an alias for the server command that can be
266 used only on routers, not interfaces.
267
269 version <number>
270 The version command states the FireHOL release the configuration file
272 was created for. In case the configuration file is newer than Fire‐
273 HOL, FireHOL will deny to run it.
274 This command is here to allow you or anyone else design and distrib‐
276 ute FireHOL configuration files, while ensuring that the correct
277 FireHOL version is going to run them.
278 The FireHOL release is increased every time the format of the config‐
280 uration file and the internals of FireHOL are changed.
281 Since FireHOL v1.67 version is not required to be present in every
283 configuration file.
284 iptables <arguments>
286 The iptables command passes all its arguments to the real iptables
288 command, during run-time.
289 You should not use /sbin/iptables directly to alter a FireHOL fire‐
291 wall in its configurations. If you do, your commands will be run
292 before FireHOL activates its firewall and while the previous firewall
293 is still running. Also, since FireHOL will delete all previous fire‐
294 wall rules in order to activate the new firewall, any changes you
295 will make, will be deleted too.
296 Always use the iptables directive to hook iptables commands in a
298 FireHOL firewall. Nothing else.
299 masquerade [reverse ⎪ interface] [optional rule parameters]
301 Masquerading is a special from of SNAT (Source NAT) that changes the
303 source of requests when they go out and replaces their original
304 source when replies come in. This way a Linux box can become an
305 internet router for a LAN of clients having unroutable IP addresses.
306 Masquerading takes care to re-map IP addresses and ports as required.
307 Masquerading is "expensive" compared to SNAT because it checks the IP
309 address of the ougoing interface every time for every packet, and
310 therefore it is suggested that if you connect to the internet with a
311 static IP address, to prefer SNAT.
312 The masquerade helper sets up masquerading on the output of a network
314 interface (not the interface command, but a real network interface).
315 If the masquerade command is placed within an interface command, its
317 network interface[s] will be used.
318 If the masquerade command is placed within a router command that has
320 an outface defined, then the outface network interface[s] will be
321 used.
322 If placed within a router command but the keyword reverse is speci‐
324 fied and the router command has an inface defined, then the inface
325 network interface[s] will be used.
326 If placed outside and before all primary commands, an interface (or
328 list of space separated interfaces, within double quotes) can be
329 specified on the masquerade command.
330 In all cases, masquerade will setup itself on the output of the given
332 interface[s].
333 Please note that if masquerade is used within some interface or
335 router, it does not respect the optional rule parameters given to
336 this interface or router command. Masquerade uses only its own
337 optional rule parameters.
338 inface and outface should not be given as parameters to masquerade
340 (inface because iptables does not support this in the POSTROUTING
341 chain, and outface because it will be overwritten by the interface(s)
342 mentioned above).
343 Finally, the masquerade helper will turn on FIREHOL_NAT and instruct
345 the kernel to do packet forwarding (like the router commands do).
346 Examples:
348 Before the first interface or router:
350 masquerade eth0 src 10.0.0.0/8 dst not 10.0.0.0/8
351 Within an interface rule to masquerade on the output of this inter‐
353 face:
354 masquerade
355 Within a router rule to masquerade on the output of the router's
357 inface:
358 masquerade reverse
359 transparent_squid <port> <user> [optional rule parameters]
361 The transparent_squid helper sets up trasparent caching for HTTP
363 traffic. The squid proxy is assumed to be running on the firewall
364 host at port port (port defaults to squid), with the credentials of
365 the local user user (user defaults to squid).
366 The transparent_squid helper can be used for two kinds of traffic:
368 · Incoming HTTP traffic
370 Incoming HTTP traffic, which is either targeted to the firewall
371 host or passing through the firewall host.
372 The optional rule parameters can be used to specify which kind of
374 incoming traffic to be catched (by using inface, src, dst, etc --
375 outface should not be used here, because the rules generated are
376 placed before the routing decision and therefore the outgoing
377 interface is not yet known).
378 If no optional rule parameters are given, then the transparent
380 cache will be setup on all network interfaces for all HTTP traffic
381 (use this with care since you are risking to serve requests from
382 the internet using your squid).
383 · Locally HTTP traffic
385 Locally generated HTTP traffic except traffic generated by pro‐
386 cesses running as user user. The optional rule parameters inface,
387 outface and src are ignored for this type of traffic.
388 This kind of matching makes it possible to support transparent
390 caching for WEB browsers running on the firewall host, as far as
391 they do not run as the user excluded. More than one users can be
392 specified by space-separating and enclosing them in double quotes.
393 This rule can be disabled by specifing as user the empty string: ""
395 Examples:
397 transparent_squid 3128 squid inface eth0 src 10.0.0.0/8
399 transparent_squid 8080 "squid privoxy root bin" inface not "ppp+
401 ipsec+" dst not "a.not.proxied.server"
402 nat <type> <target> [optional rule parameters]
404 The nat helper sets up a NAT rule for routed traffic.
406 The type parameter can be:
408 to-source
410 Defines a Source NAT (created in NAT/POSTROUTING).
411 The target in this case is the source address to be set in packets
413 matching the optional rule parameters (if no optional rule parame‐
414 ters, all forwarded traffic will be matched). target accepts all
415 --to-source values iptables accepts (see iptables -j SNAT --help).
416 Multiple --to-source values can be given, if separated by space and
417 quoted as a single argument.
418 inface should not be used in SNAT, because iptables does provide
420 this information at this point.
421 to-destination
423 Defines a Destination NAT (created in NAT/PREROUTING).
424 The target in this case is the destination address to be set in
426 packets matching the optional rule parameters (if no optional rule
427 parameters, all forwarded traffic will be matched). target accepts
428 all --to-destination values iptables accepts (see iptables -j DNAT
429 --help). Multiple --to-destination values can be given, if sepa‐
430 rated by space and quoted as a single argument.
431 outface should not be used in DNAT, because iptables does provide
433 this information at this point.
434 redirect-to
436 Catches traffic comming in and send it to the local machine (cre‐
437 ated in NAT/PREROUTING).
438 The target in this case is a port or a range of ports (XXX-YYY)
440 that packets matching the rule will be redirected to (if no
441 optional rule parameters are given, all incomming traffic will be
442 matched). target accepts all --to-ports values iptables accepts
443 (see iptables -j REDIRECT --help).
444 outface should not be used in REDIRECT, because iptables does pro‐
446 vide this information at this point.
447 Please understand that the optional rule parameters are used only to
449 limit the traffic to be matched. Consider these examples:
450 Sends to 1.1.1.1 all traffic comming in or passing trhough the fire‐
452 wall host:
453 nat to-destination 1.1.1.1
454 Redirects to 1.1.1.1 all traffic comming in or passing through, and
456 going to 2.2.2.2:
457 nat to-destination 1.1.1.1 dst 2.2.2.2
458 Redirects to 1.1.1.1 all TCP traffic comming in or passing through
460 and going to 2.2.2.2:
461 nat to-destination 1.1.1.1 proto tcp dst 2.2.2.2
462 Redirects to 1.1.1.1 all traffic comming in or passing through and
464 going to 2.2.2.2 to port tcp/25:
465 nat to-destination 1.1.1.1 proto tcp dport 25 dst 2.2.2.2
466 More examples:
468 nat to-source 1.1.1.1 outface eth0 src 2.2.2.2 dst 3.3.3.3
470 nat to-destination 4.4.4.4 inface eth0 src 5.5.5.5 dst 6.6.6.6
472 nat redirect-to 8080 inface eth0 src 2.2.2.0/24 proto tcp dport 80
474 snat [to] <target> [optional rule parameters]
476 The snat helper sets up a Source NAT rule for routed traffic, by
478 calling nat to-source target [optional rule parameters]
479 See the nat helper.
481 Example:
483 snat to 1.1.1.1 outface eth0 src 2.2.2.2 dst 3.3.3.3
485 dnat [to] <target> [optional rule parameters]
487 The dnat helper sets up a Destination NAT rule for routed traffic, by
489 calling nat to-destination target [optional rule parameters]
490 See the nat helper.
492 Example:
494 dnat to 1.1.1.1 inface eth0 src 2.2.2.2 dst 3.3.3.3
496 redirect [to] <target> [optional rule parameters]
498 The redirect helper catches all incomming traffic matching the
500 optional rule parameters given and redirects it to ports on the local
501 host, by calling nat redirect-to target [optional rule parameters]
502 See the nat helper.
504 Example:
506 nat redirect-to 8080 inface eth0 src 2.2.2.0/24 proto tcp dport 80
508
510 Actions are the actions to be taken on services and traffic described
511 by other commands and functions. Please note that normally, FireHOL
512 will pass-through to the generated iptables statements all the possible
513 actions iptables accepts, but only the ones defined here can be used
514 with lower case letters and currently it will be impossible to pass
515 arguments to some unknown action. Also, keep in mind that the iptables
516 action LOG is a FireHOL optional rule parameter (see log and loglimit)
517 that can be defined together with one of the following actions and
518 FireHOL will actually produce multiple iptables statements to achieve
519 both the logging and the action.
520 accept
522 accept allows the traffic matching the rules to reach its destina‐
524 tion.
525 Example:
527 server smtp accept, to allow SMTP requests and their replies to
529 flow.
530 reject [with message]
532 reject discards the matching traffic but sends a rejecting message
534 back to the sender.
535 with is used to offer control on the message to be returned to the
537 sender. with accepts all the arguments the --reject-with iptables
538 expression accepts. For an updated list of these messages type ipta‐
539 bles -j REJECT --help.
540 Examples:
542 policy reject with host-unreach
544 server ident reject with tcp-reset
546 UNMATCHED_INPUT_POLICY="reject with host-prohib"
548 drop
550 drop silently discards the matching traffic. The fact that the traf‐
552 fic is silently discarded makes the sender timeout in order to con‐
553 clude that it is not possible to use the wanted service.
554 Example:
556 server smtp drop, to silently discard SMTP requests and their
558 replies.
559 deny
561 deny is just an alias for drop, made for those who are used to
563 ipchains terminology.
564 Example:
566 server smtp deny, to silently discard SMTP requests and their
568 replies.
569 return
571 return will return the flow of processing to the parent of the cur‐
573 rent command. Currently, it has meaning to specify the action return
574 only as a policy to some interface.
575 Example:
577 policy return
579 Traffic not matched by any rule within an interface continues trav‐
580 eling through the firewall and is possibly matched by other inter‐
581 faces bellow.
582 mirror
584 mirror will return the traffic to the wanted port, back to the send‐
586 ing host. Use this with care, and only if you understand what you
587 doing. Keep also in mind that FireHOL will apply this action to both
588 requests and replies comming in or passing through, and will replace
589 it with REJECT for traffic generated by the local host.
590 redirect [to-port port]
592 redirect is used internally by FireHOL Helper Commands to redirect
594 traffic to ports on the local host. Unless you are a developer, you
595 will never need to use this directly.
596
598 Optional rule parameters are accepted by many commands to narrow the
599 match they do by default. The parameters described bellow are all that
600 FireHOL supports. You should check the documentation of each command to
601 find which parameters should not be used with it. Normally, all Fire‐
602 HOL commands are designed so that if you specify a parameters that is
603 also used internally, the internal one will overwrite the one given in
604 the configuration file. In such a case, FireHOL will present you a
605 warning with the old and the new value.
606 Not all parameters should be used in all cases. For example sport and
608 dport should not be used in normal server and client commands since
609 such ports are internally defined by the services themselves. In any
610 case, FireHOL will complain about optional rule parameters that should
611 not be used in certain commands.
612 src [not] <host>
614 src defines the source IP address of the REQUEST. If src is defined
616 on a server statement it matches the source of the request which is
617 the remote host, while if it is defined on a client statement it
618 matches again the source of the request, but this time it is the
619 local host. Focus on the REQUEST!!! Forget the reply.
620 Parameters
622 not
624 Optional argument that reverses the match. When defined, the rule
625 will match all hosts except the ones defined. Example:
626 server smtp accept src not 1.2.3.4
627 host
629 An IP address, a hostname, or a subnet. Multiple hosts/networks can
630 be defined if separated by space and quoted as a single argument.
631 Examples:
632 server smtp accept src 1.2.3.4
633 server smtp accept src not "1.2.3.0/24 5.6.7.8 badhost.exam‐
634 ple.com"
635 dst [not] <host>
637 dst defines the destination of the REQUEST. If dst is defined on a
639 server statement it matches the destination of the request which is
640 the local host, while if it is defined on a client statement it
641 matches again the destination of the request, but this time it is the
642 remote host. Focus on the REQUEST!!! Forget the reply.
643 dst accepts the same parameters as src.
645 inface [not] <interface>
647 inface defines the interface the REQUEST is received via. inface can‐
649 not be used in interface commands.
650 Parameters
652 not
654 An optional argument that reverses the match. When defined, the
655 rule will match all interfaces except the ones defined. Example:
656 server smtp accept inface not eth0
657 interface
659 if an interface name in the same format the interface command
660 accepts. Multiple interfaces can be defined if separated by space
661 and quoted as a single argument. Examples:
662 server smtp accept inface not eth0
663 server smtp accept inface not "eth0 eth1"
664 outface [not] <interface>
666 outface defines the interface the REQUEST is send via. outface cannot
668 be used in interface commands.
669 outface accepts the same parameters as inface.
671 custom <parameters>
673 custom passes its arguments to the generated iptables commands.
675 It is required to quote all the parameters given to custom. If the
677 parameters include a space character between some text that is
678 required to be given to iptables as one argument, it is required to
679 escape another set of quotes in order. Another way is to use double
680 quotes externally and single quotes internally.
681 Examples:
683 server smtp accept custom "--some-iptables-option and_its_value"
685 server smtp accept custom "--some-iptables-option 'one_value another_value'
687 log "<some text>" [level a_level]
689 log will log the matching packets to syslog. Note that this is not an
691 action (in iptables it is). FireHOL will actually produce multiple
692 iptables commands to accomplish both the action for the rule and the
693 logging. You can control how logging works, by altering the variables
694 FIREHOL_LOG_OPTIONS and FIREHOL_LOG_LEVEL. You can also change the
695 level of just one rule by using the level argument of the log parame‐
696 ter.
697 FireHOL logs traffic, exactly the same way iptables does. Many users
699 have complained about packet logs appearing at their console. To
700 avoid this you will have to:
701 · setup klogd to log only more important traffic
703 · change FIREHOL_LOG_LEVEL to log at a not so important log-level
704 Actually klogd's -c option and iptables' --log-level option are the
706 same thing (iptables accepts also the numeric values klogd accepts).
707 If iptables logs at a higher priority than klogd is configured to
708 use, then your packets will appear in the console too.
709 loglimit "<some text>"
711 loglimit is the same with log but limits the frequency of logging
713 according to the setting of FIREHOL_LOG_FREQUENCY and FIRE‐
714 HOL_LOG_BURST.
715 proto [not] <protocol>
717 proto sets the required protocol for the traffic. This command
719 accepts anything iptables accepts as protocols.
720 limit <frequency> <burst>
722 limit will limit the match in both directions of the traffic (request
724 and reply). This is used internally by FireHOL and its effects has
725 not been tested in the high level configuration file directives.
726 sport <port>
728 sport defines the source port of a request. It accepts port names,
730 port numbers, port ranges (FROM:TO) and multiple ports (or ranges)
731 seperated by spaces and quoted as a single argument. This parameter
732 should not be used in normal services definitions (client and server
733 commands) or interface and router definitions, unless you really
734 understand what you are doing.
735 dport <port>
737 dport defines the destination port of a request. It accepts port
739 names, port numbers, port ranges (FROM:TO) and multiple ports (or
740 ranges) seperated by spaces and quoted as a single argument. This
741 parameter should not be used in normal services definitions (client
742 and server commands) or interface and router definitions, unless you
743 really understand what you are doing.
744 uid [not] <user> =head2 user [not] <user>
746 uid or user define the operating system user sending this traffic.
748 The parameter can be a username, a user number or a list of these
749 two, seperated by spaces and quoted as a single argument.
750 This parameter can be used only in services (client and server com‐
752 mands) defined within interfaces, not routers. FireHOL is "smart"
753 enough to apply this parameter only to traffic send by the localhost,
754 i.e. the replies of servers and requests of clients. It is not possi‐
755 ble, and FireHOL will simply ignore this parameter, on traffic coming
756 in or passign through the firewall host.
757 Example 1:
759 client "pop3 imap" accept user not "user1 user2 user3" dst mymailer.example.com
761 The above will allow local users except user1, user2 and user3 to use
763 POP3 and IMAP services on mymailer.example.com. You can use this, for
764 example, to allow only a few of the local users use the fetchmail
765 program to fetch their mail from the mail server.
766 Example 2:
768 server http accept user apache
770 The above will allow all HTTP to reach the local http server, but
772 only if the web server is running as user apache the replies will be
773 send back to the HTTP client.
774 gid <group> =head2 group <group>
776 gid or group define the operating system user group sending this
778 traffic. The parameter can be a group name, a group number or a list
779 of these two, seperated by spaces and quoted as a single argument.
780 This parameter can be used only in services (client and server com‐
782 mands) defined within interfaces, not routers. FireHOL is "smart"
783 enough to apply this parameter only to traffic send by the localhost,
784 i.e. the replies of servers and requests of clients. It is not possi‐
785 ble, and FireHOL will simply ignore this parameter, on traffic coming
786 in or passing through the firewall host.
787 pid <process> =head2 process <process>
789 pid or process define the operating system process ID (or PID) send‐
791 ing this traffic. The parameter can be a PID or a list of PIDs,
792 seperated by spaces and quoted as a single argument.
793 This parameter can be used only in services (client and server com‐
795 mands) defined within interfaces, not routers. FireHOL is "smart"
796 enough to apply this parameter only to traffic send by the localhost,
797 i.e. the replies of servers and requests of clients. It is not possi‐
798 ble, and FireHOL will simply ignore this parameter, on traffic coming
799 in or passign through the firewall host.
800 sid <session> =head2 session <session>
802 sid or session define the operating system session ID of the process
804 sending this traffic (The session ID of a process is the process
805 group ID of the session leader). The parameter can be a list of such
806 IDs, seperated by spaces and quoted as a single argument.
807 This parameter can be used only in services (client and server com‐
809 mands) defined within interfaces, not routers. FireHOL is "smart"
810 enough to apply this parameter only to traffic send by the localhost,
811 i.e. the replies of servers and requests of clients. It is not possi‐
812 ble, and FireHOL will simply ignore this parameter, on traffic coming
813 in or passign through the firewall host.
814
816 DEFAULT_INTERFACE_POLICY
817 DEFAULT_INTERFACE_POLICY controls the default action to be taken on
819 traffic not matched by any rule within an interface. Actually, this
820 is a global setting for what policy does for an interface.
821 All packets that reach the end of an interface are logged only if the
823 action is not return or accept. You can control the frequency of this
824 logging by altering the frequency loglimit uses.
825 Default: DEFAULT_INTERFACE_POLICY="DROP"
827 Example: DEFAULT_INTERFACE_POLICY="REJECT"
829 UNMATCHED_INPUT_POLICY
831 UNMATCHED_OUTPUT_POLICY
833 UNMATCHED_FORWARD_POLICY
835 UNMATCHED_INPUT_POLICY controls the default action to be taken for
837 incoming traffic not matched by any interface command.
838 UNMATCHED_OUTPUT_POLICY controls the default action to be taken for
840 outgoing traffic not matched by any interface command.
841 UNMATCHED_FORWARD_POLICY controls the default action to be taken for
843 forwarded traffic not matched by any router command.
844 All variables accept all the Actions FireHOL supports.
846 All packets that reach the end of firewall in all three chains are
848 logged (always, regardless of these settings). You can control the
849 frequency of this logging by altering the frequency loglimit uses.
850 Default: UNMATCHED_INPUT_POLICY="DROP"
852 Default: UNMATCHED_OUTPUT_POLICY="DROP"
854 Default: UNMATCHED_FORWARD_POLICY="DROP"
856 Example: UNMATCHED_INPUT_POLICY="REJECT"
858 Example: UNMATCHED_OUTPUT_POLICY="REJECT"
860 Example: UNMATCHED_FORWARD_POLICY="REJECT"
862 FIREHOL_LOG_LEVEL =head2 FIREHOL_LOG_OPTIONS =head2 FIREHOL_LOG_FRE‐
864 QUENCY =head2 FIREHOL_LOG_BURST
865 FIREHOL_LOG_LEVEL controls the level at which iptables will log
867 things to the syslog. For a description of the possible values sup‐
868 ported and for per-rule control of log level, see the log optional
869 rule parameter.
870 FIREHOL_LOG_OPTIONS controls the way iptables will log things to the
872 syslog. The value of this variable is passed as is to iptables, so
873 use exact iptables parameters.
874 FIREHOL_LOG_FREQUENCY and FIREHOL_LOG_BURST (added in v1.39 of Fire‐
876 HOL) control the frequency at each each logging rule will write pack‐
877 ets to the syslog. FIREHOL_LOG_FREQUENCY is set to the maximum aver‐
878 age frequency and FIREHOL_LOG_BURST specifies the maximum initial
879 number of packets to match.
880 Default: FIREHOL_LOG_OPTIONS="--log-level warning"
882 Default: FIREHOL_LOG_FREQUENCY="1/second"
884 Default: FIREHOL_LOG_BURST="5"
886 Example: FIREHOL_LOG_OPTIONS="--log-level info --log-tcp-options --log-ip-options"
888 Example: FIREHOL_LOG_FREQUENCY="30/minute"
890 Example: FIREHOL_LOG_BURST="2"
892 To see the available iptables log options, run "/sbin/iptables -j LOG
894 --help" To see what iptables accepts as frequencies and bursts, run
895 "/sbin/iptables -m limit --help"
896 You can also check man iptables.
898 DEFAULT_CLIENT_PORTS
900 DEFAULT_CLIENT_PORTS controls the port range to be used when a remote
902 client is specified. For localhost clients, FireHOL finds the exact
903 client ports by querying the kernel options.
904 Default: 1000:65535
906 Example: DEFAULT_CLIENT_PORTS="0:65535"
908 FIREHOL_NAT
910 If FIREHOL_NAT is set to 1, FireHOL will load NAT kernel modules for
912 those services that they are require such. FireHOL sets this to 1
913 automatically if you use the Helper Commands that do NAT.
914 Default: FIREHOL_NAT="0"
916 Example: FIREHOL_NAT="1"
918 FIREHOL_AUTOSAVE
920 FIREHOL_AUTOSAVE controls the file that will be created when FireHOL
922 is called with the save command line argument. If this variable is
923 empty (the default), FireHOL will try to detect where to save the
924 file. Currently, the RedHat way (/etc/sysconfig/iptables) and the
925 Debian way (/var/lib/iptables/autosave) are automatically detected
926 (in the order given here) based on the existance of the directory
927 this file should be created in.
928 Default: FIREHOL_AUTOSAVE="" Example: FIREHOL_AUTOSAVE="/tmp/fire‐
930 hol-saved.txt"
931
933 RESERVED_IPS
934 This variable includes all the IP addresses defined as IANA -
936 Reserved by IANA.
937 Example: interface eth0 internet src not "${RESERVED_IPS}"
939 PRIVATE_IPS
941 This variable includes all the IP addresses defined as Private or
943 Test by RFC 3330.
944 Example: interface eth0 internet src not "${PRIVATE_IPS}"
946 UNROUTABLE_IPS
948 This variable is both RESERVED_IPS and PRIVATE_IPS together. I sug‐
950 gest to use this variable on interfaces and routers accepting Inter‐
951 net traffic.
952 Example: interface eth0 internet src not "${UNROUTABLE_IPS}"
954
956 /etc/firehol/firehol.conf
957
959 firehol written by Costa Tsaousis <costa@tsaousis.gr>.
960 Man page written by Marc Brockschmidt <<marc@marcbrockschmidt.de>.
962
964 firehol(1), iptables(8), bash(1)
965 2003-06-09 FIREHOL.CONF(5)