fraudulent calls detailed logging

Unanswered Question
Aug 2nd, 2008
User Badges:

We are having a problem with fraudulent calls on a CME 4 system. We have enabled logging and can see the calls and the extensions they are coming from however we have many dial-peers that are across a VPN and we suspect that someone on the other end of a vpn tunnel is doing this. the extensions are bogus and we never see a phone register to our system that is making the calls. is there any way to log the IP of a phone that makes a call in addition to the source and dest number? if I can get the ip of the offender I can find out what site this is coming from. Thanks for any insight that you may have.


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Marwan ALshawi Sat, 08/02/2008 - 19:56
User Badges:
  • Purple, 4500 points or more
  • Community Spotlight Award,

    Best Publication, December 2015

why u dont enmploy COR lists in ur CME system and make restrction on ur dial-peers so that u can control who can make calls through any spisefic dial-peer

this is for more control and security

mbates1 Mon, 08/04/2008 - 05:40
User Badges:

that is a good idea. we have blocking patterns setup, but they don't affect calls that are coming in from a dial peer. we'll add some COR lists to the dial-peers and that should resolve the problem. thanks for the feedback.

pcameron Mon, 08/04/2008 - 03:15
User Badges:
  • Cisco Employee,

Rather than logging the calls and suffering the possibly expensive phone bills, it would be better to block the calls completely.

If you have a routable device that has some kind of open access , it is possible the other parties are using SIP or H323 to make the calls. Using SCCP would mean they need to register directly to the CME system, and hence would need access to the configuration. If you only have IP phones , then maybe you should block access to SIP and H323 for external devices.

There are a couple of ways to do this -

1) Using standard access lists and applying them to the interface where the traffic is coming from -

access-list 128 deny tcp any eq 5060 any

access-list 128 deny tcp any any eq 5060

access-list 128 deny udp any eq 5060 any

access-list 128 deny udp any any eq 5060

access-list 128 deny tcp any eq 1720 any

access-list 128 deny tcp any any eq 1720

access-list 128 permit ip any any

interface fast Ethernet 0/0

ip access-group 128 in

2) Turning off SIP transport if you are not using it all. You may still need an access list to block the H323 traffic.


no transport upd

no transport tcp


(When applying this workaround to devices that are processing MGCP or H.323 calls, the device will not allow SIP processing to stop while active calls are being processed. As a result, the workaround should be implemented during a maintenance period when active calls can be stopped)

3) Using control plane policing and policy maps

access-list 111 deny tcp any any eq 5060

access-list 111 deny tcp any any eq 5061

access-list 111 deny udp any any eq 5060

access-list 111 deny udp any any eq 5061

access-list 111 deny tcp any any eq 1720

access-list 111 deny udp any any range 16384 32767

access-list 111 permit ip any any

class-map match-all drop-voice-class

match access-group 111

policy-map drop-voice-traffic

class drop-voice-class



service-policy input drop-voice-traffic

based on your description, the best thing to do would be to get packet capture (wireshark or similar) and log all the malicious traffic , this way you can easily identify source IP addresses. You can also do this with SIP or h225 debugs on the router.

If you get the IP address of the source traffic you can also apply a specific access list to block traffic from this device.

mbates1 Mon, 08/04/2008 - 05:47
User Badges:

we do have the system secured from the outside. the IOS fw is on and working and we verified that from the outside. the calls are coming from a dial-peer that is on a vpn tunnel to the system at a remote office. This is connections that they need to have, but someone is abusing it and dialing all over the place through the dial-peer. we've tried capturing h225 debugs but we cannot seem to find anything that will show the ip of the phone that initiates the call, just the extension. I think we are going to try applying COR to the dial-peers to restrict where they can dial and check that the issue is resolved. thanks for the detailed post and feed back.

Marwan ALshawi Mon, 08/04/2008 - 05:58
User Badges:
  • Purple, 4500 points or more
  • Community Spotlight Award,

    Best Publication, December 2015

keep with COR list at least u will make the users under ur control

because when u secure ur system first thing u have to do is calling rights who can call whos and so on on addition to packet filltering based on source and destiniation

so COR first then go to the next stage

good luck

please, rate if helpful

mbates1 Wed, 08/13/2008 - 05:32
User Badges:

We found a solution with after hours blocking and exemption

basically we did this:


after-hours block pattern 1 9011 7-24

ephone 16

after-hour exempt

We tried COR, but it is not effective on this type of traffic since we have no access to the CM or CME systems on the vpn endpoints. COR doesn't work unless it's applied to both legs of the call and we can't control the other end.

The solution above ended up being so simple that it hit us in the face once we figured it out. basically, we put in a 24x7 call block for international calls. then we exempted the internal phones from the block. now when calls are routed in over the vpn, the can only call locally since they are not exempt and calls get dropped if the international dialing prefix is found.

Marwan ALshawi Wed, 08/13/2008 - 05:40
User Badges:
  • Purple, 4500 points or more
  • Community Spotlight Award,

    Best Publication, December 2015


this is 5+ :)

AJAZ NAWAZ Thu, 11/06/2008 - 22:54
User Badges:
  • Silver, 250 points or more

This block pattern is for a specific match right?, and if so how is this blocking global international dialling...

or do you have an associated dial-peer in addition to this?

I understand that you are not using COR and this has nothing to do with my question.


mbates1 Fri, 11/07/2008 - 04:45
User Badges:

this, after-hours block pattern 1 9011 7-24

blocks any calls that begin with the international dial prefix of 9011 so nothing can dial internationally unless it is exempted. The dial peers are all just 9T since from inside our office we need to be able to dial anywhere. We could not make COR work in this scenario since we don't have control of the other CME systems we are connected to.


This Discussion