It is no secret that IP PBX systems are a hot target these days by attackers in order to get steal free phone calls at your expense. It is therefore important to make sure your system is secure. Remember: Security is a process, not a product. — Bruce Schneier
There are many articles out there about common security practices for Asterisk and common security practices in general. I am not going to go deep into each point but rather provide a brief look-up into the main points:

  1. Protect your server with iptables:
    There are many attacks out there: SSH, SIP, HTTP and more. Avoid exposing your services unless you absolutely have to. For each service you expose make sure you protect it against brute-force attack if you case.
  2. Use fail2ban to protect against password brute-force attacks:
    There are many protections out there against password brute-force attacks on services. fail2ban is the most popular one. Many PBX services can’t simply block SIP ports because they must serve users with dynamic IP addresses, so fail2ban is a practical useful tool for that.
  3. Follow the Asterisk security advisories:
    Vicidial, FreePBX, Elastix, Goautodial (and many others) are all using Asterisk. Follow their security advisories and make sure your Asterisk is up to date (or at the very least try to understand the impact of each vulnerability).
  4. Log to remote servers:
    By default, Asterisk logs all its activity into local files, usually in /var/log/asterisk. Asterisk logs can be sent to standard unix “syslog” daemon instead of the local files. There are many advantages to this approach, and one of them is that you will be able to send your logs to a remote server. In that case, if you have a security breach and the attacker has gained root then the former can only wipe the local logs, not the remote ones.
  5. Secure passwords do matter:
    Don’t use easy passwords such as 185901. Use difficult passwords that are not easy to guess. A password brute-force to SIP over UDP is quite cheap in terms of performance and bandwidth cost.
  6. Minimize web access to your PBX:
    Security vulnerabilities are common in web services. Make sure to follow the security updates of your product (Elastix, FreePBX, etc) and try to use iptables (or any other IP restriction) to minimize the access of guests to your system where it’s not necessary. If it is truly necessary, consider using Web Application Firewall such as mod_security.
  7. Watch your logs, monitor for intrusions:
    Make sure you have easy visibility to your CDR (Call Detail Recordings), your system logs (Splunk, and plenty of others), network and system statistics (Munin, Zabbix), network performance (smokeping), intrusion detection (Snort). You must know your system and follow it closely in order to find suspicious behavior.
  8. Harden your system with grsecurity, AppArmor, SELinux:
    It is not easy, but once you pass the learning curve you will be able to protect yourself slightly better against the unknown by restricting unwanted system operations of your daemons and applications.
  9. Test yourself – automated penetration tests for script kiddies:
    SIPVicious, Nessus and many more tools can help you test your own security. If your attackers test you by using SIPVicious, so should you.

Understanding Better Asterisk Default SIP/IAX2 Peer Context

By default, Asterisk delivers the following in sip.conf:

context=default   ; Default context for incoming calls
;allowguest=no    ; Allow or reject guest calls (default is yes)

Many people tend to leave that configuration as-is, which is ok. However, many people use the default context for many other purposes such as for outbound calls extensions like this:

exten => _00X.,1,Dial(SIP/commpeak/${EXTEN});

That means that any call coming with 00, with or without IP or Username authentication, will be passed to CommPeak and the call will be completed and therefore, billed on your expense. For tools such as SIPVicious, it is very “cheap” to make such scanners because it only costs a single UDP packet to test that (per test, of course).

Another problem that might occur is that at certain versions Asterisk may match unauthenticated calls with a valid context, one which you unattended to use for. Because of that, I personally like to do this at the end of each sip.conf file:


It may look like an odd practice, but it served me well.
Once you have finished configuring your Asterisk, enter your Asterisk’s console (asterisk -r in ssh), enter “set verbose 10” to increase visibility. Make an unauthenticated call from outside of your network to your Asterisk using your common dial plans (dial the same numbers as you would if you would have called inside your network as an authenticated user) and make sure it is blocked. You can see on the Asterisk console which context it matched the incoming call to.

Stay safe.
*This post offers unique and original content prepared by the CommPeak team. All rights reserved. For more information on CommPeak, feel free to visit our Voice Termination website.