[VoiceOps] IAD and SIP PBX Hardening Guidelines

[Mark R Lindsey]

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 +12293160013 http://ecg.co/lindsey


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