Implementing SBC Access Control Lists for IP-Based SIP Trunk Security Hardening

How-To-Articles
1

Implementing SBC Access Control Lists for IP-Based SIP Trunk Security Hardening

What This Guide Covers

This guide details the architectural implementation and configuration of Access Control Lists (ACLs) on Session Border Controllers (SBCs) to enforce strict IP-based security for SIP Trunks in Genesys Cloud CX. You will configure whitelisted IP ranges for upstream carriers, implement fail-open/fail-closed logic for maintenance windows, and validate the traffic flow using real-time monitoring. The end result is a hardened telephony perimeter that rejects unsolicited SIP traffic at the network edge, significantly reducing the attack surface for toll fraud and SIP flooding.

Prerequisites, Roles & Licensing

Licensing and Permissions

  • Genesys Cloud CX: No specific add-on license is required for SBC configuration, but you must have Telephony > Trunk > Edit permissions to modify existing trunks or create new ones.
  • SBC Vendor: You need administrative access to your SBC platform (Cisco VCS, AudioCodes Mediant, Ribbon/Avaya, or Fortinet). The specific CLI or GUI commands vary by vendor, but the logical configuration remains consistent.
  • Network Engineering: You require access to the firewall/router that hosts the SBC to verify NAT and port forwarding rules.

External Dependencies

  • Carrier Documentation: You must have the official IP address ranges (CIDR blocks) provided by your SIP Trunk provider. This document is often called the “Peering Guide” or “Interconnect Specification.”
  • SBC Health Checks: Ensure your SBC is currently passing Genesys Cloud health checks. If the SBC is already blocking traffic due to misconfiguration, you must temporarily open the ACLs to restore connectivity before making changes.

Technical Context

SIP is a UDP-based protocol (primarily port 5060) that relies heavily on stateful inspection. Unlike HTTP, where a firewall can easily inspect headers, SIP uses dynamic ports for media (RTP) and signaling. An SBC acts as a demarcation point. Without ACLs, your SBC is effectively open to the entire internet on port 5060, inviting brute-force credential stuffing, SIP INVITE flooding, and toll fraud attempts. This guide focuses on the Genesys Cloud side of the configuration and the corresponding SBC logic.

The Implementation Deep-Dive

1. Auditing Current Trunk Configuration and Carrier IP Ranges

Before touching the SBC, you must establish the ground truth of what traffic is currently allowed. Genesys Cloud does not host the SBC; it sits behind the SBC. Therefore, Genesys Cloud cannot enforce IP filtering for inbound carrier traffic. The SBC must perform this function. However, you must ensure your Genesys Cloud Trunk configuration matches the SBC’s expectations.

Step 1.1: Identify Carrier IP Ranges

Obtain the list of public IP addresses or CIDR ranges from your SIP Trunk provider. Providers often have multiple points of presence (PoPs). You must whitelist all PoPs that route traffic to your specific tenant.

The Trap: Assuming the provider’s website lists all active IPs. Many providers have dynamic IP pools for failover. If you whitelist only the primary IP and the provider fails over to a secondary IP, your entire phone system goes dark. Always request the full “Active and Failover” IP list.

Step 1.2: Review Genesys Cloud Trunk Settings

Navigate to Telephony > Trunks in Genesys Cloud. Select the target SIP Trunk.

  1. Verify the SBC IP Address listed in Genesys Cloud matches the public IP of your SBC.
  2. Check the Authentication method. If you are using IP-Based Authentication (common for large enterprise trunks), Genesys Cloud expects traffic only from the IPs listed in the Allowed IPs section of the Trunk configuration.
  3. If you are using Username/Password Authentication, Genesys Cloud will validate credentials, but this does not protect against DoS attacks. IP-based ACLs on the SBC are still required to limit the volume of invalid attempts.

Architectural Reasoning: Genesys Cloud’s “Allowed IPs” field is a secondary layer of defense. It prevents Genesys Cloud from accepting SIP messages from unauthorized sources even if the SBC lets them through. However, the SBC is the first line of defense. Blocking at the SBC saves bandwidth and processing power on the Genesys Cloud edge.

2. Configuring SBC Access Control Lists (ACLs)

The core of this implementation happens on the SBC. The logic is simple: Deny all, Permit specific. You will create an ACL that permits SIP signaling from the carrier’s IP ranges and denies all other sources.

Step 2.1: Define the ACL Logic

Create a named ACL (e.g., CARRIER_SIP_ACL). The order of evaluation matters. Most SBCs evaluate rules top-down.

Rule Structure:

  1. Permit SIP/UDP from Carrier_IP_Range to SBC_IP on Port 5060.
  2. Permit SIP/TCP from Carrier_IP_Range to SBC_IP on Port 5060 (if TCP is used).
  3. Deny SIP from Any to SBC_IP on Port 5060.
  4. Permit RTP from Carrier_IP_Range to SBC_IP on Ports 10000-20000 (or your defined media range).
  5. Deny All other traffic.

The Trap: Forgetting to permit RTP (media) traffic. SIP signaling sets up the call, but RTP carries the voice. If you only ACL the signaling port (5060), calls will connect, but users will hear silence or one-way audio. The SBC must allow the dynamic media ports established in the SDP (Session Description Protocol) negotiation.

Step 2.2: Vendor-Specific Implementation Examples

Below are production-ready configuration snippets for common SBC vendors.

AudioCodes Mediant Example (CLI):

# Define the ACL
config acl CARRIER_SIP_ACL

# Permit SIP Signaling from Carrier Range 1
config acl CARRIER_SIP_ACL rule 1 permit sip from 203.0.113.0/24 to any port 5060

# Permit SIP Signaling from Carrier Range 2 (Failover)
config acl CARRIER_SIP_ACL rule 2 permit sip from 198.51.100.0/24 to any port 5060

# Permit RTP Media from Carrier Range 1
config acl CARRIER_SIP_ACL rule 3 permit rtp from 203.0.113.0/24 to any port 10000-20000

# Permit RTP Media from Carrier Range 2
config acl CARRIER_SIP_ACL rule 4 permit rtp from 198.51.100.0/24 to any port 10000-20000

# Deny All Other SIP Traffic
config acl CARRIER_SIP_ACL rule 5 deny sip from any to any port 5060

# Deny All Other RTP Traffic
config acl CARRIER_SIP_ACL rule 6 deny rtp from any to any port 10000-20000

# Apply ACL to the SIP Trunk Interface
config sip trunk TRUNK_GENESYS_CLOUD
config sip trunk TRUNK_GENESYS_CLOUD acl inbound CARRIER_SIP_ACL
apply

Cisco VCS Expressway Example (GUI/CLI):

In Cisco VCS, you configure “Call Admission Policies” or “IP Access Control Lists.”

  1. Navigate to Security > Access control > IP access control.
  2. Create a new list named CARRIER_SIP_ACL.
  3. Add entries for each Carrier IP/CIDR with action Allow.
  4. Add a final entry for 0.0.0.0/0 with action Deny.
  5. Navigate to Call management > Call admission policies.
  6. Create a policy that applies CARRIER_SIP_ACL to inbound calls on the trunk profile associated with Genesys Cloud.

The Trap: Applying the ACL to the wrong interface. Ensure the ACL is applied to the inbound direction on the trunk interface facing the carrier, not the internal interface facing Genesys Cloud. Applying it internally breaks the trust model between the SBC and Genesys Cloud.

3. Updating Genesys Cloud Trunk Allowed IPs

Once the SBC is filtering traffic, you must align Genesys Cloud’s expectations. This step is critical for IP-Based Authentication trunks.

Step 3.1: Configure Allowed IPs

  1. In Genesys Cloud, go to Telephony > Trunks.
  2. Select your SIP Trunk.
  3. Scroll to the Security section.
  4. In the Allowed IPs field, enter the same Carrier IP ranges you whitelisted on the SBC.
  5. Save the configuration.

Architectural Reasoning: This creates a defense-in-depth strategy. If an attacker manages to bypass the SBC ACL (e.g., via a compromised SBC configuration or a misrouted internal packet), Genesys Cloud will still reject the SIP INVITE because the source IP is not in the allowed list. This is essential for compliance frameworks like PCI-DSS and HIPAA, which require layered security controls.

The Trap: Using IP-based authentication without configuring Allowed IPs. If you select “IP-Based Authentication” in Genesys Cloud but leave the Allowed IPs field empty, Genesys Cloud may accept traffic from any IP, defeating the purpose of IP-based auth. Conversely, if you use Username/Password auth, the Allowed IPs field is ignored for authentication purposes but can still be used for logging and monitoring.

4. Validating the Configuration

You must verify that legitimate traffic flows and illegitimate traffic is blocked.

Step 4.1: Test Legitimate Traffic

  1. Place a test call from the carrier’s test number (if available) or from an external PSTN line.
  2. Monitor the SBC logs for the SIP INVITE. You should see the INVITE accepted from the carrier IP.
  3. Monitor Genesys Cloud Telephony > Trunks > [Trunk Name] > Logs. You should see the call connected without authentication errors.

Step 4.2: Test Illegitimate Traffic (Controlled Environment)

Warning: Do not test this in a production environment if it could trigger a carrier-side alarm. Use a sandbox environment or a secondary trunk if possible.

  1. From a source IP not in the carrier’s range, attempt to send a SIP INVITE to your SBC’s IP on port 5060.
  2. Use a tool like sipcli or sipsak.
sipsak -v -r 10.0.0.1:5060 -m INVITE -t user@genesyscloud.com
  1. The SBC should drop the packet. You will not receive a 401 Unauthorized or 403 Forbidden response; you will receive no response at all (timeout) because the packet is dropped at the network layer.
  2. Check the SBC logs. You should see a drop event corresponding to the denied ACL rule.

The Trap: Assuming a 403 Forbidden response means the ACL is working. A 403 response means the SIP message reached the application layer and was rejected by the SBC’s SIP stack. An ACL working correctly drops the packet before it reaches the SIP stack. If you see a 403, your ACL is either not applied or misconfigured.

Validation, Edge Cases & Troubleshooting

Edge Case 1: Carrier NAT and Dynamic IP Pools

The Failure Condition: Calls fail intermittently, especially during peak hours or after carrier maintenance. The SBC logs show SIP INVITEs from IPs not in the ACL.

The Root Cause: The carrier is using Carrier-Grade NAT (CGN) or a dynamic pool of outbound IPs that change based on load balancing. Your static ACL is too rigid.

The Solution:

  1. Request a broader CIDR range from the carrier that encompasses their entire dynamic pool.
  2. If the carrier cannot provide a stable range, switch to Username/Password Authentication in Genesys Cloud. This allows the SBC to permit a broader IP range (e.g., the carrier’s entire ASN) while Genesys Cloud validates the credentials.
  3. Implement SIP Options Pings from the SBC to the carrier to detect IP changes dynamically (if supported by your SBC vendor).

Edge Case 2: SBC Firmware Updates and ACL Persistence

The Failure Condition: After an SBC firmware update, all inbound calls fail. The SBC reboots and loses the ACL configuration.

The Root Cause: The ACL was configured in the running configuration but not saved to the startup configuration. Or, the firmware update reset the trunk profiles.

The Solution:

  1. Always save the configuration after making changes (write memory or save config).
  2. Use a configuration management tool (Ansible, Puppet) to push SBC configurations. This ensures that if the SBC is rebuilt or reset, the ACLs are reapplied automatically.
  3. Include the ACL configuration in your disaster recovery runbook.

Edge Case 3: One-Way Audio Due to Media ACL Mismatch

The Failure Condition: Calls connect, but one party cannot hear the other. The SBC logs show SIP signaling success but no RTP flow.

The Root Cause: The ACL permits SIP signaling (port 5060) but blocks the dynamic RTP ports used for media. The SBC negotiates media ports via SDP in the SIP body. If the ACL blocks these ports, the media stream is dropped.

The Solution:

  1. Ensure the ACL permits RTP traffic from the carrier’s IP range to the SBC’s media port range.
  2. Verify that the SBC’s media port range (e.g., 10000-20000) is open on the firewall between the SBC and Genesys Cloud.
  3. Check if the carrier uses a different media port range. Some carriers use fixed ports or specific ranges. Adjust the ACL accordingly.

Edge Case 4: SIP Flood Attacks Bypassing Rate Limits

The Failure Condition: The SBC is overwhelmed by a high volume of SIP INVITEs from a whitelisted carrier IP. The SBC CPU spikes, and legitimate calls drop.

The Root Cause: The ACL permits the carrier IP, but does not limit the rate of requests. An attacker compromises the carrier’s infrastructure or spoofs the carrier IP.

The Solution:

  1. Implement Rate Limiting on the SBC for the carrier IP range. For example, limit to 100 INVITEs per second per IP.
  2. Configure SIP Message Validation on the SBC to reject malformed SIP packets.
  3. Work with the carrier to implement STIR/SHAKEN attestation. This helps validate the origin of the call at the network level.
  4. In Genesys Cloud, enable Fraud Detection features (if available in your license tier) to monitor for unusual call patterns.

Official References