Polycom's RealPresence Access Director (RPAD) is a scalable and secure firewall traversal solution that enables seamless video collaboration across business-to-business and intra-company networks for H.323 and SIP devices, including SVC solutions.
However, sometimes, some RPAD installations are left in a less than secure configuration. What are the best practice configurations to help? Obviously, change the default passwords. Additionaly, in most cases, it should prevent remote, unathenticated guest users from registering their video device to your system. Finaly, some organizations have business rules to only permit inbound calls to virtual meeting rooms (VMRs).
Warning, This does change how your RPAD handles calls. Misconfigurations can adversly affect external calling. As always, best practices are to implement these changes after taking a backup, off hours, and under the appropriate change controls for your organization. If you are unsure of the reasons behind implementing these settings, or why they are important, please contact your Polycom Partner or Polycom support team for more assistance.
These instructions will:
1) Prevent remote guest users from registering as an unathenticated internal user on your RPAD (via SIP or H.323)
2) Restrict guest users from directly dialing any individual endpoint and only permit them to meet your conference bridge.
1) To prevent remote guests from registering through the RPAD. We need at least 3 rules created to protect against unwanted guest registrations. You can add more depending on your business requirements, but these 3 should be basic to every install.
On the RPAD, go to Configuration > Access Control List Settings
The above is the end result of what we should be working towards. Now for the rule creation. The RPAD contains default rules which we will use. Of course your external signaling IP address will be different from those in the below images.
H323
Click Add under Actions
Service Name: H323
IP: External signaling IP
Port: H225 RAS port: 1719
Select Add
Choose Access_Without_XMA_Provision and Action set to deny
Select OK x 2
SIP 5060 (Guests)
Click Add under Actions
Service Name: SIP
IP: External signaling IP
Port: SIP External Port 5060
Select Add
Choose SIP_Registration and Action set to deny
Select OK x 2
SIP 5061 (Internal Authenticated Users)
Click Add under Actions
Service Name: SIP
IP: External signaling IP
Port: SIP External Port 5061
Select Add
Choose Access_Without_XMA_Provision and Action set to deny
Select OK x 2
Now try to register using RealPresence Desktop (or another Polycom endpoint) from outside the firewall on both H323 and Sip as a guest (without credentials). You should see the following (screen shot from RealPresence Desktop Client):
Congratulations, you've now helped secure your RPAD.
2) Additionally, you might have a business requirement to only allow incoming calls from guest users to meet on a bridge inside a virtual meeting room (VMR). In the the world, this is equivalent to saying nobody outside your organization can your direct number -- they have to meet you in a bridge.
How to implement a H323 guest policy with a RPAD and DMA. In version 2.1+ of the RPAD, you now have access to a H323 Guest Policy setting.
Configuration > SIP and H323 Settings
The above setting will add a prefix of 88 to the dial string of any H323 call coming into the RPAD. However, the DMA does not yet support this feature like it does for the SIP guest user. If a call comes into the DMA in this fashion, the DMA will reject the call as unreachable. Therefore there needs to be an additional dial rule created on the DMA.
Admin>Call Server>Dial Rules
Edit the default Dial by Conference room ID dial rule and added the following preliminary script:
DIAL_STRING = DIAL_STRING.replace(/^88/,””);
Ensure that the dial rule is still enabled when done.
Obviously if the deployment has VMRs that start with 88, then the prefix should be changed to use some other digits. As long as the RPAD prefix and the DMA dial rule are the same and don't overlap the existing dial plan, they can be anything. I know of one environment where they use 880000 to ensure uniqueness.
Congratulations, you've now restricted unauthenticated guest calls to only join a VMR.
For more information, see the individual product admin guides or the solution guide on support.polycom.com or join the Polycom communties and post your question in the Management, Securirty and Rich Media forum. Also, see www.polycom.com/security for up to date security information.
Thanks to Simon Smith and Barry Phearson for their original work on the underlying messages that became this blog post.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Featured Authors
|