[SR-Users] Kamailio as SBC

Tue Oct 23 16:04:34 CEST 2018

+1
Regards,

David Villasmil
email: david.villasmil.work at gmail.com
phone: +34669448337

ᐧ

On Tue, Oct 23, 2018 at 1:31 PM Alex Balashov <abalashov at evaristesys.com>
wrote:

> 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
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20181023/2b7c7ab8/attachment.html>