Course11:Advanced - innovaphone Security Features

From innovaphone-wiki

Jump to: navigation, search
There are other versions of this article: Course11 (this version) | Course10 | Course12

Listing all the innovaphone Security features.



There are a number of security features implemented in innovaphone VoIP devices.

Risks (source of attacks outside of the own organisation) have been minimized using sophisticated firewalls and VPN appliances on the own network border which provide encryption and thus privacy protection. However, today’s security risks are also expected to emerge from within the organization.

The inability of contemporary local area network equipment to provide encryption, and thus privacy of communications, puts the burden on the application. VoIP applications as well as other data applications must provide end-to-end encryption.

This book will introduce a number of features which will help to defend against security attacks. The transport of voice data over standard based and open networks, results in a number of security threats against VoIP systems. Voice over IP applications are like all other data applications exposed to a number of security threats.

These threats can be categorized as follows

  • Availability
  • Privacy
  • Integrity
  • Authenticity

In this course we focus on securing the VoIP application. Securing the underlying network is another topic that must be addressed by the active network components like Routers, Switches and Firewalls.


The term Availability refers to the availability of the VoIP system, the offered services (like accounting) and the voice quality.

Like every device attached to an IP network, a VoIP device may be subject to attacks against the availability of their offered services. The so-called Denial of Service Attacks (DoS) have the goal of making several application services unavailable.


Like with every communication system, a VoIP devices may be attacked to disclose confidential information.

With telephone systems, this obviously involves unauthorized access to voice conversations. Moreover, access to configuration data (such as registration accounts, passwords and extension numbers) can be of interest to attackers as well as call data (such as time and source/destination of calls).

Authenticity & Integrity

The integrity of a VoIP system covers the operating system, accounting data, log data, configuration data.

The integrity of call signalling data as well as of the voice communication itself is also of utmost importance.

Spoofing of calling party ids for example may be used to obtain unaccounted access to particular resources (such as long distance calls or special services). But also more subtle and non-obvious tampering with call signalling data like faking cause codes (signalling busy when the party in fact does not respond) or silently changing a call destination may cause severe harm.

Securing Availability by Redundancy

innovaphone devices have proved to be very robust and reliable as they are based on a dedicated and proprietary operating system and hardware which is usually not a target for viruses and other malicious code.

However, if availability is of utmost importance, redundancy options should be considered:

  • Standby PBXs can be implemented which duplicate the function of a PBX and can take over the PBX functions when the original PBX fails. Please refer to the Basic Training Book PBX - Standby PBX
  • In a Master/Slave PBX scenario, the master PBX can act as a standby for the slave PBX or vice versa. See the Redundancy topic in this course for details. Both mechanisms can be combined, resulting in a double redundancy
  • Also, all innovaphone devices can operate using Power over Ethernet (PoE). When combined with an uninterrupted power supply (UPS) this ensures continued operation even in the case of a power failure. Also, PoE may be used in combination with a local power supply
  • innovaphone gateway platforms can provide fish-help.png Ethernet redundancy by using RSTP on both of the two Ethernet ports

Securing Configuration Data

One big issue when talking about security is to keep the configuration data secure.

All configurations for innovaphone devices are stored in local flash memory. While access to the data through normal interfaces is password protected, the content can potentially be examined if an attacker has physical access to the device (this would require disassembly of the device and examination of the flash EPROM). Whenever you pass a configured device to someone else (e.g. when selling it), you should keep this in mind. If this is a concern, fish-help.png erase the data before.

Configuration data can be dumped to text format using the “Config show” or "Save config" command. The resulting text file does not contain any clear-text passwords. Still, remaining configuration information may be considered sensitive. So be careful when providing this information to 3rd parties.

Because passwords are encrypted in the config file, you will need to remember the admin password of the device being dumped in order to load it to another device later on.

Securing Access to Configuration Data

As you know from the Basic training innovaphone devices are accessible through a web based interface using HTTP or HTTPS access.


To secure your VoIP installation it is recommended that you secure all access to the configuration data.

For HTTP authentication, both basic authentication as well as digest authentication is available. You should make sure the browser you are using supports digest authentication which allows for reasonable security against password snooping and man-in-the-middle attacks. There is the Disable HTTP basic authentication check-mark available in the fish-help.png Services/HTTP/Server tab to enforce digest authentication (in other words, to disable basic authentication).

innovaphone devices feature non-protected access to the devices home page. This is convenient; however, it may reveal some critical information to random port scanners targeting a device from the Internet. You may thus choose to password protect even the home page using the Password protect all HTTP pages check-mark in the fish-help.png Services/HTTP/Server tab. Please note: this fish-help.png flag used to be not compatible with the use of PBX users as administrators with limited rights (see chapter Managing accounts). This has been fixed in a later V9 version and V10 though.

By default, all HTTP clients can gain access to the device provided they use the right password. However, there is an option to restrict HTTP access to particular hosts or networks. This can be enabled by providing the list of allowed IP addresses/networks in the Allowed stations option of the fish-help.png Services/HTTP/Server tab. Be aware that this restrict all kind of HTTP access. So it will also affect things like WEBMEDIA, SOAP, CF card access, log, CDR and Event forwarding etc.

If remote configuration access is required though (which would be disabled by this setting), you may consider to setup an administrative fish-help.png PPTP (or PPP over ISDN) dial-in access to the device. All innovaphone gateways with ISDN interfaces do support such kind of dial-in. You would then use the assign remote IP address option and assign a local IP address to the dial-in client. This way, remote configuration is still possible and additionally secured by the PPTP authentication and encryption layer.

The HTTP server (and client) on the devices supports encrypted HTTP (HTTPS). You can force all HTTP access to the device to be HTTPS by setting the Force HTTPS check-mark in the the fish-help.png Services/HTTP/Server tab. Again, this will restrict all HTTP access, not only administrative access. If payload encryption is critical to you for administration access only, you may rather choose to configure an encrypted PPTP dial-in access. Force HTTPS will cause an HTTP redirect to the same URL with http:// replaced by https://. However, not all clients do support this. To enforce HTTPS access only, we thus recommend setting the HTTP port to 0 (and leave HTTPS-Port as 443) rather.


There is a legacy, telnet based access to the configuration layer. Telnet is inherently unsafe since it transfers unencrypted passwords. It is not recommended to use this. Telnet access is disabled by default. All admin accounts can have access via telnet. Viewer accounts do not have access, as well as Kerberos accounts. It is strictly discouraged to enable telnet access!


SOAP is based on HTTP, so all considerations regarding HTTP apply to SOAP too. Please note that many SOAP client implementations do not support digest authentication, so disabling basic authentication may prevent SOAP clients from functioning.


It is possible that a innovaphone device (e.g master PBX) can act as a Kerberos server and so all innovaphone devices can be managed via one Kerberos Admin password. More about that in the Kerberos Topic.

Access to VoIP

Password Protection

Access to VoIP resources can be secured by account and password. If securing VoIP resources is an issue, make sure that all PBX objects are secured by a password. PBX objects where you do not expect registrations on (e.g. Waiting Queue objects) should be disabled for registrations by removing all of their fish-help.png Devices entries. Also, if you do not expect that non-admin users configure a registration to the object, then you should set the Admin Pwd check-mark on the respective Devices entry. This disables registration using the objects configured password. Instead, registrations are possible only using the PBX password (as defined in fish-help.png PBX/Config/Security).

IP Filter

You may even want to consider disallowing any registration without password, even from within the local area network. This can be done in the fish-help.png PBX/Config/General tab by setting the No of Regs w/o Pwd. property to zero. However, it is often more convenient to allow at least one registration per object without password. To make sure that objects which unintentionally have a Devices entry that allows registration cannot be used to register with your PBX from remote, you can specify distinct sets of network/host addresses to allow registrations with and registrations without password from. This is done in the IP-Filter section of the fish-help.png PBX/Config/Filter tab.

These settings do not apply to objects on the gateway level. So to protect your system from abuse and call fraud, also make sure to configure all fish-help.png objects on the gateway level (GWxx entries) properly. For gatekeeper type entries, make sure there is a password, for gateway type entries, make sure the configured hosts/networks (as defined in the Address and Mask properties of the fish-help.png Gateway/GK page) suits your needs. Keep in mind that especially entries of type Gateway without registration and ENUM are dangerous, as they allow everyone to call in!

Double check all routing entries to avoid unintended access e.g. to trunk lines.

SOAP Client Account

SOAP clients (such as the TAPI driver or the Operator) require an account/password for authentication at the HTTP layer. Although the devices admin account can be used for that, it is better practice to create a dedicated PBX user object for SOAP access. For the HTTP credentials, you can use the PBX users Name as account and it’s Password as the password. You will use the Long Name as SOAP access user name.

When configuring the TAPI driver e.g., you would create a user with Long Name _TAPI_, Name tapi and a password. You would then use tapi/password as Gateway Platform Access Account/Password and _TAPI_ as PBX Access/Username in the TAPI configuration dialogue

Call Filter

Even if a VoIP endpoint has registered legally with your PBX, it does not mean that it is allowed to call any destination number.

In the PBX it is possible to define a number of fish-help.png call filters. These filters can be set for all types of objects in the PBX. They are useful to restrict an object from making calls to certain numbers (e.g. public numbers). So to be sure that there is no misuse, it is important to set these filters to all objects in the PBX.

Unknown Registrations

The fish-help.png Unknown Registrations feature of the PBX allows unknown endpoints to register with the PBX. Although this is very convenient for the deployment of new endpoints (usually IP phones), there is an obvious risk associated with it. To protect your system you should not enable this feature generally. Instead, you should enable it when new phones are being rolled out and disable it afterwards. If you think you should have the feature enabled all the time, at least tick the With Admin Pwd only check-mark.

Also, there is a pre-defined filter called unknown which applies to all such registrations. Make sure you configure this filter so that no abuse of resources (like calling out to the trunk line) is possible.

Call Duration

In many installations, limiting the maximum call duration is reasonable. This can be done by setting the Max Call Duration property in the fish-help.png PBX/Config/General tab. This setting might be helpful to limit call fraud.

Hide Account Information from Telephone Books

Knowing the name of an object is a first step to attack it. One way of getting to know the objects names is the phone book. So make it a habit to tick the resources' Hide from LDAP check-mark in all object definitions others don't need to see in their phone book. Even if you secure your LDAP with a secure password: nobody ensures you that the enemy you are fighting is not a user with a legal phone-book access!

Disable Registration with User Password

In V8 and before, users rarely had a need to use their own PBX account and password. Usually, their phone was somehow registered by the administrator and 'just worked'. Only those few users who used their PBX account to log-in to the PBX Web-UI even knew 'their' password.

From V9 however, users need to know their own password to log in to the web-based UC-client myPBX. This however implies that they are able to register multiple phones to the PBX using the password. If the user discloses the password (either maliciously or by accident), call fraud can be done using such registration.

There are 2 methods available to avoid this.

innovaphone Devices

From version V11r1 on, the PBX supports registration based on H.323 via TLS (a.k.a. H.460.17). H.323/TLS tunnels all registration requests (done using the RAS protocol) as well as all signalling through a single encrypted TLS TCP connection. This of course is a good thing in the first place, as all signalling now is encrypted.

However, there is another important benefit: using TLS (more precisely mutual TLS or MTLS), both the phone and the PBX can exchange their certificates. When an endpoint tries to register using H323/TLS and no password is sent, the PBX will look at the certificate it receives from the endpoint. If this is a trusted certificate and the CN property of the certificate matches the registration name sent along with the registration request, the PBX accepts the registration anyway. Likewise, the endpoint (if it is an innovaphone device) will look at the certificate received from the PBX and check if it is trusted.

screenshot.png Cerificate based Registration

This way, a secure registration is possible with no password at all.

To set up the PBX for best security, you would screenshot.png tick the TLS only check-mark for the Device entry in the PBX object. If this is done, the PBX accepts only certificate based registrations on the Device.

(Overall Description) If TLS-only is not enabled, the phone can still register by password without having a mutual trust-relationship between the PBX and the phone. The communication is still encrypted using TLS between each other.
Only by activating TLS-only at the PBX-object, you enforce that the Trust-List of both endpoints is checked and also the CN of the certificate is matched against the registration name.


Despite the title of this chapter, this method may work with 3rd party devices too, if they support H323/TLS.

As described above, the certificates presented by the registering client must be trusted. In practical terms this means that the PBX trusts all certificates in the client certificate's certificate chain. For innovaphone hardware phones, this is the case by default, as they all have a device certificate that is derived from (i.e. signed by) the innovaphone Device Certification Authority (C=DE, O=innovaphone, OU=innovaphone Device Certification Authority), which is part of the trust list by default.

However, if the registering client is a software phone (e.g. on Windows or Android), it has no trust-able certificate installed by default. In this case, you can create your own trust-able certificates or you may use the second alternative described below.

3rd Party Devices

If a device does not support H.323/TLS or has no trust-able certificate, another scheme can be applied.

If the screenshot.png PBX Pwd check-mark is ticked in the user object configuration's Devices list, no registrations using the users own password are possible for this Device entry. Instead, the PBX admin password must be used. The user's phone should register then using its serial number and the PBX password (as defined in fish-help.png PBX/Config/Security).

If a user needs hot-desking, you may consider creating an screenshot.png extra Devices entry without the PBX Pwd and TLS only check-mark set for this.

Although this fixes your allow-hotdesking issue, it also re-introduces the vulnerability we discuss in this chapter. To fix this, it is recommended to set the IP-Filter in fish-help.png PBX/Config/Filter to the most restrictive value. You can then tick the No IP Filter check-mark, to enable secure registrations from remote.

Disable Registration with Extension Number (E.164 Number)

The innovaphone PBX allows registrations with extension numbers.

For this to work
  • the PBX object must have a Number property set
  • there must be a Device entry where the Hardware-Id is identical to the objects Name property. When a new object is created, such Device entry is created by default

Unfortunately, when it comes to VoIP attacks, this bears some special risks. One popular form of VoIP attack is done by registration scanners. These are programs which try to register (usually SIP based) to arbitrary objects in your PBX and if they succeed, do malicious calls (to external destinations usually).

A scanning attacker needs to take two hurdles. He needs

  • to know the name or number of an object to register with
  • to know the correct credentials (i.e. password)

Guessing a name is difficult, however, guessing numbers is trivial. In fact, many scanner simply try all numbers from 1 to 9999. If one of these objects has no password defined, or has a trivial password that can be guessed with a few tries, the attacker is successful.

To avoid registrations with numbers, you may want to always remove the Device entry that corresponds to the Name property.


There are a number of encryption mechanisms on various levels built in to innovaphone devices.


When using built-in dial-in (PPP, PPTP) interfaces, PAP, CHAP, MS-CHAPv1 and MS-CHAPv2 are supported. PAP by design does not allow for password encryption and is thus not recommended. The CHAP variants do support password encryption using MD4 and DES and are therefore reasonably secure.

There is no payload encryption available for PPP (that is, PPP over ISDN) and PPPoE (i.e. xDSL). However, using ISDN dialup, payload encryption is not really an issue.

PPTP however features powerful payload encryption in addition to password encryption. It is using SHA-1 for session key encryption and RC4 up to 128bit for payload encryption. If payload encryption is an issue to you, you should check the enable encryption flag in the fish-help.png PPTP configuration. Keep in mind that payload encryption incurs computational overhead and the number of concurrent PPTP session the device can handle is reduced. Using PPTP is an option if fully payload encrypted configuration access is a requirement (see previous chapter).

Password encryption with H.235

H323 user account passwords are obviously sensitive information. innovaphone devices feature RAS Registration Request (RRQ) password encryption based on the H.235 standard (H.235v2 Annex D – Baseline Security Profile). By requiring knowledge of a shared secret on both ends, mutual authentication and message integrity is provided by this mechanism.

H.225 Signaling

Based on the H.235 authentication, H.225 signalling messages carry a signature which ensure message integrity in both directions. While message content may still be looked at and thus possibly sensitive information may be disclosed, this mechanism effectively disallows corruption of call, authentication and accounting data and renders man-in-the-middle attacks ineffective.


By using H.323/TLS (which is new in V11r1), the entire H.323 signalling is securely encrypted (recommended).


Secure RTP is a security mechanism for voice payload encryption defined by www.png RFC 3711. SRTP can be used for voice encryption with H.323 and SIP. SRTP encrypts the RTP stream with AES. As a result the key will be chosen randomly on both sites and sent with the signalling data. As SRTP does not specify a key management scheme by itself, innovaphone implements H.235 key Exchange for SRTP. In SIP, using SIPS provides a secure key exchange.

SRTP involves a noticeable computational overhead. This is why SRTP is used only if both sites have activated encryption. However, use of SRTP can not be forced in a way where calls fail unless they use SRTP. Innovaphone IP phones will indicate use of SRTP by showing a little lock symbol while an encrypted call is active. There is a check mark on every Interface and phone registration for enabling SRTP.

One interesting note is what happens to calls where an implicit instance of the webmedia interface is used, as there is no explicit interface configuration where you could enable/disable SRTP. These are for example calls to the PBX voicemail object, announcements played from a Waiting Queue object or music on hold. From V9 on, the voice mail supports SRTP (and there is in fact no way to inhibit this). Announcements and music on hold however do not support it. This is chosen deliberately so to reduce CPU load on the devices involved.

Since encrypting the RTP data results in more CPU load for the encrypting device, there are some new limits for innovaphone devices.

If your system needs to handle many concurrent calls, you should carefully consider if and where SRTP is needed. If need be, you can separate the gateway and PBX function in 2 physical boxes.

H.323 and SRTP

When using H.323 and SRTP it is recommended to configure a password on the User Object. The SRTP key is encrypted using the user password. If you don't use a password, the SRTP key is sent in plain text. As a result, the key can be "sniffed" on the network. Malicious software can then easily decode your encrypted voice payload data and thus listen to the call.

The better solution of course is to use H.323/TLS.


The SRTP key is exchanged via SIP in plain text, as described in the SIP standard. To protect the SRTP key exchange, you must use SIPS (SIP via TLS).

H.323 and SIP Interworking

SRTP itself is end-to-end, so a SRTP-capable H.323 device can have an encrypted call with a SRTP-capable SIP device. The PBX will interwork the SRTP key exchange.

Media Relay and SRTP

If Media Relay is used, each call consists of 2 SRTP calls. As SRTP is always a hop-to-hop encryption, the SRTP voice stream is terminated(decrypted & encrypted) by the gateway doing Media Relay.


SIPS (a.k.a. Secure SIP) is SIP over TLS. By encrypting the signalling information, attacks on the privacy and integrity of SIP messages are prevented.


SNMP is used only for monitoring and does not allow any configuration changes. You may want to restrict the list of fish-help.png Allowed networks to make sure only valid clients can retrieve SNMP information. You may also want to change the Community to a non-standard value. innovaphone uses SNMP version 1. Version 1 and 2 are generally considered “insecure”. There will be no SNMP security implementation on innovaphone side, as it is read only on the devices.

ISDN data calls

ISDN data calls are accepted by innovaphone devices as voice calls are and they are routed similarly. Although innovaphone devices may be configured to terminate a data call and thus access the local network via dial-in, this option must be explicitly enabled.


Like any other network device, innovaphone devices may be a target for a denial of service attack. It is therefore recommended, to protect against malicious access using standard firewall techniques. However, innovaphone devices feature a built-in DoS filter which will discard unreasonable inbound traffic. Also, it is based on a dedicated and proprietary operating system which is usually not a target for viruses and other malicious code.

ARP Spoofing

Tools performing VoIP privacy attacks have been made publicly available in order to tap in to VoIP conversations in a local area network. These attacks are based on spoofing layer 2 networks addresses to create a man-in-the-middle scenario where a conversation can be recorded without service interruption to the original participants.

Basically, the attack is based on the fact that the mapping between IP addresses and Layer2 (MAC) addresses is usually built on-the-fly using a protocol (ARP) that has no security built in. Attackers can change this association without notice and thus redirect any traffic to themselves. These kind of attacks have been addressed in the innovaphone software.

innovaphone ARP stacks will reject unexpected changes to the address mapping, and furthermore cease any traffic to the poisoned mac address for 5 seconds. So when in the local ARP table a MAC address/IP address allocation changes, then this entry will be poisoned for 5 seconds. As a result, the man-in-the-middle but also the "normal" user/receiver gets no data. This way, an ARP spoofing attempt will be seen as service interruption by the end users, giving the network administrator a chance to investigate.

To enable that feature fish-help.png Check ARP check-mark must be set. Keep in mind though that devices using Link Aggregation will not work properly resulting in problems when this check-mark is enabled.

802.1X port security

As VoIP telephones usually work as an Ethernet switch (featuring a second “PC port”) they would need to enforce port security on this second port too in order not to compromise the security setup. The switch implementation must support multiple authentications on one port.

innovaphone supports the fish-help.png Interfaces/ETH/802.1X 802.1x feature with user/password authentication on all products.

X.509 Certificates

Cryptographical certificates assign a public key to an identity. This is needed for the authentication of communication endpoints. The X.509 standard defines one commonly used format for such certificates.

innovaphone fish-help.png supports management functionality for both trusted CA certificates and device certificates / private keys.

When one innovaphone device needs to get access via HTTPS to another device, the certificate of this device needs to be configured as trusted, see fish-help.png General/Certificates. An example would be if a PBX needs access to a CF card (for announcements) and this CF card is in another innovaphone gateway or if phones need to register via SIPS to the PBX.


Make sure that every third party application connecting via H.323 or SIP has proper security implementation. For H.323, H.235 password security and SRTP. For SIP, connect via SIPS and SRTP.


innovaphone systems make extensive use of LDAP queries to synchronize distributed PBX systems. These communications obviously carry sensitive data. innovaphone implemented in v9 TLS for LDAP (LDAPS) for inter-PBX communication. Securing LDAP access by clients (i.e. phones) to the PBX phone-book or to directory servers is also possible by using LDAPS.

Additionally you can specify a fish-help.png Allowed Networks list of IP ranges to restrict access to the LDAP server of a PBX.

Managing accounts

One issue for security is the account management. This defines which accounts do exist and which permissions are granted to them on the 2 account levels available in the devices.

There are two rather independent levels:

  • fish-help.png General/Admin On the gateway layer you can create administrator accounts. There are 2 types access levels available. Administrator with full permissions or Viewer with read only permissions. The Viewer can see everything both at the gateway and at the PBX level, but cannot make any changes. Having multiple Administrator-type accounts is useful so that each individual administrator can have his own account and password. Also, individual accounts can be removed when the reason for the grant of rights has expired, e.g. if a support engineer needs to get access for a limited time frame.

  • fish-help.png PBX/Objects/Edit Rights Within the PBX, each user object can be elevated to an administrator type of account by granting rights to the user object. PBX-Administrators log on to the system with their PBX user login credentials and can administer the PBX - as far as their administration rights allow. The rights granularity is much better than in the gateway level and additionally the rights can be limited to certain nodes, sites or non-critical objects. Thanks to the multilevel administrator rights system, it is possible to differentiate rights between different log-ins. Each administrator group is granted only certain rights.
When Administration is checked in fish-help.png Maintenance/Diagnostics/Logging is enabled in the syslog, you can log all changes done by the various administrators.

It is important to understand that when a user logs in, all administrator accounts both in the gateway and in the PBX level are searched for an account-name/password match. The gateway level accounts are searched first. This implies that you must not have a PBX administrator account with same user name as an existing gateway level administrator account. As the gateway level account will always be searched first, the PBX account will never be used!

Please note: if you use the fish-help.png Password protect all HTTP pages feature, users with limited admin rights may have problems to log in. It is thus best not to use this flag if limited admin accounts are used. This has been fixed in later V9 and V10 builds.

Security Recipe (e.g. if your device is accessible from the Internet)

It should be obvious that a device which is directly connected to the Internet is at a high risk. There are numerous malicious tools available on the Internet which employ all kinds of attacks against VoIP devices. The best security measure against such attacks of course is to not expose your system to the Internet at all. So before you connect a telephony device to the internet, consider carefully if this is really required. If it is not strictly required, don't do it!

If you need to provide VoIP access to the Internet, you may consider to connect a gateway to the Internet and provide an ISDN link to your internal PBX.

If connecting your system to the Internet is mandatory, make yourself comfortable with all security features and security-related configuration options. Many successful attacks are caused by configuration problems which were created by an oversight during normal maintenance work.

In addition to the fish-help.png issues raised in the wiki, here is a check-list of issues to consider :
  • Never allow devices with the default admin user account or password in your network
    Many installations have a master PBX with a secure admin account, but other devices (phones or gateways, POTS adapters etc.) still have their default accounts. Consider using Kerberos to simplify your admin account management

  • Give individual accounts to individual users, especially admin users
    This will ensure that you can block specific users from accessing the devices by removing their account. Also, you can log administrative changes and identify the person who did it

  • Do not give rights to users which do not need them
    Create viewer accounts in the gateway level, assign only required rights to PBX users

  • Choose sensible password
    There are malicious tools out there in the wilderness of the Internet which perform brute force attacks against user names and passwords. They will find easy passwords!

  • Use most recent firmware
    After all, a VoIP device is like a computer: it runs non-trivial software and is a target for hackers. Innovaphone, like every vendor constantly puts efforts in identifying security issues and improves firmware. Staying on older firmware may expose you to a risk which has been eliminated in newer firmware

  • Limit general access to device
    Use the available mechanisms to restrict access both on the administration (HTTP) and the voice level (H.323/SIP) to hosts and networks from which you expect such access

  • Use the update server to do staging and to deploy configurations and firmware
    It is nice if you configure some of your devices correctly. However, to prevent fraud, all devices need to be configured correctly always

  • Do not create PBX objects you don't need
    Often, objects are used to register with which were simply left in the configuration although they are not needed any more. It is difficult to keep track of things if your PBX configuration looks like a rubbish dump

  • Remove all Devices entries in an object if you do not expect someone to register with this object
    This typically applies to objects such as Waiting Queue objects which allow registration although it is normally not used. Removing all Devices entries disables registration

  • Do not use Unknown Registrations after deployment is done
    While this feature comes in handy during deployment, it is an obvious security risk thereafter

  • Configure PBX call filters and apply them to all objects
    One very popular attack these days is an attempt of call fraud. A malicious tool tries to create calls to arbitrary numbers (either by cracking an objects password and registering with it or by using unregistered access). The call destinations usually are foreign countries or - even worse - expensive service numbers you will then pay for

  • Set No of Regs w/o Pwd. to 0
    Allowing the first registration without a password is dangerous as it allows attackers to register with your PBX using objects which are currently not in use

  • Make sure your PBX type objects always have a password
    Distributed PBXs work great without password for the PBX objects. However, call fraud attacks do too. The attacker simply can register masqueraded as a PBX

  • Make sure your Trunk objects all have the Loopback property set
    Otherwise, external callers can call back to the PSTN - and you pay for it

  • Inspect your gateway routing tables carefully
    So you make sure calls to your trunk lines originate only from where you expect them to originate

  • Do not use objects which allow calls without registration
    This applies to gateway entries of type Gateway without registration, ENUM and Federation. It won't take long until one of the malicious port scanners in the internet have found these interfaces! So don't use them if not really required

  • Double-check routes on ENUM and Gateway without Registration interfaces
    As mentioned above, such interfaces allow anyone to create calls in your device. If this is what you want (e.g. to allow incoming ENUM traffic), make sure you disallow any unwanted call in the routing table (e.g. disallow calls which would be routed to your trunk lines)

  • Turn off unauthenticated access to the devices home page
    Many port scanning programs try to find the address of a VoIP device to attack by analysing the home page retrieved from an IP address. They have heuristic algorithms to determine from the information presented there if this is a VoIP device worth an attack. Disallowing access to the devices home page may thus fool such tools

  • Do not allow access to trunk lines on Waiting Queue objects
    When you provide a Waiting Queue object with dial-through, make sure users can only call to objects you want them to. You will most likely make sure that they can not call to your trunk line

  • Do not allow unauthenticated access to the CF card
    While allowing everyone to read or even to read/write on a CF card is a very convenient configuration, it is dangerous at the same time. So rather configure proper credentials on the requesting devices

  • Make sure Enable RPCAP is off if you don't need it
    RPCAP is by design unauthenticated. So make sure attackers cannot access it

  • Protect your user and extensions data
    Allow access to the LDAP - Server of the PBX only for devices in your network by configuring a list of fish-help.png Allowed Networks. Also hide all objects from the phone book users don't need to know of generally!

  • Block unwanted SNMP access
    Be sure to change the default Community in the fish-help.png Services/SNMP - even if you do not use SNMP yourself. Attackers might do it. Also, if you are using SNMP yourself, tick the Authentification Trap check-mark so you get noticed when an SNMP-based attack is attempted

  • Never enable telnet
    Telnet sends passwords in clear. Don't use it ever

  • Always have an eye on Events and Logs
    In order to keep track of the events and logs from all your devices, fish-help.png forward all events, alarms and logs to a central point
  • Use H.323/TLS whenever possible
    See Disable Registration with User Password above
Of course, there are further tools available to secure your devices exposed to the internet. Firewalls are one of them and you should consider using one. However, this is not within the scope of this book.

Please note also, that most if not all of these hints do make sense too in an installation which is not connected to the Internet. After all, attacks may origin from within your organisation as well.

More Information

You can find an up-to-date list of implemented security features in fish-help.png Security works with innovaphone.

Please also have a look at the topic Public PBX Access, most notably the book on Public PBX Access.
Personal tools