Am Montag, 8. Oktober 2018, 07:52:59 CEST schrieb Seshu Kumar: Hello Seshu, do you see any errors in your kamailio log? If yes, please provide them here to look at it. Best regards, Henning -- Henning Westerholt - https://skalatan.de/blog/ Kamailio security assessment - https://skalatan.de/de/assessment

Am Mittwoch, 10. Oktober 2018, 07:31:36 CEST schrieb Seshu Kumar: Hello Seshu, according to the logs the header is at least one time build and added: 5(27138) DEBUG: ims_auth [authorize.c:1663]: add_authinfo_resp_hdr(): authinfo hdr built: Authentication-Info: nextnonce="a3dc15ac2c8c9e4a4f9dd25403c891d3",qop=auth,rspauth="7ebe6bfa6b087d23b548143a0c57389a",cnonce="b9d7ed7f",nc=00000001 5(27138) DEBUG: ims_auth [authorize.c:1665]: add_authinfo_resp_hdr(): authinfo hdr added 5(27138) Can you observe this header on the network? Best regards, Henning -- Henning Westerholt - https://skalatan.de/blog/ Kamailio security assessment - https://skalatan.de/de/assessment

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 пишет: _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

May you help?.. :-) Kind regards, Ellad

May you help?.. :-) Kind regards, Ellad 22.10.2018 17:12, Alex Balashov пишет: _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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 пишет: _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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(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 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(a)lists.kamailio.org >>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>>>> >>>>>> _______________________________________________ >>>>>> Kamailio (SER) - Users Mailing List >>>>>> sr-users(a)lists.kamailio.org >>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>>> _______________________________________________ >>>>> Kamailio (SER) - Users Mailing List >>>>> sr-users(a)lists.kamailio.org >>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> _______________________________________________ >>> Kamailio (SER) - Users Mailing List >>> sr-users(a)lists.kamailio.org >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> sr-users(a)lists.kamailio.org >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > _______________________________________________ > Kamailio (SER) - Users Mailing List > sr-users(a)lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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. Kind regards, Ellad is counterpart. re-send the _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Am Mittwoch, 10. Oktober 2018, 07:31:36 CEST schrieb Seshu Kumar: Hello Seshu, according to the logs the header is at least one time build and added: 5(27138) DEBUG: ims_auth [authorize.c:1663]: add_authinfo_resp_hdr(): authinfo hdr built: Authentication-Info: nextnonce="a3dc15ac2c8c9e4a4f9dd25403c891d3",qop=auth,rspauth="7ebe6bfa6b087d23b548143a0c57389a",cnonce="b9d7ed7f",nc=00000001 5(27138) DEBUG: ims_auth [authorize.c:1665]: add_authinfo_resp_hdr(): authinfo hdr added 5(27138) Can you observe this header on the network? Best regards, Henning -- Henning Westerholt - https://skalatan.de/blog/ Kamailio security assessment - https://skalatan.de/de/assessment