fiaif.conf

package: fiaif

title: fiaif.conf(5)

text:
# fiaif.conf(5)

## NAME
fiaif.conf - fiaif global configuration file

## DESCRIPTION
fiaif.conf is the file that declares which zones should be set up in the firewall. A "zone" is a piece of the "IP universe" existing on the other side of a particular interface. A zone is defined in a file listing rules for the handling of IP traffic into, out of, and through the associated interface. The zonefile is described in zone.conf(8). General configuration parameters are also declared in this file.

fiaif.conf and the zonefiles are bash(1) scripts in which the values of variables used in the fiaif program are assigned. Although they are shell scripts, they should contain nothing but assignment statements.

Parameters in the configuration files are of three forms:

SIMPLE

These parameters take only a single value. The value may be a number or a string.

GROUP These parameters are treated as a group, and all members of the group are processed in the same way. There are two parts to these parameters´ names. The first part is the name of the group, and the second part is a mnemonic.

ARRAY Parameter values are declared in an array. Any number of values can be specified by incrementing the array index for each value.

## DEFINITIONS
bashcommand -> [a shell command line]

dirpath -> [path to a directory (no trailing ´/´)]

fname -> [filename with no path]

modulename -> [the name of an iptables module]

portspec -> [a port number | a service in /etc/services]

posint -> [an integer >= 0]

TOStype -> [a Type-of-service name | a Type-of-service number]

zonename -> [the zone identifier from a zone file]

byteint -> 0..255

cidrmask -> 0..32

nullstring -> [nothing]

string -> [char]<string>|<nullstring>

boolean -> 0|1

burstspec -> <posint>|<posint>/<timespec>

IP4addr -> <byteint>.<byteint>.<byteint>.<byteint>

iptablesprotocol -> [a protocol number | a protocol name from /etc/protocols]

modulelist -> <nullstring>|<modulename> <modulelist>

netaddr -> <IP4addr>/<cidrmask>

netlist -> <nullstring>|<netaddr> <netlist>

pathlist -> <dirpath>|<dirpath>:<pathlist>

plist -> <nullstring>|<iptablesprotocol> <plist>

tablelist -> mangle filter nat

timespec -> second|minute|hour|day

TOSportlist -> <nullstring> | any | <TOSportlistOpt>

TOSportlistOpt -> <portspec> | <portspec>,<TOSportlist>

ICMPtype -> <ICMP type string>

zonelist -> <nullstring>|<zonename> <zonelist>

## CONSTANT PARAMETERS
The values of these parameters should (almost certainly) not be altered.

### TABLES
Syntax: TABLES= "<tablelist>"

A list of the packet processing tables in the Linux kernel. As of version 2.4.18, only three tables are available: mangle, filter, and nat.

### RESERVED_NETWORKS
Syntax: RESERVED_NETWORKS= "<netlist>"|"<fname>"

A list of the reserved ipnumbers and masks, or a file containing this list, one <netaddr> per line. See http://www.iana.com for more information.

### PRIVATE_NETWORKS
Syntax: PRIVATE_NETWORKS= "<netlist>"|"<fname>"

A list of the private ipnumbers and masks, or a file containing this list, one <netaddr> per line. See http://www.iana.com and rfc1918 for more information.

### LOOPBACK_NET
Syntax: LOOPBACK_NET= "<netaddr>"

The network of the loopback interface. "127.0.0.1/8" in the distribution.

### BIN_PATH
Syntax: BIN_PATH= "<pathlist>"

The search path for the iptables and tc binaries.

## PARAMETERS
The values of these parameters should be altered. They define the firewall deployed by fiaif and customize it for local networks and security policy.

### DONT_START
Syntax: DONT_START= <boolean>

If set to one, the firewall will not be started. DONT_START is set to 1 in the distributed fiaf.conf to prevent the inadvertant deployment of an unconfigured firewall from a download. Set the value to zero or delete the line to enable the firewall.

### CONF_DIR
Syntax: CONF_DIR= "<directorypath>/"

The path to the configuration directory. CONF_DIR is set to "/etc/fiaif/" in the distribution.

### SET_PROC_ERRORS
Syntax: SET_PROC_ERRORS= <boolean>

### SET_PROC_WARNINGS
Syntax: SET_PROC_WARNINGS= <boolean>

When the command "fiaif test" is issued, a list of errors and warnings are displayed.

If SET_PROC_ERRORS is 1, FIAIF will attempt to correct the errors.

If SET_PROC_WARNINGS is 1, FIAIF will attempt to correct the warnings.

### SAVE_STATE
Syntax: SAVE_STATE= <boolean>

If enabled, FIAIF will save all iptables rules to a file after these have been applied, if no errors were encountered while generating the rules. When FIAIF is started again, this file is used if and only if no modifications have been made to any configuration files. Rules are saved to /var/lib/fiaif/iptables.

Enabling this option greatly improves start time of FIAIF, but may cause problems if, for example, the ipnumber of a static interface changes, in which case /etc/init.d/fiaif force-reload should be used to rebuild ruleset from configuration files.

### ZONES
Syntax: ZONES= "<zonelist>"

A list of the zones to be set up. There must be a zone file in the configuration directory matching each zone named in this list.

Example:

ZONES="INT EXT"

### CONF_[XXX]
Syntax: CONF_[XXX]= "<fname>"

A group (CONF) containing the names of the zone files. It should match closly the names listed in the ZONES parameter. The zone files must be in the directory specified in CONF_DIR.

Example:

CONF_INT="zone.internal"

CONT_EXT="zone.external"

### TEST_FILE
Syntax: TEST_FILE= "<dirpath>/<fname>"

The absolute pathname of the file to which commands are written when fiaif is run with the ´test´ option. Set to "/tmp/fiaif.out" in the distribution.

### DEBUG
Syntax: DEBUG= <boolean>

If set to 1, fiaif will not drop any packets, but all rules are still applied, and the results will be in the syslog. Use this as a debugging tool if you are experiencing problems while setting up the zones. Set to zero for fiaif to work normally.

### VERBOSE
Syntax: VERBOSE= <boolean>

Set this variable to 1 to have fiaif log all dropped or redirected packets in the syslog. If no logging is wanted, set it to 0. See LOG_LIMIT and LOG_BURST for details on when logging occurs.

### LOG_PREFIX
Syntax: FIAIF_ <string>

Specify the prefix to use when logging packets to system log or though ulogd.

### ENABLE_ULOGD
Syntax: ENABLE_ULOGD= <boolean>

If set to 1 (and the ulogd is running on the system), fiaif logs via a ulogd. If set to 0, fiaif logs through the standard syslog facility.

### LOG_LIMIT
Syntax: LOG_LIMIT= <posint>

### LOG_BURST
Syntax: LOG_BURST= "<burstspec>"

Specify how often dropped or rejected packets should be entered into the system log. Tune to avoid spamming of logs.

LOG_LIMIT is the maximum average matching rate. If no <timespec> is provided, ´/second´ is assumed.

LOG_BURST is the maximum initial number of packets to match; this number is incrememted by one every time the limit specified above is not reached, up to this number. Note the quotes around LOG_BURST´s value.

### LOG_LEVEL
Syntax: LOG_LEVEL= <byteint>

This specifies the loglevel, for logging to syslog or ulogd. When using syslog, the number specifies the priority, see syslog.conf(5). If ENABLE_ULOG is true, LOG_LEVEL number specifies the netlink group (1-32), to which the line to be logged is is sent.

### ENABLE_TC
Syntax: ENABLE_TC= <boolean>

Enable or disable traffic shaping system wide. Setting to 0 overrides the TC_ENABLE value in all zone configurations. To enable traffic shaping in a zone, TC_ENABLE must be set to 1 in fiaif.conf and in the zone configuration as well.

### MODULES
Syntax: MODULES= "<modulelist>"

Specifies iptables modules to be loaded upon starting the firewall. The modules remain loaded as long as the firewall is deployed.

### PRE_SCRIPT[N]
Syntax: PRE_SCRIPT[N]= "<bashcommand>"

### POST_SCRIPT[N]
Syntax: POST_SCRIPT[N]= "<bashcommand>"

This pair of array parameters may contain shell commands to be executed before/after fiaif creates the iptables rules. The lines are executed in array-index sequence.

Three chains per zone exists to support user-defined rules. The chain names are: USER_INPUT_<ZONE_NAME> USER_OUTPUT_<ZONE_NAME> USER_FORWARD_<ZONE_NAME> Where the zone name is the name of the zone. Packets will go though these chains before hitting rules generated by INPUT, OUTPUT and FORWARD rules in the zone configuration files. Remember that only packets in the NEW state will hit these chains, and hence there is no need to test the state of a packet in these chains.

### ALIASES
Points to a file with IP alias specifications. These aliases are available to all zone configuration files, and can be used in rules where the syntax [<ip>[/<mask>]=>[<ip>[/<mask>] is used, as replacement for either side. See IPSET in zone.conf(8) for more information.

### TOS_FILE
Syntax: TOS_FILE= "<fname>"

Specify the name of the Type-Of-Service configuration file located in the configuration directory. This file specifies manipulation of the TOS bits in TCP and UDP packets. Traffic control examines these fields to determine into which class a packet should fall.

The file contains a group (TOS) with values of the form:

TOS_[XXX]= "<TOS-type> <protocol> <TOSportlist|ICMPtype>"

Examples:

TOS_MIN_DLY_UDP= "Minimize-Delay udp" TOS_NORM_SRVC_TCP= "Normal-Service tcp www,https"

## FILES
/etc/fiaif/fiaif.conf

The configuration file for FIAIF

/etc/fiaif/private_networks A list of private networks as specified by RFC1918

/etc/fiaif/reserved_networks A list of reserved networks as specified by IANA.

/etc/fiaif/aliases Specifies IP aliases to be used for all configuration files.

## AUTHOR
Anders Fugmann <anders(at)fugmann.net>

## SEE ALSO
fiaif(8), zone.conf(8)


zone.conf

title: zone.conf(5)

summary: fiaif zone configuration files

text:
# zone.conf(5)

## NAME
zone.conf - fiaif zone configuration files

## DESCRIPTION
fiaif.conf is the file that determines how zones should be set up in the firewall. A zone describes how traffic from other zones are allowed into a zone, and what packets are allowed from the zone itself. Zones are based upon the interface and the network the interface is connected to. It is possible to have multiple zones per interface, if and only if the interface is not declared public. See the PUBLIC variable for more information.

The general syntax of a configuration file is the same as for a bash(1) script, in which only variables should be present.

The variables can be on three forms:

VARIABLE

This is a simple variable. It can only be assigned a single value.

VARIABLE_FOO The denotes a variable sequence. The FOO can be replaced by any keyword, allowing multiple values to be specified.

VARIABLE[N] A variable array. Any number of values can be specified by increasing N for each value.

## VARIABLES

### NAME
Syntax: <name>

Specify the name of the zone. This must be the same as specified in /etc/fiaif/fiaif.conf.

### DEV
Syntax: <interface-name>

Specifies the interface name in which this zone is connected.

### DYNAMIC
Syntax: 0|1

Specifies whether the IP of the interface is dynamic (e.g., obtained via DHCP or unknown when FIAIF is started) or not. Disabling this provides better security, but this is not always an option given from ISPs.

### GLOBAL
Syntax: 0|1

Is set to one, any packets originating from IANA reserved networks are discarded (except those specified in the NET and NET_EXTRA variables). This should be set on your internet connection. If this is set to true, the interface cannot have multible zone definitions.

### IP
Syntax: <IP address>

The IP of the interface. This is only necessary to specify if DYNAMIC=0.

### MASK
Syntax: <network mask>

The network mask of the network connected to this interface. This is only necessary to specify if DYNAMIC=0. This information can be found be using the ifconfig command.

### NET
Syntax: <ip address/networkmask>

The network mask for the interface. This is only necessary to specify if DYNAMIC=0. This information can be found be using the ifconfig command.

### BCAST
Syntax: <broadcast address>

The broadcast address of the interface. This is only necessary to specify if DYNAMIC=0. This information can be found be using the ifconfig command.

### IP_EXTRA
Syntax: [IP]*

Contains a list of additional IP addresses that the interface can receive. Extra IP's for an interface is usually created by using interface aliases (e.g. eth0:0).

### NET_EXTRA
Syntax: [IP/MASK]*

A list specifying any extra networks besides the NET variables that are connected to this zone (interface). The extra nets would normally be connected though other routers.

### DHCP_SERVER
Syntax: <0|1>

Set to '1' if the server should accept DHCP queries. Only one zone per interface should have this enabled, since DHCP packets do not hold any valid destination address.

### INPUT[N]
Syntax: <ACCEPT|REJECT|DROP|LOG|ACCEPT_LOG|REJECT_NOLOG|DROP_NOLOG> <protocol> [port<:port>[<,port>[:port]]*] ip/[mask]=>ip/[mask]

The INPUT variable describes how packets are handled through the input chain. Packets on the INPUT chain are packets coming from the zone to the firewall itself. The first argument is how a matched packet is treated. Protocol and ports and ip/mask are used to match packets (destination port, and source=>destination ip address). If none are specified, the rule matches all packets. The port argument must only be specified if the protocol is udp, tcp or icmp When using these rules, a rule of thumb is only to accept specific packets, and to drop any not matched. The following line 1 accepts HTTP-requests over the TCP protocol:

INPUT[0]="ACCEPT tcp 80 0.0.0.0/0=>0.0.0.0/0"

INPUT[1]="ACCEPT udp 1024:65535 0.0.0.0/0=>0.0.0.0/0"

INPUT[2]="DROP ALL 0.0.0.0=>0.0.0.0"

### OUTPUT[N]
Syntax: <ACCEPT|REJECT|DROP|LOG|ACCEPT_LOG|REJECT_NOLOG|DROP_NOLOG> <protocol> [port<:port>[<,port>[:port]]*] ip/[mask]=>ip/[mask]

Like the INPUT[N] rule. Packets on the OUTPUT chain are packets originating from the firewall itself going out into the zone itself. ports are destination ports, and ip/mask is the source and destination ip/mask (if '=>' is not given, the ip is assumed to be the destination ip). The port argument must only be specified if the protocol is udp, tcp or icmp The following example drops all telnet packets over the tcp protocol, drops any udp packets, and allows any other send from the firewall itself.

OUTPUT[0]="DROP tcp 21 0.0.0.0/0=>0.0.0.0/0"

OUTPUT[1]="DROP udp ALL 0.0.0.0/0=>0.0.0.0/0"

OUTPUT[2]="ACCEPT ALL 0.0.0.0/0=>0.0.0.0/0"

### FORWARD[N]
Syntax: <zone|ALL> <ACCEPT|REJECT|DROP|LOG|ACCEPT_LOG|REJECT_NOLOG|DROP_NOLOG> <protocol[port<:port>[<,port>[:port]]*]> <ip/[mask]=>ip/[mask]>

Use to specify how packets arriving from other zones are to be treated. If protocol or ports and ip/mask is not specified, then ALL is assumed. The port specifies the destination port, and ip specifies the source and destination ip. The port argument must only be specified if the protocol is udp, tcp or icmp An example: A demilitarized zone may only accept HTTP requests from the internet (zone EXT). This would be specified by:

FORWARD[0]="EXT ACCEPT tcp 80 0.0.0.0/0=>0.0.0.0/0"

FORWARD[1]="ALL DROP ALL 0.0.0.0/0=>0.0.0.0/0"

### MARK[N]
Syntax: <zone|ALL> <mark number> <protocol[port<:port>[<,port>[:port]]*]> <ip/[mask]=>ip/[mask]>

Use the MARK rules to set a MARK on packets passing through the firewall. This can then be used to determine how a packet is routed. FIAIF does not do traffic-shaping based on mark values. The port argument must only be specified if the protocol is udp, tcp or icmp If the source zone is ALL then all packets going into the zone are marked. If the source zone equals the zone-name of which the rule is in then only packets originating from the firewall are marked.

Otherwise, only packets routed through the firewall are marked. Example: Mark all tcp packets going into the zone with '1' and all udp packets with mark '2'.

MARK[0]="ALL 1 tcp ALL 0.0.0.0/0=>0.0.0.0/0"

MARK[1]="ALL 2 udp ALL 0.0.0.0/0=>0.0.0.0/0"

### REPLY_FOO
Syntax: <zone> <type> <protocol [port[:port][<,port>[:port]]*]> <ip[/mask]=>ip[/mask]>

Make special replies to packets. The type can be one of the following:

icmp-net-unreachable, icmp-host-unreachable, icmp-port-unreachable, icmp-proto-unreachable, icmp-net-prohibited, icmp-host-prohibited or tcp-reset (Only valid for the TCP protocol).

The zone argument specifies the source of the packet.

This can be used, for example, to disallow authentication requests, but instead of dropping the packets, close the connection by sending a tcp-reset.

REPLY_AUTH="EXT tcp-reset tcp auth 0.0.0.0/0=>0.0.0.0/0"

### MAC_DROP
Syntax: [MAC_ADDRESS]*|[file]

Disallow any communication with specified MAC-addresses in this zone. Inserted on PREROUTING chain. If the value is a file, then each line in the file is treated as an MAC address. Anything after a '#' is regarded as a comment and is ignored.

### IP_DROP
Syntax: [IP/MASK]*|[file]

Disallow any communication with specified IP addresses in this zone. If the value is a file, then each line in the file is treated as an ip address. Anything after a '#' is regarded as a comment and is ignored.

### ECN_REMOVE
Syntax: [IP/MASK]*|[file]

Remove the ECN bit from all packets destined to the specified servers (located in the zone). If the value is a file, then each line in the file is treated as an ip address. Anything after a '#' is regarded as a comment and is ignored.

### REDIRECT_FOO
Syntax: <protocol[port[:port]]> <ip[/mask]=>ip[/mask]> <[ipaddr[,ipaddr]*]> [port]

Alter the destination of packets. The rule applies only for packets originating from this zone. Packets can be redirected to the firewall itself (127.0.0.1), to other zones or back into the zone itself (requires DYNAMIC==0 and GLOBAL==0). If packets are redirected to other zones, then remember to add a FORWARD rule in the configuration file for the destination zone, allowing the packets to pass through. Please note, that redirecting packets back into the zone may cause serious network degradation.

Example:

REDIRECT_PROXY="tcp 80 0.0.0.0/0=>0.0.0.0/0 127.0.0.1 3128"

All packets coming from the zone itself to port 80 are redirected to the firewall itself port 3128, and this line can be used to setup a transparent proxy.

### WATCH_IP
Syntax: [IP]*|[file]

Log every packet coming from or going to the specific IP addresses. If the value is a file, then each line in the file is treated as an IP address. Anything after a '#' is regarded as a comment and is ignored.

### SNAT[N]
Syntax: <ZONE|ip> <protocol[port[:port][<,port>[:port]]*]> <ip[/mask]=>ip[/mask]>

Change the source address of a packet coming from this zone. If a ZONE is specified, then all packets are masqueraded to all ip addresses for the specified zone, specified by the IP or IP_EXTRA directive, in a round robin fashion. The last options specifies the protocol, port and original source and destination of the packets to be SNAT'ed.

To use MASQUADING, where EXT is the zone for the internet use:

SNAT[0]="EXT ALL 0.0.0.0/0=>0.0.0.0/0"

### LIMIT_FOO
Syntax: <zone> <ACCEPT|REJECT|DROP|LOG|ACCEPT_LOG|REJECT_NOLOG|DROP_NOLOG> <limit> <burt> <protocol[port<:port>[<,port>[:port]]*]> <ip[/mask]=>ip[/mask]>

Limit number of packets. A LIMIT rule specifies how many packets are acceptable within the specified period of time. If more packets arrive, policy specifies how to handle these.

zone: Is the zone from which the packet originates. This can be this zone itself.

limit: Maximum average matching rate: specified as a number, with an optional ´/second´, ´/minute´, ´/hour´, or ´/day´ suffix.

burst: Maximum initial number of packets to match: this number gets incremented by one every time the limit specified above is not reached, up to this number.

protocol: The protocol: TCP|UDP|ICMP|ALL. This parameter is optional. The port argument must only be specified if the protocol is udp, tcp or icmp

ports: If protocol is tcp|udp: A list of ports or a port range. icmp: A list of icmp types seperated by commas. This parameter is optional pending on the specified protocol.

ip[/mask]=>ip[/mask] Specifies source address and optional destination address. This can only be specified if protocol is also specified.

For example to limit number of echo requests (ping) from zone EXT, use:

LIMIT_PING="EXT DROP 1/second 3 ICMP echo-request 0.0.0.0/0=>0.0.0.0/0"

### TC_ENABLE
Syntax: <0|1>

Enable or disable Traffic Shaping for this zone (traffic going into the network card, or being sent from the network card.) TC is only enabled if ENABLE_TC is set in the global configuration as well.

### TC_DOWNLINK
Syntax: <kbit>

Specify maximum uplink and downlink speeds. The values are specifed in kilobits (1024 bits).

### TC_TYPE
Syntax: <HTB|HFSC>

Specify the type of traffic shaping to be used. htb is videly available, but the hfsc type shaping yields much better results. Choose hfsc if you have the nessesary modules.

### TC_VOIP
Syntax: <0|1>

Specify '1' to enable special VOIP traffic shaping classes. Currently only implemented for the HFSC type shaper. It reserves a minimum bandwidth for voip traffic, and creates a special high priority class for voip related traffic.

### IPSET_FOO
Syntax: <ip</mask>>[ip</mask>]*| <file>

Sepcify a set of ip's to be used in zone rules. Ip's specified can be either numbers, hostnames, networks or names of other ip sets (recursively). The name of the set will be the name occuring after IPSET_. Ip sets is bound to a zone, and cannot be used across zones. Currently, ip-sets can only be used in INPUT, OUTPUT, FORWARD, SNAT, REDIRECT and MARK rules. If the ipset points to a file, then the file is read (relative to CONF_PATH ). The name of IP sets must not conflict with aliases defined in the file pointed to by the ALIASES directive in fiaif global configuration file.

An example of the use of IP sets:

IPSET_NAMESERVERS="1.2.3.4 1.2.3.5"

INPUT[N]="ACCEPT tcp domain NAMESERVERS=>0.0.0.0/0"

Which is equivalent to:

INPUT[N]="ACCEPT tcp domain 1.2.3.4=>0.0.0.0/0"

INPUT[N+1]="ACCEPT tcp domain 1.2.3.5=>0.0.0.0/0"

## AUTHOR
Anders Fugmann <anders(at)fugmann.net>

## SEE ALSO
fiaif(8), fiaif.conf(8), iptables(8), ifconfig(8)


magic

package: file

title: magic(5)

summary: file command's magic pattern file

text:
# magic(5)

## NAME
magic — file command's magic pattern file

## DESCRIPTION
This manual page documents the format of magic files as used by the file(1) command, version 5.45. The file(1) command identifies the type of a file using, among other tests, a test for whether the file contains certain “magic patterns”. The database of these “magic patterns” is usually located in a binary file in /usr/share/file/magic.mgc or a directory of source text magic pattern fragment files in /usr/share/file/magic. The database specifies what patterns are to be tested for, what message or MIME type to print if a particular pattern is found, and additional information to extract from the file.

The format of the source fragment files that are used to build this database is as follows: Each line of a fragment file specifies a test to be performed. A test compares the data starting at a particular offset in the file with a byte value, a string or a numeric value. If the test succeeds, a message is printed. The line consists of the following fields:

offset

A number specifying the offset (in bytes) into the file of the data which is to be tested. This offset can be a negative number if it is:

- The first direct offset of the magic entry (at continuation level 0), in which case it is interpreted an offset from end end of the file going backwards. This works only when a file descriptor to the file is available and it is a regular file.

- A continuation offset relative to the end of the last up-level field (&).

type

The type of the data to be tested. The possible values are: byte

A one-byte value.

short

A two-byte value in this machine's native byte order.

long

A four-byte value in this machine's native byte order.

quad

An eight-byte value in this machine's native byte order.

float

A 32-bit single precision IEEE floating point number in this machine's native byte order.

double

A 64-bit double precision IEEE floating point number in this machine's native byte order.

string

A string of bytes. The string type specification can be optionally followed by a /<width> option and optionally followed by a set of flags /[bCcftTtWw]*. The width limits the number of characters to be copied. Zero means all characters. The following flags are supported: b

Force binary file test.

C

Use upper case insensitive matching: upper case characters in the magic match both lower and upper case characters in the target, whereas lower case characters in the magic only match upper case characters in the target.

c

Use lower case insensitive matching: lower case characters in the magic match both lower and upper case characters in the target, whereas upper case characters in the magic only match upper case characters in the target. To do a complete case insensitive match, specify both “c” and “C”.

f

Require that the matched string is a full word, not a partial word match.

T

Trim the string, i.e. leading and trailing whitespace

t

Force text file test.

W

Compact whitespace in the target, which must contain at least one whitespace character. If the magic has n consecutive blanks, the target needs at least n consecutive blanks to match.

w

Treat every blank in the magic as an optional blank. is deleted before the string is printed.

pstring

A Pascal-style string where the first byte/short/int is interpreted as the unsigned length. The length defaults to byte and can be specified as a modifier. The following modifiers are supported: B

A byte length (default).

H

A 2 byte big endian length.

h

A 2 byte little endian length.

L

A 4 byte big endian length.

l

A 4 byte little endian length.

J

The length includes itself in its count.

The string is not NUL terminated. “J” is used rather than the more valuable “I” because this type of length is a feature of the JPEG format.

date

A four-byte value interpreted as a UNIX date.

qdate

An eight-byte value interpreted as a UNIX date.

ldate

A four-byte value interpreted as a UNIX-style date, but interpreted as local time rather than UTC.

qldate

An eight-byte value interpreted as a UNIX-style date, but interpreted as local time rather than UTC.

qwdate

An eight-byte value interpreted as a Windows-style date.

beid3

A 32-bit ID3 length in big-endian byte order.

beshort

A two-byte value in big-endian byte order.

belong

A four-byte value in big-endian byte order.

bequad

An eight-byte value in big-endian byte order.

befloat

A 32-bit single precision IEEE floating point number in big-endian byte order.

bedouble

A 64-bit double precision IEEE floating point number in big-endian byte order.

bedate

A four-byte value in big-endian byte order, interpreted as a Unix date.

beqdate

An eight-byte value in big-endian byte order, interpreted as a Unix date.

beldate

A four-byte value in big-endian byte order, interpreted as a UNIX-style date, but interpreted as local time rather than UTC.

beqldate

An eight-byte value in big-endian byte order, interpreted as a UNIX-style date, but interpreted as local time rather than UTC.

beqwdate

An eight-byte value in big-endian byte order, interpreted as a Windows-style date.

bestring16

A two-byte unicode (UCS16) string in big-endian byte order.

leid3

A 32-bit ID3 length in little-endian byte order.

leshort

A two-byte value in little-endian byte order.

lelong

A four-byte value in little-endian byte order.

lequad

An eight-byte value in little-endian byte order.

lefloat

A 32-bit single precision IEEE floating point number in little-endian byte order.

ledouble

A 64-bit double precision IEEE floating point number in little-endian byte order.

ledate

A four-byte value in little-endian byte order, interpreted as a UNIX date.

leqdate

An eight-byte value in little-endian byte order, interpreted as a UNIX date.

leldate

A four-byte value in little-endian byte order, interpreted as a UNIX-style date, but interpreted as local time rather than UTC.

leqldate

An eight-byte value in little-endian byte order, interpreted as a UNIX-style date, but interpreted as local time rather than UTC.

leqwdate

An eight-byte value in little-endian byte order, interpreted as a Windows-style date.

lestring16

A two-byte unicode (UCS16) string in little-endian byte order.

melong

A four-byte value in middle-endian (PDP-11) byte order.

medate

A four-byte value in middle-endian (PDP-11) byte order, interpreted as a UNIX date.

meldate

A four-byte value in middle-endian (PDP-11) byte order, interpreted as a UNIX-style date, but interpreted as local time rather than UTC.

indirect

Starting at the given offset, consult the magic database again. The offset of the indirect magic is by default absolute in the file, but one can specify /r to indicate that the offset is relative from the beginning of the entry.

name

Define a “named” magic instance that can be called from another use magic entry, like a subroutine call. Named instance direct magic offsets are relative to the offset of the previous matched entry, but indirect offsets are relative to the beginning of the file as usual. Named magic entries always match.

use

Recursively call the named magic starting from the current offset. If the name of the referenced begins with a ^ then the endianness of the magic is switched; if the magic mentioned leshort for example, it is treated as beshort and vice versa. This is useful to avoid duplicating the rules for different endianness.

regex

A regular expression match in extended POSIX regular expression syntax (like egrep). Regular expressions can take exponential time to process, and their performance is hard to predict, so their use is discouraged. When used in production environments, their performance should be carefully checked. The size of the string to search should also be limited by specifying /<length>, to avoid performance issues scanning long files. The type specification can also be optionally followed by /[c][s][l]. The “c” flag makes the match case insensitive, while the “s” flag update the offset to the start offset of the match, rather than the end. The “l” modifier, changes the limit of length to mean number of lines instead of a byte count. Lines are delimited by the platforms native line delimiter. When a line count is specified, an implicit byte count also computed assuming each line is 80 characters long. If neither a byte or line count is specified, the search is limited automatically to 8KiB. ^ and $ match the beginning and end of individual lines, respectively, not beginning and end of file.

search

A literal string search starting at the given offset. The same modifier flags can be used as for string patterns. The search expression must contain the range in the form /number, that is the number of positions at which the match will be attempted, starting from the start offset. This is suitable for searching larger binary expressions with variable offsets, using \ escapes for special characters. The order of modifier and number is not relevant.

default

This is intended to be used with the test x (which is always true) and it has no type. It matches when no other test at that continuation level has matched before. Clearing that matched tests for a continuation level, can be done using the clear test.

clear

This test is always true and clears the match flag for that continuation level. It is intended to be used with the default test.

der

Parse the file as a DER Certificate file. The test field is used as a der type that needs to be matched. The DER types are: eoc, bool, int, bit_str, octet_str, null, obj_id, obj_desc, ext, real, enum, embed, utf8_str, rel_oid, time, res2, seq, set, num_str, prt_str, t61_str, vid_str, ia5_str, utc_time, gen_time, gr_str, vis_str, gen_str, univ_str, char_str, bmp_str, date, tod, datetime, duration, oid-iri, rel-oid-iri. These types can be followed by an optional numeric size, which indicates the field width in bytes.

guid

A Globally Unique Identifier, parsed and printed as XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX. It's format is a string.

offset

This is a quad value indicating the current offset of the file. It can be used to determine the size of the file or the magic buffer. For example the magic entries:

```
-0	offset	x	this file is %lld bytes
-0	offset	<=100	must be more than 100 \
    bytes and is only %lld
```

octal

A string representing an octal number.

For compatibility with the Single UNIX Standard, the type specifiers dC and d1 are equivalent to byte, the type specifiers uC and u1 are equivalent to ubyte, the type specifiers dS and d2 are equivalent to short, the type specifiers uS and u2 are equivalent to ushort, the type specifiers dI, dL, and d4 are equivalent to long, the type specifiers uI, uL, and u4 are equivalent to ulong, the type specifier d8 is equivalent to quad, the type specifier u8 is equivalent to uquad, and the type specifier s is equivalent to string. In addition, the type specifier dQ is equivalent to quad and the type specifier uQ is equivalent to uquad.

Each top-level magic pattern (see below for an explanation of levels) is classified as text or binary according to the types used. Types “regex” and “search” are classified as text tests, unless non-printable characters are used in the pattern. All other tests are classified as binary. A top-level pattern is considered to be a test text when all its patterns are text patterns; otherwise, it is considered to be a binary pattern. When matching a file, binary patterns are tried first; if no match is found, and the file looks like text, then its encoding is determined and the text patterns are tried.

The numeric types may optionally be followed by & and a numeric value, to specify that the value is to be AND'ed with the numeric value before any comparisons are done. Prepending a u to the type indicates that ordered comparisons should be unsigned.

The value to be compared with the value from the file. If the type is numeric, this value is specified in C form; if it is a string, it is specified as a C string with the usual escapes permitted (e.g. \n for new-line).

Numeric values may be preceded by a character indicating the operation to be performed. It may be =, to specify that the value from the file must equal the specified value, <, to specify that the value from the file must be less than the specified value, >, to specify that the value from the file must be greater than the specified value, &, to specify that the value from the file must have set all of the bits that are set in the specified value, ^, to specify that the value from the file must have clear any of the bits that are set in the specified value, or ~, the value specified after is negated before tested. x, to specify that any value will match. If the character is omitted, it is assumed to be =. Operators &, ^, and ~ don't work with floats and doubles. The operator ! specifies that the line matches if the test does not succeed.

Numeric values are specified in C form; e.g. 13 is decimal, 013 is octal, and 0x13 is hexadecimal.

Numeric operations are not performed on date types, instead the numeric value is interpreted as an offset.

For string values, the string from the file must match the specified string. The operators =, < and > (but not &) can be applied to strings. The length used for matching is that of the string argument in the magic file. This means that a line can match any non-empty string (usually used to then print the string), with >\0 (because all non-empty strings are greater than the empty string).

Dates are treated as numerical values in the respective internal representation.

The special test x always evaluates to true.

The message to be printed if the comparison succeeds. If the string contains a printf(3) format specification, the value from the file (with any specified masking performed) is printed using the message as the format string. If the string begins with “\b”, the message printed is the remainder of the string with no whitespace added before it: multiple matches are normally separated by a single space.

An APPLE 4+4 character APPLE creator and type can be specified as:

```
!:apple	CREATYPE
```

A slash-separated list of commonly found filename extensions can be specified as:

```
!:ext	ext[/ext...]
```

i.e. the literal string “!:ext” followed by a slash-separated list of commonly found extensions; for example for JPEG images:

```
!:ext jpeg/jpg/jpe/jfif
```

A MIME type is given on a separate line, which must be the next non-blank or comment line after the magic line that identifies the file type, and has the following format:

```
!:mime	MIMETYPE
```

i.e. the literal string “!:mime” followed by the MIME type.

An optional strength can be supplied on a separate line which refers to the current magic description using the following format:

```
!:strength OP VALUE
```

The operand OP can be: +, -, *, or / and VALUE is a constant between 0 and 255. This constant is applied using the specified operand to the currently computed default magic strength.

Some file formats contain additional information which is to be printed along with the file type or need additional tests to determine the true file type. These additional tests are introduced by one or more > characters preceding the offset. The number of > on the line indicates the level of the test; a line with no > at the beginning is considered to be at level 0. Tests are arranged in a tree-like hierarchy: if the test on a line at level n succeeds, all following tests at level n+1 are performed, and the messages printed if the tests succeed, until a line with level n (or less) appears. For more complex files, one can use empty messages to get just the "if/then" effect, in the following way:

```
0      string   MZ
>0x18  leshort  <0x40   MS-DOS executable
>0x18  leshort  >0x3f   extended PC executable (e.g., MS Windows)
```

Offsets do not need to be constant, but can also be read from the file being examined. If the first character following the last > is a ( then the string after the parenthesis is interpreted as an indirect offset. That means that the number after the parenthesis is used as an offset in the file. The value at that offset is read, and is used again as an offset in the file. Indirect offsets are of the form: (( x [[.,][bBcCeEfFgGhHiIlmsSqQ]][+-][ y ]). The value of x is used as an offset in the file. A byte, id3 length, short or long is read at that offset depending on the [bBcCeEfFgGhHiIlmsSqQ] type specifier. The value is treated as signed if “”, is specified or unsigned if “”. is specified. The capitalized types interpret the number as a big endian value, whereas the small letter versions interpret the number as a little endian value; the m type interprets the number as a middle endian (PDP-11) value. To that number the value of y is added and the result is used as an offset in the file. The default type if one is not specified is long. The following types are recognized:

Type

Sy Mnemonic

Sy Endian

Sy Size

bcBc

Byte/Char

N/A

1

efg

Double

Little

8

EFG

Double

Big

8

hs

Half/Short

Little

2

HS

Half/Short

Big

2

i

ID3

Little

4

I

ID3

Big

4

m

Middle

Middle

4

o

Octal

Textual

Variable

q

Quad

Little

8

Q

Quad

Big

8

That way variable length structures can be examined:

```
# MS Windows executables are also valid MS-DOS executables
0           string  MZ
>0x18       leshort <0x40   MZ executable (MS-DOS)
# skip the whole block below if it is not an extended executable
>0x18       leshort >0x3f
>>(0x3c.l)  string  PE\0\0  PE executable (MS-Windows)
>>(0x3c.l)  string  LX\0\0  LX executable (OS/2)
```

This strategy of examining has a drawback: you must make sure that you eventually print something, or users may get empty output (such as when there is neither PE\0\0 nor LE\0\0 in the above example).

If this indirect offset cannot be used directly, simple calculations are possible: appending [+-*/%&|^]number inside parentheses allows one to modify the value read from the file before it is used as an offset:

```
# MS Windows executables are also valid MS-DOS executables
0           string  MZ
# sometimes, the value at 0x18 is less that 0x40 but there's still an
# extended executable, simply appended to the file
>0x18       leshort <0x40
>>(4.s*512) leshort 0x014c  COFF executable (MS-DOS, DJGPP)
>>(4.s*512) leshort !0x014c MZ executable (MS-DOS)
```

Sometimes you do not know the exact offset as this depends on the length or position (when indirection was used before) of preceding fields. You can specify an offset relative to the end of the last up-level field using ‘&’ as a prefix to the offset:

```
0           string  MZ
>0x18       leshort >0x3f
>>(0x3c.l)  string  PE\0\0    PE executable (MS-Windows)
# immediately following the PE signature is the CPU type
>>>&0       leshort 0x14c     for Intel 80386
>>>&0       leshort 0x184     for DEC Alpha
```

Indirect and relative offsets can be combined:

```
0             string  MZ
>0x18         leshort <0x40
>>(4.s*512)   leshort !0x014c MZ executable (MS-DOS)
# if it's not COFF, go back 512 bytes and add the offset taken
# from byte 2/3, which is yet another way of finding the start
# of the extended executable
>>>&(2.s-514) string  LE      LE executable (MS Windows VxD driver)
```

Or the other way around:

```
0                 string  MZ
>0x18             leshort >0x3f
>>(0x3c.l)        string  LE\0\0  LE executable (MS-Windows)
# at offset 0x80 (-4, since relative offsets start at the end
# of the up-level match) inside the LE header, we find the absolute
# offset to the code area, where we look for a specific signature
>>>(&0x7c.l+0x26) string  UPX     \b, UPX compressed
```

Or even both!

```
0                string  MZ
>0x18            leshort >0x3f
>>(0x3c.l)       string  LE\0\0 LE executable (MS-Windows)
# at offset 0x58 inside the LE header, we find the relative offset
# to a data area where we look for a specific signature
>>>&(&0x54.l-3)  string  UNACE  \b, ACE self-extracting archive
```

If you have to deal with offset/length pairs in your file, even the second value in a parenthesized expression can be taken from the file itself, using another set of parentheses. Note that this additional indirect offset is always relative to the start of the main indirect offset.

```
0                 string       MZ
>0x18             leshort      >0x3f
>>(0x3c.l)        string       PE\0\0 PE executable (MS-Windows)
# search for the PE section called ".idata"...
>>>&0xf4          search/0x140 .idata
# ...and go to the end of it, calculated from start+length;
# these are located 14 and 10 bytes after the section name
>>>>(&0xe.l+(-4)) string       PK\3\4 \b, ZIP self-extracting archive
```

If you have a list of known values at a particular continuation level, and you want to provide a switch-like default case:

```
# clear that continuation level match
>18	clear
>18	lelong	1	one
>18	lelong	2	two
>18	default	x
# print default match
>>18	lelong	x	unmatched 0x%x
```

## SEE ALSO
file(1) - the command that reads this file.

## BUGS
The formats long, belong, lelong, melong, short, beshort, and leshort do not depend on the length of the C data types short and long on the platform, even though the Single UNIX Specification implies that they do. However, as OS X Mountain Lion has passed the Single UNIX Specification validation suite, and supplies a version of file(1) in which they do not depend on the sizes of the C data types and that is built for a 64-bit environment in which long is 8 bytes rather than 4 bytes, presumably the validation suite does not test whether, for example long refers to an item with the same size as the C data type long. There should probably be type names int8, uint8, int16, uint16, int32, uint32, int64, and uint64, and specified-byte-order variants of them, to make it clearer that those types have specified widths.


fzdefaults.xml

package: filezilla

title: fzdefaults.xml(5)

summary: Default options for FileZilla

text:
# fzdefaults.xml(5)

## NAME
fzdefaults.xml - Default options for FileZilla

## SYNOPSIS
/etc/filezilla/fzdefaults.xml

~/.filezilla/fzdefaults.xml

## DESCRIPTION
This configuration file can be used to specify some system‐wide default options for FileZilla:

- Location of user's settings directory

- Predefined list of Sitemanager entries

- Kiosk mode to prevent FileZilla from saving any passwords

- Disabling of update check capablity

Please search for the file fzdefaults.xml.example for further information. It is often found in the /usr/share/filezilla/docs directory.

## SUPPORT
Please visit https://filezilla-project.org/ for further information. Report bugs only if you are using the latest version available from the FileZilla website.

## COPYRIGHT
Copyright (C) 2004-2026 Tim Kosse

FileZilla is distributed under the terms of the GNU General Public License version 2 or later.

## SEE ALSO
filezilla(1)


firehol-action

package: firehol

title: firehol-action(5)

text:
# firehol-action(5)

## 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(8) 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(1). 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(8) use the -E and for su(1) 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 using /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(8) 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 iptables-save(8) to the location given by FIREHOL_AUTOSAVE. See firehol-defaults.conf(5) for more information.

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(8) statements.

explain

Enters an interactive mode where FireHOL accepts normal configuration commands and presents the generated iptables(8) 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.

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

## SEE ALSO
•

firehol.conf(5) - FireHOL configuration

•

firehol-defaults.conf(5) - control variables

•

FireHOL Website (http://firehol.org/)

•

FireHOL Online PDF Manual (http://firehol.org/firehol-manual.pdf)

•

FireHOL Online Documentation (http://firehol.org/documentation/)

## AUTHORS
FireHOL Team; Original man page by Marc Brockschmidt.


firehol-actions

title: firehol-actions(5)

summary: actions for rules

text:
# firehol-actions(5)

## NAME
firehol-actions - actions for rules

## SYNOPSIS
accept

accept with hashlimit name upto|above amount/period [burst amount] [mode {srcip|srcport|dstip|dstport},...] [srcmask prefix] [dstmask prefix] [htable-size buckets] [htable-max entries] [htable-expire msec] [htable-gcinterval msec]

accept with connlimit upto|above limit [mask mask] [saddr|daddr]

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 more information see log and loglimit.

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 hashlimit name upto|above
amount/period [burst amount] [mode {srcip|srcport|dstip|dstport},...] [srcmask prefix] [dstmask prefix] [htable-size buckets] [htable-max entries] [htable-expire msec] [htable-gcinterval msec]

hashlimit hashlimit uses hash buckets to express a rate limiting match (like the limit match) for a group of connections using a single iptables rule. Grouping can be done per-hostgroup (source and/or destination address) and/or per-port.

name The name for the /proc/net/ipt_hashlimit/name entry.

upto amount[/second|/minute|/hour|/day] Match if the rate is below or equal to amount/quantum. It is specified either as a number, with an optional time quantum suffix (the default is 3/hour).

above amount[/second|/minute|/hour|/day] Match if the rate is above amount/quantum.

burst amount Maximum initial number of packets to match: this number gets recharged by one every time the limit specified above is not reached, up to this number; the default is 5. This option should be used with caution - if the entry expires, the burst value is reset too.

mode {srcip|srcport|dstip|dstport},... A comma-separated list of objects to take into consideration. If no mode option is given, srcip,dstport is assumed.

srcmask prefix When --hashlimit-mode srcip is used, all source addresses encountered will be grouped according to the given prefix length and the so-created subnet will be subject to hashlimit. prefix must be between (inclusive) 0 and 32. Note that srcmask 0 is basically doing the same thing as not specifying srcip for mode, but is technically more expensive.

dstmask prefix Like srcmask, but for destination addresses.

htable-size buckets The number of buckets of the hash table

htable-max entries Maximum entries in the hash.

htable-expire msec After how many milliseconds do hash entries expire.

htable-gcinterval msec How many milliseconds between garbage collection intervals.

Examples:

Allow up to 5 connections per second per client to SMTP server:

```
server smtp accept with hashlimit smtplimit upto 5/s
```

You can monitor it using the file /proc/net/ipt_hashlimit/smtplimit

### accept with connlimit upto|above limit [mask mask]
[saddr|daddr]

accept with connlimit matches on the number of connections per IP.

saddr matches on source IP. daddr matches on destination IP. mask groups IPs with the mask given upto matches when the number of connections is up to the given limit above matches when the number of connections above to the given limit

The number of connections counted are system wide, not service specific. For example for saddr, you cannot connlimit 2 connections for SSH and 4 for SMTP. If you connlimit 2 connections for SSH, then the first 2 connections of a client can be SSH. If a client has already 2 connections to another service, the client will not be able to connect to SSH.

So, connlimit can safely be used:

•

with daddr to limit the connections a server can accept

•

with saddr to limit the total connections per client to all services.

### accept with limit requests/period burst [overflow
action]

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 name seconds hits
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 name
accept with knock allows easy integration with knockd (http://www.zeroflux.org/projects/knock/), 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
reject discards the traffic matching the rules and sends a rejecting message back to the sender.

### reject with message
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 REJECT WITH MESSAGES 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 (http://bugs.sanewall.org/sanewall/issues/10) 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 MESSAGES
The following RFCs contain information relevant to these messages:

•

RFC 1812 (http://www.ietf.org/rfc/rfc1812.txt)

•

RFC 1122 (http://www.ietf.org/rfc/rfc1122.txt)

•

RFC 792 (http://www.ietf.org/rfc/rfc0792.txt)

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.

## SEE ALSO
•

firehol(1) - FireHOL program

•

firehol.conf(5) - FireHOL configuration

•

firehol-interface(5) - interface definition

•

firehol-router(5) - router definition

•

firehol-params(5) - optional rule parameters

•

FireHOL Website (http://firehol.org/)

•

FireHOL Online PDF Manual (http://firehol.org/firehol-manual.pdf)

•

FireHOL Online Documentation (http://firehol.org/documentation/)

## AUTHORS
FireHOL Team.


firehol-blacklist

title: firehol-blacklist(5)

text:
# firehol-blacklist(5)

## NAME
firehol-blacklist - set up a unidirectional or bidirectional blacklist

## SYNOPSIS
{ blacklist | blacklist4 | blacklist6 } [ type ] [ inface device ] [ log "text" ] [ nolog ] [ connlog "text" ] [ loglimit "text" ] [ accounting accounting_name ] ip... [ except rule-params [or rule-params [or ... ]]]

## 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 all is supplied (or no type at all), 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 stateful is supplied, a bidirectional stateful blacklist will be generated. The firewall will REJECT all traffic going to the IP addresses and DROP all traffic coming from them.

The differences between full and stateful are:

1.

stateful is resource efficient, since only the packets that initiate connections are examined. Established connections will never be re-tested against the blacklist.

2.

when using full and an ipset is updated to match the IP of an established connection, this established connection will immediately be blocked too.

If the type input or him, her, it, this, these is supplied, a unidirectional stateful blacklist will be generated. Connections can be established to such IP addresses, but the IP addresses will not be able to connect to the firewall or hosts protected by it.

Using log (log every packet), connlog (log connections once), or loglimit (log packets according to global throttling settings), the text will be logged when matching packets are found.

Using nolog will disable logging for this rule.

Using inface, the blacklist will be created on the interface device only (this includes forwarded traffic).

accounting will update the NFACCT accounting with the name given.

If the keyword except is found, then all the parameters following it are rules to match packets that should excluded from the blacklist (i.e. they are a whitelist for this blacklist). See firehol-params(5) for more details.

Blacklists must be declared before the first router or interface.

IP Lists for abuse, malware, attacks, proxies, anonymizers, etc can be downloaded with the contrib/update-ipsets.sh script. Information about the supported IP Lists can be found at FireHOL IP Lists (http://iplists.firehol.org/)

## EXAMPLES

```
blacklist full 192.0.2.1 192.0.2.2
blacklist input "192.0.2.3 192.0.2.4"
blacklist full inface eth0 log "BADGUY" 192.0.1.1 192.0.1.2
```

## SEE ALSO
•

firehol(1) - FireHOL program

•

firehol.conf(5) - FireHOL configuration

•

FireHOL Website (http://firehol.org/)

•

FireHOL Online PDF Manual (http://firehol.org/firehol-manual.pdf)

•

FireHOL Online Documentation (http://firehol.org/documentation/)

•

FireHOL IP Lists (http://iplists.firehol.org/)

## AUTHORS
FireHOL Team.


firehol-classify

title: firehol-classify(5)

summary: client command

text:
# firehol-classify(5)

## NAME
firehol-client - client command

## SYNOPSIS
{ client | client46 } service action [rule-params]

client4 service action [rule-params]

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 firehol-services(5). Multiple services may be specified, space delimited in quotes.

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

The rule-params define a set of rule parameters to further restrict the traffic that is matched to this service. See firehol-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 client 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
```

## SEE ALSO
•

firehol(1) - FireHOL program

•

firehol.conf(5) - FireHOL configuration

•

firehol-modifiers(5) - ipv4/ipv6 selection

•

firehol-services(5) - services list

•

firehol-actions(5) - actions for rules

•

firehol-params(5) - optional rule parameters

•

firehol-server(5) - server subcommand

•

firehol-interface(5) - interface definition

•

firehol-router(5) - router definition

•

FireHOL Website (http://firehol.org/)

•

FireHOL Online PDF Manual (http://firehol.org/firehol-manual.pdf)

•

FireHOL Online Documentation (http://firehol.org/documentation/)

## AUTHORS
FireHOL Team.


firehol-client

title: firehol-client(5)

summary: client command

text:
# firehol-client(5)

## NAME
firehol-client - client command

## SYNOPSIS
{ client | client46 } service action [rule-params]

client4 service action [rule-params]

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 firehol-services(5). Multiple services may be specified, space delimited in quotes.

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

The rule-params define a set of rule parameters to further restrict the traffic that is matched to this service. See firehol-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 client 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
```

## SEE ALSO
•

firehol(1) - FireHOL program

•

firehol.conf(5) - FireHOL configuration

•

firehol-modifiers(5) - ipv4/ipv6 selection

•

firehol-services(5) - services list

•

firehol-actions(5) - actions for rules

•

firehol-params(5) - optional rule parameters

•

firehol-server(5) - server subcommand

•

firehol-interface(5) - interface definition

•

firehol-router(5) - router definition

•

FireHOL Website (http://firehol.org/)

•

FireHOL Online PDF Manual (http://firehol.org/firehol-manual.pdf)

•

FireHOL Online Documentation (http://firehol.org/documentation/)

## AUTHORS
FireHOL Team.


firehol-conf

title: firehol-conf(5)

text:
# firehol-conf(5)

## NAME
firehol-connmark - set a stateful mark from the connmark group

## SYNOPSIS
{ connmark | connmark46 } value chain rule-params

connmark4 value chain rule-params

connmark6 value chain rule-params

## DESCRIPTION
Marks on packets can be matched by traffic shaping, routing, and firewall rules for controlling traffic.

Note Behaviour changed significantly in FireHOL v3 compared to earlier versions

FireHOL uses iptables masks to break the single 32-bit integer mark value into smaller groups and allows you to set and match them independently. The markdef group definitions to set this up are found in firehol-defaults.conf

The connmark helper command sets values within the connmark group. You can set value between 0 (no mark) and size-1. The default size for connmark is 64, so 63 is highest value possible. The default connmark types are stateful+permanent, meaning the initial match will only be done on NEW packets and the mark will be restored to all packets in the connection.

The chain will be used to find traffic to mark. It can be any of the iptables(8) 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 firehol-params(5) for more details.

Any connmark commands must be declared before the first router or interface.

Note

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

FireQOS will read the FireHOL mark definitions and set up suitable offsets and marks for the various groups. If you are using a different tool, you should look at the emitted firewall to determine the final masks and values to use.

## EXAMPLES

```
 # mark with 1, packets sent by the local machine
 connmark 1 OUTPUT
 # mark with 2, packets routed by the local machine
 connmark 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
 connmark 3 FORWARD proto tcp dport 25 dst 198.51.100.1 src 192.0.2.2
```

## SEE ALSO
•

firehol(1) - FireHOL program

•

firehol.conf(5) - FireHOL configuration

•

firehol-params(5) - optional rule parameters

•

[firehol-mark(5)][keyword-firehol-mark] - set a stateful mark from the usermark group

•

iptables(8) (http://ipset.netfilter.org/iptables.man.html) - administration tool for IPv4 firewalls

•

ip6tables(8) (http://ipset.netfilter.org/ip6tables.man.html) - administration tool for IPv6 firewalls

•

ip(8) - show / manipulate routing, devices, policy routing and tunnels

•

FireHOL Website (http://firehol.org/)

•

Working With Marks Wiki Page (https://github.com/firehol/firehol/wiki/Working-with-MARKs)

•

FireHOL Online PDF Manual (http://firehol.org/firehol-manual.pdf)

•

FireHOL Online Documentation (http://firehol.org/documentation/)

•

Linux Advanced Routing & Traffic Control HOWTO (http://lartc.org/howto/) is variable includes all the IP addresses defined by IANA (http://www.iana.org/) 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 (https://tools.ietf.org/html/rfc3330).

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(8) 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 firehol-defaults.conf(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 firehol-defaults.conf(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:

```
    # Setup service
    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(8) 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(1) script.

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.

## DEFINITIONS
•

firehol-interface(5) - interface definition

•

firehol-router(5) - router definition

## SUBCOMMANDS
•

firehol-policy(5) - policy command

•

firehol-protection(5) - protection command

•

firehol-server(5) - server, route commands

•

firehol-client(5) - client command

•

firehol-group(5) - group command

## HELPER COMMANDS
These helpers can be used in interface and router definitions as well as before them:

•

firehol-iptables(5) - iptables helper

•

firehol-masquerade(5) - masquerade helper

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

•

firehol-tcpmss(5) - tcpmss helper

## CONFIGURATION HELPER COMMANDS
These helpers should only be used outside of interface and router definitions (i.e. before the first interface is defined).

•

firehol-version(5) - version config helper

•

firehol-action(5) - action config helper

•

firehol-blacklist(5) - blacklist config helper

•

firehol-classify(5) - classify config helper

•

firehol-connmark(5) - connmark config helper

•

firehol-dscp(5) - dscp config helper

•

firehol-mac(5) - mac config helper

•

firehol-mark(5) - mark config helper

•

firehol-nat(5) - nat, snat, dnat, redirect helpers

•

firehol-proxy(5) - transparent proxy/squid helpers

•

firehol-tos(5) - tos config helper

•

firehol-tosfix(5) - tosfix config helper

## SEE ALSO
•

firehol(1) - FireHOL program

•

firehol-defaults.conf(5) - control variables

•

firehol-services(5) - services list

•

firehol-actions(5) - actions for rules

•

FireHOL Website (http://firehol.org/)

•

FireHOL Online PDF Manual (http://firehol.org/firehol-manual.pdf)

•

FireHOL Online Documentation (http://firehol.org/documentation/)

## AUTHORS
FireHOL Team.


firehol-connmark

title: firehol-connmark(5)

text:
# firehol-connmark(5)

## NAME
firehol-connmark - set a stateful mark from the connmark group

## SYNOPSIS
{ connmark | connmark46 } value chain rule-params

connmark4 value chain rule-params

connmark6 value chain rule-params

## DESCRIPTION
Marks on packets can be matched by traffic shaping, routing, and firewall rules for controlling traffic.

Note Behaviour changed significantly in FireHOL v3 compared to earlier versions

FireHOL uses iptables masks to break the single 32-bit integer mark value into smaller groups and allows you to set and match them independently. The markdef group definitions to set this up are found in firehol-defaults.conf

The connmark helper command sets values within the connmark group. You can set value between 0 (no mark) and size-1. The default size for connmark is 64, so 63 is highest value possible. The default connmark types are stateful+permanent, meaning the initial match will only be done on NEW packets and the mark will be restored to all packets in the connection.

The chain will be used to find traffic to mark. It can be any of the iptables(8) 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 firehol-params(5) for more details.

Any connmark commands must be declared before the first router or interface.

Note

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

FireQOS will read the FireHOL mark definitions and set up suitable offsets and marks for the various groups. If you are using a different tool, you should look at the emitted firewall to determine the final masks and values to use.

## EXAMPLES

```
 # mark with 1, packets sent by the local machine
 connmark 1 OUTPUT
 # mark with 2, packets routed by the local machine
 connmark 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
 connmark 3 FORWARD proto tcp dport 25 dst 198.51.100.1 src 192.0.2.2
```

## SEE ALSO
•

firehol(1) - FireHOL program

•

firehol.conf(5) - FireHOL configuration

•

firehol-params(5) - optional rule parameters

•

[firehol-mark(5)][keyword-firehol-mark] - set a stateful mark from the usermark group

•

iptables(8) (http://ipset.netfilter.org/iptables.man.html) - administration tool for IPv4 firewalls

•

ip6tables(8) (http://ipset.netfilter.org/ip6tables.man.html) - administration tool for IPv6 firewalls

•

ip(8) - show / manipulate routing, devices, policy routing and tunnels

•

FireHOL Website (http://firehol.org/)

•

Working With Marks Wiki Page (https://github.com/firehol/firehol/wiki/Working-with-MARKs)

•

FireHOL Online PDF Manual (http://firehol.org/firehol-manual.pdf)

•

FireHOL Online Documentation (http://firehol.org/documentation/)

•

Linux Advanced Routing & Traffic Control HOWTO (http://lartc.org/howto/) is variable includes all the IP addresses defined by IANA (http://www.iana.org/) 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 (https://tools.ietf.org/html/rfc3330).

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(8) 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 firehol-defaults.conf(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 firehol-defaults.conf(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:

```
    # Setup service
    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(8) 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(1) script.

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.

## DEFINITIONS
•

firehol-interface(5) - interface definition

•

firehol-router(5) - router definition

## SUBCOMMANDS
•

firehol-policy(5) - policy command

•

firehol-protection(5) - protection command

•

firehol-server(5) - server, route commands

•

firehol-client(5) - client command

•

firehol-group(5) - group command

## HELPER COMMANDS
These helpers can be used in interface and router definitions as well as before them:

•

firehol-iptables(5) - iptables helper

•

firehol-masquerade(5) - masquerade helper

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

•

firehol-tcpmss(5) - tcpmss helper

## CONFIGURATION HELPER COMMANDS
These helpers should only be used outside of interface and router definitions (i.e. before the first interface is defined).

•

firehol-version(5) - version config helper

•

firehol-action(5) - action config helper

•

firehol-blacklist(5) - blacklist config helper

•

firehol-classify(5) - classify config helper

•

firehol-connmark(5) - connmark config helper

•

firehol-dscp(5) - dscp config helper

•

firehol-mac(5) - mac config helper

•

firehol-mark(5) - mark config helper

•

firehol-nat(5) - nat, snat, dnat, redirect helpers

•

firehol-proxy(5) - transparent proxy/squid helpers

•

firehol-tos(5) - tos config helper

•

firehol-tosfix(5) - tosfix config helper

## SEE ALSO
•

firehol(1) - FireHOL program

•

firehol-defaults.conf(5) - control variables

•

firehol-services(5) - services list

•

firehol-actions(5) - actions for rules

•

FireHOL Website (http://firehol.org/)

•

FireHOL Online PDF Manual (http://firehol.org/firehol-manual.pdf)

•

FireHOL Online Documentation (http://firehol.org/documentation/)

## AUTHORS
FireHOL Team.


firehol-cthelper

title: firehol-cthelper(5)

summary: set the DSCP field in the packet header

text:
# firehol-cthelper(5)

## 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 firehol-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(8) 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(8) 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 firehol-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(1) - FireHOL program

•

firehol.conf(5) - FireHOL configuration

•

firehol-params(5) - optional rule parameters

•

iptables(8) (http://ipset.netfilter.org/iptables.man.html) - administration tool for IPv4 firewalls

•

ip6tables(8) (http://ipset.netfilter.org/ip6tables.man.html) - administration tool for IPv6 firewalls

•

ip(8) - show / manipulate routing, devices, policy routing and tunnels

•

FireHOL Website (http://firehol.org/)

•

FireHOL Online PDF Manual (http://firehol.org/firehol-manual.pdf)

•

FireHOL Online Documentation (http://firehol.org/documentation/)

•

Linux Advanced Routing & Traffic Control HOWTO (http://lartc.org/howto/)

## AUTHORS
FireHOL Team.


firehol-defaults-conf

title: firehol-defaults-conf(5)

text:
# firehol-defaults-conf(5)

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

## SEE ALSO
•

firehol(1) - FireHOL program

•

firehol.conf(5) - FireHOL configuration

•

FireHOL Website (http://firehol.org/)

•

FireHOL Online PDF Manual (http://firehol.org/firehol-manual.pdf)

•

FireHOL Online Documentation (http://firehol.org/documentation/)

## AUTHORS
FireHOL Team.


firehol-dscp

title: firehol-dscp(5)

summary: set the DSCP field in the packet header

text:
# firehol-dscp(5)

## 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 firehol-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(8) 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(8) 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 firehol-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(1) - FireHOL program

•

firehol.conf(5) - FireHOL configuration

•

firehol-params(5) - optional rule parameters

•

iptables(8) (http://ipset.netfilter.org/iptables.man.html) - administration tool for IPv4 firewalls

•

ip6tables(8) (http://ipset.netfilter.org/ip6tables.man.html) - administration tool for IPv6 firewalls

•

ip(8) - show / manipulate routing, devices, policy routing and tunnels

•

FireHOL Website (http://firehol.org/)

•

FireHOL Online PDF Manual (http://firehol.org/firehol-manual.pdf)

•

FireHOL Online Documentation (http://firehol.org/documentation/)

•

Linux Advanced Routing & Traffic Control HOWTO (http://lartc.org/howto/)

## AUTHORS
FireHOL Team.


firehol-group

title: firehol-group(5)

summary: group commands with common options

text:
# firehol-group(5)

## 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 firehol-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
```

## SEE ALSO
•

firehol(1) - FireHOL program

•

firehol.conf(5) - FireHOL configuration

•

firehol-interface(5) - interface definition

•

firehol-router(5) - router definition

•

firehol-params(5) - optional rule parameters

•

FireHOL Website (http://firehol.org/)

•

FireHOL Online PDF Manual (http://firehol.org/firehol-manual.pdf)

•

FireHOL Online Documentation (http://firehol.org/documentation/)

## AUTHORS
FireHOL Team.


firehol-interface

title: firehol-interface(5)

summary: group commands with common options

text:
# firehol-interface(5)

## 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 [firehol-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
```

## SEE ALSO
•

[firehol(1)][] - FireHOL program

•

[firehol.conf(5)][] - FireHOL configuration

•

[firehol-interface(5)][keyword-firehol-interface] - interface definition

•

[firehol-router(5)][keyword-firehol-router] - router definition

•

[firehol-params(5)][] - optional rule parameters

•

FireHOL Website (http://firehol.org/)

•

FireHOL Online PDF Manual (http://firehol.org/firehol-manual.pdf)

•

FireHOL Online Documentation (http://firehol.org/documentation/)

## AUTHORS
FireHOL Team.


firehol-ipset

title: firehol-ipset(5)

summary: configure ipsets

text:
# firehol-ipset(5)

## NAME
firehol-ipset - configure ipsets

## SYNOPSIS
ipset command name options

## DESCRIPTION
FireHOL has an ipset helper. It is a wrapper around the real ipset command and is handled internally within FireHOL in such a way so that the ipset collections defined in the configuration will be activated before activating the firewall.

FireHOL is also smart enough to restore the ipsets after a reboot, before it restores the firewall, so that everything will work as seamlessly as possible.

The ipset helper has the same syntax with the real ipset command. So in FireHOL you just add the ipset statements you need, and FireHOL will do the rest.

Keep in mind that each ipset collection is either IPv4 or IPv6. In FireHOL prefix ipset with either ipv4 or ipv6 and FireHOL will choose the right IP version (there is also ipset4 and ipset6).

Also, do not add -! to ipset statements given in firehol.conf. FireHOL will batch import all ipsets and this option is not needed.

## FireHOL ipset extensions
The features below are extensions of ipset that can only be used from within firehol.conf. They will not work on a terminal.

The FireHOL helper allows mass import of ipset collections from files. This is done with ipset addfile command.

The ipset addfile command will get a filename, remove all comments (anything after a # on the same line), trim any empty lines and spaces, and add all the remaining lines to ipset, as if each line of the file was run with ipset add COLLECTION_NAME IP_FROM_FILE [other options].

The syntax of the ipset addfile command is:

```
 ipset addfile *name* [ip|net] *filename* [*other ipset add options*]
```

name is the collection to add the IPs.

ip is optional and will select all the lines of the file that do not contain a /.

net is optional and will select all the lines of the file that contain a /.

filename is the filename to read. You can give absolute filenames and relative filenames (to /etc/firehol).

other ipset add options is whatever else ipset add supports, that you are willing to give for each line.

The ipset add command implemented in FireHOL also allows you to give multiple IPs separated by comma or enclosed in quotes and separated by space.

## EXAMPLES

```
 ipv4 ipset create badguys hash:ip
 ipv4 ipset add badguys 1.2.3.4
 ipv4 ipset addfile badguys file-with-the-bad-guys-ips.txt
 ...
 ipv4 blacklist full ipset:badguys
 # example with multiple IPs
 ipv4 ipset create badguys hash:ip
 ipv4 ipset add badguys 1.2.3.4,5.6.7.8,9.10.11.12 # << comma separated
 ipv4 ipset add badguys "11.22.33.44 55.66.77.88"  # << space separated in quotes
```

ipsets with IP Lists for abuse, malware, attacks, proxies, anonymizers, etc can be downloaded with the contrib/update-ipsets.sh script. Information about the supported ipsets can be found at FireHOL IP Lists (http://iplists.firehol.org/)

## SEE ALSO
•

firehol(1) - FireHOL program

•

firehol.conf(5) - FireHOL configuration

•

firehol-interface(5) - interface definition

•

firehol-router(5) - router definition

•

firehol-params(5) - optional rule parameters

•

firehol-masquerade(5) - masquerade helper

•

FireHOL Website (http://firehol.org/)

•

FireHOL Online PDF Manual (http://firehol.org/firehol-manual.pdf)

•

FireHOL Online Documentation (http://firehol.org/documentation/)

•

FireHOL IP Lists (http://iplists.firehol.org/)

•

NAT HOWTO (http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-6.html)

•

netfilter flow diagram (http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg)

## AUTHORS
FireHOL Team.