How We Deal With DDoS Attacks
In light of the recent DDoS attack on the NZX more than a few of our customers have asked us how SiteHost mitigates DDoS attacks. So we thought we might put out a little post explaining what goes on behind the scenes at SiteHost should this ever happen to you.
In light of the recent DDoS attack on the NZX more than a few of our customers have asked us how SiteHost mitigates DDoS attacks. So we thought we might put out a little post explaining what goes on behind the scenes should this ever happen to you.
If you’re like me and need a bit of a DDoS primer, Cloudflare has a great explanation but in short it is when your website is flooded with traffic with the intent of overwhelming the server and taking your website down.
SiteHost has engineered several ways of mitigating DDoS attacks and these are applied at different layers within our infrastructure. As a fun fact, while researching for this post I discovered that we have had 3 separate DDoS attacks last month, all without causing outages on our network or for our customers.
So how do we handle them?
The first layer in our defence is automated scrubbing. This work is performed by our upstream transit providers at the edge of their networks overseas. When an unusual traffic pattern is detected - all traffic destined to that server is diverted and automatically analysed with only the legitimate traffic being allowed through. This is called scrubbing. Last month this was enough to tackle all 3 of our DDoS attacks without any customer impact.
The second layer is ensuring that all circuits on our network are dimensioned to ensure congestion does not occur unexpectedly. This allows us to keep the blast radius small. For example, a DDoS attack that gets past the scrubbers is most likely to affect our internationally facing circuits first - but not our domestic facing circuits.
Occasionally we will see more sustained or coordinated attacks, and I can think of a handful in the past 5 years that have caused wider availability issues. In these situations, if we are not able to scrub the traffic (due to there being too much traffic) or the attack being particularly novel we are forced to sink all the traffic as far upstream as possible. This functionality is called Remote Trigger Black Hole or RTBH and we have this enabled (and tested) with all of our upstream transit providers.
Should a wider issue occur we can disable a single IP address and advertise this throughout the Internet. This has the effect of protecting our network, but also blocking all traffic to that IP address. So, good for our customers but not so good if you’re the one being attacked.
When this happens, we would provide you a new IP address and go about getting this configured behind a Layer 7 DDoS specialist such as CloudFlare. We have done this for a number of customers while the attacker has been targeting the customer and demanding a ransom via Cryptocurrency. In the examples where we have done this, we have been able to get their websites back online within hours. For more information on CloudFlare’s DDoS service please feel free to visit their website.
As a final point, we would love to be able to recommend customers use CloudFlare all the time - however for Spark customers, traffic to CloudFlare is served from overseas, which adds unnecessary latency and sometimes performance issues.
I hope to highlight this phenomenon in a future post about Peering, but if you have your website's DNS with SiteHost then CloudFlare’s CDN can be enabled with a click of a button. You can read how in our KnowledgeBase.
Hopefully this helps explain the work that goes into keeping our network running in top performance and protecting our customers from DDoS attacks. If you’d like to discuss this or any other hosting challenge then please do not hesitate to contact us.