Documentation

Documentation.Tutorials-FraudDetection-2-3 History

Show minor edits - Show changes to markup

November 14, 2016, at 11:41 AM by liviu -
Changed line 71 from:
  • has made at least 5 calls within the last minute
to:
  • has made at least 5 calls within the last minute
November 10, 2016, at 04:01 PM by liviu -
Changed lines 44-47 from:

sequential_calls_warning, sequential_calls_critical) VALUES(1, '99', '09:00', '17:00', 'Mon-Fri', 3, 5, 120, 220, 16, 35, 3, 5, 6, 20), (1, '99', '17:01', '23:59', 'Mon-Fri', 3, 5, 160, 250, 21, 35, 3, 5, 8, 26), (1, '99', '00:00', '08:59', 'Mon-Fri', 3, 4, 80, 160, 10, 20, 3, 4, 5, 15), (1, '99', '00:00', '23:59', 'Sat,Sun', 3, 5, 190, 290, 24, 40, 3, 5, 12, 30);

to:

sequential_calls_warning, sequential_calls_critical) VALUES(1, '99', '09:00', '17:00', 'Mon-Fri', 3, 5, 7200, 13200, 16, 35, 3, 5, 6, 20), (1, '99', '17:01', '23:59', 'Mon-Fri', 3, 5, 9600, 16000, 21, 35, 3, 5, 8, 26), (1, '99', '00:00', '08:59', 'Mon-Fri', 3, 4, 4800, 9600, 10, 20, 3, 4, 5, 15), (1, '99', '00:00', '23:59', 'Sat,Sun', 3, 5, 11400, 17400, 24, 40, 3, 5, 12, 30);

November 10, 2016, at 03:59 PM by liviu -
Changed lines 52-55 from:
119909:0017:00Mon-Fri35120220163535620
219917:0123:59Mon-Fri35160250213535826
319900:0008:59Mon-Fri3480160102034515
419900:0023:59Sat,Sun351902902440351230
to:
119909:0017:00Mon-Fri35720013200163535620
219917:0123:59Mon-Fri35960016000213535826
319900:0008:59Mon-Fri3448009600102034515
419900:0023:59Sat,Sun3511400174002440351230
Changed line 66 from:
  • makes one call lasting between 120 and 219 minutes
to:
  • makes one call lasting between 7200 and 13119 seconds
Changed line 72 from:
  • makes one call lasting at least 220 minutes
to:
  • makes one call lasting at least 13120 seconds
March 18, 2015, at 09:54 PM by liviu -
Changed lines 15-16 from:

With the help of the dialog module, fraud_detection is able to closely monitor the following call-related statistics for each [user,destination] pair:

to:

With the help of the dialog module, fraud_detection is able to monitor the following call-related statistics for each [user,destination] pair:

Deleted lines 23-26:


Validation of a check_fraud() call may be done either with its return code or through the event route. (scripting examples below)

Changed lines 79-81 from:

As stated in the Chapter 1 of the documentation, the module monitors 5 parameters which are updated every time the check_fraud function is called (i.e each time a call is made). For each set of number prefix and username, unique values of the 5 parameters will be kept and monitored. Each time a value is altered, it will be compared to a threshold value. There are two threshold values for each of the 5 parameters (warning and critical thresholds), thus making a total of 10 values. This threshold values along with a time interval in which they are applicable form a so-called rule. It's the admin's job to provide the fraud rules to OpenSIPs through the db interface.

Example script

to:

As stated in the Chapter 1 of the documentation, the module monitors 5 parameters which are updated every time the check_fraud function is called (i.e each time a call is made). For each set of number, prefix and username , unique values of the 5 parameters will be kept and monitored. Each time a value is altered, it will be compared to a threshold value. There are two threshold values for each of the 5 parameters (warning and critical thresholds), thus making a total of 10 values. This threshold values along with a time interval in which they are applicable form a so-called rule. It's the admin's job to provide the fraud rules to OpenSIPs through the db interface.

Example script

March 18, 2015, at 06:39 PM by liviu -
Changed lines 46-49 from:

INSERT INTO fraud_detection(profileid, prefix, start_hour, end_hour, daysoftheweek, cpm_warning, cpm_critical, call_duration_warning, call_duration_critical, total_calls_warning, total_calls_critical, concurrent_calls_warning, concurrent_calls_critical, sequential_calls_warning, sequential_calls_critical) VALUES(1, '99', '09:00', '17:00', 'Mon-Fri', 3, 5, 120, 220, 16, 35, 3, 5, 6, 20), (1, '99', '17:01', '23:59', 'Mon-Fri', 3, 5, 160, 250, 21, 35, 3, 5, 8, 26), (1, '99', '00:00', '08:59', 'Mon-Fri', 3, 4, 80, 160, 10, 20, 3, 4, 5, 15), (1, '99', '00:00', '23:59', 'Sat,Sun', 3, 5, 190, 290, 24, 40, 3, 5, 12, 30);

to:

INSERT INTO fraud_detection(profileid, prefix, start_hour, end_hour, daysoftheweek, cpm_warning, cpm_critical, call_duration_warning, call_duration_critical, total_calls_warning, total_calls_critical, concurrent_calls_warning, concurrent_calls_critical, sequential_calls_warning, sequential_calls_critical) VALUES(1, '99', '09:00', '17:00', 'Mon-Fri', 3, 5, 120, 220, 16, 35, 3, 5, 6, 20), (1, '99', '17:01', '23:59', 'Mon-Fri', 3, 5, 160, 250, 21, 35, 3, 5, 8, 26), (1, '99', '00:00', '08:59', 'Mon-Fri', 3, 4, 80, 160, 10, 20, 3, 4, 5, 15), (1, '99', '00:00', '23:59', 'Sat,Sun', 3, 5, 190, 290, 24, 40, 3, 5, 12, 30);

March 18, 2015, at 06:38 PM by liviu -
Changed lines 79-80 from:

Current features

to:

How does it work?

Deleted lines 81-92:

Future directions for the module include adding more compression algorithms and support fore more types of routes.

Example scenario and DB provisioning

Suppose our OpenSIPs instance is responsible for routing calls to many countries as well as to the FarFarAway country which has the 99 phone prefix. We know that there are a lot of hustlers in this fictional country and if a SIP account was hijacked it could cost our company a huge amount of money by making phoney calls to FarFarAway. So, we are going to look for suspicious patterns in calls to this country. For this we are going to insert four different rules:

The first rule sets the thresholds for all the calls made in the working hours (9-17) in the working days to all the numbers starting with 99. Note that we expect anything between 5 and 10 calls during this period to be possible although not probable. However, more than two calls initiated in a single minute from a single user will raise a warning. Furthermore, we expect that more than one concurrent call from the same user to be a problem. If a user calls a number starting with 99 twice in a row (that is without calling any other number between this calls) will also raise an alarm. The second and the third rules are for time periods outside the working hours, but in the working days. Note that we still expect some calls to be made during this periods (from people who arrive early at the office or from people who stay in late). The fourth rule is for weekends. Here, almost any call should raise an alarm. Note, that all the rules have the same profile id. Basically, this means that they are from the same logical sub-set of rules. Every call of the check_fraud function will need a profile id.

March 17, 2015, at 06:08 PM by liviu -
Changed line 44 from:

The following is an example of a fraud detecting profile for destination prefix "+99". Note that all rules belong to the same profile: 1.

to:

The following is an example of a fraud detecting profile for destination prefix "99". Note that all rules belong to the same profile: 1.

Changed lines 48-49 from:

VALUES(1, '+99', '09:00', '17:00', 'Mon-Fri', 3, 5, 120, 220, 16, 35, 3, 5, 6, 20), (1, '+99', '17:01', '23:59', 'Mon-Fri', 3, 5, 160, 250, 21, 35, 3, 5, 8, 26), (1, '+99', '00:00', '08:59', 'Mon-Fri', 3, 4, 80, 160, 10, 20, 3, 4, 5, 15), (1, '+99', '00:00', '23:59', 'Sat,Sun', 3, 5, 190, 290, 24, 40, 3, 5, 12, 30);

to:

VALUES(1, '99', '09:00', '17:00', 'Mon-Fri', 3, 5, 120, 220, 16, 35, 3, 5, 6, 20), (1, '99', '17:01', '23:59', 'Mon-Fri', 3, 5, 160, 250, 21, 35, 3, 5, 8, 26), (1, '99', '00:00', '08:59', 'Mon-Fri', 3, 4, 80, 160, 10, 20, 3, 4, 5, 15), (1, '99', '00:00', '23:59', 'Sat,Sun', 3, 5, 190, 290, 24, 40, 3, 5, 12, 30);

Changed lines 54-57 from:
11+9909:0017:00Mon-Fri35120220163535620
21+9917:0123:59Mon-Fri35160250213535826
31+9900:0008:59Mon-Fri3480160102034515
41+9900:0023:59Sat,Sun351902902440351230
to:
119909:0017:00Mon-Fri35120220163535620
219917:0123:59Mon-Fri35160250213535826
319900:0008:59Mon-Fri3480160102034515
419900:0023:59Sat,Sun351902902440351230
Changed lines 87-90 from:

Suppose our OpenSIPs instance is responsible for routing calls to many countries as well as to the FarFarAway country which has the +99 phone prefix. We know that there are a lot of hustlers in this fictional country and if a SIP account was hijacked it could cost our company a huge amount of money by making phoney calls to FarFarAway. So, we are going to look for suspicious patterns in calls to this country. For this we are going to insert four different rules:

The first rule sets the thresholds for all the calls made in the working hours (9-17) in the working days to all the numbers starting with +99. Note that we expect anything between 5 and 10 calls during this period to be possible although not probable. However, more than two calls initiated in a single minute from a single user will raise a warning. Furthermore, we expect that more than one concurrent call from the same user to be a problem. If a user calls a number starting with +99 twice in a row (that is without calling any other number between this calls) will also raise an alarm.

to:

Suppose our OpenSIPs instance is responsible for routing calls to many countries as well as to the FarFarAway country which has the 99 phone prefix. We know that there are a lot of hustlers in this fictional country and if a SIP account was hijacked it could cost our company a huge amount of money by making phoney calls to FarFarAway. So, we are going to look for suspicious patterns in calls to this country. For this we are going to insert four different rules:

The first rule sets the thresholds for all the calls made in the working hours (9-17) in the working days to all the numbers starting with 99. Note that we expect anything between 5 and 10 calls during this period to be possible although not probable. However, more than two calls initiated in a single minute from a single user will raise a warning. Furthermore, we expect that more than one concurrent call from the same user to be a problem. If a user calls a number starting with 99 twice in a row (that is without calling any other number between this calls) will also raise an alarm.

March 17, 2015, at 04:56 PM by liviu -
Changed lines 46-48 from:

INSERT INTO fraud_detection(profileid, prefix, start_hour, end_hour, daysoftheweek, cpm_warning, cpm_critical, call_duration_warning, call_duration_critical, total_calls_warning, total_calls_critical, concurrent_calls_warning, concurrent_calls_critical, sequential_calls_warning, sequential_calls_critical) VALUES(1, '+99', '09:00', '17:00', 'Mon-Fri', 3, 5, 120, 220, 16, 35, 3, 5, 6, 20), (1, '+99', '17:01', '23:59', 'Mon-Fri', 3, 5, 160, 250, 21, 35, 3, 5, 8, 26),

to:

INSERT INTO fraud_detection(profileid, prefix, start_hour, end_hour, daysoftheweek, cpm_warning, cpm_critical, call_duration_warning, call_duration_critical, total_calls_warning, total_calls_critical, concurrent_calls_warning, concurrent_calls_critical, sequential_calls_warning, sequential_calls_critical) VALUES(1, '+99', '09:00', '17:00', 'Mon-Fri', 3, 5, 120, 220, 16, 35, 3, 5, 6, 20), (1, '+99', '17:01', '23:59', 'Mon-Fri', 3, 5, 160, 250, 21, 35, 3, 5, 8, 26), \

March 17, 2015, at 04:55 PM by liviu -
March 17, 2015, at 04:55 PM by liviu -
Changed lines 46-49 from:

INSERT INTO fraud_detection(profileid, prefix, start_hour, end_hour, daysoftheweek, cpm_warning, cpm_critical, call_duration_warning, call_duration_critical, total_calls_warning, total_calls_critical, concurrent_calls_warning, concurrent_calls_critical, sequential_calls_warning, sequential_calls_critical) VALUES(1, '+99', '09:00', '17:00', 'Mon-Fri', 3, 5, 120, 220, 16, 35, 3, 5, 6, 20), (1, '+99', '17:01', '23:59', 'Mon-Fri', 3, 5, 160, 250, 21, 35, 3, 5, 8, 26), (1, '+99', '00:00', '08:59', 'Mon-Fri', 3, 4, 80, 160, 10, 20, 3, 4, 5, 15), (1, '+99', '00:00', '23:59', 'Sat,Sun', 3, 5, 190, 290, 24, 40, 3, 5, 12, 30);

to:

INSERT INTO fraud_detection(profileid, prefix, start_hour, end_hour, daysoftheweek, cpm_warning, cpm_critical, call_duration_warning, call_duration_critical, total_calls_warning, total_calls_critical, concurrent_calls_warning, concurrent_calls_critical, sequential_calls_warning, sequential_calls_critical) VALUES(1, '+99', '09:00', '17:00', 'Mon-Fri', 3, 5, 120, 220, 16, 35, 3, 5, 6, 20), (1, '+99', '17:01', '23:59', 'Mon-Fri', 3, 5, 160, 250, 21, 35, 3, 5, 8, 26), (1, '+99', '00:00', '08:59', 'Mon-Fri', 3, 4, 80, 160, 10, 20, 3, 4, 5, 15), (1, '+99', '00:00', '23:59', 'Sat,Sun', 3, 5, 190, 290, 24, 40, 3, 5, 12, 30);

March 17, 2015, at 04:52 PM by liviu -
Added lines 45-47:
INSERT INTO fraud_detection(profileid, prefix, start_hour, end_hour, daysoftheweek, cpm_warning, cpm_critical, call_duration_warning, call_duration_critical, total_calls_warning, total_calls_critical, concurrent_calls_warning, concurrent_calls_critical, sequential_calls_warning, sequential_calls_critical) VALUES(1, '+99', '09:00', '17:00', 'Mon-Fri', 3, 5, 120, 220, 16, 35, 3, 5, 6, 20), (1, '+99', '17:01', '23:59', 'Mon-Fri', 3, 5, 160, 250, 21, 35, 3, 5, 8, 26), (1, '+99', '00:00', '08:59', 'Mon-Fri', 3, 4, 80, 160, 10, 20, 3, 4, 5, 15), (1, '+99', '00:00', '23:59', 'Sat,Sun', 3, 5, 190, 290, 24, 40, 3, 5, 12, 30);
March 17, 2015, at 04:28 PM by liviu -
Changed line 121 from:
		check_fraud("$fU", "$dU", "1");
to:
		check_fraud("$fU", "$rU", "1");
March 17, 2015, at 11:24 AM by liviu -
Changed line 62 from:
  • makes one call lasting between 120 minutes
to:
  • makes one call lasting between 120 and 219 minutes
March 17, 2015, at 11:23 AM by liviu -
Changed line 62 from:
  • makes one call lasting at least 120 minutes
to:
  • makes one call lasting between 120 minutes
March 17, 2015, at 11:16 AM by liviu -
Changed line 60 from:
  • Rule 1 will obviously match from 09:00 to 17:00, Monday to Friday. It will trigger a fraud warning event/error each time the same user either:
to:
  • Rule 1 will obviously match from 09:00 to 17:00, Monday to Friday. It will trigger a fraud warning event/error each time a user either:
March 17, 2015, at 11:15 AM by liviu -
Changed line 66 from:
  • The same Rule 1 will trigger a fraud critical event/error each time the same user either:
to:
  • The same Rule 1 will trigger a fraud critical event/error each time a user either:
March 17, 2015, at 11:14 AM by liviu -
Changed line 58 from:

Additional explanations:

to:

Data interpretation:

March 17, 2015, at 11:12 AM by liviu -
Changed line 30 from:

In order to create the fraud_detection table, first make sure your opensipsctlrc file contains the desired SQL engine, DB name and credentials:

to:

In order to create the fraud_detection table, first make sure your opensipsctlrc file contains the desired SQL engine, DB name and access credentials:

March 17, 2015, at 11:11 AM by liviu -
Changed line 22 from:

Note: some of the above statistics require a user-provisioned time interval to be sampled upon (see 'Table provisioning' below)

to:

Note: the above statistics require a user-provisioned time interval to be sampled upon (see 'Table provisioning' below)

March 17, 2015, at 11:10 AM by liviu -
Changed line 15 from:

With the help of the dialog module, fraud_detection is able to closely monitor the following call-related statistics for each user:

to:

With the help of the dialog module, fraud_detection is able to closely monitor the following call-related statistics for each [user,destination] pair:

March 17, 2015, at 11:09 AM by liviu -
Changed line 10 from:

The module provides a way of detecting suspicious calls from the same users to the same destinations might would otherwise likely end up costing the affected VoIP account (or the VoIP provider!) considerable amounts of money. This is done by closely monitoring a set of call-related parameters for each [user,destination] pair, together with sets of provisioned alerting thresholds.

to:

The module provides a way of detecting suspicious calls from the same users to the same destinations might would otherwise likely end up costing the affected VoIP account (or the VoIP provider!) considerable amounts of money. This is done by closely monitoring a set of call-related parameters for each [user,destination] pair, together with sets of provisioned alerting thresholds.

March 16, 2015, at 08:18 PM by liviu -
Changed line 30 from:

In order to create the fraud_detection table, first make sure opensipsctlrc file contains the desired SQL engine, DB name and credentials:

to:

In order to create the fraud_detection table, first make sure your opensipsctlrc file contains the desired SQL engine, DB name and credentials:

March 16, 2015, at 08:17 PM by liviu -
Changed line 53 from:

fraud_detection table

to:

fraud_detection table example

March 16, 2015, at 08:17 PM by liviu -
Added lines 55-56:

\\

March 16, 2015, at 08:16 PM by liviu -
Changed line 44 from:

The following is an example of a fraud detecting profile for destination prefix "+99". Note that all rules belong to the same profile: 1.

to:

The following is an example of a fraud detecting profile for destination prefix "+99". Note that all rules belong to the same profile: 1.

March 16, 2015, at 08:15 PM by liviu -
Changed line 58 from:
  • Rule 1 will obviously match from 09:00 to 17:00, Monday to Friday. It will trigger a fraud warning each time the same user either:
to:
  • Rule 1 will obviously match from 09:00 to 17:00, Monday to Friday. It will trigger a fraud warning event/error each time the same user either:
Changed line 64 from:
  • The same Rule 1 will trigger a fraud critical each time the same user either:
to:
  • The same Rule 1 will trigger a fraud critical event/error each time the same user either:
March 16, 2015, at 08:14 PM by liviu -
Changed line 62 from:
  • attempts to make more than 2 simultaneous calls
to:
  • attempts to make 3 or 4 simultaneous calls
March 16, 2015, at 08:14 PM by liviu -
Changed line 63 from:
  • makes more than 5 consecutive calls to the same destination
to:
  • makes between 6 and 19 consecutive calls to the same destination
March 16, 2015, at 08:12 PM by liviu -
Changed line 61 from:
  • makes a new call, having made at least 15 calls in the current interval
to:
  • makes a new call, having made between 15 and 33 calls in the current interval
March 16, 2015, at 08:10 PM by liviu -
Changed line 58 from:
  • Rule 1 will obviously match from 09:00 to 17:00, Monday to Friday. It will trigger a fraud warning each time the same user either:
to:
  • Rule 1 will obviously match from 09:00 to 17:00, Monday to Friday. It will trigger a fraud warning each time the same user either:
Changed line 64 from:
  • The same Rule 1 will trigger a fraud critical each time the same user either:
to:
  • The same Rule 1 will trigger a fraud critical each time the same user either:
March 16, 2015, at 08:10 PM by liviu -
Changed lines 58-63 from:
  • Rule 1 will obviously match between 09:00 and 17:00, from Monday to Friday. It will trigger a fraud warning each time the same user either:
    • has made 3 or 4 calls within the last minute
    • makes one call lasting at least 120 minutes
    • makes a new call, having made at least 15 calls in the current interval
    • attempts to make more than 2 simultaneous calls
    • makes more than 5 consecutive calls to the same destination
to:
  • Rule 1 will obviously match from 09:00 to 17:00, Monday to Friday. It will trigger a fraud warning each time the same user either:
    • has made 3 or 4 calls within the last minute
    • makes one call lasting at least 120 minutes
    • makes a new call, having made at least 15 calls in the current interval
    • attempts to make more than 2 simultaneous calls
    • makes more than 5 consecutive calls to the same destination
  • The same Rule 1 will trigger a fraud critical each time the same user either:
    • has made at least 5 calls within the last minute
    • makes one call lasting at least 220 minutes
    • makes a new call, having made at least 34 calls in the current interval
    • attempts to make at least 5 simultaneous calls
    • makes at least 20 consecutive calls to the same destination
March 16, 2015, at 08:05 PM by liviu -
Changed lines 48-51 from:
11+9909:0017:00Mon-Fri3580220163535620
21+9917:0123:59Mon-Fri35140250213535826
31+9900:0008:59Mon-Fri3460160102034515
41+9900:0023:59Sat,Sun351802902440351230
to:
11+9909:0017:00Mon-Fri35120220163535620
21+9917:0123:59Mon-Fri35160250213535826
31+9900:0008:59Mon-Fri3480160102034515
41+9900:0023:59Sat,Sun351902902440351230
Changed line 59 from:
  • has made 2 or 3 calls within the last minute
to:
  • has made 3 or 4 calls within the last minute
Changed lines 61-63 from:
  • makes a new call, having made at least 4 calls in the current interval
  • attempts to make more than 1 simultaneous call
  • makes more than 1 consecutive calls to the same destination
to:
  • makes a new call, having made at least 15 calls in the current interval
  • attempts to make more than 2 simultaneous calls
  • makes more than 5 consecutive calls to the same destination
March 16, 2015, at 08:03 PM by liviu -
Changed lines 48-51 from:
11+9909:0017:00Mon-Fri241206005101225
21+9917:0123:59Mon-Fri1260300131111
31+9900:0008:59Mon-Fri1260300131111
41+9900:0023:59Sat,Sun113060111111
to:
11+9909:0017:00Mon-Fri3580220163535620
21+9917:0123:59Mon-Fri35140250213535826
31+9900:0008:59Mon-Fri3460160102034515
41+9900:0023:59Sat,Sun351802902440351230
Changed line 59 from:
  • makes 2 calls within the last minute
to:
  • has made 2 or 3 calls within the last minute
March 16, 2015, at 07:46 PM by liviu -
Changed line 44 from:

The following is an example of a fraud detecting profile for destination prefix "+99".

to:

The following is an example of a fraud detecting profile for destination prefix "+99". Note that all rules belong to the same profile: 1.

Added lines 55-63:

Additional explanations:

  • Rule 1 will obviously match between 09:00 and 17:00, from Monday to Friday. It will trigger a fraud warning each time the same user either:
    • makes 2 calls within the last minute
    • makes one call lasting at least 120 minutes
    • makes a new call, having made at least 4 calls in the current interval
    • attempts to make more than 1 simultaneous call
    • makes more than 1 consecutive calls to the same destination
March 16, 2015, at 07:32 PM by liviu -
Changed line 15 from:

With the help of the dialog module, fraud_detection is able to closely monitor the following call-related statistics:

to:

With the help of the dialog module, fraud_detection is able to closely monitor the following call-related statistics for each user:

March 16, 2015, at 07:31 PM by liviu -
Deleted line 45:

fraud_detection table

Added line 53:

fraud_detection table

March 16, 2015, at 07:31 PM by liviu -
Added lines 43-44:

The following is an example of a fraud detecting profile for destination prefix "+99".

Deleted line 54:
March 16, 2015, at 07:24 PM by liviu -
Deleted line 41:
Deleted line 51:
March 16, 2015, at 07:22 PM by liviu -
Changed lines 30-31 from:

In order to create the fraud_detection table, edit the opensipsctlrc file and specify the SQL engine, DB name and credentials:

to:

In order to create the fraud_detection table, first make sure opensipsctlrc file contains the desired SQL engine, DB name and credentials:

Deleted line 40:
March 16, 2015, at 07:18 PM by liviu -
Changed line 22 from:

Note: some of the above statistics require a user-provisioned time interval to be sampled upon

to:

Note: some of the above statistics require a user-provisioned time interval to be sampled upon (see 'Table provisioning' below)

March 16, 2015, at 07:16 PM by liviu -
March 16, 2015, at 07:15 PM by liviu -
Changed lines 29-31 from:

In order to create

to:

Table creation

In order to create the fraud_detection table, edit the opensipsctlrc file and specify the SQL engine, DB name and credentials:

    vim /usr/local/etc/opensips/opensipsctlrc

Now you can add the extra OpenSIPS tables:

    opensipsdbctl extra

Table provisioning

Changed line 133 from:

@]

to:

@]

March 16, 2015, at 06:27 PM by liviu -
Changed lines 6-20 from:

Tutorial Overview

The purpose of this tutorial is to help you understand how the fraud detection module works and also how it should be used. After reading this tutorial you should understand which functions this module provides and also how to use it in order to determine strange patterns of sip calls.

Current features

As stated in the Chapter 1 of the documentation, the module monitors 5 parameters which are updated every time the check_fraud function is called (i.e each time a call is made). For each set of number prefix and username, unique values of the 5 parameters will be kept and monitored. Each time a value is altered, it will be compared to a threshold value. There are two threshold values for each of the 5 parameters (warning and critical thresholds), thus making a total of 10 values. This threshold values along with a time interval in which they are applicable form a so-called rule. It's the admin's job to provide the fraud rules to OpenSIPs through the db interface.

Future directions for the module include adding more compression algorithms and support fore more types of routes.

Example scenario and DB provisioning

Suppose our OpenSIPs instance is responsible for routing calls to many countries as well as to the FarFarAway country which has the +99 phone prefix. We know that there are a lot of hustlers in this fictional country and if a SIP account was hijacked it could cost our company a huge amount of money by making phoney calls to FarFarAway. So, we are going to look for suspicious patterns in calls to this country. For this we are going to insert four different rules:

to:

Introduction

Fraudulent calls have been a part of VoIP since its very beginnings. Typically, there are two ways through which a malicious user can gain permission to place calls through a VoIP platform: account hijacking and weak platform security.

The module provides a way of detecting suspicious calls from the same users to the same destinations might would otherwise likely end up costing the affected VoIP account (or the VoIP provider!) considerable amounts of money. This is done by closely monitoring a set of call-related parameters for each [user,destination] pair, together with sets of provisioned alerting thresholds.

Module Overview

Functionality

With the help of the dialog module, fraud_detection is able to closely monitor the following call-related statistics:

  • calls-per-minute
  • call duration
  • total calls
  • concurrent calls
  • consecutive calls to the same destination

Note: some of the above statistics require a user-provisioned time interval to be sampled upon


Validation of a check_fraud() call may be done either with its return code or through the event route. (scripting examples below)

DB provisioning

In order to create

Added lines 43-55:

Current features

As stated in the Chapter 1 of the documentation, the module monitors 5 parameters which are updated every time the check_fraud function is called (i.e each time a call is made). For each set of number prefix and username, unique values of the 5 parameters will be kept and monitored. Each time a value is altered, it will be compared to a threshold value. There are two threshold values for each of the 5 parameters (warning and critical thresholds), thus making a total of 10 values. This threshold values along with a time interval in which they are applicable form a so-called rule. It's the admin's job to provide the fraud rules to OpenSIPs through the db interface.

Future directions for the module include adding more compression algorithms and support fore more types of routes.

Example scenario and DB provisioning

Suppose our OpenSIPs instance is responsible for routing calls to many countries as well as to the FarFarAway country which has the +99 phone prefix. We know that there are a lot of hustlers in this fictional country and if a SIP account was hijacked it could cost our company a huge amount of money by making phoney calls to FarFarAway. So, we are going to look for suspicious patterns in calls to this country. For this we are going to insert four different rules:

Deleted lines 120-121:
November 29, 2014, at 06:30 PM by andrei_datcu -
November 29, 2014, at 06:30 PM by andrei_datcu -
Changed line 69 from:
		check_fraud("$fU", "$du", "1");
to:
		check_fraud("$fU", "$dU", "1");
November 29, 2014, at 06:28 PM by andrei_datcu -
Changed line 69 from:
		check_fraud("$fU", "$dU", "1");
to:
		check_fraud("$fU", "$du", "1");
November 29, 2014, at 06:25 PM by andrei_datcu -
Added lines 79-96:


Optionally, we can bind the warning and critical events

event_route[E_FRD_WARNING] {

	fetch_event_params("$var(param);$var(val);$var(thr);$var(user);$var(number);$var(ruleid)");
	xlog("E_FRD_WARNING: $var(param);$var(val);$var(thr);$var(user);$var(number);$var(ruleid)\n");
}

event_route[E_FRD_CRITICAL] {

	fetch_event_params("$var(param);$var(val);$var(thr);$var(user);$var(number);$var(ruleid)");
	xlog("E_FRD_CRITICAL: $var(param);$var(val);$var(thr);$var(user);$var(number);$var(ruleid)\n");
}

November 29, 2014, at 06:24 PM by andrei_datcu -
Added line 46:


Added line 54:


Changed lines 60-78 from:
to:


Let's assume that for each INITIAL INVITE we want to check and update the fraud parameters

route{
	if (has_totag()) {
		loose_route();
	}
	else {
		record_route();
		check_fraud("$fU", "$dU", "1");
		if ($rc < 0) {
			xlog("Problems for user $fU rc=$rc\n");
		}
	}
	t_relay();
}

Some issues can be identified on the spot, hence the check of the return code. Please refer to the module's documentation for the return code's meaning. Please note the last parameter of the check_fraud function: it's the profile id we set earlier.

November 29, 2014, at 06:18 PM by andrei_datcu -
Added lines 52-57:

Optionally, we load the event_route module to bind the warning and critical events to an event route

loadmodule "event_route.so"
November 29, 2014, at 06:16 PM by andrei_datcu -
Changed lines 46-53 from:

Then we set the

to:

Then we set the mandatory parameters

modparam("drouting", "db_partitions_url", "mysql://root:123456@localhost/opensips")
modparam("drouting", "use_partitions", 1)
modparam("fraud_detection", "db_url", "mysql://root:123456@localhost/opensips")
November 29, 2014, at 06:08 PM by andrei_datcu -
Changed lines 37-46 from:
to:

Example script

Firstly, we load the dependencies and the fraud_detection module

loadmodule "drouting.so"
loadmodule "dialog.so"
loadmodule "fraud_detection.so"

Then we set the

November 29, 2014, at 06:00 PM by andrei_datcu -
Changed lines 32-33 from:

The first rule sets the thresholds for all the calls made in the working hours (9-17) in the working days to all the numbers starting with +99. Note that we expect everything anything between 5 and 10 calls during this period to be possible although not probable. However, more than two calls initiated in a single minute from a single user will raise a warning. Furthermore, we expect that more than one concurrent call from the same user to be a problem. If a user calls to a number starting with +99 twice in a row (that is without calling to any other number between this calls) will also raise an alarm. The second and the third rules are for time periods outside the working hours, but in the working days. Note, that we still expect some calls to be made during this periods (from people who arrive early at the office or from people who stay in late).

to:

The first rule sets the thresholds for all the calls made in the working hours (9-17) in the working days to all the numbers starting with +99. Note that we expect anything between 5 and 10 calls during this period to be possible although not probable. However, more than two calls initiated in a single minute from a single user will raise a warning. Furthermore, we expect that more than one concurrent call from the same user to be a problem. If a user calls a number starting with +99 twice in a row (that is without calling any other number between this calls) will also raise an alarm. The second and the third rules are for time periods outside the working hours, but in the working days. Note that we still expect some calls to be made during this periods (from people who arrive early at the office or from people who stay in late).

November 29, 2014, at 05:58 PM by andrei_datcu -
Added line 35:

Note, that all the rules have the same profile id. Basically, this means that they are from the same logical sub-set of rules. Every call of the check_fraud function will need a profile id.

November 29, 2014, at 05:56 PM by andrei_datcu -
Changed lines 32-34 from:

The first rule sets the thresholds for all the calls made in the working hours (9-17) in the working days to all the numbers starting with +99.

to:

The first rule sets the thresholds for all the calls made in the working hours (9-17) in the working days to all the numbers starting with +99. Note that we expect everything anything between 5 and 10 calls during this period to be possible although not probable. However, more than two calls initiated in a single minute from a single user will raise a warning. Furthermore, we expect that more than one concurrent call from the same user to be a problem. If a user calls to a number starting with +99 twice in a row (that is without calling to any other number between this calls) will also raise an alarm. The second and the third rules are for time periods outside the working hours, but in the working days. Note, that we still expect some calls to be made during this periods (from people who arrive early at the office or from people who stay in late). The fourth rule is for weekends. Here, almost any call should raise an alarm.

November 29, 2014, at 05:48 PM by andrei_datcu -
Added line 32:

The first rule sets the thresholds for all the calls made in the working hours (9-17) in the working days to all the numbers starting with +99.

November 29, 2014, at 05:46 PM by andrei_datcu -
Added lines 30-33:


November 29, 2014, at 05:40 PM by andrei_datcu -
Changed lines 19-20 from:

Suppose our OpenSIPs instance is responsible for routing calls to many countries as well as to the FarFarAway country which has the +99 phone prefix. We know that there are a lot of hustlers in this fictional country and if a SIP account was hijacked it could cost our company a huge amount of money by making phoney calls to FarFarAway. So, we are going to look for suspicious patterns in calls to this country. For this we are going to insert two different rules:

to:

Suppose our OpenSIPs instance is responsible for routing calls to many countries as well as to the FarFarAway country which has the +99 phone prefix. We know that there are a lot of hustlers in this fictional country and if a SIP account was hijacked it could cost our company a huge amount of money by making phoney calls to FarFarAway. So, we are going to look for suspicious patterns in calls to this country. For this we are going to insert four different rules:

Changed lines 29-30 from:
c22
to:
November 29, 2014, at 05:39 PM by andrei_datcu -
Changed line 28 from:
21+9917:0123:59Mon-Fri1260300131111
to:
41+9900:0023:59Sat,Sun113060111111
November 29, 2014, at 05:37 PM by andrei_datcu -
Changed lines 26-27 from:
c21
[@c22
to:
21+9917:0123:59Mon-Fri1260300131111
31+9900:0008:59Mon-Fri1260300131111
21+9917:0123:59Mon-Fri1260300131111
November 29, 2014, at 05:31 PM by andrei_datcu -
Changed line 24 from:
ruleidprofileidprefixstart_hourend_hourdaysoftheweekcpm_warningcpm_criticalcall_duration_warningcall_duration_criticaltotal_calls_warningtotal_calls_criticalconcurrent_calls_warningconcurrent_calls_criticalsequential_calls_warningsequential_calls_critical
to:
rule idprofile idprefixstart hourend hourdays of the weekcpm warningcpm criticalcall duration warningcall duration criticaltotal calls warningtotal calls criticalconcurrent calls warningconcurrent calls criticalsequential calls warningsequential calls critical
November 29, 2014, at 05:27 PM by andrei_datcu -
Changed line 25 from:
11
to:
11+9909:0017:00Mon-Fri241206005101225
November 29, 2014, at 05:10 PM by andrei_datcu -
November 29, 2014, at 05:09 PM by andrei_datcu -
Changed lines 25-28 from:
c1
c2
to:
11
November 29, 2014, at 04:36 PM by andrei_datcu -
November 29, 2014, at 04:27 PM by andrei_datcu -
Changed line 24 from:
With Script HelperClassic Script
to:
ruleidprofileidprefixstart_hourend_hourdaysoftheweekcpm_warningcpm_criticalcall_duration_warningcall_duration_criticaltotal_calls_warningtotal_calls_criticalconcurrent_calls_warningconcurrent_calls_criticalsequential_calls_warningsequential_calls_critical
November 29, 2014, at 04:27 PM by andrei_datcu -
Changed lines 24-25 from:

ruleid || profileid || prefix || start_hour || end_hour || daysoftheweek || cpm_warning || cpm_critical || call_duration_warning || call_duration_critical || total_calls_warning || total_calls_critical || concurrent_calls_warning || concurrent_calls_critical || sequential_calls_warning || sequential_calls_critical ||

to:
With Script HelperClassic Script

c1

November 29, 2014, at 04:23 PM by andrei_datcu -
Changed line 24 from:
With Script HelperClassic Script
to:

ruleid || profileid || prefix || start_hour || end_hour || daysoftheweek || cpm_warning || cpm_critical || call_duration_warning || call_duration_critical || total_calls_warning || total_calls_critical || concurrent_calls_warning || concurrent_calls_critical || sequential_calls_warning || sequential_calls_critical ||

November 29, 2014, at 04:17 PM by andrei_datcu -
Added lines 27-29:

@]||

c21
[@c22
November 29, 2014, at 04:16 PM by andrei_datcu -
Added lines 20-27:


fraud_detection table

With Script HelperClassic Script
c1
c2
November 29, 2014, at 04:06 PM by andrei_datcu -
Changed line 19 from:

Suppose our OpenSIPs instance is responsible for routing calls to many countries as well as to the FarFarAway country which has the +99 phone prefix. We know that there are a lot of hustlers in this fictional country and if a SIP account was hijacked it could cost our company a huge amount of money by making phoney calls to FarFarAway. So, we are going to look for suspicious patterns in calls to this country.

to:

Suppose our OpenSIPs instance is responsible for routing calls to many countries as well as to the FarFarAway country which has the +99 phone prefix. We know that there are a lot of hustlers in this fictional country and if a SIP account was hijacked it could cost our company a huge amount of money by making phoney calls to FarFarAway. So, we are going to look for suspicious patterns in calls to this country. For this we are going to insert two different rules:

November 29, 2014, at 04:05 PM by andrei_datcu -
Changed lines 19-20 from:

Suppose our OpenSIPs instance is responsible for routing calls to many countries as well as to the FarFarAway country which has the +99 phone prefix. We know that there are a lot of hustlers in this fictional country and if a SIP account was hijacked it could cost our company a huge amount of money by making phoney calls to FarFarAway

to:

Suppose our OpenSIPs instance is responsible for routing calls to many countries as well as to the FarFarAway country which has the +99 phone prefix. We know that there are a lot of hustlers in this fictional country and if a SIP account was hijacked it could cost our company a huge amount of money by making phoney calls to FarFarAway. So, we are going to look for suspicious patterns in calls to this country.

November 29, 2014, at 04:02 PM by andrei_datcu -
Changed lines 15-19 from:

Future directions for the module include adding more compression algorithms and support fore more types of routes.

to:

Future directions for the module include adding more compression algorithms and support fore more types of routes.

Example scenario and DB provisioning

Suppose our OpenSIPs instance is responsible for routing calls to many countries as well as to the FarFarAway country which has the +99 phone prefix. We know that there are a lot of hustlers in this fictional country and if a SIP account was hijacked it could cost our company a huge amount of money by making phoney calls to FarFarAway

November 29, 2014, at 03:53 PM by andrei_datcu -
Changed line 13 from:

As stated in the Chapter 1 of the documentation, the module monitors 5 parameters which are updated every time the check_fraud function is called (i.e each time a call is made). For each set of number prefix and username, unique values of the 5 parameters will be kept and monitored. Each time a value is altered, it will be compared to threshold value. There are two threshold values for each of the 5 parameters, thus making a total of 10 values. This thresholds along with a time interval in which they area applicable form a so-called rule. It's the admin's job to provide the fraud rules to OpenSIPs through the db interface.

to:

As stated in the Chapter 1 of the documentation, the module monitors 5 parameters which are updated every time the check_fraud function is called (i.e each time a call is made). For each set of number prefix and username, unique values of the 5 parameters will be kept and monitored. Each time a value is altered, it will be compared to a threshold value. There are two threshold values for each of the 5 parameters (warning and critical thresholds), thus making a total of 10 values. This threshold values along with a time interval in which they are applicable form a so-called rule. It's the admin's job to provide the fraud rules to OpenSIPs through the db interface.

November 29, 2014, at 03:50 PM by andrei_datcu -
Changed line 13 from:

As stated in the Chapter 1 of the documentation, the module monitors 5 parameters which are updated every time the check_fraud function is called (i.e each time a call is made). For each set of number prefix and username, unique values of the 5 parameters will be kept and monitored. However, it's the admin's duty to define

to:

As stated in the Chapter 1 of the documentation, the module monitors 5 parameters which are updated every time the check_fraud function is called (i.e each time a call is made). For each set of number prefix and username, unique values of the 5 parameters will be kept and monitored. Each time a value is altered, it will be compared to threshold value. There are two threshold values for each of the 5 parameters, thus making a total of 10 values. This thresholds along with a time interval in which they area applicable form a so-called rule. It's the admin's job to provide the fraud rules to OpenSIPs through the db interface.

November 29, 2014, at 03:43 PM by andrei_datcu -
Changed lines 9-15 from:

this tutorial you should understand which functions this module provides and also how to use it in order to determine strange patterns of sip calls.

to:

this tutorial you should understand which functions this module provides and also how to use it in order to determine strange patterns of sip calls.

Current features

As stated in the Chapter 1 of the documentation, the module monitors 5 parameters which are updated every time the check_fraud function is called (i.e each time a call is made). For each set of number prefix and username, unique values of the 5 parameters will be kept and monitored. However, it's the admin's duty to define

Future directions for the module include adding more compression algorithms and support fore more types of routes.

November 29, 2014, at 02:43 PM by andrei_datcu -
Changed lines 4-9 from:

to:

Tutorial Overview

The purpose of this tutorial is to help you understand how the fraud detection module works and also how it should be used. After reading this tutorial you should understand which functions this module provides and also how to use it in order to determine strange patterns of sip calls.

November 29, 2014, at 02:41 PM by andrei_datcu -
Changed lines 1-4 from:

Hello World

to:
Documentation -> Tutorials -> Using the Fraud Detection module

This page has been visited 1569 times. (:toc-float Table of Content:)


November 28, 2014, at 08:34 PM by andrei_datcu -
Added line 1:

Hello World


Page last modified on November 14, 2016, at 11:41 AM