fail2ban
monitors Asterisk logs for failed ‘Register’ attempts and blocks the IP using IPTables. This means if you get yourself blocked it will appear as though the server has gone down

denyhosts
monitors /var/log/secure for failed SSH attempts and just blocks the IP for SSH access. You will get connection refused just for SSH if you get yourself blocked

It’s possible to whitelist your own IPs so that they don’t get accidentally blocked by following the instructions below.

You should replace 123.123.123.123 with your own IP -

There are a few different names given to a virtualized server – Virtual Private Server (VPS), Virtual Dedicated Server (VDS), VM (Virtual Machine) but they all refer to the same overall goal – take a dedicated server and partition it in to several virtual servers that share the underlying hardware.

Now, don’t get me wrong, I really like VMWare ESX. In fact I spent many years as a VMWare admin running mission critical ESX clusters that needed to be available 24/7. These hosted corporate web systems that processed many £100k’s of transactions per year. So does that make it the perfect platform for offering Asterisk hosting? Not necessarily.

VMWare and KVM both provide ‘full virtualization’ which is a layer in between the hardware and VPS that emulates the hardware and provides the virtual machine access to it. This means the operating system on the VPS does not need to be aware that it is running inside a VPS. It runs as normal, with VMWare/KVM translating the requests to the underlying hardware. Xen can now also do this running in HVM mode.

While this provides good segregation between the Virtual Servers it does add a layer between the VPS and underlying hardware that can cause timing issues, which are so critical to VOIP/Asterisk. This is not always the case, but a possibility.

OpenVZ is different. This provides operating system-level virtualization where the underlying hardware runs a kernel that is shared by all of the virtual machines. On SysAdminMan VPSs this is CentOS. This provides more direct access to the underlying hardware which, in my experience, makes it an ideal platform for hosting Asterisk.

Where OpenVZ gets a bad name is that it’s very easy to provision many more VPSs on a physical server than that server can really handle. This means lots of virtual machines all trying to use the CPU, ram, network etc on the underlying server, resulting in bottlenecks. This might not be a problem on a webserver. If a web server takes half a second longer to display a web page because the server is overloaded then maybe nobody will notice. However, if your VOIP packets are delayed for half a second then you will definitely notice!

SysAdminMan only has around 10 virtual servers per physical server, often less depending on the resource allocations to the VPSs on that server. This results in a lot less contention for the underlying hardware than with some providers (especially general VPS providers) that might have 20, 30, 40 servers running on the same hardware.

Probably the most crucial fact about running Asterisk on a VPS though is who you are sharing the underlying hardware with, and how well the server is managed. Even if there are only a few other virtual servers on that server and they are allowed to abuse the resources available then you will likely get a bad VOIP experience. This can definitely be the case where Asterisk is installed on a general purpose VPS.

All SysAdminMan VPSs are specifically designed to be running Asterisk. The underlying hardware is closely monitored and you can be sure that you are not sharing the hardware with customers running highly demanding Java application servers or game servers etc. It can be very difficult for VPS customers to troubleshoot VOIP quality issues on their server as they have no visibility to the underlying hardware. You have to trust that your VPS provider is not allowing the underlying server to be overloaded.

The Asterisk hosting market is definitely getting more competitive but I’m confident that the service and products offered by SysAdminMan represent excellent value for money and a stable and well managed platform to host your VOIP server. SysAdminMan has been successfully hosting Asterisk servers since early 2009.

A really useful tool for checking your DNS config is intoDNS. You just type in your domain name and it will run some tests and highlight any potential issues it finds. It uses the authoritative DNS servers to try and rule out any confusion caused by DNS propagation times.

Check it out here – intoDNS

First, whenever making changes to iptables I always temporarily disable them from running at startup. This way if you make an error and lock yourself out the server just needs a restart. You must remember to re-enable at the end!

Disable iptables at startup and copy the existing configuration -

Next list the current inbound rules with their line numbers -

So https access (port 443) is allowed in rule 9. Now we are going to delete this rule -

Now we add in the new rule to allow access to port 443 from a particular IP address. You will want to change the IP address below (123.123.123.123) to be your IP address. You may also want to change the Ethernet interface (venet0) if you are not using a SysAdminMan VPS -

Now check that the rule is working correctly. If it is we can save the current rules and enable them at startup again -

So here’s how.

Firstly all of my VMs live on LVM so create a virtual disk to hold the VM. I’m creating a 20G ‘partition’ in a volume group called kvm-storage. The logical volume is called host.demo.com.

Now download the CentOS install ISO. Either CD1 or the netinstall ISO should be fine -

Now we mount the ISO -

Now we run the virt-install command. I suggest putting this command in a file and running it from there to make editing easier!

Here are the parts of the command above that allow for a text based install -

–nographics  – tells KVM not to allocate a graphics console to the VM

-v  – means we’re doing full virtualization

-l  – sets the boot location to be the ISO we mounted earlier

–disk  – sets the install destination disk to be the disk we created earlier

-x “console=ttyS0″  – sets a kernel boot parameter telling CentOS to use ttyS0 as the console

Once this is done you should see the text based installation screens. This worked pretty well in putty, you are able to tell what menu options you are selecting. You won’t be able to use the mounted ISO for the actual installation media so I did a HTTP install, selecting one of the CentOS mirrors to do the install from  (like – http://mirrors.manchester.icecolo.com/centos/5.5/os/x86_64/)

Once the install is complete and the VM rebooted you can access the console again by running -

Over the past few weeks we have seen a big jump in the scanning of VOIP servers. All of these scans are brute force scanning attempts that first scan for valid extension numbers and then to brute force guess the extension password by repeatedly trying different passwords.

Unfortunately Asterisk doesn’t have anything built-in to prevent these types of scans but it is very good at logging these attempts in the Asterisk logs. This means we can use a free utility called fail2ban and the linux iptables firewall to block IP addresses that make repeated failed login attempts.

Fail2ban is already included in PBX-in-a-Flash but we can also use it with other Asterisk distributions.

Most of the information in this post was taken from here, so please visit for more information.

Here is a quick guide for getting fail2ban blocking Asterisk brute force scanning on a 32 bit CentOS server. You must have iptables installed already.

First we are going to install the rpmforge repository and use the fail2ban package from there -

Now disable the rpmforge repo do that it doesn’t interfere with any of the CentOS/Asterisk packages -

Next we are going to create the fail2ban configuration file for Asterisk. This tells fail2ban what text to monitor the logs for -

Next we are going to add some lines to the jail.conf file that tells fail2ban what log files to monitor and what action to take when the required text is detected. This includes sending an alert e-mail so you may want to change ‘root’ to your e-mail address. It also includes the length of time the IP address is blocked for in seconds. Here we have it set to 3 days, you may want to modify this -

Fail2ban needs the date in the Asterisk log files written in a specific format. To do this we can add a line to the ‘General’ section of the Asterisk logger configuration file. If you already have a ‘General’ section in there you will just want to add the line manually rather than running the command below -

Finally we want to fire up fail2ban and set it to start at boot time -

One final thing you may want to do is ‘whitelist’ your own IP address/s. You can do this by adding them to the ignoreip line in the jail.conf file. Here’s a couple of lines to do it automatically, just change the IP address here for your own IP address -

rpm -Uhv http://apt.sw.be/redhat/el5/en/i386/rpmforge/RPMS/rpmforge-release-0.3.6-1.el5.rf.i386.rpm

All Sysadminman VPSs come with IPTables enabled. However to allow for VOIP traffic both SIP and IAX ports are opened.

If you know that your VOIP providers and all extensions are on fixed IP addresses then it is possible to limit connections to just those addresses.

First let’s list all the VOIP traffic rules that are set up -

The extract above just show’s the sip, sip-tls and iax2 rules.

Now let’s delete those rules. Warning! All SIP/IAX2 traffic will be blocked as soon as you run this! Note that your line numbers may be different. Make sure that you delete them in reverse number order or the numbers will change as you delete them.

Don’t delete this rule if you use SIP as it is what opens the high port numbers for the actual voice/media stream -

Now, let’s assume that our SIP provider is at 1.1.1.1 and our extensions are at 2.2.2.2. Let’s allow access from those numbers for SIP.
All lines are inserted at rule 10 and get shuffled up -

Let’s check that those rules look OK (again, only listed here are the VOIP traffic rules) -

Now test that everything is working as you expect. If it is you can save the rules so that they are loaded next time you reboot -

If you make a mistake while editing the rules then just restart iptables to restore your old rules. Note that you can only do this before you save your new rules!

It’s relatively straight forward and inexpensive to get yourself a valid, externally signed, certificate.

The sysadminman template uses lighttpd as the web server so you need to follow these instructions -

Log in to your VPS as root:

Next create a folder to store the keys and then create the key. Make sure to replace the server name with the DNS name of your server. This must match the name that people will use to browse to your webserver/website. You will need to enter a password for the key at this point but we will remove it or it will need to be entered every time the webserver starts.

Next generate the Certificate Signing Request (CSR). Be very careful when entering he hostname. This must match the name of your a2billing/FreePBX website. You can leave the password blank.

Now print the CSR and copy it

Now order your SSL certificate from - http://www.namecheap.com/learn/other-services/cheap-ssl-certificate-rapidssl.asp. Select Apache + OpenSSL and paste the CSR text from earlier.

Complete the order process. You will be required to accept an e-mail to a predefined address. This must be a valid address as you will receive an order confirmation e-mail which you must acknowledge.

You will ultimately receive a zip file containing your certificate. You want the text from the file with your server name ending in .crt.

Create a file on the server called yoursername.crt and paste in the contents of the crt file

Next combine the key and certificate to create a single .pem file.

Now edit the lighttpd config file. Locate the reference to the existing .pem file and change it to your new .pem file

Now restart lighttpd and ensure it starts backup correctly

Here is my first attempt. It’s also my first attempt at writing something in Python so you definitely use at your own risk!

There is room for improvement as there is no validation on any of the fields extracted from the e-mail.

It also assumes that these components are already in place -

• Asterisk (with Astersk Manager Interface)
• E-mail server (I’m using Postfix)
• Ceptral text-to-speech (www.cepstral.com) – installed in /opt/swift/bin
• Python (I’m using v2.4.3)

First we need to pipe the incoming e-mail to our Python script. For this I added a line to /etc/aliases -

and ran newaliases -

Now for the script which is called ‘/usr/local/bin/emailspeak.py’

You will need to change at least the USER, SECRET and TRUNK settings at the top of the script to match you Asterisk setup.

And that should be it. To test just send an e-mail to emailspeak@yourserver.com with the telephone number you want to call as the subject line, and the text you want to be read in the body.

Don’t forget to write the telephone number in the format that your SIP provider is expecting it.

It’s not surpising that scanning for vulnerable SIP servers is on the increase – these sort of tools are really easy to use, and with the lure of making free phone calls at your expense it’s definitnely worth making sure that your PBX is secure.

Here’s what I did to scan one of my servers. The server is a Trixbox CE 2.6 server and I set up the following extensions for testing -

Next I downloaded Sipvicious -

Now, first we need to find the Asterisk server we want to scan and for that we use svmap.py. I obviously know the name of my server but svmap.py will also scan blocks of IP addresses too.

So all I had to do was give it the hostname/ip address of my Asterisk servers and svmap has successfully identified it.

Next we want to see what externsions are configured on the server so we use svwar.py

The “-e 1000-9999″ tells svwar to scan for all extensions between those numbers. As you can see it returns the test extensions I configured and also tells us that extension 1001 doesn’t need a password to connect to it. So potentially, as a hacker, I could already connect as this extension and start making calls.

Now let’s see if there’s any other vulnerable extenions with svcrack.py -

The “-u 1002″ tells svcrack which extension to try and guess the password for and “-r1-9999″ tells it to use that as a range for potential passwords. It took about 3 seconds to try all the numbers between 1 and 9999 and guess the password. It’s definitely not a good idea just to use numbers for your passwords!

It’s also possible to download dictionary files (just long lists of words) and tell sipvicious to use those as potential passwords. This obviously takes longer to run.

So, what can we do to protect ourselves?

There are a few really simple things that can make our Asterisk servers much more secure.

Always use long, difficult to guess passwords for your extensions!

Set “alwaysauthreject=yes” in your sip configuration file. What this does is prevent Asterisk from telling a sip scanner which are valid extension numbers. Here’s what happened when I changed the setting on my Trixbox -

I edited the file /etc/asterisk/sip_custom.conf and entered the line

Then reloaded SIP in Asterisk with -

Now if I run the same command as before to see what valid extension numbers there are I get the following error -

There are other things you can do and there is a great article here – http://blogs.digium.com/2009/03/28/sip-security/