<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Robert,<br>
    Nope no good reason not to ACL that interface. If its setup
    according to Oracle BCP then you would have the sip-interface set to
    agents-only and have an agent defined for the other end of the trunk
    and then an ACL entry setup for that agent. This would result in
    traffic from anywhere but that agent just being dropped. This would
    have no impact on distributed media from the peer, so no need to
    build an ACL entry or account for media sending endpoints, that will
    be handled dynamically by the SBC. <br>
    <br>
    On the second issue, properly ACL'ing the trunking interface will
    mitigate these issues however if there are other interfaces that DO
    need to listen publicly to anything then its best to set the sip
    interface on those to only allow registered endpoints and then tune
    your demotion policies to properly punt offenders to a blacklist.
    You are correct about this sort of thing being a gateway to CPU
    issues, and proper use of the deny list function is key to
    mitigating that exposure. The deny list is implemented in the NIU so
    stopping offenders there will preserve CPU cycles. <br>
    <br>
    Feel free to let me know if you need anymore clarity on this. <br>
    <br>
    -Ryan<br>
     <br>
    <div class="moz-cite-prefix">On 9/3/2014 8:49 AM, Robert Nystrom
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAOibF5JO4zcCuaOx+piof2CjQnCpBJuumTQpOnrnduVkvOT4rg@mail.gmail.com"
      type="cite">
      <div dir="ltr">Hello Everyone,
        <div><br>
        </div>
        <div>New to the list, so please take it easy on me :-)  I'm
          reviewing the security configuration for a customer that is
          using ACME SBC for SIP trunk to their carrier, and have some
          questions.  I thought you guys on the list would have a lot of
          experience with ACME security architecture and best practices
          recommendations.</div>
        <div><br>
        </div>
        <div>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?  Because
          this appears to be a very risky and poor security.  I would
          think that the SBC needs to be silently discard/drop any SIP
          message rather than respond, as this increases the visible
          footprint and encourages malicious actors / scanning tools.
           Would think that having ACLs that only permit traffic to/from
          the carrier's SBC would be the best configuration.  Is their
          an opposing view?</div>
        <div><br>
        </div>
        <div>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.</div>
        <div><br>
        </div>
        <div>I have read the Oracle SCME Security Guide (July, 2014),
          and learned rudimentary that there are IP ACLs, realm trust
          level settings, and traffic queues.  But really looking for
          practical advice based on experience with ACME.  This customer
          takes security very seriously, and it is informative of them
          to see how the SBC responds, black box, to attacks from the
          outside.  I'd like to recommend security settings.  It seems
          like the best would be just to drop/discard any SIP message
          from the public Internet...but wanted to get the expert's
          opinion on ACME.</div>
        <div><br>
        </div>
        <div>TIA, Rob</div>
      </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>