Thanks Mark, Jesse, and Jim, The blacklist feature on the peering makes sense given Mark's examples. I fully agree with the divergent change downside, the others are debatable as Jesse pointed out.
I have not studied the resource drain of adding a simple ACL to a router - but expect the impact to be minimal vs requiring a hardware upgrade. I also have not studied the impact of attacks against a properly configured SBC, does it eat up extra resrouces or is sluffing off the attack traffic trivial? I don't know. Regards, Russ On Thu, Sep 4, 2014 at 9:49 AM, Gast, Jim <[email protected]> wrote: > Hi, Russ – > > > > I agree. It adds to safety to put ACLs in the router(s) to discard hostile > packets destined for the peering interface(s) of your SBC(s). Mark > correctly mentioned the downsides. Router ACLs are simple and effective. > > > > Jim Gast, Network Architecture, TDS Telecom > > > > *Good, Fast, Cheap. Pick 2.* > > > > *From:* VoiceOps [mailto:[email protected]] *On Behalf Of *Mark > R Lindsey > > *Sent:* Wednesday, September 03, 2014 10:16 PM > *To:* Russ Penar > *Cc:* [email protected] > *Subject:* Re: [VoiceOps] VoiceOps Digest, Vol 63, Issue 3 > > > > Yes, Robert Nystrom the OP was talking mostly about a peering. And I > inadvertently changed the subject. Sorry about that. > > > > There are some good reasons to consider auto-blacklisting of peers: > > > > -- Sometimes peers have bugs and do nasty things > > > > -- Sometimes peers have routing loops (or as RFC3261 calls > them, "spirals") > > > > -- Sometimes peers decide to do load testing at 10am on a > Tuesday > > > > -- Sometimes peers get hacked > > > > But short of blacklisting, you might just want to limit the rate of > traffic they can send, then block their traffic if they exceed the limit. > > > > The Acme Packet has an access-control object that lets you configure the > default-deny policy. But you suggested putting a router ACL in front of the > peering interface. > > > > + Upside: Some defense in depth. Maybe if the SBC (or its > admin) got something wrong, the firewall (and its admin) won't make the > same mistake. > > > > - Downside: Divergent change: to reconfigure the IP addresses > or UDP ports of the peering you have to do it in multiple places > > > > - Downside: You have to prevent the firewall/router from > changing anything useful about the packet > > > > - Downside: You have to buy and operate and patch two > distinct devices with capacity to inspect every packet's IP and UDP > headers. Here's an example where that might really matter: If you could > depend on the SBC to be the security appliance, you might use a Cisco > Catalyst 3560X as the router between the SBC and the Internet. But if you > have to buy a router that can actually inspect every packet and keep up > with nontrivial workload, you'll need something much more capable and thus > expensive. > > > > *>>> [email protected] <[email protected]> +1-229-316-0013 <%2B1-229-316-0013> > http://ecg.co/lindsey <http://ecg.co/lindsey>* > > > > On Sep 3, 2014, at 18:23 , par <[email protected]> wrote: > > > > Jim and Mark - I read the original question to be centered around > peering vs Registration interfaces. I get the auto-blacklist argument for > Registration interfaces. I struggle to understand the same rationale for > peering interfaces. SBCs are supposed to be hardened security devices, but > as Mark mentioned - they do take fixes for bugs in the security context. > IF the company you're helping doesn't have the expertise to properly > configure or maintain their SBC, why introduce risk by not having a router > ACL in front of the peering interface(s)? > > > > Regards, > Russ > > > > > Message: 1 > Date: Wed, 3 Sep 2014 18:43:10 +0000 > From: "Gast, Jim" <[email protected]> > To: Mark R Lindsey <[email protected]>, Robert Nystrom > <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [VoiceOps] Mitigating SIP threats with SBC policies, > configuration settings > Message-ID: <24E30310A043EA45BA0B7366E86A3C390EB85666@cmailbox5> > Content-Type: text/plain; charset="us-ascii" > > Hi, Robert (and Mark) - > > Re: Mitigating threats with SBC policies > > I agree with everything Mark said. And the Metaswitch Perimeta also does > auto-blacklisting and the end result is comparable to the Acme Packet > result. > > Re: different errors other than 403 Forbidden when headers have unexpected > values . . . very risky. > > I agree. The bad guys can catalog the different responses and use those > to fine tune attacks to exploit weaknesses unique to your combination of > devices. I would like to suggest a solution that I don't deploy (and then > tell you why I don't). If you put a traditional firewall in front of your > SBC, you can drop all traffic from places like the APNIC IP space. That > way the intruder learns nothing. You can also put layer 2 ACLs in your > edge routers to drop traffic from implausible sources destined for VoIP > SBCs. > > I don't put a firewall in front of my SBCs. When high-volume attacks > come, the up-front firewall dulls the attack so much that the SBC does not > auto-blacklist effectively. In the very bad attacks, the dulled attack > might not trip the alarms that it should. Also, if you put a firewall in > front of your SBC, you will have to teach the firewall team when to yawn > and when not to. > > I am sorry if my answer is a little short on quantifiable details. We > (kudos to Mark) have be debating whether to front an SBC with an external > firewall for years. As far as I remember the answer was always to read up > on the auto-blacklisting in your SBC. And then use auto-blacklisting (even > though the bad guys may be able to use error responses to figure out what > equipment you have). > > I wish I had a better answer. > > Cheers, > > / Jim Gast, TDS Telecom > > From: VoiceOps [mailto:[email protected]] On Behalf Of Mark R > Lindsey > Sent: Wednesday, September 03, 2014 11:35 AM > To: Robert Nystrom > Cc: [email protected] > Subject: Re: [VoiceOps] Mitigating SIP threats with SBC policies, > configuration settings > > Robert -- These are good questions. > > On Sep 3, 2014, at 11:49 , Robert Nystrom <[email protected]<mailto: > [email protected]>> wrote: > 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? > > Yes; you often do want to be able to REGISTER with the SBC from random > places on the Internet. Does your specific customer need to allow > registration from anywhere on the Internet? Maybe not. One popular place to > blacklist in advance is APNIC IP space. > > The Acme Packet has auto-blacklisting features that can be setup so that > if a specific source IP sends several SIP messages without successfully > registering or completing a phone call, then the SBC can blacklist the > source for a while. E.g., if you don't successfully register within your > first three SIP messages, then blacklist you for an hour. > > If you do know in advance all the right places from which you 'd be > sending SIP to the SBC, then it *is* best to setup the SBC for default-deny > so that traffic only from those sources is permitted. That's > straightforward to do by matching access-control-trust-levels between the > realm-config and the access-control objects. > > > 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. > > The auto-blacklisting functions can help mitigate this risk. In addition > to blacklisting based on failure to successfully REGISTER (or do anything > else allowed by policy), you can auto-blacklist sources of "invalid > signaling". I haven't found a good written definition of "invalid > signaling", but I have definitely seen devices that sent slightly-malformed > SIP trigger it and get blacklisted. Non-RFC3261-compliant CR's and LF's are > definitely a popular way to do it. Bria/EyeBeam/X-Lite's "UDP Keepalives" > (0-byte UDP datagrams) have been another way. > > Further, there are internal resources (primarily, CPU capacity) allocated > differently for trusted sources versus untrusted sources. An untrusted > source could be a device that hasn't yet successfully registered , for > example, and we might only want to give 2% of total system capacity to all > untrusted sources. > > To your bigger point, though, Oracle/Acme Packet does try to be a security > device, and I know they test it against fuzzers. Their release notes show > when they fixed a security bug or a SIPd crash that was found through > fuzzer testing. Yes, it means they have to be extremely careful with how > they parse the SIP in order to do so safely. > > >>> [email protected]<mailto:[email protected]> +1-229-316-0013 http://ecg.co/lindsey > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://puck.nether.net/pipermail/voiceops/attachments/20140903/9277df4e/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Wed, 3 Sep 2014 16:08:01 -0400 > From: Patrick McNeil <[email protected]> > To: [email protected] > Subject: [VoiceOps] Mitigating SIP threats with SBC policies, > configuration settings > Message-ID: > < > cahymf5beuwuj4myuxtgqz6jtkf2bxgsqxhsytpdqkugpiox...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Rob, > > Re: First > Just make sure you follow the appendix on DDoS Prevention for Peering > Environments and you should be ok. If you are peering / trunking over the > Internet, and more than just the trunk provider can hit your IP, then > you've likely got one of the following issues: > > 1. sip-interface > sip-ports is not set to agents-only (Note: That > automatically sets up a default deny-all and a permit ACL for just the > remote session-agent you've defined - i.e. the telco at the other end) > 2. You've got an ACL implemented with a trust level that does not match the > realm trust level. See the trust level table in that document. If they > don't match you will get results that are not intuitive. > > It *can* be a good idea to connect a SIP interface to the Internet under > the right circumstances - like when supporting remote SIP clients. However > in your case it just sounds like you're misconfigured. > > Re: Second > The varying response messages are because Acme Packet had to play nice by > the RFCs if the port is open. If you get your config right it won't be > reachable. Also note that there is extensive DoS and fuzzing testing > conducted during development so it's not likely you'd create an issue. > > Again - just watch the agents-only setting and that will set up the ACLs to > work as you suggest - only allow traffic from a trusted endpoint. > > > You should also check out the Oracle | Acme Packet Community. Registration > is free, and these types of questions can be answered there if you can't > find an old thread. http://community.acmepacket.com/ > > > Cheers, > Patrick McNeil > > ---------- Forwarded message ---------- > From: Robert Nystrom <[email protected]> > To: [email protected] > Cc: > Date: Wed, 3 Sep 2014 10:49:44 -0500 > Subject: [VoiceOps] Mitigating SIP threats with SBC policies, configuration > settings > 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/e193ccfb/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > VoiceOps mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/voiceops > > > ------------------------------ > > End of VoiceOps Digest, Vol 63, Issue 3 > *************************************** > > > > _______________________________________________ > VoiceOps mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/voiceops > > >
_______________________________________________ VoiceOps mailing list [email protected] https://puck.nether.net/mailman/listinfo/voiceops
