I am wondering about following scenario.
When SIP Client sends request to Server it sends credentials via Authorization to as a proof of identity.
Let’s say when Client receives Invite from server, how does (should) client make sure that request is from trusted Asterisk server and not from some Hacker?
Clients never send INVITEs, or any other SIP requests. Asterisk is the client in this context.
The answer depends on the server, which is not Asterisk. I think most phones don’t allow this for SIP. For SIPS, they will validate Asterisk’s certificate, at least to the extent that it was signed by someone they trust.
Given that Asterisk is B2BUA, I thought it works as follows: In the scenario when A calls B, A sends INVITE to Asterisk and Asterisk sends INVITE to B (with appropriate dial plan config). Isn’t that how it works?
A sends INVITE to Asterisk, with Asterisk acting as server. Asterisk, acting as client, sends INVITE to B. For authentication to happen, on the second leg, B, acting as server, must challenge Asterisk. Asterisk will then use any outbound_auth information configured to B. auth will be used to challenge A. If there is no outbound_auth set, and B challenges, the call will fail.
In practice, if B is a phone, it will never challenge for authentication (whereas if B is an ITSP it may well challenge).
For chan_sip, secret will be used if B challenges, and remote_secret, with secret as fallback, will be used to challenge A, unless insecure=invite is set, in which case A will not be challenged, for INVITEs.
I am curious about this particular case! Why doesn’t Phone B ever challenge? Is it because, in most cases, Phone B is behind NAT and hard to reach from other IP addresses? What about the scenario when Phone B has a public IP address?
The same reason as standard recipes for chan_sip include “insecure=invite”; most providers are only configured to authenticate one way, at the SIP level.
Which comes down to most users not understanding security.
Placing a SIP phone on a public IP address is basically a Very Bad Idea,
because anyone can (and will) send Invites to it, and depending on the phone
and its configuration, might even be able to place chargeable calls to external
numbers (toll fraud).
If that turns out to be possible, then very quickly after someone has found
this out, you will get an extremely large telephone bill from your provider.
The kindlier providers will at least cut off your service before the bill
becomes extortionate.
Antony.
I believe most phones will only accept invites from endpoints matching their configuration. Eg. you configure your phone to register with sip.provider.example, when receiving a message from malicious.attacker.example the phone ignores the message, or rejects it with an appropriate message like 403 or similar.
Hence no need to further checks on the phone side. Many providers use similar checks between themselves, using just the IP addresses as authentication.
While spoofing the IP address is quite straight forward, actually receiving the responses is quite difficult, and as such in this case, where most of the traffic is more or less free to most of the parties involved, there’s not much incentive to raise the level of security by complicating the setup on the customer side.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.