Obi202 best practices for security settings

[tns1]

I have an Obi202/Anveo setup, which I am just starting to use as a POTS line replacement. I am looking to tweak what settings I can to make it as secure as is reasonable without inadvertently blocking legitimate calls. 

After reading the SIP scanner thread http://www.obitalk.com/forum/index.php?topic=5467.0
I think I'll be disabling my unused SPn services along with using the Oleg4 method:

Change X_InboundCallRoute from {ph1} to {>('Insert your AuthUserName here'):ph1}

Are there any downsides to doing this?

I also saw somewhere on a configuration page (can't find it now), that there is a setting to prevent connections that sustain per-minute rates above some threshold or maybe exceeding some total time or total cost. I don't plan on making calls to Albonia, but maybe this helps prevent rate charge scams, or fumble finger mistakes. 
Any comments on the advisability or usefulness of these settings?   

Are there any other best practices (other than good passwords) that people use?

[202Owner]

>>I think I'll be disabling my unused SPn services along with using the Oleg4 method:
Change X_InboundCallRoute from {ph1} to {>('Insert your AuthUserName here'):ph1}
Are there any downsides to doing this?

Not that I am aware of.  That method was temporarily broken in firmware Builds 4303 and 4318.  And I believe it is superseded by this setting, if supported by your ITSP i.e. it registers:
SPn Service - SIP Credentials::X_EnforceRequestUserID = checked ;prohibit anonymous SIP.

>>I also saw somewhere on a configuration page (can't find it now), that there is a setting to prevent connections that sustain per-minute rates above some threshold or maybe exceeding some total time or total cost.

I would set prudent ITSP account settings, where possible, such as limit/block International destinations and set International rate thresholds.  Also set any max call time limits.

>>Are there any other best practices (other than good passwords) that people use?

I use 12 character SIP passwords that look like this:  5o&[nTm%3$27.  And vary them across mobile softphones.

If you are using OBi2 Series v3.0.1 Build 4367 or earlier and Google Voice, use 2-Step Authentication with an app-specific password to configure the Google Voice service on your OBi.

Fund your account modestly without auto-pay.   If available, subscribe to an account balance e-mail alert and other e-mail alerts for key account setting changes.

I don't use OBiTALK Provisioning or OBiTALK Service... the OBiTALK Cloud is a point of vulnerability for both Obihai and its customers; and no device is secure if it's being updated unattended, unannounced, undocumented, untested, and unapproved:
Auto Provisioning - Auto Firmware Update::Method = Disabled ;prohibit remote access.
Auto Provisioning - ITSP Provisioning::Method = Disabled ;prohibit remote access.
Auto Provisioning - OBiTalk Provisioning::Method = Disabled ;prohibit remote access.

And:
OBiTALK Service - OBiTALK Service Settings::Enable = NOT checked ;prohibit remote access.

Disable OBi Voice Services you are not using.

Move the UserAgentPort to obscure it from scanning (should not be a problem behind a good firewall):
SPn Service - SP1 Service::X_UserAgentPort = 6xxxn

Visit Steve Gibson's reputable site https://www.grc.com, find the Shields Up! page, and scan all of your service ports to see if you are exposing any resources.

Backup your OBi configuration to file; no options.

Place your OBi downstream from your site router/firewall.  I would not use the OBi202 router for an Internet firewall.

Unrelated, but may be worth doing...

Change OBi WAN/Internet port from default (2) 10Mbs half-duplex to (1) 100Mbs full-duplex (undocumented?):

Dial *** for Device Configuration Menu
Dial 0 for option
Dial 27# for current value
Dial 1 to set a new value
Dial 1# for new value 100Mbs full-duplex
Dial 1 to confirm/save
Hang up to reboot automatically

[tns1]

Not that I am aware of.  That method was temporarily broken in firmware Builds 4303 and 4318.  And I believe it is superseded by this setting, if supported by your ITSP i.e. it registers:
SPn Service - SIP Credentials::X_EnforceRequestUserID = checked ;prohibit anonymous SIP.

On my 202, this checkbox is checked, presumably by the Anveo provisioning (via Obitalk). Is this sufficient to say that Anveo supports this method?  Is there an easy way to test this blocking, i.e. is there a scan service similar to the 'Shields Up!' that will attempt an anonymous SIP call?

[202Owner]

Not that I am aware of.  That method was temporarily broken in firmware Builds 4303 and 4318.  And I believe it is superseded by this setting, if supported by your ITSP i.e. it registers:
SPn Service - SIP Credentials::X_EnforceRequestUserID = checked ;prohibit anonymous SIP.

On my 202, this checkbox is checked, presumably by the Anveo provisioning (via Obitalk). Is this sufficient to say that Anveo supports this method?  Is there an easy way to test this blocking, i.e. is there a scan service similar to the 'Shields Up!' that will attempt an anonymous SIP call?

If your OBi is set to enforce X_EnforceRequestUserID and it still works with your Anveo SIP account, then you could reason that Anveo supports this method, yes?

For me, the test is in using it... if no unsolicited SIP calls, then it works.

Are you the one who did not want to make your OBi a hobby?

[Mango]

Visit Steve Gibson's reputable site https://www.grc.com, find the Shields Up! page, and scan all of your service ports to see if you are exposing any resources.

202Owner has made some excellent suggestions.  One thing I wanted to mention about Shields Up is that it only scans TCP ports.  So, it will not detect unprotected VoIP equipment that uses UDP.  http://sipscanner.voicefraud.com/ will, if you're interested.

Are there any other best practices (other than good passwords) that people use?

Use a restricted cone NAT router, and do not use port forwarding or DMZ.  Restricted cone NAT will only permit inbound traffic from the service provider you're registered to - in your case Anveo.  If you have a full cone NAT router, it will allow traffic from any source.  This is probably not what you intend.

If you have a Windows computer, you can test your router using the utility here: http://www.dslreports.com/forum/remark,22292023 .  To run it, use stun stun.ekiga.net from a command prompt.

[tns1]

Thanks for the info,

Are you the one who did not want to make your OBi a hobby?

Just wanted to be sure the constant tinkering was an option, not a requirement. Technically I am still in the installation phase, so it isn't a hobby yet.

I did implement most of the suggestions/tests. Even though I am part of the crowd that believes "the Cloud is evil", I am going to trust the Obitalk portal for the time being.

Shields up! shows no exposed ports.
http://sipscanner.voicefraud.com/ found no security holes.

The stun utility did not work for me, "requested address not valid in context", but I do have intentional double NAT (stacked routers for client isolation), with the Obi behind the 2nd router. I could always move it to the 1st router if I thought it was a problem, but I am getting MOS scores >4.0, and >25Mbps throughput.