Cisco Expressways and my Toll Fraud battle

Due to the recent COVID-19 pandemic, many businesses have suddenly and urgently rushed to implement Cisco Expressways for Mobile and Remote Access (MRA) so that end users may 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 apparently 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 VM, configuring the 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 still worked out but will be changed soon enough (hurray) and all of the fun configurations for my expressways.

For those of you who don’t know, Cisco Expressways work like this. From your mobile phone on a different network than your expressways (so your mobile data or home wifi) you download the Cisco Jabber app and log in with your work email. When you do that, Jabber on your phone will do a DNS lookup on your domain name, for which you have an SRV record set up for _collab-edge.yourdomain.com that points towards 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 trunk through to the Expressway-C. (C stands for Core because it’s 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 trunks is called a “zone” in the expressways. So the entire process looks about like this:

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 one for everyone spinning this stuff up 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 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 agreements, these phone bills must be paid even if they are fraudulent.

If you set up your system properly, your CUCM will shut down any fraudulent call attempts so you won’t have this problem, BUT, we don’t even want this traffic to make it into our network, so lets shut it down at the port of entry, right? So let’s take a look at how we can deny entry to these unwanted phone calls.

Taking a look at my call history, I see a LOT of potential Toll Fraud going on, even now after implementing my toll fraud protection, they are still trying constantly.

Notice the destination is making every attempt to get a call through, mostly to the same number but with variances to try to get through. The source is almost always the same, but they will try something different from time to time.

To combat this, and to ensure proper routing of calls, Cisco has given us a few tools for modifying incoming requests.

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

But before we begin, lets make sure to brush up on our regular expressions. Regex, as it’s called, is a method of creating patterns that can capture text that is as specific or as generalized as the person writing wants it to be. There are several sources online to help you learn regex, but here are what I personally use(d)

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

Another great resource, this time for writing and testing patterns, is http://www.regex101.com

When installing your expressways, you will need to implement transform rules, call policies, and search rules, but for the toll fraud, we are going to focus in on call policies. (We’ve covered a lot getting to this point, so kudo’s to you if you’ve stuck in this far)

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 this rule. The best practice is rather than trying to filter out everything we DON’T want, let’s instead just filter out everything and then allow what we DO want. This will be much simpler.

So let’s create this rule first:

This rule says, by looking at the From address in the SIP header, and if the call is unathenticated, with a Source pattern of ANY (.* in regex) and a Destination pattern of ANY (.*) we want to reject the call.

This will be our most protective rule because it will filter out ALL unathenticated calls. Call Policy Rules are ordered, so when you click on the Rules page, whichever appears first will be applied first, and whichever appears last will be applied last. So let’s make sure we apply this “implicit deny”, if you will, last, in the same manner we would with an ACL.

But wait… there are some unauthenticated calls we will want to allow… and perhaps even some authenticated calls we want to disallow.

Lets start with internal calls coming from CUCM and headed out to the internet. Since this isn’t taking a toll path, I want to allow ANY calls going outbound to go through. But how do I tell it to only look at outbound calls? Well, I could say From address again, and then create a regex pattern to match my internal dial plan… But that would be a bit tricky, so instead, let’s do this rule Source type as Zone.

So if the call is coming in via my Expressway Traversal Zone, meaning the call is originating from my Expressway-C or beyond, then I simply want to allow the call through.

This rule says that from Source type Zon, specifying my Expressway Traversal Zone, and with a Destination pattern of ANY (.*), I want to allow the traffic.

Good, now we are allowing all outbound traffic and denying all unauthenticated inbound traffic. This is good, this is good… but… well, perhaps I need more rules.

I want to allow inbound SIP calls if I have B2B enabled on my expressway… So let’s apply a Rule that allows any calls to come in if they are directed at one of my extensions (we could also apply this to names if we wanted).

Here we are saying that Source type being the From address, of Unathenticated callers, with ANY (.*) source address, if they are directed at one of my internal 4 digit extensions (\d{4}) at (@) mydomain.com, we want to allow the call.

Finally, one more rule we want to create, and that is to allow authenticated calls, being our Jabber MRA calls.

We could be as simple as a From address with authenticated callers, with a source pattern of .* and a destination pattern of .* and allow the calls, but if we want to be especially secure, we will be a bit more specific in how our source pattern is defined. Since calls technically are going outbound, we want to specify in the source pattern our CUCM IP addresses to allow those calls through.

For security reasons I’m not going to take this screenshot and the image would be useless without that part, but I do want to give you an idea of what this would look like.

^(.*@(192.168.1.1|192.168.1.2))|((^[a-z]{2,7})@mydomain.com)$

To break this down a bit:

^ = start of the pattern
( ) = a grouping of a pattern that can be later referred to with a \# (replace # with a 1 for the first group in the pattern, a 2 for the second group in the pattern, and so on)
. = any character
* = zero or any repetition of the previous character
@ = a literal @ symbol
| = or
[a-z] = any alphabetical character
{4,10} = the previous character (in this case any alphabetical character), between 2 and 7 characters long
$ = end of the pattern

Since this is a call policy rule, and we won’t be referencing it later, realistically we could remove some of the parenthesis and the start and end patterns without harm to make it look more like this:

.*@(192.168.1.1|192.168.1.2)|(^[a-z]{2,7})@mydomain.com

You may need more, or potentially even less, call policy rules, but you will definitely want to have, at a minimum, the reject all unauthenticated calls policy.

Shoutout to the Ciscoshizzle blog for publishing this information. Without that blog, I would have wasted a lot more time trying to figure this out.

Leave a Reply

Your email address will not be published. Required fields are marked *