on the reverse proxy
Fail2ban is an intrusion prevention framework that can protect the reverse proxy from brute-force attacks on PIN-protected conferences. Fail2ban is disabled by default on the reverse proxy.
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 successful attempts to access a PIN-protected conference also result in "failed PIN" log entries being created, therefore in practical terms a user will be banned if they supply 5 incorrect PIN numbers within the time window — see Limitations below for more information.
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.
To enable fail2ban on the reverse proxy, connect over SSH to the reverse proxy, log in as user pexip and run the following commands one at a time:
sudo update-rc.d fail2ban enable
sudo /etc/init.d/fail2ban restart
The response on the console to the restart command will be * Restarting authentication failure monitor fail2ban (note that this is not an error message).
If you want to disable fail2ban, use the commands:
sudo update-rc.d fail2ban disable
sudo /etc/init.d/fail2ban stop
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:
Run the following command to edit the fail2ban config file:
sudo nano /etc/fail2ban/jail.local
You can modify the following ban-related settings:
Setting Purpose Default bantime
The number of seconds that a host address is banned. 300 findtime
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
After editing and saving the file, run the following command to restart the fail2ban service:
sudo /etc/init.d/fail2ban restart
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.
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?