who had used webphone in freePBX
-
@Dashrender said:
Sure, but I also didn't say to give it a public IP, I said that you'd need to expose it to the internet - which you do through a DMZ NAT Port setup as well as by giving a public IP.
sure i understand what you mean, i just get scared by the term exposing lol, i prefer using the term port forward for security reason
-
-
@scottalanmiller said:
@IT-ADMIN said:
port forward is more secure than exposing your entire PBX to the cloud
Very true
And also completely irrelevant. Because to make this work you are port forwarding the ports for a device to register to your PBX. This is a huge attack vector and not something you ever want to do without very solid IP restrictions IMO.
-
@IT-ADMIN said:
ozeki XE IP PBX
ok, I just read up on the Ozeki website.
This is a gimmick that I would never want setup.
Who in their right mind wants to allow anyone in the world to go to your webpage and then call any number they want?
You are wanting to pay for everyone to call whoever they want?
That is what you will be getting into with just a single configuration error.
-
@JaredBusch said:
@IT-ADMIN said:
ozeki XE IP PBX
ok, I just read up on the Ozeki website.
This is a gimmick that I would never want setup.
Who in their right mind wants to allow anyone in the world to go to your webpage and then call any number they want?
You are wanting to pay for everyone to call whoever they want?
That is what you will be getting into with just a single configuration error.
In his defense, I once had Xerox do basically the same thing with POTS lines. I ended up with a home phone with unlimited (ha ha, just one line) global calling, for free.
-
@JaredBusch said:
@scottalanmiller said:
@IT-ADMIN said:
port forward is more secure than exposing your entire PBX to the cloud
Very true
And also completely irrelevant. Because to make this work you are port forwarding the ports for a device to register to your PBX. This is a huge attack vector and not something you ever want to do without very solid IP restrictions IMO.
While I understand the thought process here, Have you seen successful attacks on this vector? Completely disabling this does limit some pretty cool options - like VOIPER on your phone acting like a PBX phone.
-
@Dashrender said:
While I understand the thought process here, Have you seen successful attacks on this vector? Completely disabling this does limit some pretty cool options - like VOIPER on your phone acting like a PBX phone.
Through forwarded ports? Yes.
-
@scottalanmiller said:
@Dashrender said:
While I understand the thought process here, Have you seen successful attacks on this vector? Completely disabling this does limit some pretty cool options - like VOIPER on your phone acting like a PBX phone.
Through forwarded ports? Yes.
Yes, through forwarded ports - I can think of nearly no reason to put something directly on the public internet.
Though - that brings up a question - how do you secure cloud services when you buy a server through them? Correct me if I'm wrong, you are pretty much stuck with only using the built-in software firewall on the server, right? Or paying some additional fee for them to NAT/firewall you, if that's even an option.
-
@Dashrender said:
Though - that brings up a question - how do you secure cloud services when you buy a server through them?
Cloud services are not yours to secure.
I assume that you mean "how do you secure a cloud computing instance of IaaS?"
-
@Dashrender said:
Though - that brings up a question - how do you secure cloud services when you buy a server through them? Correct me if I'm wrong, you are pretty much stuck with only using the built-in software firewall on the server, right? Or paying some additional fee for them to NAT/firewall you, if that's even an option.
Different topic IMO, but basically if it is SSH, then you disable password log in and require keys.
For other services, restrict to IP is possible. Finally, long passwords.
-
@Dashrender said:
Correct me if I'm wrong, you are pretty much stuck with only using the built-in software firewall on the server, right? Or paying some additional fee for them to NAT/firewall you, if that's even an option.
If you mean cloud IaaS like Amazon or Rackspace then.... you buy a firewall. With RS, as an example, you get both Cisco Firewall and F5 LoadBalancers to sit in front of your workloads if you want. Plus you typically would build your own application layer that sits in front of other workloads too.
-
@JaredBusch said:
You are wanting to pay for everyone to call whoever they want?
No, the webphone will be able to call only my internal extension (customer service agent's phone) not any number
-
in the HTML code you can remove the keypad and keep only one button (Call Us) kind of pilot number and then the call will be forwarded to all of our agents (set up a dial plan for incoming calls from the webphone to extension 401,402,403...)
-
Have you found a good third party web code option yet?
-
@scottalanmiller said:
Have you found a good third party web code option yet?
Not yet, but i found an option called webRTC in freePBX, it is not a webphone but similar in some sort
-
-
@IT-ADMIN said:
No, the webphone will be able to call only my internal extension (customer service agent's phone) not any number
I realize that. But as I said, it is only s single misconfiguration from an open system. Or even a single PHP/Perl/Javascript exploit away.
