Call Us Today! 877.742.2583

Page tree
Skip to end of metadata
Go to start of metadata


Fail2Ban is an intrusion prevention system that works by scanning log files and then taking actions based on the log entries. Fail2ban specifically supports FreeSWITCH as part of its base configuration and can be easily enabled.

Fail2ban scans FreeSWITCH logs, and optionally other logs, for patterns that indicate problems; e.g., an attempt by an intruder to register with FreeSWITCH. Fail2ban looks for IP addresses in the log entries, and when problems from a specific IP address reach a threshold (as set in a configuration file), fail2ban will update iptable firewall rules to block access from that IP address – that is, "ban" that IP address. As explained at the fail2ban web site, the thresholds for a ban – what constitutes a problem, number of problems found, time frame of problems, duration of a ban, etc. – can all be configured.

Fail2Ban is available via github page and in various Linux distribution repositories.

 Click to expand Table of Contents



An installation of fail2ban requires:

  • iptables, used to ban IP addresses
  • fail2ban
  • log file(s) of problems to detect

Some distributions of fail2ban (CentOS, for example) require firewalld.





Fail2ban may be installed from the EPEL repository. See

The EPEL repository is non-architecture specific; the links to i386 are identical to x86_64.



Baseline Configuration of FreeSWITCH

For FreeSWITCH, one common intrusion is Authentication Attempts/Failures. Reports of these failures can be placed into the standard FreeSWITCH log in one of two ways:

  • Beta: mod_fail2ban, a module that will publish failure attempts to the FreeSWITCH log; or
  • Enable "log-auth-failures" for each Sofia profile

In both cases, loglevel must set to loglevel 4 (WARNING) or higher.

Later on in this document we'll see an example of how to configure a custom warning.

Baseline Configuration of Fail2ban

The maintainers of Fail2Ban have taken an interest in supporting FreeSWITCH. They have asked that we use fail2ban's FreeSWITCH configuration file at rather than specify a custom configuration here. If anyone wishes to submit other regular expressions that should be included in the fail2ban distribution, please provide samples to

Fail2ban's jail.conf file contains a standard configuration for FreeSWITCH.

From Standard jail.conf

To enable monitoring of FreeSWITCH create a file in /etc/fail2ban/jail.d called freeswitch.local. This file must contain the line "enabled=true," because by default freeswitch is not enabled.


"ignoreip" is not mandatory; if present it can be set to whatever values make sense for your installation. The usual use case is to prevent internal IP addresses from being banned.

Custom Fail2ban Monitoring

 Fail2ban sets some standard values in jail.conf;  among them, the number of retries that constitute a failure, the time window in which the failures must occur, and how long to ban the IP address. Here's how freeswitch.local looks if we change the values:

Customized freeswitch.local

If your system has only port 5060 enabled, and other ports blocked by iptables, you'll want to restrict fail2ban to control 5060 only. In that case, freeswitch.local becomes:


If email notifications are not useful, re-define the default actions – one per line, regardless of how the browser displays it below – and leave off the "mta" that's in the freeswitch section of jail.conf. Our freeswitch.local now reads:



Customizing Log Files for Use by fail2ban

The "baseline configuration of FreeSWITCH" section, above, creates entries in the FreeSWITCH log file for unauthorized attempts to register. Let's say that aside from unauthorized attempts to register, intruders also attempt to make unauthorized calls. Here's an example of how to configure FreeSWITCH and fail2ban to find these unauthorized calls and block the IP address of the attacker.

In step one, check each incoming call request over the public-facing SIP port and determine if the call is a spoof attempt. When FreeSWITCH finds that attempt, execute the following line in the dialplan:

Anti-Action in Dialplan

Of course the choice of how to set accountcode will vary according to how intrusion is detected.

In autoload_configs/cdr_csv.conf.xml, add the following line inside the templates section:

Template in cdr_csv.conf.xml

As the result of these two settings, a line will be printed in that format for each intrusion attempt in the log file /var/log/freeswitch/cdr-csv/spam.csv. Only the sip_received_ip is actually necessary here; but in this example, I assume that a human reviewing the file may be interested in more information.

Next, fail2ban must be configured to look for this pattern. This is accomplished by adding a new filter, freeswitch.local, to fail2ban's filter.d directory:


The first two lines of failregex are the original filter from filter.d/freeswitch.conf, and the next line is a regex to find the IP address to ban in the log entry we just specified in cdr_csv.config.xml.

Finally, we need to modify jail.d/freeswitch.local's list of log files to search:


As a result of these modifications, fail2ban will look for both the standard registration attempts as well as our custom-defined intrusions. If a threshold is reached by a particular IP address, fail2ban will ban the IP address of the intruder.

Start and Test Fail2ban and Verify Operation

Starting Fail2ban

Restart fail2ban (/etc/init.d/fail2ban restart, or service fail2ban restart, or systemctl restart fail2ban). The following, or something similar, should be in your /var/log/fail2ban.log:


2018-01-03 18:55:06,436 fail2ban.server         [410]: INFO    Changed logging target to /var/log/fail2ban.log for Fail2ban v0.9.7
2018-01-03 18:55:06,439 fail2ban.jail           [410]: INFO    Creating new jail 'freeswitch'
2018-01-03 18:55:06,440 fail2ban.jail           [410]: INFO    Jail 'freeswitch' uses poller {}
2018-01-03 18:55:06,443 fail2ban.jail           [410]: INFO    Initiated 'polling' backend
2018-01-03 18:55:06,446 fail2ban.filter         [410]: INFO    Added logfile = /var/log/freeswitch/freeswitch.log
2018-01-03 18:55:06,448 fail2ban.filter         [410]: INFO    Added logfile = /var/log/freeswitch/cdr-csv/spam.csv
2018-01-03 18:55:06,449 fail2ban.filter         [410]: INFO    Set maxRetry = 4
2018-01-03 18:55:06,452 fail2ban.filter         [410]: INFO    Set jail log file encoding to ANSI_X3.4-1968
2018-01-03 18:55:06,453 fail2ban.actions        [410]: INFO    Set banTime = 1200
2018-01-03 18:55:06,455 fail2ban.filter         [410]: INFO    Set findtime = 3600
2018-01-03 18:55:06,483 fail2ban.jail           [410]: INFO    Creating new jail 'recidive'
2018-01-03 18:55:06,483 fail2ban.jail           [410]: INFO    Jail 'recidive' uses poller {}
2018-01-03 18:55:06,484 fail2ban.jail           [410]: INFO    Initiated 'polling' backend
2018-01-03 18:55:06,485 fail2ban.filter         [410]: INFO    Added logfile = /var/log/fail2ban.log
2018-01-03 18:55:06,486 fail2ban.filter         [410]: INFO    Set maxRetry = 1
2018-01-03 18:55:06,486 fail2ban.filter         [410]: INFO    Set jail log file encoding to ANSI_X3.4-1968
2018-01-03 18:55:06,486 fail2ban.actions        [410]: INFO    Set banTime = 43200
2018-01-03 18:55:06,487 fail2ban.filter         [410]: INFO    Set findtime = 7200
2018-01-03 18:55:06,487 fail2ban.server         [410]: INFO    Jail recidive is not a JournalFilter instance
2018-01-03 18:55:06,499 fail2ban.jail           [410]: INFO    Jail 'freeswitch' started
2018-01-03 18:55:06,508 fail2ban.jail           [410]: INFO    Jail 'recidive' started



The values will vary, of course, based on values for findtime, bantime, etc. If you've set up other jails – for example, fail2ban's recidive to ban repeat offenders – expect to see multiple jails started.


Verify that the iptables rules were created:


Test the actual failure mode

Setup your favorite client with an invalid userid or invalid password. Try to login as many times as you have set your failure threshold in Fail2Ban. Watch Fail2Ban log:

tail -f /var/log/fail2ban.log
2010-02-05 10:13:12,070 fail2ban.actions: WARNING [freeswitch-udp] Ban
2010-02-05 10:13:12,098 fail2ban.actions: WARNING [freeswitch-tcp] Ban

Verify your client can no longer do a register (should just time out). Also verify iptables:


You can then wait for Fail2Ban to clear the the block, or do it yourself:



You might also take a look at this oreilly scn my systemript


The problems in this section are likely solved in modern versions of iptables, i.e., greater than 1.4.7, by the "lockingopt" parameter which is included by default in fail2ban's actions.d/iptables-common.conf

If you're seeing something like this in your Fail2Ban logfile:

2011-02-27 14:11:42,326 fail2ban.actions.action: ERROR  iptables -N fail2ban-freeswitch-tcp

add the time.sleep(0.1) to /usr/bin/fail2ban-client

def __processCmd(self, cmd, showRet = True):
	beautifier = Beautifier()
	for c in cmd:


sed -i -e s,beautifier\.setInputCmd\(c\),'time.sleep\(0\.1\)\n\t\t\tbeautifier.setInputCmd\(c\)', /usr/bin/fail2ban-client

Source: fail2ban wiki


See Also

fail2ban Webinar by Moshe Yudkowsky on ClueCon Weekly Conference Call