Use Classification Rules (Instead of Proxy Sets) on AudioCodes SBCs

Introduction

Admittedly, this title is misleading, but it did get you to look at this article! This is part of our series on securing AudioCodes SBCs based on eGroup | Enabling Technologies’ security mantra of “Trust No One, Harden Everything” and guidance provided by AudioCodes.

A “basic” class on configuring an AudioCodes SBC shows how to populate Proxy Sets with the IP addresses or Fully Qualified Domain Names (FQDNs) of a SIP service’s endpoints that need to communicate with an SBC, or which an SBC needs to communicate with. If a SIP Trunk vendor provided you with two (2) SIP signaling IP addresses, you would add them to the SIP Trunk Proxy Set on your SBC. The Proxy Set would have been paired with a SIP Interface on your SBC and associated with an IP Group. The problem with this configuration is that it allows traffic to enter your SBC based only on two (2) criteria:

1. The SIP Interface
2. Matching on the IP address of an endpoint

If you have a SIP Trunk running “over the internet,” bad actors can spoof their source IP address with one of these addresses and gain access to your SBC.

• In a previous article in this series, we went over how to setup the firewall built into the AudioCodes SBC, the firewall will not block a spoofed source IP address!
• In another article, we talked about the rules you need to configure on your organizational internet firewall, these rules won’t block this type of activity either!

AudioCodes recommends the use of strict Classification rules to manage the ingress of traffic into SBCs. This guidance for using Classification rules can be found in their security guidelines documents for SBCs and Gateways, referenced at the end of this article.

Classification rules are not a replacement for Proxy Sets, they are an addition that increases the security footing of the SBC. In most cases, you will still have to populate Proxy Sets with the provided IP addresses or FQDNs of the SIP service provider. Besides associating incoming traffic to an IP Group, the addresses in the Proxy Set are used to route traffic from the SBC to the SIP service provider. The Classification rules replace the Proxy Sets function of mapping incoming traffic to IP Groups.

How an SBC Manages Inbound Traffic

The SBC will try to Classify inbound traffic. Classification determines:

• Whether to allow the traffic into the SBC.
• Which IP Group the traffic should be associated with. The associated IP Group will be designated as the Source IP Group for the call.

Before the SBC begins the Classification process, the traffic must get past the SBC’s first line of defense, the firewall rules. Once the traffic is permitted, the “Network Interface” it arrived on and the appropriate “SIP Interface” is determined. The SBC can then begin the Classification process:

1. The information in the header of the SIP INVITE is checked to see if it is coming from a user or server Agent. SIP soft and hard phones are examples of user agents. If the INVITE came from a user agent, the Classification system will determine if it is in the User Registration Database on the SBC. If it is, the call will be Classified to the defined Source IP Group. User Registration will be covered in a future article.
2. If the INVITE did not come from a user agent (in this case, it will have come from a server agent):
   • The SBC will determine if the Source IP address in the SIP INVITE is a member of any of the SBC’s Proxy Sets.
   • If it finds the address in a Proxy Set, the SBC will try to find the IP Group associated with the Proxy Set.
   • If it finds an IP Group that has the setting “Classify By Proxy Set” set to “Enable,” the SBC will associate the SIP INVITE with this IP Group and will designate it as the Source IP Group for the call.
3. **At this point, the SIP INVITE has been classified based on the Network and SIP Interface it came in on and the Source IP address or Source FQDN.
4. If the SIP INVITE cannot be Classified by Proxy Set:
   • The SBC will start to evaluate the information in the SIP INVITE against the defined Classification rules and their criteria.
   • If the SBC INVITE matches a rule’s criteria, the rule will either “Allow” or “Block” the traffic. Allowed traffic will be associated with the IP Group defined in the rule.
   • Once a rule is matched, the Classification process ends, remaining rules are not evaluated.
5. If the SIP INVITE still cannot be Classified:
   • The SBC will treat the SIP INVITE as “Unclassified.”

By default, the SBC will associate the SIP INVITE with the first IP Group in the IP Groups table and the traffic will be allowed to come into the SBC.

Cloud platforms are always up to date and there is always constant improvement to these platforms. No more risky (and expensive) stair-step upgrades. The cloud provides predictable costing for both licensing and the effort required to manage and maintain the platform. Depending on the need, cloud-based virtual desktops can even eliminate much of the capital expenditures for workstations, plus they add some security and manageability features.

Speaking of security (I know, there it is again), modern and cloud-driven security platforms are a match for the threats that exist today, and these platforms are constantly improving. Beyond endpoint protection and automated response, platforms like Azure Active Directory, Defender for Cloud Apps, and Sentinel allow you to continually monitor and maintain a vastly improved security posture.

Your compliance program gets easier, too. Microsoft Purview provides robust compliance features like retention, data labeling, DLP, and insider risk detection. Purview also evolves as the rest of the Microsoft 365 cloud solutions do and can replace third-party products point solutions that require upgrades, maintenance and separate alerting and management processes.

The legacy PBX can be replaced by Teams Voice, and Teams is natively connected into the security stack and Purview to provide a one-stop shop for collaboration and interoperability with SharePoint, OneDrive, and third-party SaaS systems. Plus, storage stops requiring so much separate effort since it is included and managed alongside the cloud services.

Automation and development with Power Apps are also available and can help get those manual processes that live in people’s heads (and 7 linked spreadsheets) documented and implemented as applications that people can simply use, and not manage.

Proxy Set Call Flow — Classification by Proxy Set

1. A SIP Invite is sent from the SIP Trunk Vendor’s SIP Signaling Address, 67.67.67.67 (or 67.67.70.68) to the Public IP address provided by the client, 170.45.68.22 over port 5060/UDP.
2. The organizational firewall’s rules permit the traffic and routes it to the GE_2 Physical Interface on the SBC using the NATted IP of 192.168.30.2.
3. The SBC’s firewall allows the traffic and determines the traffic arrived on the “SIP TRUNK” Network Interface.
4. Based on the Network Interface the traffic arrived on and that it is using port 5060/UDP, the SBC determines the traffic is on the “SIP TRUNK” SIP Interface.
5. Since:
   • The SIP Interface is “SIP Trunk.”
   • The Source IP address is 67.67.67.67.
   • “Classify by Proxy Set” is enabled for the “SIP TRUNK” Proxy Set.
   • The “SIP TRUNK” Proxy Set is associated with the “SIP TRUNK” IP Group.
   • The SBC permits the traffic to enter the SBC and defines its Source IP Group as “SIP TRUNK.” Using Classification Rules for Inbound Traffic

SIP service providers will let you know the IP addresses or FQDNS you should use to reach their service. It is usually one or the other. Microsoft Teams is the best-known example of a SIP service that provides both addresses and FQDNs.

The Golden Rules1. Use Classification rules if you are given IP addresses by the service provider. If you are only given FQDNs, you cannot use Classification rules and must use “Classify by Proxy Set” for the SIP service. If you are given both, you should use Classification rules. 2. Configure the SBC to reject unclassified calls. 3. Apply strict criteria to Classification rules. The criteria should be as strict and specific as possible. Avoid using wildcards or “Any” values in the criteria. 4. The order of the rules in the table is significant. Configuring Classification RulesRules must be assigned to an SRD. From the previous articles, we know that SBCs with only a default SRD are most common. When you create a new rule, the “defaultSRD” will already be populated in the “SRD” field.

Matching CriteriaEach rule has a “Match” and “Action” component. The “Match” side specifies the criteria for the rule and the “Action” side has what should happen if the rule is matched.

There are nine (9) types of criteria that can be matched:

Rule ActionsThere are six (6) fields on the “Action” side of the rule. Only three (3) are commonly used.

IP Group SettingsChange the configuration of the IP Groups (Setup > Signaling & Media > Core Entities > IP Groups) that will use Classification Rules. The “Validate Source IP” parameter should be available in the Long-Term Support release of the 7.40 firmware for the AudioCodes SBCs.

1. In the “SBC General” section, set the value of “Classify By Proxy Set” to “Disable.”

2. Set “Validate Source IP” to “Enable.” SBC General SettingsThis setting rejects inbound SIP INVITES that cannot be Classified. This replaces the default behavior of routing the unclassified calls to the first IP Group on the SBC.

3. Click on “Setup.”

4. Click on “Signaling & Media.”
5. Click on “SBC.”
6. Click on “SBC General Settings.”
7. Change the value of “Unclassified Calls” to “Reject.”
8. Click the “Apply” button.
9. Then click on “Save” and click “Yes.” Example – Classification Rules for Teams Direct RoutingThe AudioCodes configuration guides for Teams Direct Routing include eight (8) Classification rules for Microsoft 365, Office 365 and GCC tenants.

The rules for DOD and GCC High tenants can be found in a previous blog post UPDATE! AudioCodes SBC Configuration Update for Teams Direct Routing.

Classification Rules for SIP Services that use Sub-netted IP Address Ranges

The Teams Direct Routing documentation from Microsoft for Microsoft 365, Office 365 and GCC environments states that there are three (3) FQDNs that a Teams Direct Routing SBC needs to communicate with:

1. pstnhub.microsoft.com
2. pstnhub.microsoft.com
3. pstnhub.microsoft.com

These FQDNs will resolve to IP addresses in these ranges:

1. 112.0.0/14: Available addresses – 52.112.0.1 to 52.115.255.254
2. 120.0.0/14: Available addresses – 52.120.0.1 to 52.123.255.254

As mentioned earlier, the Classification rules do not provide a way for a subnet mask to be applied to the Source IP address in the rule. The Source IP does permit the use of wildcards for one or more of the address’s octets. If we were to create two (2) Classification rules with 52.112.. and 52.120.. as the Source IP addresses, the rules would match traffic coming from these IP address ranges:

1. 112.0.1 to 52.112.255.254
2. 120.0.1 to 52.120.255.254

These ranges do not match those specified by Microsoft. To cover the Microsoft ranges, we need to create individual rules for each of the subnets in 52.112.0.0/14 and 52.120.0.0/14. It is important to note this in case you need to create Classification rules for other SIP services that use similar IP addressing.

Explanation of the Supported Classification Rules for Teams Direct RoutingThe rules provided by AudioCodes use four (4) of the matching rules to create the criteria for matching inbound traffic from Microsoft Teams.

A match will happen if an inbound SIP INVITE:

1. Arrives via the “Teams” SIP Interface
2. And the “Source IP Address” is between 52.112.0.1 and 52.112.255.254
3. And the “Destination Host” matches the Public FQDN of the SBC’s Teams interface
4. And the criteria of the “Message Condition” rule named “Teams-Contact” are met

On a match, the “Action” configured for the rule will be executed. In this case, the SIP INVITE will be marked as having a Source IP Group of “Teams” for the duration of the call.

Message Condition RulesYou can create up to 1,200 Message Condition rules on an SBC. The rules define special criteria for incoming SIP messages. They use the same syntax as Message Manipulation rules. Each Classification rule allows you to associate a single Message Condition rule. If you want to match multiple criteria, you can use the “and” and “or” constructs in the rule. You can also create separate Message Condition rules and associate them with separate identical Classification rules, except for the Message Condition rule.

The “Teams-Contact” Message Condition rule will be matched if an incoming SIP INVITE has ‘pstnhub.microsoft.com’ in the host part of the “contact” field URL in the header.

To create the rule:

1. Click on “Setup.”
2. Click on “Signaling & Media.”
3. Click on “Message Manipulation.”
4. Click on “Message Condition Rules.”
5. Type in “Teams-Contact” in the “Name” field.
6. Type, or click the “Editor” button, “header.contact.url.host contains ‘pstnhub.microsoft.com’ in the “Condition” field.
7. Click the “Apply” button.
8. Click the “Save” button then the “Yes” button when prompted. Hardening the Teams Direct Routing Classification Rule

Before changing the Teams Classification rule on an SBC, keep in mind that the configuration of these rules has been set out by AudioCodes. It can be implied that these settings reflect the AudioCodes supported configuration of the SBC. Changing these rules may adversely affect the ability of the SBC to route inbound SIP INVITEs from Microsoft Teams. Keeping this in mind, there is room to carefully add additional criteria to these rules.

Following are suggested additional criteria that can be added to the Teams Classification rules:

There is another way to configure your Classification rules to match multiple different DID ranges that you might have. This involves using Dial Plans, Tags and Call Setup rules. Details for this are beyond the scope of this article. Please contact us if you are interested in using your DID ranges as a criterion in your Classification rules.

Final Notes

• If you get FQDNS as the SIP Signaling addresses from the SIP service provider:
  • Add each FQDN as a member of the SIP Trunk’s Proxy Set.
  • Configure the associated IP Group with the “Classify by Proxy Set” and “Validate Source IP” parameters set to “Enable”.
• Always specify a “SIP Interface” in your Classification rules. Leaving the default “Any” value in the field can allow unintended traffic to be routed by the SBC.
• The order of the Classification rules is significant. The rules are evaluated from the top down. Organize the rules for each SIP Interface consecutively. Put the rules for the “Teams” SIP Interface first followed by the rules for the “SIP Trunk” SIP Interface, etc.

• Some tips for SIP Trunk Classification rules:

  • Most of the time, the SIP Trunk vendor will provide IP addresses for SIP Signaling.
  • If they provide two (2) or more IP addresses, you will need two (2) or more Classification rules.
  • You may be able to create a Message Condition rule like the “Teams-Contact” rule. This will depend on what the SIP Trunk vendor includes in the header of the SIP INVITE.
  • All calls routed to your SBC from a SIP Trunk vendor will have a Destination Number that falls within one of your DID ranges. You can match your DID ranges in the “Destination Username Pattern” field of the Classification rule to increase the strictness of your rules.
  • Remember to add rule(s) for the SIP Trunk to the AudioCodes firewall. Summary

• AudioCodes’ SBC security guidance recommends that Classification rules be used to control the admittance of inbound traffic to the SBC.

• Classification rules should be used when the SIP service provider uses IP addresses to refer to the SIP Signaling ports the SBC should communicate with.
• If the SIP service provider uses FQDNs, Classification rules should not be used for that SIP service. The FQDNs should be added to the Proxy Set for the SIP service and the associated IP Group should be configured to classify it’s inbound traffic by Proxy Set.
• The SBC should be configured to reject unclassified calls.
• Apply strict criteria to Classification rules. The criteria should be as strict and specific as possible. Avoid using wildcards or “Any” values in the criteria.
• There should be a specific SIP Interface in every Classification rule. Do not create a rule that will work with “Any” SIP Interface.
• Test your rules before putting them into production. You can leverage the Source or Destination Username pattern fields to limit their application during testing to specific Source or Destination phone numbers.

eGroup | Enabling Technologies is available and ready to answer any questions that you might have about SBC hardening and security as well as overall security for your enterprise. If you need help in implementing a security infrastructure for your organization, please contact us!

Bibliography

AudioCodes has written two (2) documents addressing security on their Session Border Controllers and Gateways. There are separate versions for the 7.2 and 7.4:

• SBC-Gateway Recommended Security Guidelines Ver. 7.2
• SBC-Gateway Recommended Security Guidelines Ver. 7.4

The AudioCodes Teams Direct Routing Configuration guides contain the configuration steps for interfacing an AudioCodes SBC to Teams Direct Routing. These guides apply to both firmware versions 7.2 and 7.4:

• Connecting AudioCodes’ SBC to Microsoft Teams Direct Routing Enterprise Model Configuration Note
• Connecting AudioCodes SBC to Microsoft Teams Direct Routing Hosting Model Configuration Note
• Mediant SBC to Microsoft Teams Direct Routing with Local Media Optimization

The AudioCodes SBC hardware installation and user manuals can also be found in the Library section of the AudioCodes website.

John MillerCloud Solutions Architect - eGroup | Enabling Technologies

The post Use Classification Rules (Instead of Proxy Sets) on AudioCodes SBCs appeared first on eGroup.