Protecting SPA112/SPA122 from outside traffic

[gustavolsson]

Some of our retailers (ISP's in most cases) are experiencing huge issues with their customer's SPA112/SPA122's locking up due to malicious SIP traffic from outside. To mitigate these issues, the best solution for us would be the ability to put the whole SPA112/122 VoIP service in a separate VLAN, i.e. the unit tagged all of it's "own" traffic with a custom VLAN tag and provided regular service (bridge/nat) to the untagged WAN-traffic. I believe some Cisco IP-phone models permit this.

Some other options we've considered:

1. Change SIP source port from 5060 to something random

2. Enable TLS on the units

3. Set an ACL in the unit only allowing SIP traffic from our subnets (not possible with the SPA112/122 to the best of my understanding?)

...or some other good way, minimum effort and pain is of course preferable. Would enabling TLS would solve the issue? The customers having these issues are the ones who've connected their SPA directly to the internet, in most cases using it as a router/bridge, the solution need to take that into account, placing the whole customer connection in a voice vlan is hence not an option.

Any advice on this? I guess we're not the only ones with these issues...

[Dan Lukes · Accepted solution]

Based on my best knowledge, the SPA phones has not been designed to be exposed to unrestricted public. They have no DoS countermeasures implemented and they seems not to be designed to be placed in unrestricted world-wide accessible network. Read Dangerous default, bill fraud may occur - it's just so dangerous to have unit accessible by untrusted peer.

You should not only put ATA into separate VLAN. Particular ATA shall be allowed to speak to PBX only (and vice versa). Direct communication between two ATA should not be allowed. Don't forget that anyone can disconnect ATA, connect computer instead of it and attack any ATA in the VLAN then.

Of course, it's not solution for remote units.

According the options you mentioned ...

[1] will help a lot if unit is accessible from world, but even with it, such unit is in danger of DoS and/or unauthorized access

[2] ATA has not so powerful CPU and TLS setup is causing noticeable delays with call originating and answering. We considered it unacceptable to our users, but try it by self.

[3] ATA has no ACL. The device is designed to be placed in secured network

I guess we're not the only ones with these issues...

I suspect our approach will not help you so much ...

We arrange closed VPN between user's network and switch dedicated to unit<->switch communication. Non-VPN packets are not allowed to reach the unit at all and only from-switch and to-switch packets are allowed to pass the tunnel. We monitor the connection, we are responsible for configuration and security of ATA unit. User is not allowed to access it's configuration at all.

But our users are sensitive to security and reliability.

I can imagine unit connected in network with unclear reliability and security. But in such case we can take no responsibility for parameters out of our control. It's customer responsibility to configure it's network to be secure or take the risks related to unit connected in insecure network ...

[gustavolsson]

Thank you very much Dan for sharing your experiences, much appreciated!

We have locked down the units as much as possible but the SIP DoS thing is still a problem. We'll give the port change a go and will try TLS also. The latter seem more like a real solution since it actually adds security and not merely obscurity.

[Dan Lukes]

We use TLS for secure provisioning (using embedded client certificate for authentication) but not for SIP session.

[gustavolsson]

Dan, In your experience, approximately how long is the delay when using TLS for SIP session? Trouble is we need to add a license to our SBC to enable TLS, if we're talking ~15second delay that solution is not feasible. But if we're talking a couple of seconds it might be worth it (both setting it up and buying the license) for the sake of testing it.

I seem to remember ~3seconds overhead when we enabled TLS for XML services on the SPA-phones, which we deemed to long.

[Dan Lukes]

I don't remember exact result of our SIP over TLS test. But I assume the the TLS setup will take same time regardless  the purpose - so delay of SIP over TLS will be same as XML service over TLS.

For XML Service delays you can read Cisco XML Phone applicatiosn over https (SSL)