<div dir="ltr">I agree with the simple path of putting a router (not FW) ACL in front of the SBC to restrict allowed traffic to known peers.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 3, 2014 at 10:00 AM, <span dir="ltr"><<a href="mailto:voiceops-request@voiceops.org" target="_blank">voiceops-request@voiceops.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send VoiceOps mailing list submissions to<br>
<a href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:voiceops-request@voiceops.org">voiceops-request@voiceops.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:voiceops-owner@voiceops.org">voiceops-owner@voiceops.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of VoiceOps digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Mitigating SIP threats with SBC policies, configuration<br>
settings (Robert Nystrom)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 3 Sep 2014 10:49:44 -0500<br>
From: Robert Nystrom <<a href="mailto:ronystrom@gmail.com">ronystrom@gmail.com</a>><br>
To: <a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>
Subject: [VoiceOps] Mitigating SIP threats with SBC policies,<br>
configuration settings<br>
Message-ID:<br>
<<a href="mailto:CAOibF5JO4zcCuaOx%2Bpiof2CjQnCpBJuumTQpOnrnduVkvOT4rg@mail.gmail.com">CAOibF5JO4zcCuaOx+piof2CjQnCpBJuumTQpOnrnduVkvOT4rg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hello Everyone,<br>
<br>
New to the list, so please take it easy on me :-) I'm reviewing the<br>
security configuration for a customer that is using ACME SBC for SIP trunk<br>
to their carrier, and have some questions. I thought you guys on the list<br>
would have a lot of experience with ACME security architecture and best<br>
practices recommendations.<br>
<br>
First: Customer's ACME is visible from public Internet on udp/5060, and<br>
SIP trunk is only being used to interconnect to SIP trunk carrier for<br>
inbound and outbound dialing. I've tested the SBC from the Internet and it<br>
actually responds to INVITE and REGISTER messages (with 403 Forbidden).<br>
They are alsonot supposed to be allowing any REGISTER for remote user MD5<br>
Digest Authentication - but it does respond. Question: Is there any<br>
operational need or business usage case that you would see that would make<br>
this setup a good idea? Because this appears to be a very risky and poor<br>
security. I would think that the SBC needs to be silently discard/drop any<br>
SIP message rather than respond, as this increases the visible footprint<br>
and encourages malicious actors / scanning tools. Would think that having<br>
ACLs that only permit traffic to/from the carrier's SBC would be the best<br>
configuration. Is their an opposing view?<br>
<br>
Second: I have written some SIP software that sends malformed message<br>
headers, and have noticed that the SBC responds with different errors other<br>
than 403 Forbidden when headers have unexpected values. For example, when<br>
I send an INVITE with extra CRLFs, I get a 400 CSeq missing header. When I<br>
send a Contact header of "None", I get 400 Invalid Contact. This leads me<br>
to believe that the SBC sip parser is parsing all of the SIP message rather<br>
than always sending a 403 Forbidden to an IP address sourced from the<br>
untrusted public Internet...this also seems to be very risky. Is there a<br>
specific security configuration with the policies that you would recommend?<br>
It seems like this introduces the risk of DoS and fuzzing attacks if the<br>
SBC is parsing more of the SIP message rather than just dropping the<br>
message based on invalid source IP. Could lead to cpu and memory issues if<br>
the queues are filled from invalid and fuzzed traffic.<br>
<br>
I have read the Oracle SCME Security Guide (July, 2014), and learned<br>
rudimentary that there are IP ACLs, realm trust level settings, and traffic<br>
queues. But really looking for practical advice based on experience with<br>
ACME. This customer takes security very seriously, and it is informative<br>
of them to see how the SBC responds, black box, to attacks from the<br>
outside. I'd like to recommend security settings. It seems like the best<br>
would be just to drop/discard any SIP message from the public<br>
Internet...but wanted to get the expert's opinion on ACME.<br>
<br>
TIA, Rob<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://puck.nether.net/pipermail/voiceops/attachments/20140903/f1e7ae19/attachment-0001.html" target="_blank">https://puck.nether.net/pipermail/voiceops/attachments/20140903/f1e7ae19/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
<br>
<br>
------------------------------<br>
<br>
End of VoiceOps Digest, Vol 63, Issue 1<br>
***************************************<br>
</blockquote></div><br></div>