[VoiceOps] Mitigating SIP threats with SBC policies, configuration settings

[Robert Nystrom]

Thanks everyone for their insight and advice.  This was valuable.

Thanks Ryan, Mark, Tim, Russ, Jim, Patrick.


On Wed, Sep 3, 2014 at 11:15 AM, Ryan Delgrosso <ryandelgrosso at gmail.com>
wrote:

>  Hi Robert,
> 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.
>
> 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.
>
> Feel free to let me know if you need anymore clarity on this.
>
> -Ryan
>
> On 9/3/2014 8:49 AM, Robert Nystrom wrote:
>
> 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
>
>
> _______________________________________________
> VoiceOps mailing listVoiceOps at voiceops.orghttps://puck.nether.net/mailman/listinfo/voiceops
>
>
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20140904/b899ee4b/attachment.html>