![](https://csdnimg.cn/release/download_crawler_static/3649372/bg12.jpg)
Elastix Without Tears Page 18 of 299
1.3 PLAN YOUR SECURITY
This part of the setting is most important and cannot be over stated.
1.3.1 Tim Yardley’s Securing Trixbox CE
For starter, the document written by TimYardley is a must read. While this document
refers to Trixbox CE, it applies equally to Elastix. This document on securing your box
can be found here:
http://engineertim.com/wp-content/uploads/2008/12/securing_trixbox_ce_ver1.pdf
1.3.2 Seven Easy Steps to Better SIP Security on Asterisk
(by J Todd http://blogs.digium.com/2009/03/28/sip-security/)
In the most part, the points below are those recommended by J. Todd but I have
taken the liberty of adding a couple of additions to make it in line with the current
versions of Elastix.
1) Don’t accept SIP authentication requests from all IP addresses. Use the
“permit=” and “deny=” lines in sip.conf to only allow a reasonable subset of IP
addresses to reach each listed extension/user in your sip.conf file. Even if you
accept inbound calls from “anywhere” (via [default]) don’t let those users reach
authenticated elements!
2) Set “alwaysauthreject=yes” in your sip_general_additional.conf file. This
should have already been set to “yes”, if not you will need to set it to “yes”. This
option has been around for a while (since 1.2?) but the default is “no”, which
allows extension information leakage. Setting this to “yes” will reject bad
authentication requests on valid usernames with the same rejection information
as with invalid usernames, denying remote attackers the ability to detect existing
extensions with brute-force guessing attacks. While you are editing
sip_general_additional.conf, add the following line as well “allowguest=no”
without the quote marks offcourse.
3) Use STRONG passwords for SIP entities. This is probably the most important
step you can take. Don’t just concatenate two words together and suffix it with
“1″ - if you’ve seen how sophisticated the tools are that guess passwords, you’d
understand that trivial obfuscation like that is a minor hindrance to a modern
CPU. Use symbols, numbers, and a mix of upper and lowercase letters at least
12 digits long.
4) Block your AMI manager ports. Use “permit=” and “deny=” lines in
manager.conf to reduce inbound connections to known hosts only. Use strong
passwords here, again at least 12 characters with a complex mix of symbols,
numbers, and letters.
5) Allow only one or two calls at a time per SIP entity, where possible. At the
worst, limiting your exposure to toll fraud is a wise thing to do. This also limits
your exposure when legitimate password holders on your system lose control of
their passphrase - writing it on the bottom of the SIP phone, for instance, which
I’ve seen.
6) Make your SIP usernames different than your extensions. While it is
convenient to have extension “1234″ map to SIP entry “1234″ which is also SIP
user “1234″, this is an easy target for attackers to guess SIP authentication
names. Use the MAC address of the device, or some sort of combination of a
common phrase + extension MD5 hash (example: from a shell prompt, try “md5 -
s ThePassword5000″)