+1 Regards, David Villasmil email: [email protected] phone: +34669448337
ᐧ On Tue, Oct 23, 2018 at 1:31 PM Alex Balashov <[email protected]> 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 <[email protected]> > > >>>>> To: [email protected] > > >>>>> 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 > > >>>>> [email protected] > > >>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > >>>>> > > >>>>> _______________________________________________ > > >>>>> Kamailio (SER) - Users Mailing List > > >>>>> [email protected] > > >>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > >>>> > > >>>> _______________________________________________ > > >>>> Kamailio (SER) - Users Mailing List > > >>>> [email protected] > > >>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > >> > > >> _______________________________________________ > > >> Kamailio (SER) - Users Mailing List > > >> [email protected] > > >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > > > > > > > _______________________________________________ > > > Kamailio (SER) - Users Mailing List > > > [email protected] > > > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > > > > > > _______________________________________________ > > Kamailio (SER) - Users Mailing List > > [email protected] > > 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 > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
