Hello everyone, I am Nikos Kostopoulos and I am a postdoctoral researcher
at the National Technical University of Athens, Greece
This demonstration will present RARE efforts on Distributed Denial of Service (DDoS) attack mitigation
The demo has been prepared along with David Schmitz
who is a researcher at the Leibniz Supercomputing Centre in Munich, Germany
Our demonstration includes a use case of Distributed Denial of Service (DDoS) attack mitigation
based on open-source software solutions developed within GÉANT
These solutions are (i) RARE, which stands for Router for Academia, Research & Education and
(ii) FoD, which stands for Firewall on Demand
RARE involves solutions for Research & Education (R&E) use cases based on routing software platforms
RARE is developed under the GN5-1 project, in Work Package 6
FoD is a system and a GÉANT service that researches and develops methods
for effective mitigation of DDoS attacks
FoD is also included within the GN5-1 project, in Work Package 8
First, we will provide brief background on DDoS attacks
In these attacks, multiple Internet sources, e.g. various compromised Internet of Things (IoT) devices
flood victims with massive malicious traffic
The purpose of DDoS attacks is to deplete the available victim resources, which typically pertain to:
(i) exhausting system capabilities, such as the available processors and the total memory
and/or (ii) congesting the links leading to the victims
As a result, victims are unable to process legitimate traffic, which is eventually discarded
rendering major Internet services inaccessible to Internet users
This slide provides an overview of BGP FlowSpec
which is widely-used for DDoS attack mitigation
FlowSpec, which stands for Flow Specification
matches network traffic based on its flow characteristics
Such characteristics may involve
(i) source and destination IP addresses
(ii) source and destination ports
and/or (iii) the type of the protocol, such as TCP, UDP or ICMP
According to the specified action
matched packets may be entirely dropped, rate-limited
or redirected to another system for further inspection
Relying on BGP, FlowSpec rules can be propagated to upstream routers
This facilitates the distributed mitigation of DDoS attacks, possibly closer to the attack sources
where filtering of malicious traffic is usually more efficient
As depicted in the figure below
FlowSpec rules are typically introduced via BGP speakers
which peer with mitigation appliances (i.e. routers)
to install the necessary defense actions
A widely-used BGP speaker is ExaBGP
Firewall on Demand (FoD) relies on BGP FlowSpec for DDoS attack mitigation
FoD has the following main characteristics:
(i) in FoD, the users are those who trigger mitigation actions
users themselves may start, modify and stop the mitigation process
by introducing their own FlowSpec rules
(ii) FoD is multi-tenant and users may gain access based on eduGAIN
both a User Interface (UI) and a REST API are available in FoD
(iv) FoD leverages on ExaBGP to peer with routers and trigger DDoS attack mitigation
FoD is also used within GÉANT as a successful service for DDoS attack mitigation
Specifically, the FoD service instance enables attack mitigation within the GÉANT core
and enables administrators of NREN NOCs to trigger mitigation actions
without contacting the GÉANT NOC
The FoD service has been productive for more than 8 years
In this demonstration, we will simulate a DDoS attack using widely-used tools
and we will constrain it by relying on Firewall on Demand
The demo setup will include four components:
(i) "host1", which will be a host that generates malicious traffic
and "host2", which will be the target of the attack
The simulated DDoS attack will be an ICMP flood attack
which will be generated using "hping3", a commonly used traffic generator
The malicious traffic will be forwarded from "host1" to "host2" via the router
The router involves the RARE platform, which mainly relies on the freeRtr routing software
Specifically, apart from routing network traffic
the RARE platform will also export NetFlow data for further analysis
and filter traffic based on the installed BGP FlowSpec rules
Finally, the demo setup includes the FoD platform enhanced with custom Python scripts
The scripts analyze NetFlow data, detect attacks and instruct FoD to trigger attack mitigation
Aiming at providing a demo setup that can be easily replicated by interested viewers
we have automated the whole process by relying on Docker and Containerlab
While Docker is well-known, we will provide further information about Containerlab
Containerlab includes CLI tools that enable users to create and manage container-based networking labs
A major advantage of Containerlab is
that the networking details between the containers of the lab topology are automatically handled
Specifically, the starting point of Containerlab is the topology file
which contains general information about the lab as well as details about the container networking
While Containerlab supports various container management tools, e.g. Podman
our demonstration relies on Docker containers
The following slides describe the demo process
In the first step, the ICMP flood attack will be executed from "host1" against "host2"
As already mentioned, malicious traffic will be generated via the "hping3" traffic generator
which is a tool, widely used by DDoS attack researchers
In the second step, the NetFlow records will be exported from the freeRtr routing software
towards the Firewall on Demand instance, which is denoted as "fod" in this figure
In the third step, the NetFlow data will be analyzed based on custom scripts
in order to detect ongoing DDoS attacks
Subsequently, the appropriate filtering rules will be determined
In our demonstration, these rules will be mainly based on the attacker source IP address
In the fourth step
the ExaBGP software will propagate the appropriate mitigation rules to the router
based on BGP FlowSpec
Finally, the freeRtr software will drop malicious traffic from the attacker IP
thus the DDoS attack will be successfully mitigated
In case that you want to replicate our demo
you may follow the following 4 steps
First, you have to clone the appropriate repository
Then, you may easily deploy our demo setup in Containerlab
by simply typing the depicted "containerlab deploy" command
which automatically brings up the lab
by following the details included within the topology file
In the following, you need to execute a Python script that includes the appropriate commands
which will configure everything within the deployed Docker containers
Finally, you may verify that DDoS attack mitigation takes place
by executing the depicted "show" command within the RARE platform
Before proceeding with the demo
we would like to mention that you may contact the RARE team
by using the following mailing list
The first step of the demo will be to clone the repository
that contains the necessary files
In order to do that, we have to use the following command:
Now that the repository has been downloaded, we can inspect its contents
Here, we see the "topology.clab.yml" file
which includes the details pertaining to the lab topology
and the networking between the Docker containers
We also see the "setup.py" script, which will be used to configure the containers
Next, we see the "parser.py" script
which is used to retrieve NetFlow records,
analyze them, determine the appropriate FlowSpec rules
and install them to the freeRtr routing software
in order to enable DDoS attack mitigation
Finally, we have the "clab-fod-lab" directory which includes various details about the lab
Among them, the major ones pertain to the configuration files of the RARE platform
that we will see later
Now, we can delve into the details of the Containerlab topology file
The first thing that we see within this file
is the name of the lab that we are going to deploy
In this case, the name of the lab is "fod-lab"
Subsequently, we may see the definition of particular IPv4 and IPv6 subnets
Although Containerlab can define arbitrary networks to make things simpler
our demo requires the definition of a custom network
The reason behind this is that we want to have
a hardcoded management IP address for the freeRtr routing software
so that we can automate the whole setup via Python
This requires knowing the router management IP address a priori
Going on with the topology file, we may see the definition of the topology nodes
Here, we define four nodes
The first two nodes pertain to the demo hosts
and they are based on simple Linux Docker containers with the latest Ubuntu Operating System
The third node is the RARE platform node that is based on the freeRtr Docker image
We can see here that we have hardcoded the management IPv4 and IPv6 addresses for the router
Finally, the topology concludes with the FoD Docker container that exposes TCP port 8000
The last part of the topology file includes the specification of the links
i.e. the connections between the Docker containers
For example, we may see from the first definition that the "eth1" interface of "host1"
is connected to the "eth1" interface of the freeRtr container
We do not have to worry about other networking details
Containerlab will handle everything and establish the connections between the specified containers
Next, we would like to show the RARE platform configuration files
The freeRtr software requires two files to operate, a hardware file and a software file
By using Containerlab, we do not have to worry about the hardware file
because Containerlab will take care of the router interconnections
The software file is preconfigured with all the necessary details before the demo
and it will be loaded to the router once we deploy the topology
We can take a look at the software file
We can see that it mainly includes
FlowSpec configuration
interface configuration
here you may see the hardcoded management IP
BGP configuration
and NetFlow configuration
Now, we are going to deploy Containerlab using the following command:
You may see that the topology has been rapidly configured
The output of the command demonstrates the management IP address of the deployed containers
Although the router container has already been configured based on the preloaded file
we also have to configure the remaining Docker containers
To that end, we are going to run the "setup.py" Python script
If we take a look within the script
we can see that the package managers of all Docker containers are initially updated
In the following, we see that the necessary packages
are installed to the appropriate containers
These packages are related to "ifconfig", "ping" and "iproute2"
the latter of which will be used for static route configuration
Next, we see the configuration of static routes in "host1" and "host2" Docker containers
Afterwards, we install "hping3" at host1 which will be used to generate attack traffic
and "nfdump" at the “fod” Docker container
which will be used by our Python scripts to extract the collected NetFlow data
Another interesting point in this script is the command that we provide
to configure the ExaBGP Speaker, which can be seen here
Finally, we start the attack and then we use the "parser.py" Python script
to analyze the collected NetFlow records, detect traffic and
install the appropriate FlowSpec rules at the router
Now we can run the "setup.py" Python script to configure the containers
While the script is running, we can also open the "parser.py" Python script and see its contents
It is a simple script
The script retrieves NetFlow information over recent time windows
parses the command output
and finally uses a threshold-based approach
to detect an ongoing attack
and install the appropriate FlowSpec rule at the RARE platform
In our last step, we can connect to the RARE platform via Telnet
and inspect if the FlowSpec rule has been installed
and thus attack mitigation takes place
We can check this by issuing the following command
We can see that the output returns the default FlowSpec rule
as well as an additional one, which pertains to the attack mitigation
If we execute the command once again
we can see that the FlowSpec counters have been updated
according to the mitigated traffic