[Securing SIP access]

Whow, that is clearly a "warning shot" and you have to so something.

 

If you are using SIP trunks, make sure that you either use an outbound proxy or explicitly specify the IP addresses where you expect traffic from. If you dont do that, the PBX assumes that traffic from unregistered sources are coming to that trunk (search for SIP ENUM if you want to find out more). It can be a feature and usually you can call only internal extensions, no outbound dialling; but if you dont want that, you definitevely want to shut this down. When you have set up the trunk without outbound proxy, you should have seen a warning about this.

 

Also, make sure that you use "good" passwords. Some people turn the password policy to "off", and then it is possible to use trivial passwords: Then you are really in trouble, because then outsiders are really very close to make some "free" international calls, paid by you. In the web interface, then you will see warning signs next to the accounts that have trivial passwords.

 

If you are provisioning phones, you should also consider setting a good password in the domain for the plug and play. And of course, you should have set a good password for the administrator.

 

Most of the problems come because people choose trivial passwords: 1234, computer, password.

 

Thank you very much! I must have glanced over the warning for the proxy so my mistake, have added that in now and will do some tests to make sure it still works. That must have been it as there weren't any registrations against any extensions while the calls were taking place. I will reset passwords again but I believe they're all strong, rather safe...

 

Thanks again!

[Securing SIP access]

Hi there, I'd like to ask for some advice on securing access to a Snom One installation - basically I noticed my phone (just have one phone configured on it) ring late at night and started investigating. I've now had two incidents where somehow someone on the net was able to ring my phone and clearly they were running through different dialling patterns to see which ones worked. After the first incident I changed the firewall rules to only allow traffic from a couple IPs that are mine of those of customers but someone was able to do it again after that. I may have done something wrong in the firewall, not sure.

 

What I really don't understand is that on both occasions they didn't have a SIP registration on an extension (or "account") so they must have been dialling in some other route and routing from there?

 

Any advice would be appreciated! I guess ideally I'd like to be able to register on an extension from a dynamic IP, say from my iPad or phone with a SIP client but I'm confused now as to how to secure the phone system.

 

Thanks!

[500 Internal Server Error - lower CSeq on every new registration]

Yes you must have had a version where we had that bug... http://wiki.snomone.com/index.php?title=Coma_Berenicids is the latest.

 

Thanks, glad to hear it's not my fault

[500 Internal Server Error - lower CSeq on every new registration]

I've just upgraded to the latest version and it seems it's keeping the registration now, should have started there I guess! Hope it stays this way. Thanks!

[500 Internal Server Error - lower CSeq on every new registration]

Hi there, I've been struggling with adding a SIP trunk to a different branch using a different PBX, it authenticates successfully the first time and then after some time fails with "500 Internal Server Error", I have contacted support for the other office's PBX and here is their response. Would appreciate any help with this!

 

"The registration produces those "500 Internal Server Error" errors because the CSeq of every new registration session is lower than that stored on last successful registration. The equipment which tries to register sends lower CSeq on every new registration, please check why it is doing so and if there is some configuration to change this behavior.

 

The cite from RFC.

 

RFC 3261

10.3. Processing REGISTER Requests

...

When receiving a REGISTER request, a registrar follows these steps:

...

6.

... the registrar checks whether

the Call-ID agrees with the value stored for each binding. If

not, it MUST remove the binding. If it does agree, it MUST

remove the binding only if the CSeq in the request is higher

than the value stored for that binding. Otherwise, the update

MUST be aborted and the request fails."

 

So is there a setting on the Trunk page that could fix this? Thank you very much!