Elastix Guide:

Elastix Security Guide V2.0 (2014)

Title
Elastix Security Guide V2.0 (2014)
Author
Bob Fryer
Date Written / Last Modified
23/3/2014
Revision
2.0
Replaces Document
Elastix Security Guide V1.0 (2011)
Tested on Elastix Version
2.2+
Backward Compatible
Released on Elastix 2.2 Some applies to earlier versions
Disclaimer:
Your
use
of
this
guide
is
subject
to
the
following
conditions:
Elastix Level
Beginner to Experienced
* Your application of these notes are entirely at your own risk.
Linux Level
Beginner
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
Network
Level
Intermediate to Experienced
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
Latest documents
Document
Source
available
from
www.elastixconnection.com
claims or comments and test in your environment to its suitability.
Credits
N/A
Licence
GNU FDL

Contents
Introduction ............................................................................................................................................ 3
Security A big beat up?? ...................................................................................................................... 6
Internal vs External Attacks .................................................................................................................... 7
The Basics ............................................................................................................................................... 8
Passwords or Secrets .......................................................................................................................... 8
Turn off Allow Anonymous SIP ........................................................................................................... 9
Limit installing additional products on your Elastix system ............................................................. 11
Use the Permit/Deny options in FreePBX/Unembedded FreePBX. ................................................. 12
Perimeter Firewall / Router .................................................................................................................. 13
Restricting IP Traffic.......................................................................................................................... 13
Implementing Intrusion Detection (IDS) .......................................................................................... 15
Elastix Firewall ...................................................................................................................................... 16
Fail2ban ................................................................................................................................................ 17
Other Security Measures ...................................................................................................................... 19
Utilising VPNs where possible especially for remote Phones ......................................................... 19
Changing the default port for SSH .................................................................................................... 19
Utilising VPNs where possible especially for remote Phones ......................................................... 20
Adding a PIN Code for all outbound International Calls................................................................... 20
Adding a time condition to your Outbound International Calls ....................................................... 20
Port Knocking.................................................................................................................................... 21
Monitoring ............................................................................................................................................ 22
Voice Provider Call Quotas .............................................................................................................. 22
Monitoring Logs................................................................................................................................ 23
Utilising the new Asterisk Security Logging ...................................................................................... 24
Monitoring Software ........................................................................................................................ 25

Disclaimer: Your use of this guide is subject to the following conditions:

* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

Introduction
Security is a very broad subject and rightly so. It is a very subjective topic as well, and to a certain degree it is
a subject that will never have a definitive end. Thats why I generally dismiss any book that claims to be a
Definitive Guide to Security. It is a constant living subject, with improvements, changes, retractions and even
changes in thinking and direction every year.
There is also no subject like security that stirs up the emotions, especially when statements are made, as
everyone has their own views and ideas. The ideas in this guide are from my own personal experience mixed
with many years of research. I can tell you that I am active in this area, work in this area on a constant basis
and backed by over 30 years of experience in the IT industry, not just the telephony industry.
Security is also not going to be fixed by one device that fixes everything. It is a set of tools, backed up by
procedures, and ultimately followed up by diligent, constant reviewing and monitoring. Security is only as
good as the weakest link in the chain.
Likewise, following this document from start to finish is not going to full protect your system, as there is no
one document that can do this as every system and design is different. Every environment is different. All
this document can do is to provide you with a basic understanding of the tools that you can use and how
they are used.
No topic presented in this document should be relied on as complete protection for your Elastix system.
Typically this document will raise a method and you should do your own research into the methodology to
confirm that it will work for you and as to what confidence you can place on its implementation.
Likewise, Security is exponentially as you want to make it. You may be able to secure your system to cover
70% of your system using tools/products that you have and no further hardware, you may be able to cover
95% of your system with a few hundred dollars, but to get to that 99%+, it could cost you thousands of
dollars, and you may still have that 1% chance that someone gets through.
This guide will provide you with an introduction on tools and techniques you can implement to cover that
70% to 95%. This guide will describe some of the common techniques that these intruders use as well as tips
and tricks to lessen the possibility of an intruder will make a successful intrusion into your system.
This document you are reading now is a second revision of this document. Over three years since the original
was written, new vulnerabilities have been found, new techniques are available and definitely more ways to
monitor are available. As I stated at the start, it is a subject that will never have a definitive end.

Disclaimer: Your use of this guide is subject to the following conditions:

* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

When implementing security I personally work on the basis of four layers which generally come down to the
basics which consist of

Firewall
Most people know what I mean here, and the prime security measure needs to exist on the
perimeter of your network. I have no issue with it existing on your Elastix system, especially as a
properly implemented Linux IPTables is probably regarded as one the best firewall implementations,
in fact many Firewall Appliance products both commercial and Open Source are based on a Linux
Kernel with IPTables. However as a general rule it is always best if the primary firewall is separate
from the product you are protecting. Have a think about it, wouldnt you prefer that you have some
distance on the product that someone is trying to hack (in this case the firewall) and the product you
are protecting. It adds that extra layer.

Authentication
Very simple, but often very little thought goes into it. The number of systems I see in place where
the implementer has used simple passwords, in many cases, the password is the same as the
extension number. The use of a numerical password is also just as bad. It doesnt take long for a
Script Kiddie to run a password guesser on your system, especially where the password is all
numbers.
Authentication also comes down to the encryption of the password if it is possible.

Obfuscation
Big term for nothing much, but it aptly describes what we are trying to do. Basically it means to
make things not clear.
This has a very successful application in the security world. Why make it clear to possible intruders
by giving them a roadmap. If a possible intruder finds everything is laid out before them, they will
use it, and its the same as these Script Kiddies, they expect everything to be as they expected,
which is why these scripts have reasonable success.
Changing the system from defaults wont stop the good intrusion attacks, but it will definitely make
it harder for all the others to attack your system. Unless they have a vested interest in the intended
target, they will normally turn away from your system and look for an easier target, especially if the
system is an automated script.

Monitoring
No Firewall is 100% foolproof, no network is 100% static (never changed), and attackers are trying
new measures every day. You cannot setup a firewall and forget. Constant monitoring of your
Firewall or Intrusion logs is necessary.

Disclaimer: Your use of this guide is subject to the following conditions:

* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

In this guide you will find that many of the techniques and ideas implement these either all together or
across a range of implementations. As I mentioned before, just implementing these ideas will not all of a
sudden make things secure. It is also a case of monitoring your system on a regular basis, investigating what
you see. Many systems that are hacked are generally not monitored, and if they had monitored on a
constant basis, they would have caught the issue before it moved to a full blown attack, especially as many
of these attacks normally have an investigation stage before they take control of your system.
One final thing, there are other measures that can be implemented and are discussed on the Internet,
particularly for pure Asterisk systems. This document is mainly written around the Elastix system which, with
a combination of FreePBX and Elastix defaults have already implemented some of these measures which
they feel are important.
As an example, you mind find a document on using the from-sip-external context as a default context. This is
already implemented by FreePBX and you can confirm this yourself by executing SIP SHOW SETTINGS under
the Asterisk CLI. This shows you most of the default settings for SIP. So if you find something that you feel is
important, execute this command to check the default settings first.

Script Kiddies (I refer to them as Kiddie Scripts)

Silly name in fact the name belies the costly possibility of what can occur to your system.
Generally these are are the first wave the scripts that perform the investigation before a
full blown attack is made on your system. Quite often their information they gain is
distributed around their groups, sometimes using the IRC channel, so that others can either
use the information or use it to gain further access to your system. But these scripts are
generally generic in nature, running over hundreds of systems looking for a way in.

Disclaimer: Your use of this guide is subject to the following conditions:

* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

Security A big beat up??

You might be wondering if this is all a big beat up, not worth the time. You might be having troubles
wondering if these scripts and hacks are real. Have a look at this video on
http://enablesecurity.com/products/enablesecurity-voippack-sipautohack-demo/ .
This is a GUI tool they are using but it clearly shows how simple these tools are and how quickly they can
determine a simple password setup.
Now you are probably thinking, fine, I can trace the address it has come from and prosecute them and get
my money back. Think again. Many of these addresses that these attacks come from are from overseas, and
most of them have no formal legal processes in place that can be initiated. Many of these attacks appear to
be coming from China, but what has really happened is that the hackers have compromised a server in China
and they are in a totally different country. They know that the chance of you obtaining information from
Chinese authorities is just about nil.
Whilst we are looking at a GUI tool in the video from a company that makes tools that you can use to secure
your system, the rest of the hacking world has written their own tools. These tools are faster and probably
even more cunning than what this company has written, which include Random word generators, number
generators, using common defaults, and includes looking for known exploits.
You might be thinking that they cant make that many calls on your system, but what is actually occurring is
that they are selling your calls (basically known as Toll Fraud). This can be done by calling cards that people
legitimately buy (particular in countries that are not effective to removing this type of issue), and when they
ring the special number before making a call, it is ringing a hacked VoIP PBX that might connect to up to 40
other hacked PBX systems, and it tries each one until it has a trunk that works (for instance one or two might
be no longer available as their owners had found them attacked). To the calling card customer, they just
notice a longer than normal delay, which is not uncommon with international calls.
Still dont believe Elastix systems are on the radar, look at the list of features in the VoIPPack on this page
http://enablesecurity.com/products/voippack/
Pointing this out is not to purposely take a swipe at Enable Security (in fact Sandro is a regular on the Elastix
forums), they just produce products that allow you as a system owner to check how good your security is.
However it does show that this is a real threat.
Just for the record, I have no association with Enable Security or their affiliates, nor do I own any of their
products. I use them as an example as they have a very good video on how these sort of attacks can occur.
One of the other things I do in the lab is run a HoneyPot system. This is an Elastix system utilising various
systems, which includes firewall, without a firewall, utilising simple passwords, common extension numbers.
I watch what occurs, reviewing the logs as well as watching live scripts do their work. This is one of the
interesting ways to see what methodologies work, and that includes implementing them whilst they are live
on your Honeypot system to see what really does work.
Disclaimer: Your use of this guide is subject to the following conditions:
* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

Internal vs External Attacks

One of the most common mistakes that many people make is concentrating on external attacks to the
system (in other words direct attacks from the Internet to their Elastix system. Sure this is the most common
and in all probability, this is where you should concentrate your resources on.
However there is the possibility that the attack may come from internally. Now youre probably thinking
most people in the company are not capable of such acts as no one has the technical ability and you could
be right, however two scenarios are possible, maybe more.
The first scenario is the possibility that someone downloads a Trojan that they install on their workstation
which came with dodgy copy of a soft phone or even a soft phone app for a Smartphone (which are
becoming a dime a dozen nowadays). It could even be one of your level 1 technicians trying to do the right
thing and use their initiative. Unbeknownst to them, it installed a Trojan that reports back the extension and
password that he entered into the soft phone. The hackers have their first entry point into your system.
Separate to this, it now has the IP address of the Elastix PBX and commences a dictionary attack on the PBX.
Further in this document, I talk about ADSL allowing 40-50 registrations a second, but with a 1Gb connection
to the PBX, they are now reaching 200-300 registrations a second, it means that they can really move
through hundreds of thousands of passwords in a hour. The chances are high that this Trojan can guess
some of your simple passwords.
This may sound like tin-foil hat type of scenario, but it is possible, in fact I wrote a windows application with
no visible GUI that executed and performed a dictionary attack to show proof of concept. I did not continue
with it, as it was meant for a presentation, but run short on time to present it.
The second scenario is a lot more possible and is a common way to attack systems particularly for the more
sophisticated hacker. As I mentioned before, the security on your system is only as good as your weakest
link. Now the attack on your system could come from another server in your organisation. Imagine this
scenario, you have just had another server installed in your network that has access to the outside world.
This server may have been installed by another third party company that has specific requirements, which
includes their access remotely to up keep the server. This server is important to the business as it is a major
part of their business (e.g. this might be a new POS system) and to a certain degree you have been kept out
of the loop and your concerns have been dismissed.
Someone hacks this system, particular if it is a Windows exploit (can anyone remember the RDP exploit of
March 2012 found on almost every version from Windows XP onwards?). They then use this system to
scan the network to find an Asterisk based system and commence a dictionary attack on your SSH and SIP
Ports until they get lucky.
These attacks have bypassed your perimeter firewall losing your valuable first layer of security. This is why I
advocate several layers of security and this is a perfect example of where the Elastix Firewall can be a great
asset particular for internal based attacks.

Disclaimer: Your use of this guide is subject to the following conditions:

* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

The Basics
Before we move any further forward...lets cover a few basic mistakes that many users make (Ive made
them as well). These are items that can immediately improve the security of your system, and should be the
first items that you tackle.

Passwords or Secrets
Passwords or secrets as they are called in the VoIP world, is one of the largest improvements you can make.
One of the big issues is that many users make is putting simple passwords on the system while they are
testing, but the system ends up moving from testing to production without a security review. Its partly due
to the nature of the product, where testing needs to be done on the real carrier lines, and once this testing is
complete, many would rather move forward due to pressure from the business to get it in.
The first thing to put into place, and this can even done if the system is in production, is reasonable
passwords/secrets on each SIP extension you have implemented. At a guess, more than 70% of systems
implemented need SIP communication with the outside world, so it is absolutely necessary to implement
this measure as it is one of the simplest ways that intruders can hack your system.
These passwords need to be of a reasonable quality, as a guide the following should be used
Passwords

Suitability

201
< basically useless one of the first passwords that they try
94932
< still poor Script Kiddies will use a rolling number generator and try again
holiday2
< poor Script Kiddies use a database of common words and add numbers
H883ksd3
<good - a mixture of upper and lower characters and numbers
h17kdi2993FDl29p23e2 <great - probably this and the one before would be suitable
It might be painful using these passwords, especially the last one, but use a spreadsheet or utilise few
random password applications out there which are also a database holding these passwords for you and
allow you to add a comment on what they were for.
Just to provide you with a statistic to put the password quality into perspective. Typically on a system with
no blocking, it is possible for a script to perform 40-50 authentication requests per second on a standard
ADSL line (12mbps/1mbps). So is possible to go through and try every word in the Oxford dictionary in just a
little over an hour. So a password like holiday2 as in the example above is most likely to be guessed in a
little over 3 hours working on the basis that they tried the dictionary again by appending 1 and the third
round appending 2 onto words.
Believe me, it is far better than having to explain to the boss why $20000 worth of calls have been made by
your system over the weekend. And this is not just a possibility, it does happen, I have witnessed it on
several occasions when asked to look at other companies systems.

Disclaimer: Your use of this guide is subject to the following conditions:

* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

It is not the just the possibility of being hacked, but also the possible impact on your Elastix system and your
network. I have seen routers that have not been able to handle the voraciousness of the attack and to the
Network manager, it looks like either his/her Internet or Router has failed. He reboots his/her router, it
works for 20 minutes and it happens all again. Likewise, it almost makes VoIP trunks useless as the
communications is so broken up, or the packet loss makes it sound like static is on the line.
So far have been speaking about passwords, and in most cases they apply to the extension
passwords/secrets, however, this same rule needs to apply to your Trunks either to your Voice Provider
(VSP) or even other SIP devices such as ATAs or GSM Gateways. Whilst in Elastix they appear to be treated
as different devices, but to Asterisk they are just another SIP device, and likewise to the intruder, it is
another SIP channel in which they may gain access to your system.
Your VSP may only provide you with a number as a login name, and a number as a password, and to be
honest, this is a little more secure than a simple three digit easily guessable extension number and a short
number as a password, but like anything, see if your VSP has a way of changing the password to something a
little more substantial. Dont panic if you cant, we have other measures we can put in place, but as I
mentioned before, the more layers, the harder it is.

Turn off Allow Anonymous SIP

Turn it off!!!!!
Unless you need ENUM functionality, which most do not, you do not need ALLOW ANONYMOUS SIP turned
on. I have yet to come across a business that is using ENUM and most businesses have never heard of ENUM
(which generally means that there is no demand for it), at least until it becomes simple to register and even
then DUNDI appears to have a better way of implementing this sort of service, lessening the security
implications.
Anonymous SIP is not a huge hole in your system, but if you can think of it, it is basically a Sand Pit that
someone can plug away looking for or and trying out vulnerabilities. Why would you want to do that??? In
fact for any client, I ask a client to sign a document stating that they understand the security implications of
this option, before I turn it on.
Whats worse is that Elastix administrators turn this on believing its a magical fix for their VSP connection
which was failing up until they did. It didnt fix anything except open up the front door to allow anyone to
walk in which also included their VSP. Its especially annoying when you see users (not just Elastix users)
proclaiming it as the fix for many issues, especially connecting to either VSPs or devices that they wish to
connect to their system. Sometimes spending the time implementing trunks/connections correctly can avoid
the need to turn on Anonymous SIP.
To be fair, some the device manuals for products that users wish to connect, have very simple configurations
as examples. The issue is that many people follow these examples (which generally are pure Asterisk
Disclaimer: Your use of this guide is subject to the following conditions:
* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

configuration file examples), and find that turning on ALLOW ANONYMOUS SIP is the only way to get it
working. The goes for some of the VSP Setups as well. They dont employ any authentication (or even simple
host IP authentication), and as such, the only way to get the connection working is again turning it on. A
quick rule is that not all VSPs are created equal. I personally steer clear of VSPs that do not support a basic
layer of authentication unless on a dedicated secure connection.
The same goes for devices, if it doesnt support a strong authentication method I will not use it. However
that said, most VSPs and devices can employ a strong authentication method, but you may have to learn
how to utilise this method and write a suitable SIP configuration. It may mean that you have to perform
some SIP debugging to see what the device is sending so that you can provide the correct responses,
especially as you implement the authentication. This may sound like hard work, and for the beginner it is,
but truly understanding the security implications of your system will hold you in good stead.
Now having said this, be careful, especially on production systems with just turning this option back off,
especially if you were not the person who implemented this Elastix system in the first place. Many have just
turned this option off and found that several hours later, they couldnt make mobile calls or worse still
werent getting phone calls coming in because they didnt realise a VSP or device was not authenticating
properly and was using this ALLOW ANONYMOUS SIP to work around the issue. It is best to make this change
after normal hours, reboot the system and perform a full range of tests, including restarting other SIP
devices.
Generally Anonymous SIP is not a huge security risk, but new Asterisk vulnerabilities are found every once in
while, and this offers a point for to commence an attack. Likewise you could misconfigure the Elastix system
and not realise that with this misconfiguration and Anonymous SIP that you have opened your system. If
anyone has watched the show Seconds from Disaster, it is generally not one mistake that causes a
disaster, but a series of mistakes.
If you feel you need to turn it on then really take the time to read all you can on Anonymous SIP on the
Internet, and even then, if you can, use a firewall to limit where those SIP Connections are coming from.
This setting is under General Settings on 2.4 (and earlier I believe), and on Elastix 2.5 it is in the unembedded
FreePBX under Asterisk SIP Settings.
While we are at it, there is one more setting that you may wish to turn off and that is the ALLOW SIP
GUESTS. This is used if you were allowing anonymous calls direct to extensions via SIP extensions.
This is found under all versions in the unembedded FreePBX under Asterisk SIP Settings.
If you are running a production system, you need to be careful turning this one as it can have the potential
to break something as it may depend on your environment, how your Gateways and Trunks are setup. The
good thing is you can put it back if you find it creates problems, however it is ideal if this setting can be
turned off. I recommend reading more of ALLOW SIP GUESTS and ALLOW ANONYMOUS SIP to get a better
handle on it. Just be aware, they are not the same thing, as some documents have incorrectly stated,
however they do have an impact on each other.

Disclaimer: Your use of this guide is subject to the following conditions:

* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

Limit installing additional products on your Elastix system

One of the biggest issues I see with Elastix systems is the disregard for security by implementing products on
the Elastix system that compromise security, or even if it is not the product itself, then the product allows
the user to compromise security without knowing it.
I have come across an Elastix system where the system owner had decided to use the Elastix Server as an
FTP Server as well. Someone installed FTP and configured it. What occurred was someone used a well known
exploit of that FTP Server to give themselves root access to the entire system. Not only did they get root
access, but they installed a hackers toolkit onto the system. Unbeknownst to the Elastix owner, their system
spent many months searching for other PBX systems to hack, reporting back to an IRC channel with any
system that it hacked with all the details. In the meantime, the reliability of their PBX suffered and as did
their internet connection (and they got charged for excess Internet). Their IT Providers response was to
disconnect the IP PBX system for 5 minutes and reconnect. It gave them a reprieve for a few hours, maybe a
day or so, but off it went again.
These toolkits are not stupid they also have a sleep function, which activates on a regular basis, which can
also include when it recognises the environment changes (e.g. reboot or cable disconnection)
Installing Webmin is another issue. It is such a powerful package that requires rights to the system. The
Internet is covered with issues relating to hacks taking place on Webmin, and to Webmins credit many of
them do not appear clearly successful, however the product itself allows the inexperienced user to make
changes to the system without considering the ongoing security implications or understanding them. Some
say they install it to get the mail working, or to implement IPTable firewalling. If you need this product to
perform these tasks, then I strongly recommend that you take the time to learn how to perform this at the
configuration level.
One of the items that you may want to remove from your Elastix system is the Vtiger CRM application which
is installed by default when you built your Elastix system. As long as you are using a recent Elastix version,
you should be able to go into the Elastix Add-ons and you will find that there is an uninstall button which will
remove the application.
As a rule, generally you want to limit the number of well known web based products from your Elastix
system. VtigerCRM is one of those products where the code is well published, well used by businesses, and
hackers will read the code looking for vulnerabilities and write scripts to look for systems that are available
from the Internet, and test the code. This is not something unique to Elastix or Vtiger but on all Web
products that are exposed to the Internet, which includes common Website CMS systems such as Joomla,
Wordpress and forums like PhpBB3 and Simple Machine forum.
One thing to remember is that I spoke about Web products that are exposed to the Internet. They do not
necessarily have to be exposed to the Internet. Have a read in a further chapter on Firewalls, in particular on
internal attacks.

Disclaimer: Your use of this guide is subject to the following conditions:

* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

Use the Permit/Deny options in FreePBX/Unembedded FreePBX.

Under the extensions configuration in Elastix you will see this screen.

As you can see, you have the ability to add the range of IP addresses that you will allow the phones to
connect from. The DENY line as it is set above disallows all addresses (classic deny all then allow specific).
The permit line is set to allow only a SIP device the local network to connect to this extension.
The same goes for access to the Asterisk Management Interface (AMI) which is set by the Asterisk API
manager in FreePBX (tools). Only allow the addresses that you need to access the AMI interface, using the
same Permit/Deny options.

That covers some of the basics that you can implement almost immediately and will provide a greater level
of security than you had previously. They dont involve a high level of skill to implement, they dont involve
you having to install any additional software, and realistically they should take very little time to implement.
We will now move onto some of the more advanced ways of increasing your security

Disclaimer: Your use of this guide is subject to the following conditions:

* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

Perimeter Firewall / Router

Elastix has an inbuilt Firewall based on Linux (IPTables) which incidentally is also the heart of many quality
Firewall/Routers. However in this section we are talking about a Perimeter based Firewall/Router, and we
will discuss the Elastix Firewall a little later in this document.
One of the best measures for security is a quality firewall/router. Let me make it very clear, not all
routers/firewalls are created equal.
Whilst medium to corporate size businesses recognise the value of a quality firewall/router, many small
businesses implement a consumer based router which has some firewall capabilities, and it remains in place
when the Elastix system is installed. One of the key components that should be reviewed before an Elastix
system is installed is the firewall/router.
Some of the features included on some of the quality firewalls are the following:

Separated NAT and Firewall Rules (e.g. in most consumer routers this is altogether)
Ability on firewall to restrict addresses that traffic is coming from
Intrusion Detection System
VPN Endpoints
Quality of Service
Packet Capture useful for debugging SIP connections but also see what is happening
Physical DMZ Connection

Yes, these firewall/routers cost a bit extra, but they only cost a fraction of what toll fraud may cost the
business owner. There are some lower cost alternatives as well such as some of the open source firewalls
which can include PFSENSE amongst others, which has many of the features mentioned above.
The following are measures that can be implemented on the firewall:

Restricting IP Traffic
If you do not have any external phones and possibly only have the one SIP Trunk, then you should consider
limiting the SIP and RTP traffic to only come from your Voice Service Providers IP Address.
This is relatively simple with a firewall that allows you to select a source address (or subnet) for the packets
on say UDP Ports - 5060 & 10000-20000. Most Voice Service providers nowadays also recognise the need to
provide this information to users, and they will normally provide a single address or subnet, so that you can
apply this to your firewall.
This will prevent scanners detecting ports open and is a simple measure that can provide a great deal of
protection.

Disclaimer: Your use of this guide is subject to the following conditions:

* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

The number of people who have good intentions of setting up a Firewalled Elastix system, but ending up
opening their router/firewall to get their Elastix system working reliably. And it happens this way because
their tested system went into production, and a day or so later (sometimes the same day), started
dropping calls or worse still not receiving calls at certain times of the day. This is generally attributed to
being forced to setup of Port Forwarding (Static NAT). If you are not sure what I mean, can I recommend you
read the section at the end of this document titled A simple guide to SIP and interaction with
Firewall/Routers
What this means however, to make your system reliable, is that you are opening up the ports for basically
anyone to try and connect to your system. Especially as SIP is generally defined as a single port number
(5060), all these Script Kiddies need to do is probe away at your Router, find the port 5060 open, and they
probe for the next few days, generally without your knowledge.
Generally for your Elastix system, when you are having problems with NAT, on the forums, they recommend
to forward 5060-5084(SIP - UDP) and 10000-20000(RTP - UDP). However, you only need to forward 5060 for
SIP if you are using an Elastix system (even for multiple conversations). The RTP ports 10000-20000 are
needed as these are used as standard by Asterisk based distributions. These can be limited based on how
many concurrent calls you expect, and you can make changes to one of the Asterisk configuration files for
RTP, but seriously, you have to open at least some, so why not leave it at the standard expected by Asterisk,
and concentrate on other security measures.
These other security measures are by utilising your Firewall function of your Router/Firewall. NAT by itself is
not a true firewall but it can end up performing many of the same functions. Generally NAT by itself has no
packet filtering, it checks the header to see what port it requires, and if a NAT rule is in place, it forwards it
to whatever address you provided in the rule. Most good router/firewalls provide port forwarding (NAT) and
also a Firewall as well. A good firewall will allow you to block or pass packets based on port number,
destination address, source address and what IP type (TCP/UDP), and generally both ways (in and out)
With a Firewall/Router that provides proper firewall capability, means that even though we have opened up
the ports needed for SIP and RTP, we can restrict them to what addresses they communicate with. Now this
requires a bit of research on your VSPs website,or possibly an email to your VSP to find out the public
addresses that your VSP uses for their SIP Servers. Dont just assume that the one you are connected to is
the SIP Server address that you need. Some good VSPs use multiple servers for redundancy, and may be
using a round robin DNS to balance out the load.
With these addresses, you can now use your firewall to only allow SIP and RTP to come from those
addresses on those particular ports. To anyone else trying to access these ports, they will see the ports
closed, which is exactly what we want.
So take the time with your router/firewall and learn how to use the firewall function. If your router/firewall
does not have this firewall ability, then look to invest in a better router/firewall.
I thoroughly recommend using a perimeter firewall. It makes plain sense not to even allow the attacker
inside your network to give them any opportunities. Furthermore, with good change practices in place, you

Disclaimer: Your use of this guide is subject to the following conditions:

* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

can do what you like inside your network knowing that the perimeter firewall is in place and unchanged,
protecting you at all times.
Alternatively if you cannot implement a perimeter firewall, wait for Elastix 2.04 which has a GUI Based
firewall based on IPTABLES built in, which is covered briefly in the next section.

Implementing Intrusion Detection (IDS)

I have raised the IDS option when talking about Quality Firewalls. It should be noted that IDS can be a
separate system and not necessarily part of the router.
Intrusion detection systems work on the basis of a set of rules that are downloadable from the Internet that
recognize particular patterns or responses from attacks. These can also include SIP patterns and responses
which also include malformed SIP requests.
In particular I use Snort (which is an open source solution). Below you will see a typical log from Snort.

What you are seeing here is some SIP traffic that has raised an Alert. I actually know the SRC address and I
know that traffic is ok, so I will create a Whitelist if I believe it is legitimate. However the traffic on the last
two lines is someone attempting to access the HoneyPot system (which is on a different IP address). You will
also note that SNORT has flagged it as a compromised or Hostile host.
The Source address is dynamic address from China, which was expected.
The other thing with Snort is that you can choose to block if an Alert is logged, or you can keep it as just a
log. This is invaluable to confirm what has happened at a particular moment. Without such a logging system,
you can in many cases only be taken a guess at what is happening.
Whilst there are standard rule sets that are downloaded from the Source Fire VRT Labs, you also have the
option to manually implement rules yourself from other sources. As an example, this link is one such link

Disclaimer: Your use of this guide is subject to the following conditions:

* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

http://blog.sipvicious.org/2008/02/detecting-sip-attacks-with-snort.html . This one is a bit old now and may

actually be in the standard rules, but it gives you an idea on how extensible the Snort IDS system is.

Elastix Firewall
As of Elastix 2.04, Elastix has a GUI Based IP Tables Firewall. Many commercial Firewall products rely on IP
Tables as the basis of their firewall, and the developers have done a great job of implementing an IP Tables
firewall with a very nice looking Web Based GUI.
Personally, I prefer to use a perimeter based dedicated Firewall as the first line of defence, but if you havent
got this capability, then the built in Elastix firewall is the next best thing. Or if you want, use a perimeter
based firewall as well as the Elastix firewall, it adds that extra layer of security which I always recommend.
Below is a screenshot of the Firewall GUI that is in Elastix. The Elastix developers have made it easy by
implementing a default set of rules which activate when you activate the firewall. It covers all of the
communications rules needed for the products currently included in Elastix

Adding a new rule is simple as per the screen shot below, and for anyone that knows how to implement
IPTABLE rules, they will find this extremely easy to follow.

Disclaimer: Your use of this guide is subject to the following conditions:

* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

If you cant wait for the Elastix Firewall product, then you can implement this same security by using
IPTABLES at the Linux command prompt and manually configuring the configuration files. To try and turn this
guide into an IPTables implementation guide is beyond the scope of this document, but on the Elastix
forums, you will find numerous posts on how to implement IPTables manually, as well as hundreds of guides
on how to best implement IPTables rules.

Fail2ban
Fail2ban is a very unique tool in that it attempts to identify Brute Force and Script Kiddie break-in attempts
and then implement rules automatically to block these attempts. This all occurs automatically and without
the need for your intervention. It actually fulfils a role of both active blocking and monitoring of these attack
attempts.
But be aware Fail2Ban is not the be all and end all. First it relies on allowing several attempts before it
blocks it, not that it is all that bad, but I would call this a secondary security method. Ideally the attack
should never have got this far if your system is secure at the perimeter, limiting any unauthorised SIP Traffic
reaching the PBX.
Another reason that it is not the ultimate solution is that it relies on the logging. So if a change is made to
the logging, you may be unaware that it is no longer protecting you. If Asterisk change the way they log, it
may fail you. In fact Asterisk has over the versions changed the way that some methods logged, and while
users though they were protected, found that they were protected only for certain events.

Disclaimer: Your use of this guide is subject to the following conditions:

* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

With Fail2Ban, it monitors the number of failed authentications from a particular IP address. If the failed
authentication attempts matches the number set as part of the Fail2Ban configuration, then it blocks that IP
address for a preset time. This generally causes these Script Kiddies to look for another system to attempt to
break into. Likewise these dictionary attacks mean that they only manage to try three login/passwords every
10 minutes, instead of 40-50 per second on a system without Fail2ban. The chances of someone successfully
guessing your login and passwords on your system are greatly diminished.
Fail2ban works in conjunction with IPTables, so you need to setup your IPTables first. There is a Web Based
GUI for Fail2Ban via the Add-ons with a small cost of $15 (at the time of writing), which is a small cost and
well worth it.
Just one other downside besides logs not logging the attempts (due to log changes or failures) is the
possibility that due to excessive attacks, your logs have filled up your diskspace, particularly on smaller
systems running fanless designs, small SSD drives etc. Anyone that has run out of diskspace, knows that
Asterisk will continue to run albeit some functions fail such as time conditions etc, but on the whole it keeps
running in memory until it is rebooted. When this occurs, no logs are written they stop dead, and although
the Fail2Ban Daemon is running, it naturally will not see any hack attempts and will fail to ban the IP address.
Sure these things (particularly on a well designed and though out Elastix system) dont happen all the time,
but it needs to be considered.

Disclaimer: Your use of this guide is subject to the following conditions:

* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

Other Security Measures

Utilising VPNs where possible especially for remote Phones
More and more Firewall/Routers have the capability to act as a VPN Endpoints. What this means is that you
can implement a secure VPN Tunnel between your Network (where PBX is situated) and the Network at the
other end (where the Remote Phone is located).
This would allow you to securely access the Elastix Web Interface and SSH ports. If you need to administer
the Elastix system remotely, then I strongly recommend implementing/utilising a VPN for this work.
Alternatively, you could implement OPENVPN on your Elastix system, and select some of the Yealink and
SNOM phones as your remote phones which have a OPENVPN Client built into them. What this means is that
you can select any port on your Router/Firewall for the VPN to come through on. This has the benefit in that
you have to worry little about the infrastructure at the remote end, knowing that you can pre-configure a
phone and let them install it. If you are using soft phones on a laptop or Android Smartphone, you can also
implement OpenVPN on these devices, and have the soft phone access the system via a VPN>
It might sound like a bit of work, but it comes down to how serious you are about protecting your Elastix
system from attack.

Changing the default port for SSH

One of the most common areas targeted for attack is Elastix systems with Port 22 exposed to the world.
Some will sit back and ask why you would do such a thing, while others feel that they cant do without it, for
remote access. Personally I wouldnt leave it open, but if you really have to, then change the standard port
number.
This is a relatively simple thing to do and in the example below I am changing the SSH port to 6222

Add a line in the file /etc/ssh/sshd_config:

Port 6222
Reload sshd by
service sshd reload
This will has now changed the port to 6222 for SSH, and while this is not foolproof, it implements one of the
layers I spoke about called Obfuscation, by not providing the attackers with a roadmap. Change the
landscape that they are expecting, and reduce the chances of being attacked.

Disclaimer: Your use of this guide is subject to the following conditions:

* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

Utilising VPNs where possible especially for remote Phones

More and more Firewall/Routers have the capability to act as a VPN Endpoints. What this means is that you
can implement a secure VPN between your Network (where PBX is situated) and the Network at the other
end (where the Remote Phone is located).
Alternatively, you could implement OPENVPN on your Elastix system, and select Yeastar T28 phones as your
remote phones which have a OPENVPN Client built into them. What this means is that you can select any
port on your Router/Firewall for the VPN to come through on. This has the benefit in that you have to worry
little about the infrastructure at the remote end, knowing that you can pre-configure a phone and let them
install it.
It might sound like a bit of work, but it comes down to how serious you are about protecting your Elastix
system from attack.

Adding a PIN Code for all outbound International Calls

Quite often, depending on the business type, you will find that the business will not make a lot of
international calls.
Providing you have implemented outbound routes for each type of call (instead of a single route which many
do when then configure Elastix) e.g. LocalNational, Mobile, International, you can add a pin code to the
International Outbound Route. So when someone dials an international number, they will be requested for
Pin code.
Many never implement this, and most of the time is because they never ask the Elastix owner if they want
this implemented. What is surprising when you ask the owner, is that they think it is a great idea as
International calls are one of the most expensive calls you can make. Quite often they only want or need a
few select staff to make International calls and to provide them with a Pin number is, in their eyes quite
acceptable.
What this has the added advantage is that if a system is hacked it also prevents calls made via the
International routes. Most toll fraud is to international numbers , particularly international mobile numbers.

Adding a time condition to your Outbound International Calls

Very similar to the Pin code method. If the Elastix owner feels that it might be too much of an issue to use
Pin codes, or the business makes a lot of International calls. Adding a time condition so that international
calls cannot be made afterhours e.g. after 6.00pm and on weekends, can again be a great risk mitigation
against toll fraud or at least limiting its impact. Again a very simple thing and easy to implement.

Disclaimer: Your use of this guide is subject to the following conditions:

* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

Port Knocking
In Elastix 2.4 a Port Knocking GUI was introduced. I have not tested this tool, and cannot provide specifics on
how it works. I have had a look for guide that clearly explains its usage, but nothing found as yet.
In very simple terms it allows you to knock on a few select ports to open another e.g. SSH. Port Knocking
can also be implemented with a password.
What this means is that your SSH port (if thats what you choose to open on a successful Port Knock), to all
port scanners, appears to be closed.
There is also some base work done on utilising the methodology with SIP, utilising unused fields in the SIP
header to create a port knock that then opens the SIP Ports to allow a SIP phone to connect. I have not seen
this being taken up in a large way, but it is an interest option.
However, I see this as another method that should be spoken about, but it comes back to being a quick and
dirty method to allow access from the outside, when other more secure methods should be employed. The
port knock is a method that is still prone to man-in-the-middle listening and replays.
However, as an obfuscation method, it definitely works as port scanners do not see the ports open.

Disclaimer: Your use of this guide is subject to the following conditions:

* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

Monitoring
Voice Provider Call Quotas
Whilst this topic straddles the headings of Security and Monitoring, it actually is very important as it is one
measure that could ultimately save you a large amount of money should your security measures let you
down.
One of the more recent changes, especially as Voice Provider look to provide value add to their products to
differentiate themselves from the next Voice Provider is daily and monthly call call quotas.
What this means is that the Voice Provider or yourself via a Web Interface, you can set a limit of how much is
spent on calls each day or totally for the month. Depending on the size of the company, you could set say a
$200 quota for the day. What this means is that once your call quota for the day is reached, it will restrict
your outgoing calls (incoming remains as per normal).
Imagine your Elastix system was hacked and they started making calls out of it over a weekend. This means
that on Monday, you would walk in and the companys liability might be $400-$600. Naturally any figure
would not be palatable, but considering they could have rung up close to $20,000 of calls over that weekend,
$400-$600 is quite a manageable amount. The best part is that if your company makes $50 worth of calls a
day, you could possibly reduce this quota to $100 (leaving yourself some headroom) which means your total
cost should your system be hacked over the weekend would be much less.
One of the downside is the fact that outgoing calls might, all of a sudden, start to fail. However it forms an
important part of the monitoring. Likewise some of these systems have the ability, once the limit is reached,
to be notified by email. In most cases you can increase the limit within minutes whilst you look at the system
to find why, whilst letting the business get on with its work.
Just a word of note on this Quota system. Many of the larger carriers of traditional services such as PSTN, E1,
T1, etc, some have a quota monitoring but dont provide it to the public. They monitor it themselves for
unusual activity, but many of them do not have real time monitoring. The figures are only provided to them
24 hours later, usually after batch (reporting) run has been completed, usually after hours. So it is possible
that $10,000 of calls can be made before they notice it.
On many of the SIP providers, their customer base is smaller, their billing systems are more flexible, and in
most cases the quotas are applied real time. As soon as that last call is made which takes it over the quota,
it restricts the calls.
So when you look at your criteria for a good Voice Provider, make sure you include a Call Quota system when
weighing up a SIP provider, but also as importantly confirm when the quota is applied.

Disclaimer: Your use of this guide is subject to the following conditions:

* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

Monitoring Logs
For many Elastix users, once they have implemented their firewall or other security measures, they sit back
believing everything is covered. They might have spent a day monitoring it to make sure no mistakes have
been done, but after that, it does not get a thought until something goes wrong, or appears to be going
wrong, or they had a lazy afternoon and decided to have a look.
Like backup systems, you cant just assume that the backup is working, only to find out when you need it
most, that the backups havent been working for several weeks. The monitoring of your Elastix PBX is just as
important
You need to set a regular procedure to check the logs to monitor for these possible attacks. It wont take
long, but you need to do it regularly.
One of the log files that you need to review on a regular basis is found at
/var/log/secure

The above example shows someone attempting to break into the system via SSH. You can see the users
names that they are trying, and this case they are trying common user names using on Unix/Linux systems.
You will find the archived logs named secure.1, secure.2 and so on. If your system is under heavy attack from
one of these Script Kiddies, then you may find that these archived files may contain attack attempts just
from the one day.
Another file to check regularly is
/var/log/audit/audit.log
This shows the login successes and failures. This is basically the Linux audit system. You mainly are looking
for unusual login failures which will give you an idea that your system is under attack.
/var/log/asterisk/full
This is the main asterisk log containing all the information about phone registrations, calls and call flows
amongst much more information. It would be impossible to read these logs line by line, but using less as
Disclaimer: Your use of this guide is subject to the following conditions:
* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

your viewer, you can search for phrases such as Registration, Forbidden, failed. You could write an
automated script to look for these or just perform a check every few weeks. Doing this will provide an
indication that someone is attempting to hack your system. Very rarely will an attacker be able to access your
system immediately (unless your system is very insecure), so quite often a successful hack is usually
perpetrated over several days or even weeks. When you start seeing these entries in your logs, you know you
need to look at your security in general and commence security improvements to stop them even trying.

Utilising the new Asterisk Security Logging

From Asterisk 1.8, there is a new feature which provides a new security feature (thank you for Sandro Gauci
from Enable Security for originally raising my interest in this new feature).
It can be enabled by editing the /etc/asterisk/logger.conf (On Elastix 2.4 systems)
full => notice,warning,error,debug,verbose,security
and adding the security at the end
or on Elastix 2.5, (FreePbx has now included this in its managed files)
by going into Unembedded FreePBX and choosing Log File Settings from the menus and selecting Security
and turning it on for the full log e.g.

Below is an example of the output after enabling it

[Mar 12 09:11:22] NOTICE[14760][C-00001122]: chan_sip.c:25081 handle_request_invite: Sending fake auth rejection for device
200<sip:200@203.133.121.42>;tag=c738a62
[Mar 12 09:22:22] SECURITY[14743]: res_security_log.c:134 security_event_cb: SecurityEvent="InvalidAccountID",EventTV="32332244499299226",Severity="Error",Service="SIP",EventVersion="1",AccountID="0123993999922",SessionID="0x7f7cd8710818",
LocalAddress="IPV4/UDP/202.133.121.42/5060",RemoteAddress="IPV4/UDP/112.78.33.22/5068"

One of the best reasons for turning this on is that it is a standard way of logging security errors. If you
wanted to, you could even have a separate log for security errors making it easier to read, instead of the
entire log.
Disclaimer: Your use of this guide is subject to the following conditions:
* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

Fail2ban can make use of this security logging, in fact if you look at any guides on Fail2Ban, make sure that it
mentions for asterisk 1.8 onwards as there are some major changes so that it reads these new logs.

Monitoring Software
I have spoken previously about looking at a Voice Service Provider that can either monitor and/or limit the
amount of calls made from your system. Whilst in most cases this is a good measure, you will generally find
that these services are offered without guarantees. Ultimately, you are responsible for the calls that you or
your system makes on the phone network.
You can perform your own monitoring by utilising products like Humbug which is included in the Elastix Addons. The Basic Analytics is free for up to 2500 calls per month (which covers a lot of small business call
requirements) and only will provide basic analytics, it is useful for business owner to see where his call costs
are going.
However if you need the fraud alerts and deeper analytics, there is a cost, but again for a small to medium
business with say 10000 calls a month, the cost is about $10 per month (at time of writing) which is a very
small price to pay and well worth it when you can sleep at night knowing the someone is watching the calls.
There is also another product in the Elastix-Addons which I have not had time to look at yet which is Mango
Analytics, but appears to provide call analytics and the product is free.
If you are after the fraud notification, then I would probably go with the Humbug solution.
However these are just examples of monitoring that you can implement. Reasonably simple to implement
and the cost savings could be in the thousands.

Disclaimer: Your use of this guide is subject to the following conditions:

* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.

Trademarks used in this document

Elastix Elastix is a trademark of Palostanto Solutions
FreePBX FreePBX is a registered trademark of Schmooze Com, Inc
Asterisk - Asterisk is a trademark of Digium, Inc.
PFSense PFSense is a federally registered trademark of Electric Sheep Fencing LLC.
Snort Snort is a registered trademark of Sourcefire, Inc'
OpenVPN OpenVPN is a trademark of OpenVPN Technologies Inc.
Yealink Yealink is the trademark of Yealink Network Technology Co.
SNOM - snom is a registered trademark of snom technology AG and affiliates in Germany, U.S.A. and certain
other countries
All other trademarks mentioned in this document are the property of their respective owners.
The Trademark declarations on this page have been sourced where the company or product mentioned
maintains a Trademark usage page.

Disclaimer: Your use of this guide is subject to the following conditions:

* Your application of these notes are entirely at your own risk.
* While tested in a Lab environment, I know nothing of your environment and may be totally unsuitable.
* You will not hold myself or any company I am associated with responsible for any damages arising from these notes. It is up to you to verify this
documents claims or comments and test in your environment to its suitability.