Hi All,
Please clarify the pike settings for SIP message count, the module Doc reports:
---- modparam("pike", "sampling_time_unit", 10)
modparam("pike", "reqs_density_per_unit", 30)
How many requests should be allowed per sampling_time_unit before blocking all the incoming request from that IP. Practically, the blocking limit is between ( let's have x=reqs_density_per_unit) x and 3*x for IPv4 addresses and between x and 8*x for IPv6 addresses.
-----
So the example above the SIP message rate is 30 messages within 10 seconds triggers an pike alert?
The description I'm confused on is "Practically, the blocking 'limit is between' (let's have x=reqs_density_per_unit) x and 3*x for IPv4"
The way this reads to me is the Pike alert could be triggered anywhere between 30 and 90 (3*30) messages within 10 second period. Am I reading this correctly? What determines when the pike trigger actually happens, could the trigger happen at say 56 messages within 10 seconds?
Thanks.
JR Richardson
Engineering for the Masses
Chasing the Azeotrope
JRx DistillCo
1'st Place Brisket
1'st Place Chili
Hello,
I am not very familiar with the code as I haven't written the module, but iirc, if it is an isolated IP, then it takes 3 x sampling_time_unit to block that IP if there is traffic from it at a rate of more than 30 requests (can be even 1000+ requests).
Then, an IP can be blocked after the first sampling_time_unit if it is part of a subnetwork (/24) that has other IP addresses already blocked.
As a simple rule, any IP is blocked for sure after 3 x sampling_time_unit with higher rate than the density and is kept block if it continues to send high volume of requests.
Cheers, Daniel
On 21.03.20 15:18, JR Richardson wrote:
Thanks Daniel,
That clear it up a bit. For my own edification, when I get a few minutes, I'll lab this up and throw some specific quantities of SIP packets and validate the time and density of trigger and report back. Maybe we can update the module documentation for clarity and remove some confusion.
JR
JR Richardson
Engineering for the Masses
Chasing the Azeotrope
JRx DistillCo
1'st Place Brisket
From: Daniel-Constantin Mierla miconda@gmail.com Sent: Sunday, March 22, 2020 4:37 AM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org; JR Richardson jmr.richardson@gmail.com; SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List sr-users@lists.sip-router.org Subject: Re: [SR-Users] Pike Module Clarification
Hello,
I am not very familiar with the code as I haven't written the module, but iirc, if it is an isolated IP, then it takes 3 x sampling_time_unit to block that IP if there is traffic from it at a rate of more than 30 requests (can be even 1000+ requests).
Then, an IP can be blocked after the first sampling_time_unit if it is part of a subnetwork (/24) that has other IP addresses already blocked.
As a simple rule, any IP is blocked for sure after 3 x sampling_time_unit with higher rate than the density and is kept block if it continues to send high volume of requests.
Cheers, Daniel
On 21.03.20 15:18, JR Richardson wrote:
Hi All,
Please clarify the pike settings for SIP message count, the module Doc reports:
---- modparam("pike", "sampling_time_unit", 10)
modparam("pike", "reqs_density_per_unit", 30)
How many requests should be allowed per sampling_time_unit before blocking all the incoming request from that IP. Practically, the blocking limit is between ( let's have x=reqs_density_per_unit) x and 3*x for IPv4 addresses and between x and 8*x for IPv6 addresses.
-----
So the example above the SIP message rate is 30 messages within 10 seconds triggers an pike alert?
The description I'm confused on is "Practically, the blocking 'limit is between' (let's have x=reqs_density_per_unit) x and 3*x for IPv4"
The way this reads to me is the Pike alert could be triggered anywhere between 30 and 90 (3*30) messages within 10 second period. Am I reading this correctly? What determines when the pike trigger actually happens, could the trigger happen at say 56 messages within 10 seconds?
Thanks.
JR Richardson
Engineering for the Masses
Chasing the Azeotrope
JRx DistillCo
1'st Place Brisket
1'st Place Chili
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hello,
improvements to the documentation are always more than welcome! Pike is a rather old module, not much touched lately, so its docs could be from long time ago. At some point I wanted to put some new code to allow defining more IP blocking trees and a few other enhancements, but other projects got into the way...
Cheers, Daniel
On 22.03.20 16:40, JR Richardson wrote:
I did some testing and found the "reqs_density_per_unit" is the actual limit/trigger within the "sampling_time_unit".
In this example: modparam("pike", "sampling_time_unit", 3) modparam("pike", "reqs_density_per_unit", 60)
If the pike module receives 59 SIP messages within 3 seconds from same IP address, there is no trigger, if 60 or more messages the trigger happens. So there is no multiplier as the documentation suggest, the reqs_density_per_unit is a hard limit within the sampling_time_unit.
For the documentation, section 3.2. reqs_density_per_unit (integer), maybe remove the "Practically, the blocking limit is between ( let's have x=reqs_density_per_unit) x and 3*x for IPv4 addresses and between x and 8*x for IPv6 addresses." This is the confusing part.
Thanks.
JR
On Sun, Mar 22, 2020 at 12:38 PM Daniel-Constantin Mierla miconda@gmail.com wrote:
Did you sent the requests from the same network as Kamailio IP or local host? I am not sure if has any impact, just checking to know when looking into the code.
You can also make a pull request on github project to update the docs based on your finding and make the content more clear -- you English is better than mine :-) .
Cheers, Daniel
On 23.03.20 14:16, JR Richardson wrote:
Not sure if you are aware but keep in mind this:
"The module does not implement any actions on blocking - it just simply reports that there is high traffic from an IP; what to do, is the administrator decision (via scripting)"
You have to script the actual blocking via a function like the below:
4.1. |pike_check_req()|
Process the source IP of the current request and return false if the IP was exceeding the blocking limit.
Return codes:
*
/1 (true)/- IP is not to be blocked or internal error occurred.
Warning
IMPORTANT: in case of internal error, the function returns true to avoid reporting the current processed IP as blocked. *
/-1 (false)/- IP is source of flooding, previously detected
*
/-2 (false)/- IP is detected as a new source of flooding - first time detection
On 3/22/20 11:40 AM, JR Richardson wrote:
-
Alex Balashov -
Andres -
Daniel-Constantin Mierla -
JR Richardson