For a few years now, we here at DOSarrest started to field enquiries into hybrid DDoS defense setups, where customers wanted to leverage their existing on-premise DDoS mitigation infrastructure to work in co-ordination with the cloud scrubbing capabilities that our network infrastructure protection service, which we call “Data Center Defender” aka DCD is able to provide.
The basic premise of these setups is as such:
When the DDoS attack volume grows beyond the capacity of the customer’s network upstream links or the capacity of the on-premise device, the on-prem device diverts traffic to the cloud provider, who has a much larger DDoS surface area to ingest and scrub the traffic..
With DOSarrest’s DCD which has great network flexibility is able to integrate with a wide variety of on prem devices and we were able to setup hybrid configurations with a number of notable on-prem vendors, utilizing BGP, API’s and web portal activation including these:
On-premise DDoS vendors:
- Juniper SRX
- Palo Alto
- Arbor Netflow/peakflow
For the most part, these setups have been successful in helping the customer get the best of both worlds, where they can continue to leverage their hardware for smaller and sophisticated attacks and use the DOSarrest DCD cloud service to handle the large volumetric and protocol attacks. However, it should be noted that we have seen a few issues that can compromise the effectiveness of these hybrid solution.
A couple of examples of these pitfalls are:
A) Keeping the on-prem configuration up to date – typically on-prem devices are set with various threshold settings, flow ingestion and SNMP read capabilities on the edge network devices of their customers networks. Often there are network topology changes (eg. Adding an additional upstream connection, adding a mixed set of capacity links, etc.) over the course of a year, and the on prem configuration is not kept up to date. This can cause an attack to be overlooked by the on prem device, resulting in saturation and collateral degradation of services, and not just to the targeted IP
B) On-Prem threshold definitions do not account for different types of attacks – This type of situation can be seen on a wide set of platforms, which may be using some sort of combination of measuring bit and/or packets per second rates, as well as different profiles for each type of valid IP/TCP/UDP services. Over the last 12 months we have seen cyber attackers use GRE packets to launch 300+ Gbps attacks, which the on prem device does not initially identify, as it does not have a profile built for that. This causes the customer to have to manually fail traffic over to DOSarrest, at which point the damage they have suffered is considerable.
C) Location, Location, Location – the location of the on-prem device will impact it’s ability to identify and divert traffic. Ideally, the hardware should be situated as close as possible to the edge, and in front of the aggregation layer. As this could represent a large amount of traffic constantly traversing these on-prem devices, it may not be fiscally feasible to put the appropriate on-prem device in place, from a reasonable capex and opex perspective. Often then, a smaller less capable model is purchased and put in front of a subset of the customer’s network that contains a higher revenue customer base (eg. Managed Hosting versus Dedicated hosting customers). Because of this limited location, some on-prem solutions are not quickly able to see what is occurring at the edge of the network, resulting in extended periods of saturation.
These are just some of the examples we have seen when troubleshooting slow diversion to the DCD network. Fundamentally, these types of situations come down to the cost, capability and placement of these on-prem devices.
All this begs the question. Why have on-prem devices at all?
If you as a customer are going to be put on a vendor treadmill of having to buy the latest and greatest hardware platform, along with ongoing licensing fees, in order to take full advantage of a cloud solution, is there an alternative solution? The answer is yes.
With DCD, you can have a hybrid setup without the requirement of an on-prem device. All you need to do is to export your netflow/sflow/jflow to the DCD network (a feature already built into your routers), configure your appropriate thresholds, and that’s it. DCD can automatically make the global BGP changes to divert traffic just based on these exported flow records, within seconds.This allows you to avoid the heavy capex of on-prem DDoS appliance, and put the money to better use, such as smaller IDS/IPS or next gen FW in front of your customers or systems that warrant these higher-level services.
For more information on DDoS protection for infrastructure
Test your on-premise device to be sure it can handle what you think or were told it can handle.
Try our self-serve DDoS Attack platform
CTO, DOSarrest Internet Security