Signaling and Media Interface Security Configuration
Securing the service interfaces is an important consideration because they are typically deployed in public unsecured networks and are usually the demarcation or access point to the core network infrastructure.
Signaling and Media Management Functions
The phy-card is intended for signaling and media traffic, only. The SBC disables ICMP, Telnet, SNMP, and FTP on signaling and media interfaces by default. Oracle recommends that you do not enable any of these protocols on a service interface for any length of time longer than required for troubleshooting purposes.
See “System Configuration” in the ACLI Configuration Guide.
SIP Interface Security
As well as the layer 3 ACLs, the SBC provides layer 5 SIP protection to its signaling interfaces. By default, the SBC sip-interface, sip-port parameter allows and routes signaling from any device.
- registered: This is the most widely deployed setting, allowing only non-REGISTER SIP requests from either a defined session-agent or a previously registered device. (All REGISTER requests are processed.)
- realm-prefix: Allows SIP requests only from defined session-agents or previously registered endpoints. Allows only REGISTER requests from endpoints within the configured realm-prefix (subnet).
Although SIP interface security will deny service to a malicious user, the SIP daemon and the core CPU is utilized to parse and process each request. Oracle recommends deploying this feature in conjunction with the Net-SAFE architecture.
For SIP-interfaces communicating with non-registering devices (peering partner SBCs or core devices such as softswitches), Oracle recommends that you set allow-anonymous for agents-only.
Oracle recommends that you configure an Enforcement Profile with the list of allowable SIP methods, and that you configure only the minimum set of SIP methods necessary for your deployment. You can configure more protection in Access scenarios where SIP endpoints send SUBSCRIBE dialogs. You can limit the rate of these messages per user.
Oracle recommends that you apply session constraints to the sip-interface to limit the max-sessions, max-burst-rate, max-sustain-rate, and rate constraints for individual method types. For more information, see Section 5.3 “Constraint Limiting” of “520-0013-05 TECH NOTE Theory of the Session-agent.”
The SBC default SIP routing behavior is to comply with Route headers, as received. This behavior leaves a security gap, where a trusted device can construct a Route header and use the SBC as a reflector for signaling to another known device. The SBC also uses the Request-URI to route traffic, even when there is no matching local policy. This is mitigated by using techniques such as stripping Route headers on ingress (proceed with caution) and configuring null routes with 0.0.0.0, as the next hop.
See “SIP Signaling Services” and “Session Routing and Load Balancing” in the ACLI Configuration Guide.
Service ACLs
ACLs on service ports provide more functions than the basic permit and deny operations provided by the ACLs on management ports. Service ACLs effect traffic management through average rate limitations, trust level, and signaling thresholds similar to those specified on a realm.
- Define an ACL for all peering partners and all core systems to which traffic will be routed. The ACL is used to permit trusted hosts, deny untrusted hosts, and guarantee bandwidth in peak periods.
- Note that the minimum-reserved-bandwidth setting does not permanently reserve bandwidth. The setting is used only in peak periods to prioritize traffic. Set the minimum-reserved-bandwidth to the maximum signaling bandwidth capable for the system. If more than one core device is used, divide the bandwidth number equally. The number is not really bandwidth, but a priority metric.
- Hosts with a trust levels of high will never be demoted or blacklisted. However, if an invalid-signal-threshold of one is configured on the ACL, a syslog event will be written which might help detect attempted abuse.
- The trust level specified on the ACL should match the trust level on the realm from which it will communicate. Trust level mismatches can have unintended consequences such as permitting traffic that is intended to be denied. Refer to the following scenario that illustrates how this can be problematic.
This scenario shows a trusted core PBX on a private network, and two
PBXs on an external public network. The trust level on the ACL applied to the
external interface and the trust level on the external realm are depicted in
the following tables, along with what happens to traffic sent from a source IP
of “.100” or “.111.” In the first table: IP .111 permitted in ACL, the effects
of having the 192.168.1.111 address permitted are depicted. The second table
shows the opposite, when the 192.168.1.111 address is denied. Note what access
the 192.168.1.100 address has is based on the trust level of the realm and
ACL.
Table 3-1 .111 permitted in ACL
| Realm Trust Level | ACL Trust Level | src:100 | src:111 |
|---|---|---|---|
| None | none | Permit | Permit |
| None | low | Deny | Permit |
| None | medium | Deny | Permit |
| None | high | Deny | Permit |
| Low | none | Permit | Permit |
| Low | low | Deny | Permit |
| Low | medium | Permit | Permit |
| Low | high | Permit | Permit |
| Medium | none | Permit | Permit |
| Medium | low | Permit | Permit |
| Medium | medium | Deny | Permit |
| Medium | high | Permit | Permit |
| High | none | Permit | Permit |
| High | low | Permit | Permit |
| High | medium | Permit | Permit |
| High | high | Deny | Permit |
Table 3-2 .111 denied in ACL
| Realm Trust Level | ACL Trust Level | src:100 | src:111 |
|---|---|---|---|
| None | none | Deny | Deny |
| None | low | Deny | Deny |
| None | medium | Deny | Deny |
| None | high | Deny | Deny |
| Low | none | Permit | Deny |
| Low | low | Permit | Deny |
| Low | medium | Permit | Deny |
| Low | high | Permit | Deny |
| Medium | none | Permit | Deny |
| Medium | low | Permit | Deny |
| Medium | medium | Permit | Deny |
| Medium | high | Permit | Deny |
| High | none | Permit | Deny |
| High | low | Permit | Deny |
| High | medium | Permit | Deny |
| High | high | Permit | Deny |
TLS for SIP
Transport Layer Security (TLS) provides end-to-end authentication and encryption of SIP signaling. TLS protects against eavesdropping, tampering, forgery, and potential theft of service. For this reason, Oracle recommends using TLS wherever possible.
All supported products have TLSv1.1 and TLS1.2.
The SBC supports mutual-authentication within a TLS profile. Although disabled by default, Oracle recommends enabling mutual-authentication when endpoints support it.
- Basic—The client authenticates the SBC certificate by using the CA public key, and checks expiration, common name, and ciphers supported. Basic provides confidentiality and integrity through encryption, but does not establish the identity of the endpoint. Credential cracking is still possible, and the move to TLS (based on TCP) may make port exhaustion DoS a bit easier for an attacker.
- Mutual—A step is added in which the client certificate is sent to the SBC for verification. You can use single or individual client certificates. Mutual provides the same characteristics of the basic model with the advantage of verifying that the client is likely trusted because an issued certificate is present. If a single certificate is used for all clients then theft or compromise of an endpoint may allow access to an attacker. Individual certificates are more secure, but require more administrative effort to issue and manage.
- Mutual with certificate revocation—Certificate revocation for individual clients is possible, which guarantees only expired or revoked clients are refused access. An external Online Certificate Status Protocol (OCSP) server is required to check against the Certificate Revocation List.
Note:
The SBC does not support local CRLs due to onboard storage limitations.- Certificates installed on the SBC must be derived from a local Certificate Signing Request in PKCS-10 PEM/Base 64 format. Certificates cannot be installed without a CSR.
- Certificate key lengths can go up to 2048 bits, with 4096 possible with SSM3 (currently on supported on 6300) after SC7.2.
- Certificates are currently signed with a SHA-1 hash by default. Oracle recommends signing with SHA-2 or above.
- If site-to-site failover is required, the main site’s fully qualified domain name (FQDN) and the FQDN for any alternate site should be specified as alternate-names in the certificate record prior to CSR generation.
- TLS session caching (tls-global element) allows a previously authenticated user to reuse a previous session so authentication is sped up. This may help reduce time to recovery due to outages, though it is best suited for environments where user IP does not vary significantly.
The list of available TLS ciphers is located in the Release Notes. The default cipher list when creating a tls-profile is "DEFAULT." The default list includes all current, secure ciphers. The "ALL" cipher list includes all available, non-debug ciphers, some of which may be potentially unsecure. The “NONE” cipher list does not provide encryption; only authentication.
- sip-config, inactive-dynamic-conn—Defines global timer for tearing down idle TCP and TLS connections where no SIP data has been sent. The timer used is twice as long for TLS.
- sip-interface settings to
limit connections:
- untrusted-conn-timeout—Closes socket if untrusted entity does not become trusted, such as if the register didn’t complete.
- inactive-conn-timeout—Tears down idle TCP/TLS connections when no further data is being sent, such as if a trusted host sends an INVITE but nothing else.
- max-incoming-conns—Set to max incoming sessions you want the SIP interface to host plus overhead for setup / teardown (depends on call rate).
- per-src-ip-max-incoming-conns—Usually 1 or 2 but affected by NAT use and application.
See “Security” in the ACLI Configuration Guide.
OCSP
The Online Certificate Status Protocol (OCSP) is defined in RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. The protocol enables you to determine the revocation state of a specific certificate, and may provide a more efficient source of revocation information than is possible with Certificate Revocation Lists (CRL).
The protocol specifies the data exchanged between an OCSP client (such as the Oracle Communications SBC) and an OCSP responder, the Certification Authority (CA), or its delegate, that issued the target certificate. An OCSP client issues a request to an OCSP responder and suspends acceptance of the certificate in question until the responder replies with a certificate status. Certificate status is reported as
- good
- revoked
- unkown
OCSP can be especially useful in environments where individual certificates have been issued to a single user or user device. Certificates for devices that are stolen or misplaced can be revoked, so even if valid credentials are known the device will not be able to connect.
See “Security” in the ACLI Configuration Guide.
SRTP
Many customers require the ability to encrypt and authenticate the content and signaling of their real time communications sessions. The SBC supports the Secure Real-Time Transport Protocol (SRTP). Authentication provides assurance that packets are from the purported source, and that the packets have not been tampered with during transmission. Encryption provides assurance that the call content and associated signaling has remained private during transmission.
With two exceptions, SRTP requires an IPsec NIU. The 1100 and 3900 platforms support software-based SRTP.
RTP and RTCP traffic are encrypted as described in RFC 3711, The Secure Real-time Transport Protocol (SRTP). The negotiation and establishment of keys and other cryptographic materials that support SRTP is described in RFC 4568, Session Description Protocol (SDP) Security Description for Media Streams. Cryptographic parameters are established with only a single message or in single round-trip exchange using the offer–answer model defined in RFC 3264. An Offer–Answer Model with the Session Description Protocol (SDP).
See Appendix L: and “Security” in the ACLI Configuration Guide.
Securing Media Interfaces with IPsec
IPsec provides another mechanism for encrypting and securing media interface traffic, including SIP, RADIUS, etc, on supported platforms.
Security Associations and Security Policies allow for flexibility in defining local and remote IP address, ports and subnet masks. These should be defined to only allow IPsec communications between authorized gateways or hosts and the SBC.
The SBC supports IKE to create IPsec tunnels dynamically. This is based on the Internet Key Exchange (IKE) Protocol as defined in RFC5996 and RFC 2409, Internet Key Exchange, and for the Dead Peer Detection (DPD) protocol as defined in RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers.
- IKE pre-shared secret support
- IKE/ISAKMP Main Mode support
- IKE/ISAKMP Aggressive Mode support
- Phase 2 Quick Mode support
- IKE pre-shared secret support
- X.509 certificate-based authentication
In addition, with IKE enabled, the SBC can support IPsec between itself and an endpoint behind a NAT device.
Oracle recommends you use IKEv2.. See “Security” in the ACLI Configuration Guide.
Call Admission Control
Call Admission Controls (CAC) limit the number of allowed resources such as bandwidth or sessions to abide by customer Service Level Agreements (SLA) and to avoid abuse. Oracle recommends that you enable the following features wherever possible:
- Bandwidth (codec) based—for bandwidth CAC settings see “Media Profiles”
- SIP Per-User CAC
- Session Capacity
- Session Rate (sustained and burst)
Bandwidth CAC
You can implement bandwidth based CAC through a media profile on the realm level. Media profiles specify or limit the range of the codecs, bandwidth, and packet rate used. See “Realms and Nested Realms” in the ACLI Configuration Guide.
SIP Per-User CAC
When you enable SIP per-user CAC, the SBC changes its default behavior to allow only the configured number of calls or total bandwidth to and from each individual user in a particular realm. You can apply CAC to an individual Address of Record (AoR) or IP address. Tracking based on IP address can cause complications when a NAT is involved, so the use of a nat-trust-threshold may be required to set the maximum number of untrusted endpoints behind NAT devices. This also enables the ability of the SBC to track endpoints based on both IP and the TCP or UDP port in use.
See “SIP Signaling Services” in the ACLI Configuration Guide.
Session Capacity and Session Rate using Constraints
Constraints is a CAC method that limits messaging based on session count and rate. You can apply constraints to SIP interfaces or realms. Oracle recommends using constraints on all external interfaces and core session-agents.
A session-agent can be configured for max-outbound-sessions, max-sessions, max-burst-rate and max-sustain-rate.
Max-outbound-sessions and max-sessions give the max number of allowed concurrent sessions. Set these to match what should be sent to an upstream session-agent (for example a service provider) or accepted into a core session-agent.
The session-agent's max-burst-rate and max-sustain-rate are used to throttle the calls per second (CPS) of traffic sent to and by that session-agent. Each of these parameters has its own configurable window by which the statistics are gauged for constraint exceptions.
For the sustained-rate, the average is calculated over the previous window (equal to the sustained-rate-window) and current window fragment. The window fragment will be between 0 and the configured sustained-rate-window upon receipt of an Invite. Once the window fragment increments and reaches the sustained-rate-window, this rotates and becomes the previous window -- and a new window fragment begins at 0. At this point all calculations are re-calibrated accordingly.
For example, consider the scenario where the sustain-rate is set to 15 and the sustain-rate-window is set to 10 seconds. When an invite is received the SD will add the amount of Invites received in the current window fragment and the previous window and divide by the number of seconds to get the average for that period. This average is then compared to the 15 CPS derived from the sustain-rate and the sustain-rate window. If the session-agent per the previous and current window is above 15 CPS when the Invite is received, the Invite will be rejected.
The max-burst-rate and burst-rate-window interact by limiting the CPS rate for a burst of traffic over the window. Using the example below, with a max-burst-rate of 20 and a burst-rate-window of 10, the SD will permit 200 sessions within the first 10 seconds and then reject all new sessions until it exits constraint mode.
Burst rate is much easier to understand and configure, so it is preferable over sustain rate.
As for a session-agent in constraint, it does not come out of constraint mode when traffic drops below its constraint thresholds; it comes out of constraint mode after 60 seconds, unless a configured time-to-resume value dictates otherwise. Even though the session-agent is out of the constraint mode after time-to-resume seconds “show sipd agent” will show it back into In-Service mode only if the traffic flows to or from that session-agent. On exceeding its constraint the session-agent is marked “C”.
Core registrars should have a max registration burst rate configured to the maximum rate (or just below) what the registrar can handle.
See “SIP Signaling Services” and “Admission Control and Quality of Service Reporting” in the ACLI Configuration Guide.
Media Policing
Media policing controls the throughput of individual session media flows (RTP and RTCP) in the SBC. It also allows the SBC to police static flows. Oracle recommends enabling media policing to protect against RTP media flooding and bandwidth piracy.
For each individual codec being used in sessions, a media-profile must be created with average-rate-limit thresholds configured.
See “Security” in the ACLI Configuration Guide.
DoS/DDoS Prevention
DoS and DDoS settings can protect against malicious and non-malicious SIP flooding attacks from untrusted sources without adversely affecting service to trusted peers.
You can prevent attacks through configuration of Access Control Lists, appropriately sized traffic queues, and trust level settings that limit or blacklist endpoints that become abusive.
Configuration of these parameters will differ based upon the configuration model used – peering, access, or hybrid. Refer to either Appendix C: DDoS Prevention for Peering Environments or Appendix D: DDoS Prevention for Access or Hybrid Environments, depending on the architectural model implemented.
Note:
Note that a comprehensive and effective DDoS prevention design requires analysis of traffic patterns, SIP message contents and performance characteristics of all peer devices to provide message thresholds, CAC, and traffic policing settings. Please contact your Oracle Sales representative for information on professional services designed to implement customized DDoS settings.Attack Tool Prevention
Many SIP scanning and attack tools employed by fraudsters can be prevented through employment of restrictive signaling thresholds and trust levels – the same ones used for DDoS protection. However, some deployments do not allow for this without impacting legitimate traffic. Attackers may also use commonly available tools that have identifiable signaling patterns. In these situations, additional attack tool identification and prevention may limit or prevent an attack from being successful.
Oracle recommends that any deployment with internet-connected interfaces comply with the settings described in Appendix E: Mitigating SIP Attacks.
Lawful Interception
Note:
LI applies to Service Provider products, only. Enterprise products do not support Lawful Interception.