[SR-Users] secfilter usage

[Aymeric Moizard]

Hi,

Tks for your answer.
Unfortunately, that wasn't my issue: I was surprised because no message was
sent. (to any port)

I have now force_rport in my config and all messages, up to now, are
answered. In my initial test, the unanswered
message contains this TOP via:

Via: SIP/2.0/UDP 204.11.194.25;branch=z9hG4bK3ce5.24b98891.0\r\n

I suppose I should have seen a message being sent to  204.11.194.25 on port
5060, the default.

I'm not able to explain the reason why my capture don't have the answer.
The address is valid, the port was valid too. It should have worked without
the force_rport.
I had received many other scam since I added force_rport, but none being
exactly equivalent, so I can't tell...

Anyway... no big trouble!
Regards,
Aymeric


Le mar. 3 déc. 2019 à 18:38, Pepelux <pepeluxx at gmail.com> a écrit :

> Hi
>
> Without the force_rport() the reply goes to an incorrect port
>
> Regards
>
> On Tue, 3 Dec 2019 at 17:58, Aymeric Moizard <amoizard at gmail.com> wrote:
>
>> Hi,
>>
>> Tks a lot for the answer.
>>
>> I'm surprised if that would fix the issue. The missing 200 ok was for an
>> invite with a via containing a public IP and no port.
>>
>> I would expect sl_send_reply to send something, even if to the wrong
>> port?
>>
>> Regards
>> Aymeric
>>
>>
>> Le mar. 3 déc. 2019 à 16:40, Pepelux <pepeluxx at gmail.com> a écrit :
>>
>>> Sorry ... Try to use force_rport() *before* sl_send_reply
>>>
>>> On Tue, 3 Dec 2019 at 16:37, Pepelux <pepeluxx at gmail.com> wrote:
>>>
>>>> Hi Aymeric
>>>>
>>>> Try to use force_rport() after sl_send_reply:
>>>>
>>>> secf_check_ua();
>>>> if ($? == -2) {
>>>>   force_rport();
>>>>   sl_send_reply("200", "OK");
>>>>   exit;
>>>> }
>>>>
>>>> For secf_check_sqli_all() the module drops the packet if a sqli is
>>>> detected in any header but for other functions as secf_check_sqli_ua() it
>>>> returns a negative code for detection and you choose if you want to drop
>>>> the packet or not
>>>>
>>>> Regards
>>>>
>>>>
>>>> On Tue, 3 Dec 2019 at 15:48, Aymeric Moizard <amoizard at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm testing and moving my kamailio script to use the newer secfilter
>>>>> module.
>>>>>
>>>>> In the past, I was replying "200 Ok" to "friendly scanners"...
>>>>>
>>>>> With the newer secfilter module, it looks like I can't send a reply
>>>>> with "sl_send_reply("200", "OK")"
>>>>>
>>>>> secf_check_ua();
>>>>> if ($? == -2) {
>>>>>   sl_send_reply("200", "OK");
>>>>>   exit;
>>>>> }
>>>>>
>>>>>
>>>>> I have read the code of the secfilter, but I was not able to see any
>>>>> specific code to silently discard the SIP request.
>>>>>
>>>>> I can see in the documentation about "secf_check_sqli_all", that the
>>>>> SIP message is supposed to be "dropped". I can see "w_check_sqli_all"
>>>>> returns 0 on detection and w_check_ua returns -2 upon detection.
>>>>>
>>>>> Are the message discarded because a negative value was returned?
>>>>>
>>>>> Would it be doable, using the secfilter, to still reply 200 Ok?
>>>>> Regards
>>>>> Aymeric
>>>>>
>>>>> --
>>>>> Antisip - http://www.antisip.com
>>>>> _______________________________________________
>>>>> Kamailio (SER) - Users Mailing List
>>>>> sr-users at lists.kamailio.org
>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
Antisip - http://www.antisip.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20191203/4d52c2d0/attachment.html>