News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Please allow IP range in X_Access List to stop SIP Scanners

Started by flex25, June 28, 2012, 04:19:53 PM

Previous topic - Next topic

flex25

Please allow Service Providers->ITSP Profile A/B->SIP->X_AccessList to accept a range of IP addresses, not only individual IP addresses separated by commas.  I use Callcentric as SP1, and their range of IP addresses is 204.11.192.0/22 or 204.11.192.0 - 204.11.195.255.  To enter that large range as individual IP addresses in Service Providers->ITSP Profile A/B->SIP->X_AccessList would require hundreds of individual entries, separated by commas.

I have already received two SIP scanner attack attempts over SP1, which didn't come through my provider, but came through the Obi box, and I've had it less than one month.  I posed on the forum about it here http://www.obitalk.com/forum/index.php?topic=3410.0
and here http://www.obitalk.com/forum/index.php?topic=823.msg23566#msg23566

If Obi would allow the range format such as 204.11.192.0/22 to be entered in Service Providers->ITSP Profile A/B->SIP->X_AccessList this would stop the SIP scanner attacks to my Obi, and would greatly enhance security.

Thank you.

lacibaci

+1 to this request. This would indeed make OBi much more secure.

MB..

+1 - just posted without seeing this request.

A better feature would be to reject SIP connections from anywhere other than the registration server(s) with which the device is currently registered. (c.f. SPA2102)




JoeSchmoe007

+1 for OP suggestion (enable IP range) and for MB suggestion (allow only registered server)

rsriram22

+1

i have not had this problem, but looking at OP and few other threads on this issue, I d say add this feature in the next firmware release itself. security must be paramount!
have two 100s and one 110

flex25

Obi? Will you respond?  This will be a security enhancement for Obi users, and will elimate a great deal of annoyance.  Thank you.

adamb2k12

There is a similar topic here:

http://www.obitalk.com/forum/index.php?topic=4159.0

I guess there is a difference between wanting to block certain IP's and wanting to block ALL of them, but essentially I think everyone from both threads wants the same thing.  It would be much easier to just have an option like the Grandstreams to reject anything not coming from the SIP proxy configured.  So I guess it would have to do a reverse DNS lookup for each incoming call and then handle it accordingly.

OBiSupport

Please see the OBi Admin Guide (p. 94) for details on the parameter called "X_AccessList".

X_AccessList
A comma separated list of IP addresses such that the device only accepts SIP requests coming from one of the given addresses. If the list is empty, the device accepts SIP requests from any IP address

This is found in the ITSP SIP Settings area of the configuration.

lhm.

Ok, X_AccessList 67.222.131.147 (sipsorcery.com) is from where I receive my inbound calls.

Problem solved ?

lacibaci

Quote from: lhm. on January 11, 2013, 07:29:36 PM
Ok, X_AccessList 67.222.131.147 (sipsorcery.com) is from where I receive my inbound calls.

Problem solved ?

Problem solved maybe for you. Larger providers use many servers so this approach is not feasible. Callcentric has a couple of hundred:

204.11.192.0/24 (as in 204.11.192.0 - 204.11.192.255)
66.193.176.0/24 (as in 66.193.176.0 - 66.193.176.255)

Lac

Shale

+1

I had another idea. Suppose you could get the outbound packets to start with a shorter time to live (TTL). This would limit how many hops the packets would survive. Now I see problems, but I was thinking that many SIP scanners would be on longer routes than your legitimate server.

The TTL idea is probably flawed. The original suggestion on this thread  to list subnets would be quite sufficient, unless the list of subnets was too big. I wonder how big the list of subnets used for GV is.

OBiTalk could pre-populate X_AccessList for the providers that it specifically knows about.


adit

+1. I just was hit by the dreadful SIP scanners , next day after setting my OBI. My provider does not provide it's IP range but you can find what the company has allocated :  http://whois.arin.net/rest/net/NET-208-65-240-0-1

So:

NetRange 208.65.240.0 - 208.65.247.255
CIDR 208.65.240.0/21

I would like to be able to enter this on my OBI. I want to allow ONLY my provider address range. This will block any SIP scanner. I'm sure that my provider does not use the all range but I did not get from the what actually is used so setting the full range should be the best. I'm sure more and more will be hit with this and allowing only a range of IP is an easy fix.

HDFLucky

Quote from: OBiSupport on January 11, 2013, 04:38:16 PM
Please see the OBi Admin Guide (p. 94) for details on the parameter called ”X_AccessList”.

X_AccessList
A comma separated list of IP addresses such that the device only accepts SIP requests coming from one of the given addresses. If the list is empty, the device accepts SIP requests from any IP address

This is found in the ITSP SIP Settings area of the configuration.

Reviving this thread, because it's even more relevant now than when first posted.
The OBi response completely misses the point. I think everyone here is aware of and agrees with the value of X_AccessList. However, it only allows full decimal notation of individual ip addresses. My provider has the range 208.64.8.0 - 208.64.11.255. That's 1024 addresses! If CIDR notation were allowed, it would only require a single entry of 208.64.8.0/22 for the entire range of addresses.

gderf

A more effective and easier method to foil SIP scanners is to use the "Oleg" method or enable X_EnforceRequestUserID. Search the forum.
Help me OBiHai PhoneOBi. You're my only hope.

cluckercreek


HDFLucky

Quote from: gderf on May 26, 2014, 10:46:55 AM
A more effective and easier method to foil SIP scanners is to use the "Oleg" method or enable X_EnforceRequestUserID. Search the forum.

I don't know that a single entry in X_EnforceRequestUserID is any easier than a single entry in X_AccessList, but I do agree that oleg's method seems like the better way to go. Thanks.