Documentation |
Documentation.Tutorials-FraudDetection-2-3 HistoryShow minor edits - Show changes to markup November 14, 2016, at 11:41 AM
by
- Changed line 71 from:
to:
November 10, 2016, at 04:01 PM
by
- 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
- Changed lines 52-55 from:
to:
Changed line 66 from:
to:
Changed line 72 from:
to:
March 18, 2015, at 09:54 PM
by
- 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:
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 scriptto:
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 scriptMarch 18, 2015, at 06:39 PM
by
- 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
- Changed lines 79-80 from:
Current featuresto:
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 provisioningSuppose 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
- 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:
to:
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
- 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 - March 17, 2015, at 04:55 PM
by
- 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
- 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
- Changed line 121 from:
check_fraud("$fU", "$dU", "1"); to:
check_fraud("$fU", "$rU", "1"); March 17, 2015, at 11:24 AM
by
- Changed line 62 from:
to:
March 17, 2015, at 11:23 AM
by
- Changed line 62 from:
to:
March 17, 2015, at 11:16 AM
by
- Changed line 60 from:
to:
March 17, 2015, at 11:15 AM
by
- Changed line 66 from:
to:
March 17, 2015, at 11:14 AM
by
- Changed line 58 from:
Additional explanations: to:
Data interpretation: March 17, 2015, at 11:12 AM
by
- 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
- 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
- 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
- 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
- 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
- Changed line 53 from:
fraud_detection table to:
fraud_detection table example March 16, 2015, at 08:17 PM
by
- Added lines 55-56:
\\ March 16, 2015, at 08:16 PM
by
- 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
- Changed line 58 from:
to:
Changed line 64 from:
to:
March 16, 2015, at 08:14 PM
by
- Changed line 62 from:
to:
March 16, 2015, at 08:14 PM
by
- Changed line 63 from:
to:
March 16, 2015, at 08:12 PM
by
- Changed line 61 from:
to:
March 16, 2015, at 08:10 PM
by
- Changed line 58 from:
to:
Changed line 64 from:
to:
March 16, 2015, at 08:10 PM
by
- Changed lines 58-63 from:
to:
March 16, 2015, at 08:05 PM
by
- Changed lines 48-51 from:
to:
Changed line 59 from:
to:
Changed lines 61-63 from:
to:
March 16, 2015, at 08:03 PM
by
- Changed lines 48-51 from:
to:
Changed line 59 from:
to:
March 16, 2015, at 07:46 PM
by
- 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:
March 16, 2015, at 07:32 PM
by
- 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
- Deleted line 45:
fraud_detection table Added line 53:
fraud_detection table March 16, 2015, at 07:31 PM
by
- 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
- Deleted line 41:
Deleted line 51:
March 16, 2015, at 07:22 PM
by
- 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
- 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 - March 16, 2015, at 07:15 PM
by
- Changed lines 29-31 from:
In order to create to:
Table creationIn 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 provisioningChanged line 133 from:
@] to:
@] March 16, 2015, at 06:27 PM
by
- Changed lines 6-20 from:
Tutorial OverviewThe 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 featuresAs 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 provisioningSuppose 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:
IntroductionFraudulent 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 OverviewFunctionalityWith the help of the dialog module, fraud_detection is able to closely monitor the following call-related statistics:
Note: some of the above statistics require a user-provisioned time interval to be sampled upon
DB provisioningIn order to create Added lines 43-55:
Current featuresAs 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 provisioningSuppose 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 - November 29, 2014, at 06:30 PM
by
- Changed line 69 from:
check_fraud("$fU", "$du", "1"); to:
check_fraud("$fU", "$dU", "1"); November 29, 2014, at 06:28 PM
by
- Changed line 69 from:
check_fraud("$fU", "$dU", "1"); to:
check_fraud("$fU", "$du", "1"); November 29, 2014, at 06:25 PM
by
- 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
- Added line 46:
Added line 54:
Changed lines 60-78 from:
to:
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
- 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
- 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
- Changed lines 37-46 from:
to:
Example scriptFirstly, 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
- 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
- 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
- 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
- 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
- Added lines 30-33:
November 29, 2014, at 05:40 PM
by
- 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:
to:
November 29, 2014, at 05:39 PM
by
- Changed line 28 from:
to:
November 29, 2014, at 05:37 PM
by
- Changed lines 26-27 from:
to:
November 29, 2014, at 05:31 PM
by
- Changed line 24 from:
to:
November 29, 2014, at 05:27 PM
by
- Changed line 25 from:
to:
November 29, 2014, at 05:10 PM
by - November 29, 2014, at 05:09 PM
by
- Changed lines 25-28 from:
to:
November 29, 2014, at 04:36 PM
by - November 29, 2014, at 04:27 PM
by
- Changed line 24 from:
to:
November 29, 2014, at 04:27 PM
by
- 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:
c1 November 29, 2014, at 04:23 PM
by
- Changed line 24 from:
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
- Added lines 27-29:
@]||
November 29, 2014, at 04:16 PM
by
- Added lines 20-27:
November 29, 2014, at 04:06 PM
by
- 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
- 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
- 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 provisioningSuppose 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
- 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
- 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
- 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 featuresAs 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
- Changed lines 4-9 from:
to:
Tutorial OverviewThe 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
- Changed lines 1-4 from:
Hello World to:
Documentation -> Tutorials -> Using the Fraud Detection moduleThis page has been visited 1569 times. (:toc-float Table of Content:) November 28, 2014, at 08:34 PM
by
- Added line 1:
Hello World |