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, <[email protected]> wrote: > Send VoiceOps mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: [email protected] > Subject: [VoiceOps] Mitigating SIP threats with SBC policies, > configuration settings > Message-ID: > < > caoibf5jo4zccuaox+piof2cjqncpbjuumtqponrnduvkvot...@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 > [email protected] > https://puck.nether.net/mailman/listinfo/voiceops > > > ------------------------------ > > End of VoiceOps Digest, Vol 63, Issue 1 > *************************************** >
_______________________________________________ VoiceOps mailing list [email protected] https://puck.nether.net/mailman/listinfo/voiceops
