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