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 <[email protected]> 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 > [email protected]https://puck.nether.net/mailman/listinfo/voiceops > > > > _______________________________________________ > VoiceOps mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/voiceops > >
_______________________________________________ VoiceOps mailing list [email protected] https://puck.nether.net/mailman/listinfo/voiceops
