HOWTO: Thwarting SIP Scanners during Set-up

[azrobert]

    >('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.

[InsanitySix]

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.

[Mango]

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}

[Taoman]

{(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.

[Mango]

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. 

[drgeoff]

According to page 193 of said document the ':' must NOT be omitted.

rule := peering-list : terminal-list
.
.
Terminal-list can be empty, which means to block this call. The preceding ':' cannot be omitted.

[oldunixguy]

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

[Mango]

This is not required for Google Voice as it does not use SIP.  You can leave the X_InboundCallRoute at its default.

[lhm.]

Or this: {>('1XXXXXXXXXX'):ph}

Edit: Not sure it actually protects, but does allow in an out bound calls from AA thru GV.

[Jax69]

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.

[Mango]

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.

[Jax69]

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.

[Veronica]

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.

[Mango]

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.

[Veronica]

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.

[N2VWZ]

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

Code Select Expand

174.34.146.162,173.208.83.50,174.137.63.206,174.142.75.171,174.34.146.162,198.144.158.125,199.21.149.36,209.62.1.2,5.77.36.136,64.120.22.242,67.205.74.164,67.205.74.184,67.205.74.187,67.215.241.250,68.233.226.97,69.147.236.82,74.54.54.178,74.63.41.218,78.129.153.20


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.

[oldunixguy]

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

[WelshPaul]

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.

[oldunixguy]

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

[WelshPaul]

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