My Voip provider says I must enable this feature to recive incoming calls, is this a bad practice or is it needed. I have tried with this turned off and it does block incoming voip calls.
it exposes your system to additional security issues. The reason this is usually needed is that the provider is originating calls from one or more IP addresses that are different from their proxy. If they can provide you with a complete list of IP addresses where the calls may be originating from, then you could configure that as part of the trunk config. You would have a line in the trunk config that looks something like this:
host=sip.myprovider.com&64.152.73.36&64.193.34.43where the list of ip addresses/fqdns are separated with & and then any calls coming from those addresses will be routed on this trunk. This usually works. You just need a complete list.
Philippe Lindheimer - FreePBX Project Lead
http//freepbx.org - IRC #freepbx
I’m wondering what the issues might be. The problem with not allowing incoming anonymous SIP calls is that incoming ENUM calls won’t work (assuming you have registered one or more of your numbers with one of the ENUM registries). You have no idea what IP address the caller might be coming from in that case, and even if you did, you probably aren’t going to set up a trunk just so you can receive those ENUM calls. It seems decidedly unfriendly to disallow anonymous SIP calls if you could register with ENUM and perhaps save some of your other VoIP callers some money (since the calls might not have to go to the PSTN and back).
So I’m wondering, what security issues would be present that are not present when someone dials in and gets your IVR (as one example)?
By the way, we really need something better than ENUM (and not something restricted to a particular distribution that may or may not happen to include FreePBX). There are a lot of people who use it, but a lot more people who could make use of it don’t bother because you have to jump through too many hoops to get registered (and then there are multiple registries, which compounds the problem). It’s not THAT difficult, but still, unless registering your incoming trunk numbers with the registry is the default (one that could be disable by checking a checkbox, but still the default if you don’t check the box), many users are just too unmotivated to go to a registry site, create an account, log in, enter their numbers, and then remember to keep that information up to date.
I moved from an Asterisk NOW implementation to Trixbox using your toolset. Much, much better.
However, I can dial out, but not receive calls. I have a SIP trunk with the incoming settings having: context=from-trunk. I also have an incoming catch all call rule… but I don’t think it gets that far… just says the number is unavailable… so I have something setup incorrectly here.
Some asterisk vulnerabilities that are yet to be exposed.
Philippe Lindheimer - FreePBX Project Lead
http//freepbx.org - IRC FreePBX
When you said “it exposes your system to additional security issues”… what, specifically, are the issues? I’m trying to find documentation on what this feature changes/does. When this is enabled, I see activity on the Asterisk console coming from locations I haven’t configured the box to talk to.
I have allowed anonymous sip for years. You can call me at the sip URL in my signature if you like. I also have a guest IAX2 trunk for inbound calls. You can reach it at:
IAX2://[email protected]/17066323343
Over the years my machine has been hacked twice, but neither time did the initial assault come through either of these routes. Once, a machine I was peered with got compromised and the attacker got the credentials to an IAX trunk between our machines and the second time, I got nailed with weak passwords on SIP extensions.
Now that being said, I think that unknown future vulnerabilities in Asterisk are an issue. My machine is behind a firewall that does intrusion detection. I am running fail2ban and I am looking at OSSEC.
I do two things that make this risk tolerable for me. First, both of these inbound trunks are in the from-trunk context. This FreePBX context allows limited use of the phone server. Second, I have an any/any route that sends you straight to a hangup. I don’t play any messages, I don’t send Zapateller, I just hang-up. Joe Roper suggested this in a forum post a while back. If we do not have an any/any route, the phone server sends an Allison voice reading the ss-noservice message. If you route calls that don’t know one of the DID’s in your inbound routes straight to a hangup, they may not recognize it as an Asterisk box, and it gets them off of you bandwidth right away.
There is an alternative to ENUM/E164 called the Dundi e164 cloud. Dundi is a peer-to-peer telephony cloud where you advertise your numbers to the cloud. Oddly enough, it does not use an open inbound trunk, but an authenticated one with rotating keys. Contact either Anthony Messina at messinet.com or me to information on peering in the cloud.
1 Like
host=sip.myprovider.com&64.152.73.36&64.193.34.43
does this really work ? I tried it and only one trunk for the last IP was created
no it does not. The host= can only take 1 IP
read your post from Thu, 10/25/2007 - 17:28
and Wed, 06/30/2010 - 00:32
-
This is due to latest restrictions/upgrades on asterisk? you wrote> host=sip.myprovider.com&64.152.73.36&64.193.34.43
then
you wrote : no it does not. The host= can only take 1 IP -
What is the alternative if any?
closing the allow anonymous so far has been the solution for many still leaving your comment to be true >Some asterisk vulnerabilities that are yet to be exposed.
- I managed dozens of installations and until this date I did not come across any hacked boxed due to this anonymous allowance. Did you ever?
Thank you for all your hard work Phillipe, you are the master in command kudos to you. FYI: I was with cosmicwombat in 2007 on the first ever certification for Ftocc. Also Kerry, Andrew, many old school buddies and the great crow.