HOWTO: Thwarting SIP Scanners during Set-up

[giqcass]

Using the Oleg method you can still use Ip dialing just fine as long as the oncoming sip uri includes your auth name.  You can also define multiple auth names with the Oleg method which is great because you can send them to different paths as well if you like.
{} is only needed in the more complex call routes. It simplest to just put them in all the time to eliminate errors.

[absteeve]

Hi.  New here.  It is 4:57am as I begin writing this... been up since 4am... sure you can figure out why

First, I'm unclear on a lot of all this but THANK YOU for the solution.  I keyed in quickly that Oleg's method is preferred.  I inputted that (while under attack), hit reboot... problem solved.  So that's fine, except:

1) I don't understand WHY it works or WHAT it does, so I'm not all that confident that I didn't just block everyone from calling me.
2) I don't understand why my PROVIDER isn't solving this issue.  I use Callcentric, which seems to me to be a large, reputable, and experienced provider.  Why are they using default ports and allowing such attacks to their customers?
3) I'm also trying to figure out if the reason for these attacks suddenly hitting me is because a) I switched from voip.ms to Callcentric or b) I switched from a PAP2T to a OBi100 or c) I switched from being behind a router to being in front of it.

Some more information on #3:
- I switched to Callcentric because they could port my home # and voip.ms couldn't.  I was happy at first because the call quality seemed immediately better.  HOWEVER, I've been battling frequent problems of calls disconnecting @ 5 minutes and/or one-way audio (always on incoming calls).
- Due to those problems, Callcentric suggested the problem was with my PAP2T device, so I got an OBi100.  The OBi was never used on voip.ms.  That's why I don't know which is causing this SIP attack issue (that I never had in YEARS with voip.ms/PAP2T).
- When switching to the OBi didn't help (dropped calls/one-way audio) they suggested it was probably my router, so I plugged it directly to the modem's 2nd port (mine has 2 available ports each getting its own WAN IP).  That actually appeared to resolve the problem because immediately from the very first test call after that switch for the next 48 hours... not a single dropped call or one-way audio issue.  However, after that (with no changes at all), back to frequent drops and one-way audio on incoming.

And, of course, now as of 4am... annoying bloody calls from these sip scanner attacks.

So now its 5:05am... still no calls since implementing the Oleg fix.  I'm going back to bed for the next 45 minutes or so before my 2yr old wakes up (sigh).  Hopefully in the morning you guys will have me comforted that Oleg's method isn't blocking wanted calls and maybe, just maybe, someone can give me some tips on my other problems (though I realize that's off topic)

[sdb-]

3.c.

If done correctly it should let your provider contact your OBi, thus allowing calls as normal.

Prior to 3.c. the router was blocking incoming connection attempts.  Now your OBi does not have that protection and is fully exposed to the Internet.  Those scans/attempts come directly to your OBi without passing thru Callcentric or your router.

You could try putting the OBi back behind the router and turning off anything SIP related in your router.  Anything else you do (DMZ or portforward to the OBi) will have the same effect as bypassing the router.

[absteeve]

OK, thanks.  For now I'll keep it exposed.  I want to eliminate variables while we (Callcentric and I) attempt to fix the call drop-outs and one-way audio issues.  It seems the router isn't the problem, of course, but until its fixed I don't want to introduce it back into the mix.  But at least now I know why the sudden barrage of calls this morning!

[Ostracus]

Hmmm, audience. Think a little syslogging will help?

[absteeve]

Yeah, that!  How?

[Shale]

absteeve wrote:
>1) I don't understand WHY it works or WHAT it does, so I'm not all
>that confident that I didn't just block everyone from calling me.

The SIP provider puts your account number in its packet. The malefactor won't know that number to put it in.

>
>2) I don't understand why my PROVIDER isn't solving this issue.  I
>use Callcentric, which seems to me to be a large, reputable, and
>experienced provider.  Why are they using default ports and
>allowing such attacks to their customers?

Your provider is totally not involved. The request came directly to you without involving your provider.
>
>3) I'm also trying to figure out if the reason for these attacks
>suddenly hitting me is because a) I switched from voip.ms to
>Callcentric or b) I switched from a PAP2T to a OBi100 or c) I
>switched from being behind a router to being in front of it.

Yes, probably 1c.. However not all routers would have saved you. If your router opens the port, you will still get that 4am wakeup. Most of us that got bit were behind routers.

Another possibility is that the SIP scanner had not found you yet.

[sdb-]

>c) I switched from being behind a router to being in front of it.

Yes, probably 1c.. However not all routers would have saved you. If your router opens the port, you will still get that 4am wakeup. Most of us that got bit were behind routers.

Most routers should not "open" the port, but rather allow thru responses matching the expected session (or flow).

Every IP packet has a source address and source port, and a destination address and destination port. The firewall in "allow outgoing" establishes an expected session from the source address and port to the destination address and port and will allow a response which has both tuples in the opposite locations.

In other words, if my OBi at 172.31.0.8:22334 tries to talk thru my firewall to 1.2.3.4:5260 on the outside, only responses from 1.2.3.4 will be allowed in, and only if they come from port 5260 and are directed inward to port 22334.

If a port is forwarded, then it will be "open."  Otherwise if you have a router which just decides to "open" the port to any incoming traffic, it is broken.

[Shale]

Most routers should not "open" the port, but rather allow thru responses matching the expected session (or flow).

1. http://en.wikipedia.org/wiki/Network_address_translation#Methods_of_port_translation shows the various methods of translation.  People have to deal with what is their router does do rather than what it "should" do.

2. Some people put the OBi into the DMZ to get things working, and don't keep working beyond that. Some just pass through some ports, but that still leaves them open to SIP scanners.

3. New firmware, such as Tomato, can change the method of port translation for many routers.

4. The Oleg method saves you even if your router is in the DMZ.

5. OBi now incorporates the Oleg method when it does the setup for its list of SIP providers.

[sdb-]

Most routers should not "open" the port, but rather allow thru responses matching the expected session (or flow).

1. http://en.wikipedia.org/wiki/Network_address_translation#Methods_of_port_translation shows the various methods of translation.  People have to deal with what is their router does do rather than what it "should" do.

Yeah, but have you have proved to have one?  In that description, "full cone NAT" is the only one which does the behavior you described.

Further, that terminology of describing port translation is obsolete because it did not adequately describe what happens in the real world.

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.

and

Especially, most NAT translators combine symmetric NAT for outgoing connections with static port mapping, where incoming packets to the external address and port are redirected to a specific internal address and port.

Which is the normal behavior today and that static port mapping (either individually or via a "DMZ host") is only way I have ever seen intentional "full cone NAT" existing in the real world.

As for your #2, of course users can break things.

Your #3, see above.

The rest, yeah I agree.


By the way, I write router firmware for a living and have been implementing and designing network protocols since long before NAT was standardized.  I have not seen it all.  But I have worked with a lot of it.

[pointpeninsula]

Hello all, another newbie here.

I realize this thread is getting old, but as I'm just now transitioning from GV to Anveo, I've run into this problem. Many thanks to you all for the help, and with luck I'll get a good night's sleep without unplugging the phone.

I do have one question, though. I've implemented the #3 solution (X_InboundCallRoute method), and nowhere in the allowable syntax for digitmaps can I find a single '>' symbol used. Can anyone explain how that's used as a prefix to the AuthUserName?

Another comment: Nowhere in the manual, or online, have I seen the admonition that you can change these settings with the webserver built into the unit on the local IP address until your fingers fall off, but the variables will always revert to the default. The expert configuration must be done on the Obitalk web site. It seems odd that it should be the case, but Obihai's support folks told me that outright, and by experimentation, I've found it to be the case.

I emphasize this as a warning to other newbies as GV is turned off.

Thanks again,
Tom

[Mango]

I believe the InboundCallRoute syntax is described here: http://www.obihai.com/OBiDeviceAdminGuide#_Toc367543130

Specifically, the > character is used in a peering-list to denote a callee-list.

With regards to a post earlier in the thread: while the Oleg method may make your device perform properly if in DMZ, it will not fully protect your device like a properly-configured firewall would.  For example, your device could still be brute forced if it is in DMZ.

[Terry]

Another comment: Nowhere in the manual, or online, have I seen the admonition that you can change these settings with the webserver built into the unit on the local IP address until your fingers fall off, but the variables will always revert to the default. The expert configuration must be done on the Obitalk web site. It seems odd that it should be the case, but Obihai's support folks told me that outright, and by experimentation, I've found it to be the case.

If I understand what's going on with Obi's "preferred" providers and their special offers, they are controlling things via "provisioning"  to make sure that well-meaning customers don't change something inadvertently and cause them (customer and provider) frustrating and expensive service calls. The provisioning does seem to assert more control over settings than, say, GV used to have.

On that subject, if the setting Anveo (for example) "provisions" to my Obi is allowing the annoying sip scanners in, even though Anveo can't control what the scanners do, since they CAN and DO control the settings of my Obi through their provisioning, and since there is a simple and working way to reject the sip scanner calls, I think it is perfectly logical to blame Anveo for the sip scanner calls getting through, since it is THEIR setup that is leaking.

If they are going to have that much control over my device, they need to take more responsibility. And, hey, since the solution is simple and therefore inexpensive (or free) to implement, just set it up in the provisioning. No excuses.

[drgeoff]

Another comment: Nowhere in the manual, or online, have I seen the admonition that you can change these settings with the webserver built into the unit on the local IP address until your fingers fall off, but the variables will always revert to the default. The expert configuration must be done on the Obitalk web site. It seems odd that it should be the case, but Obihai's support folks told me that outright, and by experimentation, I've found it to be the case.

So you haven't noticed the fourth 'sticky' at http://www.obitalk.com/forum/index.php?board=1.0 with the title:  "Managing Your OBi Device Configuration: OBiTALK or OBi Web Page but NOT Both".

And the last 'sticky' at http://www.obitalk.com/forum/index.php?board=3.0 has the same title and is a link to the one above.

It is quite simple to make configuration changes using the OBi's built-in web pages and not have them reverted back by the OBiTALK portal.

[dconway]

I recently switched to PhonePower (with the whole Google Voice deprecation of XMPP) and am having trouble with back to back SIP scanner calls coming from "2001" on my callerID.  I want to use "Oleg's Method #4" from this thread but the AuthUserName is blank in ObiTalk portal (whereas for a service like Callcentric you have a clear ID typically beginning with 1777...).

Anyway, when I log into phonepower portal, there's an option to turn on SIP credentials but there's a massive disclaimer about risk (quoted below) and they will disable features like international dialing.

Does anyone know what value I need to subsitute for {ph}in X_InboundCallRoute to get "Oleg's Method #4" to work with PhonePower?  Thanks for this great thread and for any help you can provide.

SIP Credentials
Your SIP Credentials are currently not enabled. SIP Credentials are designed for advanced users. Customers with SIP Credentials enabled have a limit of 4 registrations and 2 total concurrent calls. Disabling your SIP Credentials will remove these restrictions.

By choosing to enable your SIP Credentials you understand that Phone Power will not offer any technical support for your hand-configured device(s). Phone Power will continue to offer normal support for all auto-provisioning devices, including Phone Power supplied phone adapters, softphones, zippyphones, BYOD devices that use Phone Power's auto provisioning system, etc. If you are unable to configure your device(s) yourself, please deactivate your SIP Credentials and contact support.

After enabling your SIP Credentials, you will need to reboot all devices connected to the Phone Power network. This includes rebooting Phone Power supplied adapters, softphones, zippyphones, BYOD devices that use Phone Power's auto provisioning system, etc.

[Taoman]

Does anyone know what value I need to subsitute for {ph}in X_InboundCallRoute to get "Oleg's Method #4" to work with PhonePower?  Thanks for this great thread and for any help you can provide.

You need to enable SIP credentials or you don't have SIP, do you? Are you saying you haven't enabled SIP credentials but you are registering and making and receiving calls? How would you know your SIP password?

Here is the string for X_InboundCallRoute: {>xxxxxxxxxx:ph}

where xxxxxxxxxx is your AuthUserName which is your Auth ID which is your PhonePower supplied phone number.

[dconway]

Problem is there is no ID to insert.
Luckily PhonePower responded to a support ticket I submitted and recommended following the instructions here.  Hopefully that helps
http://www.phonepower.com/wiki/Obihai_Lite#Disable_Direct_IP_Dialing

[TonyC]

I know this topic is old, but I just switched over to Future-Nine from GV and within 24 hours my OBI202 came under SIP attack (it is BEHIND my NetGear firewall).  I even went so far as to read my NetGear log files and block individual IP addresses but still the attacks continued....every 25 minutes like clockwork.  I followed the advice below and the insanity stopped immediately.  I used steps 0, 2, & 4. 

On step 4 I did not use (), just this >AuthUserName:ph where AuthUserName is supplied in SIP Credentials section on the same config page - just below the SP1 Service Group   

PEACE & quiet AGAIN !  Thank you Mango.

Tony 

My preference is a combination of the following:

Method 0) Disable any SP that you're not using.

Method 2) Change X_UserAgentPort on SPs configured for SIP to a number between 20000 and 65535.
This will reduce the number of SIP scans that reach your device.

Method 4) Change X_InboundCallRoute to {>('Insert your AuthUserName here'):ph}
If any scanners discover the port you're using, the device will reject the call unless it's destined for your AuthUserName.

I prefer not to filter based on Caller ID Number and Shale seems to agree with me.  It would be easy to spoof a legitimate-looking number.

Method 3) is effective but my VoIP service provider changes their IPs from time to time and they have so many I can't keep up.

[Look30]

Great !
Thanks TonyC and Mango.

I know this topic is old, but I just switched over to Future-Nine from GV and within 24 hours my OBI202 came under SIP attack (it is BEHIND my NetGear firewall).  I even went so far as to read my NetGear log files and block individual IP addresses but still the attacks continued....every 25 minutes like clockwork.  I followed the advice below and the insanity stopped immediately.  I used steps 0, 2, & 4. 

On step 4 I did not use (), just this >AuthUserName:ph where AuthUserName is supplied in SIP Credentials section on the same config page - just below the SP1 Service Group   

PEACE & quiet AGAIN !  Thank you Mango.

Tony 

My preference is a combination of the following:

Method 0) Disable any SP that you're not using.

Method 2) Change X_UserAgentPort on SPs configured for SIP to a number between 20000 and 65535.
This will reduce the number of SIP scans that reach your device.

Method 4) Change X_InboundCallRoute to {>('Insert your AuthUserName here'):ph}
If any scanners discover the port you're using, the device will reject the call unless it's destined for your AuthUserName.

I prefer not to filter based on Caller ID Number and Shale seems to agree with me.  It would be easy to spoof a legitimate-looking number.

Method 3) is effective but my VoIP service provider changes their IPs from time to time and they have so many I can't keep up.

[SSmith]

On step 4 I did not use (), just this >AuthUserName:ph where AuthUserName is supplied in SIP Credentials section on the same config page - just below the SP1 Service Group

FWIW, my AuthUserName is alpha-numeric and calls would be rejected unless I used the
     >('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.