Re: [SR-Users] Kamailio as SBC

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

>> 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

>> >> 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(a)ngs.ru> >>>>>>> To: sr-users(a)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

>>>>>>> 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