[VoiceOps] Mitigating SIP threats with SBC policies, configuration settings
ronystrom at gmail.com
Thu Sep 4 09:40:21 EDT 2014
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>
> 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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the VoiceOps