HOWTO: Thwarting SIP Scanners during Set-up
N2VWZ:
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
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
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:
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.
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:
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'.
Navigation
[0] Message Index
[#] Next page
[*] Previous page