@BigChief wrote:
We're developing a WebRTC app for our Amazon-hosted FreePBX. The FreePBX Amazon instance can be pinged at it's internal IP (only from our LAN or VPN) or from the public IP (if we whitelist the user's IP beforehand in the Amazon ACL).
We have a lot of remote workers, so I'm weighing multiple options to secure their connection:
(a) Require all remote PCs to be on VPN, and have the app point to the Amazon PBX internal IP. This would work securely for all users regardless of where they are, but it'd be a lot of administrative overhead to handle all the VPN logins and train people how to connect.
(b) Have the app point to the Amazon Public IP of the FreePBX port instead (WebRTC uses port 8088). We've have to manually whitelist each home worker's IP, and they wouldn't be able to access the PBX when traveling since they'd have a different IP.
(c) Use the public IP, but open the 8088 port to the world. This lets all workers access the system from anywhere, and it should be secure as long as 8088 doesn't have any vulnerabilities and fail2ban is working correctly. But, it might be inviting for people to try to attack the port, and we'd still have to pay for the traffic and suffer and performance issues from being repeatedly poked or DDOSed.
(d) Use the public IP, open port 8088 to the world, but then secure it with Port Knocking and program the knock sequence into the click-to-call code. No idea how well this would work in practice or how difficult it would be to implement, but at least the port would be unresponsive to people scanning around.
Maybe there's a better method than any of these, but these are what I'm aware of so far. I'm also not sure if authentication is sent securely or in plaintext when connecting to WebRTC on the public IP. Anyone have suggestions?
Posts: 4
Participants: 2