New deployment, security concerns, phone questions

Sorry if I posted in the wrong section, but I’m really a newbie here transitioning from the traditional TDM hard wired PBX environment. I have an Asterisk server installed (about to install FreePBX) along with SIP trunks from my carrier. My provider will only provide me Trunks over my MPLS which means the Asterisk server has to be on my internal network. The goal is to have internal users and external users registered to the server, and at the same time overcome any NAT issues that comes along with Audio problems. Would it be best to have two NICS, one on my internal and one on my external network? Security is definately a concern in doing that! so any advise is welcomed.

Also, I will have several models of phones to register (Polycom, GrandstreamGXV3175, CiscoSPA504G). Is there options for these phone types in the GUI or will I have challenges adding these via CLI.

Do not expose the phone system to the Internet under any circumstances. No commercial vendor supports this configuration (Cisco charges 30k for a SIP gateway license) and you should not do it with an open source system either.

The correct way to connect remote users is with a VPN. An SSL VPN for roaming users and a point to point for remote locations.

What about the case of having a user from home plug in a phone on their home network that needs to register to the system?

I must add that the exposure to the internet I’m considering DMZ so I can only allow certain ports, my internal is on a different zone that I build policies between the DMZ and that internal zone allowing only certain traffic. I imagine that would minimize some risks? any thoughts?

For home users you can use the Cisco SPA525G that includes a built in IPSEC VPN client.

The other option (and then one I choose) is to put a VPN router at the users hours. VPN routers are now less than $100 so they are only a few dollars more than a regular home router.

If you open port 80 to untrusted IP’s you are really asking for trouble.

If you open SIP (usually UDP 5060) you are risking toll fraud.

SkyKingOH - I’m on a corporate LAN with a Corporate DMZ as well. I already have port 80 opened to web servers on the DMZ so I would do the same for the Asterisk as well (not TFTP). With regards to 5060, I’m following the rules of strong passwords for device registration, and using Fail2Ban as suggested in this community, so do you think I’m still at a great risk or is my risk somewhat lowered?

A DMZ is simply a mezzanine between two networks that a rule set is applied to.

If your DMZ allows any host to access port 80 on your server with FreePBX installed you are taking a major risk.

Strong Passwords and Fail2ban certainly lower your request. It would be impossible to quantify the actual level of risk.

So it seems that FreePBX is what is creating the hole with port 80, but I need port 80 or 8080 to have the external phones register, right? Or should I be using a different method of registration? Sorry for all the questions but I’m trying to learn the security risks and you have been real helpful so far.

Fail2ban has been debunked as a security mechanism for Asterisk awhile ago:

Port 80 is only used for administration so there is absolutly no need to expose port 80 to the public. Phones register on 5060 (or an alternative port if configured) and use teh defined UDP ports for voice transfer (usually 10000 - 20000 but I usually limit the number of ports to a much smaller range, usually 2 per concurrent call).

I do however agree with several of the previous posts, exposing a SIP Server to the public internet always has risks and the closer you can keep your firewall the better.

I was thinking about security this weekend and one of the most important steps you can take is to properly set the permit and deny statement for each extension. Set the local extensions to only allow registration from the localnet.

Set the remote extensions to only allow the remote IP if it is static. If it is dynamic you could allow the entire netblock from the provider. This, while still having some risk, is orders of magnitude better than allowing all IP’s to connect.

Still thinking about security, so if the phones from outside need their configs, it either has to be TFTP or HTTP while they do register over 5060. I will not open TFTP so then it may as well be HTTP. Am I right? I thought majority of the folks that deploy Asterisk is to allow external users the ease of connecting without too much hassle. I do not want to be up at night troubleshooting at home users VPN connections and their network problems…

That would be a perception. Certainly security and the level of “hassle” have an inverse relationship.

If you have to remote provision the phones I would suggest FTP. Opening up HTTP for only provisioning would be a chore left for the very knowledgable as you would only want to allow external users to access the provisioning files. There is also the possibility if an Apache vulnerability allows listing the directory on the web server the configs would be exposed along with the SIP credentials.

Having a high interest in infosec, I personally like the suggestion of the Cisco SPA525G if it does in fact have ipsec VPN functionality built-in AND you support that (or can support that) on your network.

Otherwise, I’d say limiting the IP range that can connect would be a fairly decent solution. Doing this at the firewall level would help me sleep better at night.

Also, I did a quick Google search for Asterisk and OSSEC which seemed to return some promising results. I use OSSEC on a web server to automatically block IP addresses that are hitting 400 errors in Apache (think 401 access denied).

OSSEC just monitors log files, but if it was configured to automatically block IP addresses after so many unwanted entries in a log file it should be effective.

Just some thoughts I wanted to share after following this thread.

I took all your response and have made sens out of everything that was advised. I now have a better understanding of the risks versus easy for users scenario. Thank you all.