1 General Security Principles

The following principles are fundamental to using any application securely.

Keep Software Up To Date

One of the principles of good security practice is to keep all software versions up to date. Oracle maintains multiple SBC streams or versions that are updated with applicable security patches. Always review the Critical Patch Updates and Release Notes relevant to the stream installed to determine whether an update should be applied.

Restrict Network Access to Critical Services

By design, the SBC family defaults to a closed state. No signaling or media can pass through the system unless it is explicitly configured.

Only services required for initial configuration of the system are available on a dedicated management Ethernet port (wancom0) which should be connected to a management network. Insecure services such as telnet and FTP should be disabled. Access to management services should be protected through the use of system level Access Control Lists (ACL) specifying allowed IP address ranges.

Signaling and media are only available on a separate set of Ethernet ports designated for services. ACLs should also be used on services ports for SIP peering deployments where possible. Some management capabilities can be enabled on these services ports by an administrator, so care should be taken to determine the risk of doing so in individual cases. In general it is not recommended to enable services other than perhaps ICMP.

Services should also be protected from DoS abuse through configuration of call admission controls, signaling thresholds, blacklisting, and attack tool detection, elements covered as part of this guide.

Follow the Principle of Least Privilege

The SBC family provides some implicit least privilege because direct user access is usually not provided. In most cases, the system acts as a proxy device so there is no direct user interaction. In other cases the system may provide a registrar function. However, providing the registrar function does not give the user access to any system level commands.

Administrators are the only ones who have any sort of system logon permissions. The system provides Role Based Access Control with dedicated user accounts that have pre-assigned privilege levels in the Command Line Interface. These are discussed further in the section on management interfaces. RADIUS and TACACS+ can be enabled as well to enable an outside authentication and authorization function. The minimum authorization class for RADIUS and command set should be considered for the administrator’s role.

Monitor System Activity

Monitoring system activity is critical to determine if someone is attempting to abuse system services and to detect if there are performance or availability issues. Useful monitoring information can be acquired through SNMP, RADIUS accounting, Historical Data Recording (HDR), and Syslog. At a minimum SNMP should be configured, and use of an external syslog server should be considered.

Keep Up To Date on Latest Security Information

Security issues that require a software or configuration update will be communicated in quarterly Critical Patch Updates (CPU). The latest CPUs as well as instructions to subscribe to them can be found at http://www.oracle.com/technetwork/topics/security/alerts-086861.html. A free Oracle Technology Network account is required to receive CPUs.

Overview

The Oracle Session Border Controller (SBC) family of products is designed to increase security, when deploying Voice over IP (VoIP) or Unified Communications (UC) solutions. Oracle's SBC family helps to protect IT assets, safeguard confidential information, and mitigate risks, while ensuring the high levels of service that users expect from the corporate phone system and the public telephone network.

Installed at the network perimeter, the SBC family of products provides a demarcation and enforcement point for the UC network. The primary security functions include:
  • Overload protection to prevent DoS attacks and registration floods
  • Access control to inhibit toll fraud and service theft
  • Topology hiding to counter topology discovery through reconnaissance scans
  • Encryption and authentication to ensure privacy and prevent loss of confidential information
  • Protocol validation to combat fuzzing and other types of malicious attacks

Net-SAFE Security Framework

The Oracle Net-SAFE™ security framework addresses the unique security challenges of delivering SIP-based interactive IP communications over the Internet. The Net-SAFE framework includes advanced security features, a highly-scalable architecture, and comprehensive monitoring and reporting capabilities. The framework reduces risk in UC services and applications by ensuring confidentiality, integrity, and availability.

Net-SAFE goals are as follows:
  • Protect the SBC—The first line of defense at the border is the SBC, which must be secure and resistant to attacks and overload.
  • Protect the infrastructure—The infrastructure includes the customer’s network of multimedia equipment (soft switches, application servers, SIP proxies, H.323 gatekeepers, gateways, and others).
  • Protect the service—Preventing attacks is not enough. UC services that generate revenue need to remain in service.

Example 1-1 Net-SAFE Requirements

The Net-SAFE framework identifies the requirements that an SBC must satisfy to meet the goals of the framework and provide confidentiality, integrity, and availability.

Marketing graphic depicting the 6 interconnected attributes of Net-SAFE: Access Control, Topology hiding and privacy, VPN Separation, Infrastructure DoS prevention, Fraud Prevention, and SBC DoS protection.

The Net-SAFE Framework spans seven general functions.

  1. Denial of Service (DoS) protection
    • Dynamic self-protection against malicious and non-malicious DoS attacks and overloads at layers 3 and 4 (TCP, SYN, ICMP, fragments, and others) and layer 5 (SIP signaling floods, malformed messages, and others)
    • Traffic management queues for control and throttling of signaling and media
  2. Access control
    • Session-aware access control for signaling and media using static and dynamic permit/deny ACLs at layers 3 and 5
    • ACL and DOS protection for the management interface
  3. Topology hiding and privacy
    • Complete infrastructure topology hiding at all protocol layers for confidentiality and attack prevention as well as modification, removal, or insertion of call signaling application headers and fields
    • Confidentiality and integrity through use of industry-standard encryption methods such as TLS, SRTP, and IPSec
  4. VPN separation
    • Support for Virtual Private Networks (VPNs) with full inter-VPN topology hiding and separation
    • Ability to create separate signaling-only and media-only VPNs
    • Optional intra-VPN media hair-pinning to monitor calls within a VPN
  5. Service infrastructure DoS prevention
    • Per-device signaling and media overload control, with deep packet inspection and call rate control to prevent DoS attacks from reaching service infrastructure
  6. Fraud prevention
    • Session-based authentication, authorization, and contract enforcement for signaling and media
  7. Monitoring and reporting
    • Audit trails, event logs, access violation logs and traps, and management access command recording
    • Call Detail Records (CDRs) with media performance monitoring
    • Raw packet capture ability
    • Lawful Intercept capability (For Service Provider products, only. Enterprise products do not support Lawful Intercept.)

SBC Specific Security Principles

(Security teams should consider the following guidelines when deploying a Unified Communications (UC) system. These are some of the areas where the SBC family will provide value.
  • Create a demarcation and enforcement point for the UC network: The enforcement point provides demarcation between zones of varying trust, such as the internal enterprise network, a BYOD network, a guest network, a demilitarized zone, or the public Internet.
  • Hide topology: Hackers can plan attacks by ascertaining information about network equipment (determining equipment types and software versions) or by detecting the IP addressing scheme a company employs. A UC demarcation device should remove any protocol fields that may assist in “fingerprinting” and should provide NAT (network address translation) at all protocol levels to conceal internal addressing schemes.
  • Encrypt endpoint communications: Businesses should encrypt communications flows when transiting public networks to prevent eavesdropping or impersonation. Encryption should also be considered on private networks to verify identity and prevent eavesdropping on privileged communications. Encryption can hinder lawful interception or other regulatory and corporate compliance requirements, so be sure to understand any impacts in your environment. By establishing a UC demarcation point and anchoring, unencrypting, and re-encrypting sessions at the network perimeter, security teams can tap or replicate sessions in the clear for compliance purposes.
  • Normalize protocol differences on-demand: Because UC venders implement SIP differently, using devices from multiple venders may cause interoperability problems. In extreme cases, the “normal” messaging from one manufacturer might cause failures or outages for another. Rather than depending on vendors to fix these interoperability issues, it is preferable to do so, in real-time, using an SBC.
  • Prevent DoS attacks and overloads: DoS or Distributed DoS (DDoS) attacks and other non-malicious events such as registration floods can impair IP communications infrastructure (border elements, application servers, endpoints) and disturb critical applications and services. Attackers may try to flood a network from one or more endpoints or may send malformed messages (protocol fuzzing) to overwhelm network devices. A UC demarcation device can ensure continued service availability by identifying DoS and DDoS attacks, and appropriately throttling or blocking traffic.