13 Aug
2019
13 Aug
'19
11:27 p.m.
I read documentation for pike usage.. and have a doub.. what it's the
best for very dinamyc ip of my devices.. i mean, i'm just curious of
that very ironic and problematic scenario:
for the scanners i setup fail2ban but only when the scaning are
detecte.. but if i have the pike option how this:
# 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!
--
Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com
14 Aug
14 Aug
11:55 a.m.
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_lat…
=====
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))
3:47 p.m.
El mié., 14 de ago. de 2019 a la(s) 04:55, Daniel Tryba (d.tryba(a)pocos.nl)
escribió:
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)
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.
Thanks a lot, the language barrier confused all, you confirmed to me..
that the pike only are a tool to property ban with htable.. thanks o lot
But now have a doub, please guide me with that:
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))
you said: " A simple SIP phone will only send a couple of messages per
second"
so if i have that special case with dinamyc ip in clients.. who could be
better to not confuse those clients with intents of attacks?
oh, also i put for scanners that:
if($ua =~ "friendly-scanner") {
xlog("L_ALERT", "friendly scanning incoming $rm IP:$si:$sp - R:$ruri -
F:$fu - T:$tu - UA:$ua - $rm\n");
$sht(ipban=>$si) = 1;
drop();
}
so i ban the ip where the friendly scanner are made for a while, it's that
correct?
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
5:11 p.m.
On Wed, Aug 14, 2019 at 08:47:02AM -0400, PICCORO McKAY Lenz wrote:
you said: " A simple SIP phone will only send a
couple of messages per
second"
so if i have that special case with dinamyc ip in clients.. who could be
better to not confuse those clients with intents of attacks?
I'm not sure what you are trying to say here.
In my setups I have a limit of 64 requests per 2s. But I also have
whitelist (with/via the permissions module) for known high traffic
ipaddresses. Dimensioning the pike module for the known high traffic
hosts kind of defeats the purpose of using pike to detect strange
unwanted traffic. The correct numbers depend on your endpoints.
if(src_ip!=myself && !allow_address("2", "$si",
"$sp"))
{
if($sht(ipban=>$si)!=$null)
{
# ip is already blocked
exit;
}
if (!pike_check_req())
{
$sht(ipban=>$si) = 1;
exit;
oh, also i put for scanners that:
if($ua =~ "friendly-scanner") {
xlog("L_ALERT", "friendly scanning incoming $rm IP:$si:$sp - R:$ruri -
F:$fu - T:$tu - UA:$ua - $rm\n");
$sht(ipban=>$si) = 1;
drop();
}
so i ban the ip where the friendly scanner are made for a while, it's that
correct?
Yes, this adds the source ip to the htable that is used to block further
requests. But my experience is that if you sent a 200 OK the scans
will stop for the older scanners. So you might want to add a
sl_send_reply("200", "OK");
before the drop.
9:52 p.m.
El mié., 14 de ago. de 2019 a la(s) 10:11, Daniel Tryba (d.tryba(a)pocos.nl)
escribió:
Yes, this adds the source ip to the htable that is
used to block further
requests. But my experience is that if you sent a 200 OK the scans
will stop for the older scanners. So you might want to add a
sl_send_reply("200", "OK");
before the drop.
added! thanks
but:
I'm not sure what you are trying to say here.
In my setups I have a limit of 64 requests per 2s. But I also have
whitelist (with/via the permissions module) for known high traffic
ipaddresses. Dimensioning the pike module for the known high traffic
hosts kind of defeats the purpose of using pike to detect strange
unwanted traffic. The correct numbers depend on your endpoints.
i cannot use whitelist due my experiment are for all dinamyc ip clients
so what its the meaning of "depend on your endpoints" ?
if(src_ip!=myself &&
!allow_address("2", "$si", "$sp"))
{
if($sht(ipban=>$si)!=$null)
{
# ip is already blocked
exit;
}
if (!pike_check_req())
{
$sht(ipban=>$si) = 1;
exit;
oh, also i put for scanners that:
if($ua =~ "friendly-scanner") {
xlog("L_ALERT", "friendly scanning incoming $rm IP:$si:$sp - R:$ruri -
F:$fu - T:$tu - UA:$ua - $rm\n");
$sht(ipban=>$si) = 1;
drop();
}
so i ban the ip where the friendly scanner are made for a while, it's
that
correct?
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
15 Aug
15 Aug
12:05 p.m.
On Wed, Aug 14, 2019 at 02:52:45PM -0400, PICCORO McKAY Lenz wrote:
You need to dimension pike to at least normal expected traffic from your
endpoints (and the max number of concurrent channels). If all your
endpoints are residential phonelines, you might expect 1 or 2 active
calls. In the worst case scenario you might "a few" call setups per
second, so maybe bursts of 10 messages per second.
But if you know you have a call center with 50 phones, with a queue to
accept bursts you might have more than 50 call setups in a worst case
scenario in a second so you might get 150 messages per second from this
endpoint (the queue answers directly, so 1 invite might result in a 100
trying, 180 ringing and a 200 OK within a second)
Since there is only 1 setting for pike you have to account for the
highest number of legit messages possible.
If you want to keep the pike max number of message lower, you'll need to
be creative. Like dynamically create a whitelist of known "excessive"
trunks (by username) and exclude the ipaddresses they register from from
pike.
In my setups I
have a limit of 64 requests per 2s. But I also have
whitelist (with/via the permissions module) for known high traffic
ipaddresses. Dimensioning the pike module for the known high traffic
hosts kind of defeats the purpose of using pike to detect strange
unwanted traffic. The correct numbers depend on your endpoints.
i cannot use whitelist due my experiment are for all dinamyc ip clients
so what its the meaning of "depend on your endpoints" ? 
12:16 p.m.
On 15.08.19 11:05, Daniel Tryba wrote:
On Wed, Aug 14, 2019 at 02:52:45PM -0400, PICCORO
McKAY Lenz wrote:
You need to
dimension pike to at least normal expected traffic from your
endpoints (and the max number of concurrent channels). If all your
endpoints are residential phonelines, you might expect 1 or 2 active
calls. In the worst case scenario you might "a few" call setups per
second, so maybe bursts of 10 messages per second.
But if you know you have a call center with 50 phones, with a queue to
accept bursts you might have more than 50 call setups in a worst case
scenario in a second so you might get 150 messages per second from this
endpoint (the queue answers directly, so 1 invite might result in a 100
trying, 180 ringing and a 200 OK within a second)
Since there is only 1 setting for pike you have to account for the
highest number of legit messages possible.
If you want to keep the pike max number of message lower, you'll need to
be creative. Like dynamically create a whitelist of known "excessive"
trunks (by username) and exclude the ipaddresses they register from from
pike.
Jumping in to point that pipelimit can be an alternative to pike for
more dynamic needs. Pike is optimized for source IP addresses, but not
as flexible as pipelimit, which can track traffic rates per
what-ever-defined key, like user id, ip address, method type, etc ...
With pipelimit one can define new "pipe" on-the-fly in routing block,
not restricted to static definition via modparam.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
In my
setups I have a limit of 64 requests per 2s. But I also have
whitelist (with/via the permissions module) for known high traffic
ipaddresses. Dimensioning the pike module for the known high traffic
hosts kind of defeats the purpose of using pike to detect strange
unwanted traffic. The correct numbers depend on your endpoints.
i cannot use whitelist due my experiment are for all dinamyc ip clients
so what its the meaning of "depend on your endpoints" ?
1926
days inactive
1928
days old
6 comments
3 participants
participants (3)
-
Daniel Tryba -
Daniel-Constantin Mierla -
PICCORO McKAY Lenz