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

summary: set up custom filtering actions

text:
# firehol-action(5)

## NAME
firehol-action - set up custom filtering actions

## SYNOPSIS
action name [table table_name] type type_params [ next [ type type_params [ next ] ] ]

## DESCRIPTION
The action helper creates custom actions that can be used everywhere in FireHOL, like this:

```
action ACT1 chain accept
interface any world
    server smtp ACT1
router myrouter
    policy ACT1
```

The action helper allows linking multiple actions together and having some logic to select which action to execute, like this:

```
action ACT1 \
         rule src 192.168.0.0/16 action reject \
    next rule dst 192.168.0.0/16 action reject \
    next rule inface eth2 action drop \
    next rule outface eth2 action drop \
    next action accept
interface any world
    server smtp ACT1
router myrouter
    policy ACT1
```

There is no limit on the number of actions that can be linked together.

type can be chain or action (chain and action are aliases), rule, iptrap, ipuntrap or sockets_suspects_trap.

### Chain type actions
This is the simpler action. It creates an iptables(8) chain which can be used to control the action of other firewall rules once the firewall is running.

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

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

Note

The names created with this command are case-sensitive.

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

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

```
action ACT1 chain accept
interface any world
    server smtp ACT1
    client smtp ACT1
```

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

```
iptables -t filter -I ACT1 -j DROP
```

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

```
iptables -t filter -D ACT1 -j DROP
```

Note

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

### Rule type actions
rule type actions define a few conditions that will lead to an action.

All optional rule parameters FireHOL supports can be used here (see firehol-params(5)).

```
action ACT1 \
    rule inface eth0 action accept
    next rule outface eth0 action accept
    next action reject
interface any world
    server smtp ACT1
```

In the above example the smtp server can only be accessed from eth0.

It is important to remember that actions will be applied for all the traffic, both requests and replies. The type of traffic can be filtered with the state optional rule parameter, like this:

```
action ACT1 \
    rule inface eth0 state NEW action reject
    next action accept
interface any world
    server smtp ACT1
    client smtp ACT1
```

In the above example, the smtp server will not accept NEW connections from eth0, but the smtp client will be able to connect to servers on eth0 (and everywhere else).

### iptrap type actions
iptrap (see [firehol-iptrap(5)][]) is a helper than copies (traps) an IP to an ipset (see [firehol-ipset(5)][]). It does not perform any action on the traffic.

Using the iptrap action, the iptrap helper can be linked to filtering actions, like this:

```
 # a simple version of TRAP_AND_REJECT
 # this uses just 2 ipsets, one for counting packets (policytrap)
 # and one to store the banned IPs (trap).
 # it also needs a ipset called whitelist, for excluded source IPs.
 # it will ban IPs when they have 50+ reject packets
 action4 TRAP_AND_REJECT \
    rule iptrap src policytrap 30 inface "${wan}" \
        src not "${UNROUTABLE_IPS} ipset:whitelist" \
        state NEW log "POLICY TRAP" \
    next iptrap trap src 86400 \
        state NEW log "POLICY TRAP - BANNED" \
        ipset policytrap src no-counters packets-above 50 \
    next action reject
 # a complete TRAP_AND_REJECT
 # this uses 3 ipset, one for keeping track of the rejected sockets
 # per source IP (called 'sockets'), one for counting the sockets
 # per source IP (called 'suspects') and one to store the banned IPs
 # (called 'trap').
 # it also needs a ipset called whitelist, for excluded source IPs.
 # it will ban IPs when they have 3 or more rejected sockets
 action4 TRAP_AND_REJECT \
    iptrap sockets src,dst,dst 3600 method hash:ip,port,ip counters \
        state NEW log "TRAP AND REJECT - NEW SOCKET" \
        inface "${wan}" \
        src not "${UNROUTABLE_IPS} ipset:whitelist" \
    next iptrap suspects src 3600 counters \
        state NEW log "TRAP AND REJECT - NEW SUSPECT" \
        ipset sockets src,dst,dst no-counters packets 1 \
    next iptrap trap src 86400 \
        state NEW log "TRAP AND REJECT - BANNED" \
        ipset suspects src no-counters packets-above 2 \
    next action REJECT
 interface any world
    policy TRAP_AND_REJECT
    protection bad-packets
    ...
 router wan2lan inface "${wan}" outface "${lan}"
    policy TRAP_AND_REJECT
    protection bad-packets
    ...
```

Since we used the action TRAP_AND_REJECT as an interface policy, it will get all the traffic not accepted, rejected, or dropped by the server and client statements.

For all these packets, the action TRAP_AND_REJECT will first check that they are coming in from wan0, that their src IP is not in UNROUTABLE_IPS list and in the whitelist ipset, that they are NEW connections, and if all these conditions are met, it will log with the tag POLICY TRAP and add the src IP of the packets in the policytrap ipset for 30 seconds.

All traffic not matched by the above, will be just rejected.

### sockets_suspects_trap type actions
The type sockets_suspects_trap will automatically a custom trap using the following template:

```
action4 *name* sockets_suspects_trap *SUSPECTS_TIMEOUT* *TRAP_TIMEOUT* *VALID_CONNECTIONS* [*optional params*] next ...
```

This will:

1.

Create the ipset ${name}_sockets where the matched sockets will be stored for SUSPECTS_TIMEOUT seconds.

2.

Create the ipset ${name}_suspects where the source IPs of the matched sockets will be stored for SUSPECTS_TIMEOUT seconds.

3.

Create the ipset ${name}_trap where the trapped IPs will be stored for TRAP_TIMEOUT seconds. IPs will be added to this ipset only if more than VALID_CONNECTIONS have been matched by this IP.

optional params are FireHOL optional rule parameters (firehol-params(5)) that can be used to limit the match for the first ipset (sockets).

So, to design the same TRAP_AND_REJECT as above, this statement is needed:

```
action4 TRAP_AND_REJECT \
    sockets_suspects_trap 3600 86400 2 \
        inface "${wan}" \
        src not "${UNROUTABLE_IPS} ipset:whitelist" \
    next action REJECT
```

The ipsets that will be created will be named: TRAP_AND_REJECT_sockets, TRAP_AND_REJECT_suspects and TRAP_AND_REJECT_trap.

Note Always terminate sockets_suspects_trap with a next action DROP or next action REJECT, or the traffic will continue to flow.

## SEE ALSO
•

firehol(1) - FireHOL program

•

firehol.conf(5) - FireHOL configuration

•

firehol-actions(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

•

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-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" ] [ 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 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)

text:
# firehol-classify(5)

## NAME
firehol-classify - classify traffic for traffic shaping tools

## SYNOPSIS
{ classify | classify46 } class [rule-params]

classify4 class [rule-params]

classify6 class [rule-params]

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

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

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

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

## EXAMPLES

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

## SEE ALSO
•

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

•

tc(8) - show / manipulate traffic control settings

•

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

summary: FireHOL configuration

text:
# firehol-conf(5)

## NAME
firehol.conf - FireHOL configuration

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

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

```
version 6

```

See firehol-version(1) for full details.

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

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

```

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

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

Note that IPv6 will be disabled silently if your system is not configured to use it. You can test this by looking for the file /proc/net/if_inet6. The IPv6 HOWTO (http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/systemcheck-kernel.html) has more information.

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

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

```

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

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

It is simple to add extra service definitions which can then be used in the same way as those provided as standard. See ADDING SERVICES.

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

Special control variables may be set up and used outside of any definition, see firehol-defaults.conf(5) as can the functions in CONFIGURATION HELPER COMMANDS and HELPER COMMANDS.

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

UNROUTABLE_IPS

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

```
interface eth0 internet src not "${UNROUTABLE_IPS}"
```

PRIVATE_IPS

This variable includes all the IP addresses defined as Private or Test by RFC 3330 (https://tools.ietf.org/html/rfc3330).

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

RESERVED_IPS

This variable includes all the IP addresses defined by IANA (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/)

## AUTHORS
FireHOL Team.


firehol-cthelper

title: firehol-cthelper(5)

summary: control connection tracking helpers

text:
# firehol-cthelper(5)

## NAME
firehol-cthelper - control connection tracking helpers

## SYNOPSIS
{ cthelper | cthelper4 | cthelper6 } protocol helper where [rule-params]

## DESCRIPTION
The netfilter team has included in the Linux kernel protocol helpers that monitor traffic and allow them to work under the connection tracker.

The following protocol helpers have been provided:

•

amanda

•

ftp

•

tftp (cannot be configured)

•

h323 (cannot be configured)

•

irc (does not support IPv6)

•

netbios_ns (cannot be configured)

•

pptp (does not support IPv6)

•

gre (cannot be configured)

•

sane

•

sip

By default, the helpers will trust either side of the communication. This is considered a security issue and should be avoided.

Using cthelper the helpers that can be configured, can be instructed to trust a specific side of the communication.

Before doing so, the variable FIREHOL_CONNTRACK_HELPERS_ASSIGNMENT should be set to manual.

where defines where the trusted traffic is expected. It can be:

•

IN, INPUT, or PREROUTING to match incoming packets

•

OUT, OUTPUT to match outgoing packets

•

BOTH, BIDIRECTIONAL, or INOUT to match all packets

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

FIREHOL_CONNTRACK_HELPERS_ASSIGNMENT accepts the following values:

•

kernel which is the default, allows the kernel to determine by itself which side to trust.

•

firehol to have FireHOL automatically generate cthelper statements keeping src, dst, inface and outface from the statements that require each helper. Keep in mind this will only generate valid statements if you don't use NAT at all. cthelper statements are executed by iptables before any NAT is applied, while packet filtering is configured after DNAT and before SNAT, resulting in wrong statements when NAT is applied.

•

manual to use the cthelper helper to configure the trusts in firehol.conf.

When set to kernel, FireHOL will set net.netfilter.nf_conntrack_helper=1. In all other cases, FireHOL will set net.netfilter.nf_conntrack_helper=0.

## EXAMPLES

```
 # enable manual protocol helpers mode
 FIREHOL_CONNTRACK_HELPERS_ASSIGNMENT="manual"
 # trust SIP packets we send via interface dsl0
 cthelper sip out outface dsl0
 # trust SIP packets we receive from 10.0.0.1 via eth0
 cthelper sip in inface eth0 src 10.0.0.1
 # trust pptp packets we send via interface wan0 (IPv4 only)
 cthelper4 pptp out outface wan0
```

## 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-defaults-conf

title: firehol-defaults-conf(5)

summary: control variables for FireHOL

text:
# firehol-defaults-conf(5)

## NAME
firehol-defaults.conf - control variables for FireHOL

## SYNOPSIS
Defaults in /etc/firehol/firehol-defaults.conf:

•

DEFAULT_INTERFACE_POLICY="DROP"

•

DEFAULT_ROUTER_POLICY="RETURN"

•

UNMATCHED_INPUT_POLICY="DROP"

•

UNMATCHED_OUTPUT_POLICY="DROP"

•

UNMATCHED_FORWARD_POLICY="DROP"

•

FIREHOL_INPUT_ACTIVATION_POLICY="ACCEPT"

•

FIREHOL_OUTPUT_ACTIVATION_POLICY="ACCEPT"

•

FIREHOL_FORWARD_ACTIVATION_POLICY="ACCEPT"

•

FIREHOL_LOG_MODE="LOG"

•

FIREHOL_LOG_LEVEL=see notes

•

FIREHOL_LOG_OPTIONS="--log-level warning"

•

FIREHOL_LOG_FREQUENCY="1/second"

•

FIREHOL_LOG_BURST="5"

•

FIREHOL_LOG_PREFIX=""

•

FIREHOL_DROP_INVALID="0"

•

DEFAULT_CLIENT_PORTS="1000:65535"

•

FIREHOL_NAT="0"

•

FIREHOL_ROUTING="0"

•

FIREHOL_AUTOSAVE=see notes

•

FIREHOL_AUTOSAVE6=see notes

•

FIREHOL_LOAD_KERNEL_MODULES="1"

•

FIREHOL_TRUST_LOOPBACK="1"

•

FIREHOL_DROP_ORPHAN_TCP_ACK_FIN="1"

•

FIREHOL_DROP_ORPHAN_TCP_ACK_RST="1"

•

FIREHOL_DROP_ORPHAN_TCP_ACK="1"

•

FIREHOL_DROP_ORPHAN_TCP_RST="1"

•

FIREHOL_DROP_ORPHAN_IPV4_ICMP_TYPE3="1"

•

WAIT_FOR_IFACE=""

## DESCRIPTION
From FireHOL 3 upwards, variables which control FireHOL behaviour are held in a separate file: /etc/firehol/firehol-defaults.conf.

Some variables can also be set in the main firehol.conf file but that is not recommended, since they may be used before the main configuration is processed.

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

## VARIABLES
DEFAULT_INTERFACE_POLICY

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

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

Example:

```
DEFAULT_INTERFACE_POLICY="REJECT"
```

DEFAULT_ROUTER_POLICY

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

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

Example:

```
DEFAULT_ROUTER_POLICY="REJECT"
```

UNMATCHED_{INPUT|OUTPUT|FORWARD}_POLICY

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

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

Example:

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

FIREHOL_{INPUT|OUTPUT|FORWARD}_ACTIVATION_POLICY

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

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

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

Example:

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

FIREHOL_LOG_MODE

This variable controls method that FireHOL uses for logging.

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

Example:

```
FIREHOL_LOG_MODE="ULOG"
```

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

FIREHOL_LOG_LEVEL

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

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

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

iptables/klogd levels

iptables

klogd

description

emerg (0)

0

system is unusable

alert (1)

1

action must be taken immediately

crit (2)

2

critical conditions

error (3)

3

error conditions

warning (4)

4

warning conditions

notice (5)

5

normal but significant condition

info (6)

6

informational

debug (7)

7

debug-level messages

Note

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

FIREHOL_LOG_OPTIONS

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

Example:

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

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

FIREHOL_LOG_FREQUENCY; FIREHOL_LOG_BURST

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

Example:

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

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

FIREHOL_LOG_PREFIX

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

Example:

```
FIREHOL_LOG_PREFIX="FIREHOL:"
```

FIREHOL_DROP_INVALID

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

You may be better off using firehol-protection(5) to control matching of INVALID packets and others on a per-interface and per-router basis.

Note

Care must be taken on IPv6 interfaces, since ICMPv6 packets such as Neighbour Discovery are not tracked, meaning they are marked as INVALID.

Example:

```
FIREHOL_DROP_INVALID="1"
```

DEFAULT_CLIENT_PORTS

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

Example:

```
DEFAULT_CLIENT_PORTS="0:65535"
```

FIREHOL_NAT

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

Example:

```
FIREHOL_NAT="1"
```

FIREHOL_ROUTING

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

Example:

```
FIREHOL_ROUTING="1"
```

FIREHOL_AUTOSAVE; FIREHOL_AUTOSAVE6

These variables specify the file of IPv4/IPv6 rules that will be created when firehol(1) is called with the save argument.

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

Example:

```
FIREHOL_AUTOSAVE="/tmp/firehol-saved-ipv4.txt"
FIREHOL_AUTOSAVE6="/tmp/firehol-saved-ipv6.txt"
```

FIREHOL_LOAD_KERNEL_MODULES

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

Example:

```
FIREHOL_LOAD_KERNEL_MODULES="0"
```

FIREHOL_TRUST_LOOPBACK

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

Warning

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

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

Example:

```
FIREHOL_TRUST_LOOPBACK="0"
```

FIREHOL_DROP_ORPHAN_TCP_ACK_FIN

If set to 1, FireHOL will drop all orphan such packets without logging them.

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

Example:

```
FIREHOL_DROP_ORPHAN_TCP_ACK_FIN="1"
```

FIREHOL_DROP_ORPHAN_TCP_ACK_RST

If set to 1, FireHOL will drop all orphan such packets without logging them.

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

Example:

```
FIREHOL_DROP_ORPHAN_TCP_ACK_RST="1"
```

FIREHOL_DROP_ORPHAN_TCP_ACK

If set to 1, FireHOL will drop all orphan such packets without logging them.

In busy environments the iptables(8) connection tracker removes unneeded connection tracking list entries. This makes ACK packets appear as an invalid packet which will normally be logged by FireHOL.

Example:

```
FIREHOL_DROP_ORPHAN_TCP_ACK="1"
```

FIREHOL_DROP_ORPHAN_TCP_RST

If set to 1, FireHOL will drop all orphan such packets without logging them.

In busy environments the iptables(8) connection tracker removes unneeded connection tracking list entries. This makes RST packets appear as an invalid packet which will normally be logged by FireHOL.

Example:

```
FIREHOL_DROP_ORPHAN_TCP_RST="1"
```

FIREHOL_DROP_ORPHAN_IPV4_ICMP_TYPE3

If set to 1, FireHOL will drop all orphan ICMP destination unreachable packets without logging them.

In busy environments the iptables(8) connection tracker removes unneeded connection tracking list entries. This makes ICMP destination unreachable appear as an invalid packet which will normally be logged by FireHOL.

Example:

```
FIREHOL_DROP_ORPHAN_IPV4_ICMP_TYPE3="1"
```

WAIT_FOR_IFACE

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

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

Example:

```
WAIT_FOR_IFACE="eth0"
```

## SEE ALSO
•

firehol(1) - FireHOL program

•

firehol.conf(5) - FireHOL configuration

•

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

•

firehol-actions(5) - actions for rules

•

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

•

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: interface definition

text:
# firehol-interface(5)

## NAME
firehol-interface - interface definition

## SYNOPSIS
{ interface | interface46 } real-interface name rule-params

interface4 real-interface name rule-params

interface6 real-interface name rule-params

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

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

The behaviour of the defined interface is controlled by adding subcommands from those listed in INTERFACE SUBCOMMANDS.

Note

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

Note

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

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

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

## PARAMETERS
real-interface

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

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

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

```
interface "eth0 eth1 ppp0" myname
```

name

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

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

rule-params

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

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

```
interface eth0 intranet src 192.0.2.0/24
interface eth0 internet src not "${UNROUTABLE_IPS}"
```

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

## SEE ALSO
•

firehol(1) - FireHOL program

•

firehol.conf(5) - FireHOL configuration

•

firehol-params(5) - optional rule parameters

•

firehol-modifiers(5) - ipv4/ipv6 selection

•

firehol-router(5) - router definition

•

firehol-iptables(5) - iptables helper

•

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

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

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


firehol-iptables

title: firehol-iptables(5)

summary: include custom iptables commands

text:
# firehol-iptables(5)

## NAME
firehol-iptables - include custom iptables commands

## SYNOPSIS
iptables argument...

ip6tables argument...

## DESCRIPTION
The iptables and ip6tables helper commands pass all of their arguments to the real iptables(8) or ip6tables(8) at the appropriate point during run-time.

Note

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

You should not use /sbin/iptables or /sbin/ip6tables directly in a FireHOL configuration as they will run before FireHOL activates its firewall. This means that the commands are applied to the previously running firewall, not the new firewall, and will be lost when the new firewall is activated.

The iptables and ip6tables helpers are provided to allow you to hook in commands safely.

When using the -t option to specify a table, ensure this is the first option to iptables, otherwise "fast activation" will fail with an error message such as:

```
iptables-restore: The -t option cannot be used in iptables-restore
```

## EXAMPLES
Fix LXC DHCP on same host:

```
iptables -t mangle -A POSTROUTING -p udp --dport 68 -j CHECKSUM --checksum-fill
```

## SEE ALSO
•

firehol(1) - FireHOL program

•

firehol.conf(5) - FireHOL configuration

•

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

•

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

title: firehol-iptrap(5)

text:
# firehol-iptrap(5)

## NAME
firehol-iptrap - dynamically put IP addresses in an ipset

## SYNOPSIS
{ iptrap | iptrap4 | iptrap6 } ipset type seconds [ timeout | counters ] [ method method ] [rule-params] [ except [rule-params] ]...

{ ipuntrap | ipuntrap4 | ipuntrap6 } ipset type [ timeout | counters ] [ method method ] [rule-params] [ except [rule-params] ]...

## DESCRIPTION
iptrap adds the IP addresses of the matching packets to ipset.

ipuntrap deletes the IP addresses of the matching packets from ipset.

Both helpers do not affect the flow of traffic. They do not ACCEPT, REJECT, DROP packets or affect the firewall in any way.

ipset is the name of the ipset to use.

type selects which of the IP addresses of the matching packets will be used (added or removed from the ipset). type can be src, dst, src,dst, dst,src, etc. If type is a pair, then the ipset must be an ipset of pairs too.

seconds is required by iptrap and gives the duration in seconds of the lifetime of each IP address that is added to ipset. Every matching packet will refresh this duration for the IP address in the ipset. The Linux kernel will automatically remove the IP from the ipset when this time expires. The user may monitor the remaining time for each IP, by running ipset list NAME (where NAME is the ipset parameter given in the iptrap command).

The seconds value default will not set any seconds. The ipset default will be used.

A seconds of 0 (zero), writes to the ipset permanently (this is a feature of the ipset command, not the ipset FireHOL helper).

The keywords timeout and counters are mutually exclusive. timeout is the default and means that each IP address every time is matched its timeout will be refreshed, while counters means that its packets and bytes counters will be refreshed. Unfortunately the kernel either re-add the IP in the ipset with the new timeout - but its counters will be lost, or just the counters will be updated, but the timeout will not be refreshed.

method is defines the storage method of the underlying ipset. It accepts all the types the ipset commands accepts.

method and type should match. For example if method is hash:ip then method should be either src or dst. If method is hash:ip,ip then method should be either src,dst or dst,src. If method is hash:ip,port,ip method should be src,src,dst or src,dst,dst or dst,src,src or dst,dst,src. For more information check the manual page of the ipset command.

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

except rule-params are used to exclude traffic, i.e. traffic that normally is matched by the first set of rule-params, will be excluded if matched by the second.

iptrap and ipuntrap are hooked on PREROUTING so it is only useful for incoming traffic.

iptrap and ipuntrap cannot setup both IPv4 and IPv6 traps with one call. The reason is that the ipset can either be IPv4 or IPv6.

Both helpers will create the ipset specified, if that ipset is not already created by other statements. When the ipset is created by the iptrap helper, the ipset will not be reset (emptied) when the firewall is restarted.

The ipset options used when these helpers create ipsets can be controlled with the variable IPTRAP_DEFAULT_IPSET_OPTIONS.

## EXAMPLES

```
 # Example: mini-IDS
 # add to the ipset `trap` for an hour (3600 seconds) all IPs from all packets
 # coming from eth0 and going to tcp/3306 (mysql).
 iptrap4 src trap 3600 inface eth0 proto tcp dport 3306 log "TRAPPED HTTP"
 # block them
 blacklist4 full inface eth0 log "BLOCKED" src ipset:trap except src ipset:whitelist
 # Example: ipuntrap
 ipuntrap4 src trap inface eth0 src ipset:trap proto tcp dport 80 log "UNTRAPPED HTTP"
 # Example: a knock
 # The user will be able to knock at tcp/12345
 iptrap4 src knock1 30 inface eth0 proto tcp dport 12345 log "KNOCK STEP 1"
 # in 30 seconds knock at tcp/23456
 iptrap4 src knock2 60 inface eth0 proto tcp dport 23456 src ipset:knock1 log "KNOCK STEP 2"
 # in 60 seconds knock at tcp/34566
 iptrap4 src knock3 90 inface eth0 proto tcp dport 34567 src ipset:knock2 log "KNOCK STEP 3"
 #
 # and in 90 seconds ssh
 interface ...
     server ssh accept src ipset:knock3
```

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

title: firehol-mac(5)

text:
# firehol-mac(5)

## NAME
firehol-mac - ensure source IP and source MAC address match

## SYNOPSIS
mac IP macaddr

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

Note

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

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

When packets are dropped, a log is produced with the label "MAC MISSMATCH" (sic.). mac obeys the default log limits (see [LOGGING][] in firehol-params(5)).

Note

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

## EXAMPLES

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

## SEE ALSO
•

firehol(1) - FireHOL program

•

firehol.conf(5) - FireHOL configuration

•

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

title: firehol-mark(5)

text:
# firehol-mark(5)

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

## SYNOPSIS
{ mark | mark46 } value chain rule-params

mark4 value chain rule-params

mark6 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

There is also a mark parameter which allows matching marks within individual rules (see firehol-params(5)).

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 mark helper command sets values within the usermark group. You can set value between 0 (no mark) and size-1. The default size for usermark is 128, so 127 is highest value possible. The default usermark 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 mark 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
 mark 1 OUTPUT
 # mark with 2, packets routed by the local machine
 mark 2 FORWARD
 # mark with 3, packets routed by the local machine, sent from
 #              192.0.2.2 destined for port TCP/25 of 198.51.100.1
 mark 3 FORWARD proto tcp dport 25 dst 198.51.100.1 src 192.0.2.2
```

## SEE ALSO
•

firehol(1) - FireHOL program

•

firehol.conf(5) - FireHOL configuration

•

firehol-params(5) - optional rule parameters

•

firehol-connmark(5) - set a stateful mark from the connmark 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/)

## AUTHORS
FireHOL Team.