Security best practices
The Pexip Infinity platform uses industry-standard encryption and security protocols to control access and to prevent unwanted audiences from listening in and stealing communications. It is also designed to comply with the strictest US Federal requirements.
This topic describes how you can help secure your Pexip Infinity deployment from network-based attacks and integrate Pexip Infinity into your existing network security architecture. For a full discussion of general best practices to prevent your videoconferencing deployment from being compromised, read this Pexip white paper.
Attacks on the operating system and management interfaces
Pexip Infinity uses a customized, cut-down version of Linux which has been designed to avoid exposing unnecessary network services and thus naturally limits the "attack surface" available to an attacker. Pexip regularly releases new software versions which incorporate the very latest operating system security patches (see Pexip security bulletins for more information). In addition, all Pexip Infinity APIs and management interfaces are password or PIN protected.
To mitigate attacks on the operating system and management interfaces:
- Disable the local management account and instead authenticate and authorize login accounts via a centrally managed Windows Active Directory / LDAP-accessible server. You can also limit what certain administrator groups can do (for example, support teams may not need the ability to deploy Conferencing Nodes). You can also configure client-certificate-based access if required. See Managing administrator access via LDAP for more information.
- Configure Global settings to define an administration session timeout and login banner text.
- Configure Global settings to disable access over SSH if it is not required.
- If you use Simple Network Management Protocol (SNMP), use SNMPv3 to both encrypt and authenticate incoming SNMP discovery and monitoring between the Management Node and the SNMP manager (see Monitoring via SNMP).
- Use secure NTP to obtain accurate system time (see Syncing with NTP servers).
- Use a firewall to prevent unauthorized network traffic from reaching your devices, and to block unauthorized access to services and network ports that are not required to be exposed for video communications to work correctly. For example, the management user interface HTTPS, SNMP and SSH services do not usually need to be accessible to anyone other than your network administrator. See Pexip Infinity port usage and firewall guidance for more information.
- Use secure remote logging via the industry-standard syslog protocol (see Using a syslog server).
- Use the latest release of Pexip Infinity software.
Pexip Infinity, as with many network services, can be vulnerable to Denial of Service (DOS) or a Distributed Denial of Service (DDOS) attacks. To mitigate such attacks:
- Use a firewall to block unauthorized access to services and network ports that are not required to be exposed for video communications (see Pexip Infinity port usage and firewall guidance).
- Disable unneeded services altogether. You can do this by configuring services and protocols via Global settings.
Eavesdropping and rogue calls
Pexip Infinity supports the latest industry standards for encryption for communication with end-user devices and employs IPsec security to provide strong protection of all inter-node communications (see Encryption methodologies). Inter-node traffic is restricted to only protocols that are expected; any unexpected traffic/protocols are dropped. Pexip Infinity also works with all popular video call control systems in the market today, and can connect legacy devices in the corporate network (which may not themselves support encryption) and encrypt on behalf of those devices when connecting to external devices that do support encryption.
Common attacks on videoconferencing systems include rogue calls — such as Spam Over Internet Telephony (SPIT) or toll fraud call attempts — that are targeted at an organization’s SIP (or, more rarely, H.323) infrastructure. Typically the attacker will place a large volume of calls to numeric aliases to try and gain access to a VoIP to PSTN gateway — and, if successful, use the gateway to commit toll fraud.
To mitigate eavesdropping and rogue calls:
Use proper TLS/SSL certificates from a respectable source on all Pexip Infinity nodes so that clients and other servers can verify that they have genuinely connected to the correct Pexip Infinity server and not an impostor or "man-in-the-middle" (see Managing TLS and trusted CA certificates). You can also:
- Use OCSP to check the status of certificates.
- If appropriate, enable SIP TLS verification / mutual authentication to require that peer certificates are verified. Typically, this is recommended for Microsoft Skype for Business and Lync integrations, but most other videoconferencing deployments are not equipped to provide a proper SIP TLS certificate so SIP TLS verification is not recommended unless you only expect calls from a closed circle of users.
Note that all Pexip Infinity nodes use HSTS (HTTP Strict Transport Security) to ensure greater security.
- Enable PIN protection on your Virtual Meeting Rooms:
- use a long (at least 6 digits), unique, randomly-generated PIN for each Virtual Meeting Room (you can automate this if you are Provisioning VMRs, devices and users from Active Directory via LDAP),
- use a trailing # at the end of each PIN to disguise the length,
- regularly change the PIN on each VMR.
- When using numeric aliases for your VMRs, make them at least 6 digits long.
- If you are using the Pexip Reverse Proxy and TURN Server, you should enable fail2ban on the reverse proxy.
- Ensure that PIN brute force resistance and VOIP scanner resistance are enabled, either globally or in specific locations.
When using the Infinity Gateway, consider:
- Limiting your Call Routing Rules applicability to only allow calls to be made from devices that are registered to Pexip Infinity, or are received in certain locations.
- Limiting calls to certain incoming protocols e.g. SIP only.
- Only allowing calls to be placed to devices that are registered to Pexip Infinity.
- Using precise regular expressions in your Call Routing Rules for the domains, dial plans and alias patterns that you want to support.
See Configuring Call Routing Rules for more information about routing calls via the Infinity Gateway service.
- Pexip Infinity disables SIP UDP by default (as SIP UDP is the most commonly targeted signaling service). However, consider disabling other unused protocols (see Enabling and disabling SIP, H.323, WebRTC and RTMP).
- Disable any other features that are not required in your deployment, such as the ability to make outbound calls, and support for the Connect app / API clients (see Global settings).
- Protect against toll fraud by ensuring that access to your VoIP gateway or your VoIP provider's SIP trunk and other important resources is carefully restricted – especially for unauthenticated external SIP/H.323 callers (see PSTN gateways and toll fraud).
- Implement a local policy script such as our example Reject specified User Agents script that rejects calls from known bad User Agents. This script will deflect the majority of "casual" scan attacks.
- Monitor the administrator log and use features of your firewall to block offenders.
Certifications and deploying in secure mode
Pexip Infinity holds the following certifications:
- ISO/IEC 27001:2013 certification
- GDPR (EU Regulation 2016/679) compliance
- U.S. Defense Information Systems Agency (DISA) Department of Defense Information Network (DoDIN) Approved Product List (APL)
- National Institutes of Standards & Technology (NIST) Federal Information Processing Standard (FIPS) 140-2 compliance
- Enables Health Insurance Portability and Accountability Act (HIPAA) compliancy
Deploying in secure mode
Full documentation of the configuration parameters used in the DoDIN APL certification are described in Deploying Pexip Infinity in a secure mode of operation. Note that this "secure deployment" guide is specifically structured around some of the guidelines required for APL certification, and therefore the need to disable some configuration and operational features are not necessarily required for other environments.