Remote Connect Required Loosening of UCM Extension ACL Policy Security

#1

I just tried using RemoteConnect (Wave on iPhone via Remote Connect to UCM63xx) and have found that in order to allow remote phones to connect I have to remove the ACL Policy I have in place to restrict access to known IPs in the Extension.

When a device connected via RemoteConnect it is showing up as the actual public IP of the connecting device and NOT as a connection coming from GDMS.

This, IMHO, removes an important level of security that prevents rogue connections to UCM extensions.

@grandstream and @bvanmeter can this be addressed?

#2

Dear user,

Thank you for using the UCMRC services! When the user logs in the Wave iOS application with an extension in the UCM63xx through the UCMRC address, the UCM will display the device IP as public IP. We design it like this because if it displays the IP addresses of the UCMRC, all extensions registered by the Wave users in the same UCM device will show all same address in the UCM side. I have passed your concern to our UCM development team today. Could you kindly help to confirm if this is your request: If the user logs in the Wave application through UCMRC address, the IP address shown in the UCM should be displayed with the RC address? Thanks for your testing!

Thank you!

#3

@GSSupport74 thank you for your prompt response.

To clarify, my problem is not with the public IP of the RemoteConnect computer showing up, it is that I cannot use an Extension ACL to restrict the user to known locations (IP addresses) when using RemoteConnect unless that user has a static IP (which is virtually certain not to be there from a cell phone).

What I would like to see is a switch/setting that says only allow connections from these know IPs and optionally from RemoteConnect as applicable. That way I can limit UCM extension access to know networks and, if applicable, to Remote Connect users.

Under the current setup I have to open up to the world from an Extension ACL perspective if I want to use RemoteConnect.

I hope I clarified this. If not, let me know.

Again, thanks.

#4

+1 to this idea, nice security feature improvement at the PBX level. Although if NAT is not open it should be okay, but still good for hybrid environments or a failed firewall, good to be secured right at the source.

#5

Dear user,

Thank you for all your feedback! You can try to use “ACL Policy” option on the Web UI of the UCM:

Access Control List manages the IP addresses that can register to this extension.
Allow All: Any IP adddress can register to this extension.
Local Network: Only IP addresses in the configured network segments can register to this extension.

%E5%9B%BE%E7%89%87
图片.png806x167 8.43 KB

Let me know if you have any questions. Thanks!

Thank you!

#6

I have not used remote connect as of yet as I continue to view the overall program to be too immature and still not ready for prime time. There are simply too many forum posts regarding various issues and GS itself has yet to release any pricing or bring the product out of Beta.

If I am reading your post correctly, you are wanting to restrict the use of the remote connect at the UCM level to a given IP or possibly to the application itself as a security measure, but I do not understand your remark about having to open up to the world. How might the rogue devices get in?

It is my understanding that the purpose of remote connect is to provide “a companion cloud service for the UCM6300 series that provides always-on, automatic NAT firewall traversal to ensure secure connections by remote users”. This implies to me that the need to open a firewall to allow such “secure” connections is not needed and therefore makes the ACL issue moot as you should be able to leave the ACL open as “rogue” devices should not be able to get past the firewall.

All the conditions you mentioned involved the use of RC devices, and if the product eliminates the NAT concern, then it is not clear to me why the concern.

I am sure I must be missing something and as I indicated, I have yet to explore it.

#7

@GSSupport74.

Thank you for your response.

Can you please show me how to restrict access using this facility to just:

  • The Local Network Address (say 192.168.1.0/24)
    AND
  • Phones coming thru RemoteConnect

Since phones coming thru RemoteConnect are seen by the UCM as their public IP (which are not static and therefore cannot be pre-defined) I have been unable to get this to work.

Thanks.

#8

Firewall instead of ACL in extension.
ACL use sip IP, but firewall use real IP.

#9

@lpneblett I generally agree with your comments (as usual).

Here is my thinking. I always put my UCMs behind a firewall. And in some instances I even have the phone network on a separate physical or logical LAN. In theory that should minimize external devices from being able to attempt to connect to the UCM. However, never underestimating the user’s ability to shoot themselves in the foot by opening up/creating some backdoor, or the ability of a new hack to somehow negate what I have put in place, I always like to take advantage of free security mechanisms built into the technology I use. I look at the UCM’s ACL Policy as one such free security item. I hate losing any security, so hence this thread.

Just call me a belts and suspenders type of guy when it comes to security.

Hope that explains my thinking. If not, you know where to find me… :wink:

#10

But why not use both as I have in the past? I just want to extend this to the new paridyn.

#11

Because GS do not think about it yet :stuck_out_tongue:
ACL is local or all, no other option.

UCM have firewall so you can stop rogue there.

#12

Hi, David,

one thing escapes me, but if “your” remote extensions are on dynamic public IP, anyway you would not solve with ACL, as you would have to put a range of IPs, so you don’t restrict the problem, on the contrary you make it vulnerable.
With remote connect you need to know the Remote Connnect server (obviously not to be disclosed), user and pswd. So I don’t see the risk, moreover on UCM you can establish which ip pibblici can register for each extension, in case of dynamic public ip you would be at the starting point.

#13

Dear users,

Thank you for all your feedback! All your feedback have been sent to our UCM development team for evaluation, and I will update you once we have any conclusions. We will test this function in our own lab and share our suggestions to you. Thanks for all your testing!

Thank you!