---

labels:

- 'Stage-Alpha'

summary: 'A rule-based stanza filtering module'

rockspec:

  build:

    modules:

      mod_firewall.actions: actions.lib.lua

      mod_firewall.conditions: conditions.lib.lua

      mod_firewall.definitions: definitions.lib.lua

      mod_firewall.marks: marks.lib.lua

      mod_firewall.test: test.lib.lua

---

------------------------------------------------------------------------

**Note:** mod\_firewall is in its very early stages. This documentation

is liable to change, and some described functionality may be missing,

incomplete or contain bugs.

------------------------------------------------------------------------

Introduction

============

A firewall is an invaluable tool in the sysadmin's toolbox. However

while low-level firewalls such as iptables and pf are incredibly good at

what they do, they are generally not able to handle application-layer

rules.

The goal of mod\_firewall is to provide similar services at the XMPP

layer. Based on rule scripts it can efficiently block, bounce, drop,

forward, copy, redirect stanzas and more! Furthermore all rules can be

applied and updated dynamically at runtime without restarting the

server.

Details

=======

mod\_firewall loads one or more scripts, and compiles these to Lua code

that reacts to stanzas flowing through Prosody. The firewall script

syntax is unusual, but straightforward.

A firewall script is dominated by rules. Each rule has two parts:

conditions, and actions. When a stanza matches all of the conditions,

all of the actions are executed in order.

Here is a simple example to block stanzas from spammer@example.com:

    FROM: spammer@example.com

    DROP.

FROM is a condition, and DROP is an action. This is about as simple as

it gets. How about heading to the other extreme? Let's demonstrate

something more complex that mod\_firewall can do for you:

    %ZONE myorganisation: staff.myorg.example, support.myorg.example

    ENTERING: myorganisation

    KIND: message

    TIME: 12am-9am, 5pm-12am, Saturday, Sunday

    REPLY=Sorry, I am afraid our office is closed at the moment. If you need assistance, please call our 24-hour support line on 123-456-789.

This rule will reply with a short message whenever someone tries to send

a message to someone at any of the hosts defined in the 'myorganisation'

outside of office hours.

Specifying rule sets

--------------------

Firewall rules should be written into text files, e.g. `ruleset.pfw` file.

One or more rule files can be specified in the configuration using:

    firewall_scripts = { "path/to/ruleset.pfw", "path/to/ruleset2.pfw" }

If multiple files are specified and they both add rules to the same [chains](#chains),

each file's rules will be processed in order, but the order of files is undefined.

Reloading Prosody's configuration also reloads firewall rules.

Make sure that `firewall_scripts` is in the global section of the configuration file

and not below a virtual host or a component - unless you want per-vhost

firewall rules.

Conditions

----------

All conditions must come before any action in a rule block. The

condition name is followed by a colon (':'), and the value to test for.

A condition can be preceded or followed by `NOT` to negate its match.

For example:

    NOT FROM: user@example.com

    KIND NOT: message

Some conditions do not take parameters, and these should end with just a

question mark, like:

    IN ROSTER?

### Zones

A 'zone' is one or more hosts or JIDs. It is possible to match when a

stanza is entering or leaving a zone, while at the same time not

matching traffic passing between JIDs in the same zone.

Zones are defined at the top of a script with the following syntax (they

are not part of a rule block):

    %ZONE myzone: host1, host2, user@host3, foo.bar.example

There is an automatic zone named `$local`, which automatically includes

all of the current server's active hosts (including components). It can

be used to match stanzas entering or leaving the current server.

A host listed in a zone also matches all users on that host (but not

subdomains).

The following zone-matching conditions are supported:

  Condition    Matches

  ------------ ------------------------------------------

  `ENTERING`   When a stanza is entering the named zone

  `LEAVING`    When a stanza is leaving the named zone

### Lists

It is possible to create or load lists of strings for use in scripts. For

example, you might load a list of blocked JIDs, malware URLs or simple words

that you want to filter messages on.

  List type    Example

  -----------  -----------------------

  memory       %LIST spammers: memory

  file         %LIST spammers: file:/etc/spammers.txt

  http         %LIST spammers: http://example.com/spammers.txt

#### List types

##### memory

```

%LIST name: memory (limit: number)

```

A memory-only list, with an optional limit. Supports addition and removal of items by scripts.

If a limit is provided, the oldest item will be discarded to make room for a new item if the

list is full. The limit is useful to prevent infinite memory growth on busy servers.

##### file

```

%LIST name: file:/path/to/file (missing: string)

```

Reads a list from a file. The list can be added to and removed from by scripts, but

these changes do not persist between restarts.

If the file is missing, an error will be raised. The optional 'missing' parameter can be set

to 'ignore' (e.g. `(missing: ignore)`) to ignore a missing file.

##### http

```

%LIST name: http://example.com/ (ttl: number, pattern: pat, hash: sha1, checkcerts: when-sni)

```

Fetches a list from a HTTP or HTTPS URL. The following options are accepted:

  Option    Description

  -------   -----------

  ttl       Seconds to cache the list for. After expiry, it will be refetched. Default 3600 (1 hour).

  pattern   Optional pattern used to extract list entries from the response. Default is to treat each line as a single item.

  hash      Optional hash to be applied to items before looking them up in the list, e.g. sha1 or sha256.

  checkcert Whether to verify HTTPS certificates. May be "always", "never" or "when-sni". Default "when-sni".

The "when-sni" default disables certificate verification when Prosody's HTTP client API doesn't support SNI,

as in Prosody 0.11.6 and earlier.

#### CHECK LIST

Checks whether a simple [expression](#expressions) is found in a given list.

Example:

    %LIST blocked_jids: file:/etc/prosody/blocked_jids.txt

    # Rule to block presence subscription requests from blocked JIDs

    KIND: presence

    TYPE: subscribe

    CHECK LIST: blocked_jids contains $<@from>

    BOUNCE=policy-violation (Your JID is blocked)

#### SCAN

SCAN allows you to search inside a stanza for a given pattern, and check each result against a list. For example,

you could scan a message body for words and check if any of the words are found in a given list.

Before using SCAN, you need to define a search location and a pattern. The search location uses the same 'path'

format as documented under the 'INSPECT' condition. Patterns can be any valid Lua pattern.

To use the above example:

    # Define a search location called 'body' which fetches the text of the 'body' element

    %SEARCH body: body#

    # Define a pattern called 'word' which matches any sequence of letters

    %PATTERN word: [A-Za-z]+

    # Finally, we also need our list of "bad" words:

    %LIST badwords: file:/etc/prosody/bad_words.txt

    # Now we can use these to SCAN incoming stanzas

    # If it finds a match, bounce the stanza

    SCAN: body for word in badwords

    BOUNCE=policy-violation (This word is not allowed!)

#### COUNT

COUNT is similar to SCAN, in that it uses a defined SEARCH and breaks it up according to a PATTERN. Then it

counts the number of results.

For example, to block every message with more than one URL:

    # Define a search location called 'body' which fetches the text of the 'body' element

    %SEARCH body: body#

    # Define a pattern called 'url' which matches HTTP links

    %PATTERN url: https?://%S+

    COUNT: url in body > 1

    BOUNCE=policy-violation (Up to one HTTP URL is allowed in messages)

### Stanza matching

  Condition   Matches

  ----------- ------------------------------------------------------------------------------------------------------------------------------------------------------------

  `KIND`      The kind of stanza. May be 'message', 'presence' or 'iq'

  `TYPE`      The type of stanza. This varies depending on the kind of stanza. See 'Stanza types' below for more information.

  `PAYLOAD`   The stanza contains a child with the given namespace. Useful for determining the type of an iq request, or whether a message contains a certain extension.

  `INSPECT`   The node at the specified path exists or matches a given string. This allows you to look anywhere inside a stanza. See below for examples and more.

#### Stanza types

  Stanza     Valid types

  ---------- ------------------------------------------------------------------------------------------

  iq         get, set, result, error

  presence   *available*, unavailable, probe, subscribe, subscribed, unsubscribe, unsubscribed, error

  message    normal, chat, groupchat, headline, error

**Note:** The type 'available' for presence does not actually appear in

the protocol. Available presence is signalled by the omission of a type.

Similarly, a message stanza with no type is equivalent to one of type

'normal'. mod\_firewall handles these cases for you automatically.

### Sender/recipient matching

  Condition     Matches

  ------------- -------------------------------------------------------

  `FROM`        The JID in the 'from' attribute matches the given JID.

  `TO`          The JID in the 'to' attribute matches the given JID.

  `TO SELF`     The stanza is sent by any of a user's resources to their own bare JID.

  `TO FULL JID` The stanza is addressed to a valid full JID on the local server (full JIDs include a resource at the end, and only exist for the lifetime of a single session, therefore the recipient must be online, or this check will not match).

The TO and FROM conditions both accept wildcards in the JID when it is

enclosed in angle brackets ('\<...\>'). For example:

    # All users at example.com

    FROM: <*>@example.com

    # The user 'admin' on any subdomain of example.com

    FROM: admin@<*.example.com>

You can also use [Lua's pattern

matching](http://www.lua.org/manual/5.1/manual.html#5.4.1) for more

powerful matching abilities. Patterns are a lightweight

regular-expression alternative. Simply contain the pattern in double

angle brackets. The pattern is automatically anchored at the start and

end (so it must match the entire portion of the JID).

    # Match admin@example.com, and admin1@example.com, etc.

    FROM: <<admin%d*>>@example.com

**Note:** It is important to know that 'example.com' is a valid JID on

its own, and does **not** match 'user@example.com'. To efficiently match

domains we recommend defining them as [Zones](#zones).

  Condition        Matches

  ---------------- ---------------------------------------------------------------

  `FROM_EXACTLY`   The JID in the 'from' attribute exactly matches the given JID

  `TO_EXACTLY`     The JID in the 'to' attribute exactly matches the given JID

These additional conditions do not support pattern matching, but are

useful to match the exact to/from address on a stanza. For example, if

no resource is specified then only bare JIDs will be matched. TO and FROM

match all resources if no resource is specified to match.

**Note:** Some chains execute before Prosody has performed any

normalisation or validity checks on the to/from JIDs on an incoming

stanza. It is not advisable to perform access control or similar rules

on JIDs in these chains (see the [chain documentation](#chains) for more info).

#### INSPECT

INSPECT takes a 'path' through the stanza to get a string (an attribute

value or text content). An example is the best way to explain. Let's

check that a user is not trying to register an account with the username

'admin'. This stanza comes from [XEP-0077: In-band

Registration](http://xmpp.org/extensions/xep-0077.html#example-4):

``` xml

<iq type='set' id='reg2'>

  <query xmlns='jabber:iq:register'>

    <username>bill</username>

    <password>Calliope</password>

    <email>bard@shakespeare.lit</email>

  </query>

</iq>

```

    KIND: iq

    TYPE: set

    PAYLOAD: jabber:iq:register

    INSPECT: {jabber:iq:register}query/username#=admin

    BOUNCE=not-allowed (The username 'admin' is reserved.)

That weird string deserves some explanation. It is a path, divided into

segments by '/'. Each segment describes an element by its name,

optionally prefixed by its namespace in curly braces ('{...}'). If the

path ends with a '\#' then the text content of the last element will be

returned. If the path ends with '@name' then the value of the attribute

'name' will be returned.

You can use INSPECT to test for the existence of an element or attribute,

or you can check if it matches a specific value, e.g. by appending `=VALUE`

(like in the example above, that checks if the content of username is 'admin').

#### INSPECT comparison operators

As well as checking for an exact string match, there are some other modifiers

you can apply to the comparison:

  Comparison    Matches when

  ------------- -------------------------------------------------------

  `=`           The value is exactly the given string.

  `/=`          The value is or *contains* the given string (e.g. `/=admin` would match `administrator` or `myadmin`).

  `~=`          The value matches the given [Lua pattern](https://www.lua.org/manual/5.2/manual.html#6.4.1).

Finally, if the comparison operator is preceded by a `$` character, [expressions](#expressions)

will be interpreted in the string following the comparison operator.

e.g. `INSPECT: {jabber:iq:register}query/username}$/=$(session.host)` would match

if the username of an account registration contained the session's current hostname

somewhere in it.

#### INSPECT performance

INSPECT can be somewhat slower than the other stanza matching conditions. To

minimise performance impact, always place it below other faster

condition checks where possible (e.g. in the example above we first checked KIND,

TYPE and PAYLOAD matched what we wanted before reaching the INSPECT rule).

### Roster

These conditions access the roster of the recipient (only). Therefore they cannot (currently)

be used in some [chains](#chains), such as for outgoing messages (the recipient may be on another server).

Performance note: these checks can potentially cause storage access (especially if the recipient

is currently offline), so you may want to limit their use in high-traffic situations, and place rules

containing a roster check below other rules (such as a rate limiter). The storage access is

performed unconditionally just before evaluation of the first rule that contains a roster-based

condition, even if earlier conditions in that rule do not match.

#### IN ROSTER

Tests whether the sender is in the recipient's roster.

    IN ROSTER?

#### IN ROSTER GROUP

Tests whether the sender is in the recipient's roster, and in the named group.

    IN ROSTER GROUP: Friends

#### SUBSCRIBED

Tests whether the recipient is subscribed to the sender, ie will receive

presence updates from them.

Note that this *does* work, regardless of direction and which [chain](#chain) is

used, since both the sender and the recipient will have mirrored roster

entries.

### Groups

Using Prosody's mod\_groups it is possible to define groups of users on the server. You can

match based on these groups in firewall rules.

  Condition         Matches

  ----------------- ----------------------------

  `FROM GROUP`      When the stanza is being sent from a member of the named group

  `TO GROUP`        When the stanza is being sent to a member of the named group

  `CROSSING GROUPS` When the stanza is being sent between users of different named groups

#### CROSSING GROUPS

The `CROSSING GROUPS` condition takes a comma-separated list of groups to check. If the

sender and recipient are not in the same group (only the listed groups are checked), then the

this condition matches and the stanza is deemed to be crossing between groups.

For example, if you had three groups: Engineering, Marketing and Employees. All users are

members of the 'Employees' group, and the others are for employees of the named department only.

To prevent employees in the marketing department from communicating with engineers, you could use

the following rule:

```

CROSSING GROUPS: Marketing, Engineering

BOUNCE=policy-violation (no communication between these groups is allowed!)

```

This works, even though both the users are in the 'Employees' group, because that group is not listed

in the condition.

In the above example, a user who is member of both groups is not restricted.

#### SENT DIRECTED PRESENCE TO SENDER

This condition matches if the recipient of a stanza has previously sent directed presence to the sender of the stanza. This

is often done in XMPP to exchange presence information with JIDs that are not on your roster, such as MUC rooms.

This condition does not take a parameter - end the condition name with a question mark:

    # Rule to bounce messages from senders not in the roster who haven't been sent directed presence

    NOT IN ROSTER?

    NOT SENT DIRECTED PRESENCE TO SENDER?

    BOUNCE=service-unavailable

### Permissions

Rules can consult Prosody's internal role and permissions system to check whether a certain action may

be performed. The acting entity, their role, and appropriate context is automatically inferred. All you

need to do is provide the identifier of the permission that should be checked.

  Condition               Description

  ----------------------- --------------------------------------------------------------------

  `MAY=permission`        Checks whether 'permission' is allowed in the current context.

As with all other conditions, `MAY` can be combined with `NOT` to negate the result of the check.

Example, blocking outgoing stanzas from users with roles that do not allow the 'xmpp:federate' permission:

```

::deliver_remote

MAY NOT: xmpp:federate

BOUNCE=policy-violation (You are not allowed access to the federation)

```

### Roles

  Condition        Matches

  ---------------- -------------------------------------------------------------------------------------

  `TO ROLE`       When the recipient JID of the stanza has the named role

  `FROM ROLE`     When the sender JID of the stanza has the named role

**Note:** In most cases, you should avoid checking for specific roles, and instead check for

permissions granted by those roles (using the 'MAY' condition).

### Admins

**Deprecated:** These conditions should no longer be used. Prefer 'MAY', 'TO ROLE' or 'FROM ROLE'.

Prosody allows certain JIDs to be declared as administrators of a host, component or the whole server.

  Condition        Matches

  ---------------- -------------------------------------------------------------------------------------

  `TO ADMIN`       When the recipient of the stanza is admin of the current host

  `FROM ADMIN`     When the sender of the stanza is admin of the current host

  `FROM ADMIN OF`  When the sender of the stanza is an admin of the named host on the current server

  `TO ADMIN OF`    When the recipient of the stanza is an admin of the named host on the current server