HOWTO: Thwarting SIP Scanners during Set-up
ontwowheels:
Quote from: Felix on June 16, 2013, 11:41:10 pm
Quote from: ontwowheels on June 15, 2013, 05:43:36 pm
Scan away, not going to find my Obi behind my DD-WRT router. ;)
You may be right; however, you don't explain why you think this way... When your ATA accepts calls, it essentially opens a port for incoming traffic (say, on port 5060, but it could be some other port, of course). So, if you don't do anything, SIP scanners will find your OBi.
This whole thread and several others are discussing how to protect against it (although with Oleg's embarrassingly simple solution, - unless you want to accept direct IP calls - the conversation is pretty much over). DD-WRT is a very smart OS (I personally prefer OpenWRT, but it's a matter of taste) - and you can configure firewall there to blacklist VSP's IP address. But it seems much more straightforward to do it on OBi
The firewall blocks unsolicited communication, it only allows a response to a request. The firewall is allowing communication to the Obi from the servers that the Obi has initiated communication with. In my case either the GV servers or the Anveo E911 service. When the Obi is first turned on it must call out to those servers, so the firewall allows the traffic to pass. If not, I would have had to open those ports on the firewall and port forward them to the LAN IP of the Obi….similar to setting up and IP camera which I have configured a few of.
Maybe I am wrong but I keep seeing it like this. You open up a browser on your PC that is on the LAN and behind the same firewall as the Obi. Amazon.com cannot scan my WAN ip and try to find a LAN ip that is listening on port 80 or 443. The request has to be initiated by the browser.
mayge:
Quote from: Shale on March 11, 2013, 08:57:16 am
For voip.ms, the expanded 256-character string would be
174.34.146.162,173.208.83.50,174.137.63.206,174.142.75.171,174.34.146.162,198.144.158.125,199.21.149.36,209.62.1.2,5.77.36.136,64.120.22.242,67.205.74.164,67.205.74.184,67.205.74.187,67.215.241.250,68.233.226.97,69.147.236.82,74.54.54.178,74.63.41.218,78.129.153.20
Why is 67.215.241.250 not included in voip.ms access list? I use losangeles.voip.ms from nevada instead of houston.voip.ms: choosing voip.ms server
Quote from: =http://wiki.voip.ms/article/Choosing_Server
that there is a network tool that will help you when deciding which server you want to use, generally named a "ping", which will provide you the latency between you and the server, therefore the server which provides you less latency, should be used.
Isn't there a WEAK correlation between ping and RTP path?
Copying what was visible to me in OP left me with this truncated list. After editing to quote I noticed the list is murch larger.
Quote
67.215.241.250,174.34.146.162,173.208.83.50,174.137.63.206,174.142.75.171,174.34.146.162,198.14
The last two octets should have been a hint I suppose
But it seems BBcode Quote is at fault
(above imageshack.us hosted image has green border. If you cannot see the green rectangle you're missing some bits)
Forum setting is truncating large items: lists, images, whatnot
maybe code tags scroll bar will better hint others
Code:
174.34.146.162,173.208.83.50,174.137.63.206,174.142.75.171,174.34.146.162,198.144.158.125,199.21.149.36,209.62.1.2,5.77.36.136,64.120.22.242,67.205.74.164,67.205.74.184,67.205.74.187,67.215.241.250,68.233.226.97,69.147.236.82,74.54.54.178,74.63.41.218,78.129.153.20
Quote
X_UserAgentPort
I'm assuming X_UserAgentPort needs to be unique when multiple obi on LAN (and unique among multiple IP phone control ports)
By using an X_UserAgentPort outside 5060-5080 what pfSense WAN- and LAN rules would the gurus suggest?
Please consider editing the pfSense wiki for obihai devices! Especially as the voip topic leaves out much for my taste. I would appreciate example rule sets images
http://doc.pfsense.org/index.php/VoIP_Configuration
I'm using pfsense on the recommendation of one more tech than myself as my previous router had undisablable sip alg. I have tried DD-WRT once upon a WRT54GS v2.0 time but its 24 megabits/s limitation constrains my synchronous 50 megabit/s wan connection.
Quote
anveo e911
I'm only interested in paying for e911 ONCE for the house. I have multiple SIP providers. I have already purchased e911 prior to learning about anveo. How do I opt out of anveo e911? Surely they understand federal legislation does NOT mandate every ITSP collect e911 from every subscriber in this (and other) situation?
[1]: http://pfsense.org
[2]: http://imageshack.us
[3]: http://wiki.voip.ms/article/Choosing_Server
[4]: http://doc.pfsense.org/index.php/VoIP_Configuration
Shale:
Mayge, thanks for your comments. I did switch to use the CODE method for the long string. That looks much better for the long string. If you think the contents of the string should be modified, post your suggestion, and how confident you are that it is the proper complete string.
With OBiTalk now implementing method 4 for at least some service providers, it would be best to just go with their method. I am sceptical that method 4 is suitable for all providers, but nobody has posted an exception. I do like the method 3 simplicity where we can specify a working string, but copying the content of one field to another is not bad. Is it universal? We will see.
Regarding whether the port number need to be unique between OBis on the same LAN, I am not sure that is important. Generally you can use the unmodified numbers and have more than one OBi. That also have duplication of port numbers. So somehow I guess the NAT process works all of that out. I am not expert enough to know why it works.
I don't know pfSense. I see it is a firewall.
Regarding Anveo 911, I think that if your phone is located in the US or Canada or maybe even if the address provided is in the US or Canada, their interpretation is that 911 is required, and they will charge. That has nothing to do with OBi. There are other forums such as http://www.dslreports.com/forum/voip where those things that are not related to configuring an OBi are more commonly discussed. I like their 911, and I don't have another SIP provider for that.
Mango:
Quote from: Shale on June 14, 2013, 07:14:28 am
It seems that a "full cone" router can protect its ports from being accessed by an IP other than the one which the port was opened for.
You're close but actually it's the other way around. A restricted cone NAT router restricts incoming traffic to IP addresses that devices on the local network have recently sent packets to. In other words, restricted cone NAT is more secure. If you have a full cone NAT router, you're vulnerable to SIP scanners.
Quote from: ontwowheels on June 15, 2013, 05:43:36 pm
I have been using Tomato and DD-WRT for years, configuring them as repeaters range extenders, client bridges etc. [...] Unless you have the Obi in your DMZ, or have setup wide open port forwards to the Obi I can't see having this issue.
My Tomato router operates as port restricted cone NAT. I haven't tested DD-WRT, but it probably is the same or similar, given that you've never had the problem.
carl:
Quote from: mayge on July 16, 2013, 11:10:10 am
Quote
anveo e911
I'm only interested in paying for e911 ONCE for the house. I have multiple SIP providers. I have already purchased e911 prior to learning about anveo. How do I opt out of anveo e911? Surely they understand federal legislation does NOT mandate every ITSP collect e911 from every subscriber in this (and other) situation?
No, they will all charge you e911. They make good money on it, although some of them are fresh enough to tell you that they do not, and they will charge you that junk fee over and over againwith an unclear regulation as an excuse.
Only remedy : Claim that you moved with your service out of US/Canada. Create a dummy address anywhere else.
You can still have a US billing address for your credit card. A number of people did this, and it worked.
Navigation
[0] Message Index
[#] Next page
[*] Previous page