HOWTO: Thwarting SIP Scanners during Set-up

[Jackson]

I have Anveo for a backup + e911.    Took me a bit to figure out what those pesky rings were.

Simply followed this advice:

I presume Anveo uses anycast IP addresses, because they seem to only use one IP address for each server location.

So with Anveo, set the corresponding X_AccessList to 72.9.149.69,67.212.84.21,176.9.39.206

Just like to say thanks.  Seems like the problem has gone away.

[ontwowheels]

Question...can't this issue of SIP Scanners be addressed on the router/firewall that the Obi is behind?  I run DD-WRT and it has a kazillion options.

[Shale]

Question...can't this issue of SIP Scanners be addressed on the router/firewall that the Obi is behind?  I run DD-WRT and it has a kazillion options.

I think that it probably can, but I am not quite sure. 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. Since most routers don't have that, and trying to understand that, is daunting, I decided to not put that into the initial posting at this point. Your experiences could change that. See  Reply #13 and #14  on this thread.

[ontwowheels]

Question...can't this issue of SIP Scanners be addressed on the router/firewall that the Obi is behind?  I run DD-WRT and it has a kazillion options.

I think that it probably can, but I am not quite sure. 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. Since most routers don't have that, and trying to understand that, is daunting, I decided to not put that into the initial posting at this point. Your experiences could change that. See  Reply #13 and #14  on this thread.

Interesting.  I have been using Tomato and DD-WRT for years, configuring them as repeaters range extenders, client bridges etc.  I have never heard the term cone router.  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.

Scan away, not going to find my Obi behind my DD-WRT router.  

[Felix]

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

[ontwowheels]

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]

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

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.

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 Select Expand

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

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.

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]

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.

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]

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.

[newobi]

I've been waking in the middle of the night by 201, 301, 3001 calls.  Upon research, I've read both threads, this Thwarting SIP Scanners and the long SIP Scanners thread. I'm not sure which is the best method now.

Is everything I have below correct?

ORIGINAL MEtHOD

Under X_InboundCallRoute

{(?|x|xx|xxx|xxxx|xxxxx|xxxxxx|un@@.|anon@@.):},{ph}

or

{(?|@|@@|@@@|@@@@|@@@@@|@@@@@@):},{ph}

Is @ same as x?

And, I've seen advice suggesting changing the X_UserAgentPort as well.

This method can end up blocking wanted calls, like a Callerid of "PIE A"?

NEW RECOMMENDED METHOD...

Oleg's method #4

No change needed on SPn Service for Google Voice, just on the VOIP SPn Service?

Also, not need to change the X_UserAgentPort?

[Mango]

My preference is a combination of the following:

Method 0) Disable any SP that you're not using.

Method 2) Change X_UserAgentPort on SPs configured for SIP to a number between 20000 and 65535.
This will reduce the number of SIP scans that reach your device.

Method 4) Change X_InboundCallRoute to {>('Insert your AuthUserName here'):ph}
If any scanners discover the port you're using, the device will reject the call unless it's destined for your AuthUserName.

I prefer not to filter based on Caller ID Number and Shale seems to agree with me.  It would be easy to spoof a legitimate-looking number.

Method 3) is effective but my VoIP service provider changes their IPs from time to time and they have so many I can't keep up.

[ianobi]

Is @ same as x?

"x" refers to any digit. "@" refers to any alphanumeric character. "xxxx" will match "3001" but not "test". "@@@@" will match "3001" and "test".


I agree with Mango's comments.

There have been no reports of Oleg's method failing. If you use your OBi simply to terminate services on, then it should be enough on its own. Some of us use single-stage "through dialling", where calls can come in on an InboundCallRoute and go out on another service. This needs some added security. I like to change my UserAgentPorts as an extra layer of security.

I have not heard of scanners being a problem on any spX used for Google Voice. GV does not use SIP. It does appear the scanners are only looking for SIP trunks to use.

[bsdaiwa]

{ph}                 [before]
{>17771234567:ph}  [after adding protection from SIP scanners]

Question, do I use the { } or are they removed? When I look at my current setting the ph has no brackets around it, so I am not sure if I should include them or not when I make the change and insert my AuthUserName.
Thanks

[Shale]

{ph}                 [before]
{>17771234567:ph}  [after adding protection from SIP scanners]

Question, do I use the { } or are they removed? When I look at my current setting the ph has no brackets around it, so I am not sure if I should include them or not when I make the change and insert my AuthUserName.
Thanks

Use them. I guess they are not needed in all cases, but I suspect they are at least some of the time. And it works with them.

[bsdaiwa]

{ph}                 [before]
{>17771234567:ph}  [after adding protection from SIP scanners]

Question, do I use the { } or are they removed? When I look at my current setting the ph has no brackets around it, so I am not sure if I should include them or not when I make the change and insert my AuthUserName.
Thanks

Use them. I guess they are not needed in all cases, but I suspect they are at least some of the time. And it works with them.

Thanks

[newobi]

Thanks everyone.  I will use Oleg's method #4.  Going to set up my parent's also, before they start getting the SIP scanners.

[Shale]

Thanks everyone.  I will use Oleg's method #4.  Going to set up my parent's also, before they start getting the SIP scanners.

If you are using OBiTalk to set up your parent's OBi and their SIP provider is one that OBiTalk sets up automatically, the X_InboundCallRoute may have already been modified during the latest update or might get updated with the next update from OBiTalk.

[newobi]

Thanks everyone.  I will use Oleg's method #4.  Going to set up my parent's also, before they start getting the SIP scanners.

If you are using OBiTalk to set up your parent's OBi and their SIP provider is one that OBiTalk sets up automatically, the X_InboundCallRoute may have already been modified during the latest update or might get updated with the next update from OBiTalk.

Thanks, I just made the change on their OBi and the X_InboundCallRoute was not modified yet.  I asked them if they recall any of the strange shortened Callerids like 201, 301, 3001 and up to now they haven't been affected by those calls.  We both should be in the clear now.

[gtech]

{ph}                 [before]
{>17771234567:ph}  [after adding protection from SIP scanners]

Question, do I use the { } or are they removed? When I look at my current setting the ph has no brackets around it, so I am not sure if I should include them or not when I make the change and insert my AuthUserName.
Thanks

I am new to voip but have everthing setup pretty good so far. I have received a sip scan less then 4 days in calling from 800. I am trying to tweak but am having troubles.
When I try to use this method {>17771234567:ph}  including the  { and > I get parsing errors in my SP1 service page and I have to reflash my obi100 to regain access.
I am assuming that the "17771234567" is replaced with your AuthUserName from your SIP Creditentals which in my case is my assigned phone number.

Thanks for any help in advance