[SR-Users] Kamailio as SBC

Ellad Yatsko eyatsko at ngs.ru
Wed Oct 24 13:02:11 CEST 2018 

Hello Alex!

1. First of all I'd like to apologize about my yesterday unwise notice. :-)

2. Regarding your paragraph 2 -> "Via ..." & "Supported: path"?
   And how to make Kamailio to "proxy" REIGISTER to upstream registrar
   (Asterisk - do you know it supports "path"? For a what degree does
Asterisk
   follow "the letter of RFCs"?)?

3. Regarding "topoh" I will read, ok. As I remember MY config has something
     modparam("topoh", "mask_ip", "1.1.1.2")
     modparam("topoh", "mask_callid", 0)
   I think I will cope this by myself.. :-)

4. Yes, I know about "htable", I can complete it by myself. I familiar
with this.

Thank you for your asnwers Alex. Looking at you name - may I ask? Are
you from
Russia? :-)

Kind regards,
Ellad


23.10.2018 15:27, Alex Balashov пишет:
> Ellad,
>
> The reason for the lukewarm replies is not a failure on the part of the
> public to understand the detailed content of your request; you don't
> need to "simplify" it for them by individuating the paragraphs. 
>
> The central obstacle is that you don't appear to understand that
> Kamailio is a SIP proxy at the core. There is a well-defined mechanism
> by which they relay various kinds of requests to user agents (UAs), and
> this does not consist of capriciously "rewriting IP/UDP headers".
>
> In this sense, the valuable conceptual comprehension from so-called
> "general words" precedes "eager and spirited implementation", and is the
> reason why you have been encouraged to consider "general words".
>
> Having said that:
>
> 1. Kamailio can certainly relay REGISTERs to an upstream registrar;
>
> 2. This presents the problem of letting the registrar know that the
> registrant has to be reached back through Kamailio as an adjacency, and
> the solution to this is provided by the Path extension:
>
> https://tools.ietf.org/html/rfc3327
>
> This Path header is added to the REGISTER and serves a similar purpose
> to the one served by Record-Route in dialog-forming requests; it shunts
> all subsequent inbound requests to the registrant through Kamailio,
> which removes the Path header and passes it on.
>
> 3. As a proxy, Kamailio will dutifully forward authentication
> challenges back to the caller, as it will do with any final
> transaction-disposing reply.
>
> 4. Proxies do not hide topology in the manner you propose, whether in
> the context of forwarding registrations or for any other purpose. The
> message headers will consist mostly of information populated by the user
> agent that constructed the message, with a few additional bits of
> information added by Kamailio to reflects its role in the process. This
> is mainly in the form of an additional Via hop, a Record-Route, etc.
>
> Kamailio has a number of modules which can accomplish this in a somewhat
> "unorthodox" manner:
>
> https://kamailio.org/docs/modules/5.1.x/modules/topoh.html
> https://kamailio.org/docs/modules/5.1.x/modules/topos.html
>
> However, these are used mainly for security-motivated topology
> concealment relative to third parties. The problems invited by these
> approaches are certainly not worthwhile for use inside one's own
> network.
>
> 5. A REGISTER flow is not a dialog. The term "dialog" has a very
> specific meaning articulated in 3261 § 12. 
>
> In core SIP, and notwithstanding subscribe/notify or any other
> extensions, only INVITEs are dialog-forming requests.
>
> 6. There is no need for Kamailio to maintain - to "remember" or
> "memorise" - any state for this flow. It can take part in an entirely
> stateless way.
>
> 7. The 'htable' module, as suggested by others, is the best way to
> implement any sort of temporary IP banning. Otherwise, log the offending
> IP via xlog() and have fail2ban deal with it.
>
> -- Alex
>
> On Tue, Oct 23, 2018 at 12:30:03PM +0300, Ellad Yatsko wrote:
>
>> Ok. Let's divide overall task onto several little steps.
>>
>> I. How to implement the following:
>>    - when Kamailio receives REGISTER from user in the Internet
>>    - Kamailio rewrites IP/UDP headers - it acts with Asterisk on behalf
>> of User, Asterisk should know just Kamailio IP (add "Via"?)
>>    - Kamailio remembers [somehow] this dialog (how?) and
>>    - retransmits REGISTER to Asterisk
>>    - on receiving Unauthorized Kamailio retransmits it to User - this is
>> an intermediate step, no action needed
>>    - User repeats steps on Registration with the Nonce
>>    - on receiving OK [from Asterisk] for the memorized dialog Kamailio
>> retransmits OK to User and composes User Location
>>    - on receiving NOT FOUND, FORBIDDEN, etc Kamailio retransmits SIP
>> answer to User and after several unsuccessful attempts blocks User IP
>>    - Fail2Ban completes the rest - inserts new rule
>> Every time Kamailio retransmit SIP packet to the User from Asterisk it
>> HIDES topology (IP/UDP headers and all SIP-related Info from SIP
>> Packets). User should know just about Kamailio as about its counterpart.
>>
>> How to track SIP REGISTER related messages inside Kamailio?
>>
>> TO: Yu Boot - is it "standalone" implementation? How do you think? :-)
>>
>> Kind regards,
>> Ellad
>>
>>
>> 22.10.2018 20:16, Yu Boot пишет:
>>> I can help you with cfg, if you 're ready to implement standalone
>>> softswitch on your Kamailio :)
>>>
>>>
>>> 22.10.2018 17:21, Ellad Yatsko пишет:
>>>> May you help?.. :-)
>>>>
>>>> Kind regards,
>>>> Ellad
>>>>
>>>> 22.10.2018 17:12, Alex Balashov пишет:
>>>>> I did not say that my article represents a complete answer to every
>>>>> part
>>>>> of every one of your questions, at every level of abstraction and
>>>>> specificity. Just that it might be helpful. :-)
>>>>>
>>>>> On Mon, Oct 22, 2018 at 04:40:03PM +0300, Ellad Yatsko wrote:
>>>>>
>>>>>> Dear Alex,
>>>>>>
>>>>>> your article is just "general words". :-) There is a couple of
>>>>>> questions:
>>>>>>
>>>>>>    - can my "vision" be completed?
>>>>>>    - how can it be implemented?
>>>>>>
>>>>>> The major problem as I see is to modify algorithm so Kamailio will
>>>>>> not check
>>>>>> database but will lean on answers of its upstream to generate
>>>>>> UL. It should not BALANCE, just forward SIP traffic, ANALYZE
>>>>>> answers of
>>>>>> Upstream
>>>>>> SIP-Server, make decision about attacks and PROXY RTP. It should be
>>>>>> more
>>>>>> clear
>>>>>> definition what I would like to achieve.
>>>>>>
>>>>>> I could be confused about exact terminology of "Session Border
>>>>>> Controller".
>>>>>> But I'd like to implement FRAUD/BruteForce protection of my
>>>>>> Asterisk using
>>>>>> Kamailio (in the middle) because I heard it highly effective in the
>>>>>> point
>>>>>> of view of heavy loads. Asterisk might not bear a "tons" of SIP
>>>>>> requests
>>>>>> (dialogs).
>>>>>>
>>>>>>
>>>>>>
>>>>>> Kind regards,
>>>>>> Ellad
>>>>>>
>>>>>>
>>>>>> 22.10.2018 12:07, Alex Balashov пишет:
>>>>>>> I hate to plug my own articles, but in this case it might help:
>>>>>>>
>>>>>>> http://www.evaristesys.com/blog/kamailio-as-an-sbc-five-years-on/
>>>>>>>
>>>>>>> -- 
>>>>>>> Sent from mobile. Apologies for brevity and errors.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Ellad Yatsko <eyatsko at ngs.ru>
>>>>>>> To: sr-users at lists.kamailio.org
>>>>>>> Sent: Mon, 22 Oct 2018 3:28 AM
>>>>>>> Subject: [SR-Users] Kamailio as SBC
>>>>>>>
>>>>>>> Hello!
>>>>>>>
>>>>>>> I'd like to implement the following diagram:
>>>>>>>
>>>>>>>   Users  -> Internet -> Kamailio -> Asterisk
>>>>>>>
>>>>>>> 1. Kamailio has no own users, it just re-writes headers and re-send
>>>>>>> REGISTER messages to Asterisk where usres are located.
>>>>>>>
>>>>>>> 2. Depending on Astersisk's answers Kamailio either form UL (using
>>>>>>> original IP from the first, original REGISTER from Users) or
>>>>>>> translates
>>>>>>> Asterisk's answer back to Users. If it is error (e.g.
>>>>>>> forbidden/notfound) Kamailio blocks User's IP (for instance using
>>>>>>> pike
>>>>>>> module) and Fail2Ban adds affected IP into IPSet's List to block
>>>>>>> it by
>>>>>>> IPTables Permanently.
>>>>>>>
>>>>>>> 3. INVITEs are translated to Asterisk as to the only Upstream
>>>>>>> SIP-Server. And again Errors from Asterisk are processed in the
>>>>>>> same way
>>>>>>> as Bad REGISTERs. Pike in conjunction with IPSet/IPTables block
>>>>>>> affected
>>>>>>> IPs.
>>>>>>>
>>>>>>> 4. Astersisk sees all registrations from Internet user as they are
>>>>>>> directly behind Kamailio. Kamailio rewirtes headers twice: from
>>>>>>> Users to
>>>>>>> Asterisk and from Asterisk to Users - this allows to hide topology
>>>>>>> from
>>>>>>> users (they deal ONLY with Kamailio) and block non-static IPs on the
>>>>>>> Asterisk's side.
>>>>>>>
>>>>>>> Is this possible?
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> Ellad Yatsko
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>
>>> _______________________________________________
>>> 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

More information about the sr-users mailing list