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:
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.
Navigation
[0] Message Index
[#] Next page