Everyone is likely aware of the recent issues with VoIP.ms. Some are not aware that there was also an attack on 3 UK providers 3 weeks. ago.
Because of this, Skyetel has reached out to various people such as @wardmundy and myself to have a conversation about their DDoS defense design.
The details of the conversation are confidential, but I will say that I am still 100% confident in Skyetel’s ability to handle a DDoS attack such as the one being waged against VoIP.ms right now.
Frankly I can think of several providers I would trust more than voip.ms to withstand a DDoS.
But I don’t think I would be painting bullseyes on their backs in a public forum!
Some hackers enjoy a challenge.
I’ve been in touch with the President of Skyetel in regards to their DDoS mitigation strategy because of some of what’s going on in the industry and specifically what happened to VoIP.ms. I completely agree with what Jared has said. Solid engineers that know what they’re doing. They’ve got a solid mitigation strategy that I’m confident wouldn’t be susceptible to these attacks.
Rob started a list post for provider recommendations on reddit
The grass isn’t always greener on the other side and all providers are subject to outages. That said this is a good display of why you shouldn’t have all of your eggs in one basket.
Chris Bardos, the President of Skyetel, specifically asked me to post my opinion of the conversation on multiple forums. He is well aware of the target problem.
A bit off-topic for this thread, but the recent VoIP.MS DDoS wasn’t just affecting their service. Our company’s external SIP traffic was affected as well, as provided by SIP.US. Looking up the LRN details for a few numbers we have through VoIP.MS and SIP.US, it appears as if both of them have Bandwidth.Com as their upstream provider. Those guys were likely the ones hit with the DDoS.
I really doubt Bandwidth is the issue with VoIP.ms. I can’t ping most of VoIP.ms’ POPs or website. Sure most of their DIDs are probably through Bandwidth. However, if Bandwidth is having a major outage we would be hearing it from all ends of the VoIP universe.
Just a note, there is no part of VOIP that needs any ICMP (ping) path.
True. VoIP.ms advertises that you should ping their POP servers to determine best latency. So when their servers are “un-pingable” there is an issue.
That was not the problem, name resolution was, SIP can use bare IP or SRV or NAPTR or a number of of other protocols to resolve the actual SIP server. For a couple of days, voip.ms choice of their Name Service (DNS) has been compromised.
Translate there ping advise to "pissing in the wind’ here, it is totally vapid
Yes, DNS is one of their issues but also the IP addresses of their POPs are not responding or allowing registrations. I assume the DDoS was directed to all their infrastructure. What a mess!
That indicates that they have a bigger problem than DNS as replying to SIP messages is always once removed from Name services. If their SIP servers are still equally overwhelmed, then competannt help will eventually out, but please, your random surmise (guessing) won’t be helpful . . . .
I would think you would want it to be, rather than what it appears to be. Let’s just say it is.
If there is a question of who is actually the underlying provider of the phone-calls and phone numbers I am actually paying for and using , I personally would choose an entity that was uniquely authoritative, I don’t want my provider to be outsourcing anything especially if they do it incompetently.
I really doubt Bandwidth is the issue with VoIP.ms.
It was odd or coincidental that starting on Saturday we confirmed sporadic connectivity issues with VoIP.MS as well as SIP.US. Here was the notice that I found on SIP.US’s website around the time. Maybe the bad actors hit multiple providers I guess. Which isn’t out of the question. Crazy times for sure!
If this was Bandwidth, which like those two, is my primary pipe. Then I have a more resilient network than SIP.US and VoIP.ms because I have not been down or experienced any call quality issues or had any services interrupted by any of this.
Yeah, according to Bandwidth’s status page (https://bandwidth.statuscast.com/#!/incidentlist?componentId=26550) their SIP trunking appears to have been steady as she goes the entire time.
That’s concerning how that multiple providers could fall over during the same timeframe. Guess to have a truly more fault-tolerant phone system it would likely involve primary SIP trunking with one provider, secondary SIP trunking with another provider, and some tertiary T1/PRI broken out with someone else?
Multiple sip providers over multiple ISP over multiple physical media… You can never be too redundant assuming money is no object.
FYI that I reached out to a support guy I know relatively well over at SIP.US. Their DDoS issue was related to an upstream data center provider. So yeah, nothing to do with Bandwidth.Com services. I have a sneaky suspicion that there are definitely some “cloud” providers being hit. Getting spotty response times trying to use my primary VAR’s e-com site, manage Office 365 services, etc. Trying to access them from other networks with similar poor outcomes.