Howto:Security works with innovaphone

From innovaphone-wiki

Revision as of 13:11, 12 July 2019 by Msc (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

Contents

Applies To

  • all innovaphone devices


More Information

Security issues in VoIP installations become more and more important to customers. While innovaphone very early has implemented a security framework based on the H.235 standard for H.323 supporting authentication and message integrity, the need for encryption to enforce privacy more and more emerges as a requirement.

This paper discusses the existing mechanisms in the version 6,7,8 and 9 release.

Risks

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

• Accountability

Availability

As all devices attached to a network, VoIP devices may be subject to attacks against the availability of their offered services.

Such so-called Denial of Service Attacks may be attempted using various strategies, including amongst others exploiting weaknesses of the implementation or legal but excessive use of offered resources.

Privacy

As with all communication systems, VoIP devices may be misused 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). Call fraud or so called brute force attacks are very common these days.

Integrity

The integrity of call signalling data as well as of the voice communication itself can be 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) etc. or silently changing a call destination may cause severe harm.

Security Features implemented in Version 6

innovaphone products today feature a number of security features.

This article provides a rundown of the essential features and how they are enabled.

Securing Configuration Data

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, erase the data before (see related articles below). Configuration data can be dumped to text format using the “Config show” command.

From version 5 on, 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

innovaphone devices are configured through a web based interface using HTTP or HTTPS access.

HTTP

For HTTP authentication, both basic authentication (which is not encrypted) 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 an option to enforce digest authentication in the “General Settings” (in other words, to disable basic authentication).

However, since the PBX’s SOAP interface is based on HTTP too, all SOAP clients not supporting digest authentication (and the TAPI driver currently is such a client) would be disabled using this option.

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 an option in the “General Settings” area.

By default, all HTTP clients can gain access to the device configuration provided they have the right password. However, there is an option to restrict HTTP access generally to a particular host or network. This option allows you to restrict all HTTP access (and thus administrative access too) e.g. to hosts from within your own LAN.

If remote configuration access is required though (which would be disabled by this setting), you may consider to setup an administrative PPTP (or PPP over ISDN) dial-in access to the device. Many innovaphone devices do support such kind of dial-in out of the box. 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 encryption layer.

Due to the computational overhead of HTTPS, HTTP payload traffic is not encrypted in innovaphone devices. If payload encryption is critical to you for administration access, make sure you configure an encrypted PPTP dial-in access for configuration as described above.

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. From build 04-5807 on, telnet access is disabled by default. Previous builds can disable telnet access by specifying “/port 0” on the TELNET0 config file line.

HTTPS

HTTPS is supported in the since Version 6 Service Release 2 (V6 SR2). RFC 2818 defines use of TLS (Transport Level Security, RFC 2246) to secure the HTTP protocol.

Managing Accounts

All administrative functions are secured by account names and passwords. It is strongly recommended neither to keep the default account nor the default password setting.

Access to VoIP resources

Access to VoIP resources (such as gatekeeper registrations and access to trunk lines) can be secured by account and password. If securing VoIP resources is an issue, make sure that all gatekeeper accounts are secured by a password. You may even want to consider disallowing any registration without password, even from within the local area network. This can be done in the “general settings” area of the PBX.

To protect your trunk lines from unintended access, make sure to configure all gateways (GWxx entries) properly. For gatekeeper type entries, make sure there is a password, for gateway type entries, make sure the configured netmask suits your needs. Double check all routing entries to avoid unintended access e.g. to trunk lines.

PPP and PPTP

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 variations 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 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 above).

RAS Registrations

H323 user account passwords are obviously sensitive information. innovaphone devices feature RAS RegistrationRequest (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 is provided by this mechanism.

H.225 Signalling

Based on the H.235 authentication (see above), 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.

RTP

RTP (i.e. media stream) traffic is not encrypted with Version 6. However, media stream endpoints are negotiated securely (see above), so that content spoofing is made difficult.

SIP message security

The current SIP implementation features mutual digest authentication and a reasonable protection against spoofed identities, there is currently no message digest signature available in SIP messages. The integrity of SIP messages thus is not ensured as is the integrity of H.225 and RAS messages (see above).

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 use the PBX user password for this. 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.

SNMP

SNMP is only for monitoring and does not allow any configuration changes. You may want to restrict the list of “accepted hosts” using the gateway applets SNMP area. You may want to change the “community” to a non-standard value.

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.

Denial of Service attacks

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 V6.

innovaphone ARP stacks will reject unexpected changes to the address mapping, and furthermore cease any traffic to the poisened mac address for 5 seconds. This feature needs to be enabled Reference7:Configuration/ETH/IP with Check ARP.

This way, an Arp spoofing attempt will be seen as service interruption by the end users, giving the network administrator a chance to investigate.

Availability

innovaphone devices have proved to be very robust and reliable. However, if availability is of utmost importance, redundancy options are available which allow for outstanding protection against loss of service.

Also, all innovaphone devices may be powered via power over Ethernet (PoE) which when combined with an uninterrupted power supply (UPS) ensure seamless operation even in the case of a local power failure.

PoE may be used concurrently with a local power supply.

Additional Security Features in Version 7

Although at present there are a number of security features implemented in innovaphone VoIP devices, there is still a lack of protection for the privacy of communications. This reflects the fact that previously, the source of attacks usually was expected to be outside of the own organization.

Such risks have been defended using sophisticated firewalls and VPN appliances on the own network border which provide for encryption and thus privacy protection. However, today’s security risks are more and more expected to emerge from within the organization.

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

The V7 introduces a number of features which help to defend against the risks of security attacks.

SRTP

Secure RTP is a security mechanism defined by 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 signaling data.

Only if both sites have activated encryption SRTP is used.

SRTP can not be forced.


innovaphone supports with Version 7:

  • AES-128
  • AES-192
  • AES-256

all with 32 or 80 bit SHA1 hashed message authentication codes (HMAC).

SRTP Interoperability

No interop problems are to be expected if other vendor device offers exactly one of the above crypto suites. Innovaphone equiment will always adapt to the offered crypto suite.

Problems will araise if other vendor device offers multiple crypto suites during call establishment. In this case all innovaphone devices must be configured to that crypto suite, which is offered at first position.

TLS

The TLS protocol obsoletes SSL and allows applications to communicate across a network in a way designed to prevent eavesdropping, tampering, and message forgery. TLS provides endpoint authentication and communications privacy over the Internet using cryptography.

Typically, only the server is authenticated (i.e., its identity is ensured) while the client remains unauthenticated; this means that the end user (whether an individual or an application, such as a Web browser) can be sure with whom they are communicating. The next level of security—in which both ends of the conversation are sure with whom they are communicating—is known as mutual authentication. Mutual authentication requires public key infrastructure (PKI) deployment to clients.

TLS is needed for

  • HTTPS
  • secure SIP (SIPS)

innovaphone supports TLS with the following methods:

  • RSA with 3DES
  • RSA with AES-128
  • RSA with AES-256

all with SHA1 hashes.

H.235

We currently use H.235v2 Annex D – Baseline Security Profile. It relies on symmetric techniques and provides authentication and/or message integrity based on shared secrets. H.235v3 Annex G – SRTP & MIKEY usage discusses a key management scheme suitable for use of SRTP (FRC 3711).

As SRTP does not specify a key management scheme by itself, the MSEC working group within the IETF discusses key management solutions and currently favours MIKEY. MIKEY defines AES as mandatory transport encryption enforces the use of X.509v3 certificates for public key encryption and digital signatures.

innovaphone implemented H.235 key Exchange for SRTP in Version 7.

SIPS

SIPS is SIP over TLS, which is mandated for proxies, redirect servers and registrars by RFC 3261. However, use of TLS requires a secure transport protocol, i.e. TCP.

The mechanisms supported are: TLS, HTTP Digest.

SIPS is supported since version 7.

Telnet

The secure shell protocol as per RFC 4251 can be used to apply content encryption to telnet sessions. We will not implement secure shell as we do not recommended to use Telnet at all, and telnet access is disabled by default.

LDAP

LDAP uses the SASL security as per RFC 2222. Unfortunately, this does not account for content encryption. LDAP v3 thus has defined extension for use of TLS with LDAP (in RFC 2830).

With Version 9 innovaphone will support LDAP via TLS

SNMP

SNMP versions 1 and 2 have been considered “insecure”. SNMP Version 3 includes considerably enhanced security mechanisms (as per RFC 3414). Unfortunately, this puts some difficult burden on SNMP implementations resulting in a rather little deployment compared to SNMP V2. There will be no SNMP security implementation on innovaphone side, as it is read only on the devices.

802.1X port security

Port security secures physical ports by enforcing a user authentication before allowing data transfer through a given Ethernet switch port. The endpoint needs to perform this authentication in order to be able to communicate.

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 802.1x feature on all products.

X.509 Certificates

Cryptographic 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 supports management functionality for both trusted CA certificates and device certificates / private keys.

We use X.509v3.

Additional Security Features in Version 8

Kerberos based Authentication

A single innovaphone device can act as an authentication server for all other innovaphone devices. User accounts that are managed on the authentication server can be used to login on each device in the installation. You can also configure devices to accept user accounts from a PBX (full admin rights) or a Windows domain.

IP Filter

Separate IP filter for log-ins with password and without password.

Additional Security Features in Version 9

Object Device

  • In case of registrations to a PBX using incorrect passwords, all other registrations to the relevant object are blocked for 20secs ( Security issues in PBX/Objects).
  • It is possible to define at the object (for each device ) that the admin password is needed to log in.
  • It is possible to delete all devices at an object and thus completely deny any registration.

HTTP Access Filter

Support for multiple networks in IP filter for the HTTP server (administration).

Unknown registrations

It is possible to use the admin password for unknown registrations (deployment of new endpoints).

Voicemail

The innovaphone voicemail supports SRTP via H.323 or SIPS.

LDAP via TLS

With version 9 innovaphone supports LDAP via TLS, for LDAP replication between master/slave/standby/standby-slave PBX.

Additional Security Features in Version 10

TLS

From v10sr8 certificates with SHA2 signatures are accepted. The new supported signature algorithms are SHA256, SHA384 and SHA512 with RSA encryption.

SIP Blacklist

Introduced in v10sr9. The SIP stack maintains an automated blacklist. When a REGISTER message is received for either a non-existing user or for an existing user but with a wrong password, the messages source IP address is put on a blacklist for at least 20s. SIP messages received from IP addresses in the blacklist are ignored.

Additional Security Features in Version 11

H.460.17

Endpoints can now register using H323/TLS. Device certificates can be used for authenticating registrations.

TLS

From version 11 TLS protocol version 1.1 and renegotiation (RFC 5746) is supported.

Support for certificates with SHA2 signatures (SHA224, SHA256, SHA384, SHA512).

DTLS-SRTP

Up to version 10 SDES was used for the exchange of SRTP keys between endpoints. This means the SRTP key is transported hop-to-hop inside signalling.

From version 11 DTLS-SRTP (RFC 5764) is available as an additional key exchange method. DTLS-SRTP uses end-to-end encryption and is done inband in the media stream. This means that the PBXes and proxies that forward signalling messages can not see the SRTP key. As a drawback, DTLS-SRTP adds a delay at the begin of calls.

Session border controller - SBC

The Session Border Controller provides the session border functionality, which is that a device can register to an session border object and the session border object establishes the registration to a configured PBX. This can be used when for example the device is located within the public internet and the PBX in a private network.

Additional Security Features in Version 12

TLS

From version 12r1 we support the following cipher suites. The DHE and ECDHE suites provide perfect forward secrecy.

  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA (new)
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA (new)
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (new)
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (new)

The following cipher suites have been deactivated and are no longer in use.

  • TLS_RSA_WITH_3DES_EDE_CBC_SHA (deactivated)

Additional Security Features in Version 13r1

TLS

Supported TLS versions:

  • TLS 1.0
  • TLS 1.1
  • TLS 1.2 (new)
  • DTLS 1.0
  • DTLS 1.2 (new)

Supported ciphers in version 13r1:

  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA256 (new)
  • TLS_RSA_WITH_AES_256_CBC_SHA256 (new)
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (new)
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (new)
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (new)
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (new)
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (DTLS only)
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (DTLS only)
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (new, DTLS only)
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (new, DTLS only)

TLS_RSA_WITH_3DES_EDE_CBC_SHA was finally removed and can't be activated in v13r1.

Additionaly we added the configuration of TLS profiles. They can be used to configure the selection and priority of used TLS versions and ciphers.

Cipher suite TLS (normal) TLS (fast) TLS (secure) DTLS
TLS_RSA_WITH_AES_128_CBC_SHA X
TLS_RSA_WITH_AES_256_CBC_SHA X
TLS_RSA_WITH_AES_128_CBC_SHA256 X
TLS_RSA_WITH_AES_256_CBC_SHA256 X
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA X X X
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA X X X
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 X X X
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 X X X

Random numbers

For creating private keys for certificates and certificate request, we now use the HMAC-DBRG random number generator based on HMAC-SHA512.

STARTTLS in SMTP client

The SMTP client in the firmware and on the app platform now implements STARTTLS for encrypted communication with mail servers.

Session Riding / "Cross-Site-Request-Forgery"

For safe administration, see Howto:Protection against "Cross-Site-Request-Forgery".

IP Phone USB Interfaces

Some of the innovaphone hardware phones feature a USB host interface which supports connection of USB headsets (a.k.a. audio and HID devices) and proprietary innovaphone extension modules. No other device types are supported or recognized.

Like all innovaphone devices, the phones run a proprietary operating system (think of it as the innovaphone OS). It has been written from the ground by innovaphone and is not based on any existing operating system such as Windows, Linux or VxWorks. As such, it does not allow execution of any code (e.g. drivers) derived from such systems. Also, the operating system does not allow execution of user code (that is, code that has been crafted by a user and is not integral part of the operating system). Execution of malware is not possible thus.

All headset drivers are entirely written by innovaphone too. No 3rd party code (such as vendor SDKs) are used.

From V12r1 SR14, you have the option to disable the USB port(s) altogether. Also, you can limit its use to audio or HID devices. See Reference12r1:Phone/Protect for details.

From V12r2 SR21, you can request informations about the connected USB Device via !mod cmd USB-HOST port

<info><port type="hub" port="1"/><port type="device" port="4" vendor="0xb0e" product="0x245d" release="0x118" product_name="Jabra Link 370"/></info>

In addition, a syslog entry is generated.

20190103-140636 USB-DEVICE plugged: vendor=1395 'Sennheiser' product=0051 'Sennheiser USB-ED CC 01' release=0603
20190103-140637 USB-DEVICE unplugged: vendor=1395 'Sennheiser' product=0051 'Sennheiser USB-ED CC 01' release=0603

Conclusion

Given the fact that today’s IT managers consider threats originating from inside the organisation as (at least) as critical as those originating externally, the only viable solution is a combination of media stream and signalling encryption performed directly by the endpoints.


Fortunately, both relevant signalling protocols in the PBX environment (H.323 and SIP) seem to converge as far as the media stream encryption (SRTP) and the key management are concerned. This should ensure end-to-end compatibility between SIP and H.323 endpoints. The necessary definitions for use of SRTP with H.323 are part of H.235-Annex G, for SIP it is SIPS - SIP via TCP and TLS. innovaphone has implemented SRTP according to H.235 Annex G as well as according to the SIP/SDP (SIPS/TLS) key management. The TLS is also used for HTTP, it requires an X.509 public key/certificate.infrastructure in place.


As the security of data transfer used for configuration is considered crucial, HTTPS is a mandatory requirement. This implies the existence of an X.509 certificate on each device. innovaphone devices entertain various http-based client connections to foreign http servers (e.g. for voice announcements, configuration provisioning). Since these connections are (at least) as critical as configuration sessions where the device acts as an http server, both proper http digest authentication and also TLS content encryption (https) is implemented by innovaphone.


The use of telnet to access innovaphone devices is deprecated and thus there is no need to address possible security issues related to the telnet access. As a “best practice” rule it is recommended to disable telnet access anyway (which in fact is the default configuration anyway).


While innovaphone devices do support SNMP, they do not allow any modification or retrieval of sensitive data using this mechanism. It is merely meant to facilitate maintaining devices health status. SNMP should be guarded against risk originating externally anyway (e.g. using firewall techniques). Risks originating from inside the organisation are considered less important. innovaphone will thus stay with the current SNMP v1 implementation.


innovaphone systems make extensive use of LDAP queries to synchronize distributed PBX systems. These communications obviously carry sensitive data (although from the very beginning there were no passwords conveyed in clear). innovaphone has implemented TLS for LDAP for inter-PBX communication. Securing LDAP access by clients (i.e. phones) to organisational directory services is considered less important as the conveyed data usually is not as critical. Also, existing directory servers may not support TLS for LDAP.


While 802.1X port security adds some extra barrier against certain types of internal risks, it also creates a number of open issues. Telephones usually are considered to work even if they are currently not authenticated by user. This may be mandatory for emergency calls for example. Use of port security would then mandate the storage of a fixed password within the non-volatile memory of an IP phone. Furthermore, the authentication of the second (PC) port needs to be performed with 802.1.x multiple authentications. innovaphone has implemented 802.1x on all of its devices.


As brute force attacks are very common these days, it is recommended to limit the ip subnets for configuration access (HTTP access filter). Configure that only registrations with password are allowed. For each object set a complex password or configure them with the admin password check-mark. Set the device field empty at the object when no registration should take place, thus nobody can register at all at this object. Deactivate "unknown registrations" or set them with admin password check-mark. From version 11r1 on, it is recommended to use H.323/TLS certificate based registration whenever possible.



Related Articles

Personal tools