Past few days I’ve been thinking about the stuff our students were asking during our FreePBX training course. One of the main thing that they were talking about is security and how “bad” Asterisk’s reputation has been with security in the past. I must agree with them. There’s enough worrying cases of poor implementations, deployments and management since Asterisk took center stage some years back giving run for big IP telephony players. AND, we also must say that we’ve had our share of scares and have come a long way since, thanks to mistakes done in the past. The whole security scene with Asterisk (or any products out there) will continue to be a living, growing and evolving problem, no doubt!.
While it is quite easy to
“blame it on the people who deploy for not securing it”, I feel its some what also every single Asterisk/FreePBX folks' responsibility as subject matter experts and consultants on Asterisk to keep up the good name of the product and continue helping the community get stronger by helping each other as much as possible.
With that, we advise all those who deploy solutions for their customers, to take into serious consideration
some sort of security best practices, starting with those highlighted by Digium
here and do keep track of the Asterisk security Advisories
here. While there are many other things you need to be aware of and not just Asterisk/FreePBX security, it’s definitely THE STARTING POINT TO LOOK AT.
Anyway:
Here’s a small list of things (a checklist if you may) that you
could consider for each deployment out there. These are especially important when you put your server out on the internet (public facing). I would like to highlight, these are merely suggestions and not an ultimatum but I know sure as anything, they do help.
A little bit of something is better than a whole lot of nothing.
Anyway, we would like to present the following things you should implement when you deploy an Asterisk/FreePBX solution. We figured it would make sense to couple it together with FreePBX since it’s probably the most deployed front end.
The 10 security things you should consider after an Asterisk/FreePBX installation
1) Do not open it up to the internet (unless you absolutely need to)
Even for the sake of testing, implement VPNs and firewalling based on source IP addresses to start with. Unless it’s a business requirement, only then put it up on the Internet by following this guide here and lots of esteemed writers out there and their guides too. Firewalling is a must, open only ports you want to be used over the internet. Management ports and protocols such as HTTP/SSH should be disabled from the internet and must have complex credentials.
2) Update everything
A new install should be updated with everything, operating system, FreePBX and Asterisk version. Update does not mean use new versions but the updated version of what version you prefer. Most OS distros like CentOS and Debian, have very easy ways to manage and get updates.
3) Do not use default FreePBX password, use database for authentication
Manual installations of FreePBX may have/use default passwords. Follow these guides to change them.
a)
AMI Password
b)
MySQL password
c) ARI password (edit amportal.conf or advance settings module)
d) FOP password (edit amportal.conf or advance settings module)
e) Change authtype to database (edit amportal.conf or advance settings module)
3) Create new-anything with complex passwords
Absolutely never create easy to guess extensions, trunks and DISA, etc passwords. The passwords acceptable includes all types of characters and combination. Use them.
Here’s a good place to learn about complex passwords. Use the FreePBX Weak Password Detection module to help audit your passwords
4) Limit your extension registration source IP
For all extensions that are not public facing, define that those extensions are only accessible via your internal network. This ACL type limitation can be done at both extensions and trunk levels. On extensions, you have something called the “deny” and “permit” and “host” definition in your trunk settings
5) Use fail2ban, application firewall
Fail2ban will help with some of those scanners out there. If anyone tries to get into your system without providing correct credentials for
n number of times, their IP will be banned for as long as you please (using iptables). Here’s how to get fail2ban to
work with Asterisk. While many say this is the silver bullet, I strongly disagree, its not, but it sure it a first grand step. I am starting to like BFD nowadays (
http://www.rfxn.com/projects/brute-force-detection/) because it is a little more flexible with the rules using simple bash commands to get info and how to ban stuff as opposed to fail2ban which only allows regex
6) Obfuscation
I know, many will say, this is not security, true. It’s not security but it helps. Most people attack Asterisk systems because they know its Asterisk. So, lets try to throw them off course a little shall we?
How? Well, here’s what I suggest to do first (Change/add the fields below in sip.conf or in FreePBX use the SIP Settings module right at the bottom where it says “other sip settings”)
a) useragent=<somethingweird> like useragent=SIPSERVE
b) Change the realm, e.g. realm=sipserve
c) Set alwaysauthreject=yes (
here’s why)
d) Using a front firewall, block off IAX2 (4569), AMI (5038) and probably MySQL (3306). All those can give away easily you’re using Asterisk
Remember the above are mostly only to thwart off scripts that look for Asterisk servers in particular.
7) It’s a PBX, let it be a PBX, not a file server, or etc. Reduce surface attacks.
I think the subject matter above speaks for itself. Like your Cisco switch, its meant to be a switch, you don’t put a file server on there do you? So, the Asterisk box is a PBX, don’t put other crap in there.
If there’s a FreePBX module you don’t need, disable or remove it.
If there’s a protocol you don’t need (e.g. IAX2, H323) disable it too.
8) Use custom contexts and/or some neat restrictions in FreePBX 2.10
a) When using FreePBX 2.10, you can set max calls per extension. Set that to one!. There’s really no reason why one extension is firing 10 calls at the same time. They don’t even have phones with that many lines do they?.
b) Use time restrictions for external calls. For example, if your office only works till 8pm at most and starts at 8am, restrict calling out during these times only.
c)Now custom contexts can be used to limit down where an extension can call, e.g. 1000 can only call local numbers. I am sure you will have more people with restrictions then those unrestricted. So if at all an extension is compromised, probability of them hitting a restrictive extension and that may help you reduce the damage.
d) Also, use uncommon dialout prefixes, e.g. #9 to dial out. When an extension gets compromised, the attacker also must learn how you dial out. If there’s no prefixes in their call, then the call will fail. They can’t figure out the dialplan with just a compromised extension!
e) Limit the max amount of calls per trunk level at one time
9) Send commonly compromised numbers/countries to a blackhole
You should create an outbound route right above all that will hit to a fake trunk (create a ZAP/DAHDI trunk and use is as g100). Put all commonly exploited numbers/uncommonly dialed numbers in there. Remember, its like a firewall, close as much down as possible then open as the need arises
10) Turn on as much logging as possible, backup backup
With Asterisk 1.8 there’s a “security” only logging you can switch on but in the lower versions of Asterisk, you should always keep your full log on and flush them periodically if you want. Also, log all CDR calls. Logging helps you look for “odd” stuff for auditing purposes.
Backup your stuff and restore them in case someone gets admin access to your system and changes everything, a restore can quickly bring order back. And of course, backup for the sake of recovering in case sh1t happens, you know
neat huh…, its an island within Sabah, a state in East Malaysia. Can’t mention much details for privacy purposes 
