How to prevent toll fraud on Cisco Gateways.

Link

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 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.

rstaples@configbytes.com www.configbytes.com

Goodbye to Microsoft Windows 2000

July 13 2010 marks the end of Microsoft’s extended support for Windows 2000

I’m sad to see it go, it’s my opinion that Windows 2000 was probably one of the most stable OS’s that Microsoft put out.  I rarely had any issues running it and I know that a lot of businesses were still using the OS, it does a great job of getting basic internet tasks done.

Windows 2000We seen several services packs released over years for Windows 2000, service pack 1 gave us IPV6 support which was easily enable with the net start tcpipv6 command.   Service pack 2 gave us DX 9c and 128-bit encryption, SP 3 gave more security updates and SP 4 allows users of an Win2k users who have not applied any packs to fully upgrade.

Granted is was not all was warm and fuzy in Win2k land, there were security issues in the beginning most notably was the leak memo by Marry Jo Foley who revealed that Win2K had over sixty thousand known defects .  Win2K also received its fair virus share of famous attacks such as Code Red and Nimda.


Continue reading