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