SIDNlabs heeft een distributed testbed ontwikkeld dat gebruikers hiervan in staat stelt een realistische DDOS aanval na te bootsen.
Hierover verscheen op 14 oktober het onderstaande artikel op de website van SIDNLabs.
Developing and running a testbed for the DDoS Clearing House
Demonstrating the DDoS Clearing House in a representative simulated environment
Thijs van den Hout, Remco Poortinga-van Wijnen, Cristian Hesselman, Christos Papachristos, mr. Karin Vink CIPPE
We have created a distributed testbed that enables us to realistically test the DDoS Clearing House: a system that enables organisations to handle DDoS attacks more proactively by automatically sharing measurements of the DDoS attacks they handle. Our testbed allows us to temporarily skip typically time-consuming organisational processes such as setting up data sharing agreements and deploying software in production systems, which helps to advance the system towards a pilot and a production version. We discuss the motivation for developing our testbed, its requirements, implementation and our lessons learnt. We’re developing the Clearing House and the testbed as part of the CONCORDIA project, and we’ll be using both in the Dutch Anti-DDoS Coalition.
DDoS Clearing House recap
The DDoS Clearing House is a system that enables organisations to continually and automatically share measurements of the DDoS attacks they handle in the form of “DDoS fingerprints”. The Clearing House thus widens these organisations’ view on the DDoS attack landscape and enables them to proactively prepare their networks for a particular DDoS attack before it might actually hit them, which reduces the probability of system outages and increases the availability of services for customers and users. The DDoS Clearing House is an additional layer of security that complements DDoS mitigation services such as NBIP’s NaWas, which organisations need to have in place to handle actual DDoS traffic. The DDoS Clearing House is one of the core services of a so-called “Anti-DDoS Coalition”, a group of organisations that have committed to fight DDoS attacks collaboratively. One such coalition is the Dutch Anti-DDoS Coalition, which connects eighteen organisations from different sectors in the Netherlands, such as telecom, internet infrastructure, banking, and government. Coalition members are potential targets of DDoS attacks, or organisations in the business of DDoS mitigation. They share knowledge and expertise, for instance through the Clearing House and through joint large-scale DDoS drills. Joining forces in a coalition enables them to organise collaborative and proactive anti-DDoS activities. The DDoS Clearing House consists of three core components: the Dissector, DDoS-DB, and Converters.
- The Dissector analyses collected DDoS traffic captures and generates a fingerprint that summarize the attack’s key characteristics, such as protocol types, packet lengths, and source IP addresses. Coalition members run the Dissector in their networks and process their own network traffic internally.
- DDoS-DB is a logically centralised interactive database that stores and shares DDoS fingerprints from Dissectors operated by the members of an anti-DDoS coalition. DDoS-DB is a shared facility among coalition partners.
- A Converter receives fingerprints from DDoS-DB and enables members to ward off the attack described in a fingerprint targeted at them. A Converter transforms DDoS fingerprints into mitigation rules. Since fingerprints only contain the metadata of the attacks and not actual attack traffic, coalition partners don’t run the risk of unintentionally sharing privacy or commercially sensitive network traffic information with others.
Why do we need a DDoS clearing house testbed?
We need a testbed to learn how the DDoS Clearing House operates in a realistic setting, but without the members of an Anti-DDoS Coalition having to add a Dissector to their networks or to exchange fingerprints with actual IP addresses in them. This is important because we have experienced that such processes often take a significant amount of time, typically in the order of months. For example, organisations need to modify their production networks to add the Dissector, and they need to sign a data sharing agreement because the IP addresses in DDoS fingerprints are personally identifiable information (PII). While such processes are indispensable for a production version of the Clearing House (TRL8-9), they can significantly slow down the development and evaluation of the system. We aimed to achieve TRL6 with our testbed (“Technology demonstrated in relevant environment”). It precedes an actual pilot with the Dutch Anti-DDoS Coalition, which will be at TRL7 (“System prototype demonstration in operational environment”). In the pilot, the members of the coalition will install Dissectors in their networks and sign data sharing agreements covering the exchange of fingerprints via the DDoS-DB. Our goal is to use the pilot as input for a production system (TRL8-9).