FreePBX on VPS
-
@aaronstuder said:
@fuznutz04 said:
What is everyone's method for provisioning phones remotely?
Do you have access to the phones before they are deployed? Do you have access to the network the phones will be on?
Yes, I would have access to phones before deployment, but not access to the destination network.
-
@fuznutz04 said:
Yes, I would have access to phones before deployment, but not access to the destination network.
Then pre-configure them - make sure you use a DNS name, not a IP address in case you want to move the server, etc.
-
@aaronstuder
Correct, that's the plan. However, when the phones check for configuration/provisioning periodically, while remote, what method do you use to secure the communication? You can use http, ftp, etc, but this is inherently not secure. This could be secured through firewall rules on the PBX, but this becomes difficult when dealing with people who travel with their phones.
-
@fuznutz04 said:
Correct, that's the plan. However, when the phones check for configuration/provisioning periodically, while remote, what method do you use to secure the communication? You can use http, ftp, etc, but this is inherently not secure. This could be secured through firewall rules on the PBX, but this becomes difficult when dealing with people who travel with their phones.
Most phones have OpenVPN built-in, that's a good option
-
@fuznutz04 What phones are you using?
-
I think you are trying to make it too complicated. All you need to work on the phone is the IP address of the phone (where ever it happens to be) and remote connection to a machine on that network (assuming that would be your employees laptop etc). Then you can reconfigure the phone easily. Even a basic user can hit the ok button a phone and get the IP address and read if off to you.
-
@Minion-Queen Then how to you connect the phone to the PBX securely? Most phones support HTTP, FTP and TFTP - none of which are secure. Also, you login and make manual changes every time you want to make a simple change on a phone? Sounds painful, and even more painful if you have more then a handful of phones....
-
@aaronstuder said:
@Minion-Queen Then how to you connect the phone to the PBX securely? Most phones support HTTP, FTP and TFTP - none of which are secure. Also, you login and make manual changes every time you want to make a simple change on a phone? Sounds painful, and even more painful if you have more then a handful of phones....
How much are you doing changes on a phone? 99% of everything that changes is done at the PBX level. The only time you should be touching a handset is to register it to the PBX.
-
@coliver That's a fair point, we are making a lot of changes right now due to just have installing the system. I could still see us making changes once everything couple of months. Having to change 60 phones by hand seems painful. Some features can't be controlled by the PBX such a softkey, etc. Still, the question remains, how do you do it securely?
-
This post is deleted! -
@aaronstuder said:
@Minion-Queen Then how to you connect the phone to the PBX securely? Most phones support HTTP, FTP and TFTP - none of which are secure. Also, you login and make manual changes every time you want to make a simple change on a phone? Sounds painful, and even more painful if you have more then a handful of phones....
If you are having to touch the phones hardly at all then you are doing it wrong.
-
@Minion-Queen Completely Agree. That still don't solve the security issue.
Transmitting a phone configure over the open internet without encryption is a bad idea.
-
@Minion-Queen HTTPS solves the encryption problem, but does not solve the authentication problem. None of the phones I have seem support using a username and password to authenticate over HTTPS. Some phones support encrypted conf files, that would work.
Need to know what phones @fuznutz04 is using, and they we can give them some options
-
@aaronstuder said:
@Minion-Queen HTTPS solves the encryption problem, but does not solve the authentication problem. None of the phones I have seem support using a username and password to connect. Some phones support encrypt conf files, that would work. Need to know what phones @fuznutz04 is using, and they we can give them some options
Are we talking about a username/password to configure the phone or to login with SIP?
Check out Yealink they require a username and password to connect. Snom does as well. I even had a conference room phone, can't remember the manufacturer, that requires a username and password.
-
@coliver to authenticate over HTTPS..... clearly SIP requires both for all phones.
-
We are using Grandstream and Yealink. Sip usernames and password are already taken care of with very strong passwords autogenerated from the system. The question is regarding security when checking for/downloading configuration files from the server. Since most phones are set to check for configuration changes every so often, a secure method to connect to the provisioning server should exist. I know some phones have OpenVPN connectivity options, but most have either FTP, or HTTP options.
-
@fuznutz04 OpenVPN seems like the only good way to secure the traffic end to end.
-
Why does it need to be secure? the PSTN you connect to for most calls isn't even remotely secure.
Also many phones support using SSL certs to connect to the PBX without a VPN. Pretty sure Yealink has ones that do. I think Grandstream can to. You can also use SFTP for config.
-
@Jason said:
Why does it need to be secure? the PSTN you connect to for most calls isn't even remotely secure.
This is why Scott claims that Faxing is less secure than email - but PSTN is not easily remotely hacked. A Chinese hacker in China can't easily hack my PSTN connection, nor my PSTN fax
So I'll disagree with the security purely from that perspective.
Also many phones support using SSL certs to connect to the PBX without a VPN. Pretty sure Yealink has ones that do. I think Grandstream can to. You can also use SFTP for config.
Technically the SSL is a VPN, but you're right in so much that you don't need something else standing up another tunnel to run through.
-
@Dashrender said:
Technically the SSL is a VPN, but you're right in so much that you don't need something else standing up another tunnel to run through.
No it's not. an encrypted transport yes, but it's not a VPN. A VPN doesn't even have to have encryption. It's just extended a private network over the WAN.
