L3 Hardening: Gen.2 GWx

The GWx concept, originally introduced to come up w/ a solution against regularly occuring DDoS attacks, has recently undergone a massive consolidation process which has proven to work very well.

Gen.1 Refresher

As a short refresher, the Gen.1 GWx concept introduced in mid 2017 worked by deploying at least 4 systems that divided the attack flow amongst them by using round robin DNS, which enabled pre-filtering traffic at 4 locations. But since then, the attack bandwidth of distributed reflected DoS attacks steadily increased, for the first time mostly paralyzing all 4 Gen.1 GWx systems.

Gen.2: Implementation

So, it was time to overhaul and come up w/ a new and more efficient concept: Gen.2 GWx. Generally, the idea of dividing the attack traffic into multiple smaller flows is still the foundation of the whole concept, so that introducing even more distribution by adding multiple IP addresses each having it's own route in a different country was the next thing that came into mind. If you have 4x GWx, you could easily assign 8 IPs to each of them resulting in 32 IPs for the whole grid. This also takes into account the fact that those shady "DDoS Stresser" sites have their own business model, namely restricting their skript-kid "customers" to a limited number of IP addresses to attack.

Gen.2: Hardening & Stealthiness

When it comes to hardening the GWx systems, an extended packetfilter ruleset had to be implemented, mainly blocking (as in silently dropping) a lot more of INVALID traffic, packets w/ weird flags and so on. Also, it became a priority to protect 2nd layer upstream traffic which is not directly attackeable and is kept as secret as the backend IP addresses at the 3rd layer. Additionally, the DNS configuration returns only a small portion of valid IP addresses which is randomly cycling (w/o the help of lavalamps). The network security monitoring of netflow and syslog containing packet filter information remains highly relevant enabling us to classify attacks and subsequentially adjust mitigation concepts

In combination w/ the provider's own DDoS mitigation, this concept seems to be highly efficient, remains self-hosted thus under full control, can be easily expanded and comes at a fraction of the costs for the shady krautflaire approach. However, let's keep in mind that the base for many of the rDDoS attacks are old, unpatched and badly maintained systems as well as upstream providers that let invalid traffic pass.


Comments powered by Disqus