Cisco Expressways and my Toll Fraud battle

Due to the COVID-19 pandemic, many businesses suddenly and urgently rushed to implement Cisco Expressways for Mobile and Remote Access (MRA) so that end users could use their home PC, iPhone, Android phone, or iPad as their work phone to work from home.

My employer was no different. Suddenly it became apparent that this infrastructure was needed, and rather than taking months to prepare, plan, and deploy, I needed it up and running yesterday. Over the span of about a week and a half I worked constantly to deploy Expressways in our enterprise—deploying the VMs, configuring public and private DNS, public server certificates (which for me was the worst part), an odd single-NIC hairpin solution for my Expressway-E (which isn’t best practice, but was necessary for what I was trying to accomplish and will be changed soon enough), and all of the configurations for our Expressway pair.

For those of you who don’t know, Cisco Expressways work like this: from your mobile phone on a different network than your Expressways (such as mobile data or home Wi-Fi), you download the Cisco Jabber app and log in with your work email. When you do that, Jabber on your phone performs a DNS lookup on your domain name, for which you have an SRV record set up for _collab-edge._tls.yourdomain.com that points toward your Expressway-E (expe.yourdomain.com—E stands for Edge because it lives on the edge of your network).

The Expressway-E receives this request and traverses your firewall via a SIP traversal trunk through to the Expressway-C (C stands for Core because it lives in your core network).

From the Expressway-C, the message is passed on to your CUCM for verification, before the process is done again in reverse.

Each of these SIP connections is called a Zone in the Expressways. The end-to-end call and registration flow looks like this:

[Remote Jabber Client]
        │  DNS SRV (_collab-edge._tls.yourdomain.com)
        ▼
[Expressway-E (DMZ Edge)]
        │  Traversal Zone (Firewall Traversal)
        ▼
[Expressway-C (Internal Core)]
        │  CUCM Zone (SIP / UDS)
        ▼
[Cisco Unified CM Cluster]

To the point of the post

Oh yes, I went off topic before I even got on the topic: TOLL FRAUD!

This is a huge priority for everyone spinning up edge voice infrastructure because if you don’t protect against toll fraud, you’re going to have a HUGE phone bill. There are many international companies that charge high tolls on their phone lines. They offer fraudsters a percentage of their earnings if the fraudster can generate fraudulent phone calls through other companies’ phone lines. Because of international carrier agreements, these phone bills often must be paid even if they are fraudulent.

If you set up your system properly, your CUCM Calling Search Spaces and Partitions will shut down fraudulent call attempts so they cannot hairpin out to the PSTN—BUT we don’t even want this probing traffic to make it into our network, so let’s shut it down at the port of entry. Let’s take a look at how we can deny entry to these unwanted phone calls on the Expressway.

Taking a look at call history on an internet-facing Expressway-E, you will see a LOT of attempted toll fraud scanning—even after implementing toll fraud protection, automated scanners keep trying constantly with different international dial prefixes (011..., 00..., 9011...).

To combat this, and to ensure proper routing of calls, Cisco gives us three main tools for controlling and modifying requests:

1. Transform Rules
2. Call Policies
3. Search Rules

Before we begin, let’s make sure to brush up on our regular expressions (regex). Regex is a method of creating patterns that can capture text as specific or as generalized as you want it to be. Two great resources I personally use:

• Derek Banas created a regex tutorial series on YouTube that is short and easy to understand: https://www.youtube.com/watch?v=DRR9fOXkfRE&list=PLFA4F2FDD28D0C40E
• For writing and testing patterns interactively: https://regex101.com

When installing your Expressways, you will implement transform rules, call policies, and search rules, but for toll fraud prevention, we are going to focus on Call Policies (also known as Call Policy Language / CPL).

Configuring Local CPL Call Policy Rules

Navigate to Configuration > Call Policy > Configuration and set your Call Policy mode to Local CPL.

Now navigate to Configuration > Call Policy > Rules and click on the New button.

The first thing we need to determine is how we want to apply our rules. Best practice is: rather than trying to blacklist every international prefix we don’t want, let’s instead reject everything by default and explicitly allow only what we do want.

Rule 1 (Bottom Rule): The Implicit Deny for Unauthenticated Calls

Let’s create our baseline reject rule first:

Field	Value
Source type	From address
Caller authentication	Unauthenticated callers
Source pattern	.*
Destination pattern	.*
Action	Reject

Configuration Note: By looking at the From address in the SIP header, if the call is unauthenticated with a Source pattern of ANY (.* in regex) and a Destination pattern of ANY (.*), we Reject the call.

This will be our most protective rule because it filters out ALL unauthenticated calls. Call Policy Rules are evaluated in order from top to bottom, so let’s make sure we place this “implicit deny” rule last in the list, in the same manner we would with a firewall ACL.

Rule 2: Allow Outbound Calls from Internal Zones

What about internal calls coming from CUCM and headed out to the internet (such as B2B video calls)? Since this isn’t taking an inbound toll path, we want to allow calls originating from inside our network to go through. Rather than matching From addresses against our internal dial plan, we can set Source type to Zone.

If the call is coming in via our Expressway Traversal Zone (meaning the call originated from Expressway-C / CUCM), we allow the call through:

Field	Value
Source type	Zone
Zone	Expressway Traversal Zone
Caller authentication	All callers
Destination pattern	.*
Action	Allow

Rule 3: Allow Inbound B2B Calls to Valid Internal Extensions Only

If you have Business-to-Business (B2B) SIP calling enabled on your Expressway, you can add a rule above the implicit deny that only allows unauthenticated inbound calls if the destination explicitly matches your internal 4-digit extension range at your domain:

Field	Value
Source type	From address
Caller authentication	Unauthenticated callers
Source pattern	.*
Destination pattern	\d{4}@mydomain\.com
Action	Allow

Rule 4: Allow Authenticated Jabber MRA Calls

Finally, we want to allow authenticated calls—which are our remote Jabber MRA users.

We could simply match From address for Authenticated callers with a source pattern of .* and a destination pattern of .*, or if we want to be even more specific in how our source pattern is defined, we can explicitly match our CUCM node IP addresses or Jabber user IDs:

^(.*@(192\.168\.1\.1|192\.168\.1\.2))|(([a-z]{2,7})@mydomain\.com)$

To break this regex down:

• ^ = start of the pattern
• ( ) = a grouping of a pattern that can be referenced later with \1, \2, etc.
• . = any character
• * = zero or more repetitions of the previous character
• @ = a literal @ symbol
• | = logical OR
• [a-z] = any lowercase alphabetical character
• {2,7} = between 2 and 7 repetitions of the previous character class
• $ = end of the pattern

Since this is a Call Policy match rule and we won’t be referencing capture groups in a replacement string, we can simplify it to:

.*@(192\.168\.1\.1|192\.168\.1\.2)|^[a-z]{2,7}@mydomain\.com

You may need more (or fewer) Call Policy rules depending on your B2B requirements, but at a minimum, every internet-facing Expressway deployment should enforce the reject all unauthenticated calls policy at the bottom of its Local CPL rule table.

Shoutout to the Ciscoshizzle blog for publishing great hardening notes on VCS/Expressway.