HOWTO: Thwarting SIP Scanners during Set-up

[Shale]

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

[Rick]

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.

[ianobi]

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

[Shale]

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"

[ianobi]

Looks good now 

Let's see if others can add any more useful info to this subject.

[Mango]

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

[Mango]

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 

m.

[Shale]

Thanks. I have made fixes and additions per your suggestions.

[QBZappy]

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/

[Felix]

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 

[Mango]

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.

[claude]

{>(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)}

[ianobi]

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)}

[Shale]

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.

[Felix]

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

[Ostracus]

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 

Maybe Obihai would include it in their production digitmaps? Or at least the portal.

[MattG]

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

[Agent88]

2. 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?

[QBZappy]

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

[zapattack]

http://www.obitalk.com/forum/index.php?topic=5467.0
Reply #6 from Mango
is the short answer.