Course11:Advanced - Public PBX Access

This book explains how to provide public access to PBX

Challenges

When it comes to public access to PBX services, there are two major challenges

• the services must be technically accessible in the given network setup.
  Here, most notably firewalls and NAT create problems
• the systems security level needs to be maintained.
  Although many attacks to IT systems origin from within the organizations, opening up access from the internet creates a whole lot of new issues

In this book, we will discuss how to address these issues. When we use the term "public access" it refers to clients accessing the PBX from anywhere including places in the internet (such as public hot spots) or from within foreign private networks.

Making it work

The first challenge is simply to make it work technically.

Let us first have a look at which PBX services we are actually talking of

• An endpoint (e.g. phone) will want to register with the PBX and place calls. So H.323 call signalling has to work
• During a call, media (voice, video, application sharing) needs to be exchanged. So (S)RTP has to work
• The endpoint will want to search phone books for name look-up and reverse calling number resolution. So LDAP(S) directory access to the PBX and/or a separate diretory service has to work
• The remote user may have a myPBX client running which requires HTTP(S) access to the PBX (and possibly the reporting service if it provides the call lists)
  

 Protocols used

When it comes to public access, we have to consider the routing schemes used in the network.

 Protocols used remotely

TCP based Protocols

TCP based services such as HTTP, LDAP, H.225 are connected through a well-known, that is, fixed port. HTTP(S) use TCP port 80/443, LDAP(S) 389/636 and H.225 1720/1300 by default.

To make such services work, the only thing that needs to be done is to create an in-bound NAT map in the local NAT router for the well known port that sends incoming packets to the right IP address in the customer network. Let us assume our PBX in the local network has IP address 172.31.31.132. For LDAP e.g. we would then create  NAT maps for TCP ports 389 and 636 to the same ports at 172.31.31.132.

Some care must be taken though if a single protocol is used for services on more than one machine. For example, if we use the reporting service to provide calls lists instead of the PBX-built-in CALL-LIST service, the external myPBX client will access both the PBX and the reporting service with HTTP. As we can not have 2 different mappings for the same protocol type (port) in our NAT router, we need to use a different, non-standard port for one of the two services externally. In our example, we could use port 80 to access the PBX and port 8000 to access the reporting service. This allows us to route incoming packets to the right machine by specifying two NAT maps on the NAT router (80->pbx-ip and 8000->reporting-ip). Note that internally, we still can use the same port on both machines (would specify a deviating target port (80) for the port 8000 map).

UDP based Protocols

With UDP based services, things are more difficult. UDP ports are usually dynamically chosen and thus not well-known in advance. A static NAT map cannot be employed thus.

Looking at our protocol  drawing again, we see that UDP is used by RTP and RAS. We use different approaches to fix both.

RAS and H.460.17

To fix the UDP NAT issues with RAS,  H.460.17 is implemented in the innovaphone devices. This standard defines how to tunnel RAS messages through an existing H.225 (thus TCP) connection. This can be done with unencrypted H.225 (known as protocol type H.323/TCP) or encrypted (known as protocol type H.323/TLS) connection. As far as routing is concerned, we get rid of RAS altogether if H.323/TCP or H.323/TLS is used.

However, neither H.323/TLS nor H.323/TCP is used by default. The default is using UDP based RAS (known as protocol type H.323). To get the benefit of tunnelled RAS, you need to set  H.323/TLS in the Protocol property of an endpoint.

This setting can also be deployed using the VoIP Protocol vendor option of the DHCP server (set it to H.323/TCP or  H.323/TLS). For a complete list of supported options see  IP4/ETH/DHCP-Server.

RTP and STUN/ICE

To fix the UDP NAT issues with RTP,  STUN/ICE is implemented in the innovaphone devices. This standard defines how to discover and communicate dynamic ports that are used behind NAT routers during RTP channel setup.

Routers will create dynamic NAT maps when an UDP packet is sent outbound. This is done so that an UDP response packet returning can be forward to the original source of the UDP packet.

With ICE the idea is to determine the properties (ports) of the NAT map the router creates beforehand, so it can be communicate to the peer (this is done within the signalling, so as part of the H.225 protocol in our case). For this determination, a STUN server is needed that is located (as seen from the endpoint) behind the router. This can be an external STUN server or the NAT router itself. The STUN server is  queried by an endpoint to learn the external IP address and port.

innovaphone devices have a built-in STUN server. If an innovaphone device is used as the NAT router (or if it is for any other reason located behind the NAT router as seen from the endpoint), it can be used as STUN server. This is done by  ticking the Enable STUN check-mark in the NAT settings (which also requires Enable NAT to be ticked, as the STUN server is part of the NAT module).

ICE actually does not only communicate the external NATed address and port. Instead, it communicates all possible address/port pairs. For example, if the endpoint supports both IPv4 and IPv6, both addresses are communicated. The address/port pairs sent are known as candidates. As part of the ICE handshake, all candidates are actually tried until a working one is found. This is why a phone, after a successful  ICE handshake, will use its local network IP address to communicate with another phone in the local network but will use the external IP address of the router to communicate with a peer in the internet.

ICE is used by default, so it does not need to be enabled explicitly. However, for ICE to work, a STUN server must be known to all endpoints. To get the benefit of ICE, you need to set a STUN server in the  IP4/General/STUN/STUN Servers or  Phone/User-x/General/Stun Server property of an endpoint (or - if the endpoint is a gateway, in the respective gateway configuration, e.g. Gateway/{Interfaces,SIP,GK}.

This setting can also be deployed using the STUN Server vendor option of the DHCP server (set it to the  IP address of your STUN server). For a complete list of supported options see  IP4/ETH/DHCP-Server. If your router is the STUN server, you need to specify its external address.

The MyPBX-launcher will use the STUN server configured for the currently selected phone for video and application-sharing media streams. WebRTC media streams will use the STUN server setting configured for the user's registration PBX (that is, those set in IP4/General/STUN or received by DHCP).

Multiple STUN Servers

It is possible to configure multiple STUN servers. The idea here is that all those servers are redundant, that is, they will return the same external address. All servers will be tried in parallel and the first one returning an answer will win.

If you use the ip-address[:port]] notation, you can specify 2 servers. If you use a single domain name, the DNS record may resolve to multiple IP addresses, which are executed in parallel. Multiple domain names are not supported.

myPBX Call List Service

The call list service used by myPBX (regardless if you use the PBX call list service or the reporting on a LAP) is called directly from the myPBX client via HTTP (for a detailed description see the Call List Services chapter in myPBX).

The client obtains this configuration from the PBX (in  PBX/Config/myPBX). Unfortunately, there is only one single configuration for all myPBX clients on this PBX. In a public PBX access scenario however, you would want your internal myPBX clients to use the internal address of the call list service, whereas your external clients should use the external address of your NAT router (the one that provides the NAT map as described in TCP based Protocols above).

This issue can be addressed by  using a DNS name as Host property for the Call List Service configuration, rather than an IP address. You would then specify different DNS entries for this name in your internal and external DNS.

Requirements

In order for STUN/ICE based communication to work, at least one of the two routers performing NAT in a conversation must support full-cone or restricted NAT.

 NAT Router Setup



In this scenario, if the Main Router supports full cone NAT, Phone A can talk to both Phone B and Phone C, as the Main Router supports full-cone NAT. However, for Phone B talk to Phone C, one of the Branch Routers must also support full-cone NAT.

To support any-to-any communication, all of the routers must support full-cone or restricted NAT thus. If this is an issue, media-relay can be enabled for all remote clients in the SB object (note though that this does not help for remote WebRTC endpoints).

For a method to determine if a router supports full-cone NAT, see  Concept Using PBX services from public internet.

Other NAT Types

If none of the involved routers support full cone NAT, it might still work.

Full-cone, restricted- and port-restricted will work in any combination. However, if one end does symmetric NAT it will work only if the other side does full-cone or restricted NAT.

Keeping it secure

PBX systems (like all IT systems) are threatened by both internal and external attackers. In a way, all security concerns even apply thus if your PBX is not connected to the internet at all. However, providing public access to your PBX of course takes ensuring security to the next level.

Make Security a Habit

Many successful attacks succeeded not because of inherent insecure design flaws of the attacked system, but due to careless configuration. Keep in mind that most attacks are automated. They will scan your entire system to find a hole they can exploit. Therefore, all of your configuration must be made with security in mind. Most of the configuration is not good enough.

Please read through the innovaphone Security Features carefully and exercise utmost accuracy when configuring a PBX that is connected to the internet.

For our topic here, please review the Access to VoIP in particular.

Use H.323/TLS

Whenever possible, avoid registrations with password. This is not because the password mechanism is insecure. It is because humans dealing with passwords are unreliable.

H.323/TLS provides authentication of registrations based on their device certificate. If the device certificate is trusted by the PBX and the CN in the Subject included in the certificate matches the registration name and the Subject is the Hardware-ID in a Devices entry in one of the PBX objects, the PBX will grant access.

 cert-check



Likewise, the endpoint (if it is an innovaphone device) will look at the certificate received from the PBX and check if it is trusted.

New and old-style Hardware IDs

V11 devices will use their plain MAC address (e.g. 009033010203) as default registration name. Older versions used a decorated form (e.g. IPxxx-01-02-03). V11 PBXs will recognize either style, both when locating the correct Devices entry and when validating the certificate.

Consider setting up a Frontend PBX

The H.323/TLS based registration method we discussed so far works and is secure. However, keep in mind that the map you configure in your NAT router creates sort of a tunnel attackers can use to access your PBX. This can be used by scanning- and brute-force-malware that tries to find and exploit a flaw in your configuration.

Any NAT map also creates a means to perform Denial of Service Attacks. Such attacks could for example flood your PBX with useless requests. They will of course be denied by the PBX, however, this can impact performance and stability of your PBX.

A frontend PBX is an additional box located in the DMZ.

 Frontend PBX



If you don't run a DMZ, a  simplified setup is possible.

A Frontend PBX is a PBX that has nothing but  Session Border objects. A session border object accepts remote registrations (like a plain User object would do) and in turn  registers to the real PBX on behalf of its accepted registration. All signalling messages are subsequently forwarded back and forth between the remote endpoint and the real PBX.

Using a Frontend PBX, you can configure your network so that H.323/TLS access to your real PBX is not possible (that is, you do not forward port 1300 on your NAT router). This limits any VoIP call fraud scanning attacks to the objects on the frontend PBX - which should be only a few and carefully configured ones.

Troubleshooting STUN and ICE

To troubleshoot STUN and ICE setting, you should  tick the H.323 ICE check-mark in Maintenance/Diagnostics/Tracing.

When you try a call then, the trace will show your the ICE candidates gathered with STUN:

 Good ICE Trace



 Bad ICE Trace