Hi Denis,

Some interesting data! Here's some analysis:

1) First we have this detection suite:

4/2/18 0:12 270675427b234658 X.X.X.X 1111111111 8102463894929 Fraud_detectead 0

This is due to the "cpm" throttling (> 5 cpm within the last 2 minutes) hitting. Once he makes a pause until 0:15, he is able to place more calls.

2) Next, another detection:

4/2/18 0:22 2d37337b576cdf52 X.X.X.X 1111111111 810213550011711 Fraud_detectead 0

This time it's due to the "total calls" hitting, since he had placed 29 calls, and the 30th one hits the "critical" threshold.

3) He seems to be able to place another call 3 hours later:

4/2/18 3:20 20580b68fb2d185b X.X.X.X 1111111111 810355692075970 OK 780

and another 28 calls within the next 5 hours, before finally getting blocked again:

4/2/18 8:32 5f3aa44b6451bd4c X.X.X.X 1111111111 810355692075972 Fraud_detectead 0

So the "total calls" limit is hitting again, which is good.

The question is: why did the "total calls" reset for this guy? One possible answer could be timezone-related. I'm not sure whether the "0:22" from the CDR correlates with the local OpenSIPS machine time. Remember that OpenSIPS resets all stats if it detects a "new day" or a "new interval". IMO, the day change is the most likely cause of this behavior.

Let me know if the above clears your questions. Also, one of your SIP statuses has a typo: "Fraud_detectead".

Cheers,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 04.04.2018 14:00, Denis via Users wrote:
Liviu, and another interesting case.
Here, https://yadi.sk/i/-vRrJXtz3U5m2Z, you can find cdr of the fraud case.
In the table:
time - time of the call
callid - sip callid
src_domain - source ip
src_user - caller (from one number)
dst_user - callee
sip_reason and duration - column from acc table.
Several sip callid with the same value deal with serial forking.
So, sip_reason "fraud_detected" means that fraud module detected bad calls. Why do we have a situation when after fraud detected there are successful bad calls?
Fraud profile is the same as mentioned early.
Thank you.
--
С уважением, Денис.
Best regards, Denis
03.04.2018, 18:28, "Liviu Chircu" <li...@opensips.org>:

Hmmm... indeed, the "sequential calls" only reset if you dial a different number.

If the other stats reset at midnight/interval change, I don't see why this specific one should be different. To me, it looks like a bug. Do you agree?

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com <http://www.opensips-solutions.com/>
On 03.04.2018 16:49, Denis via Users wrote:
Hello Liviu!
I am sorry, i totally missed one important thing - serial forking)))
I.e. i had 52 records in accounting, but several of them leads to one call. As a result i had exactly 29 calls before fraud module became block subsequent calls.
About counters reset i understood. Thank you.
The last question about "sequential_calls". This counter does not reset? Even in manual mode?
Thank you.
--
С уважением, Денис.
Best regards, Denis
03.04.2018, 15:30, "Liviu Chircu" <li...@opensips.org> <mailto:li...@opensips.org>:

Hi Denis,

Regarding the "52 calls" vs. 25/30 limits, are you sure all 52 calls were made by the same user? Keep in mind that all fraud_detection module stats are per-user counters, and not global counters. If they really were all made by the same user, please let me know and I will double-check my tests.

The "cpm", "total_calls" and "concurrent_calls" reset either on an interval change or at midnight (new day ahead). This leads to a possible undetected abuse of up to 2x your provisioned "cpm", "total_calls" or "concurrent_calls", if the malicious user places "limit - 1" events before the reset, followed by another "limit - 1" events past the reset. If this is too much for you, then your provisioned limits (thresholds) are incorrect, and you should simply cut them in half.

Best regards,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com <http://www.opensips-solutions.com/>
On 22.03.2018 09:59, Denis via Users wrote:
Hello!
Is there any idea about the problem?
Thank you.
--
С уважением, Денис.
Best regards, Denis
16.03.2018, 15:22, "Denis via Users" <users@lists.opensips.org> <mailto:users@lists.opensips.org>:
Hello!
I am sorry that it was early, but anyway.
Server:: OpenSIPS (2.2.5 (x86_64/linux))
Fraud_module has been activated.
Profile data
17.02.18 20:55 Opensips received first fraud call.
And before Opensips detected fraud there were 52 yet calls to 810 prefix. First question is why it didn`t detected fraud early (dialing with total_calls, for example)?
Then.
Till the end of 17.02 Opensips blocked the calls from client to 810, but in 18.02 i can see success fraud calls to 810 from the client again.
Second question is why? Opensips resets count every new day?
Thank you.
--
С уважением, Денис.
Best regards, Denis
,

_______________________________________________
Users mailing list
Users@lists.opensips.org <mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
Users@lists.opensips.org <mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
,

_______________________________________________
Users mailing list
Users@lists.opensips.org <mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
Users@lists.opensips.org <mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
,

_______________________________________________
Users mailing list
Users@lists.opensips.org <mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to