Subscribers are able to use free internet services by using whitelisted IP as proxy

[rshroti]

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:

•           Monitor Subscriber Traces (for below 4 scenarios )with enabling A,X,19,26,36,verbosity-5+

1.          Use twitter whitelisted IP as proxy IP and try fraud twitter usage
2.          Use twitter whitelisted IP as proxy IP and try other websites apart from twitter
3.         Use Production WAP IP as proxy IP and try accessing twitter usage
4.         Use Production WAP IP as proxy IP and try other websites apart from twitter

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.

•            SSD of the ASR5K node
•            Show config verbose

Please Note: IPs used are twitter Public IPs and are given just as an example.