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 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[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.
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 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?
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?
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.
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.