[SR-Users] pike parameters doup when have dinamyc ip clients and scanners

Daniel Tryba d.tryba at pocos.nl
Wed Aug 14 10:55:01 CEST 2019


On Tue, Aug 13, 2019 at 03:57:36PM -0430, PICCORO McKAY Lenz wrote:
> # this it's my setup for pike due the dinamyc ip and devices over the internet:
> modparam("pike", "sampling_time_unit", 4)
> modparam("pike", "reqs_density_per_unit", 80)
> modparam("pike", "remove_latency", 60)
> ...
> route {
>   if (!pike_check_req()) {
>     xlog("L_ALERT","ALERT: pike block $rm from $fu (IP:$si:$sp)\n");
>     exit;
>   }
>  ...
> }
> 
> 
> I put the remove latency in 60, so then due are dinamycally must
> remian in memory more (due any one will be a possible clilent), just
> ban if there are 180 (60*3) request each 4 seconds,
> 
> it's a good configuration or maybe i'm wrong please help me!

remove_latency doesn't do what you think it does:
https://kamailio.org/docs/modules/5.2.x/modules/pike.html#pike.p.remove_latency
=====
3.3. remove_latency (integer)

Specifies for how long the IP address will be kept in memory after the
last request from that IP address. It's a sort of timeout value, in
seconds. Note that it is not the duration to keep the IP in state
'blocked'. An IP is unblocked next occurrence of 'sampling_time_unit'
that does not exceed 'reqs_density_per_unit'. Keeping an IP in memory
results in faster reaching of blocked state -- see the notes about the
limits of getting to state 'blocked'. 
=====

With above settings a client will be banned if it sends more than 80
messages per 4s. And ipaddresses will be tracked by pike for at max 60s
after the last request.

The ban time is specified in the htable:
# ----- htable params -----
# ip ban htable with autoexpire after 5 minutes
modparam("htable", "htable", "ipban=>size=8;autoexpire=300;")

Wheter the config id good depends on the behavior of your clients. A
simple SIP phone will only send a couple of messages per second. A
multitenant machine can send many depending on the number of channels
and trunks configured (and the way it may REGISTER, e.g. asterisk tries
to REGISTER all trunks at the same time (sequentially))





More information about the sr-users mailing list