+1
Regards,

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

ᐧ

On Tue, Oct 23, 2018 at 1:31 PM Alex Balashov <abalashov@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@ngs.ru>
> >>>>> To: sr-users@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@lists.kamailio.org
> >>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >>>>>
> >>>>> _______________________________________________
> >>>>> Kamailio (SER) - Users Mailing List
> >>>>> sr-users@lists.kamailio.org
> >>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >>>>
> >>>> _______________________________________________
> >>>> Kamailio (SER) - Users Mailing List
> >>>> sr-users@lists.kamailio.org
> >>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >>
> >> _______________________________________________
> >> Kamailio (SER) - Users Mailing List
> >> sr-users@lists.kamailio.org
> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >
> >
> > _______________________________________________
> > Kamailio (SER) - Users Mailing List
> > sr-users@lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users@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@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users