OBiTALK Community

General Support => Installation and Set-Up (Devices) => Topic started by: Shale on March 11, 2013, 08:57:16 AM

Title: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Shale on March 11, 2013, 08:57:16 AM
Note: Things changed for the better about June/July 2013. OBiTalk has been implementing method 4, Oleg method described below, for at least some of the SIP providers by default. If your provider is not one that OBiTalk lists or if you get a SIP scan, or if you have overridden the X_InboundCallRoute so that OBiTalk does not control the field, or if you choose to not use OBiTalk, the information below will still apply. (note #j)
     =========The need for the following has been reduced========

An unfortunate thing we all must learn about is how to thwart SIP scanners.  It is best to handle this now rather than getting motivated at 4AM by a phantom call with caller ID "1001" or some such.  There are four ways to address the SIP scan intruders.  For those using OBiTalk to set things up (as I do), each involves using the "OBI Expert Configuration" to change values from the defaults.  Methods (pick one only for each SPn Service that is not set up for GV):

0. Disable any unused SPn Service by un-ticking (Voice Services)SPn Service->Enable. This may be unneeded, but it will not hurt for an unused SPn

1. Filter on the length of the caller ID string. This is more complex and seems less effective IMHO.  It would seem easy to circumvent by spoofing a real number.

2. Change the (Voice Services)SPn Service->X_UserAgentPort ports for each SPn  to a number not in the 506x range. This seems effective based on people's experience, but how long until the scanners broaden their scans?

3.  Change the X_AccessList value for each service to permit only the listed IP addresses to be used as a SIP server.   If using ObiTalk expert configuration, that path would be :
System Management -> Service Providers-> ISTP Profile n SIP -> X_AccessList

The list is limited in the OBi boxes to 512 characters, and each item in the list can be up to 16 characters long with an average of 14.28 while we are using IPV4 addressing.  This would permit maybe 36 addresses to be listed in a comma-separated list.  This will be plenty for some SIP suppliers, but not enough for others.  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
if you want to allow the US, Canadian and German servers. I tested that one. 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


This was my preferred method if the IPs are known and fit the string. However if OBiTalk performs method 4 for you automatically, then I would now go that way. I would check to see what OBiTalk did for each SPn before implementing new methods:

4. Method 4 , as discovered by Oleg and applied by Mango, is to change the (Voice Services)SPn Service->X_InboundCallRoute: from {ph}, if that is what it currently is, to
{>('Insert your AuthUserName here'):ph}
This method is particularly useful for those using SIP providers that have too many IP addresses to use method #3, although it may become the preferred method for more providers. The AuthUserName can be read from your OBi or ObiTalk expert at
(Voice Services)SPx Service->AuthUserName.

Legend for examples:
6065556789 Sample trusted phone number
17771234567 Sample account name/number for SIP provider. I think they are saying for Callcentric they all start with 1777 followed by 7 more digits. Anveo is also all numbers, but
is a little shorter.

Here are some examples of the Oleg method (please suggest more examples and point out needed fixes):

OBi110 with no trusted caller set up with service 1 being routed to the phone port; (Voice Services)SP1 Service->X_InboundCallRoute:

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


OBi202  with one trusted caller with service 2 being routed to phone line 2; (Voice Services)SP2 Service->X_InboundCallRoute:
{(x.6065556789):aa},{ph2}  [before]

These are both tested to work:
{(x.6065556789):aa},{>17771234567:ph2}  [ Tested and works]
{(x.6065556789):aa},{>('17771234567'):ph2}  [Permits alphanumerics]
[The single quotes are not needed if the ID is all numbers, but will not hurt]

See note #h below.



Notes:

a. http://www.obitalk.com/forum/index.php?topic=4067.0 discusses the methods including Callcentric IP numbers. http://www.obitalk.com/forum/index.php?topic=5455.msg35330 also discusses the methods including Anveo IP numbers.

b.http://www.obitalk.com/forum/index.php?topic=3544.0 is a feature request asking that OBi firmware to allow specifying blocks of IP numbers into the X_AccessList lists.

c.  http://www.obitalk.com/forum/index.php?topic=4873.0 cites #b plus it asks that the OBi have an option to "Reject SIP requests except from registration server".

d. The motivation for the SIP scanners appears to mostly be probing for PBX servers to allow expensive international and premium calls for profit. http://en.wikipedia.org/wiki/Premium-rate_telephone_number

e. I do not know if a port set up for  Google Voice could get hit with the phantom phone calls, since it uses a different protocol. Changing  X_UserAgentPort will not hurt, and it may be proactive against somebody using that scanning with that protocol in the future.

f.  Unused ports should be disabled. One way is to un-check the (Voice Services)SPn Service->Enable box, which is Enabled by default.  The OBi202 has 4 SPn ports.  Obi100 and OBi110 have 2 SPn ports.  You could change your X_AccessList to 0.0.0.0 as a sure method.

g. Search for "SIP scanners" here or elsewhere for more information.

h. Method 4 was posted by Oleg, and Mango recognized the general applicability of this method. See http://www.obitalk.com/forum/index.php?topic=4067.80 to follow the birth and development of this method. I hope to add more examples for other SIP providers, but it is the Callcentric users who cannot use method #3. I got a hub to use Wireshark packet sniffer to monitor communications to my OBi202. Formats are similar to what Oleg saw for Callcentric. Normally you would only use one method for each SP.

j. The implementation of anti-scanner method by OBiTalk was first posted by ianobi on reply 7 of http://www.obitalk.com/forum/index.php?topic=6266.0
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Rick on March 11, 2013, 09:33:40 AM
I only have GV setup (on both SP1 and SP2), and have never rec'd any call.  I don't believe that GV is affected.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: ianobi on March 11, 2013, 10:25:36 AM
Shale,

Bringing this information together in one post is a good idea.

You can disable any SPX Service by unchecking:
Voice Services -> SPX Service -> Enable
Scanners attempting to call that SP will then receive "404:Not Found".

I'm not sure about GV either as I don't use it, but I seem to remember one user did report a scanner problem on a GV SP. Maybe someone would check using the following method:

Here is an easy way to test how well you are blocking CallerIDs. If you have chosen to also use the X_AccessList method, then you will need to include the local subnet address where you have installed PhonerLite in that list:

Download PhonerLite softphone onto a pc in the same subnet. (It's a free download).
Set up a very basic account on the PhonerLite softphone. Leave proxy/registrar blank, leave register checkbox unchecked. Fill in "User Name" - this is CallerID.
Send calls to your OBi by calling ip address:port. For example: 192.168.1.10:5061 (default for sp2)

Keep sending the same calls, but change the "User Name" to any CallerID that you wish to test as an incoming call to your OBi. This only takes about two seconds per test call - change "User Name", then hit "save" each time.

For calls that fail to get into your OBi, the Phonerlite Logbook will record "486:Busy Here".
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Shale on March 11, 2013, 10:48:33 AM
I have made changes. I don't know how I messed up the X_UserAgentPort. I also switched to SPx to represent SP1, SP2 and maybe SP3, SP4. I  used "(Voice Services)SPx Service->X_UserAgentPort" as a stylistic thing since you don't actually click "Voice Services"
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: ianobi on March 11, 2013, 11:36:30 AM
Looks good now  ;)

Let's see if others can add any more useful info to this subject.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Mango on March 19, 2013, 06:15:21 AM
Quote from: Shale on March 11, 2013, 08:57:16 AM2. Change the (Voice Services)SPx Service->X_UserAgentPort ports for each SPx  to a number not in the 506x range. This seems effective based on people's experience, but how long until the scanners broaden their scans?

I think it is unlikely the scanners will broaden their scans, though of course not impossible.

What they're trying to find is PBX systems set up with default or test settings, for example a User ID of "1001" and password of "password".  Once they find such credentials, they can route calls to high cost destinations through the compromised PBX.  Us OBi users aren't the target of their activities; we're just a side effect.  Since someone who knows enough to change their PBX's port probably also knows not to use easy passwords, I think the scanners will find themselves most successful in the 50xx range.

So, I expect your suggestion is a good one and that using a port in the range of 20000-65535 should be quite safe.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Mango on March 21, 2013, 09:37:53 AM
Shale,

Perhaps you could add Oleg's solution to this excellent post:

Change the (Voice Services)SPx Service->X_InboundCallRoute: {>('Insert your AuthUserName here'):ph}

Also, perhaps this thread could be made sticky  ;D

m.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Shale on March 22, 2013, 02:26:06 PM
Thanks. I have made fixes and additions per your suggestions.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: QBZappy on March 22, 2013, 05:08:31 PM
Quote from: Shale on March 11, 2013, 08:57:16 AM
If anybody knows an easier way to find the strings actually being used, let us know.

Phoner lite and Jitsi softphones both have built in 'wireshark like' abilities to debug calls. It should be possible to use this as a tool to read the sip information provided by the call.
http://phonerlite.de/index_en.htm
https://jitsi.org/
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Felix on March 23, 2013, 10:24:45 PM
The more I am thinking, Oleg's solution (#4) is bulletproof and doesn't have negative side effects. In other words, it's ideal.

Or what would be the situation when this wouldn't work? I assume that your adapter is not in DMZ; so if it is not registered with a provider, the port is closed to the internet. And if it is registered, then you have some kind of id that you can match against X_InboundCallRoute

Am I missing something? I don't know Oleg (I wish I knew), but it looks like a solution that is genius in its simplicity  :D
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Mango on March 23, 2013, 10:31:52 PM
I agree.  The only way for a cracker to get past it would be to guess your AuthUserName.  That would take forever, and there would be no point.

If you're not registered to a service provider, you can still set an AuthUserName if you want to.  Also, even if you don't use DMZ, it's still possible for the port to be open, if your router is not a "restricted cone NAT" type.  If your router IS a restricted cone NAT type, you don't have to worry because the router will block inbound SIP traffic except from your VoIP service provider.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up please help
Post by: claude on March 29, 2013, 12:41:58 AM
{>(123456):ph1,ph2},{(514xxxxxxx):aa},{ph1,ph2,pp1(ob500xxxxxx),sp31514xxxxxxx)}



123456 is my AuthUserName in voip.ms   123456 is fake number for this post.

my probleme is i do not received call to my sp3514xxxxxxx whe a call is placed to my voip.ms phone number

before i had (514xxxxxxx):aa},{ph1,ph2,pp1(ob500xxxxxx),sp31514xxxxxxx)}
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: ianobi on March 29, 2013, 05:24:05 AM
This rule {>(123456):ph1,ph2} is matching all CallerIDs so the other rules do not get used. I think there is also a missing "(" after sp3 in the last rule - maybe just a typo. I think this would work for you:

{(514xxxxxxx):aa},{>(123456):ph1,ph2,pp1(ob500xxxxxx),sp3(1514xxxxxxx)}


Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Shale on March 31, 2013, 12:27:40 PM
I was considering something brief as a method 5. Here was my initial idea for a description:

=============================================================
5. Have the OBi behind a Restricted Cone NAT router. I wish there was a list of such routers and settings to implement this. I don't even know what the word "cone" means in this context. We could use a page or thread describing this method that will probably need new hardware. This method seems complex to understand.
===========================================================

I fear that at this point, there is not a clear how-to statement that I could make. If I could refer to a nice list of routers along with either the settings to go restricted-cone or the statement that the router is restricted-cone, this would not yet be appropriate to this thread. With restricted cone routers, an outside server can only send packets in if you have previously sent that server a packet. There are varieties: Port-restricted cone NAT and Address-restricted cone NAT. http://en.wikipedia.org/wiki/Network_address_translation

So at this point, I don't think "method 5" is suitable to add to the list. The SIP scanner thwarting methods list needs simplification more than it needs comprehensiveness.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Felix on March 31, 2013, 07:08:39 PM
Quote from: Shale on March 31, 2013, 12:27:40 PM
So at this point, I don't think "method 5" is suitable to add to the list. The SIP scanner thwarting methods list needs simplification more than it needs comprehensiveness.
+1
from wikipedia (http://en.wikipedia.org/wiki/Restricted_cone_NAT#Methods_of_port_translation):
This terminology has been the source of much confusion, as it has proven inadequate at describing real-life NAT behavior. Many NAT implementations combine these types, and it is therefore better to refer to specific individual NAT behaviors instead of using the Cone/Symmetric terminology.

Neither OpenWRT nor DD-WRT mention anything about restricted-cone in its documentation. It will just confuse the reader without adding much value. I can't think of use-case where this approach would be best...
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Ostracus on April 01, 2013, 05:12:45 AM
Quote from: Felix on March 23, 2013, 10:24:45 PM
The more I am thinking, Oleg's solution (#4) is bulletproof and doesn't have negative side effects. In other words, it's ideal.

Or what would be the situation when this wouldn't work? I assume that your adapter is not in DMZ; so if it is not registered with a provider, the port is closed to the internet. And if it is registered, then you have some kind of id that you can match against X_InboundCallRoute

Am I missing something? I don't know Oleg (I wish I knew), but it looks like a solution that is genius in its simplicity  :D

Maybe Obihai would include it in their production digitmaps? Or at least the portal.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: MattG on April 10, 2013, 12:03:21 PM
I want to say thank you for the work so many of you have done. I still consider myself a newbie when it comes to voip and sip, and last night was the first time I've had issues with sip scanners during the night (started at 3am and every 5 min till 8am) With just a few minutes research, you guys had explained and answered all my questions.

Minor tweak to your setup instruction, as a newbie with CallCentric service I was following every character
"{>:17771234567:ph}  [after adding protection from SIP scanners]" It didn't work till I took out the first ":" {>17771234567:ph}

Thanks Again
Matt
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Agent88 on April 17, 2013, 02:42:42 PM
Quote from: Mango on March 19, 2013, 06:15:21 AM
Quote from: Shale on March 11, 2013, 08:57:16 AM2. Change the (Voice Services)SPx Service->X_UserAgentPort ports for each SPx  to a number not in the 506x range. This seems effective based on people's experience, but how long until the scanners broaden their scans?

I think it is unlikely the scanners will broaden their scans, though of course not impossible.

What they're trying to find is PBX systems set up with default or test settings, for example a User ID of "1001" and password of "password".  Once they find such credentials, they can route calls to high cost destinations through the compromised PBX.  Us OBi users aren't the target of their activities; we're just a side effect.  Since someone who knows enough to change their PBX's port probably also knows not to use easy passwords, I think the scanners will find themselves most successful in the 50xx range.

So, I expect your suggestion is a good one and that using a port in the range of 20000-65535 should be quite safe.

I just became a member here today, and to my surprise came upon this topic.  I have been getting these spam calls on my softphone I use with my RingCentral account.  They started last October and got worse by January.  I made numerous calls to RC tech support and spent hours upon hours with their level 3 engineers trying to stop them.  They began by downloading Wireshark on my PC, showing me how to catch the IP of the ringing offender.  Then I was told to put them in my Windows 7 firewall to block that IP.  This was an exercise like "whack-a-mole" at Chuckee Cheeze.  After entering two or three dozen IPs in my firewall even I realized I needed another approach, so I called tier 3 once more and this latest engineer had me change my LAN IP because it appeared to her that the scanner was using my softphone IP to do the dirty deed.  I had been told at one point that I should change my port configuration, but it was never done.  Now I read this forum and think that would have done the trick.

But wait, there's more:  I noticed in configuring my Cisco devices that provisioning had made some mistakes in my dial plan relating to 7-digit dialing, which I fixed with the help of Cisco t/s.  Are you saying that I might be able to add the instuctions about establishing an authorization name to block the ITSP's IP to the dial plan?  How would I go about this, or is this an instruction set just for the OBI Expert configuration file?
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: QBZappy on April 17, 2013, 03:04:16 PM
Welcome,

That method you referenced has been superseded. The mother of all solutions for scanner blocking has been developed by our friend oleg. Look him up in the search. He doesn't post often, however his contributions are significant. He is what I like to call a "deep thinker".  :)
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: zapattack on April 20, 2013, 10:38:48 AM
http://www.obitalk.com/forum/index.php?topic=5467.0
Reply #6 from Mango
is the short answer.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Jackson on May 03, 2013, 07:12:14 AM
I have Anveo for a backup + e911.    Took me a bit to figure out what those pesky rings were.

Simply followed this advice:

QuoteI 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.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: ontwowheels on June 14, 2013, 05:42:27 AM
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.

Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Shale on June 14, 2013, 07:14:28 AM
Quote from: ontwowheels on June 14, 2013, 05:42:27 AM
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.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: ontwowheels on June 15, 2013, 05:43:36 PM
Quote from: Shale on June 14, 2013, 07:14:28 AM
Quote from: ontwowheels on June 14, 2013, 05:42:27 AM
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.   ;)
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: 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
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: ontwowheels on June 17, 2013, 10:42:13 AM
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.   
Title: HOWTO: Thwarting SIP Scanners during obi110 Set-up behind pfsense
Post by: mayge on July 16, 2013, 11:10:10 AM
Quote from: Shale on March 11, 2013, 08:57:16 AMFor 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 (http://wiki.voip.ms/article/Choosing_Server)

Quote from: =http://wiki.voip.ms/article/Choosing_Serverthat 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.

Quote67.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

(http://img18.imageshack.us/img18/9316/vhsf.png)

But it seems BBcode Quote is at fault

(http://img40.imageshack.us/img40/8509/sdl.png)
(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

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

QuoteX_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.

Quoteanveo 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
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Shale on July 16, 2013, 12:30:28 PM

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.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Mango on July 16, 2013, 07:31:00 PM
Quote from: Shale on June 14, 2013, 07:14:28 AMIt 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 PMI 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.

Title: Re: HOWTO: Thwarting SIP Scanners during obi110 Set-up behind pfsense
Post by: carl on July 16, 2013, 09:17:14 PM
Quote from: mayge on July 16, 2013, 11:10:10 AM

Quoteanveo 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.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: newobi on August 18, 2013, 07:36:22 AM
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?
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Mango on August 18, 2013, 08:13:22 AM
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.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: ianobi on August 18, 2013, 08:22:50 AM
QuoteIs @ 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.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: bsdaiwa on August 18, 2013, 09:02:42 AM
Quote from: Shale on March 11, 2013, 08:57:16 AM

{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
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Shale on August 18, 2013, 09:05:33 AM
Quote from: bsdaiwa on August 18, 2013, 09:02:42 AM
Quote from: Shale on March 11, 2013, 08:57:16 AM

{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.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: bsdaiwa on August 18, 2013, 09:11:25 AM
Quote from: Shale on August 18, 2013, 09:05:33 AM
Quote from: bsdaiwa on August 18, 2013, 09:02:42 AM
Quote from: Shale on March 11, 2013, 08:57:16 AM

{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
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: newobi on August 18, 2013, 09:22:33 AM
Thanks everyone.  I will use Oleg's method #4.  Going to set up my parent's also, before they start getting the SIP scanners.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Shale on August 18, 2013, 09:40:24 AM
Quote from: newobi on August 18, 2013, 09:22:33 AM
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.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: newobi on August 18, 2013, 06:44:34 PM
Quote from: Shale on August 18, 2013, 09:40:24 AM
Quote from: newobi on August 18, 2013, 09:22:33 AM
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.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: gtech on November 16, 2013, 01:05:27 PM
Quote from: bsdaiwa on August 18, 2013, 09:02:42 AM
Quote from: Shale on March 11, 2013, 08:57:16 AM

{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
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: giqcass on November 22, 2013, 12:30:46 AM
Using the Oleg method you can still use Ip dialing just fine as long as the oncoming sip uri includes your auth name.  You can also define multiple auth names with the Oleg method which is great because you can send them to different paths as well if you like.
{} is only needed in the more complex call routes. It simplest to just put them in all the time to eliminate errors.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: absteeve on January 05, 2014, 05:06:42 AM
Hi.  New here.  It is 4:57am as I begin writing this... been up since 4am... sure you can figure out why :(

First, I'm unclear on a lot of all this but THANK YOU for the solution.  I keyed in quickly that Oleg's method is preferred.  I inputted that (while under attack), hit reboot... problem solved.  So that's fine, except:

1) I don't understand WHY it works or WHAT it does, so I'm not all that confident that I didn't just block everyone from calling me.
2) I don't understand why my PROVIDER isn't solving this issue.  I use Callcentric, which seems to me to be a large, reputable, and experienced provider.  Why are they using default ports and allowing such attacks to their customers?
3) I'm also trying to figure out if the reason for these attacks suddenly hitting me is because a) I switched from voip.ms to Callcentric or b) I switched from a PAP2T to a OBi100 or c) I switched from being behind a router to being in front of it.

Some more information on #3:
- I switched to Callcentric because they could port my home # and voip.ms couldn't.  I was happy at first because the call quality seemed immediately better.  HOWEVER, I've been battling frequent problems of calls disconnecting @ 5 minutes and/or one-way audio (always on incoming calls).
- Due to those problems, Callcentric suggested the problem was with my PAP2T device, so I got an OBi100.  The OBi was never used on voip.ms.  That's why I don't know which is causing this SIP attack issue (that I never had in YEARS with voip.ms/PAP2T).
- When switching to the OBi didn't help (dropped calls/one-way audio) they suggested it was probably my router, so I plugged it directly to the modem's 2nd port (mine has 2 available ports each getting its own WAN IP).  That actually appeared to resolve the problem because immediately from the very first test call after that switch for the next 48 hours... not a single dropped call or one-way audio issue.  However, after that (with no changes at all), back to frequent drops and one-way audio on incoming.

And, of course, now as of 4am... annoying bloody calls from these sip scanner attacks.

So now its 5:05am... still no calls since implementing the Oleg fix.  I'm going back to bed for the next 45 minutes or so before my 2yr old wakes up (sigh).  Hopefully in the morning you guys will have me comforted that Oleg's method isn't blocking wanted calls and maybe, just maybe, someone can give me some tips on my other problems (though I realize that's off topic)
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: sdb- on January 05, 2014, 07:52:46 AM
3.c.

If done correctly it should let your provider contact your OBi, thus allowing calls as normal.

Prior to 3.c. the router was blocking incoming connection attempts.  Now your OBi does not have that protection and is fully exposed to the Internet.  Those scans/attempts come directly to your OBi without passing thru Callcentric or your router.

You could try putting the OBi back behind the router and turning off anything SIP related in your router.  Anything else you do (DMZ or portforward to the OBi) will have the same effect as bypassing the router.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: absteeve on January 05, 2014, 08:03:49 AM
OK, thanks.  For now I'll keep it exposed.  I want to eliminate variables while we (Callcentric and I) attempt to fix the call drop-outs and one-way audio issues.  It seems the router isn't the problem, of course, but until its fixed I don't want to introduce it back into the mix.  But at least now I know why the sudden barrage of calls this morning!
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Ostracus on January 05, 2014, 05:13:44 PM
Hmmm, audience. Think a little syslogging will help? ;)
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: absteeve on January 05, 2014, 05:41:02 PM
Yeah, that!  How?
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Shale on January 08, 2014, 12:46:34 PM
absteeve wrote:
>1) I don't understand WHY it works or WHAT it does, so I'm not all
>that confident that I didn't just block everyone from calling me.

The SIP provider puts your account number in its packet. The malefactor won't know that number to put it in.

>
>2) I don't understand why my PROVIDER isn't solving this issue.  I
>use Callcentric, which seems to me to be a large, reputable, and
>experienced provider.  Why are they using default ports and
>allowing such attacks to their customers?

Your provider is totally not involved. The request came directly to you without involving your provider.
>
>3) I'm also trying to figure out if the reason for these attacks
>suddenly hitting me is because a) I switched from voip.ms to
>Callcentric or b) I switched from a PAP2T to a OBi100 or c) I
>switched from being behind a router to being in front of it.

Yes, probably 1c.. However not all routers would have saved you. If your router opens the port, you will still get that 4am wakeup. Most of us that got bit were behind routers.

Another possibility is that the SIP scanner had not found you yet.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: sdb- on January 09, 2014, 06:55:07 AM
Quote from: Shale on January 08, 2014, 12:46:34 PM
>c) I switched from being behind a router to being in front of it.

Yes, probably 1c.. However not all routers would have saved you. If your router opens the port, you will still get that 4am wakeup. Most of us that got bit were behind routers.

Most routers should not "open" the port, but rather allow thru responses matching the expected session (or flow).

Every IP packet has a source address and source port, and a destination address and destination port. The firewall in "allow outgoing" establishes an expected session from the source address and port to the destination address and port and will allow a response which has both tuples in the opposite locations.

In other words, if my OBi at 172.31.0.8:22334 tries to talk thru my firewall to 1.2.3.4:5260 on the outside, only responses from 1.2.3.4 will be allowed in, and only if they come from port 5260 and are directed inward to port 22334.

If a port is forwarded, then it will be "open."  Otherwise if you have a router which just decides to "open" the port to any incoming traffic, it is broken.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Shale on January 09, 2014, 07:30:45 AM
Quote from: sdb- on January 09, 2014, 06:55:07 AM
Most routers should not "open" the port, but rather allow thru responses matching the expected session (or flow).

1. http://en.wikipedia.org/wiki/Network_address_translation#Methods_of_port_translation shows the various methods of translation.  People have to deal with what is their router does do rather than what it "should" do.

2. Some people put the OBi into the DMZ to get things working, and don't keep working beyond that. Some just pass through some ports, but that still leaves them open to SIP scanners.

3. New firmware, such as Tomato, can change the method of port translation for many routers.

4. The Oleg method saves you even if your router is in the DMZ.

5. OBi now incorporates the Oleg method when it does the setup for its list of SIP providers.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: sdb- on January 10, 2014, 06:56:49 AM
Quote from: Shale on January 09, 2014, 07:30:45 AM
Quote from: sdb- on January 09, 2014, 06:55:07 AM
Most routers should not "open" the port, but rather allow thru responses matching the expected session (or flow).

1. http://en.wikipedia.org/wiki/Network_address_translation#Methods_of_port_translation shows the various methods of translation.  People have to deal with what is their router does do rather than what it "should" do.

Yeah, but have you have proved to have one?  In that description, "full cone NAT" is the only one which does the behavior you described.

Further, that terminology of describing port translation is obsolete because it did not adequately describe what happens in the real world.

Quote from: wikipediaThis terminology has been the source of much confusion, as it has proven inadequate at describing real-life NAT behavior. Many NAT implementations combine these types, and it is therefore better to refer to specific individual NAT behaviors instead of using the Cone/Symmetric terminology.

and

Quote from: ibidEspecially, most NAT translators combine symmetric NAT for outgoing connections with static port mapping, where incoming packets to the external address and port are redirected to a specific internal address and port.

Which is the normal behavior today and that static port mapping (either individually or via a "DMZ host") is only way I have ever seen intentional "full cone NAT" existing in the real world.

As for your #2, of course users can break things.

Your #3, see above.

The rest, yeah I agree.


By the way, I write router firmware for a living and have been implementing and designing network protocols since long before NAT was standardized.  I have not seen it all.  But I have worked with a lot of it.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: pointpeninsula on April 30, 2014, 07:26:41 PM
Hello all, another newbie here.

I realize this thread is getting old, but as I'm just now transitioning from GV to Anveo, I've run into this problem. Many thanks to you all for the help, and with luck I'll get a good night's sleep without unplugging the phone.

I do have one question, though. I've implemented the #3 solution (X_InboundCallRoute method), and nowhere in the allowable syntax for digitmaps can I find a single '>' symbol used. Can anyone explain how that's used as a prefix to the AuthUserName?

Another comment: Nowhere in the manual, or online, have I seen the admonition that you can change these settings with the webserver built into the unit on the local IP address until your fingers fall off, but the variables will always revert to the default. The expert configuration must be done on the Obitalk web site. It seems odd that it should be the case, but Obihai's support folks told me that outright, and by experimentation, I've found it to be the case.

I emphasize this as a warning to other newbies as GV is turned off.

Thanks again,
Tom
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Mango on May 01, 2014, 08:18:22 AM
I believe the InboundCallRoute syntax is described here: http://www.obihai.com/OBiDeviceAdminGuide#_Toc367543130

Specifically, the > character is used in a peering-list to denote a callee-list.

With regards to a post earlier in the thread: while the Oleg method may make your device perform properly if in DMZ, it will not fully protect your device like a properly-configured firewall would.  For example, your device could still be brute forced if it is in DMZ.

Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Terry on May 01, 2014, 12:09:02 PM
Quote from: pointpeninsula on April 30, 2014, 07:26:41 PM
Another comment: Nowhere in the manual, or online, have I seen the admonition that you can change these settings with the webserver built into the unit on the local IP address until your fingers fall off, but the variables will always revert to the default. The expert configuration must be done on the Obitalk web site. It seems odd that it should be the case, but Obihai's support folks told me that outright, and by experimentation, I've found it to be the case.

If I understand what's going on with Obi's "preferred" providers and their special offers, they are controlling things via "provisioning"  to make sure that well-meaning customers don't change something inadvertently and cause them (customer and provider) frustrating and expensive service calls. The provisioning does seem to assert more control over settings than, say, GV used to have.

On that subject, if the setting Anveo (for example) "provisions" to my Obi is allowing the annoying sip scanners in, even though Anveo can't control what the scanners do, since they CAN and DO control the settings of my Obi through their provisioning, and since there is a simple and working way to reject the sip scanner calls, I think it is perfectly logical to blame Anveo for the sip scanner calls getting through, since it is THEIR setup that is leaking.

If they are going to have that much control over my device, they need to take more responsibility. And, hey, since the solution is simple and therefore inexpensive (or free) to implement, just set it up in the provisioning. No excuses.

Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: drgeoff on May 01, 2014, 02:18:43 PM
Quote from: pointpeninsula on April 30, 2014, 07:26:41 PM
Another comment: Nowhere in the manual, or online, have I seen the admonition that you can change these settings with the webserver built into the unit on the local IP address until your fingers fall off, but the variables will always revert to the default. The expert configuration must be done on the Obitalk web site. It seems odd that it should be the case, but Obihai's support folks told me that outright, and by experimentation, I've found it to be the case.

So you haven't noticed the fourth 'sticky' at http://www.obitalk.com/forum/index.php?board=1.0 with the title:  "Managing Your OBi Device Configuration: OBiTALK or OBi Web Page but NOT Both".

And the last 'sticky' at http://www.obitalk.com/forum/index.php?board=3.0 has the same title and is a link to the one above.

It is quite simple to make configuration changes using the OBi's built-in web pages and not have them reverted back by the OBiTALK portal.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: dconway on May 10, 2014, 07:36:56 PM
I recently switched to PhonePower (with the whole Google Voice deprecation of XMPP) and am having trouble with back to back SIP scanner calls coming from "2001" on my callerID.  I want to use "Oleg's Method #4" from this thread but the AuthUserName is blank in ObiTalk portal (whereas for a service like Callcentric you have a clear ID typically beginning with 1777...).

Anyway, when I log into phonepower portal, there's an option to turn on SIP credentials but there's a massive disclaimer about risk (quoted below) and they will disable features like international dialing.

Does anyone know what value I need to subsitute for {ph}in X_InboundCallRoute to get "Oleg's Method #4" to work with PhonePower?  Thanks for this great thread and for any help you can provide.

QuoteSIP Credentials
Your SIP Credentials are currently not enabled. SIP Credentials are designed for advanced users. Customers with SIP Credentials enabled have a limit of 4 registrations and 2 total concurrent calls. Disabling your SIP Credentials will remove these restrictions.

By choosing to enable your SIP Credentials you understand that Phone Power will not offer any technical support for your hand-configured device(s). Phone Power will continue to offer normal support for all auto-provisioning devices, including Phone Power supplied phone adapters, softphones, zippyphones, BYOD devices that use Phone Power's auto provisioning system, etc. If you are unable to configure your device(s) yourself, please deactivate your SIP Credentials and contact support.

After enabling your SIP Credentials, you will need to reboot all devices connected to the Phone Power network. This includes rebooting Phone Power supplied adapters, softphones, zippyphones, BYOD devices that use Phone Power's auto provisioning system, etc.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Taoman on May 10, 2014, 08:52:17 PM
Quote from: dconway on May 10, 2014, 07:36:56 PM

Does anyone know what value I need to subsitute for {ph}in X_InboundCallRoute to get "Oleg's Method #4" to work with PhonePower?  Thanks for this great thread and for any help you can provide.

You need to enable SIP credentials or you don't have SIP, do you? Are you saying you haven't enabled SIP credentials but you are registering and making and receiving calls? How would you know your SIP password?

Here is the string for X_InboundCallRoute: {>xxxxxxxxxx:ph}

where xxxxxxxxxx is your AuthUserName which is your Auth ID which is your PhonePower supplied phone number.

Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: dconway on May 11, 2014, 05:56:05 PM
Problem is there is no ID to insert.
Luckily PhonePower responded to a support ticket I submitted and recommended following the instructions here.  Hopefully that helps
http://www.phonepower.com/wiki/Obihai_Lite#Disable_Direct_IP_Dialing
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: TonyC on May 17, 2014, 10:06:58 PM
I know this topic is old, but I just switched over to Future-Nine from GV and within 24 hours my OBI202 came under SIP attack (it is BEHIND my NetGear firewall).  I even went so far as to read my NetGear log files and block individual IP addresses but still the attacks continued....every 25 minutes like clockwork.  I followed the advice below and the insanity stopped immediately.  I used steps 0, 2, & 4. 

On step 4 I did not use (), just this >AuthUserName:ph where AuthUserName is supplied in SIP Credentials section on the same config page - just below the SP1 Service Group   

PEACE & quiet AGAIN !  Thank you Mango.

Tony 

Quote from: Mango on August 18, 2013, 08:13:22 AM
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.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Look30 on June 25, 2014, 05:55:36 PM
Great !
Thanks TonyC and Mango.

Quote from: TonyC on May 17, 2014, 10:06:58 PM
I know this topic is old, but I just switched over to Future-Nine from GV and within 24 hours my OBI202 came under SIP attack (it is BEHIND my NetGear firewall).  I even went so far as to read my NetGear log files and block individual IP addresses but still the attacks continued....every 25 minutes like clockwork.  I followed the advice below and the insanity stopped immediately.  I used steps 0, 2, & 4. 

On step 4 I did not use (), just this >AuthUserName:ph where AuthUserName is supplied in SIP Credentials section on the same config page - just below the SP1 Service Group   

PEACE & quiet AGAIN !  Thank you Mango.

Tony 

Quote from: Mango on August 18, 2013, 08:13:22 AM
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.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: SSmith on June 30, 2014, 01:12:18 PM
QuoteOn step 4 I did not use (), just this >AuthUserName:ph where AuthUserName is supplied in SIP Credentials section on the same config page - just below the SP1 Service Group

FWIW, my AuthUserName is alpha-numeric and calls would be rejected unless I used the
     >('AuthUserName'):ph
syntax. 

It makes sense from the Admin guide that an all-numeric AuthUserName would not require the parentheses and hyphens but an alpha-numeric one would.  Presumably, the hyphens would not be necessary if the AuthUserName did not include any reserved characters but mine does.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: azrobert on June 30, 2014, 03:43:05 PM
Quote from: SSmith on June 30, 2014, 01:12:18 PM
    >('AuthUserName'):ph
syntax.  

It makes sense from the Admin guide that an all-numeric AuthUserName would not require the parentheses and hyphens but an alpha-numeric one would.  Presumably, the hyphens would not be necessary if the AuthUserName did not include any reserved characters but mine does.

I believe you are wrong and TonyC is correct.

{>('AuthUserName'):ph}

When you enclose the string in parentheses (like above rule) it becomes a DigitMap. In a DigitMap reserved characters must be enclosed in quotes if you don't want to use them as reserved characters, so what you coded is a correct syntax.


Here is where you are wrong:
When you don't enclose the string in parentheses like this:
{>AuthUserName:ph}

The string becomes a literal and all characters including reserved characters are valid without quotes.

Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: InsanitySix on August 10, 2014, 06:46:22 AM
The cheapskate that I am.. I bought a newer Obi100 and use Ring.To (from a GrooveIP account I had) and Anveo e911.  Except for the almost immediate SIP scanner issue, it all works better than it should (pretty much perfectly).  Actually I manly did it for a spare line for my kids when they are home and we are out so we can take both of our cell phones with us.

So because of that I really didn't need more.  We still use our cells as our primary lines.

ANYWAY.  The setup that Obihai does automagically for this is the Oleg #4 for Anveo e911 (SP2) but not for ring.to!  It was port 5060 and {ph} for SP1.

So for the last two months or so I been fine with the {?|x|xx|xxx...} method.  But this morning "AS100" kept calling.. ;)  So I did block that string and also changed the ports to a high random for both SP1/Ring.to and SP2/Anveo e911.

The AuthUserName for ring.to is a string like the following "ringto_user_12345".  What's the proper method of using Oleg's#4 with this string?  Could I and should I combine it with the {?|x|xx|xxx} method as well?  This might, for instance be handy for whomever with otherwise legit numbers I want to put right to Ringto voicemail.

Thanks much..

The Crazy One.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Mango on August 10, 2014, 07:14:02 AM
Set the following as your (Voice Services) SPn Service->X_InboundCallRoute

Only accept calls destined for your AuthUserName:
{>('ringto_user_12345'):ph}

Reject calls with specific Caller ID numbers, accept all other calls destined for your username: (note this is one of multiple ways to do this)
{(2064560661|9052811282|8888001250):},{>('ringto_user_12345'):ph}
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Taoman on August 10, 2014, 07:54:56 AM
Quote from: Mango on August 10, 2014, 07:14:02 AM

{(2064560661|9052811282|8888001250):},{>('ringto_user_12345'):ph}

Thanks for this info. Didn't realize you could combine the Oleg method with individual numbers you wanted to block. However, the syntax you used wouldn't work for me. I had to remove the ":" after the numbers that I wanted blocked in order for it to work. I assume you made a typo or should it actually work the way you have it listed? Thanks.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Mango on August 10, 2014, 08:03:20 AM
Actually that wasn't a typo.  What I posted was based on the rule at http://www.obihai.com/docs/OBiDeviceAdminGuide.pdf, at the bottom of page 194.  However, as long as what you are doing works, then that's just fine.  :)

Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: drgeoff on August 10, 2014, 12:53:58 PM
According to page 193 of said document the ':' must NOT be omitted.

Quote
rule := peering-list : terminal-list
.
.
Terminal-list can be empty, which means to block this call. The preceding ':' cannot be omitted.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: oldunixguy on October 27, 2014, 11:52:25 PM
I'm having trouble making this work with my new Obi200 devices.

1. So called Method 4 states to change "(Voice Services)SPn Service->X_InboundCallRoute: from {ph}"
to:
{>('Insert your AuthUserName here'):ph}

Well, The default for the field on the 200 is not {ph} but rather just plain ph.

Why is this? Is this default wrong?

2. When I do change this (I'm using Google Voice) to:
{>('myaddress@gmail.com'):ph}

incoming calls STOP. I am completely certain that I have my gmail address correct. Also, outgoing calls still work.

Changing the field back to ph makes it work again.

What is going wrong and how do I fix this?

thanks in advance
oldunixguy


Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Mango on October 28, 2014, 04:42:24 AM
This is not required for Google Voice as it does not use SIP.  You can leave the X_InboundCallRoute at its default.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: lhm. on October 28, 2014, 05:04:15 AM
Or this: {>('1XXXXXXXXXX'):ph}

Edit: Not sure it actually protects, but does allow in an out bound calls from AA thru GV.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Jax69 on October 29, 2014, 06:34:45 PM
Ok guys, I've been trying to make heads or tails of this issue. It just started happening to me and I have my OBi100 configured to GV. I started getting calls from 1001 since about 3pm and every 10min it is now 6:15pm).

I checked the ports, as it said in the beginning of this thread, and my X_UserAgentPort port is not set to 506X. I use both SPx lines and neither is set to near that port.

I did change the X_InboundCallRoute to what was stated {>('1xxxxxxx'):ph}  (where the x's are the phone number) on both sp lines. That made is so I couldn't receive calls.

Now my SP1 line is configured to Simon Technologies, this is so I can receive the caller id (I'm not sure if this is still needed or if I can just kill that line).

My SP2 is my GV configuration. In playing with the X_InboundCallRoute I found if I change the GV one to
{>('1XXXXXXXXXX'):ph} (where the x's are my phone number) I can now receive and make calls.

So far the dialing from 1001 has stopped but wanted to know if I should be worried as I have 3 other obi boxes for my other lines but this one is the only one configured to Simon Technologies for one of the sp's.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Mango on October 29, 2014, 06:43:22 PM
If SP2 is configured for Google Voice, the SIP scanners must be arriving via SP1.  You can confirm my guess by checking Call History.

For SP1, is your AuthUserName the same as 1xxxxxxx?  If not, that is why your X_InboundCallRoute failed.  The correct syntax is:

{>('Insert your AuthUserName here'):ph}

If you use port forwarding or DMZ on your router, you should remove it, unless things won't work any other way.  Using port forwarding or DMZ disables your router's firewall and leaves your OBi open to the internet.  If you're not doing this, then you have a "full cone NAT" router which is effectively a port forward.  If possible, configure your router so that its firewall is more secure.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Jax69 on October 29, 2014, 07:13:56 PM
The configuration I now have is preventing the scan to come through. I don't have a DMZ or use port forwarding so just regular NAT is in place. I'll have to relook at the settings on the router. Not sure if I really need the Simon Technologies setting I may delete it unless it really has a purpose. I think GV currently uses a caller id type thing.

I'm not really technical when it comes to PBX config but I can muddle my way through it. Thank you for the feedback.

Update:
I went ahead and updated the SP1 back so it matched the SP2 setting and scanning calls started again so I know it's from the Simon Technologies site or set up that is causing the issue. I'll have to delete that setting in SP1.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Veronica on November 02, 2014, 09:25:52 AM
Hello 2 days ago i received over 10 calls from "1001" it's been a long time since i didn't receive 1001, 100 or 101 ghosting calls. So i got fed up and starting browsing the web for a solution and i found other forum which suggested to change X_UserAgentPort (i checked but i already had done that for both my SPx services) and this:

{(?|x|xx|xxx|xxxx|xxxxx):},{ph}

My setup is SP1 for FreePhoneLine (canadian #) and SP2 for Google Voice. Confirmed all the ghosting calls came from SP1 looking at Call History.

The method described above worked i guess because i didn't received more calls from "1001" BUT yesterday and today (this last woke me up so i unplugged my OBI 110 power) received calls from "default". So i had no more choice than keep looking for a solution and just found these thread very fast.

I just setup {>('Insert your AuthUserName here'):ph} and will report back if i get those again. I just hope there is no problem for "Unknown" calls.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Mango on November 02, 2014, 09:43:10 AM
The rule you used previously seems to block anonymous calls, and with a Caller ID of five or less characters numbers.  Since "default" is seven characters not numeric, the call was routed to your phone.  Your new rule should be more reliable as it only accepts calls destined for your AuthUserName.

I also suggest you set X_UserAgentPort to a random number between 20000 and 65535.  Obscurity is part of security.  Out of curiosity, what was your X_UserAgentPort set to, when you received the call from "default"?

Edits for technical accuracy.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Veronica on November 05, 2014, 08:53:56 AM
ok, i just realised about that, results i got confused. I thought "x" took numbers also too.

Anyways the port i use is 5080, i know that's not too far from 5060.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: N2VWZ on April 27, 2015, 12:58:01 PM
Quote from: Shale on March 11, 2013, 08:57:16 AM
Note: Things changed for the better about June/July 2013. OBiTalk has been implementing method 4, Oleg method described below, for at least some of the SIP providers by default. If your provider is not one that OBiTalk lists or if you get a SIP scan, or if you have overridden the X_InboundCallRoute so that OBiTalk does not control the field, or if you choose to not use OBiTalk, the information below will still apply. (note #j)
     =========The need for the following has been reduced========

An unfortunate thing we all must learn about is how to thwart SIP scanners.  It is best to handle this now rather than getting motivated at 4AM by a phantom call with caller ID "1001" or some such.  There are four ways to address the SIP scan intruders.  For those using OBiTalk to set things up (as I do), each involves using the "OBI Expert Configuration" to change values from the defaults.  Methods (pick one only for each SPn Service that is not set up for GV):

0. Disable any unused SPn Service by un-ticking (Voice Services)SPn Service->Enable. This may be unneeded, but it will not hurt for an unused SPn

1. Filter on the length of the caller ID string. This is more complex and seems less effective IMHO.  It would seem easy to circumvent by spoofing a real number.

2. Change the (Voice Services)SPn Service->X_UserAgentPort ports for each SPn  to a number not in the 506x range. This seems effective based on people's experience, but how long until the scanners broaden their scans?

3.  Change the X_AccessList value for each service to permit only the listed IP addresses to be used as a SIP server.   If using ObiTalk expert configuration, that path would be :
System Management -> Service Providers-> ISTP Profile n SIP -> X_AccessList

The list is limited in the OBi boxes to 512 characters, and each item in the list can be up to 16 characters long with an average of 14.28 while we are using IPV4 addressing.  This would permit maybe 36 addresses to be listed in a comma-separated list.  This will be plenty for some SIP suppliers, but not enough for others.  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
if you want to allow the US, Canadian and German servers. I tested that one. 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


This was my preferred method if the IPs are known and fit the string. However if OBiTalk performs method 4 for you automatically, then I would now go that way. I would check to see what OBiTalk did for each SPn before implementing new methods:

4. Method 4 , as discovered by Oleg and applied by Mango, is to change the (Voice Services)SPn Service->X_InboundCallRoute: from {ph}, if that is what it currently is, to
{>('Insert your AuthUserName here'):ph}
This method is particularly useful for those using SIP providers that have too many IP addresses to use method #3, although it may become the preferred method for more providers. The AuthUserName can be read from your OBi or ObiTalk expert at
(Voice Services)SPx Service->AuthUserName.

Legend for examples:
6065556789 Sample trusted phone number
17771234567 Sample account name/number for SIP provider. I think they are saying for Callcentric they all start with 1777 followed by 7 more digits. Anveo is also all numbers, but
is a little shorter.

Here are some examples of the Oleg method (please suggest more examples and point out needed fixes):

OBi110 with no trusted caller set up with service 1 being routed to the phone port; (Voice Services)SP1 Service->X_InboundCallRoute:

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


OBi202  with one trusted caller with service 2 being routed to phone line 2; (Voice Services)SP2 Service->X_InboundCallRoute:
{(x.6065556789):aa},{ph2}  [before]

These are both tested to work:
{(x.6065556789):aa},{>17771234567:ph2}  [ Tested and works]
{(x.6065556789):aa},{>('17771234567'):ph2}  [Permits alphanumerics]
[The single quotes are not needed if the ID is all numbers, but will not hurt]

See note #h below.



Notes:

a. http://www.obitalk.com/forum/index.php?topic=4067.0 discusses the methods including Callcentric IP numbers. http://www.obitalk.com/forum/index.php?topic=5455.msg35330 also discusses the methods including Anveo IP numbers.

b.http://www.obitalk.com/forum/index.php?topic=3544.0 is a feature request asking that OBi firmware to allow specifying blocks of IP numbers into the X_AccessList lists.

c.  http://www.obitalk.com/forum/index.php?topic=4873.0 cites #b plus it asks that the OBi have an option to "Reject SIP requests except from registration server".

d. The motivation for the SIP scanners appears to mostly be probing for PBX servers to allow expensive international and premium calls for profit. http://en.wikipedia.org/wiki/Premium-rate_telephone_number

e. I do not know if a port set up for  Google Voice could get hit with the phantom phone calls, since it uses a different protocol. Changing  X_UserAgentPort will not hurt, and it may be proactive against somebody using that scanning with that protocol in the future.

f.  Unused ports should be disabled. One way is to un-check the (Voice Services)SPn Service->Enable box, which is Enabled by default.  The OBi202 has 4 SPn ports.  Obi100 and OBi110 have 2 SPn ports.  You could change your X_AccessList to 0.0.0.0 as a sure method.

g. Search for "SIP scanners" here or elsewhere for more information.

h. Method 4 was posted by Oleg, and Mango recognized the general applicability of this method. See http://www.obitalk.com/forum/index.php?topic=4067.80 to follow the birth and development of this method. I hope to add more examples for other SIP providers, but it is the Callcentric users who cannot use method #3. I got a hub to use Wireshark packet sniffer to monitor communications to my OBi202. Formats are similar to what Oleg saw for Callcentric. Normally you would only use one method for each SP.

j. The implementation of anti-scanner method by OBiTalk was first posted by ianobi on reply 7 of http://www.obitalk.com/forum/index.php?topic=6266.0


The latest firmware has a new parameter in the SP1. . .SPx menu:

X_AcceptSipFromRegistrarOnly

Checking the box seems to effective against Sip Scanners.  This method should be added to the main list on page 1.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: oldunixguy on April 27, 2015, 10:10:24 PM
I just updated firmware in my Obi 200 using ***6
HardwareVersion   1.4
SoftwareVersion   3.0.1 (Build: 4477)

1. I can't find this new parameter X_AcceptSipFromRegistrarOnly
2. I'm getting "can't complete call" intermittently and only on certain numbers.

Any ideas?

thanks
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: WelshPaul on April 27, 2015, 11:16:15 PM
Quote from: oldunixguy on April 27, 2015, 10:10:24 PM
I just updated firmware in my Obi 200 using ***6
HardwareVersion   1.4
SoftwareVersion   3.0.1 (Build: 4477)

1. I can't find this new parameter X_AcceptSipFromRegistrarOnly
2. I'm getting "can't complete call" intermittently and only on certain numbers.

Any ideas?

thanks

For the record... the latest firmware is 3.0.1 (Build: 4581)

Try dialling ***6 again or download the latest here: http://fw.obihai.com/OBi2-latest.fw

X_AcceptSipFromRegistrarOnly can be found under Voice Services > SPx. It's the sixth parameter down in the list.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: oldunixguy on April 27, 2015, 11:21:06 PM
I'm confused then... I just prior to my post performed the ***6 firmware update....  does it not update it to the latest version?

It is clear that it DID perform an update because the prior one that was running before I did this was 3.0.1 Build 4420

Can you explain?

thanks
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: WelshPaul on April 28, 2015, 03:42:15 AM
Quote from: oldunixguy on April 27, 2015, 11:21:06 PM
I'm confused then... I just prior to my post performed the ***6 firmware update....  does it not update it to the latest version?

It is clear that it DID perform an update because the prior one that was running before I did this was 3.0.1 Build 4420

Can you explain?

thanks

Updating via **6 is unpredictable. If you have not updated your firmware in some time then you will usually hear a message telling you 'software update not available' even though there is actually a new firmware version available. Other times you hear the same message if you're two or more versions behind the current latest release, sometimes it does indeed find an update and proceed to update the device however it sometimes doesn't update the device to the very latest release like it did for you...

Then again - sometimes it actually does install the latest firmware even though your several firmware revisions behind or haven't done an update in months.

Previously I had two OBi202's that were both purchased at the same time, both had the same firmware versions at the time (I forget what version they were on), I knew there was a later firmware version available so I proceeded to update both via the ***6 method, the first updated just fine, the second device kept telling me 'software update not available'.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: pbd3mon on June 04, 2015, 06:41:31 AM
Hello everyone, thank you for taking the time to provide all of this information.  Like everyone else that ended up here I too fell victim to the middle of the night calls  >:(

Based on method #3 I tried to apply the X_AccessList IPs through OBiTalk but I was not successful.  The field will not allow me to input anything... The OBiTalk settings box is checked.  What am I doing wrong?

Also I see ITSP Profile A SIP and ITSP Profile B SIP, do both have to be provided with the IPs?

Thank you in advance for your help in this matter.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: azrobert on June 04, 2015, 07:59:03 AM
QuoteThe OBiTalk settings box is checked.
Uncheck the box under OBiTalk Setting
Then uncheck the box under Device Default
Now change the value
Click Submit at the bottom of the page.
OBiTalk will download the configuration changes to the OBi and reboot it.

QuoteAlso I see ITSP Profile A SIP and ITSP Profile B SIP, do both have to be provided with the IPs?
You only have to block scanners when you defined a SIP trunk for SP2. You don't have to do this for trunks defined as GV. GV uses the XMPP protocol. Define means you supplied a ProxyServer and an AuthUserName for a trunk.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: pbd3mon on June 04, 2015, 09:18:55 AM
Quote from: azrobert on June 04, 2015, 07:59:03 AM

Uncheck the box under OBiTalk Setting
Then uncheck the box under Device Default
Now change the value
Click Submit at the bottom of the page.
OBiTalk will download the configuration changes to the OBi and reboot it.

Ahh, what got me was that once I unchecked the OBiTalk Setting box it automatically checked the other box which made me think it was one or the other.  Thank you, I feel pretty silly  :-[


Quote from: azrobert on June 04, 2015, 07:59:03 AM
You only have to block scanners when you defined a SIP trunk for SP2. You don't have to do this for trunks defined as GV. GV uses the XMPP protocol. Define means you supplied a ProxyServer and an AuthUserName for a trunk.

Got it, thank you once again for the quick reply.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: infin8loop on June 16, 2015, 07:17:50 PM
I would suggest using option 2:
2. Change the (Voice Services)SPn Service->X_UserAgentPort ports for each SPn  to a number not in the 506x range. 

I was hit with a SIP scanner yesterday when the phone started ringing at 2am about every 4 minutes. The incoming number was 7 digits long but was changing.  I had blocks in place for 1 thru 6 digit numbers. I added a block for 7 digit numbers and the phone stopped ringing. However looking at the debug log I have running for the OBi I noticed the log file was unusually large.  Looking closer I noticed the SIP scanner had been beating the OBi to death for quite some time. Bogus INVITEs with incremented phone numbers that didn't ring the phone because they were less than 7 digits. It appears the OBi responded to the bogus INVITEs with one to many "SIP/2.0 503 Service Unavailable" messages. This was filling up the debug log. The incoming phone number wasn't a solid sequential increment but changing upward until it reached 7 digits and the phone rang.  I changed the X_UserAgentPort to outside the 506x range and that stopped the bogus traffic.  In this case port 5061 was the target on SP2 of an OBi110.  The point I'd like to make is, that if they find your open port they might just keep beating on it like they did mine. You won't know it unless the phone rings, but it's a lot of unnecessary traffic.  Just change the port to something that probably won't be scanned/found in the first place.  I updated my IPKall and Callcentric SIP URL forwards to the new port. I also added an email alert on the debug log that will notify me if it sees more than five "SIP/2.0 503 Service Unavailable" messages in an hour.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Mango on June 16, 2015, 07:21:13 PM
Better yet, place your device behind a firewall.

There have been reports - very few, but not nonexistant - of scanners finding and attempting to exploit VoIP equipment with port numbers above 6000.  If your VoIP equipment is behind a restricted cone NAT firewall, the firewall will only allow traffic from your service provider to reach your equipment.  For everyone else, there will not be any indication that VoIP hardware even exists.

My favourite firewall is a Tomato router.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: infin8loop on June 16, 2015, 07:59:52 PM
Quote from: Mango on June 16, 2015, 07:21:13 PM
Better yet, place your device behind a firewall.

There have been reports - very few, but not nonexistant - of scanners finding and attempting to exploit VoIP equipment with port numbers above 6000.  If your VoIP equipment is behind a restricted cone NAT firewall, the firewall will only allow traffic from your service provider to reach your equipment.  For everyone else, there will not be any indication that VoIP hardware even exists.

No doubt excellent advice, but a lot of folks (including me ;)) probably have no idea what that means and are too lazy (including me) to Google it.  I think my port is exposed by a stun server (yeah, go ahead, beat me down for that) since the OBi is behind a router (not expensive) that serves as a firewall of sorts and there are no port forwards setup in the router. The OBi is not registered to either IPKall (not allowed) nor Callcentric (don't want to). I guess I could go figure out the IP addresses for IPKall and Callcentric and put them in the X_AccessList but I'm too lazy.  I'm so lazy I'm surprised I'm even typing this message.  Someone in another post suggested using ports in the 20000 to 65535? range.  I didn't go that extreme because it would have involved typing extra digits (you know that lazy thing).

Is someone going to commandeer my OBi and launch rockets or something? Or will my phone just ring again at 2am if someone finds my port? I have no virtual PBX and am too lazy to go figure that tech out as well.

<serious>But seriously, what are the risks of a hacker taking over the OBi if they find an open SIP port?</serious>

I always enjoy your informative posts and hope you see the hopefully humorous spirit I have while writing this.

I'm no network guru and if you can't tell already, this stuff ceased to be fun for me months ago.  ;D
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Mango on June 16, 2015, 08:04:25 PM
A STUN server does not introduce a security risk.  (But it does add an additional point of failure.)  Your router is a "full cone NAT" type.  This means that even though you didn't set up any port forwards, your router did automatically.  This is why the scanner traffic can reach your ATA.

You mentioned that you're not registered to some of your service providers, and that does make security more tricky - particularly since Callcentric has a great deal of IP addresses.

I think the worst case scenario is that someone figures out how to route calls via your Callcentric account.  As long as you don't keep a very high balance, I wouldn't expect a significant problem.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Ostracus on June 24, 2015, 01:55:22 AM
Quote from: infin8loop on June 16, 2015, 07:17:50 PM
I would suggest using option 2:
2. Change the (Voice Services)SPn Service->X_UserAgentPort ports for each SPn  to a number not in the 506x range. 

I was hit with a SIP scanner yesterday when the phone started ringing at 2am about every 4 minutes. The incoming number was 7 digits long but was changing.  I had blocks in place for 1 thru 6 digit numbers. I added a block for 7 digit numbers and the phone stopped ringing. However looking at the debug log I have running for the OBi I noticed the log file was unusually large.  Looking closer I noticed the SIP scanner had been beating the OBi to death for quite some time. Bogus INVITEs with incremented phone numbers that didn't ring the phone because they were less than 7 digits. It appears the OBi responded to the bogus INVITEs with one to many "SIP/2.0 503 Service Unavailable" messages. This was filling up the debug log. The incoming phone number wasn't a solid sequential increment but changing upward until it reached 7 digits and the phone rang.  I changed the X_UserAgentPort to outside the 506x range and that stopped the bogus traffic.  In this case port 5061 was the target on SP2 of an OBi110.  The point I'd like to make is, that if they find your open port they might just keep beating on it like they did mine. You won't know it unless the phone rings, but it's a lot of unnecessary traffic.  Just change the port to something that probably won't be scanned/found in the first place.  I updated my IPKall and Callcentric SIP URL forwards to the new port. I also added an email alert on the debug log that will notify me if it sees more than five "SIP/2.0 503 Service Unavailable" messages in an hour.

IPv6 can't get here soon enough. Yes, that's security through obscurity. Next up, port knocking.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Mango on June 24, 2015, 05:57:41 AM
Why not use security through firewall, which is available today?
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: curt00 on November 12, 2015, 04:35:56 PM
Quote from: Shale on March 11, 2013, 08:57:16 AM

OBi202  with one trusted caller with service 2 being routed to phone line 2; (Voice Services)SP2 Service->X_InboundCallRoute:
{(x.6065556789):aa},{ph2}  [before]

These are both tested to work:
{(x.6065556789):aa},{>17771234567:ph2}  [ Tested and works]
{(x.6065556789):aa},{>('17771234567'):ph2}  [Permits alphanumerics]
[The single quotes are not needed if the ID is all numbers, but will not hurt]


I have OBi202, but I do not have:

{(x.6065556789):aa},{ph2}

I have:

{('curt00'):aa},{ph1}

I changed it to:

{('curt00'):aa},{>12221234567:ph1}

where 12221234567 is my AuthUserName.  Did I do it right?

Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: ianobi on November 13, 2015, 12:49:19 AM
QuoteI changed it to:

{('curt00'):aa},{>12221234567:ph1}

where 12221234567 is my AuthUserName.  Did I do it right?

Looks good to me.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: unmesh on May 11, 2016, 07:04:23 PM
Quote from: Mango on June 16, 2015, 07:21:13 PM
Better yet, place your device behind a firewall.

There have been reports - very few, but not nonexistant - of scanners finding and attempting to exploit VoIP equipment with port numbers above 6000.  If your VoIP equipment is behind a restricted cone NAT firewall, the firewall will only allow traffic from your service provider to reach your equipment.  For everyone else, there will not be any indication that VoIP hardware even exists.

My favourite firewall is a Tomato router.
I switched to a Tomato router because the other fixes were not working. The phone still rings at midnight  >:(

I have GV configured on SP1 and nothing on SP2 on a Obi110 with the latest firmware. Any suggestions?
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Mango on May 11, 2016, 07:09:41 PM
Google Voice is not vulnerable to this type of attack.

Please check Voice Services >> SP2 Service >> Enable and verify it is unchecked.

If it is already that way, or if that does not solve your problem, then your ringing is caused by something that is not a SIP scanner.

Does your ATA have a static IP address?  If not you might want to set one up.  I seem to recall a similar situation that caused the phone to ring when the ATA renewed its IP.

I assume you've checked your call history and found nothing?  If there is something around the time of the calls, please post details.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: unmesh on May 11, 2016, 08:04:53 PM
Quote from: Mango on May 11, 2016, 07:09:41 PM
Google Voice is not vulnerable to this type of attack.

Please check Voice Services >> SP2 Service >> Enable and verify it is unchecked.

If it is already that way, or if that does not solve your problem, then your ringing is caused by something that is not a SIP scanner.

Does your ATA have a static IP address?  If not you might want to set one up.  I seem to recall a similar situation that caused the phone to ring when the ATA renewed its IP.

I assume you've checked your call history and found nothing?  If there is something around the time of the calls, please post details.
Enable is unchecked and there is nothing in the call history. DHCP is set to issue 1440 minute leases and the Obi is renewing at about 7pm.

Let me try a static IP address tonight.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: unmesh on May 12, 2016, 07:07:26 PM
Unfortunately, setting up a static IP address did not fix the problem.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Mango on May 12, 2016, 07:30:09 PM
In that case I suggest you make a new thread.  You may get more exposure that way, since this problem is not related to SIP scanners.

I suggest you state what appears on your Caller ID and what happens if you answer the phone.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: PennyPincher on August 29, 2016, 10:16:55 AM
Hi All,

I am a newbie to this SIP scanner issue. I setup Obihai 202 with 1 phone line using freephoneline.ca. This setup worked perfectly fine for almost 6 months. 2 weeks ago I changed my router from motorola to a "Hitron" due to a upgraded internet service. Since then I have started receiving calls from 1001 and 3001.

So I went into the forum and started researching and came across this thread.

1. Based on the information I have Unchecked SP2, SP3 & SP4. Does this need to be done for ObiTalk too?
2. My X_UserAgentPort is 5080
3. My X_InboundCallRoute shows as {ph1}. Here I see suggestions to modify this to something "XXXX"|aa,some phone number...I am getting thoroughly confused here. Can someone guide me?

Best Regards

PP
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: Mango on August 29, 2016, 10:24:02 AM
1) OBiTALK can stay active.
2) Change your X_UserAgentPort to a random number between 20000 and 65535, such as 31688.
3) Follow step 3 from the first post in this thread: http://forum.fongo.com/viewtopic.php?f=15&t=16090

as an alternate to 3) you can use X_AcceptSipFromRegistrarOnly if you have a newer firmware version.

When you are done, test to be sure legitimate incoming calls still arrive.  This should block the scanning calls.
Title: Re: HOWTO: Thwarting SIP Scanners during Set-up
Post by: PennyPincher on August 29, 2016, 11:46:34 AM
Quote from: Mango on August 29, 2016, 10:24:02 AM
1) OBiTALK can stay active.
2) Change your X_UserAgentPort to a random number between 20000 and 65535, such as 31688.
3) Follow step 3 from the first post in this thread: http://forum.fongo.com/viewtopic.php?f=15&t=16090

as an alternate to 3) you can use X_AcceptSipFromRegistrarOnly if you have a newer firmware version.

When you are done, test to be sure legitimate incoming calls still arrive.  This should block the scanning calls.

Hi Mango,

Effected the changes, and phone is still working. Now to wait and see if the scanning still happens. Thank you so much for your help.

+1 to you.

Regards

PP