<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi, Robert (and Mark) –<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Re:
</span>Mitigating threats with SBC policies<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I agree with everything Mark said. And the Metaswitch Perimeta also does auto-blacklisting and the end result is comparable to the Acme Packet result.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Re:
</span>different errors other than 403 Forbidden when headers have unexpected values . . . very risky.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I agree. The bad guys can catalog the different responses and use those to fine tune attacks to exploit weaknesses unique to your combination of devices.
I would like to suggest a solution that I don’t deploy (and then tell you why I don’t). If you put a traditional firewall in front of your SBC, you can drop all traffic from places like the APNIC IP space. That way the intruder learns nothing. You can also
put layer 2 ACLs in your edge routers to drop traffic from implausible sources destined for VoIP SBCs.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I don’t put a firewall in front of my SBCs. When high-volume attacks come, the up-front firewall dulls the attack so much that the SBC does not auto-blacklist
effectively. In the very bad attacks, the dulled attack might not trip the alarms that it should. Also, if you put a firewall in front of your SBC, you will have to teach the firewall team when to yawn and when not to.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I am sorry if my answer is a little short on quantifiable details. We (kudos to Mark) have be debating whether to front an SBC with an external firewall for
years. As far as I remember the answer was always to read up on the auto-blacklisting in your SBC. And then use auto-blacklisting (even though the bad guys may be able to use error responses to figure out what equipment you have).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I wish I had a better answer.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="mso-element:para-border-div;border:none;border-bottom:solid windowtext 1.0pt;padding:0in 0in 1.0pt 0in">
<p class="MsoNormal" style="border:none;padding:0in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">/ Jim Gast, TDS Telecom<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> VoiceOps [mailto:voiceops-bounces@voiceops.org]
<b>On Behalf Of </b>Mark R Lindsey<br>
<b>Sent:</b> Wednesday, September 03, 2014 11:35 AM<br>
<b>To:</b> Robert Nystrom<br>
<b>Cc:</b> voiceops@voiceops.org<br>
<b>Subject:</b> Re: [VoiceOps] Mitigating SIP threats with SBC policies, configuration settings<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Robert -- These are good questions.<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">On Sep 3, 2014, at 11:49 , Robert Nystrom <<a href="mailto:ronystrom@gmail.com">ronystrom@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">First: Customer's ACME is visible from public Internet on udp/5060, and SIP trunk is only being used to interconnect to SIP trunk carrier for inbound and outbound dialing. I've tested the SBC from the Internet and it actually responds
to INVITE and REGISTER messages (with 403 Forbidden). They are alsonot supposed to be allowing any REGISTER for remote user MD5 Digest Authentication - but it does respond. Question: Is there any operational need or business usage case that you would see
that would make this setup a good idea? <o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Yes; you often do want to be able to REGISTER with the SBC from random places on the Internet. Does your specific customer need to allow registration from anywhere on the Internet? Maybe not. One popular place to blacklist in advance is
APNIC IP space.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The Acme Packet has auto-blacklisting features that can be setup so that if a specific source IP sends several SIP messages without successfully registering or completing a phone call, then the SBC can blacklist the source for a while.
E.g., if you don't successfully register within your first three SIP messages, then blacklist you for an hour.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If you do know in advance all the right places from which you 'd be sending SIP to the SBC, then it *is* best to setup the SBC for default-deny so that traffic only from those sources is permitted. That's straightforward to do by matching
access-control-trust-levels between the realm-config and the access-control objects.<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">Second: I have written some SIP software that sends malformed message headers, and have noticed that the SBC responds with different errors other than 403 Forbidden when headers have unexpected values. For example, when I send an INVITE
with extra CRLFs, I get a 400 CSeq missing header. When I send a Contact header of "None", I get 400 Invalid Contact. This leads me to believe that the SBC sip parser is parsing all of the SIP message rather than always sending a 403 Forbidden to an IP address
sourced from the untrusted public Internet...this also seems to be very risky. Is there a specific security configuration with the policies that you would recommend? It seems like this introduces the risk of DoS and fuzzing attacks if the SBC is parsing
more of the SIP message rather than just dropping the message based on invalid source IP. Could lead to cpu and memory issues if the queues are filled from invalid and fuzzed traffic.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">The auto-blacklisting functions can help mitigate this risk. In addition to blacklisting based on failure to successfully REGISTER (or do anything else allowed by policy), you can auto-blacklist sources of "invalid signaling". I haven't
found a good written definition of "invalid signaling", but I have definitely seen devices that sent slightly-malformed SIP trigger it and get blacklisted. Non-RFC3261-compliant CR's and LF's are definitely a popular way to do it. Bria/EyeBeam/X-Lite's "UDP
Keepalives" (0-byte UDP datagrams) have been another way.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Further, there are internal resources (primarily, CPU capacity) allocated differently for trusted sources versus untrusted sources. An untrusted source could be a device that hasn't yet successfully registered , for example, and we might
only want to give 2% of total system capacity to all untrusted sources. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">To your bigger point, though, Oracle/Acme Packet does try to be a security device, and I know they test it against fuzzers. Their release notes show when they fixed a security bug or a SIPd crash that was found through fuzzer testing. Yes,
it means they have to be extremely careful with how they parse the SIP in order to do so safely.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><i><span style="font-size:10.0pt;font-family:Consolas;color:#177F2C">>>>
<a href="mailto:mark@ecg.co">mark@ecg.co</a> +1-229-316-0013 <a href="http://ecg.co/lindsey">
http://ecg.co/lindsey</a></span></i><o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>