[VoiceOps] IAD and SIP PBX Hardening Guidelines

Fri Jan 4 19:53:14 EST 2013

Mark,
I have seen 2 approaches here that work (ok 3 technically but we'll get 
into that in a minute)

The first approach is what Linksys/Cisco devices do which is use a 
restricted access domain. This allows the device to use a DNS lookup to 
see if the party requesting access should be allowed to talk to the 
device. These params are used to restrict both management as well as sip 
communications. It certainly isnt foolproof but it goes a long way 
toward making you a less attractive target than the next guy. I have 
seen various permutations and have requested come vendors implement 
similar features (only accept SIP from registered proxy in grandstream 
etc) but nothing quite to the extent that this provides.

The second approach which is arguably far superior to option 1 is a 
total out-of-band management solution similar to what Innomedia provides 
on their endpoints through their DMS product which gives you complete 
out of band management that can traverse customer NAT. The single 
biggest reason I see for devices left exposed to the dirty dirty 
internet is provider access for management. These devices can be 
additionally locked down to not accept sip from anything but the proxy 
they register to, effectively making it a smooth wall to the internet 
but to the provider its as if it was on their desk in the office.

The 3rd psuedo approach isnt one that most have problems with but simply 
NAT your CPE devices. This eliminates 99% of SIP exposure through the 
stateful NAT table, and 100% of management exposure as long as you dont 
immediately have the customer jam it in the DMZ and undo all this. This 
is really just accomplished through some customer education (I know 
laugh it up, JUST customer education) and a proper edge device on the SP 
to manage NAT traversal.

I think there are 3 lessons device manufacturers need to take away here:

1: Out of band management is the way of the future, and I dont mean SIP 
triggered re-provisioning. That was a bad idea when it was conceived and 
it hasnt improved since. 99% of the time if you as the provider are in a 
device tinkering its because it wont register for some reason, so what 
good is a management system that DEPENDS on it registering in order to 
receive the order to reprovision. It is the SIP equivalent of a solar 
powered flashlight. Get a REAL OOB management solution, something that 
can traverse NAT and let the provider manage and poll devices at scale.

2: Sweet zombie Jesus don't allow the SIP credentials to be read out of 
the device in ANY fashion, especially not over the network. Its not a 
matter of if a device will become compromised but when. Eventually a 
motivated enough attacker will always get what they want. Its trivial to 
just remove the temptation. If it is fruitless to compromise a specific 
brand of device then people will stop trying to compromise it.

3: ACLs ACLs ACLs. Give the provider every tool you can imagine to lock 
their devices down. Not one, not two but several. Not every provider has 
the same business or support model and your one-size-fits-all solution 
probably doesnt work for many providers. I would like to Cisco (well 
sipura since they actually built it) as leading the pack here with DNS 
based management whitelists. These are manageable by even the most 
challenged ITSP and follow the KISS principle which leads to much less 
breakage.

-Ryan

On 01/04/2013 12:54 PM, Mark R Lindsey wrote:
> Are there any published hardening guidelines or howtos on IADs, SIP 
> PBXs, or and any other SIP devices on the public Internet?
>
> If not, we should put some together. For IADs, the list might start 
> with some of the same rules you'd use on any other router.
>
> But for IADs or SIP PBXs, it seems like these two are pretty 
> important: Restricting remote login; Restricting SIP.
>
> /(1) Restrict telnet, ssh, snmp to only Administrator locations, by IP./
>
> Many of the recent attacks happening at service providers are IAD or 
> SIP PBX compromises. These devices are often on the public Internet, 
> and they have poor passwords. BadGuy just scans for telnet-accessible 
> devices, logs in, and then sets up the IAD to route calls. Or he may 
> just simply steal the SIP credentials.
>
> I can't think of good reasons that these IADs should allow telnet, 
> ssh, or snmp from the public Internet at large. Of course, the 
> administrators of the device (often the voice SP itself) needs to be 
> able to login.
>
> As an alternative, you might just ensure that strong passwords are 
> used. Lots of folks are moving to RADIUS authentication for IADs, on 
> the hopes that they'll use better usernames and passwords.
>
> /(2) Restrict SIP & RTP to only the Service Provider's SBCs, by IP./
>
> On some IADs, you can send SIP to the device's SIP stack just by 
> sending it SIP to port UDP/5060. A lot of IADs are CPU-poor anyway, so 
> giving them extra SIP parsing isn't going to help. In fact, just 
> sending in bogus SIP can be enough to DoS the device.
>
> But in our world of (a)  buffer overflows and code injection and (b) 
> complex parsing of SIP, it seems intrinsically risky to allow BadGuy 
> to send SIP in to a CPE. It seems very likely that a determined 
> attacker could use specially-crafted SIP messages to cause a SIP IAD 
> or phone to do anything they want:
> -- Make fraudulent calls
> -- Play advertisements
> -- Send a copy of the RTP to a mysterious destination on the Internet
>
>
> Some of the same risks are present with RTP. But fortunately, RTP is 
> simple enough that hardening the implementation may be easier. And 
> often RTP is handed directly to a DSP, where (I would guess) the 
> opportunities for code injection are less interesting.
>
> But there's a real downside here: What if you need to manage SIP 
> traffic, and allow IADs to register to some other location? If you're 
> doing it  RFC3263 style, then you might just be using DNS to route 
> IADs and PBXs to the appropriate SBC. If you need to add additional 
> SBCs, then you have to be sure the IAD will have ACLs that allow 
> traffic from those other SBCs in advance.
>
> Finally: What about the poor souls who put SIP phones directly on the 
> Public Internet?  Maybe you can change the administrator password, and 
> make it harder to login and extract the SIP authentication 
> credentials. But beyond that, SIP phones don't typically have 
> firewall-type features. I think the better bet here is to put them 
> behind a stateful firewall/NAT device.
>
> Any other opinions?
>
> />>> mark at ecg.co <mailto:mark at ecg.co> +12293160013 http://ecg.co/lindsey/
>
>
>
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20130104/d42d8c0a/attachment-0001.html>