Hello Henning I have seen logs I didn't find any error per se. I am attaching the log file. Thank you for answering. regards Seshu

On Tue, Oct 9, 2018 at 11:08 PM Henning Westerholt hw@kamailio.org wrote:

Am Montag, 8. Oktober 2018, 07:52:59 CEST schrieb Seshu Kumar:

...

I am using Kamailio version 5.0.4 in IMS mode. I have added ims_auth in kamailio.cfg in S-Server. And added line modparam("ims_auth", "add_authinfo_hdr", 1)

I am not finding “Authentication-Info” header being added in 200 OK responses. Anything more i need to enable. Kindly someone give a clue.

Or this is known problem?

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

Hello Henning, I apologize for replying late, I was on vacation. 200 OK doesn't contain above message.. Regards Seshu Kumar

On Mon, Oct 15, 2018 at 1:06 AM Henning Westerholt hw@kamailio.org wrote:

Am Mittwoch, 10. Oktober 2018, 07:31:36 CEST schrieb Seshu Kumar:

...

I have seen logs I didn't find any error per se. I am attaching the log file. Thank you for answering.

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

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

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

On 10/22/18 10:21 AM, Ellad Yatsko wrote:

May you help?.. :-)

Kind regards, Ellad

Not sure if you're looking for someone to do the work for you, in which case, I'd recommend the business list.

The concepts you're looking for here are covered in a variety of modules that you can integrate together to provide a solution to your needs:

HTABLE DMQ PERMISSIONS UAC PIKE

The beauty of this software is to look at the modules, understand the components, and then integrate it as you desire into a custom solution.

--fred

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

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

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. Looking at you name - may I ask? Are you from Russia? :-)

Kind regards, Ellad

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

Asterisk is compatible with "path" in pjsip.

If you need it for chan_sip in was implemented in asterisk v12 AFAIR.

On Wed, Oct 24, 2018 at 11:11 PM Ellad Yatsko eyatsko@ngs.ru wrote:

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

...

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

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

---

Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Hello Henning, As you pointed out Authenticatio-Info header is prepared, but it not added while forming 200 OK packet. In ims_registrar_scscf module "200 OK" is formed in reply.c but no where I see Authentication-info header being added. Thanks in advance. regards Seshu Kumar

On Mon, Oct 15, 2018 at 1:06 AM Henning Westerholt hw@kamailio.org wrote:

Am Mittwoch, 10. Oktober 2018, 07:31:36 CEST schrieb Seshu Kumar:

...

I have seen logs I didn't find any error per se. I am attaching the log file. Thank you for answering.

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