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.
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-peer voice 11 pots
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 1731 (MSICCP)
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.