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(a)gmail.com> wrote:
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:
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(a)gmail.com>
Sent: Sunday, March 22, 2020 4:37 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>rg>; JR
Richardson <jmr.richardson(a)gmail.com>om>; SIP Router - Kamailio (OpenSER) and SIP
Express Router (SER) - Users Mailing List <sr-users(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla --
www.asipto.com
www.twitter.com/miconda --
www.linkedin.com/in/miconda
--
Daniel-Constantin Mierla --
www.asipto.com
www.twitter.com/miconda --
www.linkedin.com/in/miconda