[OpenSIPS-Users] Fraud_detection module

[Denis]

Ok, Liviu, where this realization can be expected (if any)?

Thank you.

 mailto:denis7979 at mail.ru


The "sequential-calls" is the only statistic which may also benefit from a periodical reset (daily / weekly / monthly, etc.). IMO, calls-per-min / total-calls / concurrent-calls _should not_ reset to 0 at midnight.
Since a rule's "sequential-calls" cannot be easily reused with multiple reset intervals (it requires either small/big numbers), a check_fraud() parameter will not work so well. This information should be tied to the rule, either in a simplistic string "flags" column (with "d"/"w"/"m" as values), or we could even re-design "sequential_calls" into "seq_daily" / "seq_weekly" / "seq_monthly" and concurrently monitor 0 - 3 of them, depending on their values.
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 14.11.2016 12:17, Denis wrote:

Re: [OpenSIPS-Users] Fraud_detection module Hello, Liviu!

Thank you very much for your answer!
I understood my main mistake. I thought that "call duration" is the total value for all calls but not of only one.
Ok, "sequential-calls" may be that thing which can help to avoid such situation, but the main problem is (and as you wrote in the previous letter), that this value doesn`t go to 0 at the next period.
Because of this i have to increase this value to 5000, otherwise i blocked honest users.
Can "sequential-calls" be set to 0 at the next period?

mailto:denis7979 at mail.ru


Hi, Denis!
First of all, thank you for taking the time to gather this nice data! Looking at the calls, to me it looks like the module behaved as expected. Here are some thoughts:
- all call durations were less under 1500 seconds, while your fraud rule is set to 3600 seconds, so it never got triggered.
- the "calls-per-minute" rule worked! Your rule was set to max 6 cpm, thus calls #7 - #9 to prefix "810" were considered fraudulent (at 01:41), as the caller was starting to exceed this quota. The proper critical warnings were raised, calls blocked, emails sent.
- the attacker now _learned_ about your 6 cpm limitation and _lowered_ his cpm to 3 during the following 10 hours (until 11:08), thus bypassing the cpm rate limiting, managing to place 21 fraudulent calls.
It seems like the 21 successful fraudulent calls between 03:06 - 11:08 could _maybe_ have been avoided by setting a better value for "sequential-calls". This is a bit tricky though, as we also don't want to block calls of honest users because of false positives.
Regards,
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 11.11.2016 09:38, Denis wrote:

Re: [OpenSIPS-Users] Fraud_detection module Hello, Liviu!

OK, thank you.

Additionally i will ask you to analyze one case.
In attachment you can find a log of calls, which were made by one user some time ago (with the number 1234567). It`s a fraud.
Also i attached a piece of opensips.cfg related to a fraud detection (see script.txt). When critical event triggered Opensips sends email to some address (see script.txt).

As you can see in the call log, fraud began at 01:40 2016-10-01. Value of the field "sip_reason" "fraud_detected" means that fraud_module detects the fraud and a call was discarded by script logging (see script.txt)
First email about that i received at 01:41 with fraud param " calls per minute".
Next email i received only at 11:08 with fraud param "total calls".

Between these two time stamps i have no emails about fraud, and as you can see from the call log, there were many successful calls in this period with "big" duration.

Fraud_detection table had such content:
profileid = 1
prefix = 810
start_hour = 00:00
end_hour = 23:59
daysoftheweek = Mon-Sun
cpm_critical = 6
call_duration_critical = 3600
tatal_calls_critical = 30
concurant_calls_critical = 30
sequential_calls_critical = 5000

The questions is:
- Why module didn`t detect fraud based on "call duration"?

Thank you.

mailto:denis7979 at mail.ru


Upon looking through the source code, it seems that calls_per_min / total_calls / concurrent_calls are also reset to 0 every time a new rule is matched, or if the day has changed since we last matched the current rule.
I will make sure this info ^ is more easily accessible: either in a new tutorial section or the module doc.
Regards,
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 10.11.2016 16:29, Denis wrote:

Re: [OpenSIPS-Users] Fraud_detection module 

Hello, Liviu!

Thank you for your answer.

About 2)

"Calls per minute" - ok, but what about other parameters?
For example, "total calls"?
Suppose we have 09:00 - 17:00, Mon-Fri, and "total calls" = 30.
If in Mon user makes 25 calls, on Tue since 09:00 counts of  "total calls" begin from 0 or 25?

mailto:denis7979 at mail.ru


Hi, Deniz!
Answers below.
Regards,
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 10.11.2016 15:18, Denis wrote:

Re: Fraud_detection modul 

Hello!

Opensips 2.2.1

A couple of questions about fraud_detection:

1) In documentation says "consecutive calls to the same destination ". Same destination = same number, or prefix?
Same prefix, taken from the fraud detection rule 

2) At the beginning of the next period, a counts of events begin 0?
The module uses a gliding window of 60 seconds, in order to keep track of "calls per minute". When changing time intervals, hence putting new thresholds in place, the "calls per minute" will not reset. In other words, when switching intervals, the new "calls per minute" thresholds will initially work with calls placed during the last minute when the old thresholds were in place. 

3) is there any method to reset counts of events for certain user?
Currently there is no way of doing this.


4)  what is the value used to calculate duration in fraud_module, minutes or seconds?
It should be "seconds", I will fix the misleading example in the tutorial. 

______________________________________________ 
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20161114/a27e21f8/attachment.htm>