<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Mark,<br>
I have seen 2 approaches here that work (ok 3 technically but we'll
get into that in a minute) <br>
<br>
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. <br>
<br>
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. <br>
<br>
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. <br>
<br>
<br>
I think there are 3 lessons device manufacturers need to take away
here:<br>
<br>
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.<br>
<br>
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. <br>
<br>
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. <br>
<br>
<br>
-Ryan<br>
<br>
<br>
<div class="moz-cite-prefix">On 01/04/2013 12:54 PM, Mark R Lindsey
wrote:<br>
</div>
<blockquote
cite="mid:1FB8230B-E2A4-4985-A420-5EDE636568E1@e-c-group.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
Are there any published hardening guidelines or howtos on IADs,
SIP PBXs, or and any other SIP devices on the public Internet?
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>But for IADs or SIP PBXs, it seems like these two are pretty
important: Restricting remote login; Restricting SIP.</div>
<div><br>
</div>
<div><i>(1) Restrict telnet, ssh, snmp to only Administrator
locations, by IP.</i></div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><i>(2) Restrict SIP & RTP to only the Service Provider's
SBCs, by IP.</i></div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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:</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>--
Make fraudulent calls</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>--
Play advertisements</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>--
Send a copy of the RTP to a mysterious destination on the
Internet</div>
<div><br>
</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Any other opinions?</div>
<div>
<div><br>
<div apple-content-edited="true">
<div><i style="color: rgb(214, 214, 214); font-family:
Consolas; font-size: x-small; ">>>> <a
moz-do-not-send="true" href="mailto:mark@ecg.co">mark@ecg.co</a>
+12293160013 <a moz-do-not-send="true"
href="http://ecg.co/lindsey">http://ecg.co/lindsey</a></i></div>
</div>
<br>
</div>
</div>
<div><br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
VoiceOps mailing list
<a class="moz-txt-link-abbreviated" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a>
</pre>
</blockquote>
<br>
</body>
</html>