Known Unknown Peers - Help Request

Here’s the little challenge that is driving me batty (new install of FreePXB)…

I have a DID number forwarded to my network. Asterisk authorises the user, then puts the call into the ‘unknown peers’ call flow.

I can capture the call for any given ip address of their.net (although, I have the additional problem of it then going to call terminated). But, not if I specify host=dynamic – it then goes to no user.

See below: I have substituted my.asterisk.net, their.net and OKUSER for their real equivalents.
(((
[2014-10-10 11:06:44] SECURITY[1884] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“1412735604-825632”,Severity=“Informational”,Service=“SIP”,EventVersion=“1”,AccountID=“OKUSER”,SessionID=“0x967467c”,LocalAddress=“IPV4/UDP/my.asterisk.net/5060”,RemoteAddress=“IPV4/UDP/their.net.130/5060”,UsingPassword=“1”
[2014-10-10 11:06:44] VERBOSE[27675][C-000000a1] pbx.c: – Executing [[email protected]:1] NoOp(“SIP/their.net.165-0000009a”, “Received incoming SIP connection from unknown peer to OKUSER”) in new stack)))
Please advise how I can get this connection to be accepted (i.e. not an unknown peer).

Their.net.NNN can be any one of 2048 addresses – and I’m hoping not to enter 2048 peers!

My (possibly perverted) logic reckons that there must be some way of configuring this connection to be accepted, especially since it has passed user authentication.

Register back at their.net is not an option.

Any pointers warmly appreciated,
Thanks,
Keith

I’ll try and make myself a little clearer…

I cannot fathom how to construct the trunk / inbound route combination for the following use case:

DID provider successfully authenticates as user, but incoming call is from an unknown peer.

I have searched extensively online and tried numerous combinations of user/extension/trunk/inbound route parameters. I am clearly missing something.

e.g. Is it possible to create a valid peer on-the-fly when a user successfully authenticates?

Thanks

It seems unlikely that any ITSP would authenticate as a user. Are you sure you don’t mean that you have authenticated with them?

Generally people put insecure=invite precisely because ITSPs never authenticate themselves.

If you have a strange ITSP that does authenticate, I think you need to provide the contents of the INVITE you receive from them, together with your sip.conf entries. Please mangle any authentication data, including in the INVITE, but not so much as to hide its presence.

I’m not entirely sure that I understand your question, but I think you’re saying that you want to allow incoming calls from unknown peers on your PBX. If that’s correct, you’ll need to:

  1. Change “Allow Anonymous Inbound Calls” to “Yes” in the Asterisk SIP Settings module.
  2. Forward Port 5060 from your router to your PBX, at least for the IP address where the call will come from.
  3. Create an Inbound Route to match the DID that will be presented when the call comes in.

Note that forwarding port 5060 for everyone creates a serious security risk and I do not recommend it.

If you really need to allow calls from anyone, you may wish to follow this guide from Ward Mundy, which will allow you to receive inbound calls from unknown peers via VOIP.ms:

http://nerdvittles.com/?p=2598

Thank you David.

My sip.conf is the vanilla freePBX one - as for entries in other places - I keep fiddling with them to try different things I find on the net (e.g. host=dynamic, etc.).

“Square one” might be a better idea - this was my starting point http://www.ttnc.co.uk/help/number-setup/call-forwarding/voip-termination/

I know the system works fine if I ‘Allow anonymous’ - but would like the end result to be secure, so have been trying combinations that only allow a connection via an authorised account. i.e. I’d like to reject all anonymous calls unless accompanied by a valid username:password combination. Is that doable?

Thanks,
Keith

Thank you AdHominem.

That set-up is definitely worth considering if I fail to achieve my desired configuration.

Best regards,
Keith

More info: the INVITE block…

<— SIP read from UDP:87.238.72.130:5060 —>
INVITE sip:username:[email protected] SIP/2.0
Record-Route: sip:87.238.72.130;lr=on;ftag=427772D0-332
Via: SIP/2.0/UDP 87.238.72.130;branch=z9hG4bK0833.7fb8d702.0
Via: SIP/2.0/UDP 87.238.72.164:5060;branch=z9hG4bK1807092CAF
Remote-Party-ID: sip:[email protected];party=calling;screen=yes;privacy=off
From: sip:[email protected];tag=427772D0-332
To: sip:[email protected]
Date: Mon, 13 Oct 2014 08:45:07 GMT
Call-ID: [email protected]
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
User-Agent: MSSGW (RC)
Allow: INVITE, BYE, CANCEL, ACK
CSeq: 101 INVITE
Max-Forwards: 69
Timestamp: 1413189907
Contact: sip:[email protected]:5060
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 418

Interesting that FreePBX looks for a peer in the name of the originating number (014238238238) in my example. Why does it not look for one in the name of 443333333333 (which makes more sense to me because the former can be anything and the latter can only be what I expect)??

He’s already allowing calls form anonymous peers. He wants to disable this whilst still allowing calls from the address block used by his ITSP. He claims the ITSP is authenticating calls to him, but I find that very unlikely.

You should never be guessing at the setting of host=dynamic. I’ve never heard of an ITSP that would require it.

[quote=“MangledMind, post:5, topic:24717, full:true”]I know the system works fine if I ‘Allow anonymous’ - but would like the end result to be secure, so have been trying combinations that only allow a connection via an authorised account. i.e. I’d like to reject all anonymous calls unless accompanied by a valid username:password combination. Is that doable?
[/quote]
Yes, but the peer has to send an id and password, which is rather unlikely.

Because that number is the destination number, i.e. the DID number, not the identity of the entity that is trying to authenticate. If you had true DID, you could have thousands of possible values for this number.

It does look as though they are passing a password, which is unusual, unless they are simply reflecting the contact address you gave when you registered. If they were really authenticating with you, I would expect a separate MD5 authentication exchange.

I think you will need to allow guests, but restrict the address range in your firewall.

I’m pretty sure this security message indicates successful authentication - I’m presuming it is inbound

All that means is that it wasn’t rejected for security reasons. The decision to output that message is made after the end of processing the INVITE request, not at the point of authentication.

Thanks - I’m starting to ‘get it’, I think.

I’d got myself confused between endpoint and ITSP.

This is the bit that tells me the inbound call came via an expected ITSP:

I guess that if I can define an inbound trunk and/or dial plan context that caters for that and excludes hackers, that’d suffice for now

It seems to me that for all the GUI goodness, I might have to get my hands dirty to construct such.

The more I investigate this the more confusing it becomes. Here’s my take…

I can get this to work if I turn allow anonymous on. Let’s say this is okay because anonymous means that the caller is not known by IP - and this is true when the caller can have any one of 2048

Now, we know a valid call from my ITSP authenticates - logically that should be our basis for accepting/rejecting the call, but it appears there is no provision for this case (shame).

So, we create an inbound trunk and route combo that includes a requirement to match on DID (OKUSER) and deny 0.0.0.0 and permit all known IP addresses.

Fine - that works, and can be routed to the appropriate IVR/extensions etc.

So what’s the problem, then?

Plenty of incoming calls (e.g. from ‘friendly scanner’ and other hackers) seem to fall into call contexts like from-trunk and ext-did. However, these calls have no defined context - so really should not get in this far. Moreover, in an attempt to see if earlier rejection is possible, an inbound trunk ‘Bogus’ was created as a catch all that just goes to hangup. This seems to remain unused.

I remain utterly baffled why I cannot permit one legitimate, authenticated, inbound route and reject all others through making a few logical and simple settings.