4 Deploying WebRTC Session Controller in a Demilitarized Zone

This chapter explains how to deploy Oracle Communications WebRTC Session Controller in an semi-secured environment. This chapter refers to this type of deployment as a demilitarized zone (DMZ) deployment.

Overview and Recommended Configurations

A WebRTC Session Controller DMZ deployment should include multiple networks configured for access on separate networks cards. Access points on each host shield back-end systems such as administration servers, media servers, and the Session Initiation Protocol (SIP) core from DMZ/Internet traffic. In particular, consider hosting WebRTC Session Controller administration servers on a separate network to isolate administration traffic from application traffic.

If your WebRTC Session Controller installation must be deployed in the DMZ, Oracle recommends that you use one of the multi-tier WebRTC Session Controller implementations shown in Figure 4-1, or Figure 4-2 to protect its components. These implementations take advantage of technologies that WebRTC Session Controller uses to protect itself:

• A design that incorporates network layer access control so you can give individual WebRTC Session Controller components the level of protection they require. This modular design enables you to restrict access to WebRTC Session Controller from the Internet using firewalls, and restrict access within WebRTC Session Controller using WebLogic connection filters.

• The ability to require Secure Sockets Layer (SSL) communication between WebRTC Session Controller components.

• Using operating system hardening to protect specific sensitive files and programs.

Note:

Figure 4-1 and Figure 4-2 are only intended to show a high level overview of possible WebRTC Session Controller networking configurations.

For explicit routing details, see the following sections:

• Securing Traffic Between the Internet and WebRTC Session Controller

• Securing Traffic between the WebRTC Session Controller and the SIP Core

Figure 4-1 shows the most exposed WebRTC Session Controller components, the WebRTC clients, outside firewall protection in the Internet, with the traffic being filtered by a firewall before being passed through to WebRTC Session Controller. The WebRTC Session Controller Signaling Engine (SE) and Media Engine (ME) instances are deployed in the DMZ behind a firewall as well as a suitable load balancing device for the SE instances.

Note:

To provide an additional layer of security, the SE administration server can be a separate server deployed behind an additional firewall on its own separate VLAN (not pictured). Traffic to the SE administration server endpoint (default port 7001/7002) should be disallowed from the Internet.

Suitable load balancing devices include the Apache Software Foundation HTTP web server using mod_wl, the F5 Networks 5 load balancer, or the Oracle HTTP Web Server using mod_wl_ohs. Oracle recommends that you obtain and install a component with proxy capability to limit traffic between the firewall WebRTC Session Controller as well.

The SIP core itself sits behind a firewall on yet another separate VLAN and traffic from WebRTC Session Controller is routed through a SIP-aware load balancer.

Note:

The load balancer serving the SE instances, if SIP-aware, can also be used to balance traffic to the SIP core.

See "Securing WebRTC Session Controller Components in the DMZ" for the list of tasks required to implement this deployment.

Figure 4-1 WebRTC Session Controller DMZ Deployment

Figure 4-2 shows a WebRTC Session Controller DMZ deployment with an additional firewall separating customer systems such as database servers, media servers, and others. In this deployment, the customer systems are on a separate private VLAN behind a firewall which can only connect to WebRTC Session Controller.

Note:

For an additional layer of protection, you can use a VPN tunnel as an access gateway to the customer systems as well (not pictured).

Figure 4-2 WebRTC Session Controller Interfaced with Customer Systems

WebRTC Session Controller Network Sources, Destinations, Protocols, and Ports Reference

Table 4-1 lists the various sources, destinations, protocols and ports which may be used in a WebRTC Session Controller DMZ deployment.

Note:

Not all of these source/destination combinations and devices are described in the diagrams and descriptions used in this chapter.

Table 4-1 SE and ME Ports, Source, Destination, and Protocols

Source	Destination	Level 4 Protocol	Level 5-7 Protocol	Default Dest. Ports
Internet Browsers	SE Access IP	TCP	HTTP(S): HTML, JavaScript, WebSockets	7001 for HTTP, and 7002 and/or 443 for HTTPS/WSS
Internet Browsers	ME Access IP	UDP	STUNFoot 1 /TURNFoot 2 , DTLSFoot 3 -SRT[C]PFoot 4	3478 for STUN/TURN over UDP; Configurable range for DTLS-SRT[C]P media, for example, 20000 to 25000Foot 5
Internet Browsers	ME Access IP	TCP	TURN	3478 for plain TCP, 5349 for TLS
SE Core IP	SBCFoot 6  Signaling IP	UDP and TCP	SIP	5060, 5061
Signaling Core IP	SE Core IP	UDP and TCP	SIP	5060, 5061
SE Management Nodes	SE Management IP	TCP	HTTP(S), SSH	7000/7001, 22
ME Management Nodes	ME Management IP	TCP	HTTP(S), SSH	80/443, 22
SE Internal IP	ME Internal IP	TCP	SOAP/HTTP Load Factor	8080
ME Internal IP	SE Internal IP	TCP	SOAP/HTTP Event Callbacks	4057
ME Access IP	Internet Browsers	UDP	STUN, DTLS-SRT[C]P	3478 for STUN over UDP, Configurable range for DTLS-SRT[C]P media, for example, 20000 to 25000
ME Core IP	SBC Media IP	UDP	RTP, RTCP	Configurable range, for example, 20000 to 25000
SBC Media IP	ME Core IP	UDP	RTP, RTCP	Configurable range, for example, 20000 to 25000

^Footnote 1 Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators (NATs)

^Footnote 2 Traversal Using Relays around NAT

^Footnote 3 Datagram Transport Layer Security

^Footnote 4 The Secure Real-time Transport Protocol

^Footnote 5 The number of media ports to open, in this case, the default 5000, depends upon your requirements for the number of concurrent media sessions.

^Footnote 6 Session Border Controller

Securing WebRTC Session Controller Components in the DMZ

Complete these tasks to implement a DMZ deployment as shown in Figure 4-1:

• Securing Traffic Between the Internet and WebRTC Session Controller

• Securing Traffic between the WebRTC Session Controller and the SIP Core

Complete all of the tasks in this section and add a firewall and optional VPN between your customer systems and the WebRTC Session Controller to implement a DMZ deployment as shown in Figure 4-2.

Securing Traffic Between the Internet and WebRTC Session Controller

You secure traffic between the Internet and WebRTC Session Controller by:

• Configuring a firewall between WebRTC Session Controller and the Internet. See "Configure a Firewall to Protect WebRTC Session Controller" for details.

• Configuring WebRTC Session Controller ME specific security measures. See "ME Specific Security Tasks" for details.

• Hardening the underlying operating system components for all SE and ME engines. See "General Hardening Instructions for SE and ME Installations" for details.

• Make sure all of your SE and ME instances are fully patched.

• Optionally, for SE engines, configuring connection filters. See "Configuring Connection Filters for SE Components Instead of a Firewall" for details.

The following sections provides details.

Configure a Firewall to Protect WebRTC Session Controller

Configure a firewall as described in Table 4-2. This example uses the sample components and IP addresses/ports shown in Figure 4-1.

Note:

The IP addresses and ports in Table 4-2 are only examples. Yours will be different.

Table 4-2 Configuring a Firewall Between the Internet and WebRTC Session Controller Access Tiers

Specifically Allow Traffic From:	To The Component/IP Address:Port	Notes
WebRTC Clients	Signaling Engine 1 (192.168.10.1:7002)	Allow WebRTC API traffic to SE 1 via a load balancer.
WebRTC Clients	Signaling Engine 2 (192.168.10.2:8002)	Allow WebRTC API traffic to SE 2 via a load balancer.
WebRTC Clients	Media Engine 1 (192.168.10.3:20000-25000)	Allow WebRTC API traffic (DTLS-SRT[C]P) to ME 1 with the appropriate number of media ports open for your requirements, in this case 20000 to 25000.Foot 1
WebRTC Clients	Media Engine 2 (192.168.10.4:20000-25000)	Allow WebRTC API traffic (DTLS-SRT[C]P) to ME 2 with the appropriate number of media ports open for your requirements, in this case 20000 to 25000.
WebRTC Clients	Media Engine 1 and 2 (192.168.10.3:3478/5349, and 192.168.10.4:3478/5349)	Allow WebRTC API traffic to ME using TURN with ME acting as a TURN server. These ports are not in the diagram.
Signaling Engine 1 and 2	Media Engine 1 and 2 (192.168.10.5:8080, and 192.168.10.6:8080)	SOAP and the HTTP load factor application. These IP addresses are not in the diagram.
Media Engine 1 and 2	Signaling Engine 1 and 2 (192.168.10.7:4057, and 192.168.10.8:4057)	SOAP and HTTP event callbacks. These IP addresses are not in the diagram.

^Footnote 1 The number of media ports to open, in this case, the default 5000, depends upon your requirements for the number of concurrent media sessions.

Figure 4-3 illustrates the configuration in Table 4-2.

Figure 4-3 Firewall Configuration: Internet to WebRTC Session Controller

Securing Traffic between the WebRTC Session Controller and the SIP Core

To secure traffic between WebRTC Session Controller and the SIP Core:

• Obtain and configure a firewall between the WebRTC Session Controller and the SIP Core so that it allows only RTCP traffic between the SIP Core and the ME engines.

  See "Configuring a Firewall Between WebRTC Session Controller and the SIP Core" for more information.

• Follow the instructions for hardening SE administration servers in "Securing the Signaling Engine Administration Server".

• Secure Node Manager access to SE engines as described in "Securing Node Manager Access to SE".

• Make sure all of your ME and SE servers are fully patched.

Configuring a Firewall Between WebRTC Session Controller and the SIP Core

This example uses the sample components and IP addresses/ports shown in Figure 4-1.

Note:

The IP addresses and ports in Table 4-3 are only examples. Yours will be different.

Table 4-3 Configuring a Firewall Between WebRTC Session Controller and the SIP Core

Specifically Allow Traffic From:	To The Component/IP Address:Port	Notes
Signaling Engine 1	SIP Core (10.168.10.1:5061)	SIP traffic flows from SE 1to the SIP core and back through a SIP-aware load balancer.
Signaling Engine 2	SIP Core (10.168.10.1:5061), SE Admin Server (10.168.20.1:7002)	SIP traffic flows from SE 1to the SIP core and back through a SIP-aware load balancer. Access to the SE Admin server hosted on SE 1.
Media Engine 1	SIP Core (10.168.10.1:5061)	RTP and RTCP traffic flows from ME 1 to the SIP core and back.
Media Engine 2	SIP Core (10.168.10.1:5061)	RTP and RTCP traffic flows from ME 2 to the SIP core and back.
SIP Core	SE 1 (192.168.20.1:5060/5061), SE 2 (192.168.20.2:5060/5061), ME 1 (192.168.30.1:20000-25000), ME 2 (192.168.30.2:20000-25000)	N/A

Figure 4-4 illustrates the configuration in Table 4-3.

Figure 4-4 Firewall Configuration: WebRTC Session Controller to the SIP Core

General Hardening Instructions for SE and ME Installations

Keep these operating system level security considerations in mind:

• Confirm that the SE and ME binaries are owned by the WebRTC Session Controller installation user.

  Note:

  File permissions and ownership are set correctly by the WebRTC Session Controller installer, but you should verify that they have not been modified before deployment.

• For SE, lock down access to everything except:

  • Read/write access to the file system below the WebLogic domain directory

  • Access to the Java Virtual Machine (JVM)

  • Access to the RMI, and HTTP/HTTPS ports.

• Periodically audit the operating system file system file to notify administrators of unauthorized system binary changes.

Oracle Linux Security Hardening Information

For detailed hardening instructions pertinent to Oracle Linux, see the following sections in the Oracle Linux Security Guide:

• Pre-Installation Tasks which includes information on physical security, BIOS passwords and other system level considerations.

• Installing Oracle Linux which includes information on configuring shadow passwords and hashing, disk partition encryption, software selection and network time services.

• Implementing Oracle Linux Security which includes information on topics including:

  • Configuring and Using Data Encryption

  • Configuring and Using Access Control Lists

  • Configuring and Using SELinux

  • Configuring and Using Auditing

  • Configuring and Using System Logging

  • Configuring and Using Process Accounting

  • Configuring Access to Network Services

  • Configuring and Using Chroot Jails

SE Specific Security Tasks

This section provides details on security tasks that are specific to WebRTC Session Controller Signaling Engine.

Securing the Signaling Engine Administration Server

Securing the administration server involves these tasks:

• Encrypting the RMI traffic between the SE engines and the SE administration server. See "Encrypt SE RMI Traffic Between SE and the SE Administration Server" for details.

• Configuring the WebRTC Session Controller SE and ME administration servers to use a nonstandard port so that you can use customized firewall rules as well as encryption (HTTPS, IIOPS, or T3S). See "Securing the SE Administration Network Channel" for details.

• Changing the SE administration server context path from the default of /console to something else, for example, /adminconsole. See "Configuring the SE Admin Server to Use a Non-standard Context Path" for details.

• Configuring WebRTC Session Controller to only allow SSL traffic to the administration server. See "Restricting the SE Administration Server to SSL" for details.

Encrypt SE RMI Traffic Between SE and the SE Administration Server

To encrypt RMI traffic between SE and the SE administration server, for each SE server:

1. Open the Administration Console for your domain.

2. Click the Lock & Edit button.

3. Expand the Environments node in the Domain Structure pane and click the Servers node.

4. Click the Configuration tab in the Summary of Servers pane and click the name of the server in the Servers table that you want to configure.

5. Check SSL Listen Port Enabled.

   Note:

   Weblogic server uses the default JKS file store (Demo Identity and Demo Trust) for SSL configuration. However, you could specify a custom trust Keystore. See the Oracle WebLogic Server 12c: Configuring Managed Servers document for details.

6. Enter a numeric port number in the SSL Listen Port edit box.

7. Click Save to save your configuration changes.

8. Expand the Environments node in the Domain Structure pane if it is not already expanded and click Clusters.

9. Click the Signaling Engine cluster and then click the General tab.

10. Replace the port in the Cluster Address edit box with the SSL port you configured in step 6.

11. Click the Configuration tab, then the Replication tab.

12. Check Secure Replication Enabled.

13. Repeat steps 9 through 12 for the remaining SE servers.

14. Click Save to save your configuration changes.

15. Click Activate Changes to apply your changes to the SE servers.

16. To enable a secure channel for Java Message Service (JMS) add the -Dweblogic.DefaultProtocol=t3s flag to JAVA_OPTIONS in the middleware_home/bin/setDomainEnv.sh script:

    JAVA_OPTIONS="${JAVA_OPTIONS} -Dweblogic.DefaultProtocol=t3s"
    export JAVA_OPTIONS
    

17. Change the ADMIN_URL item in the domain_home/bin/startManagedWeblogic.sh script to https://IP_address:port_number

18. Restart each Signaling Engine server with this command:

    startManagedManaged.sh server_name https://IP_address:port_number
    

Note:

Make sure you enable SSL on your administration server as well to ensure that SSL is used throughout the cluster.

Network traffic between SEs and the SE administration server is now encrypted.

Securing the SE Administration Network Channel

In a DMZ deployment you should configure Signaling Engine servers to use custom ports as well as HTTPS, and certificates if required.

To secure the network channels:

1. Set your Signaling Engine environment:

   cd ~/domain_home/bin
   . ./setDomainEnv.sh
   

   where domain_home is the path to the domain's home directory.

2. Start WLST:

   java weblogic.WLST
   

3. Connect to the server using the username and password you configured during installation:

   connect('username','password','t3://myserver:port_number')
   

4. Switch to the server:

   cd('/Servers/myserverendpoint')
   

5. Create a new network channel:

   cmo.createNetworkAccessPoint('MyChannelName')
   

6. Switch to the new network channel:

   cd('/Servers/MyDomain/NetworkAccessPoints/MyChannelName')
   

7. Configure the network channel port:

   cmo.setProtocol('https')
   cmo.setListenPort(nnnn)
   cmo.setEnabled(true)
   cmo.setHttpEnabledForThisProtocol(true)
   cmo.setTunnelingEnabled(false)
   cmo.setOutboundEnabled(false)
   

8. Configure certificate usage and HTTPs for the network channel:

   cmo.setClientCertificateEnforced(true)
   cmo.setTwoWaySSLEnabled(true)
   

IMPORTANT:

The default channel settings remain stored in ServerMBean and SSLMBean, and are used if necessary to provide connections to a server instance. Make sure you explicitly specify the secure channel as the communications path between access and network tiers.

Configuring the SE Admin Server to Use a Non-standard Context Path

Oracle recommends changing the administration server context path from the default of /console to something like /adminportal.

To change the SE admin context path:

1. Set your SE environment:

   cd ~/domain_home/bin
   . ./setDomainEnv.sh
   

   where domain_home is the path to the domain's home directory.

2. Start the WebLogic Scripting Tool (WLST):

   java weblogic.WLST
   

3. Connect to the administration server for your WebRTC Session Controller domain using the username and password you configured during installation:

   connect('username','password','t3://myadminserver:port_number')
   

4. Switch to the administration server:

   cd('/Servers/AdminServer')
   

5. Create a new network channel:

   cmo.createNetworkAccessPoint('MyAdminServer')
   

6. Switch to the new network channel:

   cd('/Servers/AdminServer/NetworkAccessPoints/MyAdminServer')
   

7. Set the network channel's protocol to admin:

   cmo.setProtocol('admin')
   

8. Configure the administration server port:

   cmo.setListenPort(nnnn)
   cmo.setEnabled(true)
   cmo.setHttpEnabledForThisProtocol(true)
   cmo.setTunnelingEnabled(false)
   cmo.setOutboundEnabled(false)
   

9. Enable bidirectional SSL:

   cmo.setTwoWaySSLEnabled(true)
   

10. Disable client side certificates if they are not in use:

    cmo.setClientCertificateEnforced(false)
    

11. Set the listen addresses for the new administration channel:

    cmo.setPublicAddress('nnn.nnn.nnn.nnn')
    cmo.setListenAddress('nnn.nnn.nnn.nnn')
    

Restricting the SE Administration Server to SSL

To configure the SE administration server to allow only SSL:

1. Open the Administration Console for your domain.

2. Click Lock & Edit.

3. Expand the Environments node in the Domain Structure pane and click the Servers node.

4. Click AdminServer(Admin).

5. Click Configuration in the Summary of Servers pane and click the name of the server in the Servers table to configure.

6. Click General.

7. Check SSL Listen Port Enabled.

   Note:

   Weblogic server uses the default JKS file store (Demo Identity and Demo Trust) for SSL configuration. However, you should specify a custom trust Keystore. See the Oracle WebLogic Server 12c: Configuring Managed Servers document for details.

8. Enter a numeric port number in the SSL Listen Port edit box.

9. Uncheck the Listen Port Enabled box.

10. Click Save.

11. Click Activate Changes to apply your changes to the engine servers.

Securing Node Manager Access to SE

You can control WebRTC Session Controller by using Oracle WebLogic Node Manager (Node Manager) features. Node Manager relies on a one-way SSL connection for security. See ”Configuring Java-based Node Manager Security” and ”Using SSL with Java-Based Node Manager” in Fusion Middleware Node Manager Administrator's Guide for Oracle WebLogic Server 12c for details.

Configuring Connection Filters for SE Components Instead of a Firewall

In cases where WebRTC Session Controller SE components are not separated by firewalls, for instance between an SE server and an SE administration server, you can use WebLogic connection filters to provide network layer access control and block unwanted intrusions.

To configure a WebLogic connection filter:

1. Set your SE environment:

   cd ~/domain_home/bin
   . ./setDomainEnv.sh
   

   where domain_home is the path to the domain's home directory.

2. Start WLST:

   java weblogic.WLST
   

3. Connect to the server using the username and password you configured during installation:

   connect('username','password','t3://myserver:port_number')
   

4. Switch to the domain security MBean:

   cd('/SecurityConfiguration/'+domainName)
   

5. Enable a connection filter:

   cmo.setConnectionLoggerEnabled(true)
   

6. Define the connection filter implementation:

   cmo.setConnectionFilter('weblogic.security.net.ConnectionFilterImpl')
   

   Note:

   The example above uses the default connection filter implementation. For information on creating custom connection filters see "Developing Custom Filters" in Fusion Middleware Programming Security for Oracle WebLogic Server.

7. Configure the rules as a string array:

   set('ConnectionFilterRules',jarray.array
   ([String('myserver ip_address port allow t3s https'),
   String('ip_address/subnet_mask ip_address port allow'),
   String('ip_address ip_address port deny t3 http')],
   String))
   

ME Specific Security Tasks

After installing ME instances:

• Configure user accounts and restrict access to the ME instances as described in "Configuring Permissions, Users, and Authorization" in Oracle Communications WebRTC Session Controller System Administrator's Guide.

• Configure Secure Real-time Transport Protocol (SRTP) sessions as described in "Configuring Secure Media (SRTP) Sessions" in Oracle Communications WebRTC Session Controller Installation Guide.