Enabling fail2ban on the reverse proxy

Fail2ban is an intrusion prevention framework that can protect the reverse proxy from brute-force attacks on PIN-protected conferences.

When enabled, fail2ban works by scanning the logs on the reverse proxy for repeated failed PIN entry attempts from the same IP address, and then blocks the source IP address that is responsible for that activity.

By default, it blocks access for 300 seconds if 10 PIN failures are logged from the same IP address within a 300 second window. The blocked IP address will be unable to connect to the reverse proxy for the duration of the ban. Note that each attempt to access a PIN-protected conference always creates one "failed PIN" log entry (even if the supplied PIN is correct), plus a second failure log entry if the supplied PIN is incorrect. Therefore in practical terms a user will be banned if they supply 5 incorrect PIN numbers (5 incorrect attempts x 2 log entries per attempt = 10) within the time window — see Limitations below for more information.

If you are using v5 (or earlier) of the OVA template, refer to the previous documentation for the appropriate instructions.


It allows any source IP address a maximum of 5 incorrect PIN entries in a 5 minute (300s) window — and thus (on average) limits an attacker to about one PIN guess attempt per minute over the long term. If you have a six digit PIN you'd need an average of 500,000 PIN guess attempts to crack the average PIN (assuming the PIN was random) — which would take a single attacker, attacking from a single source IP, approximately 500000/60/24 = 347 days to crack (using a naive brute force attack). A four digit PIN would take just 5000/60/24 = 3.47 days to crack — so longer PINs really do provide a significant benefit.


Due to the nature of the underlying protocol used to access PIN-protected conferences, every attempt to access a PIN-protected conference results in one "failed PIN" log entry being created — and then a further "failed PIN" log entry is recorded if an incorrect PIN is submitted. Thus, for example, two incorrectly submitted PINs for the same conference will result in four "failed PIN" log entries being created. An attempt to access a conference where an incorrect PIN is submitted before the correct PIN is supplied will result in three "failed PIN" log entries.

Therefore, to provide a balance between blocking intruders but allowing for normal use and genuine user errors, the default settings within the fail2ban service are configured to ban the source IP address if it detects 10 "failed PIN" entries in the log file (i.e. the intruder has submitted 5 incorrect PINs). Note that this also means, for example, that a source address would be blocked if it attempts to join 10 PIN-protected conferences within a 5 minute period, even if the correct PIN is always supplied. You can modify the default settings for the number of failures, ban duration and so on if required.

The fail2ban service won't deter a determined or well-resourced attacker who is prepared to conduct a brute force attack from multiple source IP addresses or ride out the ban duration repeatedly over a period of days, but it does make break-in harder.

Users behind NATs

All users that are behind the same NAT are seen as having the same source address. Therefore, if you have multiple users behind the same NAT who are accessing the reverse proxy, we recommend caution in enabling fail2ban as they could block themselves out even if they never enter a wrong PIN.

Alternative deployment scenario possibilities to cater for users behind a NAT include having a separate internal reverse proxy (with fail2ban enabled) for any internal users that are behind your own NAT and using split horizon DNS to ensure they are routed to the internal reverse proxy. Individual users who work from home or other remote location (from behind a remote NAT) will not normally be a problem as each user will typically be behind a different NAT (with a different IP address). However, a service-provider scenario where a publicly-deployed reverse proxy is providing conferencing facilities to a group of remote users who are all behind the same enterprise NAT will need to have fail2ban disabled.

Enabling, configuring and monitoring fail2ban

This section describes how to enable fail2ban, modify the default configuration if required, and how to monitor the service.

Enabling fail2ban

You can enable or disable fail2ban when you run (or rerun) the installation wizard.

At the Enable Fail2ban? prompt in the installation wizard, answer "yes" to enable fail2ban, or "no" to disable it. The default is "no" when you first install the reverse proxy, and if you rerun the installation wizard it defaults to your previous setting.

Modifying the default fail2ban configuration

The default configuration of the fail2ban service is to block access for 300 seconds if it detects 10 "failed PIN" log entries from the same IP address within a 5 minute window.

You can modify each of these settings if required. To change the fail2ban configuration:

  1. Connect over SSH to the reverse proxy and log in as user pexip.
  2. Run the following command to edit the fail2ban config file:

    sudo nano /etc/fail2ban/jail.local

  3. You can modify the following ban-related settings:

    Setting Purpose Default
    (DEFAULT section)
    The number of seconds that a host address is banned. 300
    (DEFAULT section)
    The time period in seconds that is monitored. 300


    (you must modify the maxretry value specified in the pexiprp jail)

    The number of failures that when reached will trigger the ban. A host is banned if it generates maxretry failures during the last findtime seconds. 10
  4. After editing and saving the file, run the following command to restart the fail2ban service:

    sudo systemctl restart fail2ban

For more information on advanced configuration, see https://www.digitalocean.com/community/tutorials/how-to-protect-an-nginx-server-with-fail2ban-on-ubuntu-14-04.

Checking the status of the fail2ban service

You can check the status of the fail2ban service by running the following command:

sudo fail2ban-client status pexiprp

which gives the following status:

pexip@rp:/var/log$ sudo fail2ban-client status pexiprp
Status for the jail: pexiprp
|- filter
|  |- File list:    /var/log/nginx/pexapp.access.log 
|  |- Currently failed:    0
|  `- Total failed:    0
`- action
   |- Currently banned:    0
   |  `- IP list:    
   `- Total banned:    0

The failed and banned counts may be non-zero if the service has detected access failures.

If the service is not running you will see: ERROR Unable to contact server. Is it running?