Canadian TV, Computing and Home Theatre Forums banner

1 - 8 of 8 Posts

·
Member #1
Joined
·
47,683 Posts
Discussion Starter #1
Received this today via email from VoIP.ms

We are contacting you with some suggestions on how to improve the security of your PBX systems and VoIP adapters. We have no specific reason to believe your system may have been compromised. This is a courtesy email sent to all our customers.
Remainder of email below.

Thoughts on this?
 

·
Member #1
Joined
·
47,683 Posts
Discussion Starter #2
Rest of email

Based on the broad view we have of thousands of customers, leads us to believe that most of the hacking cases for the purpose of placing unwanted calls, can be avoided my following these suggestions:

1) Use strong Passwords: We can't stress this one enough: Use strong passwords! One of the first actions many people do when after they install their PBX, is often to create a phone extension with an easy password. Avoid using short or weak extension passwords. Please remember to use passwords of at least 8 characters, including a mix of upper and lower case along with digits. Remember to change them periodically every 2-3 months at most.

2) Public Internet: Avoid leaving your PBX systems, ATA Adapters and IP Phones open to the internet. Do not use DMZ mode on your router and do not forward ports to your equipment, unless you absolutely know what you are doing. This is only needed on specific cases, and only leave it open to the internet if you have experience on how to properly manage security on equipment that is open to the internet.

3) Asterisk Tweak: If you are using an Asterisk based PBX, add the following line to the sip.conf file under the [general] section and issue a reload
alwaysauthreject = yes

What this parameter does, is that it will always return an authentication error instead of a .404 not found:., even when the extension doesn't exist. This steps-up the difficulty for brute force scanners when they are attacking your PBX.

4) Trixbox, PBX In a Flash and other web interface based PBX: Change the default password. Different flavors of PBX installs come with default administration passwords. Make sure to change the default passwords immediately after your installation and also make sure the web interface is not reachable from the internet.

5) PBX Dial Plan: Do you make international calls? If no, do not allow international calls to be placed from your PBX. In Asterisk, remove ._011.. Or .00_. . Never use ._... If you are only calling a few countries on a regular basis, enable these countries only. For example: The only country you're calling is UK? Only configure _01144. In your dialplan.

6) Use additional caution while travelling: Do you plan on using a soft phone at a random internet cafe? Make sure you remove your login details after using it, and uninstall the software if possible.

7) Asterisk and Fail2ban: As an additional step you can install an additional security tool such as fail2ban, which is a free brute force detection system, it scans the log files of your PBX and then takes action based on the entries of those logs.
(http://www.voip-info.org/wiki/view/Fail2Ban+(with+iptables)+And+Asterisk)
We also offer the optional service of installing fail2ban into your Asterisk PBX. A trained linux Asterisk professional can install it on your system for a one time fee of $150 USD.

There are various other measures that you can perform to secure your VoIP equipment, however this email covers some of the most important aspects. The technology and the methods used by abusers keep evolving constantly. Meeting the recommendations on this email you will have a more secure PBX system.

Feel free to contact us via Live Chat or through the ticketing system should you need any more information regarding how to improve the security of your PBX system.

Kindest regards,

VoIP.ms Technical Support Team
 

·
Registered
Joined
·
3,022 Posts
Got the same email, and I thought it was prudent advice, especially given that VoIP.ms systems have the potential to be far more complex than other consumer VoIP systems.

I can only assume that they see problems on the rise if they sent the email. I have all my IP phones behind a NAT, so I'm ok, but this post shows that it does happen:

http://digitalhome.ca/forum/showpost.php?p=1201393&postcount=1450
 

·
Registered
Joined
·
33 Posts
2) Public Internet: Avoid leaving your PBX systems, ATA Adapters and IP Phones open to the internet. Do not use DMZ mode on your router and do not forward ports to your equipment, unless you absolutely know what you are doing. This is only needed on specific cases, and only leave it open to the internet if you have experience on how to properly manage security on equipment that is open to the internet.
I need web access to a couple of ATAs. Right now I have the "enable web admin access" set to YES. In the routers I have external port xxxxx forwarded to port 80 on the ATA. I have set up strong passwords of course, but the usernames remain "user" and "admin" since these apparently can't be changed AFAIK.

Is this unsafe?
 

·
Registered
Joined
·
3,022 Posts
Can you move the web port off of 80? That's the first thing I would do, since common ports like FTP, SSH, telnet, http, etc get sniffed first...
 

·
Registered
Joined
·
877 Posts
Other than what's been said, the only other things I could think of are using a VPN or if you have a static IP address, restricting the router to only allow admin access to your IP.

As for if what you're doing is unsafe, I don't think so. I've never heard of anyone brute-forcing an ATA but would be interested to know if anyone has had that happen.

m.
 

·
Registered
Joined
·
33 Posts
@99semaj: AFAIK, the ATA interface cannot be changed from port 80. But I don't think port 80 can be sniffed: on the WAN side, I have port 5555 open. And the router is forwarding port 5555 to port 80 on the ATA. I think this will prevent it from being sniffed?

@Mango: Unfortunately I don't have a static IP and tomato won't let me use a dyndns for the source address in the port forwarding config. I've also had VPN on my mind for some time but I'm not sure how feasible it is for my case (although I haven't set up a VPN before so maybe I'm wrong).

I agree that the risk of a brute force attack on an ATA probably isn't very likely...and I'm hoping that simply having the web interface off of port 80 will be enough to prevent that possibility. Actually, just a few weeks ago I wouldn't have even thought about a brute force attack. But after setting up QOS in Tomato I discovered (by looking at the graphs/details) that one of my machines was being brute forced on 3389 (RDP) and I've become a bit more security-minded since that.
 

·
Registered
Joined
·
3,022 Posts
You know, if I was a bad guy, an ATA would be exactly what I would want to attack. Long distance access can easily be monetized and resold. In most cases, the value wouldn't be worth pursuing legally.

How hard would it be to write scripts to seek and break common ATAs? Sounds like the perfect scam for someone to set up.
 
1 - 8 of 8 Posts
Top