on 06-13-2016 12:09 AM
Table of Content
Introduction
Problem
Why it is fraud usage
Problem Analysis
Logs collected for investigation
Introduction:
This document helps to understand how subscribers may use internet services without getting charged. This leads to revenue leakage for an operator. This document will help to overcome such issues when they are seen in operator network.
Problem:
Subscribers are able to use internet services without getting charged. They do it by modifying APN (Access Point Name) settings. This issue is seen with operators who provide WAP based APN service.
As WAP based APNs are required to use WAP gateway IP as a Proxy IP through which they are allowed to access internet services, there are some subscribers who are replacing the WAP gateway IP (in handset under APN settings) with one of the whitelisted IP from active ruledef available in the rulebase of that APN.
Why it is fraud usage:
All communication from UE to external Application server is reported under the RG (Rating Group)’s quota which subscriber is using as a whitelisted IP as proxy in handset APN setting. So if user takes some unlimited plan having that RG covered under it, than all that internet usage will get reported under that RG’s Quota, even if the usage is genuine or fraud.
For example: Subscriber has taken some unlimited plan for accessing twitter services, and he is replacing the WAP gateway IP with one of the twitter IP as proxy in WAP APN settings. Now all internet usage either of twitter or any other web service will get reported under the RG that is defined for twitter usage. This implies even if customer will use facebook or google or any other web service, it will get reported as twitter usage only, which is a fraud and it leads to revenue leakage for operator.
Problem Analysis:
To understand this issue better, we will use sample example of twitter service’s fraud usage.
Consider below ECS related configuration which was earlier available in node when fraud was detected:
active-charging service ECS-SVC
host-pool twitter1
ip X.Y.148.96/32
ip X.Y.158.184/32
ip X.Y.148.212/32
ip X.Y.150.7/32
ip X.Y.150.44/32
ip X.Y.156.11/32
ip X.Y.156.75/32
ip X.Y.158.180/32
ip X.Y.158.169/32
ip X.Y.156.199/32
ruledef test-twitter-allow
ip server-ip-address range host-pool twitter1
multi-line-or all-lines
charging-action CHARGING-ACTION-2
content-id 2
billing-action egcdr
cca charging credit
rulebase RULEBASE_1
action priority 2 ruledef test-twitter-allow charging-action CHARGING-ACTION-2
action priority 3 ruledef TCP_RULEDEF charging-action CHARGING-ACTION-2
p2p dynamic-flow-detection
From the monitor subscriber traces analysis, we found that subscriber were using http “connect” request for fraud internet usage via twitter whitelisted IP. Please see it below:
10.95.223.95.48445 > X.Y.148.96.80: P [tcp sum ok] 1:72(71) ack 1 win 457 <nop,nop,timestamp 1724884 3429256415> (DF) (ttl 64, id 43148, len 123)
PROTOCOL PAYLOAD ENDS.
PDU HEX DUMP FOLLOWS:
0x0000 32ff 007f 936a 0092 005b 0000 4500 007b 2....j...[..E..{
0x0010 a88c 4000 4006 4c96 0a5f df5f c73b 9460 ..@.@.L.._._.;.`
0x0020 bd3d 0050 556b e7e8 8a6e fdc9 8018 01c9 .=.PUk...n......
0x0030 0576 0000 0101 080a 001a 51d4 cc66 4cdf .v........Q..fL.
0x0040 434f 4e4e 4543 5420 7379 6e63 2e65 7269 CONNECT.sync.xyz
0x0050 6373 736f 6e2e 636f 6d3a 3434 3320 4854 .com:443.HT
0x0060 5450 2f31 2e31 0d0a 486f 7374 3a20 7379 TP/1.1..Host:.sy
0x0070 6e63 2e65 7269 6373 736f 6e2e 636f 6d3a nc.xyz.com:
0x0080 3434 330d 0a0d 0a 443....
For a genuine/legitimate usage, only GET/POST requests are used and not CONNECT request which is seen above, which validates that it is fraud usage.
Solution of this issue:
We can block or charge such usage separately using following ruledef along with server IP address.
block_twitter_connect
http request method = connect
ip server-ip-address = X.Y.148.96/32 -- > it can be IP-pool as well
#exit
charging-action block_twitter_connect
flow-action discard [in case customer want to charge this they can do the same as well]
#exit
Below is the end to end configuration which is suggested to overcome this issue:
active-charging service ECS-SVC
host-pool twitter1
ip X.Y.148.96/32
ip X.Y.158.184/32
ip X.Y.148.212/32
ip X.Y.150.7/32
ip X.Y.150.44/32
ip X.Y.156.11/32
ip X.Y.156.75/32
ip X.Y.158.180/32
ip X.Y.158.169/32
ip X.Y.156.199/32
ruledef test-twitter --------------------------- this will detect “connect” request
ip server-ip-address range host-pool twitter1
http request method = connect
#exit -------------- > Do not use “multi-line-or all-lines” command in this ruledef
ruledef test-twitter-allow --------------------------- this will detect rest all twitter usage
ip server-ip-address range host-pool twitter1
multi-line-or all-lines
charging-action CHARGING-ACTION-2
content-id 2
billing-action egcdr
cca charging credit
#exit
charging-action CHARGING-ACTION-BLOCK
flow action discard
#exit
rulebase RULEBASE_1
flow end-condition timeout normal-end-signaling session-end charging-edr EDR_FORMAT_1
billing-records egcdr
action priority 1 ruledef test-twitter charging-action CHARGING-ACTION-BLOCK
action priority 2 ruledef test-twitter-allow charging-action CHARGING-ACTION-2
action priority 3 ruledef TCP_RULEDEF charging-action CHARGING-ACTION-2
flow control-handshaking charge-to-application all-packets
p2p dynamic-flow-detection
Note: Please make note of command “flow control-handshaking charge-to-application all-packets” which is required to enable delayed charging action. This will make sure initial TCP control packets (i.e. SYN/SACK etc.) do not match TCP rule.
After doing the changes, we can see the fraud usage under “test-twitter” ruledef which is defined with “CHARGING-ACTION-BLOCK”. Please see it below in command output “show active-charging sessions full imsi <IMSI>”:
Ruledef Name Pkts-Down Bytes-Down Pkts-Up Bytes-Up Hits Match-Bypassed
-------------------- ---------- ---------- ---------- ---------- ---------- --------------
TCP_RULEDEF 265 159261 331 43936 496 0
test-twitter 55 20246 56 6623 84 0
As per operator’s requirement, either they can discard such usage or charge it separately.
Logs collected for investigation:
Please note: above traces were collected to understand the behavior of traffic at user plane level, which helps us to understand what action plan in configuration modification can be taken.
Please Note: IPs used are twitter Public IPs and are given just as an example.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: