Contents
Security Considerations
Genesys is committed to offering products and solutions with a high level of security. Opening a real-time communication channel on the web requires secure transmission, and the Genesys WebRTC Service does not compromise the security level of the enterprise network. The following topics discuss the issues that you may wish to take into account when deploying the Genesys WebRTC Service, depending on your enterprise network architecture.
Secure Transports
With WebRTC, the browser is initiating both an HTTP connection and a media session that connects it with another WebRTC peer. Since the description of the media session is signaled over HTTP, this can be protected with the use of HTTPS, which is not enabled by default, however. If an HTTP proxy and/or a load balancer (LB) that are deployed in the same network are used, then HTTPS may not be needed between the proxy/LB and the gateway.
The media session is secured through the use of Secure Real-time Transport (SRTP), meaning all media are encrypted before being sent over the wire. The security keys for encrypting the media are exchanged in a secure manner through either the signal path (SDP security descriptions) or the media path itself (DTLS). The Genesys WebRTC Service enables DTLS-SRTP by default to ensure that all media paths with the browser are secure. Note that DTLS-SRTP is mandated by the WebRTC standard for media.
Please see Platform Configuration section on how to configure these options.
Securing the Host
The best practice for securing a host that is deployed on the web is to place the host behind a firewall. The Genesys WebRTC Service requires the firewall to open up the HTTPS port for inbound traffic with the browser, and a range of SRTP ports for inbound and outbound traffic with the TURN server (or directly with the browser, if that is acceptable, and TURN server is not to be used).
The WebRTC Service also needs to establish SIP calls to Genesys SIP Server. Genesys SIP Server and agent endpoints are typically deployed within the enterprise firewall, so in this case, the WebRTC Service only needs to access the SIP port and a range of RTP ports on the enterprise network.
The WebRTC Service also connects to the Genesys Management Framework, which is deployed within the enterprise network. This means that the Service requires access to Local Control Agent and Configuration Server.
Other ports may be allowed by the firewall for other administration purposes. It is recommended that they only be accessible either from within the enterprise network or through a secure communication channel from the Internet, such as ssh.
Please refer to Ports and Protocols for information on the port usage.
Security for the Web Application
The user does not directly access the WebRTC Service to place calls, as it is the responsibility of the web application to deliver a user interface to the browser for the user. The WebRTC Service includes a JavaScript API that provides a set of HTTP API methods by means of which the web application can access the WebRTC Service separately from the web server that hosts the web application.
Cross Origin Resource Sharing (CORS)
Since the browser Same Origin Policy prevents a web page from making an XMLHttpRequest to another domain, the WebRTC Service supports Cross Origin Resource Sharing (CORS) to allow the web application to interact with the WebRTC Service across domains.
For a simple request—one that uses either GET or POST and whose body is text/plain—the request is sent with an extra header called Origin. The Origin header contains the origin URI (scheme, domain name or address, and port, as per RFC 6454) of the requesting page so that the server can easily determine whether or not it should serve a response. An example Origin header might look like this:
Origin: http://www.genesys.com:8080
The WebRTC Service provides a configuration option (domain-whitelist) to specify the allowed list of domains, and any CORS request specifying an Origin that is not allowed will result in an error. However, if the list of allowed domains is set to empty, the WebRTC Service then allows interactions with all sites with CORS by setting the Access-Control-Allow-Origin HTTP header in the response to the value specified in the Origin header value from the original request.
If the server decides that the request should be allowed, it either sends an Access-Control-Allow-Origin header echoing back the same origin that was sent or '*' if it is a public resource.
For example:
Access-Control-Allow-Origin: http://www.genesys.com:8080
If this header is missing, or the value of this header does not match the value of Origin header, then the browser disallows the request. If all is well, then the browser processes the response.
Tools and Services
Fail2ban
To block IP addresses that repeatedly have failed login attempts, Genesys recommends installing and using Fail2ban on Linux hosts.
The Fail2ban RPMs are available through EPEL repository, which may need to be set up first. You can then install Fail2ban using YUM:
sudo yum –y install fail2banThe default install will ban IP addresses after three failed attempts for 600 seconds.
Telnet and FTP
Telnet and FTP services have known security issues. Genesys recommends disabling these services on the hosts.
Xinetd
Genesys recommends disabling Xinetd on Linux by running the following command:
sudo chkconfig xinetd off