[VoiceOps] VoiceOps Digest, Vol 63, Issue 1

[par]

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.


On Wed, Sep 3, 2014 at 10:00 AM, <voiceops-request at voiceops.org> wrote:

> Send VoiceOps mailing list submissions to
>         voiceops at voiceops.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://puck.nether.net/mailman/listinfo/voiceops
> or, via email, send a message with subject or body 'help' to
>         voiceops-request at voiceops.org
>
> You can reach the person managing the list at
>         voiceops-owner at voiceops.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of VoiceOps digest..."
>
>
> Today's Topics:
>
>    1. Mitigating SIP threats with SBC policies, configuration
>       settings (Robert Nystrom)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 3 Sep 2014 10:49:44 -0500
> From: Robert Nystrom <ronystrom at gmail.com>
> To: VoiceOps at voiceops.org
> Subject: [VoiceOps] Mitigating SIP threats with SBC policies,
>         configuration settings
> Message-ID:
>         <
> CAOibF5JO4zcCuaOx+piof2CjQnCpBJuumTQpOnrnduVkvOT4rg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello Everyone,
>
> 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.
>
> 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?
>
> 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.
>
> 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.
>
> TIA, Rob
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://puck.nether.net/pipermail/voiceops/attachments/20140903/f1e7ae19/attachment-0001.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
> ------------------------------
>
> End of VoiceOps Digest, Vol 63, Issue 1
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20140903/2ea5cc00/attachment-0001.html>