So we learned to ask our clients about their bandwidth limitations to avoid overwhelming their pipes. Proudly, we would start our attacks on say, a SIP target, only to find that the network is saturated with our traffic. We consider these attacks as far more sophisticated than a simple UDP flood when attacking specific behaviors of the applications handling SIP, RTP and other protocols used for real-time communications. Our focus with DDoS simulation has been on non-volumetric attacks aimed at the applications on test. So what does this have to do with our denial of service security tests? A lot, actually. VoIP Unlimited’s website was down at the time of writing Our VoIP DDoS testing experience So, while the attacks have not stopped, they have shifted again to a different target. At the time of writing, not only do their SIP services appear to be unreachable, but also their websites. This victim was previously targeted back in late August and early September. The cyber-criminals behind this are now back to targeting VoIP Unlimited, a UK provider. In the second post, what I found interesting is that they started seeing other traffic, including SIP protocol-specific attacks. And naturally, they highlighted their offers and technology - for example, that they have created filtering for invalid traffic on the SIP targets. They also gave out some numbers, most interestingly, the malicious traffic peaking at 130 Gbps and 17.4 million packets per second. The first post explained how most of the malicious traffic was coming from DNS reflection and other common amplification and reflection vectors. How did they resolve their issues? Similar to VoIP.ms, they routed their traffic through Cloudflare’s Magic Transit.Ĭloudflare’s staff wrote two valuable blog posts where they shared details on the sort of traffic that they saw during these attacks. This also affected many other providers that route their calls through Bandwidth, including Twilio, Accent, DialPad,, and RingCentral. During that time, 911 emergency calls passing through the victim provider along with other critical services were failing.
They were targeted right after VoIP.ms and suffered downtime from 25th until around 30th September. Since I wrote that post, more attacks were launched. Instead, they were saturating the network bandwidth and server resources. Primarily, the attacks appeared to consist of traffic commonly generated by booter services. In my previous post, I explained that providers were being blackmailed after their services fell prey to ongoing DDoS attacks. So what changed my mind? To explain myself, I need to describe a bit what has been happening to some major VoIP providers in the past 2 months. But, it’s time to stop neglecting bandwidth saturation and start giving it the attention that it deserves. Ironically, we had been unwittingly simulating volumetric DDoS attacks while quietly ignoring our own results. If you had asked us for such a test, we would have given you a negative answer. Until a few days ago, I was of the opinion that simulating volumetric DDoS attacks is not something we should be doing.
0 kommentar(er)
