Since the early versions of Elastix, several security issues have been reported. Although, a lot of users and novice administrators are unaware and thus do not fix up this problem in corporate environments.

In the early versions of Elastix there were default passwords for most of the services and administrator interfaces, including the database server. If the administrator wasn’t experienced enough or didn’t review the documentation before deploying the solution, it would lead to a hacked server or worse, a huge phone bill to one of those exotic destinations where US based businesses never call.

It didn’t take the Elastix development team long to include a password change script, available during the OS installation stage. Plus it also developed a security module that bundles several tools including an audit interface that tracks all the actions that the users commit on the main web interface.

It is really important to understand that securing a VoIP server is not an optional task. There are several interests in hacking VoIP servers. Hacking VoIP servers to generate traffic represents cash payments to the hackers who get into them, and that is why, it is a very common practice among black hat hackers.

Another common practice that several administrators tend to perform is to connect an Elastix server to the DMZ interface on their external firewall, just to be sure that the system “works”. Not a very smart idea, isn’t it?

The truth is that like other UCS systems, Elastix integrates several software packages, each maintained independently. For example one of the CRMs included in the bundle is vTiger, which has a very severe security flaw, discovered recently, that could allow arbitrary remote code execution on unsecured and unpatched servers.

Zero day exploits (as they are called) are impossible to predict and usually it takes the developers several days to announce and fix the issue. So, on our side as security administrators, we need to take measures to mitigate the risk of our servers getting hacked.

Of course we’ll never be able to provide a 100% secure server. The only way to achieve that is to keep a server in a locked room without network connectivity… powered off…
The recommended practice is to implement the ID and IP systems along with firewalls in order to have an acceptable secure environment.

Today we are focusing on the firewall aspect of the security. As we mentioned earlier, Elastix includes a firewall (Iptables) that provides a very convenient way of setting up the rules for our system.

Elastix Firewall

The Elastix firewall configuration interface conveniently includes all the ports required by the different software pieces that comprise, for example, the ports required for the IM messenger to work or the SSH administration console port.

Generally, what we recommend is to allow only the hosts that will be involved in the system operation (including VPNs) and to block all the traffic that doesn’t belong to our system’s required traffic.

On a typical installation where we use SIP trunks and our endpoints are located on the LAN we only allow traffic between the LAN and the Server’s IP. From the outside we only allow traffic for the SIP provider on the port ranges required by SIP (usually the UDP port 5060 and in the range of 10000-20000).

The problem occurs, again, when distracted administrators activate the firewall and leave it with the default settings, which is basically the same as not activating it. Since, by default these rules allow the traffic to go through those ports without filtering any IP address.

This is why turning on the Elastix firewall is not enough. We also need to setup the rules and block the ports to prevent unwanted access to our servers and to be a little bit safer.

Next time you configure security on your UCS server, please make sure you configure the rules accordingly.

This article was written by Juan Pablo Bustos, from NUsource Technology Group, an official Elastix Training Program instructor and provider of enterprise-class solutions for businesses.