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