CME Toll Fraud

Unanswered Question
Apr 6th, 2010
User Badges:

Hi, I know this has been discussed a lot in here and I have done my research however I still have the following questions.


A customer of ours who don't have any SIP services and only has connection the PSTN has been hit with toll fraud, they use a Cisco 2801 ISR that runs CME and is also terminating internet connection. Most calls have been to Cuba and a few other countries, after looking into it I applied the following ACLs on the WAN interface however this hasn't stopped the fraud continuing.


ip access-list extended EXTERNAL

deny ucp any any eq 5060 5061

deny tcp any any eq 5060 5061

deny tcp any any eq 1720 1721

deny udp any any range 16384 32767

permit ip any any


I have also disabled SIP processing that is:


sip-ua

no transport tcp

no transport udp


However when looking at the router it's still listening on TCP port 5061 and 1720, could this be a bug? What more can I do to stop this.


Local address          Foreign Address          State

*.5061                    *.*                               Listen

*.1720                    *.*                               Listen


Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
harisivaji Tue, 04/06/2010 - 23:05
User Badges:

Hi,

Can you provide more information on this?


There are lot of ways to acheieve it (Feature restriction tools)

you can create Time of day routing and block patterns based on Cuba country code.

If you want you can block always or you can block in specific time

For this your CME should be atleast 4.3.


Eg:

telephony-service
after-hours block pattern 1 853....

after-hours day mon 19:00 07:00
after-hours day tue 19:00 07:00
after-hours day wed 19:00 07:00
after-hours day thu 19:00 07:00
after-hours day fri 19:00 07:00
after-hours day sat 13:00 07:00
after-hours day sun 12:00 12:00


or


You can use translation rule to block that specific destination for outbound calls



Eg: Rule 1 reject /^853......../


or


If you want to do only with ACL try to match with source IP and with ports


It may be VOIP devices or you can block CME ip going outside with SIP ports (carefully block only SIP ports)

so that first signallling itslef will be blocked

So no worries



HTH,

Hari

hadisharifi Tue, 04/06/2010 - 23:12
User Badges:

Thanks Hari, After checking previous call logs it seems that it wasn't just calls to Cuba but a number of other countries like Morocco. After consulting with the client I have removed the 0.T dialpeer and replaced it with specific ones for STD and international to the US for now. I have recommended that they frontend their network with a firewall which will not only prevent toll fraud but will also hide their internal network and lower attack risks on their internal network.


What do you think of my above suggestion?


Thanks

harisivaji Tue, 04/06/2010 - 23:54
User Badges:

Firewall is good option, where we can deny the SIP ports in that level also and it will provide second level of prevention.

(only preventing this Toll fraud Firewall is not necessary, but it will secure you network in many different ways like internal network hiding)

Granular Toll prevention can achieved only with Voice related commands in CME

so i would suggest you the same


If you want to block based on specific countries, still you can go with translation rule with their country code

which is quite flexible

So it is better to block specific countries

by adding commands like "transfer pattern blocked ...."

paolo bevilacqua Wed, 04/07/2010 - 06:45
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

They may be calling via PSTN, getting dialtone via DP that doesn't have direct-inward-dial.

Or via SCCP port 2000.

hadisharifi Thu, 04/08/2010 - 00:17
User Badges:

Hi, how can I monitor and identify this that the calls might be coming via PSTN? There is no dialpeer that is allowing incoming calls and don't have the direct-inward dial enabled.


In the meantime I have suggested that they consider installing a firewall to protect their network in general.


Thanks

paolo bevilacqua Thu, 04/08/2010 - 06:23
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

That is strange, is strange either yo do not ahve applied the ACL correctly, or they are coming in some other way.


The router is able to protect itself perfectly and does not need an external firewalll. To the contrary, it can do firewall itself.

pa-jturner Thu, 04/08/2010 - 09:06
User Badges:

I just experienced the same thing on my CME in the UK. Someone was able to dial into our

system and then place outbound calls. The only thing i noticed on my router was a dial-peer 2 voice pots that had nothing under it so i deleted it. My AA does not allow external transfers. How can someone dialin and then get a second dial tone to place outbound calls?







dial-peer voice 1 pots
preference 7
incoming called-number .
direct-inward-dial
port 0/0/0:15
!
dial-peer voice 5250 voip
description pilot number 5250 for VM
destination-pattern 5250
session protocol sipv2
session target ipv4:10.200.4.10
dtmf-relay sip-notify
codec g711ulaw
no vad
!
dial-peer voice 9001 pots
description ***External Call***
destination-pattern 9T
port 0/0/0:15
!
dial-peer voice 6600 voip
description pilot number for AA
destination-pattern 6600
session protocol sipv2
session target ipv4:10.200.4.10
dtmf-relay sip-notify
codec g711ulaw
no vad
!
dial-peer voice 6660 voip
description pilot number for AA
destination-pattern 6660
session protocol sipv2
session target ipv4:10.200.4.10
dtmf-relay sip-notify
codec g711ulaw
no vad
!
dial-peer voice 4000 voip
description ***Send to Durham Call Manager***
destination-pattern 4...
session target ipv4:10.26.0.1
incoming called-number .
dtmf-relay h245-alphanumeric
codec g711ulaw
!
dial-peer voice 5000 voip
description ***Send to Durham Call Manager***
destination-pattern 5...
session target ipv4:10.26.0.1
dtmf-relay h245-alphanumeric
codec g711ulaw
no vad
!
dial-peer voice 9011 pots
description ***International External Call***
numbering-type international
destination-pattern 9T
port 0/0/0:15
!
sip-ua

paolo bevilacqua Thu, 04/08/2010 - 10:20
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

I know it seems strange to believe, but if you call in from a number starting with 9, you would get dialtone in your case, because it hits a DP with such destination-pattern and no direct-inward-dial.


Basically, you have to ubserve with debugs enabled for understand the exact way they do it.

rcordeiro Wed, 08/11/2010 - 05:26
User Badges:

Hi,


Can you give some info on this? Maybe some documents on how to prevent this kind of situations?


Thanks

paolo bevilacqua Wed, 08/11/2010 - 05:28
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

Just enter "toll fraud" in cisco.com search box.

Actions

This Discussion