SBC Access Control List Configuration: Designing IP Allow-Lists That Actually Hold Up in Production

Every Session Border Controller exposed to the internet receives unwanted SIP traffic within minutes of going live. Some of it is opportunistic scanning, some of it is registration brute-forcing, and some of it is the slow background hum of malformed packets that come from compromised hosts looking for a path into a PBX. An access control list is the first instrument the SBC uses to decide which of those packets get a closer look and which get dropped before they consume CPU resources.

This guide is about how to configure those lists rather than what they exist to defend against. It covers where ACL evaluation actually happens inside the SBC, the two design philosophies that govern every rule you write, how scopes interact across global, interface, and per-trunk levels, the configuration patterns for the deployments TelcoBridges sees most often, and the operational pitfalls that quietly break calls weeks after a clean install.

Why IP-Based Access Control Is the Foundation, Not the Ceiling

An ACL is the cheapest decision an SBC ever makes. The packet has not been parsed, the SIP transaction has not been opened, and no application-layer state has been allocated. A drop at this layer costs the SBC almost nothing in CPU or memory, which is precisely why it has to be the first decision in the chain. If an attacker can make the SBC reach the SIP parser before being filtered, every malformed packet becomes a transaction that competes for resources with legitimate calls.

That economic argument is also the reason ACLs cannot be the only defense. IP-based filtering knows nothing about who the sender claims to be, what method they are invoking, or whether their credentials are valid. A permitted carrier IP can still source malformed messages, REGISTER floods, or fraudulent calls if it is itself compromised. ACLs reduce the surface area; the full SBC security stack handles the threats that arrive from inside the allowed perimeter.

The practical implication is that good ACL configuration is not a one-time hardening exercise. It is a continuous discipline of keeping the allow-list tight enough that the rate limiter, the protocol validator, and the routing engine only ever see traffic worth processing.

Where ACLs Sit in the SBC’s Processing Pipeline

Configuring an ACL well requires understanding exactly when it is consulted. An SBC processes every inbound packet through an ordered chain of checks, and the position of the ACL in that chain determines what it can and cannot protect against.

The Order of Operations

The pipeline starts at the network interface where a UDP, TCP, or TLS packet arrives. The kernel hands the packet to the SBC process, which applies the global ACL first. Packets that match a permit rule advance to the interface-specific ACL. Packets that pass the interface check are then evaluated against the per-NAP allow-list, which is the most granular scope the SBC enforces. In ProSBC’s processing model, only after all three ACL layers have permitted the packet does the traffic advance to the rate limiter, the SIP parser, and finally the routing engine.

Each layer drops packets cheaply. The global check costs the fewest cycles, since it matches against a small set of universal rules. The per-NAP check is the most expensive of the three, but it runs against an already-shrunken candidate set, so the absolute cost stays low. The economic logic is the same at every step: cheap drops first, expensive processing only for traffic that has cleared every cheaper gate.

Why Ordering Matters for Configuration

Ordering matters because each layer can only enforce what it sees. A global ACL that blocks a malicious /24 protects every NAP automatically. A per-NAP allow-list that names a specific carrier IP protects that trunk group regardless of what is happening on the global ACL. Putting too much into the global layer makes maintenance painful, since every change forces a review across every trunk. Putting too little into the global layer means each NAP has to re-implement defenses that should have been universal.

The configuration patterns later in this guide follow a consistent rule of thumb: universal rules live at the global scope, peer-specific rules live at the NAP scope, and the interface scope handles the cases that fall between (such as separating signaling-facing interfaces from management-facing ones).

The Two Design Philosophies: Default Deny vs. Default Allow

Every ACL is governed by one of two starting positions. The choice between them is the most consequential decision in an SBC’s security posture, and it has to be made deliberately for every interface, not assumed.

Default Deny: The Allow-List Posture

Default deny means the ACL drops any packet that does not match an explicit permit rule. The operator enumerates every source that is allowed to send SIP to the interface, and everything else is rejected at the earliest possible layer. This is the correct posture for any signaling interface where the legitimate peer set is small and known: a SIP trunk facing one or two carriers, a Teams-facing interface where Microsoft’s published IP ranges are the only legitimate source, or a peering link between two service providers.

The operational benefit is enormous. The SBC sees background scanning traffic from compromised hosts every minute of every day, and a default-deny posture drops all of it without ever opening a transaction. The cost is the maintenance burden of keeping the permitted list in sync with the carrier or partner’s actual source IPs, which change occasionally and without warning.

Default Allow: The Deny-List Posture

Default allow means the ACL accepts any packet that does not match an explicit deny rule. The operator lists known bad sources and trusts everything else by default. This posture is appropriate only when the legitimate source population is too large to enumerate, such as a residential softphone deployment serving thousands of remote workers whose home IPs change daily.

Even in those cases, default allow on the ACL is paired with strong authentication at the SIP layer, since the IP filter cannot meaningfully reduce the attack surface. The deny-list is reserved for cutting off specific, identified bad actors, and the SBC relies on registration authentication, rate limiting, and dynamic blacklisting to handle the long tail of opportunistic abuse.

Choosing the Right Posture Per Interface

Most production SBCs run a mix. Trunk-facing interfaces almost always use default deny because the carrier IPs are known. User-facing interfaces lean toward default allow because the source population is dynamic. The crucial point is that the posture is chosen per interface rather than per SBC, and the choice should be documented alongside the configuration so the rationale survives operator turnover.

ACL Scopes: Global, Per-Interface, and Per-NAP

ProSBC enforces ACL policy at three distinct scopes. Understanding what belongs at each one is the difference between an ACL that scales and one that grows into an unmaintainable thicket.

Global Scope

The global ACL applies to every packet that reaches the SBC, regardless of interface or trunk. It is the right place for rules that should hold true everywhere: blocking known-bad ranges sourced from threat-intelligence feeds, dropping bogon and reserved prefixes, and permitting management traffic from internal subnets. Global rules are evaluated first, so a global drop saves work at every downstream layer.

The discipline at the global scope is restraint. Anything that applies to one trunk and not another belongs further down. A global ACL with hundreds of carrier-specific entries quickly becomes a maintenance liability, since every change requires reasoning about whether the rule conflicts with another trunk’s needs.

Interface Scope

The interface ACL applies to packets arriving on a specific physical or virtual network interface. Most deployments use this scope to separate signaling, media, and management planes, so that a packet arriving on the management interface cannot reach the signaling stack and vice versa. Interface rules are also useful for splitting trunks across multiple network paths in deployments where carriers connect over different upstream providers.

Interface rules sit between global and per-NAP in maintenance cost. They are touched less often than per-NAP rules but more often than the global ones, which makes them a good fit for plane-separation policy that is stable but not universal.

Per-NAP Scope

The per-NAP ACL is where most peer-specific policy lives. Each NAP represents a single trunk group, carrier connection, or customer tenant, and its ACL defines exactly which source IPs are permitted to send SIP messages through that trunk. ProSBC’s BlackWhiteListing module supports per-NAP scope with longest-prefix matching, so an operator can permit a carrier’s /24 generally while blocking a specific /32 within that range if a single host inside the carrier’s network has been compromised.

The per-NAP scope is also where dynamic blacklisting attaches. When the SBC detects abnormal behavior from a source against a specific NAP (failed registrations from a specific IP, malformed INVITEs at a high rate), it can add a deny rule to that NAP’s ACL automatically. The static configuration defines the steady state; the dynamic additions handle the live response. The same idea applies in reverse for greylisting, where ProSBC will throttle a configurable percentage of traffic from a suspect source while leaving the rest of the trunk untouched.

How the Three Scopes Combine

The simplest way to think about the three scopes is as concentric circles. Global is the outermost. A packet that fails the global check never reaches the interface or NAP layer. Interface is the middle ring, scoping rules to the physical or virtual port. Per-NAP is the innermost, scoping rules to a specific trunk group. A packet must pass all three to reach the SIP parser, and any layer can drop it independently.

Common ACL Configuration Patterns

Most SBC deployments fall into one of a handful of recurring patterns. Each one calls for a specific scope mix and posture combination, and the differences matter at scale.

Single SIP Trunk to One Carrier

The simplest case. The carrier publishes a small set of source IPs that send SIP to the SBC, and the SBC’s job is to ensure that nothing else reaches the trunk. Configure the carrier-facing NAP with a default-deny posture and permit only the carrier’s published /32 entries (or a tight /29 or /30 if the carrier uses a small contiguous range). Add the carrier’s media subnet to the per-NAP ACL too, since RTP and SIP often come from different addresses inside the carrier’s network.

The global ACL should permit only the bogon-block rules and any management subnets. In most deployments, there is little reason for the global ACL to contain carrier-specific policy; that policy belongs scoped to the NAP that uses it.

Multi-Carrier Deployment

A service provider with two or three upstream carriers and dozens of downstream customers needs scope discipline more than anything else. Each carrier gets its own NAP with its own allow-list, scoped to that carrier’s IPs only. Each customer gets its own NAP with its own allow-list, scoped to the customer’s gateway IP. The global ACL handles only the universal rules: bogon blocking, threat-feed denies, and management permits.

The benefit of this discipline shows up the first time a carrier rotates its source IPs. The change is local to one NAP, takes a single line of configuration, and cannot accidentally affect the other carriers or the customer trunks. A flat global ACL with all carrier rules in one place would require careful diffing and risks unintended changes to unrelated trunks.

Microsoft Teams Direct Routing

Teams-facing interfaces present a specific allow-list problem because Microsoft publishes the IP ranges Teams uses for signaling and media, and those ranges occasionally expand. Configure the Teams-facing NAP with a default-deny posture and permit Microsoft’s published Direct Routing IP ranges as CIDR blocks rather than individual /32 entries, so that minor changes inside a published range do not require a configuration update.

Pair the ACL with mutual TLS so that an attacker who manages to source from an allowed range still cannot complete a TLS handshake without a trusted certificate. The combination of IP allow-list and properly configured TLS and SRTP is what Microsoft expects from a production Direct Routing deployment.

MSP Multi-Tenant Deployment

A managed service provider running multiple Teams or hosted-PBX tenants on a single SBC instance needs ACL isolation between tenants. Each tenant gets its own NAP, and each NAP’s ACL permits only the tenant’s authorized endpoints (whether that is a Teams tenant boundary, a customer’s office router IP, or a CPaaS platform’s source ranges). Tenant ACLs do not share rules, so a misconfiguration in tenant A cannot loosen the perimeter for tenant B.

This is also where the per-NAP scope earns its operational keep. ProSBC supports up to 1,024 NAPs per instance, which means even a service provider with hundreds of customers can keep ACL policy strictly scoped per tenant without running into platform limits.

Remote and Work-From-Home Users

The hardest pattern. Remote softphone users come from residential ISPs with dynamic addresses, and enumerating their source IPs is impossible. The ACL on a user-facing NAP runs default-allow with a tight deny-list, and the security load shifts to SIP-layer registration authentication, rate limiting, and dynamic blacklisting.

The static ACL still does work. Block known anonymizer ranges, block cloud-hosting provider ranges that no legitimate user should ever source SIP from, and block any geography that the deployment does not serve. The dynamic blacklist catches the residual: any source that fails registration repeatedly, sends malformed messages, or scans for valid users gets added automatically. ProSBC’s SIP registration scanning protection feeds this dynamic deny-list, so a registration flood is identified and blocked before it exhausts the registrar.

Static ACLs and Dynamic Blacklisting: A Working Partnership

The static ACL expresses policy, and the dynamic blacklist expresses live response. Configuring one without the other leaves the SBC either too rigid or too reactive.

What Each One Does Best

Static rules encode the things you know in advance. Carrier IPs, Microsoft’s Teams ranges, customer gateway addresses, bogon blocks, and threat-feed denies all belong in static configuration. They change slowly, the change is deliberate, and they form the durable shape of the SBC’s policy.

Dynamic rules encode what the SBC discovers about its environment in real time. A source that sends 50 failed registrations in 10 seconds is almost certainly hostile, but no operator can write that source into a static ACL ahead of time because the source IP was unknown until the attack started. ProSBC monitors source-IP behavior continuously and adds a dynamic deny entry the moment a configured threshold is crossed.

Greylisting Between Permit and Deny

Pure permit-or-deny is sometimes too binary. ProSBC’s percentage-based greylist sits between the two: when a source crosses a soft threshold, the SBC accepts a configurable fraction of its traffic and drops the rest. The behavior is useful for two scenarios. The first is a carrier with a legitimate but unexpected spike, where outright blocking would cause an outage for real callers. The second is a suspected attacker whose traffic the operator wants to keep observing to confirm the verdict before applying a full block.

Greylisting is also the right tool when blocking by source IP would amplify the impact of source-IP spoofing. Dropping 90% of traffic from a suspected source forces the attacker to expend more resources to maintain attack volume while preserving enough sampling for the SBC’s analytics to confirm the attack signature.

The Time Horizon Question

Dynamic entries should not be permanent. An IP that was hostile last Tuesday may belong to a different host today, and a perpetual block on a recycled residential IP eventually denies service to a legitimate user. Configure dynamic blacklist entries with an expiry interval (commonly 24 hours, sometimes longer for confirmed bad actors), and let the dynamic engine reapply the block if the behavior repeats. Static blocks of confirmed-malicious infrastructure can stay permanent; dynamic blocks should age out.

Operational Pitfalls That Quietly Break Calls

The patterns above describe how ACLs should work. The list below covers the recurring ways they fail in production, usually weeks after a deployment that passed every initial test.

Overly Broad CIDR Permits

The most common configuration error is permitting a CIDR block wider than the carrier’s actual footprint. A carrier publishes signaling IPs in 198.51.100.16/28, the operator types 198.51.100.0/24, and the SBC now accepts SIP from 240 addresses the carrier does not control. A compromised host inside that range can source SIP to the SBC and the ACL will not stop it. Always permit the narrowest prefix the carrier specifies, even if writing a few extra lines.

Forgetting the Media Plane

SIP signaling and RTP media often originate from different IP ranges inside the same carrier’s network. An ACL that permits only the signaling addresses will accept INVITEs but drop the inbound RTP, producing one-way audio that is incorrectly diagnosed as a codec or NAT problem. When configuring a carrier-facing NAP, ask the carrier for both the signaling and the media source ranges and add both to the allow-list.

Missing IPv6

Plenty of carriers, cloud providers, and Microsoft Teams ranges now use IPv6 addresses. An SBC with a complete IPv4 ACL and an empty IPv6 ACL effectively runs default-allow on the IPv6 plane, which means an attacker reaching the SBC over IPv6 sails past every check intended for the IPv4 perimeter. Mirror every IPv4 rule in IPv6 wherever the corresponding range exists.

NATed Source IPs From Customer Networks

When a customer sits behind a NAT, every endpoint inside the customer network presents the same public source IP to the SBC. Allow-listing the NAT IP works for legitimate traffic but does nothing to distinguish individual endpoints, so any compromise inside the customer’s network appears to come from a permitted source. This is a limitation to plan for rather than a bug to fix; the ACL has to be paired with strong SIP-layer authentication for customers behind NAT, and rate limits per source IP should be set with awareness that one IP may represent many users.

Misordering Rules in Top-Down Engines

ProSBC’s BlackWhiteListing module uses longest-prefix matching, so rule order is independent of rule precedence. Many other SBCs evaluate ACL rules top-down, where the first matching rule wins. On those platforms, a broad permit at the top of the list silently overrides a narrow deny further down. If migrating from a top-down ACL engine to a longest-prefix engine, or vice versa, audit every rule for ordering assumptions before promoting the configuration to production.

Stale Dynamic Entries

Dynamic blacklist entries that were added six months ago for IPs that have since changed hands are a slow-growing source of false positives. The SBC’s CDR shows nothing wrong; the customer just complains that calls from a partner keep failing. Periodic review of the dynamic deny-list, with attention to entries older than the configured expiry, prevents this class of incident. The same drift affects permit rules in reverse, and combining ACL hit-counter review with routine VoIP monitoring catches both shapes of decay before they surface as customer complaints.

ACL Changes Without Hit-Counter Verification

Adding a permit rule and assuming it works is not the same as confirming it works. After any ACL change, watch the rule’s hit counter to verify that legitimate traffic is actually matching the new rule rather than being silently dropped by something earlier in the chain. A change that looks correct on paper but never registers a hit is almost certainly being shadowed by a global rule or an interface-level rule that the operator forgot about.

Maintaining ACLs in Production

An SBC’s ACL configuration drifts. Carriers rotate IPs, customers move offices, partners are acquired, and threat-feed entries age out. Treating ACL maintenance as a periodic operational activity (rather than something that happens only when calls break) is what separates a stable production SBC from one that limps from incident to incident.

Audit Cadence

A quarterly audit is sufficient for most deployments. The review covers every permit rule (does the source still exist, is the prefix still correct, is the rule still needed), every deny rule (is the source still hostile, has the threat-feed entry expired), and every dynamic entry that has persisted longer than expected. The output is a short change set that gets reviewed and applied in the next maintenance window.

Higher-traffic SBCs benefit from monthly audits. Smaller deployments serving stable peer sets can stretch to semi-annual. The right frequency is governed by how often the peer set actually changes, not by how often the calendar reminds the operator.

Change Windows and Rollback

ACL changes are the kind of change that should always have a documented rollback. A permit rule that should have allowed traffic but did not is harmless once reverted; a deny rule that accidentally cuts off a carrier is an outage that costs minutes per call. Apply changes during a maintenance window, watch the hit counters in real time, and revert immediately if traffic patterns do not look as expected.

Logging No-Match Events

A no-match log captures every packet that was dropped because no rule permitted it. On a busy SBC, this log is large and noisy, but it is the primary signal for two things: an attacker who is probing the perimeter, and a legitimate peer whose source IP has changed without notice. Sampling the no-match log periodically (or alerting on no-match volume from any single source crossing a threshold) catches both cases before they become tickets.

Hit Counters as a Health Signal

A permit rule that has not registered a hit in 30 days is either obsolete or shadowed. Either way, the rule should be flagged for review. Most production SBCs let you sort rules by last-hit timestamp; running that report monthly is a low-effort way to keep the ACL from collecting dead rules. Stale rules are not just clutter, they are surface area; every rule that exists is a potential exception that an attacker could maneuver into.

Documentation Alongside the Configuration

The ACL on a production SBC is read by the next operator long after the original author has moved on. Every non-obvious rule needs a comment that records why it exists, who authorized it, and when it should be reviewed. ProSBC’s web interface supports comments on most rule types; the comment field is one of the most underused features in voice infrastructure operations.

Frequently Asked Questions

Conclusion

An SBC’s access control list is the simplest, cheapest, and most important security check it makes. Configured well, it drops the background noise of internet-sourced SIP scanning before that noise consumes a cycle of CPU. Configured poorly, it either lets attackers reach the SIP parser unimpeded or silently breaks calls from legitimate peers whose source IPs nobody remembered to add.

The recurring themes are scope discipline, posture-per-interface, and the partnership between static and dynamic rules. Universal rules belong in the global scope. Peer-specific rules belong in the per-NAP scope. Default deny is the right posture wherever the peer set can be enumerated, and default allow paired with strong authentication is the fallback for cases where it cannot. Static rules express policy that is known in advance, and dynamic rules respond to behavior that only becomes visible at runtime. The two complement each other; neither one is sufficient on its own.

Treat the ACL as a living configuration. Audit it on a cadence, watch the hit counters, document the rationale beside the rules, and let the dynamic engine carry the load that the static configuration cannot anticipate.