How to prevent toll fraud on Cisco Gateways.

Recently I experienced an issue with a customer that had their long distance carrier shut the service down .  The reason why was that they were showing an excessively large amount of long distance calls made to various African countries as well as Cuba.   

Click to open PDF

The customer is using a Call Manager Business Edition which puts the Call Manger and Unity on the same 7800 server.

The way the problem was presented to us suggested that these calls may have been made internally (it’s my experience that someone on the cleaning crew could be making these calls) which can be easily and quickly identify, all we need to do is look for a pattern when the calls were made, time, day and extension.

Most the time internal fraud calls like theses are made from an open fax machine that has a headset attached to it.  Sometimes Fax lines may be configured to go straight to the gateway on an FXS port; relying on whatever the dial peerforward-digits 7that port is configure to.   Of course this type of configuration bypasses the CM and its logging, dial restriction ability.    Other times the fax line can be set to go into the CM and required to follow what every the dial restrictions are set to.

dial-peers configured
dial-peer voice 11 pots
destination-pattern 9[2-9]……
port 0/2/0:23

Dial Restrictions

Dial Restrictions

The CM log showed unauthorized long distance calls made from the VM extension.    But how was this possible?    CM and Unity normally run independent of one of another, however the business edition is BOTH ran on the same sever.   Which is fine; once a call enters Unity it out of CM’s hands, but if call can somehow be rerouted back to CM, CM can and will forward to call to the outside.

Cisco said that there are rare instances when someone can make a long distance call from VM if they can manipulate an extension into reaching a dial tone.  A lot of variables have to be met before this can happen as well as the person needs to have a working knowledge of how CME and Unity works.  I’ve even heard of people forwarding lines to an outside line.

This can all be fixed with a few minor adjustments on the dial restrictions.

With the dial restrictions in place, we waited…   after 56 days the customer called back to say they were being hit again with toll frauds.    This time, the CM logs reported NOTHING, nada; there were NO forwarded calls from the VM.    They found another way out…   The only item left was the gateway, a Cisco 2821

First thing I check was the dial-peers, I went through each one and found **ADD250X250** no issues at all… but I did notice that this customer did not have a basic access-list to block various ports.  Further investigation showed a lack of an access-list.  I explained to the customer a lack of an access-list can and will allow unauthorized connection to the gateway and make long distance calls; I proved this with a program call XLTE , with this I was able to connect to the gateway using sip and make a call.

This was resolved with the access-list below and applied to the internet connection.

Extended IP access list 101
access-list 101 deny udp any any eq 2427 log
access-list 101 deny tcp any any eq 2428 log
access-list 101 deny tcp any any range 1718 1720 log
access-list 101 deny tcp any any eq 1731 log
access-list 101 deny tcp any any eq 2000 log
access-list 101 deny tcp any any eq 5060 log
access-list 101 deny udp any any eq 5060 log
access-list 101 permit ip any any

Next we apply this to our interface with the following command.

ip access-group 101 in

We have “log” at each end so we can keep track of what protocols are being hit from the outside.  It’s been my experience that you will large amount of hits on 5060 TCP/UDP due to the fact the port belongs to SIP, which a common open standard VOIP protocol that most vendors support.

UDP 2427 (MGCP)
TCP 2428 l (MGCP)
TCP 1718 1720 (H323)
TCP 2000 (SCCP) SKiNNY  Cisco
TCP 5060 (SIP)
UDP 5060 (SIP)

It’s been several months now and there have NOT been any toll fraud issues reported.  A simple access-list like the one above helped elevate this common mistake.

4 thoughts on “How to prevent toll fraud on Cisco Gateways.

  1. The only way to prevent dial through fraud is to place a SecureLogix Voice FW on the PSTN connection. The issue is that PBX’s, Gateways, VoiceMail systems, IVR,s modems, faxes, Dialers, Call Center Suites of all vintages, makes and models, IP or TDM as well as the carrier do not tell the enterprise what the wireline attributes of the individual calls are. Sure…they have databases but those cannot enforce policy and at best are rarely updated properly. Trust nothing is what we go by. You need attribute identification to build policies that give real time visibility and control into the “PSTN Edge”. We identify attributes such as Call Type(is that a modem, fax, human voice, STU, wideband video, Modem energy etc. As well as source, destination, time of day, direction, action, etc. Very similar to a packet only FW. Once attributes are collected they can then fill out the various security and enforcement policies(FW, IPS/Fraud prevention, Usage manager, performance Manager, Policy based call recording) Dial through fraud is a multi-billon $ global issue. In some cases is actually tied to funding terrorist activities. We have 15 patents granted in this space and sit on more than 4 million lines. Many marquis enterprises and Federal Agencies depend on us. We are a Cisco Development Parter, A member of the Cisco SmartGrid Ecoystem as well as a feature in their channel programs.

  2. Joe thanks for your comment.

    You are absolutely correct that a Voice FW would be a better solution, however most “mom and pop shops” or even slight larger offices may not have that option in their budget. It’s sad but true that allot of these are poorly misconfigued and throw up onto net with the notion if it works, leave it.

    Security does not become an issue until they are exposed, granted a simple access list will not protect you entirety but it will keep an honest person honest. Think of putting a lock on a door, if someone really wants to get in they will.

    In summary any major corporation or government agency worth their salt is going have an elaborate security policy in place. Whether is be voice, data or physical.

Leave a Reply to Ron Staples Cancel reply

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