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!
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_late... ===== 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))
El mié., 14 de ago. de 2019 a la(s) 04:55, Daniel Tryba (d.tryba@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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.
El mié., 14 de ago. de 2019 a la(s) 10:11, Daniel Tryba (d.tryba@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
On Wed, Aug 14, 2019 at 02:52:45PM -0400, PICCORO McKAY Lenz wrote:
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" ?
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.
On 15.08.19 11:05, Daniel Tryba wrote:
On Wed, Aug 14, 2019 at 02:52:45PM -0400, PICCORO McKAY Lenz wrote:
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" ?
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 Tryba -
Daniel-Constantin Mierla -
PICCORO McKAY Lenz