Dovecot Anti Abuse Shield

Dovecot Anti-Abuse Shield is included along with Dovecot Pro, but works with both Dovecot Pro and OX App Suite as a component to protect against login/authentication abuse.

Anti-Abuse Shield runs on a cluster of servers, and integrates with both OX App Suite and Dovecot to detect abuse, brute force attacks and also to enforce common authentication/authorization policies across the platform.

Key Features

Features of Dovecot Anti-Abuse Shield include:

Replicated/clustered architecture – Login reports are shared between all the servers in a cluster so there is a single view of abuse

Scriptable Policy Language – Using the Lua language, the functionality of the daemon can be extended to record and protect against a large variety of abusive behavior, as well as implement specific customer policies.

Ratelimiting and Tarpitting – Extremely flexible, these can be enabled and enforced based on IP address, login name, geoip location, time windows, etc.

Flexible In-Memory Statistics Database – A versatile and extensible in-memory database is used to store statistics information about abuse over time periods from a few minutes to many hours.

Integration with Customer Authentication/Authorization Systems – Customers can use the open HTTP REST API to benefit from the protection of the anti-abuse daemon in their own authentication/authorization systems.

Pricing and availability

Dovecot Anti-Abuse Shield is only available with a valid Dovecot Pro license.

Please contact Open-Xchange Sales for further information and pricing details.

In General

The goal of Dovecot Anti-Abuse Shield is to detect brute forcing of passwords across many servers, services and instances, as well as enforce policy for authentication and authorization. In order to support the real world, brute force detection policy can be tailored to deal with "bulk, but legitimate" users of your service, as well as botnet-wide slow-scans of passwords.

Here is how it works:

Report successful logins via JSONhttp-api

Report unsuccessful logins via JSONhttp-api

Query if a login should be allowed to proceed, should be delayed, or ignored via JSONhttp-api

Policies

Configuration and control of policy is almost entirely through a configuration file which is based on the Lua scripting language. There is a sensible default configuration in wforce.conf, and extensive support for crafting your own policies using the Lua scripting language.

Note that although there is a single Lua configuration file, the report and allow functions run in different lua states from the rest of the configuration, thus you cannot share state.

The main way to track statistics is by using a sliding-time-window based, in-memory stats database, that enables extremely efficient storage and retrieval of three types of statistics:

Integer - Counting the number of times relevant events happened

HyperLogLog - Counting the uniqueness or cardinality of a data set

CountMin - Distinct count of multiple items in a data set

Country-level IPv4 and v6 IP lookups are available, as are a variety of DNS lookup functions, including querying RBLs.

Many more metrics are available to base decisions on, and are documented in the wforce.conf man page, available on any system with Dovecot Anti-Abuse Shield installed. It also ships with wforce.conf.example, which gives many examples of how to configure the service and policy.

If you have installed the optional wforce-policy package, a full-featured example policy is available to use, either as-is, or as the basis for customised site-specific policies.

Console

Although wforce normally runs under systemd, you can launch wforce manually (`wforce -C "config file"`), or as a daemon (`wforce --daemon`). To connect using the console, run `wforce -c "config file"`. Comes with autocomplete and command history. If you put an actual IP address in place of 0.0.0.0, you can use the same config to listen and connect remotely.

To get some stats, try:

> stats()
40 reports, 8 allow-queries, 40 entries in database

Load balancing: siblings

For high-availability or performance reasons it may be desirable to run multiple instances of wforce. To present a unified view of status however, these instances then need to share data. To do so, wforce implements a simple knowledge-sharing system.

The original version of wforce simply broadcast all received report tuples (best effort, UDP) to all siblings. However the latest version only broadcasts incremental changes to the underlying state databases, namely the stats dbs and the blacklist.

The sibling list is parsed such that we don't broadcast messages to ourselves accidentally, and can thus be identical across all servers.

Even if you configure siblings, stats db data is not replicated by default. To do this, use the "twEnableReplication()" command on each stats db for which you wish to enable replication. Blacklist information is automatically replicated if you have configured siblings.

The first line sets the authentication and encryption key for our sibling communications. To make your own key (recommended), run `makeKey()` on the console and paste the output in all your configuration files.

This last line configures that we also listen to our other siblings (which is nice). The default port is 4001, the protocol is UDP.