- VoiceOps - lists.voiceops.org

Trouble completing calls to Alliance Connect
by jared＠compuwizz.net Sept. 25, 2014

Sept. 25, 2014

Out of the 14 routes I have to connect to LRN 13196717000 Alliance Connect, only one route works. I've opened trouble tickets and haven't gotten anywhere with vendors. I get very long PDD and then the call fails on all routes. Carriers tested included Intelepeer, Bandwidth.com, O1, Verizon, Onvoy legacy, Onvoy 360 Networks, Global Crossing legacy, Peerless, Hypercube, and more. If anyone has a contact for this company that can look into this issue, please contact me off list. Regards, Jared Geiger

4 3

ITFS Term vendor question
by nick.crocker＠gmail.com Sept. 17, 2014

Sept. 17, 2014

Hi everyone, I have a question that I am hoping someone will have an answer to. We have recently deployed gear internationally and are turning up customers off this gear in various countries, we have ran into a situation that we did not plan for which is in-country toll free termination. For example a customer in Singapore needs to dial an in-country 800NNNNNNN TN and all of our carriers are looking at us like we have two heads. They will give us ITFS numbers of course but when we ask to term an ITFS call on them they act like it is not possible. This is coming from all the major players, ATT, Verizon, L3, Tata, DT, Colt, PCCW the list goes on and on. Can someone shed some light on how you might be accomplishing this, I have a hard time believing that customers are being told they cannot dial TF numbers in their own country. Any help or advice would be greatly appreciated. Regards, Nick

1 0

AUP on Unlimited Calling
by shripald＠gmail.com Sept. 11, 2014

Sept. 11, 2014

Hey Guys, For all of those who provide unlimited calling plans on their hosted offering--what do you consider abusive from a minutes of usage standpoint? 1000 minutes/sub? 5000/sub? at what point do you actually tell the customer they are abusing your service agreement and they are in breach? Thx Shri

5 5

Grandstream ATAs for Faxing
by jamesleo＠socket.net Sept. 10, 2014

Sept. 10, 2014

Hello, We having been utilizing Grandstream ATAs (HT70X and GXW400X) as analog hand offs with our Hosted Services built on the Broadworks platform and Sansay's SBC. We've had regular trouble when using them with fax and credit card machines. We support t38 but have often gone to g711 pass-through. Echo cancellation is disabled. We've tested them with the various jitter buffer lengths, Rx/Tx setting adjustments and various impedance values. The results seem very inconsistent. This is site to site as well as inconsistent results at the same site. The faxing/credit card transmissions will work for a period of time and then begin failing without any changes. We are a CLEC who control the QoS from device out to the PSTN. We've found that replacing the ATA with a Adtran TA90X usually corrects the issues but this is not a cost effective solution. Anyone have similar experiences with Grandstream ATAs? Anyone have reliable VoIP faxing with their ATAs? If anyone has been successful integrating the Grandstreams, I would be interested in knowing what config changes you've made from their default. Which models you've used with which firmware? Anyone have other ATA's that seem to work well for faxing and credit card machines? We'd like to keep our offering to as few manufacturers as possible that can offer 2, 4, 8+ FXS ports. Thanks for any and all recommendations. Jamey Socket Telecom

8 8

international origination providers
by shripald＠gmail.com Sept. 4, 2014

Sept. 4, 2014

Hey guys, I'm looking for an international SIP Orig provider. We have VoIP innovations for a few international numbers, however, their coverage is pretty small. Voxbone is an option, but they don't have Turkey, which is a specific requirement. Any suggestions? thanks, Shri

3 3

VoiceOps Digest, Vol 63, Issue 3
by slocoach＠gmail.com Sept. 4, 2014

Sept. 4, 2014

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 On Wed, Sep 3, 2014 at 2:08 PM, <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. Re: Mitigating SIP threats with SBC policies, configuration > settings (Gast, Jim) > 2. Mitigating SIP threats with SBC policies, configuration > settings (Patrick McNeil) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 3 Sep 2014 18:43:10 +0000 > From: "Gast, Jim" <jim.gast at tdstelecom.com> > To: Mark R Lindsey <lindsey at e-c-group.com>, Robert Nystrom > <ronystrom at gmail.com> > Cc: "voiceops at voiceops.org" <VoiceOps at voiceops.org> > Subject: Re: [VoiceOps] Mitigating SIP threats with SBC policies, > configuration settings > Message-ID: <24E30310A043EA45BA0B7366E86A3C390EB85666 at 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:voiceops-bounces at voiceops.org] On Behalf Of Mark R > Lindsey > Sent: Wednesday, September 03, 2014 11:35 AM > To: Robert Nystrom > Cc: voiceops at voiceops.org > 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 <ronystrom at gmail.com<mailto: > ronystrom at gmail.com>> 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. > > >>> mark at ecg.co<mailto:mark at ecg.co> +1-229-316-0013 http://ecg.co/lindsey > >

4 4

Any SIP based 411 provider ?
by feby.francis＠crosstel.com Sept. 4, 2014

Sept. 4, 2014

Hello Group, Does anyone use any SIP based 411 provider ? We currently use TDM based and was thinking if we can move to SIP based 411 provider as the transport cost doesn't make any sense to go in that route any more. Also any other ideas to effectively support 411 these days? Thanks for all the suggestions, Feby Francis

2 1

Mitigating SIP threats with SBC policies, configuration settings
by ronystrom＠gmail.com Sept. 4, 2014

Sept. 4, 2014

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

4 4

Mitigating SIP threats with SBC policies, configuration settings
by patrick＠themcneils.org Sept. 3, 2014

Sept. 3, 2014

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 <ronystrom at gmail.com> To: VoiceOps at voiceops.org 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

1 0

VoiceOps Digest, Vol 63, Issue 1
by slocoach＠gmail.com Sept. 3, 2014

Sept. 3, 2014

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 >

1 0