Solved: Toll fraud - ISP trying to hold me responsible

jeffrey.girard · ‎03-19-2012

Small ISP in central NY. I have 3 phone lines coming into my home. They are delivered via 2 x cable modems (2 x FXS jacks on each cable modem). I have connected 2 of the FXS ports on the cable modems to 2 x FXO ports on a 2811 router. I also receive my bandwidth via the cable modem. I use connection plar opx <insert phone number here> and then define the phone number on my CUCM.

Over a two day span, someone generated 28 calls to Dominica for a total of 498 minutes.

CDR records provided to me from the ISP all show the source DN as my DN.

My CDR records from my CUCM do not show any of these calls. My route patterns do not even allow 13 digit international dialing (max is 1plus 10 for long distance)

My CUCM is behind a NAT router with no static mappings from inside to outside.

So, other than empty CDR records and my denials, what else can I do to prove my innocence? My belief is that the modem itself was hacked.

From the ISP, I received something that appears to be a detailed CDR record.

Report Date: 3/15/2012

Call Count: 28

Call Duration: 498 Minutes

Calling Number: DELETED - THIS WAS ONE OF MY NUMBERS

Destination: DOMINICA

Called Number: 767-275-3700 / 767-275-4477

Call Example:

1 : start-time = 2012-03-16 18:05:19

2 : start-time = 1331935519

3 : call-duration = 000:27:03

4 : call-source = 199.58.145.156

5 : call-source-q931sig-port = 0

6 : call-dest = 10.2.10.40

7 : unused =

8 : call-source-custid =

9 : called-party-on-dest = 17672753700

10 : called-party-from-src = 17672753700

11 : call-type = IV

12 : unused = 01

13 : disconnect-error-type = N

14 : call-error = 0

15 : call-error =

16 : unused =

17 : unused =

18 : ani = DELETED - THIS WAS ONE OF MY NUMBERS

19 : unused =

20 : unused =

21 : unused =

22 : cdr-seq-no = 23442826

23 : unused =

24 : callid = 959f9128-c73a919c-13c4-50029-1110-23229e7f-1110

25 : call-hold-time = 000:00:05

26 : call-source-regid = dynamic-3539396626.865246.069

27 : call-source-uport = 1

28 : call-dest-regid = MetaSwitch01

29 : call-dest-uport = 0

30 : isdn-cause-code = 16

31 : called-party-after-src-calling-plan = 17672753700

32 : call-error-dest =

33 : call-error-dest =

34 : call-error-event-str = ack-rx#na

35 : new-ani = DELETED - THIS WAS ONE OF MY NUMBERS

36 : call-duration = 1623

37 : incoming-leg-callid =

38 : protocol = sip

39 : cdr-type = end1

40 : hunting-attempts = 0

41 : caller-trunk-group =

42 : call-pdd = 4506

43 : h323-dest-ras-error =

44 : h323-dest-h225-error =

45 : sip-dest-respcode =

46 : dest-trunk-group =

47 : call-duration-fractional = 1623.424

48 : timezone = EDT

49 : msw-name = msx1

50 : called-party-after-transit-route =

51 : called-party-on-dest-num-type = 0

52 : called-party-from-src-num-type =

53 : call-source-realm-name = <private>

54 : call-dest-realm-name = <private>

55 : call-dest-crname =

56 : call-dest-custid =

57 : call-zone-data =

58 : calling-party-on-dest-num-type = 0

59 : calling-party-from-src-num-type =

60 : original-isdn-cause-code = 16

61 : packets-received-on-src-leg = 80892

62 : packets-lost-on-src-leg = 304

63 : packets-discarded-on-src-leg = 303

64 : pdv-on-src-leg = 0

65 : codec-on-src-leg = g711ulaw

66 : latency-on-src-leg =

67 : rfactor-on-src-leg = 91

68 : packets-received-on-dest-leg =

69 : packets-lost-on-dest-leg =

70 : packets-discarded-on-dest-leg =

71 : pdv-on-dest-leg =

72 : codec-on-dest-leg = unknown

73 : latency-on-dest-leg =

74 : rfactor-on-dest-leg =

75 : sip-src-respcode =

76 : peer-protocol = sip

77 : src-private-ip = 199.58.145.156

78 : dest-private-ip = <private>

79 : src-igrp-name =

80 : dest-igrp-name = 1

81 : diversion-info =

82 : custom-contact-tag =

83 : e911-call =

84 : reserved =

85 : reserved =

86 : call-release-source = destination

87 : hunt-attempts-including-LCF-tries =

88 : call-gapping-error =

89 : error-code-in-reason-header =

90 : ocl-object-type =

91 : ocl-object-id-dtn-regid-realmname =

92 : ocl-object-id-dtnrealm-uport =

93 : ocl-policy-name =

94 : src-private-port = 50368

95 : dest-private-port = 28632

96 : src-realm-media-ip = 68.70.57.8

97 : src-realm-media-port = 28456

98 : dest-realm-media-ip = <private>

99 : dest-realm-media-port = 22070

The ISP tells me that the 199.58.145.156 address is my cable modem/FXS ports.

Is there anything here that would help me defend myself?

Jeff

Kenneth Mohammed · ‎03-19-2012

Hi Jeffery,

Unfortunately, the ISP is correct. If they are nice to you, maybe they can come to some sort of settlement agreement with you as to the amount of the bill.

I have seen this happen with several of my customers.

Basically what is happening, is that phreakers (phone system hackers), are registering SIP or H323 softphones (maybe Xlite, or another type softphone) to the public IP of your 2811 router, and being able to determine that the IP resides in the US, and may more than likely use a "9" to get an outside line. Of course you have dial-peers in the router to forward these calls out of your FXO ports, and voila, the call is made!

The call will never hit your voip dial peer pointing to CUCM, which is why you won't see anything in your CDRs

This can be remedied with an ACL applied to your internet facing interface, blocking sip and h323 traffic. Or, you can make explicit dial peers that will block calls made to notorious toll-fraud destinations (Cuba, etc).

ip access-list extended TOLL_FRAUD_BLOCK

deny tcp any any eq 5060

deny udp any any eq 5060

deny tcp any any eq 1720

deny udp any any eq 1720

permit ip any any

interface (outside/internet facing interface)

ip access-group TOLL_FRAUD_BLOCK in

Then, Im pretty sure, the next day, if you do a show access-list, you should see some hits for the deny SIP and maybe the deny H323 (I usually see this done using SIP), and you will know that you have effectively blocked the toll fraud. You will be amazed at the amount of times they tried to hit your router before they finally decide to give up. I have noticed that this usually happens during the late night hours. Also, Dominica is in the Caribbean, and therefore has a 1+10 digit numbers, which is why the router allows the call, since there is a dialpeer to match it.

Hope that helped, if so, please rate.

View solution in original post

Kenneth Mohammed · ‎03-19-2012

Hi Jeffery,

Unfortunately, the ISP is correct. If they are nice to you, maybe they can come to some sort of settlement agreement with you as to the amount of the bill.

I have seen this happen with several of my customers.

Basically what is happening, is that phreakers (phone system hackers), are registering SIP or H323 softphones (maybe Xlite, or another type softphone) to the public IP of your 2811 router, and being able to determine that the IP resides in the US, and may more than likely use a "9" to get an outside line. Of course you have dial-peers in the router to forward these calls out of your FXO ports, and voila, the call is made!

The call will never hit your voip dial peer pointing to CUCM, which is why you won't see anything in your CDRs

This can be remedied with an ACL applied to your internet facing interface, blocking sip and h323 traffic. Or, you can make explicit dial peers that will block calls made to notorious toll-fraud destinations (Cuba, etc).

ip access-list extended TOLL_FRAUD_BLOCK

deny tcp any any eq 5060

deny udp any any eq 5060

deny tcp any any eq 1720

deny udp any any eq 1720

permit ip any any

interface (outside/internet facing interface)

ip access-group TOLL_FRAUD_BLOCK in

Then, Im pretty sure, the next day, if you do a show access-list, you should see some hits for the deny SIP and maybe the deny H323 (I usually see this done using SIP), and you will know that you have effectively blocked the toll fraud. You will be amazed at the amount of times they tried to hit your router before they finally decide to give up. I have noticed that this usually happens during the late night hours. Also, Dominica is in the Caribbean, and therefore has a 1+10 digit numbers, which is why the router allows the call, since there is a dialpeer to match it.

Hope that helped, if so, please rate.

jeffrey.girard · ‎03-20-2012

Kenneth -

I appreciate your very detailed reply and Im sorry that you have to know this from experience as well (at least your clients)

If I read your post correct, you are presuming that the phreakers are inside my network (as that is the only way that they could be going "out" my public facing interface.

If that is true, than one of my inside boxes has been compromised.

I will try out your suggestion and re-post to let all know what happened.

Jeff

jeffrey.girard · ‎03-20-2012

Kenneth -

I just re-read your response and now realize what you are saying. They are not inside my network, they are outside, but they are hairpinning/tromboning into and then back out of my 2811.

That is very interesting.

I will apply the ACLs as well as the block dial peers and see what happens

Jeff

jeffrey.girard · ‎03-20-2012

Kenneth -

Well, I dont know if we are going to find out the real truth or not.

Through conversations with the tech guy at the ISP, they discoverd weak passwords and fixed them and also put an international block on my line (that I had requested some time ago and they did not implement). After they put the international block on my line, there were 3 attempts and then they stopped. There has been no more attempts since then.

I did place the ACL, but it has not had any hits and it appears that the culprit has moved on to other game.

Thank you anyway, its great advise and I will keep it in place.

Now, how do I place a rating in the system?

Jeff

Gajanan Pande · ‎03-19-2012

Jeff,

I concur with Kenneth. If the situation is indeed as Kenneth predicted, then my friend it's a bad news.

GP.

Jonathan Schulenberg · ‎03-20-2012

Another option in addition to the ACLs is to upgrade to IOS 15.1(2)T or newer. They implemented a deny-by-default behavior for VoIP dial-peers. All SETUP/INVITE requests will be denied unless the source address is also a target address of a VoIP dial-peer.

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a0080b3e123.shtml