Securing SIP access

[Eugene]

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!

[Vodia PBX]

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.

[Eugene]

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!

[Steve B]

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!

 

Go here and set the password length to 12 or higher and include punctuation. An example produced would be 644eYaneCa$r which would take a PC about 5 million years to decode per this site.

[global_s]

Just to understand better.

 

By setting in the Access section the ip I allow SIP connection from, have I secured my PBX from the issue as the original poster?

 

I need to have a trunk with no proxy address (because I didn't find anything on the KB that would allow me to set more than an ip address per trunk) and I restrict the traffic only from few ip.

 

Shouldn't this be enough?

[Vodia PBX]

For extensions, you can define from what IP the extension may register from. I would not consider that a strong security feature, though it definitevely helps. Disadvantages: (1) Still all traffic visible (2) IP addresses can also be spoofed, potentially at the risk of having an IP address in the LAN (3) Inflexible, DHCP might be your enemy.

 

For trunks and in the real world, yes IP addresses do matter. There is a field called "Explicitly list addresses for inbound traffic" where you can enter a list (seperated by space) which IP address traffic is considered to come from this trunk. If you leave the field empty, the PBX tries to figure out by DNS resolution of the outbound proxy field which addresses are candidates. But if you can, you should make this explicit. The input field also accepts DNS names and also port numbers if you have them, but the DNS resolution does only A and AAAA (no SRV or NAPTR).

[global_s]

For trunks and in the real world, yes IP addresses do matter. There is a field called "Explicitly list addresses for inbound traffic" where you can enter a list (seperated by space) which IP address traffic is considered to come from this trunk. If you leave the field empty, the PBX tries to figure out by DNS resolution of the outbound proxy field which addresses are candidates. But if you can, you should make this explicit. The input field also accepts DNS names and also port numbers if you have them, but the DNS resolution does only A and AAAA (no SRV or NAPTR).

 

I'm not getting your answer fully. Maybe I need to give more details to understand why and how to implement the security.

 

I bought my number from a provider who is sending calls directly to SIP identity in the form "extension@ip_snomone"

I setup Access List in System settings to only allow connection from a set of ip addresses and then blocking all the others

I created a trunk (SIP gateway, only inbound) where no domain nor proxy address is set. If I try to add data to these field the calls fail

 

Why do I have to inserti the ip address of the provider in the field "Explicitly list addresses for inbound traffic" ? Shouldn't the Access list take of of that?

The provider is using different ip for signaling and RTP communications. Which ip should I put ? both? only signaling? does this field allow entire subnets to be added?

 

Looking forward to your reply

[Vodia PBX]

I bought my number from a provider who is sending calls directly to SIP identity in the form "extension@ip_snomone"

I setup Access List in System settings to only allow connection from a set of ip addresses and then blocking all the others

I created a trunk (SIP gateway, only inbound) where no domain nor proxy address is set. If I try to add data to these field the calls fail

 

Okay, we are talking about trunks here, so you can forget about settings in the extension. The access list on system level is not related to either trunks or extensions, it is really for all traffic on the system. It is a good idea to blacklist anything if you dont have to deal with registrations from users on airports, home office, etc. Then of course you have to make sure that your SIP trunk provider can still send you traffic.

 

Why do I have to inserti the ip address of the provider in the field "Explicitly list addresses for inbound traffic" ? Shouldn't the Access list take of of that?

The provider is using different ip for signaling and RTP communications. Which ip should I put ? both? only signaling? does this field allow entire subnets to be added?

 

The access list and the trunk settings are really two different layers in the system, you have to take care about them both, seperately. The word "Explicitly" implies that there is also a implicit way of doing that, which is specifying the outbound proxy on the trunk. In many cases, this is kind of unpredictable and even instable, that's why we (after years) introduced the explicit field where we give you control over what exact addresses you expect traffic from the service provider.

 

This setting only affects SIP. RTP is not related to that at all, and you dont have to worry about RTP. RTP is even not part of the access list mechanism.

[global_s]

RTP is even not part of the access list mechanism.

 

Thanks for the explanation; I still have one question about the Access list mechanism though.

 

What do you mean by the quoted sentence?

Aren't RTP packets, simple UDP packets sent from/to the PBX? Shouldm't they obey Access List rule after all?

More on the access list, have you benchmark it against a common set of attacks? I would like to understand if it's better to use iptables for the access list, rather than the pbx feature.

[Vodia PBX]

Aren't RTP packets, simple UDP packets sent from/to the PBX? Shouldm't they obey Access List rule after all?

 

Yes, in principle you are right. However, running every RTP packet through the rule would be a huge CPU effort, that's why this subsystem is seperate.

 

More on the access list, have you benchmark it against a common set of attacks? I would like to understand if it's better to use iptables for the access list, rather than the pbx feature.

 

Of course iptables is faster; however because we support multiple platforms including Windows thats not really an option for us. Also the PBX operates on "application layer" that means it automatically detects suspicious traffic, which you can only do in the PBX itself, especially when TLS is being used (which rules out solutions that monitor the traffic on the interface layer). One weak point is that the PBX accepts TCP connections even if they are coming from blacklisted locations, just to shut them down right after that. In theory that could be a way to attack the PBX; however this would be only for destructive purposes, not for getting access to the system. In Windows you can actually run a function that checks for the IP address before accepting the connection, however because of the platform independence we did not use this feature.