FireHOL + FireQOS Reference

FireHOL Team

2.0.0-pre7


Table of Contents

1. Introduction
Latest version
Who should read this manual
Where to get help
Manual Organisation
Installation
Licence
I. FireHOL
2. Configuration
Getting started
Language
Use of bash
3. Security
Important Security Note
What happens when FireHOL Runs?
Where to learn more
4. Troubleshooting
Reading log output
II. FireQOS
5. Configuration
III. FireHOL Reference
I. Running and Configuring
FireHOL program: firehol — an easy to use but powerful iptables stateful firewall
FireHOL configuration: firehol.conf — FireHOL configuration file
control variables: firehol-variables — Variables controlling FireHOL
ipv4/ipv6 selection: firehol-modifiers — select IPv4 or IPv6 mode
II. Definition Commands
interface definition: firehol-interface — create an interface definition
router definition: firehol-router — create a router definition
III. Rule Subcommands
policy command: firehol-policy — set default action for a definition
protection command: firehol-protection — add extra protections to a definition
server, route commands: firehol-server — accept requests to a service
client command: firehol-client — accept replies from a service
group command: firehol-group — group commands with common options
IV. Optional Parameters and Actions
optional rule parameters: firehol-rule-params — optional rule parameters
actions for rules: firehol-actions — rule actions
V. Helper Commands
iptables helper: firehol-iptables — include custom iptables commands
masquerade helper: firehol-masquerade — set up masquerading (NAT) on an interface
tcpmss helper: firehol-tcpmss — set the MSS of TCP SYN packets for routers
VI. Configuration Helper Commands
version config helper: firehol-version — set version number of configuration file
action config helper: firehol-action — set up custom filter actions
blacklist config helper: firehol-blacklist — set up a unidirectional or bidirectional blacklist
classify config helper: firehol-classify — classify traffic for traffic shaping tools
connmark config helper: firehol-connmark — set a stateful mark on a connection
dscp config helper: firehol-dscp — set the DSCP field in the packet header
mac config helper: firehol-mac — ensure source IP and source MAC address match
mark config helper: firehol-mark — mark traffic for traffic shaping tools
nat, snat, dnat, redirect config helpers: firehol-nat — set up NAT and port redirections
transparent_proxy, transparent_squid helpers: firehol-transparent_proxy — set up a transparent proxy
tos config helper: firehol-tos — set the Type of Service (TOS) of packets
tosfix config helper: firehol-tosfix — apply suggested TOS values to packets
VII. Services Reference
services list: firehol-services — FireHOL service list
services list a: firehol-services-a — FireHOL service list a
services list b: firehol-services-b — FireHOL service list b
services list c: firehol-services-c — FireHOL service list c
services list d: firehol-services-d — FireHOL service list d
services list e: firehol-services-e — FireHOL service list e
services list f: firehol-services-f — FireHOL service list f
services list g: firehol-services-g — FireHOL service list g
services list h: firehol-services-h — FireHOL service list h
services list i: firehol-services-i — FireHOL service list i
services list j: firehol-services-j — FireHOL service list j
services list k: firehol-services-k — FireHOL service list k
services list l: firehol-services-l — FireHOL service list l
services list m: firehol-services-m — FireHOL service list m
services list n: firehol-services-n — FireHOL service list n
services list o: firehol-services-o — FireHOL service list o
services list p: firehol-services-p — FireHOL service list p
services list q: firehol-services-q — FireHOL service list q
services list r: firehol-services-r — FireHOL service list r
services list s: firehol-services-s — FireHOL service list s
services list t: firehol-services-t — FireHOL service list t
services list u: firehol-services-u — FireHOL service list u
services list v: firehol-services-v — FireHOL service list v
services list w: firehol-services-w — FireHOL service list w
services list x: firehol-services-x — FireHOL service list x
services list y: firehol-services-y — FireHOL service list y
services list z: firehol-services-z — FireHOL service list z
IV. FireQOS Reference
VIII. Running and Configuring
FireQOS program: fireqos — an easy to use but powerful traffic shaping tool
FireQOS configuration: fireqos.conf — FireQOS configuration file
IX. Organising Traffic
interface definition: fireqos-interface — create an interface definition
traffic class: fireqos-class — define a traffic class
traffic match: fireqos-match — define a traffic match
X. Optional Parameters
class/match parameters: fireqos-shared-params — class/match parameters
optional class parameters: fireqos-class-params — optional class parameters
optional match parameters: fireqos-match-params — optional match parameters
V. Appendices
A. ICMPv6 Firewall Recommendations
Introduction
Allow outbound echo requests from prefixes which belong to the site
Allow inbound echo requests towards only predetermined hosts
Allow incoming and outgoing echo reply messages only for existing sessions
Deny icmps to/from link local addresses
Drop echo replies which have a multicast address as a destination
Allow incoming destination unreachable messages only for existing sessions
Allow outgoing destination unreachable messages
Allow incoming Packet Too Big messages only for existing sessions
Allow outgoing Packet Too Big messages
Allow incoming time exceeded code 0 messages only for existing sessions
Allow incoming time exceeded code 1 messages
Allow outgoing time exceeded code 0 messages
Allow outgoing time exceeded code 1 messages
Allow incoming parameter problem code 1 and 2 messages for an existing session
Allow outgoing parameter problem code 1 and code 2 messages
Allow incoming and outgoing parameter problem code 0 messages
Drop NS/NA messages both incoming and outgoing
Drop RS/RA messages both incoming and outgoing
Drop Redirect messages both incoming and outgoing
Drop incoming and outgoing Multicast Listener queries (MLDv1 and MLDv2)
Drop incoming and outgoing Multicast Listener reports (MLDv1)
Drop incoming and outgoing Multicast Listener Done messages (MLDv1)
Drop incoming and outgoing Multicast Listener reports (MLDv2)
Drop router renumbering messages
Drop node information queries (139) and replies (140)
If there are mobile ipv6 home agents present on the trusted side allow
If there are roaming mobile nodes present on the trusted side allow
Drop everything else

List of Tables

1. iptables/klogd levels

Chapter 1. Introduction

Latest version

The latest version of this document will always be available here. There are PDF and HTML versions.

Who should read this manual

This manual is aimed at those who wish to create and maintain firewalls with FireHOL or perform traffic shaping with FireQOS.

For more information and tutorials, see the FireHOL website.

Where to get help

The FireHOL website.

The mailing lists and archives.

The package comes with a complete set of manpages, a README and a brief INSTALL guide.

Manual Organisation

FireHOL, the package, consists of two principal programs. The manual is split into four parts. For firewalling read about FireHOL in Part I, “FireHOL” with reference material in Part III, “FireHOL Reference” For traffic shaping/QOS read about FireQOS in Part II, “FireQOS” with reference material in Part IV, “FireQOS Reference”.

Installation

You can download tar-file releases by visiting the FireHOL website download area.

Unpack and change directory with:

tar xfz firehol-version.tar.gz
cd firehol-version
      

Options for the configure program can be seen in the INSTALL file and by running:

./configure --help
      

To build and install taking the default options:

./configure && make && sudo make install
      

Alternatively, just copy the sbin/firehol.in and sbin/fireqos.in files to where you want them. All of the common SysVInit command line arguments are recognised which makes it easy to deploy the scripts as startup services.

Packages are available for most distributions and you can use your distribution's standard commands (e.g. aptitude, yum, etc.) to install these.

Note

Distributions do not always offer the latest version. You can see what the latest release is on the FireHOL website.

Licence

This manual is licensed under the same terms as the FireHOL package, the GNU GPL v2 or later.

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

Part I. FireHOL

Chapter 2. Configuration

Getting started

Please see the online tutorials for help getting started.

Language

Use of bash

FireHOL configuration files are normal BASH scripts. As such, you can use all BASH features within FireHOL configuration files, including functions, loops, variables, I/O, etc.

BASH is used as the base configuration language for FireHOL since it is the common denominator for a language that all UNIX system administrators and developers should know and understand.

The fact that FireHOL uses BASH for its configuration, allows development of add-ons and enables FireHOL to use programs to access SQL databases, directory structures, DBM or other files, web front ends or other means for the rules of the firewall.

Exactly the same reason allows the build of remote managers for centralised administration of a large number of Linux hosts and routers.

What to avoid

The only BASH commands a FireHOL configuration script should never use are trap and exit.

Traps are used by FireHOL for cleaning up all temporary files, and possibly restoring the previously running firewall in case FireHOL execution breaks, and the exit command will not just exit the configuration file, it will exit FireHOL. FireHOL has disabled these features by default, so that you will not be able to use them, unless you specifically enable them.

Since a FireHOL configuration script runs inline with FireHOL, all variables and function names defined within the configuration file overwrite the ones defined by FireHOL so you should avoid some names.

Avoid using variables that start with FIREHOL_, work_, server_, and client_ as many such variables are used by FireHOL internally.

There are also a number of functions names you should avoid, but there is no generic pattern at the moment. I suggest you should avoid defining functions with the names of FireHOL commands (interface, router, client, server, etc) and functions starting with rules_.

Note

You may wish to overwrite a few variables and functions if you want to modify FireHOL services. See the section called “Adding Services” for details.

Chapter 3. Security

This chapter discusses some of the security considerations of firewalls in general and using FireHOL in particular.

Important Security Note

It should be observed that FireHOL can be no more secure than your use of it. You should audit the output results at least once to ensure you are happy with the rules produced. The rules that get output are extremely regular and should make the task fairly straightforward.

In particular it is your responsibility to ensure the final firewall produced behaves as you expect. If in doubt we recommend that you seek help from a firewall/networking professional.

Please consider signing up to the mailing lists to ensure you are kept informed in the event that a security problem is discovered.

What happens when FireHOL Runs?

FireHOL is a BASH script. To run its configuration file, FireHOL first defines a set of functions and variables and then it "sources" (runs inline) its configuration file to be executed by BASH.

The keywords interface, client, server, router, etc. are all BASH functions that are executed by BASH when and if they appear in the configuration file. Using shared variables these functions share some state information that allows them to know, for example, that a client command appears within an interface and not within a router and that the name given to an interface that has not been used before.

Instead of running iptables commands directly, each of these functions (i.e. FireHOL) just writes the generated iptables commands to a temporary file. This is done to prevent altering a running firewall before ensuring that the syntax of the configuration file is correct. So, a complete run of the configuration file actually produces all the iptables commands for the firewall, written to a temporary file (script). Even the iptables commands given within the configuration file use the same concept (they just generate iptables commands in this script).

Finally, this script (the generated iptables commands) has to be run, but before doing so, FireHOL saves the running firewall to another temporary file. The saved firewall will be automatically restored if some of the generated iptables commands produces an error. Such an error is possible when for example, you specify an invalid IP address or hostname, or an invalid argument to some parameter that gets passed to iptables as-is.

It is important to understand that during the run of the generated iptables script (including the possible restoration of the old firewall), FireHOL allows all traffic to reach its destination. This has been done to prevent a possible lock-out situation where you are SSHing to the server to alter its firewall, and suddenly you loose the connection (although this can still happen if your new firewall doesn't allow the connection). To control this behaviour, set the ACTIVATION variables (see control variables: firehol-variables(5)).

If no error has been seen, FireHOL deletes all temporary files generated and exits.

In case there was an error, FireHOL will make the most to restore your previous firewall and will present you details about the error and its line number in the original configuration file.

Where to learn more

The FireHOL website contains more information and there are a number of iptables tutorials online.

Chapter 4. Troubleshooting

Table of Contents

Reading log output

The main tool you have for troubleshooting a running firewall is the system log, typically /var/log/syslog, /var/log/messages or similar.

Reading log output

The system log will log any packets dropped implicitly by FireHOL. This means any packets which do not match any rules in the configuration file.

FireHOL always logs packets not matched by any rule, although it does not log every single packet, in order to protect you from an attack that could use all of your free hard disk space. The rate is controlled in the same way as loglimit.

In the system log you will find entries that look like:

Dec 21 20:01:07 gateway kernel: IN-internet:IN=ppp0 OUT= MAC= \
  SRC=200.75.88.187 DST=195.97.5.193 LEN=78 TOS=0x00 PREC=0x00 \
  TTL=111 ID=63816 PROTO=UDP SPT=34165 DPT=137 LEN=58 

Dec 21 22:25:39 gateway kernel: OUT-unknown:IN= OUT=ppp0 \
  SRC=195.97.5.193 DST=192.168.23.1 LEN=48 TOS=0x00 PREC=0x00 \
  TTL=64 ID=0 DF PROTO=TCP SPT=139 DPT=1255 WINDOW=2128 \
  RES=0x00 ACK SYN URGP=0 
  
Dec 21 20:01:07 gateway kernel: PASS-unknown:IN=ppp0 OUT=eth0 \
  SRC=200.75.88.187 DST=195.97.5.194 LEN=78 TOS=0x00 PREC=0x00 \
  TTL=110 ID=64840 PROTO=UDP SPT=34132 DPT=137 LEN=58 
      

Each of such lines represent one packet that did not satisfy the requirements of the configuration file rules.

FireHOL provides a reason text which indicates where a packet was dropped:

IN-name

IN-name refers to packets that were dropped at the end of the interface definition called name's input (see interface definition: firehol-interface(5)). These packets tried to come into this host (it is not routed traffic). There is also the special name unknown that matches packets which tried to come into this host but did not match any of the interfaces given in FireHOL's configuration file.

OUT-name

OUT-name refers to packets that were dropped at the end of the interface definition called name's output (see interface definition: firehol-interface(5)). These are packets the host tried to send (it is not routed traffic). There is also the special name unknown that matches packets which tried to come into this host but did not match any of the interfaces given in FireHOL's configuration file.

PASS-unknown

PASS-unknown refers to packets that that were dropped at the end of all router definitions (see router definition: firehol-router(5)). This matches forwarded traffic. There is no name here, since all FireHOL routers have only one policy RETURN. All packets are processed against all routers and then get dropped at the end of the firewall.

Further information about the dropped packet is logged:

IN=

The real network interface name the packet came in from. It can be empty when the packet was generated locally.

OUT=

The real network interface name the packet tried to use to go out of this host. It can be empty when the packet was received by the firewall host.

SRC=

The IP address of the packet's sender.

DST=

The IP address of the packet's destination.

PROTO=

The protocol this packet is using (TCP, UDP, ICMP, etc).

SPT=

The source port number of this packet.

DPT=

The destination port number of this packet.

Generally, you should monitor the system log for such entries and decide if each entry was something useful or not. If it was something useful, you should have added another service somewhere in your FireHOL configuration to match that packet and allow it to reach its destination. If it was not something useful, then FireHOL did the right job and dropped it.

Keep in mind that there are certain cases where packets get dropped even though FireHOL has specific rules that should allow them to pass. Such cases are not always errors, and here is why:

The iptables connection tracker has a mechanism for matching request packets and reply packets. When an allowed request comes in, the connection tracker keeps it in a list and then waits for a matching reply to come in the opposite direction. This list of active connections is available for you to see at /proc/net/ip_conntrack. Simply cat this file to see all the current connections your system has.

The connection tracker will wait for a reply a certain amount of time. This time is, for example, about 20 seconds for UDP traffic. After that time the connection tracker will remove the request from its list. A reply that is send after the connection tracker has removed the request from its list, will be dropped and therefore logged in the system log.

This situation may, for example, produce a few log entries in your DNS server for cases where the DNS server could not respond within the time limits set by iptables, but this is not a problem because the DNS client had already timed out in 2 or 3 seconds.

Note however that the above are common when the connection tracker is trying to keep a state on a stateless protocol (such as UDP or ICMP). Stateful protocols, such as TCP, always respond immediately to acknowledge the connection and therefore the time needed by the application server to respond does not make the connection tracker to remove the request from its list.

Part II. FireQOS

Table of Contents

5. Configuration

Chapter 5. Configuration

TODO

Part III. FireHOL Reference

Table of Contents

I. Running and Configuring
FireHOL program: firehol — an easy to use but powerful iptables stateful firewall
FireHOL configuration: firehol.conf — FireHOL configuration file
control variables: firehol-variables — Variables controlling FireHOL
ipv4/ipv6 selection: firehol-modifiers — select IPv4 or IPv6 mode
II. Definition Commands
interface definition: firehol-interface — create an interface definition
router definition: firehol-router — create a router definition
III. Rule Subcommands
policy command: firehol-policy — set default action for a definition
protection command: firehol-protection — add extra protections to a definition
server, route commands: firehol-server — accept requests to a service
client command: firehol-client — accept replies from a service
group command: firehol-group — group commands with common options
IV. Optional Parameters and Actions
optional rule parameters: firehol-rule-params — optional rule parameters
actions for rules: firehol-actions — rule actions
V. Helper Commands
iptables helper: firehol-iptables — include custom iptables commands
masquerade helper: firehol-masquerade — set up masquerading (NAT) on an interface
tcpmss helper: firehol-tcpmss — set the MSS of TCP SYN packets for routers
VI. Configuration Helper Commands
version config helper: firehol-version — set version number of configuration file
action config helper: firehol-action — set up custom filter actions
blacklist config helper: firehol-blacklist — set up a unidirectional or bidirectional blacklist
classify config helper: firehol-classify — classify traffic for traffic shaping tools
connmark config helper: firehol-connmark — set a stateful mark on a connection
dscp config helper: firehol-dscp — set the DSCP field in the packet header
mac config helper: firehol-mac — ensure source IP and source MAC address match
mark config helper: firehol-mark — mark traffic for traffic shaping tools
nat, snat, dnat, redirect config helpers: firehol-nat — set up NAT and port redirections
transparent_proxy, transparent_squid helpers: firehol-transparent_proxy — set up a transparent proxy
tos config helper: firehol-tos — set the Type of Service (TOS) of packets
tosfix config helper: firehol-tosfix — apply suggested TOS values to packets
VII. Services Reference
services list: firehol-services — FireHOL service list
services list a: firehol-services-a — FireHOL service list a
services list b: firehol-services-b — FireHOL service list b
services list c: firehol-services-c — FireHOL service list c
services list d: firehol-services-d — FireHOL service list d
services list e: firehol-services-e — FireHOL service list e
services list f: firehol-services-f — FireHOL service list f
services list g: firehol-services-g — FireHOL service list g
services list h: firehol-services-h — FireHOL service list h
services list i: firehol-services-i — FireHOL service list i
services list j: firehol-services-j — FireHOL service list j
services list k: firehol-services-k — FireHOL service list k
services list l: firehol-services-l — FireHOL service list l
services list m: firehol-services-m — FireHOL service list m
services list n: firehol-services-n — FireHOL service list n
services list o: firehol-services-o — FireHOL service list o
services list p: firehol-services-p — FireHOL service list p
services list q: firehol-services-q — FireHOL service list q
services list r: firehol-services-r — FireHOL service list r
services list s: firehol-services-s — FireHOL service list s
services list t: firehol-services-t — FireHOL service list t
services list u: firehol-services-u — FireHOL service list u
services list v: firehol-services-v — FireHOL service list v
services list w: firehol-services-w — FireHOL service list w
services list x: firehol-services-x — FireHOL service list x
services list y: firehol-services-y — FireHOL service list y
services list z: firehol-services-z — FireHOL service list z

Running and Configuring


Table of Contents

FireHOL program: firehol — an easy to use but powerful iptables stateful firewall
FireHOL configuration: firehol.conf — FireHOL configuration file
control variables: firehol-variables — Variables controlling FireHOL
ipv4/ipv6 selection: firehol-modifiers — select IPv4 or IPv6 mode

Name

firehol — an easy to use but powerful iptables stateful firewall

Synopsis

firehol

sudo -E firehol panic [ IP ]

firehol command [ -- conf-arg... ]

firehol CONFIGFILE [ start | debug | try ] [ -- conf-arg... ]

Description

Running firehol invokes iptables(8) to manipulate your firewall.

Run without any arguments, firehol will present some help on usage.

When given CONFIGFILE, firehol will use the named file instead of /etc/firehol/firehol.conf as its configuration. If no command is given, firehol assumes try.

It is possible to pass arguments for use by the configuration file separating any conf-arg values from the rest of the arguments with --. The arguments are accessible in the configuration using standard bash(1) syntax e.g. $1, $2, etc.

Panic

To block all communication, invoke firehol with the panic command.

FireHOL removes all rules from the running firewall and then DROPs all traffic on all iptables tables (mangle, nat, filter) and pre-defined chains (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING).

DROPing is not done by changing the default policy to DROP, but by adding one rule per table/chain to drop all traffic. This allows systems which do not reset all the chains to ACCEPT when starting to function correctly.

When activating panic mode, FireHOL checks for the existence of the SSH_CLIENT shell environment variable, which is set by ssh. If it finds this, then panic mode will allow the established SSH connection specified in this variable to operate.

Note

In order for FireHOL to see the environment variable you must ensure that it is preserved. For sudo use the -E and for su omit the - (minus sign).

If SSH_CLIENT is not set, the IP after the panic argument allows you to give an IP address for which all established connections between the IP address and the host in panic will be allowed to continue.

Commands

start, restart

Activates the firewall configuration from /etc/firehol/firehol.conf.

Use of the term restart is allowed for compatibility with common init implementations.

try

Activates the firewall, waiting for the user to type the word commit. If this word is not typed within 30 seconds, the previous firewall is restored.

stop

Stops a running iptables firewall by clearing all of the tables and chains and setting the default policies to ACCEPT. This will allow all traffic to pass unchecked.

condrestart

Restarts the FireHOL firewall only if it is already active. This is the generally expected behaviour (but opposite to FireHOL prior to 2.0.0-pre4).

status

Shows the running firewall, using /sbin/iptables -nxvL | less.

save

Start the firewall and then save it using /sbin/iptables-save to /etc/sysconfig/iptables.

The required kernel modules are saved to an executable shell script /var/spool/firehol/last_save_modules.sh, which can be called during boot if a firewall is to be restored.

Note

External changes may cause a firewall restored after a reboot to not work as intended where starting the firewall with FireHOL will work.

This is because as part of starting a firewall, FireHOL checks some changeable values. For instance the current kernel configuration is checked (for client port ranges), and RPC servers are queried (to allow correct functioning of the NFS service).

debug

Parses the configuration file but instead of activating it, FireHOL shows the generated iptables statements.

explain

Enters an interactive mode where FireHOL accepts normal configuration commands and presents the generated iptables commands for each of them, together with some reasoning for its purpose.

Additionally, FireHOL automatically generates a configuration script based on the successful commands given.

Some extra commands are available in explain mode.

Special commands in explain mode

help

Present some help

show

Present the generated configuration

quit

Exit interactive mode and quit

helpme, wizard

Tries to guess the FireHOL configuration needed for the current machine.

FireHOL will not stop or alter the running firewall. The configuration file is given in the standard output of firehol, thus firehol helpme > /tmp/firehol.conf will produce the output in /tmp/firehol.conf.

The generated FireHOL configuration must be edited before use on your systems. You are required to take a number of decisions; the comments in the generated file will instruct you in the choices you must make.

Files

/etc/firehol/firehol.conf

Name

firehol.conf — FireHOL configuration file

Description

/etc/firehol/firehol.conf is the default configuration file for FireHOL program: firehol(1). It defines the stateful firewall that will be produced.

A configuration file starts with an optional version indicator which looks like this:

version 5

See version config helper: firehol-version(5) for full details.

A configuration file contains one or more interface definitions, which look like this:

interface eth0 lan
  client all accept # This host can access any remote service
  server ssh accept # Remote hosts can access SSH on local server
  # ...
    

The above definition has name "lan" and specifies a network interface (eth0). A definition may contain zero or more subcommands. See interface definition: firehol-interface(5) for full details.

By default FireHOL will try to create both IPv4 and IPv6 rules for each interface. To make this explicit or restrict which rules are created write both interface, ipv4 interface or ipv6 interface.

A configuration file contains zero or more router definitions, which look like this:

DMZ_IF=eth0
WAN_IF=eth1
router wan2dmz inface ${WAN_IF} outface ${DMZ_IF}
  route http accept  # Hosts on WAN may access HTTP on hosts in DMZ
  server ssh accept  # Hosts on WAN may access SSH on hosts in DMZ
  client pop3 accept # Hosts in DMZ may access POP3 on hosts on WAN
  # ...
    

The above definition has name "wan2dmz" and specifies incoming and outgoing network interfaces (eth1 and eth0) using variables. A definition may contain zero or more subcommands. Note that a router is not required to specify network interfaces to operate on. See router definition: firehol-router(5) for full details.

By default FireHOL will try to create both IPv4 and IPv6 rules for each router. To make this explicit or restrict which rules are created write both router, ipv4 router or ipv6 router.

It is simple to add extra service definitions which can then be used in the same way as those provided as standard. See the section called “Adding Services”.

The configuration file is parsed as a bash(1) script, allowing you to set up and use variables, flow control and external commands.

Special control variables: firehol-variables(5) may be set up and used outside of any definition as can the functions in the section called “Configuration Helper Commands” and the section called “Helper Commands”.

Variables Available

The following variables are made available in the FireHOL configuration file and can be accessed as ${VARIABLE}.

UNROUTABLE_IPS

This variable includes the IPs from both PRIVATE_IPS and RESERVED_IPS. It is useful to restrict traffic on interfaces and routers accepting Internet traffic, for example:

interface eth0 internet src not "${UNROUTABLE_IPS}"
          

PRIVATE_IPS

This variable includes all the IP addresses defined as Private or Test by RFC 3330.

You can override the default values by creating a file called /etc/firehol/PRIVATE_IPS.

RESERVED_IPS

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

You can override the default values by creating a file called /etc/firehol/RESERVED_IPS.

Now that IPv4 address space has all been allocated there is very little reason that this value will need to change in future.

MULTICAST_IPS

This variable includes all the IP addresses defined as Multicast by RFC 3330.

You can override the default values by creating a file called /etc/firehol/MULTICAST_IPS.

Adding Services

To define new services you add the appropriate lines before using them later in the configuration file.

The following are required:

server_myservice_ports="proto/sports"
client_myservice_ports="cports"
    

proto is anything iptables(8) accepts e.g. "tcp", "udp", "icmp", including numeric protocol values.

sports is the ports the server is listening at. It is a space-separated list of port numbers, names and ranges (from:to). The keyword any will match any server port.

cports is the ports the client may use to initiate a connection. It is a space-separated list of port numbers, names and ranges (from:to). The keyword any will match any client port. The keyword default will match default client ports. For the local machine (e.g. a client within an interface) it resolves to sysctl variable net.ipv4.ip_local_port_range (or /proc/sys/net/ipv4/ip_local_port_range). For a remote machine (e.g. a client within an interface or anything in a router) it resolves to the variable DEFAULT_CLIENT_PORTS (see control variables: firehol-variables(5)).

The following are optional:

require_myservice_modules="modules"
require_myservice_nat_modules="nat-modules"
    

The named kernel modules will be loaded when the definition is used. The NAT modules will only be loaded if FIREHOL_NAT is non-zero (see control variables: firehol-variables(5)).

For example, for a service named daftnet that listens at two ports, port 1234 TCP and 1234 UDP where the expected client ports are the default random ports a system may choose, plus the same port numbers the server listens at, with further dynamic ports requiring kernel modules to be loaded:

version 5
	
server_daftnet_ports="tcp/1234 udp/1234"
client_daftnet_ports="default 1234"
require_daftnet_modules="ip_conntrack_daftnet"
require_daftnet_nat_modules="ip_nat_daftnet"

interface eth0 lan0
    server daftnet accept
	
interface eth1 lan1
    client daftnet reject
	
router lan2lan inface eth0 outface eth1
    route daftnet accept
    

Where multiple ports are provides (as per the example), FireHOL simply determines all of the combinations of client and server ports and generates multiple iptables statements to match them.

To create more complex rules, or stateless rules, you will need to create a bash function prefixed rules_ e.g. rules_myservice. The best reference is the many such functions in the main firehol executable.

When adding a service which uses modules, or via a custom function, you may also wish to include the following:

ALL_SHOULD_ALSO_RUN="${ALL_SHOULD_ALSO_RUN} myservice"
    

which will ensure your service is set-up correctly as part of the all service.

Note

To allow definitions to be shared you can instead create files and install them in the /etc/firehol/services directory with a .conf extension.

The first line must read:

FHVER 1:213

1 is the service definition API version. It will be changed if the API is ever modified. The 213 originally referred to a FireHOL 1.x minor version but is no longer checked.

FireHOL will refuse to run if the API version does not match the expected one.

Helper Commands

These helpers can be used in interface and router definitions as well as before them.

iptables helper: firehol-iptables(5)
masquerade helper: firehol-masquerade(5)

This helper can be used in router definitions as well as before any router or interface.

tcpmss helper: firehol-tcpmss(5)

Name

firehol-variables — Variables controlling FireHOL

Description

There are a number of variables that control the behaviour of FireHOL.

All variables may be set in the main FireHOL configuration file /etc/firehol/firehol.conf.

Variables which affect the runtime but not the created firewall may also be set as environment variables before running firehol. These can change the default values but will be overwritten by values set in the configuration file. If a variable can be set by an environment variable it is specified below.

FireHOL also sets some variables before processing the configuration file which you can use as part of your configuration. These are described in FireHOL configuration: firehol.conf(5).

Variables

DEFAULT_INTERFACE_POLICY

This variable controls the default action to be taken on traffic not matched by any rule within an interface. It can be overridden using policy command: firehol-policy(5).

Packets that reach the end of an interface without an action of return or accept are logged. You can control the frequency of this logging by altering FIREHOL_LOG_FREQUENCY.

Default:

DEFAULT_INTERFACE_POLICY="DROP"
          

Example:

DEFAULT_INTERFACE_POLICY="REJECT"
          

DEFAULT_ROUTER_POLICY

This variable controls the default action to be taken on traffic not matched by any rule within a router. It can be overridden using policy command: firehol-policy(5).

Packets that reach the end of a router without an action of return or accept are logged. You can control the frequency of this logging by altering FIREHOL_LOG_FREQUENCY.

Default:

DEFAULT_ROUTER_POLICY="RETURN"
          

Example:

DEFAULT_ROUTER_POLICY="REJECT"
          

UNMATCHED_INPUT_POLICY, UNMATCHED_OUTPUT_POLICY, UNMATCHED_FORWARD_POLICY

These variables control the default action to be taken on traffic not matched by any interface or router definition that was incoming, outgoing or for forwarding respectively. Any supported value from actions for rules: firehol-actions(5) may be set.

All packets that reach the end of a chain are logged, regardless of these settings. You can control the frequency of this logging by altering FIREHOL_LOG_FREQUENCY.

Defaults:

UNMATCHED_INPUT_POLICY="DROP"
UNMATCHED_OUTPUT_POLICY="DROP"
UNMATCHED_FORWARD_POLICY="DROP"
          

Example:

UNMATCHED_INPUT_POLICY="REJECT"
UNMATCHED_OUTPUT_POLICY="REJECT"
UNMATCHED_FORWARD_POLICY="REJECT"
          

FIREHOL_INPUT_ACTIVATION_POLICY, FIREHOL_OUTPUT_ACTIVATION_POLICY, FIREHOL_FORWARD_ACTIVATION_POLICY

These variables control the default action to be taken on traffic during firewall activation for incoming, outgoing and forwarding respectively. Acceptable values are ACCEPT, DROP and REJECT. They may be set as environment variables.

FireHOL defaults all values to ACCEPT so that your communications continue to work uninterrupted.

If you wish to prevent connections whilst the new firewall is activating, set these values to DROP. This is important to do if you are using all or any to match traffic; connections established during activation will continue even if they would not be allowed once the firewall is established.

Defaults:

UNMATCHED_INPUT_POLICY="ACCEPT"
UNMATCHED_OUTPUT_POLICY="ACCEPT"
UNMATCHED_FORWARD_POLICY="ACCEPT"
          

Example:

FIREHOL_INPUT_ACTIVATION_POLICY="DROP"
FIREHOL_OUTPUT_ACTIVATION_POLICY="DROP"
FIREHOL_FORWARD_ACTIVATION_POLICY="DROP"
          

FIREHOL_LOG_MODE

This variable controls method that FireHOL uses for logging.

Acceptable values are LOG (normal syslog) and ULOG (netfilter ulogd). When ULOG is selected, FIREHOL_LOG_LEVEL is ignored.

Default:

FIREHOL_LOG_MODE="LOG"
          

Example:

FIREHOL_LOG_MODE="ULOG"
          

To see the available options run: /sbin/iptables -j LOG --help or /sbin/iptables -j ULOG --help

FIREHOL_LOG_LEVEL

This variable controls the level at which events will be logged to syslog.

To avoid packet logs appearing on your console you should ensure klogd only logs traffic that is more important than that produced by FireHOL.

Use the following option to choose an iptables log level (alpha or numeric) which is higher than the -c of klogd.

Table 1. iptables/klogd levels

iptablesklogddescription
emerg (0)0

system is unusable

alert (1)1

action must be taken immediately

crit (2)2

critical conditions

error (3)3

error conditions

warning (4)4

warning conditions

notice (5)5

normal but significant condition

info (6)6

informational

debug (7)7

debug-level messages


Note

The default for klogd is generally to log everything (7 and lower) and the default level for iptables is to log as warnings (4).

FIREHOL_LOG_OPTIONS

This variable controls the way in which events will be logged to syslog.

Default:

FIREHOL_LOG_OPTIONS="--log-level warning"
          

Example:

FIREHOL_LOG_OPTIONS="--log-level info \
   --log-tcp-options --log-ip-options"
          

To see the available options run: /sbin/iptables -j LOG --help

FIREHOL_LOG_FREQUENCY, FIREHOL_LOG_BURST

These variables control the frequency that each logging rule will write events to syslog. FIREHOL_LOG_FREQUENCY is set to the maximum average frequency and FIREHOL_LOG_BURST specifies the maximum initial number.

Default:

FIREHOL_LOG_FREQUENCY="1/second"
FIREHOL_LOG_BURST="5"
          

Example:

FIREHOL_LOG_FREQUENCY="30/minute"
FIREHOL_LOG_BURST="2"
          

To see the available options run: /sbin/iptables -m limit --help

FIREHOL_LOG_PREFIX

This value is added to the contents of each logged line for easy detection of FireHOL lines in the system logs. By default it is empty.

Default:

FIREHOL_LOG_PREFIX=""
          

Example:

FIREHOL_LOG_PREFIX="FIREHOL:"
          

FIREHOL_DROP_INVALID

If set to 1, this variable causes FireHOL to drop all packets matched as INVALID in the iptables(8) connection tracker.

Note

You can use protection command: firehol-protection(5) to control matching of INVALID packets and others on per-interface and per-router basis.

Default:

FIREHOL_DROP_INVALID="0"
          

Example:

FIREHOL_DROP_INVALID="1"
          

DEFAULT_CLIENT_PORTS

This variable controls the port range that is used when a remote client is specified. For clients on the local host, FireHOL finds the exact client ports by querying the kernel options.

Default:

DEFAULT_CLIENT_PORTS="1000:65535"
          

Example:

DEFAULT_CLIENT_PORTS="0:65535"
          

FIREHOL_NAT

If set to 1, this variable causes FireHOL to load the NAT kernel modules. If you make use of the NAT helper commands, the variable will be set to 1 automatically. It may be set as an environment variable.

Default:

FIREHOL_NAT="0"
          

Example:

FIREHOL_NAT="1"
          

FIREHOL_ROUTING

If set to 1, this variable causes FireHOL to enable routing in the kernel. If you make use of router definitions or certain helper commands the variable will be set to 1 automatically. It may be set as an environment variable.

Default:

FIREHOL_ROUTING="0"
          

Example:

FIREHOL_ROUTING="1"
          

FIREHOL_AUTOSAVE

This variable specifies the file of (IPv4) rules that will be created when FireHOL program: firehol(1) is called with the save argument. It may be set as an environment variable.

If the variable is not set, a system-specific value is used which was defined at configure-time. If no value was chosen then the save fails.

Default:

FIREHOL_AUTOSAVE=""
          

Example:

FIREHOL_AUTOSAVE="/tmp/firehol-saved-ipv4.txt"
          

FIREHOL_LOAD_KERNEL_MODULES

If set to 0, this variable forces FireHOL to not load any kernel modules. It is needed only if the kernel has modules statically included and in the rare event that FireHOL cannot access the kernel configuration. It may be set as an environment variable.

Default:

FIREHOL_LOAD_KERNEL_MODULES="1"
          

Example:

FIREHOL_LOAD_KERNEL_MODULES="0"
          

FIREHOL_TRUST_LOOPBACK

If set to 0, the loopback device "lo" will not be trusted and you can write standard firewall rules for it.

Warning

If you do not set up appropriate rules, local processes will not be able to communicate with each other which can result in serious breakages.

By default "lo" is trusted and all INPUT and OUTPUT traffic is accepted (forwarding is not included).

Default:

FIREHOL_TRUST_LOOPBACK="1"
          

Example:

FIREHOL_TRUST_LOOPBACK="0"
          

FIREHOL_DROP_ORPHAN_TCP_ACK_FIN

If set to 1, FireHOL will drop all TCP connections with ACK FIN set without logging them.

In busy environments the iptables connection tracker removes connection tracking list entries as soon as it receives a FIN. This makes the ACK FIN appear as an invalid packet which will normally be logged by FireHOL.

Default:

FIREHOL_DROP_ORPHAN_TCP_ACK_FIN="0"
          

Example:

FIREHOL_DROP_ORPHAN_TCP_ACK_FIN="1"
          

FIREHOL_DEBUGGING

If set to a non-empty value, switches on debug output so that it is possible to see what processing FireHOL is doing.

Note

This variable can only be set as an environment variable, since it is processed before any configuration files are read.

Default:

FIREHOL_DEBUGGING=""
          

Example:

FIREHOL_DEBUGGING="Y"
          

WAIT_FOR_IFACE

If set to the name of a network device (e.g. eth0), FireHOL will wait until the device is up (or until 60 seconds have elapsed) before continuing.

Note

This variable can only be set as an environment variable, since it determines when the main configuration file will be processed.

A device does not need to be up in order to have firewall rules created for it, so this option should only be used if you have a specific need to wait (e.g. the network must be queried to determine the hosts or ports which will be firewalled).

Default:

WAIT_FOR_IFACE=""
          

Example:

WAIT_FOR_IFACE="eth0"
          


Name

firehol-modifiers — select IPv4 or IPv6 mode

Synopsis

ipv4 definition-or-command

ipv6 definition-or-command

Description

Without a modifier, interface and router definitions and commands that come before either will be applied to both IPv4 and IPV6. Commands within an interface or router assume the same behaviour as the enclosing definition.

When preceded by a modifier, the command or definition can be made to apply to IPv4 or IPv6 only. Note that you cannot create an IPv4 only command within and IPv6 interface or vice-versa.

Examples:

interface eth0 ifboth src4 192.0.2.0/24 src6 2001:DB8::/24
  ipv4 server http accept
  ipv6 server http accept

ipv4 interface eth0 if4only src 192.0.2.0/24
  server http accept

ipv6 interface eth0 if6only src 2001:DB8::/24
  server http accept

Many definitions and commands have explicitly named variants (such as router4, router6, router46) which can be used as shorthand.

Definition Commands


Table of Contents

interface definition: firehol-interface — create an interface definition
router definition: firehol-router — create a router definition

Name

firehol-interface — create an interface definition

Synopsis

interface|interface46 real-interface name [rule-params]

interface4 real-interface name [rule-params]

interface6 real-interface name [rule-params]

Description

An interface definition creates a firewall for protecting the host on which the firewall is running.

The default policy is DROP, so that if no subcommands are given, the firewall will just drop all incoming and outgoing traffic using this interface.

The behaviour of the defined interface is controlled by adding subcommands (listed in the section called “See Also”).

Note

Forwarded traffic is never matched by the interface rules, even if it was originally destined for the firewall but was redirected using NAT. Any traffic to be passed through the firewall for whatever reason must be in a router (see router definition: firehol-router(5)).

Note

Writing interface4 is equivalent to writing ipv4 interface and ensures the defined interface is created only in the IPv4 firewall along with any rules within it.

Writing interface6 is equivalent to writing ipv6 interface and ensures the defined interface is created only in the IPv6 firewall along with any rules within it.

Writing interface46 is equivalent to writing both interface and ensures the defined interface is created in both the IPv4 and IPv6 firewalls. Any rules within it will also be applied to both, unless they specify otherwise.

Parameters

real-interface

This is the interface name as shown by ip link show. Generally anything iptables accepts is valid.

The + (plus sign) after some text will match all interfaces that start with this text.

Multiple interfaces may be specified by enclosing them within quotes, delimited by spaces for example:

interface "eth0 eth1 ppp0" myname
          

name

This is a name for this interface. You should use short names (10 characters maximum) without spaces or other symbols.

A name should be unique for all FireHOL interface and router definitions.

rule-params

The set of rule parameters to further restrict the traffic that is matched to this interface.

See optional rule parameters: firehol-rule-params(5) for information on the parameters that can be used. Some examples:

interface eth0 intranet src 192.0.2.0/24

interface eth0 internet src not "${UNROUTABLE_IPS}"
          

See FireHOL configuration: firehol.conf(5) for an explanation of ${UNROUTABLE_IPS}.


Name

firehol-router — create a router definition

Synopsis

router|router46 name [rule-params]

router4 name [rule-params]

router6 name [rule-params]

Description

A router definition consists of a set of rules for traffic passing through the host running the firewall.

The default policy for router definitions is RETURN, meaning packets are not dropped by any particular router. Packets not matched by any router are dropped at the end of the firewall.

The behaviour of the defined router is controlled by adding subcommands (listed in the section called “See Also”).

Note

Writing router4 is equivalent to writing ipv4 router and ensures the defined router is created only in the IPv4 firewall along with any rules within it.

Writing router6 is equivalent to writing ipv6 router and ensures the defined router is created only in the IPv6 firewall along with any rules within it.

Writing router46 is equivalent to writing both router and ensures the defined router is created in both the IPv4 and IPv6 firewalls. Any rules within it will also be applied to both, unless they specify otherwise.

Parameters

name

This is a name for this router. You should use short names (10 characters maximum) without spaces or other symbols.

A name should be unique for all FireHOL interface and router definitions.

rule-params

The set of rule parameters to further restrict the traffic that is matched to this router.

See optional rule parameters: firehol-rule-params(5) for information on the parameters that can be used. Some examples:

router mylan inface ppp+ outface eth0 src not ${UNROUTABLE_IPS}

router myrouter
          

See FireHOL configuration: firehol.conf(5) for an explanation of ${UNROUTABLE_IPS}.

Working with routers

Routers create stateful iptables rules which match traffic in both directions.

To match some client or server traffic, the input/output interface or source/destination of the request must be specified. All inface/outface and src/dst optional rule parameters: firehol-rule-params(5) can be given on the router statement (in which case they will be applied to all subcommands for the router) or just within the subcommands of the router.

For example, to define a router which matches requests from any PPP interface and destined for eth0, and on this allowing HTTP servers (on eth0) to be accessed by clients (from PPP) and SMTP clients (from eth0) to access any servers (on PPP):

router mylan inface ppp+ outface eth0
  server http accept
  client smtp accept
    

Note

The client subcommand reverses any optional rule parameters passed to the router, in this case the inface and outface.

Equivalently, to define a router which matches all forwarded traffic and within the the router allow HTTP servers on eth0 to be accessible to PPP and any SMTP servers on PPP to be accessible from eth0:

router mylan
  server http accept inface ppp+ outface eth0
  server smtp accept inface eth0 outface ppp
    

Note

In this instance two server subcommands are used since there are no parameters on the router to reverse. Avoid the use of the client subcommand in routers unless the inputs and outputs are defined as part of the router.

Any number of routers can be defined and the traffic they match can overlap. Since the default policy is RETURN, any traffic that is not matched by any rules in one will proceed to the next, in order, until none are left.

Rule Subcommands


Table of Contents

policy command: firehol-policy — set default action for a definition
protection command: firehol-protection — add extra protections to a definition
server, route commands: firehol-server — accept requests to a service
client command: firehol-client — accept replies from a service
group command: firehol-group — group commands with common options

Name

firehol-policy — set default action for a definition

Synopsis

policy action

Description

The policy subcommand defines the default policy for an interface or router.

The action can be any of the actions listed in actions for rules: firehol-actions(5).

Note

Change the default policy of a router only if you understand clearly what will be matched by the router statement whose policy is being changed.

It is common to define overlapping router definitions. Changing the policy to anything other than the default return may cause strange results for your configuration.

Warning

Do not set a policy to accept unless you fully trust all hosts that can reach the interface. FireHOL CANNOT create valid "accept by default" firewalls.


Name

firehol-protection — add extra protections to a definition

Synopsis

protection [reverse] flood-protection-type [requests/period [burst] ]

protection [reverse] strong [requests/period [burst] ]

protection [reverse] { bad-packets | packet-protection-type }

Description

The protection subcommand sets protection rules on an interface or router.

Flood protections honour the options requests/period and burst. They are used to limit the rate of certain types of traffic.

The default rate FireHOL uses is 100 operations per second with a burst of 50. Run iptables -m limit --help for more information.

The protection type strong will switch on all protections (both packet and flood protections) except all-floods. It has aliases full and all.

The protection type bad-packets will switch on all packet protections but not flood protections.

You can specify multiple protection types by using multiple protection commands or in a single command by enclosing the types in quotes.

Note

On a router, protections are normally set up on inface.

The reverse option will set up the protections on outface. You must use it as the first keyword.

Packet protection types

invalid

Drops all incoming invalid packets, as detected INVALID by the connection tracker.

See also FIREHOL_DROP_INVALID in control variables: firehol-variables(5) which allows setting this function globally.

fragments

Drops all packet fragments.

This rule will probably never match anything since iptables(8) reconstructs all packets automatically before the firewall rules are processed whenever connection tracking is running.

new-tcp-w/o-syn

Drops all TCP packets that initiate a socket but have not got the SYN flag set.

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.

Flood protection types

icmp-floods [requests/period [burst]]

Allows only a certain amount of ICMP echo requests.

syn-floods [requests/period [burst]]

Allows only a certain amount of new TCP connections.

Be careful to not set the rate too low as the rule is applied to all connections regardless of their final result (rejected, dropped, established, etc).

all-floods [requests/period [burst]]

Allows only a certain amount of new connections.

Be careful to not set the rate too low as the rule is applied to all connections regardless of their final result (rejected, dropped, established, etc).

Examples

protection strong

protection "invalid new-tcp-w/o-syn"

protection syn-floods 90/sec 40
  

Bugs

When using multiple types in a single command, if the quotes are forgotten, incorrect rules will be generated without warning.

When using multiple types in a single command, FireHOL will silently ignore any types that come after a group type (bad-packets, strong and its aliases). Only use group types on their own line.


Name

firehol-server — accept requests to a service

Synopsis

server|server46|server4|server6 service action [rule-params]

route|route46|route4|route6 service action [rule-params]

Description

The server subcommand defines a server of a service on an interface or router. Any rule-params given to a parent interface or router are inherited by the server.

For FireHOL a server is the destination of a request. Even though this is more complex for some multi-socket services, to FireHOL a server always accepts requests.

The route subcommand is an alias for server which may only be used in routers.

The service parameter is one of the supported service names from services list: firehol-services(5). Multiple services may be specified, space delimited in quotes.

The action can be any of the actions listed in actions for rules: firehol-actions(5).

The rule-params define a set of rule parameters to further restrict the traffic that is matched to this service. See optional rule parameters: firehol-rule-params(5) for more details.

Note

Writing server4 is equivalent to writing ipv4 server and ensures this subcommand is applied only in the IPv4 firewall rules.

Writing server6 is equivalent to writing ipv6 server and ensures this subcommand is applied only in the IPv6 firewall rules.

Writing server46 is equivalent to writing both server and ensures this subcommand is applied in both the IPv4 and IPv6 firewall rules; it cannot be used as part an interface or router that is IPv4 or IPv6 only.

The default server inherits its behaviour from the enclosing interface or router.

The same rules apply to the variations of route.

Examples

server smtp accept

server "smtp pop3" accept

server smtp accept src 192.0.2.1

server smtp accept log "mail packet" src 192.0.2.1
  

Name

firehol-client — accept replies from a service

Synopsis

client|client46|client4|client6 service action [rule-params]

Description

The client subcommand defines a client of a service on an interface or router. Any rule-params given to a parent interface or router are inherited by the client, but are reversed.

For FireHOL a client is the source of a request. Even though this is more complex for some multi-socket services, to FireHOL a client always initiates the connection.

The service parameter is one of the supported service names from services list: firehol-services(5). Multiple services may be specified, space delimited in quotes.

The action can be any of the actions listed in actions for rules: firehol-actions(5).

The rule-params define a set of rule parameters to further restrict the traffic that is matched to this service. See optional rule parameters: firehol-rule-params(5) for more details.

Note

Writing client4 is equivalent to writing ipv4 client and ensures this subcommand is applied only in the IPv4 firewall rules.

Writing client6 is equivalent to writing ipv6 client and ensures this subcommand is applied only in the IPv6 firewall rules.

Writing client46 is equivalent to writing both client and ensures this subcommand is applied in both the IPv4 and IPv6 firewall rules; it cannot be used as part an interface or router that is IPv4 or IPv6 only.

The default server inherits its behaviour from the enclosing interface or router.

Examples

client smtp accept

client "smtp pop3" accept

client smtp accept src 192.0.2.1

client smtp accept log "mail packet" src 192.0.2.1
  

Name

firehol-group — group commands with common options

Synopsis

group with [rule-params]

group end

Description

The group command allows you to group together multiple client and server commands.

Grouping commands with common options (see optional rule parameters: firehol-rule-params(5)) allows the option values to be checked only once in the generated firewall rather than once per service, making it more efficient.

Nested groups may be used.

Examples

This:

interface any world
    client all accept
    server http accept

    # Provide these services to trusted hosts only
    server "ssh telnet" accept src "192.0.2.1 192.0.2.2"
    

can be replaced to produce a more efficient firewall by this:

interface any world
    client all accept
    server http accept

    # Provide these services to trusted hosts only
    group with src "192.0.2.1 192.0.2.2"
        server telnet accept
        server ssh accept
    group end
    

Optional Parameters and Actions


Table of Contents

optional rule parameters: firehol-rule-params — optional rule parameters
actions for rules: firehol-actions — rule actions

Name

firehol-rule-params — optional rule parameters

Synopsis

Common

src|src4|src6 [not] host

dst|dst4|dst6 [not] host

srctype [not] type

dsttype [not] type

proto [not] protocol

mac [not] macaddr

dscp [not] { value | class classid }

mark [not] id

tos [not] id

custom "iptables-options..."

Router Only

inface [not] interface

outface [not] interface

physin [not] interface

physout [not] interface

Interface Only

uid [not] user

gid [not] group

Logging

log "log text" [level loglevel]

loglimit "log text" [level loglevel]

Other

sport port(s)

dport port(s)

Description

Optional rule parameters are accepted by many commands to narrow the match they make. Not all parameters are accepted by all commands so you should check the individual commands for exclusions.

All matches are made against the REQUEST. FireHOL automatically sets up the necessary  stateful rules to deal with replies in the reverse direction.

Use the option not to match any value other than the one(s) specified.

The logging parameters are unusual in that they do not affect the match, they just cause a log message to be emitted. Therefore, the logging parameters don't support the not option.

FireHOL is designed so that if you specify a parameter that is also used internally by the command then a warning will be issued (and the internal version will be used).

Common

Use src and dst to define the source and destination IP addresses of the request respectively. host defines the IP or IPs to be matched. Examples:

server4 smtp accept src not 192.0.2.1
server4 smtp accept dst 198.51.100.1
server4 smtp accept src not 192.0.2.1 dst 198.51.100.1
server6 smtp accept src not 2001:DB8:1::/64
server6 smtp accept dst 2001:DB8:2::/64
server6 smtp accept src not 2001:DB8:1::/64 dst 2001:DB8:2::/64
    

When attempting to create rules for both IPv4 and IPv6 it is generally easier to use the src4, src6, dst4 and dst6 pairs:

server46 smtp accept src4 192.0.2.1 src6 2001:DB8:1::/64
server46 smtp accept dst4 198.51.100.1 dst6 2001:DB8:2::/64
server46 smtp accept dst4 $d4 dst6 $d6 src4 not $d4 src6 not $s6
    

To keep the rules sane, if one of the 4/6 pair specifies not, then so must the other. If you do not want to use both IPv4 and IPv6 addresses, you must specify the rule as IPv4 or IPv6 only. It is always possible to write a second IPv4 or IPv6 only rule.

Use srctype or dsttype to define the source or destination IP address type of the request. type is the address type category as used in the kernel's network stack. It can be one of:

UNSPEC

an unspecified address (i.e. 0.0.0.0)

UNICAST

a unicast address

LOCAL

a local address

BROADCAST

a broadcast address

ANYCAST

an anycast address

MULTICAST

a multicast address

BLACKHOLE

a blackhole address

UNREACHABLE

an unreachable address

PROHIBIT

a prohibited address

THROW, NAT, XRESOLVE

undocumented

See iptables(8) or run iptables -m addrtype --help for more information. Examples:

server smtp accept srctype not "UNREACHABLE PROHIBIT"
    

Use proto to match by protocol. The protocol can be any accepted by iptables(8).

Use mac to match by MAC address. The macaddr matches to the "remote" host. In an interface, "remote" always means the non-local host. In a router, "remote" refers to the source of requests for servers. It refers to the destination of requests for clients. Examples:

# Only allow pop3 requests to the e6 host
client pop3 accept mac 00:01:01:00:00:e6

# Only allow hosts other than e7/e8 to access smtp
server smtp accept mac not "00:01:01:00:00:e7 00:01:01:00:00:e8"
    

Use dscp to match the DSCP field on packets. For details on DSCP values and classids, see dscp config helper: firehol-dscp(5).

server smtp accept dscp not "0x20 0x30"
server smtp accept dscp not class "BE EF"
    

Use mark to match marks set on packets. For details on mark ids, see mark config helper: firehol-mark(5).

server smtp accept mark not "20 55"
    

Use tos to match the TOS field on packets. For details on TOS ids, see tos config helper: firehol-tos(5).

server smtp accept tos not "Maximize-Throughput 0x10"
    

Use custom to pass arguments directly to iptables(8). All of the parameters must be in a single quoted string. To pass an option to iptables(8) that itself contains a space you need to quote strings in the usual bash(1) manner. For example:

server smtp accept custom "--some-option some-value"
server smtp accept custom "--some-option 'some-value second-value'"
    

Router Only

Use inface and outface to define the interface via which a request is received and forwarded respectively. Use the same format as interface definition: firehol-interface(5). Examples:

server smtp accept inface not eth0
server smtp accept inface not "eth0 eth1"
server smtp accept inface eth0 outface eth1
    

Use physin and physout to define the physical interface via which a request is received or send in cases where the inface or outface is known to be a virtual interface; e.g. a bridge. Use the same format as interface definition: firehol-interface(5). Examples:

server smtp accept physin not eth0
    

Interface only

These parameters match information related to information gathered from the local host. They apply only to outgoing packets and are silently ignored for incoming requests and requests that will be forwarded.

Use uid to match the operating system user sending the traffic. The user is a username, uid number or a quoted list of the two.

For example, to limit which users can access POP3 and IMAP by preventing replies for certain users from being sent:

client "pop3 imap" accept user not "user1 user2 user3"
    

Similarly, this will allow all requests to reach the server but prevent replies unless the web server is running as apache:

server http accept user apache
    

Use gid to match the operating system group sending the traffic. The group is a group name, gid number or a quoted list of the two.

Note

The Linux kernel infrastructure to match PID/SID and executable names with pid, sid and cmd has been removed so these options can no longer be used.

Logging

Use log or loglimit to log matching packets to syslog. Unlike iptables(8) logging, this is not an action: FireHOL will produce multiple iptables commands to accomplish both the action for the rule and the logging.

Logging is controlled using the FIREHOL_LOG_OPTIONS and FIREHOL_LOG_LEVEL environment variables (see control variables: firehol-variables(5)). loglimit additionally honours the FIREHOL_LOG_FREQUENCY and FIREHOL_LOG_BURST variables.

Specifying level (which takes the same values as FIREHOL_LOG_LEVEL) allows you to override the log level for a single rule.

Lesser used parameters

FireHOL also provides dport, sport and limit which are used internally and rarely needed within configuration files.

dport requires an argument port which can be a name, number, range (FROM:TO) or a quoted list of ports. It specifies the destination port of a request and can be useful when matching traffic to helper commands (such as nat) where there is no implicit port.

sport requires an argument port which can be a name, number, range (FROM:TO) or a quoted list of ports. It specifies the source port of a request and can be useful when matching traffic to helper commands (such as nat) where there is no implicit port.

limit requires the arguments frequency and burst and will limit the matching of traffic in both directions.


Name

firehol-actions — rule actions

Synopsis

accept

accept with limit requests/period burst [ overflow action ]

accept with recent name seconds hits

accept with knock name

reject [ with message ]

drop

deny

return

tarpit

Description

These actions are the actions to be taken on traffic that has been matched by a particular rule.

FireHOL will also pass through any actions that iptables(8) accepts, however these definitions provide lowercase versions which accept arguments where appropriate and which could otherwise not be passed through.

Note

The iptables(8) LOG action is best used through the optional rule parameter log since the latter can be combined with one of these actions (FireHOL will generate multiple firewall rules to make this happen). For information on log and loglimit, see optional rule parameters: firehol-rule-params(5).

The following actions are defined:

accept

accept allows the traffic matching the rules to reach its destination.

For example, to allow SMTP requests and their replies to flow:

server smtp accept
            

accept with limit

accept with limit allows the traffic, with new connections limited to requests/period with a maximum burst. Run iptables -m limit --help for more information.

The default overflow action is to REJECT the excess connections (DROP would produce timeouts on otherwise valid service clients).

Examples:

server smtp accept with limit 10/sec 100

server smtp accept with limit 10/sec 100 overflow drop
            

accept with recent

accept with recent allows the traffic matching the rules to reach its destination, limited per remote IP to hits per seconds. Run iptables -m recent --help for more information.

The name parameter is used to allow multiple rules to share the same table of recent IPs.

For example, to allow only 2 connections every 60 seconds per remote IP, to the smtp server:

server smtp accept with recent mail 60 2
          

Note

When a new connection is not allowed, the traffic will continue to be matched by the rest of the firewall. In other words, if the traffic is not allowed due to the limitations set here, it is not dropped, it is just not matched by this rule.

accept with knock

accept with knock allows easy integration with knockd, a server that allows you to control access to services by sending certain packets to "knock" on the door, before the door is opened for service.

The name is used to build a special chain knock_<name> which contains rules to allow established connections to work. If knockd has not allowed new connections any traffic entering this chain will just return back and continue to match against the other rules until the end of the firewall.

For example, to allow HTTPS requests based on a knock write:

server https accept with knock hidden
            

then configure knockd to enable the HTTPS service with:

iptables -A knock_hidden -s %IP% -j ACCEPT
            

and disable it with:

iptables -D knock_hidden -s %IP% -j ACCEPT
            

You can use the same knock name in more than one FireHOL rule to enable/disable all the services based on a single knockd configuration entry.

Note

There is no need to match anything other than the IP in knockd. FireHOL already matches everything else needed for its rules to work.

reject with message, reject

reject discards the traffic matching the rules and sends a rejecting message back to the sender.

When used with with the specific message to return can be specified. Run iptables -j REJECT --help for a list of the --reject-with values which can be used for message. See the section called “Reject With Messsages” for some examples.

The default (no message specified) is to send tcp-reset when dealing with TCP connections and icmp-port-unreachable for all other protocols.

For example:

UNMATCHED_INPUT_POLICY="reject with host-prohib"

policy reject with host-unreach

server ident reject with tcp-reset
          

drop, deny

drop discards the traffic matching the rules. It does so silently and the sender will need to timeout to conclude it cannot reach the service.

deny is a synonym for drop. For example, either of these would silently discard SMTP traffic:

server smtp drop

server smtp deny
          
return

return will return the flow of processing to the parent of the current command.

Currently, the only time return can be used meaningfully used is as a policy for an interface definition. Unmatched traffic will continue being processed with the possibility of being matched by a later definition. For example:

policy return
          
tarpit

tarpit captures and holds incoming TCP connections open.

Connections are accepted and immediately switched to the persist state (0 byte window), in which the remote side stops sending data and asks to continue every 60-240 seconds.

Attempts to close the connection are ignored, forcing the remote side to time out the connection after 12-24 minutes.

Example:

server smtp tarpit
            

Note

As the kernel conntrack modules are always loaded by FireHOL, some per-connection resources will be consumed. See this bug report for details.

The following actions also exist but should not be used under normal circumstances:

mirror

mirror returns the traffic it receives by switching the source and destination fields. REJECT will be used for traffic generated by the local host.

Warning

The MIRROR target was removed from the Linux kernel due to its security implications.

MIRROR is dangerous; use it with care and only if you understand what you are doing.

redirect, redirect to-port port

redirect is used internally by FireHOL helper commands.

Only FireHOL developers should need to use this action directly.

Reject With Messsages

The following RFCs contain information relevant to these messages:

RFC 1812
RFC 1122
RFC 792

icmp-net-unreachable, net-unreach

ICMP network unreachable

Generated by a router if a forwarding path (route) to the destination network is not available.

From RFC 1812, section 5.2.7.1. See RFC 1812 and RFC 792.

Note

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

icmp-host-unreachable, host-unreach

ICMP host unreachable

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

From RFC 1812, section 5.2.7.1. See RFC 1812 and RFC 792.

Note

Use with care. The sender and the routers between you and the sender may conclude that your host is entirely unreachable, and prevent other traffic from reaching you.

icmp-proto-unreachable, proto-unreach

ICMP protocol unreachable

Generated if the transport protocol designated in a datagram is not supported in the transport layer of the final destination.

From RFC 1812, section 5.2.7.1. See RFC 1812 and RFC 792.

icmp-port-unreachable, port-unreach

ICMP port unreachable

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.

From RFC 1812, section 5.2.7.1. See RFC 1812 and RFC 792.

Generated by hosts to indicate that the required port is not active.

icmp-net-prohibited, net-prohib

ICMP communication with destination network administratively prohibited

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.

From RFC 1812, section 5.2.7.1. See RFC 1812 and RFC 1122.

Note

This message may not be widely understood.

icmp-host-prohibited, host-prohib

ICMP communication with destination host administratively prohibited

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.

From RFC 1812, section 5.2.7.1. See RFC 1812 and RFC 1122.

Note

This message may not be widely understood.

tcp-reset

TCP RST

The port unreachable message of the TCP stack.

See RFC 1122.

Note

tcp-reset is useful when you want to prevent timeouts on rejected TCP services where the client incorrectly ignores ICMP port unreachable messages.

Helper Commands


Table of Contents

iptables helper: firehol-iptables — include custom iptables commands
masquerade helper: firehol-masquerade — set up masquerading (NAT) on an interface
tcpmss helper: firehol-tcpmss — set the MSS of TCP SYN packets for routers

Name

firehol-iptables — include custom iptables commands

Synopsis

iptables argument...

Description

The iptables helper command passes all of its arguments to the real iptables(8) at the appropriate point during run-time.

Note

When used in an interface or router, the result will not have a direct relationship to the enclosing definition as the parameters passed are only those you supply.

You should not use /sbin/iptables directly in a FireHOL configuration as it will run before FireHOL activates its firewall. This means they it be applied to the running firewall, not the new firewall, so will be removed when the new firewall is activated.

The iptables helper is provided to allow you to hook in commands safely.

See Also

FireHOL program: firehol(1)
FireHOL configuration: firehol.conf(5)
administration tool for IPv4 firewalls: iptables(8)

Name

firehol-masquerade — set up masquerading (NAT) on an interface

Synopsis

masquerade real-interface [rule-params]

masquerade [reverse] [rule-params]

Description

The masquerade helper command sets up masquerading on the output of a real network interface (as opposed to a FireHOL interface definition).

If a real-interface is specified the command should be used before any interface or router definitions. Multiple values can be given separated by whitespace, so long as they are enclosed in quotes.

If used within an interface definition the definition's real-interface will be used.

If used within a router definition the definition's outface(s) will be used if specified. If the reverse option is gived, then the definition's inface(s) will be used if specified.

Unlike most commands, masquerade does not inherit its parent definition's rules-params, it only honour's its own. The inface and outface parameters should not be used (iptables does not support inface in the POSTROUTING chain and outface will be overwritten by FireHOL using the rules above).

Note

The masquerade always applies to the output of the chosen network interfaces.

FIREHOL_NAT will be turned on automatically (see control variables: firehol-variables(5)) and FireHOL will enable packet-forwarding in the kernel.

Masquerading and SNAT

Masquerading is a special form of Source NAT (SNAT) that changes the source of requests when they go out and replaces their original source when they come in. This way a Linux host 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 compare to SNAT because it checks the IP address of the outgoing interface every time for every packet. If your host has a static IP address you should generally prefer SNAT.

Examples

# Before any interface or router
masquerade eth0 src 192.0.2.0/24 dst not 192.0.2.0/24

# In an interface definition to masquerade the output of its real-interface
masquerade

# In a router definition to masquerade the output of its outface
masquerade

# In a router definition to masquerade the output of its inface
masquerade reverse
  

Name

firehol-tcpmss — set the MSS of TCP SYN packets for routers

Synopsis

tcpmss { mss | auto } [ if-list ]

Description

The tcpmss helper command sets the MSS (Maximum Segment Size) of TCP SYN packets routed through the firewall. This can be used to overcome situations where Path MTU Discovery is not working and packet fragmentation is not possible.

A numeric mss will set MSS of TCP connections to the value given. Using the word auto will set the MSS to the MTU of the outgoing interface minus 40 (clamp-mss-to-pmtu).

If used within a router or interface definition the MSS will be applied to outgoing traffic on the outface(s) of the router or interface.

If used before any router or interface definitions it will be applied to all traffic passing through the firewall. If if-list is given, the MSS will be applied only to those interfaces.

Examples

tcpmss auto

tcpmss 500

tcpmss 500 "eth1 eth2 eth3"
  

Configuration Helper Commands


Table of Contents

version config helper: firehol-version — set version number of configuration file
action config helper: firehol-action — set up custom filter actions
blacklist config helper: firehol-blacklist — set up a unidirectional or bidirectional blacklist
classify config helper: firehol-classify — classify traffic for traffic shaping tools
connmark config helper: firehol-connmark — set a stateful mark on a connection
dscp config helper: firehol-dscp — set the DSCP field in the packet header
mac config helper: firehol-mac — ensure source IP and source MAC address match
mark config helper: firehol-mark — mark traffic for traffic shaping tools
nat, snat, dnat, redirect config helpers: firehol-nat — set up NAT and port redirections
transparent_proxy, transparent_squid helpers: firehol-transparent_proxy — set up a transparent proxy
tos config helper: firehol-tos — set the Type of Service (TOS) of packets
tosfix config helper: firehol-tosfix — apply suggested TOS values to packets

Name

firehol-version — set version number of configuration file

Synopsis

version 6

Description

The version helper command states the configuration file version.

If the value passed is newer than the running version of FireHOL supports, FireHOL will not run.

You do not have to specify a version number for a configuration file, but by doing so you will prevent FireHOL trying to process a file which it cannot handle.

The value that FireHOL expects is increased every time that the configuration file format changes.

Note

If you pass version 5 to FireHOL, it will disable IPv6 support and warn you that you must update your configuration.


Name

firehol-action — set up custom filter actions

Synopsis

action chain name action

Description

The action helper command creates an iptables chain which can be used to control the action of other firewall rules once the firewall is running.

For example, you can setup the custom action ACT1, which by default is ACCEPT, but can be dynamically changed to DROP, REJECT or RETURN (and back) without restarting the firewall.

The name can be any chain name accepted by iptables. You should try to keep it within 5 and 10 characters.

Note

The names created with this command are case-sensitive.

The action can be any of those supported by FireHOL (see actions for rules: firehol-actions(5)). Only ACCEPT, REJECT, DROP, RETURN have any meaning in this instance.

Examples

To create a custom chain and have some rules use it:

action chain ACT1 accept

interface any world
    server smtp ACT1
    client smtp ACT1
    

Once the firewall is running you can dynamically modify the behaviour of the chain from the Linux command-line, as detailed below:

To insert a DROP action at the start of the chain to override the default action (ACCEPT):

iptables -t filter -I ACT1 -j DROP

To delete the DROP action from the start of the chain to return to the default action:

iptables -t filter -D ACT1 -j DROP

Note

If you delete all of the rules in the chain, the default will be to RETURN, in which case the behaviour will be as if any rules with the action were not present in the configuration file.

You can also create multiple chains simultaneously. To create 3 ACCEPT and 3 DROP chains you can do the following:

action chain "ACT1 ACT2 ACT3" accept
action chain "ACT4 ACT5 ACT6" drop
    


Name

firehol-blacklist — set up a unidirectional or bidirectional blacklist

Synopsis

blacklist [ full | all ] ip...

blacklist { input | them | him | her | it | this | these } ip...

Description

The blacklist helper command creates a blacklist for the ip list given (which can be in quotes or not).

If the type full or one of its aliases is supplied, or no type is given, a bidirectional stateless blacklist will be generated. The firewall will REJECT all traffic going to the IP addresses and DROP all traffic coming from them.

If the type input or one of its aliases is supplied, a unidirectional stateful blacklist will be generated. Connections can be initiated to such IP addresses, but the IP addresses will not be able to connect to the firewall or hosts protected by it.

Any blacklists will affect all router and interface definitions. They must be declared before the first router or interface.

Examples

blacklist full 192.0.2.1 192.0.2.2
blacklist input "192.0.2.3 192.0.2.4"
    

Name

firehol-classify — classify traffic for traffic shaping tools

Synopsis

classify class [rule-params]

Description

The classify helper command puts matching traffic into the specified traffic shaping class.

The class is a class as used by iptables and tc (e.g. MAJOR:MINOR).

The rule-params define a set of rule parameters to match the traffic that is to be classified. See optional rule parameters: firehol-rule-params(5) for more details.

Any classify commands will affect all traffic matched. They must be declared before the first router or interface.

Examples

# Put all smtp traffic leaving via eth1 in class 1:1
classify 1:1 outface eth1 proto tcp dport 25
    

See Also

FireHOL program: firehol(1)
FireHOL configuration: firehol.conf(5)
administration tool for IPv4 firewalls: iptables(8)
show / manipulate traffic control settings: tc(8)
Linux Advanced Routing & Traffic Control HOWTO

Name

firehol-connmark — set a stateful mark on a connection

Synopsis

connmark { value | save | restore } chain [rule-params]

Description

The connmark helper command sets a mark on a whole connection. It applies to both directions.

Note

To set a mark on packets matching particular rules, regardless of any connection, see mark config helper: firehol-mark(5).

The value is the mark value to set (a 32 bit integer). If you specify save then the mark on the matched packet will be turned into a connmark. If you specify restore then the matched packet will have its mark set to the current connmark.

The chain will be used to find traffic to mark. It can be any of the iptables built in chains belonging to the mangle table. The chain names are: INPUT, FORWARD, OUTPUT, PREROUTING and POSTROUTING. The names are case-sensitive.

The rule-params define a set of rule parameters to match the traffic that is to be marked within the chosen chain. See optional rule parameters: firehol-rule-params(5) for more details.

Any connmark commands will affect all traffic matched. They must be declared before the first router or interface.

Examples

Consider a scenario with 3 ethernet ports, where eth0 is on the local LAN, eth1 connects to ISP 'A' and eth2 to ISP 'B'. To ensure traffic leaves via the same ISP as it arrives from you can mark the traffic:

# mark connections when they arrive from the ISPs
connmark 1 PREROUTING inface eth1
connmark 2 PREROUTING inface eth2

# restore the mark (from the connmark) when packets arrive from the LAN
connmark restore OUTPUT
connmark restore PREROUTING inface eth0
    

It is then possible to use the commands from iproute2 such as ip, to pick the correct routing table based on the mark on the packets.

See Also

FireHOL program: firehol(1)
FireHOL configuration: firehol.conf(5)
mark config helper: firehol-mark(5)
administration tool for IPv4 firewalls: iptables(8)
show / manipulate routing, devices, policy routing and tunnels: ip(8)
Linux Advanced Routing & Traffic Control HOWTO

Name

firehol-dscp — set the DSCP field in the packet header

Synopsis

dscp { value | class classid } chain [rule-params]

Description

The dscp helper command sets the DSCP field in the header of packets traffic, to allow QoS shaping.

Note

There is also a dscp parameter which allows matching DSCP values within individual rules (see optional rule parameters: firehol-rule-params(5)).

Set value to a decimal or hexadecimal (0xnn) number to set an explicit DSCP value or use class classid to use an iptables DiffServ class, such as EF, BE, CSxx or AFxx (see iptables -j DSCP --help for more information).

The chain will be used to find traffic to mark. It can be any of the iptables built in chains belonging to the mangle table. The chain names are: INPUT, FORWARD, OUTPUT, PREROUTING and POSTROUTING. The names are case-sensitive.

The rule-params define a set of rule parameters to match the traffic that is to be marked within the chosen chain. See optional rule parameters: firehol-rule-params(5) for more details.

Any dscp commands will affect all traffic matched. They must be declared before the first router or interface.

Examples

# set DSCP field to 32, packets sent by the local machine
dscp 32 OUTPUT

# set DSCP field to 32 (hex 20), packets routed by the local machine
dscp 0x20 FORWARD

# set DSCP to DiffServ class EF, packets routed by the local machine
#              and destined for port TCP/25 of 198.51.100.1
dscp class EF FORWARD proto tcp dport 25 dst 198.51.100.1
    

See Also

FireHOL program: firehol(1)
FireHOL configuration: firehol.conf(5)
administration tool for IPv4 firewalls: iptables(8)
show / manipulate routing, devices, policy routing and tunnels: ip(8)
Linux Advanced Routing & Traffic Control HOWTO
optional rule parameters: firehol-rule-params(5)

Name

firehol-mac — ensure source IP and source MAC address match

Synopsis

mac IP macaddr

Description

Any mac commands will affect all traffic destined for the firewall host, or to be forwarded by the host. They must be declared before the first router or interface.

Note

There is also a mac parameter which allows matching MAC addresses within individual rules (see optional rule parameters: firehol-rule-params(5)).

The mac helper command DROPs traffic from any IP address that was not sent using the macaddr specified.

When packets are dropped, a log is produced with the label "MAC MISSMATCH" (sic.). mac obeys the default log limits (see the section called “Logging” in optional rule parameters: firehol-rule-params(5)).

Note

This command restricts an IP to a particular MAC address. The same MAC address is permitted send traffic with a different IP.

Examples

mac 192.0.2.1    00:01:01:00:00:e6
mac 198.51.100.1 00:01:01:02:aa:e8
    

Name

firehol-mark — mark traffic for traffic shaping tools

Synopsis

mark value chain [rule-params]

Description

The mark helper command sets a mark on packets that can be matched by traffic shaping tools for controlling the traffic.

Note

To set a mark on whole connections, see connmark config helper: firehol-connmark(5). There is also a mark parameter which allows matching marks within individual rules (see optional rule parameters: firehol-rule-params(5)).

The value is the mark value to set (a 32 bit integer).

The chain will be used to find traffic to mark. It can be any of the iptables built in chains belonging to the mangle table. The chain names are: INPUT, FORWARD, OUTPUT, PREROUTING and POSTROUTING. The names are case-sensitive.

The rule-params define a set of rule parameters to match the traffic that is to be marked within the chosen chain. See optional rule parameters: firehol-rule-params(5) for more details.

Any mark commands will affect all traffic matched. They must be declared before the first router or interface.

Note

If you want to do policy based routing based on iptables marks, you will need to disable the Root Path Filtering on the interfaces involved (rp_filter in sysctl).

Examples

# mark with 1, packets sent by the local machine
mark 1 OUTPUT

# mark with 2, packets routed by the local machine
mark 2 FORWARD

# mark with 3, packets routed by the local machine, sent from
#              192.0.2.2 destined for port TCP/25 of 198.51.100.1
mark 3 FORWARD proto tcp dport 25 dst 198.51.100.1 src 192.0.2.2
    

Name

firehol-nat — set up NAT and port redirections

Synopsis

nat { to-source | to-destination } ipaddr[:port] [rule-params]

nat redirect-to port[-range] [rule-params]

snat [to] ipaddr[:port] [rule-params]

dnat [to] ipaddr[:port] [rule-params]

redirect [to] port[-range] [rule-params]

Description

Note

The rule-params are used only to determine the traffic that will be matched for NAT in these commands, not to permit traffic to flow.

The dnat helper is a synonym for nat to-destination (Destination NAT), the snat helper is a synonym for nat to-source (Source NAT), and the redirect helper is a synonym for nat redirect-to (redirect to port on local host).

The port part of the new address is optional with SNAT and DNAT; if not specified it will not be changed.

When you apply NAT to a packet, the Linux kernel will track the changes it makes, so that when it sees replies the transformation will be applied in the opposite direction. For instance if you changed the destination port of a packet from 80 to 8080, when a reply comes back, its source is set as 80. This means the original sender does not need to be aware a transformation is happening.

Applying NAT does not automatically create rules to allow the traffic to pass. You will still need to include client or server entries in an interface or router to allow the traffic.

When using SNAT, the transformation is in the POSTROUTING chain of the NAT table and happens after normal rules are matched, so your client or server rule should match the "unmodified" traffic.

When using DNAT or a REDIRECT, the transformation is in the PREROUTING chain of the NAT table and happens before normal rules are matched, so your client or server rule should match the "modified" traffic.

If you would like to see more detail, this flow diagram shows how network packets are processed by the kernel.

The nat helper takes one of the following sub-commands:

to-destination ipaddr[:port]

Defines a Destination NAT (DNAT). Commonly thought of as port-forwarding (where packets destined for the firewall with a given port and protocol are sent to a different IP address and possibly port), DNAT is much more flexible in that any number of parameters can be matched before the destination information is rewritten.

ipaddr[:port] is the destination address to be set in packets matching rule-params.

If no rules are given, all forwarded traffic will be matched. outface should not be used in DNAT since the information is not available at the time the decision is made.

ipaddr[:port] accepts any --to-destination values that iptables(8) accepts. Run iptables -j DNAT --help to for more information. Multiple ipaddr may be specified by separating with spaces and enclosing with quotes.

to-source ipaddr[:port]

Defines a Source NAT (SNAT). SNAT is similar to masquerading (see masquerade helper: firehol-masquerade(5)) but more efficient for static IP addresses. You can use it to give a public IP address to a host which does not have one behind the firewall.

ipaddr[:port] is the source address to be set in packets matching rule-params.

If no rules are given, all forwarded traffic will be matched. inface should not be used in SNAT since the information is not available at the time the decision is made.

ipaddr[:port] accepts any --to-source values that iptables(8) accepts. Run iptables -j SNAT --help to for more information. Multiple ipaddr[:port] may be specified by separating with spaces and enclosing with quotes.

redirect-to port[-range]

Redirect matching traffic to the local machine. This is typically useful if you want to intercept some traffic and process it on the local machine.

port[-range] is the port range (from-to) or single port that packets matching rule-params will be redirected to.

If no rules are given, all forwarded traffic will be matched. outface should not be used in REDIRECT since the information is not available at the time the decision is made.

Examples

# Port forwarding HTTP
dnat to 192.0.2.2 proto tcp dport 80

# Port forwarding HTTPS on to a different port internally
dnat to 192.0.2.2:4443 proto tcp dport 443

# Fix source for traffic leaving the firewall via eth0 with private address
snat to 198.51.100.1 outface eth0 src 192.168.0.0/24

# Transparent squid (running on the firewall) for some hosts
redirect to 8080 inface eth0 src 198.51.100.0/24 proto tcp dport 80

# Send to 192.0.2.1
#  - all traffic arriving at or passing through the firewall
nat to-destination 192.0.2.1

# Send to 192.0.2.1
#  - all traffic arriving at or passing through the firewall
#  - which WAS going to 203.0.113.1
nat to-destination 192.0.2.1 dst 203.0.113.1

# Send to 192.0.2.1
#  - TCP traffic arriving at or passing through the firewall
#  - which WAS going to 203.0.113.1
nat to-destination 192.0.2.1 proto tcp dst 203.0.113.1

# Send to 192.0.2.1
#  - TCP traffic arriving at or passing through the firewall
#  - which WAS going to 203.0.113.1, port 25
nat to-destination 192.0.2.1 proto tcp dport 25 dst 203.0.113.1
  

Name

firehol-transparent_proxy — set up a transparent proxy

Synopsis

transparent_proxy service port user [rule-params]

transparent_squid port user [rule-params]

Description

The transparent_proxy helper command sets up transparent caching for TCP traffic.

Note

The proxy application must be running on the firewall host at port port with the credentials of the local user user (which may be a space-delimited list enclosed in quotes) serving requests appropriate to the TCP port service.

The rule-params define a set of rule parameters to define the traffic that is to be proxied. See optional rule parameters: firehol-rule-params(5) for more details.

For traffic destined for the firewall host or passing through the firewall, do not use the outface rule because the rules are applied before the routing decision and so the outgoing interface will not be known.

An empty user string ("") disables caching of locally-generated traffic. Otherwise, traffic starting from the firewall is captured, except traffic generated by the local user(s) user. The inface, outface and src rule-params are all ignored for locally-generated traffic.

The transparent_squid helper command sets up the special case for HTTP traffic with service implicitly set to 80.

Examples

transparent_proxy 80 3128 squid inface eth0 src 192.0.2.0/24
transparent_squid 3128 squid inface eth0 src 192.0.2.0/24

transparent_proxy "80 3128 8080" 3128 "squid privoxy root bin" \
  inface not "ppp+ ipsec+" dst not "a.not.proxied.server"
transparent_squid "80 3128 8080" "squid privoxy root bin" \
  inface not "ppp+ ipsec+" dst not "non.proxied.server"
  

Name

firehol-tos — set the Type of Service (TOS) of packets

Synopsis

tos value chain [rule-params]

Description

The tos helper command sets the Type of Service (TOS) field in packet headers.

Note

There is also a tos parameter which allows matching TOS values within individual rules (see optional rule parameters: firehol-rule-params(5)).

The value can be an integer number (decimal or hexadecimal) or one of the descriptive values accepted by iptables (run iptables -j TOS --help for a list).

The chain will be used to find traffic to mark. It can be any of the iptables built in chains belonging to the mangle table. The chain names are: INPUT, FORWARD, OUTPUT, PREROUTING and POSTROUTING. The names are case-sensitive.

The rule-params define a set of rule parameters to match the traffic that is to be marked within the chosen chain. See optional rule parameters: firehol-rule-params(5) for more details.

Any tos commands will affect all traffic matched. They must be declared before the first router or interface.

Examples

# set TOS to 16, packets sent by the local machine
tos 16 OUTPUT

# set TOS to 0x10 (16), packets routed by the local machine
tos 0x10 FORWARD

# set TOS to Maximize-Throughput (8), packets routed by the local
#              machine, destined for port TCP/25 of 198.51.100.1
tos Maximize-Throughput FORWARD proto tcp dport 25 dst 198.51.100.1
    

Name

firehol-tosfix — apply suggested TOS values to packets

Synopsis

tosfix

Description

The tosfix helper command sets the Type of Service (TOS) field in packet headers based on the suggestions given by Erik Hensema in iptables and tc shaping tricks .

The following TOS values are set:

  • All TCP ACK packets with length less than 128 bytes are assigned Minimize-Delay, while bigger ones are assigned Maximize-Throughput

  • All packets with TOS Minimize-Delay, that are bigger than 512 bytes are set to Maximize-Throughput, except for short bursts of 2 packets per second

The tosfix command must be used before the first router or interface.

Services Reference


Table of Contents

services list: firehol-services — FireHOL service list
services list a: firehol-services-a — FireHOL service list a
services list b: firehol-services-b — FireHOL service list b
services list c: firehol-services-c — FireHOL service list c
services list d: firehol-services-d — FireHOL service list d
services list e: firehol-services-e — FireHOL service list e
services list f: firehol-services-f — FireHOL service list f
services list g: firehol-services-g — FireHOL service list g
services list h: firehol-services-h — FireHOL service list h
services list i: firehol-services-i — FireHOL service list i
services list j: firehol-services-j — FireHOL service list j
services list k: firehol-services-k — FireHOL service list k
services list l: firehol-services-l — FireHOL service list l
services list m: firehol-services-m — FireHOL service list m
services list n: firehol-services-n — FireHOL service list n
services list o: firehol-services-o — FireHOL service list o
services list p: firehol-services-p — FireHOL service list p
services list q: firehol-services-q — FireHOL service list q
services list r: firehol-services-r — FireHOL service list r
services list s: firehol-services-s — FireHOL service list s
services list t: firehol-services-t — FireHOL service list t
services list u: firehol-services-u — FireHOL service list u
services list v: firehol-services-v — FireHOL service list v
services list w: firehol-services-w — FireHOL service list w
services list x: firehol-services-x — FireHOL service list x
services list y: firehol-services-y — FireHOL service list y
services list z: firehol-services-z — FireHOL service list z

Name

firehol-services-a — FireHOL service list a

Services starting with A

AH - IPSec Authentication Header (AH)
all - Match all traffic
amanda - Advanced Maryland Automatic Network Disk Archiver
any - Match all traffic (without modules or indirect)
anystateless - Match all traffic statelessly
apcupsd - APC UPS Daemon
apcupsdnis - APC UPS Daemon Network Information Server
aptproxy - Advanced Packaging Tool Proxy
asterisk - Asterisk PABX

AH - IPSec Authentication Header (AH)

Example

Configuration sample:

server AH accept

Service Type

simple

Server Ports

51/any

Client Ports

any

Links

Wikipedia

Notes

For more information see this Archive of the FreeS/WAN documentation and RFC 2402.

all - Match all traffic

Example

Configuration sample:

server all accept

Service Type

complex

Server Ports

all

Client Ports

all

Notes

Matches all traffic (all protocols, ports, etc) while ensuring that required kernel modules are loaded.

This service may indirectly setup a set of other services, if they require kernel modules to be loaded. The following complex services are activated:

ftp - File Transfer Protocol
irc - Internet Relay Chat

amanda - Advanced Maryland Automatic Network Disk Archiver

Service Type

simple

Server Ports

udp/10080

Client Ports

default

Netfilter Modules

nf_conntrack_amanda (CONFIG_NF_CONNTRACK_AMANDA)

Netfilter NAT Modules

nf_nat_amanda (CONFIG_NF_NAT_AMANDA)

Links

Homepage, Wikipedia

any - Match all traffic (without modules or indirect)

Example

Configuration sample:

server any myname accept proto 47

Service Type

complex

Server Ports

all

Client Ports

all

Notes

Matches all traffic (all protocols, ports, etc), but does not care about kernel modules and does not activate any other service indirectly. In combination with the optional rule parameters: firehol-rule-params(5) this service can match unusual traffic (e.g. GRE - protocol 47).

Note that you have to supply your own name in addition to "any".

anystateless - Match all traffic statelessly

Example

Configuration sample:

server anystateless myname accept proto 47

Service Type

complex

Server Ports

all

Client Ports

all

Notes

Matches all traffic (all protocols, ports, etc), but does not care about kernel modules and does not activate any other service indirectly. In combination with the optional rule parameters: firehol-rule-params(5) this service can match unusual traffic (e.g. GRE - protocol 47).

This service is identical to "any" but does not care about the state of traffic.

Note that you have to supply your own name in addition to "anystateless".

apcupsd - APC UPS Daemon

Example

Configuration sample:

server apcupsd accept

Service Type

simple

Server Ports

tcp/6544

Client Ports

default

Links

Homepage, Wikipedia

Notes

This service must be defined as "server apcupsd accept" on all machines not directly connected to the UPS (i.e. slaves).

Note that the port defined here is not the default port (6666) used if you download and compile APCUPSD, since the default conflicts with IRC and many distributions (like Debian) have changed this to 6544.

You can define port 6544 in APCUPSD, by changing the value of NETPORT in its configuration file, or overwrite this FireHOL service definition using the procedures described in the section called “Adding Services” of FireHOL configuration: firehol.conf(5).

apcupsdnis - APC UPS Daemon Network Information Server

Example

Configuration sample:

server apcupsdnis accept

Service Type

simple

Server Ports

tcp/3551

Client Ports

default

Links

Homepage, Wikipedia

Notes

This service allows the remote WEB interfaces of APCUPSD, to connect and get information from the server directly connected to the UPS device.

aptproxy - Advanced Packaging Tool Proxy

Example

Configuration sample:

server aptproxy accept

Service Type

simple

Server Ports

tcp/9999

Client Ports

default

Links

Wikipedia

asterisk - Asterisk PABX

Example

Configuration sample:

server asterisk accept

Service Type

simple

Server Ports

tcp/5038

Client Ports

default

Links

Homepage, Wikipedia

Notes

This service refers only to the manager interface of asterisk. You should normally enable sip - Session Initiation Protocol , h323 - H.323 VoIP , rtp - Real-time Transport Protocol , etc. at the firewall level, if you enable the relative channel drivers of asterisk.


Name

firehol-services-b — FireHOL service list b

Services starting with B

Currently no services start with B


Name

firehol-services-c — FireHOL service list c

Services starting with C

cups - Common UNIX Printing System
custom - Custom definitions
cvspserver - Concurrent Versions System

cups - Common UNIX Printing System

Example

Configuration sample:

server cups accept

Service Type

simple

Server Ports

tcp/631 udp/631

Client Ports

any

Links

Homepage, Wikipedia

custom - Custom definitions

Example

Configuration sample:

server custom myimap tcp/143 default accept

Service Type

custom

Server Ports

N/A

Client Ports

N/A

Notes

The full syntax is:

subcommand custom name svr-proto/ports cli-ports action params

This service is used by FireHOL to allow you create rules for services which do not have a definition.

subcommand, action and params have their usual meanings.

A name must be supplied along with server ports in the form proto/range and client ports which takes only a range.

To define services with the built-in extension mechanism to avoid the need for custom services, see the section called “Adding Services” of FireHOL configuration: firehol.conf(5).

cvspserver - Concurrent Versions System

Example

Configuration sample:

server cvspserver accept

Service Type

simple

Server Ports

tcp/2401

Client Ports

default

Links

Homepage, Wikipedia


Name

firehol-services-d — FireHOL service list d

Services starting with D

darkstat - Darkstat network traffic analyser
daytime - Daytime Protocol
dcc - Distributed Checksum Clearinghouse
dcpp - Direct Connect++ P2P
dhcp - Dynamic Host Configuration Protocol
dhcprelay - DHCP Relay
dhcpv6 - Dynamic Host Configuration Protocol for IPv6
dict - Dictionary Server Protocol
distcc - Distributed CC
dns - Domain Name System

darkstat - Darkstat network traffic analyser

Example

Configuration sample:

server darkstat accept

Service Type

simple

Server Ports

tcp/666

Client Ports

default

Links

Homepage

daytime - Daytime Protocol

Example

Configuration sample:

server daytime accept

Service Type

simple

Server Ports

tcp/13

Client Ports

default

Links

Wikipedia

dcc - Distributed Checksum Clearinghouse

Example

Configuration sample:

server dcc accept

Service Type

simple

Server Ports

udp/6277

Client Ports

default

Links

Wikipedia

Notes

See also this DCC FAQ.

dcpp - Direct Connect++ P2P

Example

Configuration sample:

server dcpp accept

Service Type

simple

Server Ports

tcp/1412 udp/1412

Client Ports

default

Links

Homepage

dhcp - Dynamic Host Configuration Protocol

Example

Configuration sample:

server dhcp accept

Service Type

complex

Server Ports

udp/67

Client Ports

68

Links

Wikipedia

Notes

The dhcp service is implemented as stateless rules.

DHCP clients broadcast to the network (src 0.0.0.0 dst 255.255.255.255) to find a DHCP server. If the DHCP service was stateful the iptables connection tracker would not match the packets and deny to send the reply.

Note that this change does not affect the security of either DHCP servers or clients, since only the specific ports are allowed (there is no random port at either the server or the client side).

Note also that the "server dhcp accept" or "client dhcp accept" commands should placed within interfaces that do not have src and / or dst defined (because of the initial broadcast).

You can overcome this problem by placing the DHCP service on a separate interface, without a src or dst but with a policy return. Place this interface before the one that defines the rest of the services.

For example:

          interface eth0 dhcp
              policy return
              server dhcp accept
           
          interface eth0 lan src "$mylan" dst "$myip"
              client all accept
          

This service implicitly sets its client or server to ipv4 mode.

dhcprelay - DHCP Relay

Example

Configuration sample:

server dhcprelay accept

Service Type

simple

Server Ports

udp/67

Client Ports

67

Links

Wikipedia

Notes

From RFC 1812 section 9.1.2:

In many cases, BOOTP clients and their associated BOOTP server(s) do not reside on the same IP (sub)network. In such cases, a third-party agent is required to transfer BOOTP messages between clients and servers. Such an agent was originally referred to as a BOOTP forwarding agent. However, to avoid confusion with the IP forwarding function of a router, the name BOOTP relay agent has been adopted instead.

For more information about DHCP Relay see section 9.1.2 of RFC 1812 and section 4 of RFC 1542

dhcpv6 - Dynamic Host Configuration Protocol for IPv6

Example

Configuration sample:

server dhcp accept src "fe80::/64"
client dhcp accept src "fe80::/64"

Service Type

complex

Server Ports

udp/547

Client Ports

546

Links

Wikipedia

Notes

The dhcp service is implemented as stateless rules.

Clients broadcast from a link-local address to the multicast address ff02::1:2 to find a server. The Server sends a unicast replies back to the client.

If the DHCPv6 service was stateful, the iptables connection tracker would not match the packets and deny to the reply so the service is implemented as stateless rules.

Note that this does not affect the security of either DHCP servers or clients, since only the specific ports are allowed (there is no random port at either the server or the client side).

This service implicitly sets its client or server to ipv6 mode.

dict - Dictionary Server Protocol

Example

Configuration sample:

server dict accept

Service Type

simple

Server Ports

tcp/2628

Client Ports

default

Links

Wikipedia

Notes

See RFC2229.

distcc - Distributed CC

Example

Configuration sample:

server distcc accept

Service Type

simple

Server Ports

tcp/3632

Client Ports

default

Links

Homepage, Wikipedia

Notes

For distcc security, please check the distcc security design.

dns - Domain Name System

Example

Configuration sample:

server dns accept

Service Type

simple

Server Ports

udp/53 tcp/53

Client Ports

any

Links

Wikipedia

Notes

On very busy DNS servers you may see a few dropped DNS packets in your logs. This is normal. The iptables connection tracker will timeout the session and lose unmatched DNS packets that arrive too late to be useful.


Name

firehol-services-e — FireHOL service list e

Services starting with E

echo - Echo Protocol
emule - eMule (Donkey network client)
eserver - eDonkey network server
ESP - IPSec Encapsulated Security Payload (ESP)

echo - Echo Protocol

Example

Configuration sample:

server echo accept

Service Type

simple

Server Ports

tcp/7

Client Ports

default

Links

Wikipedia

emule - eMule (Donkey network client)

Example

Configuration sample:

client emule accept src 192.0.2.1

Service Type

complex

Server Ports

many

Client Ports

many

Links

Homepage

Notes

According to eMule Port Definitions, FireHOL defines:

Accept from any client port to the server at tcp/4661
Accept from any client port to the server at tcp/4662
Accept from any client port to the server at udp/4665
Accept from any client port to the server at udp/4672
Accept from any server port to the client at tcp/4662
Accept from any server port to the client at udp/4672

Use the FireHOL client command: firehol-client(5) command to match the eMule client.

Please note that the eMule client is an HTTP client also.

eserver - eDonkey network server

Example

Configuration sample:

server eserver accept

Service Type

simple

Server Ports

tcp/4661 udp/4661 udp/4665

Client Ports

any

Links

Wikipedia

ESP - IPSec Encapsulated Security Payload (ESP)

Example

Configuration sample:

server ESP accept

Service Type

simple

Server Ports

50/any

Client Ports

any

Links

Wikipedia

Notes

For more information see this Archive of the FreeS/WAN documentation RFC 2406.


Name

firehol-services-f — FireHOL service list f

Services starting with F

finger - Finger Protocol
ftp - File Transfer Protocol

finger - Finger Protocol

Example

Configuration sample:

server finger accept

Service Type

simple

Server Ports

tcp/79

Client Ports

default

Links

Wikipedia

ftp - File Transfer Protocol

Example

Configuration sample:

server ftp accept

Service Type

simple

Server Ports

tcp/21

Client Ports

default

Netfilter Modules

nf_conntrack_ftp (CONFIG_NF_CONNTRACK_FTP)

Netfilter NAT Modules

nf_nat_ftp (CONFIG_NF_NAT_FTP)

Links

Wikipedia

Notes

The FTP service matches both active and passive FTP connections.


Name

firehol-services-g — FireHOL service list g

Services starting with G

gift - giFT Internet File Transfer
giftui - giFT Internet File Transfer User Interface
gkrellmd - GKrellM Daemon
GRE - Generic Routing Encapsulation

gift - giFT Internet File Transfer

Example

Configuration sample:

server gift accept

Service Type

simple

Server Ports

tcp/4302 tcp/1214 tcp/2182 tcp/2472

Client Ports

any

Links

Homepage, Wikipedia

Notes

The gift FireHOL service supports:

Gnutella listening at tcp/4302
FastTrack listening at tcp/1214
OpenFT listening at tcp/2182 and tcp/2472

The above ports are the defaults given for the corresponding giFT modules.

To allow access to the user interface ports of giFT, use the giftui - giFT Internet File Transfer User Interface .

giftui - giFT Internet File Transfer User Interface

Example

Configuration sample:

server giftui accept

Service Type

simple

Server Ports

tcp/1213

Client Ports

default

Links

Homepage, Wikipedia

Notes

This service refers only to the user interface ports offered by giFT. To allow gift accept P2P requests, use the gift - giFT Internet File Transfer .

gkrellmd - GKrellM Daemon

Example

Configuration sample:

server gkrellmd accept

Service Type

simple

Server Ports

tcp/19150

Client Ports

default

Links

Homepage, Wikipedia

GRE - Generic Routing Encapsulation

Example

Configuration sample:

server GRE accept

Service Type

simple

Server Ports

47/any

Client Ports

any

Netfilter Modules

nf_conntrack_proto_gre (CONFIG_NF_CT_PROTO_GRE)

Netfilter NAT Modules

nf_nat_proto_gre (CONFIG_NF_NAT_PROTO_GRE)

Links

Wikipedia

Notes

Protocol No 47.

For more information see RFC RFC 2784.


Name

firehol-services-h — FireHOL service list h

Services starting with H

h323 - H.323 VoIP
heartbeat - HeartBeat
http - Hypertext Transfer Protocol
httpalt - HTTP alternate port
https - Secure Hypertext Transfer Protocol
hylafax - HylaFAX

h323 - H.323 VoIP

Example

Configuration sample:

server h323 accept

Service Type

simple

Server Ports

tcp/1720

Client Ports

default

Netfilter Modules

nf_conntrack_h323 (CONFIG_NF_CONNTRACK_H323)

Netfilter NAT Modules

nf_nat_h323 (CONFIG_NF_NAT_H323)

Links

Wikipedia

heartbeat - HeartBeat

Example

Configuration sample:

server heartbeat accept

Service Type

simple

Server Ports

udp/690:699

Client Ports

default

Links

Homepage

Notes

This FireHOL service has been designed such a way that it will allow multiple heartbeat clusters on the same LAN.

http - Hypertext Transfer Protocol

Example

Configuration sample:

server http accept

Service Type

simple

Server Ports

tcp/80

Client Ports

default

Links

Wikipedia

httpalt - HTTP alternate port

Example

Configuration sample:

server httpalt accept

Service Type

simple

Server Ports

tcp/8080

Client Ports

default

Links

Wikipedia

Notes

This port is commonly used by web servers, web proxies and caches where the standard http - Hypertext Transfer Protocol port is not available or can or should not be used.

https - Secure Hypertext Transfer Protocol

Example

Configuration sample:

server https accept

Service Type

simple

Server Ports

tcp/443

Client Ports

default

Links

Wikipedia

hylafax - HylaFAX

Example

Configuration sample:

server hylafax accept

Service Type

complex

Server Ports

many

Client Ports

many

Links

Homepage, Wikipedia

Notes

This service allows incoming requests to server port tcp/4559 and outgoing from server port tcp/4558.

The correct operation of this service has not been verified.

USE THIS WITH CARE. A HYLAFAX CLIENT MAY OPEN ALL TCP UNPRIVILEGED PORTS TO ANYONE (from port tcp/4558).


Name

firehol-services-i — FireHOL service list i

Services starting with I

iax - Inter-Asterisk eXchange
iax2 - Inter-Asterisk eXchange v2
icmp - Internet Control Message Protocol
ICMP - Internet Control Message Protocol
ICMPV6 - Internet Control Message Protocol v6
icmpv6 - Internet Control Message Protocol v6
icp - Internet Cache Protocol
ident - Identification Protocol
imap - Internet Message Access Protocol
imaps - Secure Internet Message Access Protocol
ipsecnatt - NAT traversal and IPsec
ipv6error - ICMPv6 Error Handling
ipv6neigh - IPv6 Neighbour discovery
ipv6router - IPv6 Router discovery
irc - Internet Relay Chat
isakmp - Internet Security Association and Key Management Protocol (IKE)

iax - Inter-Asterisk eXchange

Example

Configuration sample:

server iax accept

Service Type

simple

Server Ports

udp/5036

Client Ports

default

Links

Homepage, Wikipedia

Notes

This service refers to IAX version 1. There is also iax2 - Inter-Asterisk eXchange v2 .

iax2 - Inter-Asterisk eXchange v2

Example

Configuration sample:

server iax2 accept

Service Type

simple

Server Ports

udp/5469 udp/4569

Client Ports

default

Links

Homepage, Wikipedia

Notes

This service refers to IAX version 2. There is also iax - Inter-Asterisk eXchange .

icmp - Internet Control Message Protocol

Alias

See ICMP - Internet Control Message Protocol

ICMP - Internet Control Message Protocol

Example

Configuration sample:

server ICMP accept

Service Type

simple

Server Ports

icmp/any

Client Ports

any

Links

Wikipedia

ICMPV6 - Internet Control Message Protocol v6

Example

Configuration sample:

server ICMPV6 accept

Service Type

simple

Server Ports

icmpv6/any

Client Ports

any

Links

Wikipedia

icmpv6 - Internet Control Message Protocol v6

Alias

See ICMPV6 - Internet Control Message Protocol v6

icp - Internet Cache Protocol

Example

Configuration sample:

server icp accept

Service Type

simple

Server Ports

udp/3130

Client Ports

3130

Links

Wikipedia

ident - Identification Protocol

Example

Configuration sample:

server ident reject with tcp-reset

Service Type

simple

Server Ports

tcp/113

Client Ports

default

Links

Wikipedia

imap - Internet Message Access Protocol

Example

Configuration sample:

server imap accept

Service Type

simple

Server Ports

tcp/143

Client Ports

default

Links

Wikipedia

imaps - Secure Internet Message Access Protocol

Example

Configuration sample:

server imaps accept

Service Type

simple

Server Ports

tcp/993

Client Ports

default

Links

Wikipedia

ipsecnatt - NAT traversal and IPsec

Service Type

simple

Server Ports

udp/4500

Client Ports

any

Links

Wikipedia

ipv6error - ICMPv6 Error Handling

Example

Configuration sample:

server ipv6error accept

Service Type

complex

Server Ports

N/A

Client Ports

N/A

Notes

Not all icmpv6 error types should be treated equally inbound and outbound.

The ipv6error rule wraps all of them in the following way:

allow incoming messages only for existing sessions
allow outgoing messages always

The following ICMPv6 messages are handled:

destination-unreachable
packet-too-big
ttl-zero-during-transit
ttl-zero-during-reassembly
unknown-header-type
unknown-option

Interfaces should always have this set:

server ipv6error accept

In a router with inface being internal and outface being external the following will meet the recommendations of RFC 4890:

server ipv6error accept

Do not use:

client ipv6error accept

unless you are controlling traffic on a router interface where outface is the internal destination.

This service implicitly sets its client or server to ipv6 mode.

ipv6neigh - IPv6 Neighbour discovery

Example

Configuration sample:

client ipv6neigh accept
server ipv6neigh accept

Service Type

complex

Server Ports

N/A

Client Ports

N/A

Links

Wikipedia

Notes

IPv6 uses the Neighbour Discovery Protocol to do automatic configuration of routes and to replace ARP. To allow this functionality the network neighbour and router solicitation/advertisement messages should be enabled on each interface.

These rules are stateless since advertisement can happen automatically as well as on solicitation.

Neighbour discovery (incoming) should always be enabled:

server ipv6neigh accept

Neighbour advertisement (outgoing) should always be enabled:

client ipv6neigh accept

The rules should not be used to pass packets across a firewall (e.g. in a router definition) unless the firewall is for a bridge.

This service implicitly sets its client or server to ipv6 mode.

ipv6router - IPv6 Router discovery

Example

Configuration sample:

client ipv6router accept

Service Type

complex

Server Ports

N/A

Client Ports

N/A

Links

Wikipedia

Notes

IPv6 uses the Neighbour Discovery Protocol to do automatic configuration of routes and to replace ARP. To allow this functionality the network neighbour and router solicitation/advertisement messages should be enabled on each interface.

These rules are stateless since advertisement can happen automatically as well as on solicitation.

Router discovery (incoming) should always be enabled:

client ipv6router accept

Router advertisement (outgoing) should be enabled on a host that routes:

server ipv6router accept

The rules should not be used to pass packets across a firewall (e.g. in a router definition) unless the firewall is for a bridge.

This service implicitly sets its client or server to ipv6 mode.

irc - Internet Relay Chat

Example

Configuration sample:

server irc accept

Service Type

simple

Server Ports

tcp/6667

Client Ports

default

Netfilter Modules

nf_conntrack_irc (CONFIG_NF_CONNTRACK_IRC)

Netfilter NAT Modules

nf_nat_irc (CONFIG_NF_NAT_IRC)

Links

Wikipedia

isakmp - Internet Security Association and Key Management Protocol (IKE)

Example

Configuration sample:

server isakmp accept

Service Type

simple

Server Ports

udp/500

Client Ports

any

Links

Wikipedia

Notes

For more information see the Archive of the FreeS/WAN documentation


Name

firehol-services-j — FireHOL service list j

Services starting with J

jabber - Extensible Messaging and Presence Protocol
jabberd - Extensible Messaging and Presence Protocol (Server)

jabber - Extensible Messaging and Presence Protocol

Example

Configuration sample:

server jabber accept

Service Type

simple

Server Ports

tcp/5222 tcp/5223

Client Ports

default

Links

Wikipedia

Notes

Allows clear and SSL client-to-server connections.

jabberd - Extensible Messaging and Presence Protocol (Server)

Example

Configuration sample:

server jabberd accept

Service Type

simple

Server Ports

tcp/5222 tcp/5223 tcp/5269

Client Ports

default

Links

Wikipedia

Notes

Allows clear and SSL client-to-server and server-to-server connections.

Use this service for a jabberd server. In all other cases, use the jabber - Extensible Messaging and Presence Protocol .


Name

firehol-services-k — FireHOL service list k

Services starting with K

Currently no services start with K


Name

firehol-services-l — FireHOL service list l

Services starting with L

l2tp - Layer 2 Tunneling Protocol
ldap - Lightweight Directory Access Protocol
ldaps - Secure Lightweight Directory Access Protocol
lpd - Line Printer Daemon Protocol

l2tp - Layer 2 Tunneling Protocol

Service Type

simple

Server Ports

udp/1701

Client Ports

any

Links

Wikipedia

ldap - Lightweight Directory Access Protocol

Example

Configuration sample:

server ldap accept

Service Type

simple

Server Ports

tcp/389

Client Ports

default

Links

Wikipedia

ldaps - Secure Lightweight Directory Access Protocol

Example

Configuration sample:

server ldaps accept

Service Type

simple

Server Ports

tcp/636

Client Ports

default

Links

Wikipedia

lpd - Line Printer Daemon Protocol

Example

Configuration sample:

server lpd accept

Service Type

simple

Server Ports

tcp/515

Client Ports

any

Links

Wikipedia

Notes

LPD is documented in RFC 1179.

Since many operating systems incorrectly use the non-default client ports for LPD access, this definition allows any client port to access the service (in addition to the RFC defined 721 to 731 inclusive).


Name

firehol-services-m — FireHOL service list m

Services starting with M

microsoft_ds - Direct Hosted (NETBIOS-less) SMB
mms - Microsoft Media Server
msn - Microsoft MSN Messenger Service
msnp - msnp
ms_ds - Direct Hosted (NETBIOS-less) SMB
multicast - Multicast
mysql - MySQL

microsoft_ds - Direct Hosted (NETBIOS-less) SMB

Example

Configuration sample:

server microsoft_ds accept

Service Type

simple

Server Ports

tcp/445

Client Ports

default

Notes

Direct Hosted (i.e. NETBIOS-less SMB)

This is another NETBIOS Session Service with minor differences with netbios_ssn - NETBIOS Session Service . It is supported only by Windows 2000 and Windows XP and it offers the advantage of being independent of WINS for name resolution.

It seems that samba supports transparently this protocol on the netbios_ssn - NETBIOS Session Service ports, so that either direct hosted or traditional SMB can be served simultaneously.

Please refer to the netbios_ssn - NETBIOS Session Service for more information.

mms - Microsoft Media Server

Example

Configuration sample:

server mms accept

Service Type

simple

Server Ports

tcp/1755 udp/1755

Client Ports

default

Netfilter Modules

See here.

Netfilter NAT Modules

See here.

Links

Wikipedia

Notes

Microsoft's proprietary network streaming protocol used to transfer unicast data in Windows Media Services (previously called NetShow Services).

msn - Microsoft MSN Messenger Service

Example

Configuration sample:

server msn accept

Service Type

simple

Server Ports

tcp/1863 udp/1863

Client Ports

default

msnp - msnp

Example

Configuration sample:

server msnp accept

Service Type

simple

Server Ports

tcp/6891

Client Ports

default

ms_ds - Direct Hosted (NETBIOS-less) SMB

Alias

See microsoft_ds - Direct Hosted (NETBIOS-less) SMB

multicast - Multicast

Example

Configuration sample:

server multicast reject with proto-unreach

Service Type

complex

Server Ports

N/A

Client Ports

N/A

Links

Wikipedia

Notes

The multicast service matches all packets sent to the $MULTICAST_IPS addresses using IGMP or UDP. For IPv4 that means 224.0.0.0/4 and for IPv6 FF00::/16.

mysql - MySQL

Example

Configuration sample:

server mysql accept

Service Type

simple

Server Ports

tcp/3306

Client Ports

default

Links

Homepage, Wikipedia


Name

firehol-services-n — FireHOL service list n

Services starting with N

netbackup - Veritas NetBackup service
netbios_dgm - NETBIOS Datagram Distribution Service
netbios_ns - NETBIOS Name Service
netbios_ssn - NETBIOS Session Service
nfs - Network File System
nis - Network Information Service
nntp - Network News Transfer Protocol
nntps - Secure Network News Transfer Protocol
nrpe - Nagios NRPE
ntp - Network Time Protocol
nut - Network UPS Tools
nxserver - NoMachine NX Server

netbackup - Veritas NetBackup service

Example

Configuration sample:

server netbackup accept
client netbackup accept

Service Type

simple

Server Ports

tcp/13701 tcp/13711 tcp/13720 tcp/13721 tcp/13724 tcp/13782 tcp/13783

Client Ports

any

Links

Wikipedia

Notes

To use this service you must define it as both client and server in NetBackup clients and NetBackup servers.

netbios_dgm - NETBIOS Datagram Distribution Service

Example

Configuration sample:

server netbios_dgm accept

Service Type

simple

Server Ports

udp/138

Client Ports

any

Links

Wikipedia

Notes

See also the samba - Samba .

Keep in mind that this service broadcasts (to the broadcast address of your LAN) UDP packets. If you place this service within an interface that has a dst parameter, remember to include (in the dst parameter) the broadcast address of your LAN too.

netbios_ns - NETBIOS Name Service

Example

Configuration sample:

server netbios_ns accept

Service Type

simple

Server Ports

udp/137

Client Ports

any

Links

Wikipedia

Notes

See also the samba - Samba .

netbios_ssn - NETBIOS Session Service

Example

Configuration sample:

server netbios_ssn accept

Service Type

simple

Server Ports

tcp/139

Client Ports

default

Links

Wikipedia

Notes

See also the samba - Samba .

Please keep in mind that newer NETBIOS clients prefer to use port 445 (microsoft_ds - Direct Hosted (NETBIOS-less) SMB ) for the NETBIOS session service, and when this is not available they fall back to port 139 (netbios_ssn). Versions of samba above 3.x bind automatically to ports 139 and 445.

If you have an older samba version and your policy on an interface or router is DROP, clients trying to access port 445 will have to timeout before falling back to port 139. This timeout can be up to several minutes.

To overcome this problem you can explicitly REJECT the microsoft_ds - Direct Hosted (NETBIOS-less) SMB with a tcp-reset message:

server microsoft_ds reject with tcp-reset

nfs - Network File System

Example

Configuration sample:

client nfs accept dst 192.0.2.1

Service Type

complex

Server Ports

many

Client Ports

N/A

Links

Wikipedia

Notes

The NFS service queries the RPC service on the NFS server host to find out the ports nfsd, mountd, lockd and rquotad are listening. Then, according to these ports it sets up rules on all the supported protocols (as reported by RPC) in order the clients to be able to reach the server.

For this reason, the NFS service requires that:

the firewall is restarted if the NFS server is restarted
the NFS server must be specified on all nfs statements (only if it is not the localhost)

Since NFS queries the remote RPC server, it is required to also be allowed to do so, by allowing the portmap - Open Network Computing Remote Procedure Call - Port Mapper too. Take care that this is allowed by the running firewall when FireHOL tries to query the RPC server. So you might have to setup NFS in two steps: First add the portmap service and activate the firewall, then add the NFS service and restart the firewall.

To avoid this you can setup your NFS server to listen on pre-defined ports, as documented in NFS Howto. If you do this then you will have to define the the ports using the procedure described in the section called “Adding Services” of FireHOL configuration: firehol.conf(5).

nis - Network Information Service

Example

Configuration sample:

client nis accept dst 192.0.2.1

Service Type

complex

Server Ports

many

Client Ports

N/A

Links

Wikipedia

Notes

The nis service queries the RPC service on the nis server host to find out the ports ypserv and yppasswdd are listening. Then, according to these ports it sets up rules on all the supported protocols (as reported by RPC) in order the clients to be able to reach the server.

For this reason, the nis service requires that:

the firewall is restarted if the nis server is restarted
the nis server must be specified on all nis statements (only if it is not the localhost)

Since nis queries the remote RPC server, it is required to also be allowed to do so, by allowing the portmap - Open Network Computing Remote Procedure Call - Port Mapper too. Take care that this is allowed by the running firewall when FireHOL tries to query the RPC server. So you might have to setup nis in two steps: First add the portmap service and activate the firewall, then add the nis service and restart the firewall.

This service was added to FireHOL by Carlos Rodrigues. His comments regarding this implementation, are:

These rules work for client access only!

Pushing changes to slave servers won't work if these rules are active somewhere between the master and its slaves, because it is impossible to predict the ports where yppush will be listening on each push.

Pulling changes directly on the slaves will work, and could be improved performance-wise if these rules are modified to open fypxfrd. This wasn't done because it doesn't make that much sense since pushing changes on the master server is the most common, and recommended, way to replicate maps.

nntp - Network News Transfer Protocol

Example

Configuration sample:

server nntp accept

Service Type

simple

Server Ports

tcp/119

Client Ports

default

Links

Wikipedia

nntps - Secure Network News Transfer Protocol

Example

Configuration sample:

server nntps accept

Service Type

simple

Server Ports

tcp/563

Client Ports

default

Links

Wikipedia

nrpe - Nagios NRPE

Service Type

simple

Server Ports

tcp/5666

Client Ports

default

Links

Wikipedia

ntp - Network Time Protocol

Example

Configuration sample:

server ntp accept

Service Type

simple

Server Ports

udp/123 tcp/123

Client Ports

any

Links

Wikipedia

nut - Network UPS Tools

Example

Configuration sample:

server nut accept

Service Type

simple

Server Ports

tcp/3493 udp/3493

Client Ports

default

Links

Homepage

nxserver - NoMachine NX Server

Example

Configuration sample:

server nxserver accept

Service Type

simple

Server Ports

tcp/5000:5200

Client Ports

default

Links

Wikipedia

Notes

Default ports used by NX server for connections without encryption.

Note that nxserver also needs the ssh - Secure Shell Protocol to be enabled.

This information has been extracted from this The TCP ports used by nxserver are 4000 + DISPLAY_BASE to 4000 + DISPLAY_BASE + DISPLAY_LIMIT. DISPLAY_BASE and DISPLAY_LIMIT are set in /usr/NX/etc/node.conf and the defaults are DISPLAY_BASE=1000 and DISPLAY_LIMIT=200.

For encrypted nxserver sessions, only ssh - Secure Shell Protocol is needed.


Name

firehol-services-o — FireHOL service list o

Services starting with O

openvpn - OpenVPN
oracle - Oracle Database
OSPF - Open Shortest Path First

openvpn - OpenVPN

Service Type

simple

Server Ports

tcp/1194 udp/1194

Client Ports

default

Links

Homepage, Wikipedia

oracle - Oracle Database

Example

Configuration sample:

server oracle accept

Service Type

simple

Server Ports

tcp/1521

Client Ports

default

Links

Wikipedia

OSPF - Open Shortest Path First

Example

Configuration sample:

server OSPF accept

Service Type

simple

Server Ports

89/any

Client Ports

any

Links

Wikipedia


Name

firehol-services-p — FireHOL service list p

Services starting with P

ping - Ping (ICMP echo)
pop3 - Post Office Protocol
pop3s - Secure Post Office Protocol
portmap - Open Network Computing Remote Procedure Call - Port Mapper
postgres - PostgreSQL
pptp - Point-to-Point Tunneling Protocol
privoxy - Privacy Proxy

ping - Ping (ICMP echo)

Example

Configuration sample:

server ping accept

Service Type

complex

Server Ports

N/A

Client Ports

N/A

Links

Wikipedia

Notes

This services matches requests of protocol ICMP and type echo-request (TYPE=8) and their replies of type echo-reply (TYPE=0).

The ping service is stateful.

pop3 - Post Office Protocol

Example

Configuration sample:

server pop3 accept

Service Type

simple

Server Ports

tcp/110

Client Ports

default

Links

Wikipedia

pop3s - Secure Post Office Protocol

Example

Configuration sample:

server pop3s accept

Service Type

simple

Server Ports

tcp/995

Client Ports

default

Links

Wikipedia

portmap - Open Network Computing Remote Procedure Call - Port Mapper

Example

Configuration sample:

server portmap accept

Service Type

simple

Server Ports

udp/111 tcp/111

Client Ports

any

Links

Wikipedia

postgres - PostgreSQL

Example

Configuration sample:

server postgres accept

Service Type

simple

Server Ports

tcp/5432

Client Ports

default

Links

Wikipedia

pptp - Point-to-Point Tunneling Protocol

Example

Configuration sample:

server pptp accept

Service Type

simple

Server Ports

tcp/1723

Client Ports

default

Netfilter Modules

nf_conntrack_pptp (CONFIG_NF_CONNTRACK_PPTP), nf_conntrack_proto_gre (CONFIG_NF_CT_PROTO_GRE)

Netfilter NAT Modules

nf_nat_pptp (CONFIG_NF_NAT_PPTP), nf_nat_proto_gre (CONFIG_NF_NAT_PROTO_GRE)

Links

Wikipedia

privoxy - Privacy Proxy

Example

Configuration sample:

server privoxy accept

Service Type

simple

Server Ports

tcp/8118

Client Ports

default

Links

Homepage


Name

firehol-services-q — FireHOL service list q

Services starting with Q

Currently no services start with Q


Name

firehol-services-r — FireHOL service list r

Services starting with R

radius - Remote Authentication Dial In User Service (RADIUS)
radiusold - Remote Authentication Dial In User Service (RADIUS)
radiusoldproxy - Remote Authentication Dial In User Service (RADIUS)
radiusproxy - Remote Authentication Dial In User Service (RADIUS)
rdp - Remote Desktop Protocol
rndc - Remote Name Daemon Control
rsync - rsync protocol
rtp - Real-time Transport Protocol

radius - Remote Authentication Dial In User Service (RADIUS)

Example

Configuration sample:

server radius accept

Service Type

simple

Server Ports

udp/1812 udp/1813

Client Ports

default

Links

Wikipedia

radiusold - Remote Authentication Dial In User Service (RADIUS)

Example

Configuration sample:

server radiusold accept

Service Type

simple

Server Ports

udp/1645 udp/1646

Client Ports

default

Links

Wikipedia

radiusoldproxy - Remote Authentication Dial In User Service (RADIUS)

Example

Configuration sample:

server radiusoldproxy accept

Service Type

simple

Server Ports

udp/1647

Client Ports

default

Links

Wikipedia

radiusproxy - Remote Authentication Dial In User Service (RADIUS)

Example

Configuration sample:

server radiusproxy accept

Service Type

simple

Server Ports

udp/1814

Client Ports

default

Links

Wikipedia

rdp - Remote Desktop Protocol

Example

Configuration sample:

server rdp accept

Service Type

simple

Server Ports

tcp/3389

Client Ports

default

Links

Wikipedia

Notes

Remote Desktop Protocol is also known also as Terminal Services.

rndc - Remote Name Daemon Control

Example

Configuration sample:

server rndc accept

Service Type

simple

Server Ports

tcp/953

Client Ports

default

Links

Wikipedia

rsync - rsync protocol

Example

Configuration sample:

server rsync accept

Service Type

simple

Server Ports

tcp/873 udp/873

Client Ports

default

Links

Homepage, Wikipedia

rtp - Real-time Transport Protocol

Example

Configuration sample:

server rtp accept

Service Type

simple

Server Ports

udp/10000:20000

Client Ports

any

Links

Wikipedia

Notes

RTP ports are generally all the UDP ports. This definition narrows down RTP ports to UDP 10000 to 20000.


Name

firehol-services-s — FireHOL service list s

Services starting with S

samba - Samba
sane - SANE Scanner service
sip - Session Initiation Protocol
smtp - Simple Mail Transport Protocol
smtps - Secure Simple Mail Transport Protocol
snmp - Simple Network Management Protocol
snmptrap - SNMP Trap
socks - SOCKet Secure
squid - Squid Web Cache
ssh - Secure Shell Protocol
stun - Session Traversal Utilities for NAT
submission - SMTP over SSL/TLS submission
sunrpc - Open Network Computing Remote Procedure Call - Port Mapper
swat - Samba Web Administration Tool
syslog - Syslog Remote Logging Protocol

samba - Samba

Example

Configuration sample:

server samba accept

Service Type

complex

Server Ports

many

Client Ports

default

Links

Homepage, Wikipedia

Notes

The samba service automatically sets all the rules for netbios_ns - NETBIOS Name Service , netbios_dgm - NETBIOS Datagram Distribution Service , netbios_ssn - NETBIOS Session Service and microsoft_ds - Direct Hosted (NETBIOS-less) SMB .

Please refer to the notes of the above services for more information.

NETBIOS initiates based on the broadcast address of an interface (request goes to broadcast address) but the server responds from its own IP address. This makes the "server samba accept" statement drop the server reply, because of the way the iptables connection tracker works.

This service definition includes a hack, that allows a Linux samba server to respond correctly in such situations, by allowing new outgoing connections from the well known netbios_ns - NETBIOS Name Service port to the clients high ports.

However, for clients and routers this hack is not applied because it would open all unprivileged ports to the samba server. The only solution to overcome the problem in such cases (routers or clients) is to build a trust relationship between the samba servers and clients.

sane - SANE Scanner service

Service Type

simple

Server Ports

tcp/6566

Client Ports

default

Netfilter Modules

nf_conntrack_sane (CONFIG_NF_CONNTRACK_SANE)

Netfilter NAT Modules

N/A

Links

Homepage

sip - Session Initiation Protocol

Example

Configuration sample:

server sip accept

Service Type

simple

Server Ports

udp/5060

Client Ports

5060 default

Netfilter Modules

nf_conntrack_sip (CONFIG_NF_CONNTRACK_SIP)

Netfilter NAT Modules

nf_nat_sip (CONFIG_NF_NAT_SIP)

Links

Wikipedia

Notes

SIP is an IETF standard protocol (RFC 2543) for initiating interactive user sessions involving multimedia elements such as video, voice, chat, gaming, etc. SIP works in the application layer of the OSI communications model.

smtp - Simple Mail Transport Protocol

Example

Configuration sample:

server smtp accept

Service Type

simple

Server Ports

tcp/25

Client Ports

default

Links

Wikipedia

smtps - Secure Simple Mail Transport Protocol

Example

Configuration sample:

server smtps accept

Service Type

simple

Server Ports

tcp/465

Client Ports

default

Links

Wikipedia

snmp - Simple Network Management Protocol

Example

Configuration sample:

server snmp accept

Service Type

simple

Server Ports

udp/161

Client Ports

default

Links

Wikipedia

snmptrap - SNMP Trap

Example

Configuration sample:

server snmptrap accept

Service Type

simple

Server Ports

udp/162

Client Ports

any

Links

Wikipedia

Notes

An SNMP trap is a notification from an agent to a manager.

socks - SOCKet Secure

Example

Configuration sample:

server socks accept

Service Type

simple

Server Ports

tcp/1080 udp/1080

Client Ports

default

Links

Wikipedia

Notes

See also RFC 1928.

squid - Squid Web Cache

Example

Configuration sample:

server squid accept

Service Type

simple

Server Ports

tcp/3128

Client Ports

default

Links

Homepage, Wikipedia

ssh - Secure Shell Protocol

Example

Configuration sample:

server ssh accept

Service Type

simple

Server Ports

tcp/22

Client Ports

default

Links

Wikipedia

stun - Session Traversal Utilities for NAT

Example

Configuration sample:

server stun accept

Service Type

simple

Server Ports

udp/3478 udp/3479

Client Ports

any

Links

Wikipedia

Notes

STUN is a protocol for assisting devices behind a NAT firewall or router with their packet routing.

submission - SMTP over SSL/TLS submission

Example

Configuration sample:

server submission accept

Service Type

simple

Server Ports

tcp/587

Client Ports

default

Links

Wikipedia

Notes

Submission is essentially normal SMTP with an SSL/TLS negotiation.

sunrpc - Open Network Computing Remote Procedure Call - Port Mapper

Alias

See portmap - Open Network Computing Remote Procedure Call - Port Mapper

swat - Samba Web Administration Tool

Example

Configuration sample:

server swat accept

Service Type

simple

Server Ports

tcp/901

Client Ports

default

Links

Homepage

syslog - Syslog Remote Logging Protocol

Example

Configuration sample:

server syslog accept

Service Type

simple

Server Ports

udp/514

Client Ports

syslog default

Links

Wikipedia


Name

firehol-services-t — FireHOL service list t

Services starting with T

telnet - Telnet
tftp - Trivial File Transfer Protocol
time - Time Protocol
timestamp - ICMP Timestamp
tomcat - HTTP alternate port

telnet - Telnet

Example

Configuration sample:

server telnet accept

Service Type

simple

Server Ports

tcp/23

Client Ports

default

Links

Wikipedia

tftp - Trivial File Transfer Protocol

Example

Configuration sample:

server tftp accept

Service Type

simple

Server Ports

udp/69

Client Ports

default

Netfilter Modules

nf_conntrack_tftp (CONFIG_NF_CONNTRACK_TFTP)

Netfilter NAT Modules

nf_nat_tftp (CONFIG_NF_NAT_TFTP)

Links

Wikipedia

time - Time Protocol

Example

Configuration sample:

server time accept

Service Type

simple

Server Ports

tcp/37 udp/37

Client Ports

default

Links

Wikipedia

timestamp - ICMP Timestamp

Example

Configuration sample:

server timestamp accept

Service Type

complex

Server Ports

N/A

Client Ports

N/A

Links

Wikipedia

Notes

This services matches requests of protocol ICMP and type timestamp-request (TYPE=13) and their replies of type timestamp-reply (TYPE=14).

The timestamp service is stateful.

tomcat - HTTP alternate port

Alias

See httpalt - HTTP alternate port


Name

firehol-services-u — FireHOL service list u

Services starting with U

upnp - Universal Plug and Play
uucp - Unix-to-Unix Copy

upnp - Universal Plug and Play

Example

Configuration sample:

server upnp accept

Service Type

simple

Server Ports

udp/1900 tcp/2869

Client Ports

default

Links

Homepage, Wikipedia

Notes

For a Linux implementation see: Linux IGD.

uucp - Unix-to-Unix Copy

Example

Configuration sample:

server uucp accept

Service Type

simple

Server Ports

tcp/540

Client Ports

default

Links

Wikipedia


Name

firehol-services-v — FireHOL service list v

Services starting with V

vmware - vmware
vmwareauth - vmwareauth
vmwareweb - vmwareweb
vnc - Virtual Network Computing

vmware - vmware

Example

Configuration sample:

server vmware accept

Service Type

simple

Server Ports

tcp/902

Client Ports

default

Notes

Used from VMWare 1 and up. See the VMWare KnowledgeBase.

vmwareauth - vmwareauth

Example

Configuration sample:

server vmwareauth accept

Service Type

simple

Server Ports

tcp/903

Client Ports

default

Notes

Used from VMWare 1 and up. See the VMWare KnowledgeBase.

vmwareweb - vmwareweb

Example

Configuration sample:

server vmwareweb accept

Service Type

simple

Server Ports

tcp/8222 tcp/8333

Client Ports

default

Notes

Used from VMWare 2 and up. See VMWare Server 2.0 release notes and the VMWare KnowledgeBase.

vnc - Virtual Network Computing

Example

Configuration sample:

server vnc accept

Service Type

simple

Server Ports

tcp/5900:5903

Client Ports

default

Links

Wikipedia

Notes

VNC is a graphical desktop sharing protocol.


Name

firehol-services-w — FireHOL service list w

Services starting with W

webcache - HTTP alternate port
webmin - Webmin Administration System
whois - WHOIS Protocol

webcache - HTTP alternate port

Alias

See httpalt - HTTP alternate port

webmin - Webmin Administration System

Example

Configuration sample:

server webmin accept

Service Type

simple

Server Ports

tcp/10000

Client Ports

default

Links

Homepage

whois - WHOIS Protocol

Example

Configuration sample:

server whois accept

Service Type

simple

Server Ports

tcp/43

Client Ports

default

Links

Wikipedia


Name

firehol-services-x — FireHOL service list x

Services starting with X

xbox - Xbox Live
xdmcp - X Display Manager Control Protocol

xbox - Xbox Live

Example

Configuration sample:

client xbox accept

Service Type

complex

Server Ports

many

Client Ports

default

Notes

Definition for the Xbox live service.

See program source for contributor details.

xdmcp - X Display Manager Control Protocol

Example

Configuration sample:

server xdmcp accept

Service Type

simple

Server Ports

udp/177

Client Ports

default

Links

Wikipedia

Notes

See Gnome Display Manager for a discussion about XDMCP and firewalls (Gnome Display Manager is a replacement for XDM).


Name

firehol-services-y — FireHOL service list y

Services starting with Y

Currently no services start with Y


Name

firehol-services-z — FireHOL service list z

Services starting with Z

Currently no services start with Z

Part IV. FireQOS Reference

Table of Contents

VIII. Running and Configuring
FireQOS program: fireqos — an easy to use but powerful traffic shaping tool
FireQOS configuration: fireqos.conf — FireQOS configuration file
IX. Organising Traffic
interface definition: fireqos-interface — create an interface definition
traffic class: fireqos-class — define a traffic class
traffic match: fireqos-match — define a traffic match
X. Optional Parameters
class/match parameters: fireqos-shared-params — class/match parameters
optional class parameters: fireqos-class-params — optional class parameters
optional match parameters: fireqos-match-params — optional match parameters

Running and Configuring


Table of Contents

FireQOS program: fireqos — an easy to use but powerful traffic shaping tool
FireQOS configuration: fireqos.conf — FireQOS configuration file

Name

fireqos — an easy to use but powerful traffic shaping tool

Synopsis

fireqos CONFIGFILE [ start | debug ] [ -- conf-arg... ]

fireqos { stop | clear_all_qos }

fireqos status [ name [ dump [class] ] ]

fireqos { dump | tcpdump } name class [ tcpdump-arg ... ]

fireqos { drops | overlimits | requeues } name

Description

FireQOS is a helper to assist you configure traffic shaping on Linux.

Run without any arguments, fireqos will present some help on usage.

When given CONFIGFILE, fireqos will use the named file instead of /etc/firehol/fireqos.conf as its configuration.

The parameter name always refers to and interface name from the configuration file. The parameter class always refers to a named class within a named interface.

It is possible to pass arguments for use by the configuration file separating any conf-arg values from the rest of the arguments with --. The arguments are accessible in the configuration using standard bash(1) syntax e.g. $1, $2, etc.

Commands

start, debug

Activates traffic shaping on all interfaces, as given in the configuration file. When invoked as debug, FireQOS also prints all of the tc(8) commands it executes.

stop

Removes all traffic shaping applied by FireQOS (it does not touch QoS on other interfaces and IFBs used by other tools).

clear_all_qos

Removes all traffic shaping on all network interfaces and removes all IFB devices from the system, even those applied by other tools.

status

Shows live utilisation for the specified interface. FireQOS will show you the rate of traffic on all classes, adding one line per second (similarly to vmstat, iostat, etc.)

If dump is specified, it tcpdumps the traffic in the given class of the interface.

tcpdump, dump

FireQOS temporarily mirrors the traffic of any leaf class to an IFB device. Then it runs tcpdump on this interface to dump the traffic to your console.

You may add any tcpdump parameters you like to the command line, (to dump the traffic to a file, match a subset of the traffic, etc.), for example this:

fireqos tcpdump adsl-in voip -n

will start a tcpdump of all traffic on interface adsl-in, in class voip. The parameter -n is a tcpdump parameter.

Note

When FireQOS is running in tcpdump mode, it locks itself and will refuse to run in parallel with another FireQOS altering the QoS, or tcpdumping other traffic. This is because FireQOS reserves device ifb0 for monitoring. If two FireQOS processes were allowed to tcpdump in parallel, your dumps would be wrong. So it locks itself to prevent such a case.

drops

Shows packets dropped per second, per class, for the specified interface.

overlimits

Shows packets delayed per second, per class, for the specified interface.

requeues

Shows packets requeued per second, per class, for the specified interface.

Files

/etc/firehol/fireqos.conf

Name

fireqos.conf — FireQOS configuration file

Description

This file defines the traffic shaping that will be applied by FireQOS program: fireqos(1).

The default configuration file is /etc/firehol/fireqos.conf. It can be overridden from the command line.

A configuration consists of a number of input and output interface definitions (see interface definition: fireqos-interface(5)). Each interface can define any number of (optionally nested) classes (see traffic class: fireqos-class(5)) which shape the traffic which they match (see traffic match: fireqos-match(5)).

Speed Units

In FireQOS, speeds can be expressed in the following units:

#bps

# bytes per second

#kbps, #Kbps

# kilobytes per second

#mbps, #Mbps

# megabytes per second

#gbps, #Gbps

# gigabytes per second

#bit

# bits per second

#kbit, #Kbit, #

# kilobits per second (default)

#mbit, #Mbit

# megabits per second

#gbit, #Gbit

# gigabits per second

#%

In a class, uses this percentage of the enclosing rate.

Note

The default, kbit is different to tc which assumes bytes per second when no unit is specified.

Example

# incoming traffic from my ADSL router
interface eth2 adsl-in input rate 10500kbit adsl remote pppoe-llc
  class voip commit 100kbit pfifo
    match udp ports 5060,10000:10100 # asterisk sip and rtp
    match udp ports 16393:16402 # apple facetime

  class realtime commit 10%
    match tcp port 22,1195:1198,1753 # ssh, openvpn, pptp
    match udp port 53 # dns
    match proto GRE
    match icmp
    match tcp syn
    match tcp ack

  class clients commit 10%
    match tcp port 20,21,25,80,143,443,465,873,993 # mail, web, ftp, etc

  # unmatched traffic goes here ('default' is a special name)
  class default max 90%

  # I define torrents beneath the default class, because I want them
  # to slow down when the default class is willing to get bandwidth
  class torrents max 90%
    match port 51414 # my torrent client

# outgoing traffic to my ADSL router
interface eth2 adsl-out output rate 800kbit adsl remote pppoe-llc
  class voip commit 100kbit pfifo
    match udp ports 5060,10000:10100 # asterisk sip and rtp
    match udp ports 16393:16402 # apple facetime

  class realtime commit 10%
    match tcp port 22,1195:1198,1753 # ssh, openvpn, pptp
    match udp port 53 # dns
    match proto GRE
    match icmp
    match tcp syn
    match tcp ack

  class clients commit 10%
    match tcp port 20,21,25,80,143,443,465,873,993 # mail, web, ftp, etc

  # unmatched traffic goes here ('default' is a special name)
  class default max 90%

  # I define torrents, beneath the default class, because I want them
  # to slow down when the default class is willing to get bandwidth
   class torrents max 90%
       match port 51414 # my torrent client
  

Organising Traffic


Table of Contents

interface definition: fireqos-interface — create an interface definition
traffic class: fireqos-class — define a traffic class
traffic match: fireqos-match — define a traffic match

Name

fireqos-interface — create an interface definition

Synopsis

interface|interface4 device name direction [optional-class-params] { rate | commit | min } speed

interface46 ...

interface6 ...

Description

Writing interface or interface4 applies traffic shaping rules only to IPv4 traffic.

Writing interface6 applies traffic shaping rules only to IPv6 traffic.

Writing interface46 applies traffic shaping rules to both IPv4 and IPv6 traffic.

The actual traffic shaping behaviour of a class is defined by adding classes. See traffic class: fireqos-class(5).

Note

To achieve best results with incoming traffic shaping, you should not use 100% of the available bandwidth at the interface level.

If you use all there is, at 100% utilisation of the link, the neighbour routers will start queuing packets. This will destroy prioritisation. Try 85% or 90% instead.

Parameters

device

This is the interface name as shown by ip link show (e.g. eth0, ppp1, etc.)

name

This is a single-word name for this interface and is used for retrieving status information later.

direction

If set to input, traffic coming in to the interface is shaped.

If set to output, traffic going out via the interface is shaped.

optional-class-params

For a list of optional class parameters which can be applied to an interface, see optional class parameters: fireqos-class-params(5).

speed

For an interface, the committed speed must be specified with the rate option. The speed can be expressed in any of the units described in FireQOS configuration: fireqos.conf(5).

Examples

To create an input policy on eth0, capable of delivering up to 1Gbit of traffic:

interface eth0 lan-in input rate 1Gbit
    


Name

fireqos-class — define a traffic class

Synopsis

class|class4|class6|class46 [group] name [optional-class-params]

class|class4|class6|class46 group end

Description

There is also an optional match parameter called class; see optional match parameters: fireqos-match-params(5).

Writing class inherits the IPv4/IPv6 version from its enclosing interface (see interface definition: fireqos-interface(5)).

Writing class4 includes only IPv4 traffic in the class.

Writing class6 includes only IPv6 traffic in the class.

Writing class46 includes both IPv4 and IPv6 traffic in the class.

The actual traffic to be matched by a class is defined by adding matches. See traffic match: fireqos-match(5).

The sequence that classes appear in the configuration defines their priority. The first class is the most important one. Unless otherwise limited it will get all available bandwidth if it needs to.

The second class is less important than the first, the third is even less important than the second, etc. The idea is very simple: just put the classes in the order of importance to you.

Classes can have their priority assigned explicitly with the prio parameter. See optional class parameters: fireqos-class-params(5).

Note

The underlying Linux qdisc used by FireQOS, HTB, supports only 8 priorities, from 0 to 7. If you use more than 8 priorities, all after the 8th will get the same priority (prio 7).

All classes in FireQOS share the interface bandwidth. However, every class has a committed rate (the minimum guaranteed speed it will get if it needs to) and a ceiling (the maximum rate this class can reach, provided there is capacity available and even if there is spare).

Classes may be nested to any level by using the class group syntax.

By default FireQOS creates nested classes as classes directly attached to their parent class. This way, nesting does not add any delays.

FireQOS can also emulate new hardware at the group class level. This may be needed, when for example you have an ADSL router that you connect to via Ethernet: you want the LAN traffic to be at Ethernet speed, but WAN traffic at ADSL speed with proper ADSL overheads calculation.

To accomplish hardware emulation nesting, you add a linklayer definition (ethernet, adsl, atm, etc.) or just an mtu to the group class. FireQOS will create a qdisc within the class, where the linklayer parameters will be assigned and the child classes will be attached to this qdisc. This adds some delay to the packets of the child classes, but allows you to emulate new hardware. For linklayer options, see optional class parameters: fireqos-class-params(5).

There is special class, called default. Default classes can be given explicitly in the configuration file. If they are not found in the config, FireQOS will append one at the end of each interface or class group.

Parameters

group

It is possible to nest classes by using a group. Grouped classes must be closed with the class group end command.

name

This is a single-word name for this class and is used for displaying status information.

optional-class-params

The set of optional class parameters to apply to this class.

The following optional class parameters are inherited from the interface the class is in:

ceil
burst
cburst
quantum
qdisc

If you define one of these at the interface level, then all classes within the interface will get the value by default. These values can be overwritten by defining the parameter on the class too.

Optional class parameters not in the above list are not inherited from interfaces.

Examples

To create a nested class, called servers, containing http and smtp:

interface eth0 lan input rate 1Gbit
  class voip commit 1Mbit
    match udp ports 5060,10000:10100

  class group servers commit 50%  # define the parent class
    match tcp                     # apply to all child classes

    class mail commit 50%         # 50% of parent ('servers')
      match port 25               # matches within parent ('servers')

    class web commit 50%
      match port 80
  class group end                 # end the group 'servers'

  class streaming commit 30%
    

To create a nested class which emulates an ADSL modem:

interface eth0 lan output rate 1Gbit ethernet
   class lan
      match dst 192.168.0.0/24 # LAN traffic

   class group adsl rate 10Mbit ceil 10Mbit adsl remote pppoe-llc
      match all # all non-lan traffic in this emulated hardware group

      class voip # class within adsl
         match udp port 5060

      class web # class within adsl
         match tcp port 80,443
    class group end
    


Name

fireqos-match — define a traffic match

Synopsis

match|match4|match6|match46 [optional-match-params]

Description

Writing match inherits the IPv4/IPv6 version from its enclosing class (see traffic class: fireqos-class(5)).

Writing match4 includes only IPv4 traffic in the match.

Writing match6 includes only IPv6 traffic in the match.

Writing match46 includes both IPv4 and IPv6 traffic in the match.

You can add as many match statements as you like to a FireQOS configuration. They assign traffic to a class (see traffic class: fireqos-class(5)), by default to the class after which they are declared.

The sequence that matches appear in the configuration defines their priority, with the first match being given a prio of 10, with 10 added for each subsequent match (10, 20, 30, ...).

Matches can have their priority assigned explicitly with the prio parameter. See optional match parameters: fireqos-match-params(5).

If one match statement generates multiple tc filter statements, all filters generated by the same match statement will have the same prio.

Note

match rules are attached to the parent of the class they appear in. Within the configuration they are written under a class, but in reality they are attached to their class parent, so that they classify the parent's traffic that they match, into the class.

It is also possible to group all match statements together below the classes. This allows them to be arranged in preferred order, without the need for any explicit prio parameters. In this case however, each match statement must specify to which class it classifies the packets it matches, using the class parameter. See optional match parameters: fireqos-match-params(5) and the examples below.

Parameters

optional-match-params

The set of optional parameters which describe this match. See optional match parameters: fireqos-match-params(5).

Examples

Match traffic within classes:

interface eth0 lan output rate 1Gbit
  class voip
    match udp ports 5060,10000:10100
  class dns
    match udp port 53
  class mail
    match tcp port 25
    

Matches split out and explicitly assigning traffic to classes (N.B. without the class parameters, all traffic would be classified into 'mail'):

interface eth0 lan output rate 1Gbit
  class voip
  class dns
  class mail

  match udp ports 5060,10000:10100 class voip
  match tcp port 25 class mail
  match tcp port 80 class web
    

Optional Parameters


Table of Contents

class/match parameters: fireqos-shared-params — class/match parameters
optional class parameters: fireqos-class-params — optional class parameters
optional match parameters: fireqos-match-params — optional match parameters

Name

fireqos-shared-params — class/match parameters

Description

Some optional parameter names are the same for both class and match. This page exists as a placeholder to help you find the appropriate documentation.

For the class version, see optional class parameters: fireqos-class-params(5).

For the match version, see optional match parameters: fireqos-match-params(5).


Name

fireqos-class-params — optional class parameters

Synopsis

rate|commit|min speed

ceil|max speed

minrate speed

qdisc qdisc-name [ options "qdisc-options" ]
or pfifo|bfifo|sfq|fq_codel|codel|none

prio { 0..7 | keep | last }

linklayer linklayer-name
or ethernet|atm

adsl local | remote encapsulation

mtu bytes

mpu bytes

tsize size

overhead bytes

r2q factor

burst bytes

cburst bytes

quantum bytes

priority|balanced

Description

All of the options apply to interface and class statements.

Units for speeds are defined in FireQOS configuration: fireqos.conf(5).

rate speed, commit speed, min speed

When a committed rate is provided to a class, it means that the bandwidth will be given to the class when it needs it. If the class does not need the bandwidth, it will be available for any other class to use.

For interfaces, a rate must be defined.
For classes the rate defaults to 1/100 of the interface capacity.
ceil speed, max speed

Defines the maximum speed a class can use. Even there is available bandwidth, a class will not exceed its ceil speed.

For interfaces, the default is the rate speed of the interface.
For classes, the defaults is the ceil of the their interfaces.
minrate speed

Defines the default committed speed for all classes not specifically given a rate in the config file. It forces a recalculation of tc r2q.

When minrate is not given, FireQOS assigns a default value of 1/100 of the interface rate.

qdisc qdisc-name, pfifo, bfifo, sfq, fq_codel, codel, none

The qdisc defines the method to distribute class bandwidth to its sockets. It is applied within the class itself and is useful in cases where a class gets saturated. For information about these, see http://www.tldp.org/HOWTO/Traffic-Control-HOWTO/classless-qdiscs.html

A qdisc is only useful when applied to a class. It can be specified at the interface level in order to set the default for all of the included classes.

To pass options to a qdisc, you can specify them through an environment variable or explicitly on each class.

Set the variable FIREQOS_DEFAULT_QDISC_OPTIONS_qdiscname in the config file. For example, for sfq:

FIREQOS_DEFAULT_QDISC_OPTIONS_sfq="perturb 10 quantum 2000".

Using this variable each sfq will get these options by default. You can still override this by specifying explicit options for individual qdiscs.

Add options "qdisc options here". So to specify, for example, sfq options you would write:

class name sfq options "perturb 10 quantum 2000"

The options keyword must appear just after the qdisc name.

prio 0..7|keep|last

HTB supports 8 priorities, from 0 to 7. Any number less than 0 will give priority 0. Any number above 7 will give priority 7.

By default, FireQOS gives the first class priority 0, and increases this number by 1 for each class it encounters in the config file. If there are more than 8 classes, all classes after the 8th will get priority 7. In balanced mode (see priority), all classes will get priority 4 by default.

FireQOS restarts priorities for each interface and class group.

The class priority defines how the spare bandwidth is spread among the classes. Classes with higher priorities (lower prio) will get all spare bandwidth. Classes with the same priority will get a percentage of the spare bandwidth, proportional to their committed rates.

The keywords keep and last will make a class use the priority of the class just above / before it. So to make two consecutive classes have the same prio, just add prio keep to the second one.

linklayer linklayer-name, ethernet, atm

The linklayer can only be given on interfaces. It is used by the kernel to calculate the overheads in the packets.

adsl local|remote encapsulation

adsl is a special linklayer that automatically calculates ATM overheads for the link.

local is used when the ADSL modem is directly attached to your computer (for example a PCI card, or a USB modem).

remote is used when you have an ADSL router attached to an ethernet port of your computer.

When one is using PPPoE pass-through, so there is an ethernet ADSL modem (not router) and PPP is running on the Linux host, the option to choose is local.

Note

This special case has not yet been demonstrated for sure. Experiment a bit and if you find out, let us know to update this page. In practice, this parameter lets the kernel know that the packets it sees, have already an ethernet header on them.

encapsulation can be one of (all the labels on the same line are aliases):

IPoA-VC/Mux or ipoa-vcmux or ipoa-vc or ipoa-mux
IPoA-LLC/SNAP or ipoa-llcsnap or ipoa-llc or ipoa-snap
Bridged-VC/Mux or bridged-vcmux or bridged-vc or bridged-mux
Bridged-LLC/SNAP or bridged-llcsnap or bridged-llc or bridged-snap
PPPoA-VC/Mux or pppoa-vcmux or pppoa-vc or pppoa-mux
PPPoA-LLC/SNAP or pppoa-llcsnap or pppoa-llc or pppoa-snap
PPPoE-VC/Mux or pppoe-vcmux or pppoe-vc or pppoe-mux
PPPoE-LLC/SNAP or pppoe-llcsnap or pppoe-llc or pppoe-snap

If your adsl router can give you the mtu, it would be nice to add an mtu parameter too. For detailed info, see: http://ace-host.stuart.id.au/russell/files/tc/tc-atm/.

mtu bytes

Defines the MTU of the interface.

FireQOS will query the interface to find its MTU. You can overwrite this behaviour by giving this parameter to a class or interface.

mpu bytes

Defines the MPU of the interface.

FireQOS does not set a default value. You can set your own using this parameter.

tsize size

FireQOS does not set a default value. You can set your own using this parameter.

overhead bytes

FireQOS automatically calculates the overhead for ADSL. For all other technologies, you can specify the overhead in the config file.

r2q factor

FireQOS calculates the proper r2q, so that you can control speeds in steps of 1/100th of the interface speed (if that is possible).

Note

The HTB manual states that this parameter is ignored when a quantum have been set. By default, FireQOS sets quantum to interface MTU, so r2q is probably is ignored by the kernel.

burst bytes

burst is the number of bytes that will be sent at once, at ceiling speed, when a class is allowed to send traffic. It is like a 'traffic unit'. A class is allowed to send at least burst bytes before trying to serve any other class.

burst should never be lower that the interface mtu and class groups and interfaces should never have a smaller burst value than their children. If you do specify a higher burst for a child class, its parent may get stuck sometimes (the child will drain the parent).

By default, FireQOS lets the kernel decide this parameter, which calculates the lowest possible value (the minimum value depends on the rate of the interface and the clock speed of the CPU).

burst is inherited from interfaces to classes and from group classes to their subclasses. FireQOS will not allow you to set a burst at a subclass, higher than its parent. Setting a burst of a subclass higher than its parent will drain the parent class, which may be stuck for up to a minute when this happens. For this check to work, FireQOS uses just its configuration (it does not query the kernel to check how the value specified in the config file for a subclass relates to the actual value of its parent).

cburst bytes

cburst is like burst, but at hardware speed (not just ceiling speed).

By default, FireQOS lets the kernel decide this parameter.

cburst is inherited from interfaces to classes and from group classes to their subclasses. FireQOS will not allow you to set a cburst at a subclass, higher to its parent. Setting a cburst of a subclass higher than its parent, will drain the parent class, which may be stuck for up to a minute when this happens. For this check to work, FireQOS uses just its configuration (it does not query the kernel to check how the value specified in the config file for a subclass relates to the actual value of its parent).

quantum bytes

quantum is the amount of bytes a class is allowed to send at once, when it is borrowing spare bandwidth from other classes.

By default, FireQOS sets quantum to the interface mtu.

quantum is inherited from interfaces to classes and from group classes to their subclasses.

priority, balanced

These parameters set the priority mode of the child classes.

priority is the default mode, where FireQOS assigns an incremental priority to each class. In this mode, the first class takes prio 0, the second prio 1, etc. When a class has a higher prio than the others (higher = smaller number), this high priority class will get all the spare bandwidth available, when it needs it. Spare bandwidth will be allocate to lower priority classes only when the higher priority ones do not need it.

balanced mode gives prio 4 to all child classes. When multiple classes have the same prio, the spare bandwidth available is spread among them, proportionally to their committed rate. The value 4 can be overwritten by setting FIREQOS_BALANCED_PRIO at the top of the config file to the prio you want the balanced mode to assign for all classes.

The priority mode can be set in interfaces and class groups. The effect is the same. The classes that are defined as child classes, will get by default the calculated class prio based on the priority mode given.

These options affect only the default prio that will be assigned by FireQOS. The default is used only if you don't explicitly use a prio parameter on a class.


Name

fireqos-match-params — optional match parameters

Synopsis

at root | name

class name

syn|syns

ack|acks

proto|protocol protocol [,protocol...]
or tcp|udp|icmp|gre|ipv6

tos|priority tosid [,tosid...]

mark mark [,mark...]

port|ports port[:range] [,port[:range]...]

sport|sports port[:range] [,port[:range]...]

dport|dports port[:range] [,port[:range]...]

ip|net|host net [,net...]

src net [,net...]

dst net [,net...]

prio id

Description

These options apply to match statements.

at root|name

By default a match is attached to the parent of its parent class. For example, if its parent is a class directly under the interface, then the match is attached to the interface and is compared against all traffic of the interface. For nested classes, a match of a leaf, is attached to the parent class and is compared against all traffic of this parent class.

With the at parameter, a match can be attached any class. The name parameter should be a class name. The name root attaches the match to the interface.

class name

Defines the name of the class that will get the packets matched by this match.

By default it is the name of the class the match statement appears under.

syn, syns

Match TCP SYN packets. Note that the tcp parameter must be specified.

If the same match statement includes more protocols than TCP, then this match will work for the TCP packets (it will be silently ignored for all other protocols).

For example, syn is ignored when generating the UDP filter in the below:

match tcp syn
match proto tcp,udp syn

ack, acks

Same as syn, but matching TCP ACK packets.

proto protocol[,protocol...], protocol protocol[,protocol...], tcp, udp, icmp, gre, ipv6

Match the protocol in the IP header.

tos tosid[,tosid...], priority tosid[,tosid...]

Match to TOS field of ipv4 or the priority field of ipv6. id can be a value/mask in any format tc accepts, or one of the following:

min-delay, minimize-delay, minimum-delay, low-delay, interactive
maximize-throughput, maximum-throughput, max-throughput, high-throughput, bulk
maximize-reliability, maximum-reliability, max-reliability, reliable
min-cost, minimize-cost, minimum-cost, low-cost, cheap
normal-service, normal

mark mark[,mark...]

Match an iptables MARK. Matching iptables MARKs does not work on input interfaces. You can use them only on output. The IFB devices that are used for shaping inbound traffic do not have any iptables hooks to allow matching MARKs. If you try it, FireQOS will attempt to do it, but currently you will get an error from the tc command executed.

ports port[:range][,port[:range]...], sports port[:range][,port[:range]...], dports port[:range][,port[:range]...]

Match ports of the IP header. ports will create rules for matching source and destination ports (separate rules for each). dports matches destination ports, sports matches source ports.

ip net[,net...], net net[,net...], host net[,net...], src net[,net...], dst net[,net...]

Match IPs of the IP header. ip, net and host will create rules for matching source and destination IPs (separate rules for each). src matches source IPs and dst destination IPs.

Note

If the class these matches appear in are IPv4, then only IPv4 IPs can be used. To override use match6 ... src/dst IPV6_IP.

Similarly, if the class is IPv6, then only IPv6 IPs can be used. To override use match4 ... src/dst IPV4_IP.

You can mix IPv4 and IPv6 in any way you like. FireQOS supports inheritance, to figure out for each statement which is the default. For example:

interface46 eth0 lan output rate 1Gbit # ipv4 and ipv6 enabled
  class voip # ipv4 and ipv6 class, as interface is both
    match udp port 53 # ipv4 and ipv6 rule, as class is both
    match4 src 192.0.2.1 # ipv4 only rule
    match6 src 2001:db8::1 # ipv6 only rule

  class4 realtime # ipv4 only class
    match src 198.51.100.1 # ipv4 only rule, as class is ipv4-only

  class6 servers # ipv6 only class
    match src 2001:db8::2 # ipv6 only rule, as class is ipv6-only

To convert an IPv4 interface to IPv6, just replace interface with interface6. All the rules in that interface, will automatically inherit the new protocol. Of course, if you use IP addresses for matching packets, make sure they are IPv6 IPs too.

prio id

All match statements are attached to the interface. They forward traffic to their class, but they are actually executed for all packets that are leaving the interface (note: input matches are actually output matches on an IFB device).

By default, the priority they are executed, is the priority they appear in the configuration file, i.e. the first match of the first class is executed first, then the rest matches of the first class in the sequence they appear, then the matches of the second class, etc.

It is sometimes necessary to control the order of matches. For example, when you want host 192.0.2.1 to be assigned the first class, except port tcp/1234 which should be assigned the second class. The following will not work:

interface eth0 lan output rate 1Gbit
  class high
    match host 192.0.2.1

  class low
    match host 192.0.2.1 port 1234 # Will never match

In this case, the first match is assigned priority 10 and the second priority 20. The second match will never match anything, since all traffic for the host is already matched by the first one.

Setting an explicit priority allows you to change the order in which the matches are executed. FireQOS gives priority 10 to the first match of every interface, 20 to the second match, 30 to the third match, etc. So the default is 10 x the sequence number. You can set prio to overwrite this number.

To force executing the second match before the first, just set a lower priority for it. For example, this will cause the desired behaviour:

interface eth0 lan output rate 1Gbit
  class high
    match host 192.0.2.1

  class low
    match host 192.0.2.1 port 1234 prio 1 # Matches before host-only

Part V. Appendices

Table of Contents

A. ICMPv6 Firewall Recommendations
Introduction
Allow outbound echo requests from prefixes which belong to the site
Allow inbound echo requests towards only predetermined hosts
Allow incoming and outgoing echo reply messages only for existing sessions
Deny icmps to/from link local addresses
Drop echo replies which have a multicast address as a destination
Allow incoming destination unreachable messages only for existing sessions
Allow outgoing destination unreachable messages
Allow incoming Packet Too Big messages only for existing sessions
Allow outgoing Packet Too Big messages
Allow incoming time exceeded code 0 messages only for existing sessions
Allow incoming time exceeded code 1 messages
Allow outgoing time exceeded code 0 messages
Allow outgoing time exceeded code 1 messages
Allow incoming parameter problem code 1 and 2 messages for an existing session
Allow outgoing parameter problem code 1 and code 2 messages
Allow incoming and outgoing parameter problem code 0 messages
Drop NS/NA messages both incoming and outgoing
Drop RS/RA messages both incoming and outgoing
Drop Redirect messages both incoming and outgoing
Drop incoming and outgoing Multicast Listener queries (MLDv1 and MLDv2)
Drop incoming and outgoing Multicast Listener reports (MLDv1)
Drop incoming and outgoing Multicast Listener Done messages (MLDv1)
Drop incoming and outgoing Multicast Listener reports (MLDv2)
Drop router renumbering messages
Drop node information queries (139) and replies (140)
If there are mobile ipv6 home agents present on the trusted side allow
If there are roaming mobile nodes present on the trusted side allow
Drop everything else

Appendix A. ICMPv6 Firewall Recommendations

Table of Contents

Introduction
Allow outbound echo requests from prefixes which belong to the site
Allow inbound echo requests towards only predetermined hosts
Allow incoming and outgoing echo reply messages only for existing sessions
Deny icmps to/from link local addresses
Drop echo replies which have a multicast address as a destination
Allow incoming destination unreachable messages only for existing sessions
Allow outgoing destination unreachable messages
Allow incoming Packet Too Big messages only for existing sessions
Allow outgoing Packet Too Big messages
Allow incoming time exceeded code 0 messages only for existing sessions
Allow incoming time exceeded code 1 messages
Allow outgoing time exceeded code 0 messages
Allow outgoing time exceeded code 1 messages
Allow incoming parameter problem code 1 and 2 messages for an existing session
Allow outgoing parameter problem code 1 and code 2 messages
Allow incoming and outgoing parameter problem code 0 messages
Drop NS/NA messages both incoming and outgoing
Drop RS/RA messages both incoming and outgoing
Drop Redirect messages both incoming and outgoing
Drop incoming and outgoing Multicast Listener queries (MLDv1 and MLDv2)
Drop incoming and outgoing Multicast Listener reports (MLDv1)
Drop incoming and outgoing Multicast Listener Done messages (MLDv1)
Drop incoming and outgoing Multicast Listener reports (MLDv2)
Drop router renumbering messages
Drop node information queries (139) and replies (140)
If there are mobile ipv6 home agents present on the trusted side allow
If there are roaming mobile nodes present on the trusted side allow
Drop everything else

Introduction

RFC 4890 is entitled "Recommendations for Filtering ICMPv6 Messages in Firewalls".

The recommendations pertain to firewalling at router level, not necessarily hosts or bridges (which may need to treat some packets differently, e.g. NS/NA and RS/RA).

The sections below were extracted from the example implementation; each one describes how the recommendation can be achieved with FireHOL.

It is assumed that a policy of reject or deny is in place. If that is not the case then some packet types need dropping explicitly to meet the recommendations.

Allow outbound echo requests from prefixes which belong to the site

The router command (see router definition: firehol-router(5)) should be used with an appropriate src rule parameter (see optional rule parameters: firehol-rule-params(5)).

Allow inbound echo requests towards only predetermined hosts

The ping - Ping (ICMP echo) should be used in combination with an appropriate dst rule parameter (see optional rule parameters: firehol-rule-params(5)).

Allow incoming and outgoing echo reply messages only for existing sessions

This is handled automatically by the ping - Ping (ICMP echo) .

Deny icmps to/from link local addresses

The router command (see router definition: firehol-router(5)) should be used with an appropriate src and dst rule parameter (see optional rule parameters: firehol-rule-params(5)). For example:

src not "${UNROUTABLE_IPS}" dst not "${UNROUTABLE_IPS}"

Drop echo replies which have a multicast address as a destination

The ping - Ping (ICMP echo) can be used with an appropriate src rule parameter (see optional rule parameters: firehol-rule-params(5)). For example:

ipv6 route ping src not "${MULTICAST6_IPS}"

will prevent incoming echo-requests from multicast IPs and replies to them.

Allow incoming destination unreachable messages only for existing sessions

Ensure any routers have:

server ipv6error accept

Adding dst "$inner_prefix" ensures only public hosts receive the messages. See ipv6error - ICMPv6 Error Handling .

Allow outgoing destination unreachable messages

The rule(s) suggested by the section called “Allow incoming destination unreachable messages only for existing sessions” will also meet this recommendation.

Allow incoming Packet Too Big messages only for existing sessions

The rule(s) suggested by the section called “Allow incoming destination unreachable messages only for existing sessions” will also meet this recommendation.

Allow outgoing Packet Too Big messages

The rule(s) suggested by the section called “Allow incoming destination unreachable messages only for existing sessions” will also meet this recommendation.

Allow incoming time exceeded code 0 messages only for existing sessions

The rule(s) suggested by the section called “Allow incoming destination unreachable messages only for existing sessions” will also meet this recommendation.

Allow incoming time exceeded code 1 messages

The rule(s) suggested by the section called “Allow incoming destination unreachable messages only for existing sessions” will also meet this recommendation.

Note

Note: in the example RFC script, non-established/related messages are allowed through for this type.

It is not clear why since code 0 and not code 1 messages are listed as part of the establishment of communications. Code 1 messages are listed as less essential for propagation over the network.

The behaviour implemented here is as per destination unreachable messages, so the same as the incoming time exceeded code 0 messages example.

Allow outgoing time exceeded code 0 messages

The rule(s) suggested by the section called “Allow incoming destination unreachable messages only for existing sessions” will also meet this recommendation.

Allow outgoing time exceeded code 1 messages

The rule(s) suggested by the section called “Allow incoming destination unreachable messages only for existing sessions” will also meet this recommendation.

Allow incoming parameter problem code 1 and 2 messages for an existing session

The rule(s) suggested by the section called “Allow incoming destination unreachable messages only for existing sessions” will also meet this recommendation.

Allow outgoing parameter problem code 1 and code 2 messages

The rule(s) suggested by the section called “Allow incoming destination unreachable messages only for existing sessions” will also meet this recommendation.

Allow incoming and outgoing parameter problem code 0 messages

From the RFC it is not really necessary to allow these messages. FireHOL handles this automatically (by dropping them) unless you create a rule to explicitly allow the packets using the icmpv6 type bad-header.

Drop NS/NA messages both incoming and outgoing

FireHOL handles this automatically unless you set up an explicit route for the packets.

Note

Hosts and bridges need to allow these messages. See ipv6neigh - IPv6 Neighbour discovery .

Drop RS/RA messages both incoming and outgoing

FireHOL handles this automatically unless you set up an explicit route for the packets.

Note

Hosts and bridges need to allow these messages. See ipv6router - IPv6 Router discovery .

Drop Redirect messages both incoming and outgoing

FireHOL handles this automatically unless you set up an explicit route for the packets.

Note

At some point FireHOL may have a helper command added to simplify allowing these messages on a host/bridge. Meantime this is an example of the relevant ip6tables command:

ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type redirect -j DROP

Drop incoming and outgoing Multicast Listener queries (MLDv1 and MLDv2)

FireHOL handles this automatically unless you set up an explicit route for the packets.

Note

At some point FireHOL may have a helper command added to simplify allowing these messages on a host/bridge. Meantime this is an example of the relevant ip6tables command:

ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 130 -j DROP

Drop incoming and outgoing Multicast Listener reports (MLDv1)

FireHOL handles this automatically unless you create a rule to explicitly allow the packets.

Note

At some point FireHOL may have a helper command added to simplify allowing these messages on a host/bridge. Meantime this is an example of the relevant ip6tables command:

ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 131 -j DROP

Drop incoming and outgoing Multicast Listener Done messages (MLDv1)

FireHOL handles this automatically unless you create a rule to explicitly allow the packets.

Note

At some point FireHOL may have a helper command added to simplify allowing these messages on a host/bridge. Meantime this is an example of the relevant ip6tables command:

ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 132 -j DROP

Drop incoming and outgoing Multicast Listener reports (MLDv2)

FireHOL handles this automatically unless you create a rule to explicitly allow the packets.

Note

At some point FireHOL may have a helper command added to simplify allowing these messages on a host/bridge. Meantime this is an example of the relevant ip6tables command:

ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 143 -j DROP

Drop router renumbering messages

FireHOL handles this automatically unless you create a rule to explicitly allow the packets.

Note

At some point FireHOL may have a helper command added to simplify allowing these messages on a host/bridge. Meantime this is an example of the relevant ip6tables command:

ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 138 -j DROP

Drop node information queries (139) and replies (140)

FireHOL handles this automatically unless you create a rule to explicitly allow the packets.

Note

At some point FireHOL may have a helper command added to simplify allowing these messages on a host/bridge. Meantime this is an example of the relevant ip6tables command:

ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 139 -j DROP
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 140 -j DROP

If there are mobile ipv6 home agents present on the trusted side allow

At some point FireHOL may have a helper command added to simplify this setup. Meantime this is an example of the relevant ip6tables commands from the RFC script:

#incoming Home Agent address discovery request
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
     --icmpv6-type 144 -j ACCEPT
#outgoing Home Agent address discovery reply
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
     --icmpv6-type 145 -j ACCEPT
#incoming Mobile prefix solicitation
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
     --icmpv6-type 146 -j ACCEPT
#outgoing Mobile prefix advertisement
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
     --icmpv6-type 147 -j ACCEPT

If there are roaming mobile nodes present on the trusted side allow

At some point FireHOL may have a helper command added to simplify this setup. Meantime this is an example of the relevant ip6tables commands from the RFC script:

#outgoing Home Agent address discovery request
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
     --icmpv6-type 144 -j ACCEPT
#incoming Home Agent address discovery reply
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
     --icmpv6-type 145 -j ACCEPT
#outgoing Mobile prefix solicitation
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
     --icmpv6-type 146 -j ACCEPT
#incoming Mobile prefix advertisement
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
     --icmpv6-type 147 -j ACCEPT

Drop everything else

FireHOL handles this automatically unless you create a rule to explicitly allow the packets.