Welcome to Cisco Support Community. We would love to have your feedback.
We have encountered two separate attacks regarding toll fraud. Our carrier shut it down both times and alerted us. After the first time, I worked with TAC to help identify and prevent furture attacks. But it has occured again. According to CDR, the calls are transers from VoiceMail ports to international (Cuba) numbers.
Before the first attack, we did have restriction table in place to prevent this. TAC verified these were in place correctly. The one change that had me do is change the CSS on each VM port to one that does not allow International calling.
I am trying to figure out how this could be occuring. The gateway these calls are using (both times) is a PRI. I am looking for any ideas as to how this may be occuring. I attached a portion of the CDR and the Restriction Table Configuration (which is same for each Table).
CUCM - 18.104.22.16800-7
CUCXN - 8.5.1ES47.12900-7
there is a service parameter in call manager called "block transfer off-net to offnet call", set this paramter to true.
also in the gateway set the call to "offnet".
please rate all helpful posts
The call comes from Unity which is not considered offnet, so changing the parameter will do nothing.
To answer the question here, there are many ways toll fraud can be exploited via voicemail, any call handler, opening greeting etc can be exploited and caller might be able to enter any long distance or international number, that is the reason you configure restrictions rules in Unity, to prevent the potential.
I agree and what I want to understand is what are "the many ways" this could have occured even though I have restriction tables in place to block fraud. I tested the both a call handler and my own vm account by assigning an unused option to route to one of the fraudulent numbers shown on the report. I could not get the call to go thru. I have now created route patterns to block call to the fraud number from the gateway. I just wish I knew how they were doing this?
The most importnat thing which you have to take care of CSS of your VM registered ports . You have to make sure from the partitions which included on VM ports CSS. Other question can you share with us the Partition for international call , you can check that and check again your CSS for VM ports . CSS of VM ports should not include this partition , if there is no parition for international calls so you have to do a partition for international calls.
please rate all useful information
Well, you have to be careful with that if you desire any phone call notifications to work. If you block all external calls from the VM ports or SIP trunk (if using SIP integration) that will also break your notifications.
Regarding to Restriction tables , are ok , but your VM ports can not do any outgoing call if VM CSS not include any partition for RP "route pattern" for outgoing call. I hope to share with us the CSS for VM ports and the included partitions and the partition for international calls.
please rate all useful information
The simplest way to check if your VM ports are indeed not routing IDD calls, is to run the dialed number analyzer and see if the dialplan woulod actually block. i know a very crude test, but worth doing
Please remember to rate useful posts, by clicking on the stars below.
Yes, after the first attack I checked the VM port CSS and they were set to a CSS that allowed International. I changed them to a CSS that does not allow Int calls. However I only applied the change on the Directory Number Info for each VM port. The device information for each VM port still had a CSS that allowed Int calling. I did not change it on the device information level because I though the Directory Number Info to precidence over the device information. Screen shot below.
I did the Dial Numb Analyzer and my CSS's are valid.
I worked on a thread here where the poster was pretty
sure from his testing that the Line Level CSS was ignored on his
VM port configs.
It may be in your best interest to restrict @ the Device Level
as well just to be safe.
"Why do the best things always disappear "
- The Band