Happy New year!!!
We have call manager System version: 220.127.116.11900-3 and voice gateway H323. The telco send the reports and saying that from our PRI used some high risk county calls. also High usage of ILD calls to spcific county and call duration is very huge....
As per the Telco the calls are made from our pilot number e.g. A party -223099xxxxx and B Party 00974444xxxx.
based on the Telco B-party number and timestamp we have collected CDR logs, from CDR logs we unable to match B-party numbers...
we have created route pattern and blocked spiciifc country calls also, still we got some calls used those PRI...
please advise me, if any possible using 3rd party SIP phones to our voicegateway and making calls or any way to hacking the VG.
please any one advise your inputs on the same....
Thanks & Regards,
If you are using H323 and only blocked it on the CUCM, you still have the gateway to worry about since you have a peer to peer setup. Also you can setup a syslog server(kiwi) comes to mind and run debugs and log them to your desktop so you can see them when you come to work or VPN from home and take a look.
I'm not sure of how they are getting out at this point I've seen tool fruad from just fowarding numbers, to people getting dial tone on unity. As for right now you should be blocking calls to that location at the provider level, and setup access-list to only allow VOIP traffic to come from your subnets on to your gateway.
I am naveen's colleague.
We have been monitoring the debugs. Though I have not done it personally. My team has reported that there has not been anything in the debug.
However I have enabled the Traces from CUCM on the Gateways. Will that help.
You might need to concentrate on the gateways rather than the call manager, as generally PSTN gateway is the most vulnerable part being exposed to the outside world. Toll fraud may occur if you're generating secondary dial tone on any of your PRI lines. That should be the first thing to check. This kind of traffic is not passing thru call managers, so it doesn't generate any logs or CDRs.
As a reference, you can refer to this document, even though it's titled for CME it covers the relevant parts:
Also you can immediately check show isdn history to check the traffic (default 15 minutes) or
use "show call history voice brief"
You can increase the history size using the commands:
dial-control-mib retain-timer 2880 (in minutes)
dial-control-mib max-size 1200 (number of records)
As tol fraud seems be an issue here I suggest that you read
this link and upgrade your IOS to at least 15.1.T2
Implement the anti toll fraud config (very simple) this will allow
outbound calls only to set up from your call managers and will
block all other SIP or H323 call attempts
voice service voip
ip address trusted list
ipv4 10.10.10.100 255.255.255.255
ipv4 10.10.10.200 255.255.255.255
Where the 2 Ip addresses are examples of
Call Manager servers and no other addresses will be trusted
Please rate useful posts
Possibly the fraud does not come from network, but from PSTN; where they find a DID that gives dial-tone, and use it as a re-dialer.
Hi Thanks for the excellent suggestion.
Getting aproval for upgrade is going to take some time, but we will try to push for this.
Hi Naveen / Rohan,
Are your voicemail ports restricted from dialling out?http://www.cisco.com/en/US/docs/voice_ip_comm/connection/8x/security/guide/8xcucsec020.html
Do you allow all users to dial international calls? Maybe setup some CSS and partitions
What about time of day routing?http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_configuration_example09186a0080a7bc96.shtml
You could also enable the CDR reports on the UCM and check for the calls.
A basic reporting interface is provided by Cisco or you could use a 3rd party tool to collect the data and run reports. Many are listed on the Developer portal using the following search terms:
Call Logging (Certified products)
http://developer.cisco.com/web/partner/search?text=call logging&technologyIds=a0G40000000xlnlEAA&subTechnologyIds=a0K40000000eHsEEAU&technologyProductIds=a0I40000000ycykEAA&partnerProductFamilies=Call Accounting and Billing&certified=Yes&onCiscoPriceList=All&portfolioPartner=All
Call Accounting (Certified products)
http://developer.cisco.com/web/partner/search?text=call accounting&technologyIds=a0G40000000xlnlEAA&subTechnologyIds=a0K40000000eHsEEAU&technologyProductIds=a0I40000000ycykEAA&partnerProductFamilies=Call Accounting and Billing&certified=Yes&onCiscoPr...
Our TIM Plus and TIM Enterprise products have built in toll fraud with customisable alarms, AXL directory integration and unlimited display boards included as standard.
Were CDR's enabled on all your UCM node(s) before you had the toll fraud calls? If so you could run your historic data through our product and see what calls were reported by the UCM and setup alarms for any future calls.
You can arrange for a free trial via our Cisco microsite www.tri-line.com/cisco
TIM Enterprise overview video:
Like the others suggested if your not seeing the calls on the call manager then the gateway itself is placing the calls. Does your gateway have a public IP address?
you can do a show udp on the voice gateway and see if any forgen hosts are are connected. Especially look to see what is using ports 5060 and 5061.
If these udp ports are open a third party can use SIP to place calls to your gateway and as long as it matches a dial-peer it will palace the call for them. A 9T dial peer will let them use your gateway to dial out any where.
If you have a foriegn host using these ports you can use an ACL to deny access on these ports.
Just to add the James' (+5) comments, the most common instance I see of toll fraud is where someone has connected their gateway to the Internet, but has not configured an inbound ACL.
If you want to see how often gateways are targetted to see if their H.323 or SIP ports are open, create an ACL blocking TCP/1720, UDP/5060 and TCP/5060 and log it.
ip access-list ext inbound
deny udp any any eq 5060 log
deny tcp any any eq 5060 log
deny tcp any any eq 1720 log
permit ip any any
desc outside interface
ip access-group inbound in
Note that you'll need to tailor this ACL to reflect your actual requirements, however you will very quickly see matches on the rules blocking SIP and H.323. IOS version 12.4 and earlier will automatically place H323 calls unless you specifically block them.
An example for a router that has been up for less than a week:
Rtr#show ip access-list inboundfilters
Extended IP access list inboundfilters
1 deny tcp any any eq 5060 log (18 matches)
2 deny tcp any any eq 1720 log (18 matches)
3 deny udp any any eq 5060 log (1487 matches)