DTN-DoS is a collection of shell scripts for analyzing the effects of different variants of denial of service attacks on delay-tolerant networks.
Linux is the only supported operating system, the DTN-DoS most likely does not run on the Windows Subsystem for Linux.
We try to keep the setup as simple as possible.
- Clone the repository using
git clone https://github.com/tobinatore/dtn-dos.git - Switch to the newly created directory.
- In the directory run
$ ./setup_new.sh. This will configure your operating system and download / install ION-DTN and CORE. - Run
$ ./start.shthis will start the scenario picker.
This script installs two components on your system.
- CORE - A network emulation tool
- ION-DTN - A DTN implementation used by e.g. NASA
It also copies the included scenarios into the project directory of the CORE installation.
Starts the core daemon needed for running the network simulations and prompts the user to choose a scenario. When the user has chosen a valid scenario, the scripts starts core-gui in execution mode and the simulation gets run.
The script always downloads the most recent version of CORE and installs it on your system.
If you have Docker installed, the default iptable rules will block CORE traffic.
The script will download version 4.0.0 of ION-DTN from Sourceforge, so make sure you're connected to the internet.
We developed and tested the script on Ubuntu 20.04. It should work on different distributions, but that's untested.
The script might seem unresponsive during the installation of ION-DTN but it is most likely not. We've decided to not display the output of the ./configure, make and make install commands as to not clutter the terminal. Errors and warnings will still be displayed.
When you have chosen a scenario to run using the start.sh script, the core gui gets started, and the simulation runs. The setup of the scenarios in CORE is handled by setup scripts, so you don't have to do anything besides running the start.sh script and picking a scenario.
A simple scenario for testing ION commands. Topology:
┌─────O─────┐
│ 2 │
O O
1 3
The following services are being automatically started when this scenario is chosen:
- bping on node 1, pinging node 3 on the 3.1 enpoint from node 1's 1.2 endpoint
- bpecho on node 3, acknowledging incoming bundles on enpoint 3.1
When double clicking on a node in the CORE-GUI, a shell with root access will open on that specific node. You can run any ION command there for further testing.
As of now, there is no script visualizing the traffic between node 1 and node 3. It's most likely that there won't be one in the near future, as this is just a basic scenario for testing. You can run bpstats followed by tail ion.log to get an overview about how many bundles were sent / received.
A line by line overview of the output of bpstats:
- Number of bundles sourced (created) by this node. -> grouped by priority with a sum of all bundles at the end (this also applies for the following lines)
- Number of bundles forwarded by the node.
- Number of bundles that have been transmitted.
- Number of bundles that have been received.
- Number of bundles that have been delivered.
- Number of bundles that have been custody transferred.
- Number of bundles that have been reforwarded
- Number of bundles that expired.
A scenario simulating transmission from ground control to a satellite with a single attacker flooding the node connecting GC to the satellite with bundles. This effectively halts communication between GC and the satellite. Topology:
O────┐ O─┐
GRC │ ATK│
│ │
O─────O─────O
REL CON SAT
GRC = Ground Control, REL = Relay
ATK = Attacker, CON = Connecting node
SAT = Satellite
This scenario has a few automated services, which get started when the scenario is run via start_dtndos.sh:
- Bundle count visualization (bundlecount.sh and bundlewatch.sh) showing how many bundles are currently stored at each node.
- Bundle ping visualization, which shows the gradual drop in connectivity (and subsequent loss of connection) as ATK begins to flood CON.
- Unstable connection between SAT and CON, simulating connection loss every 30s for 30s. This forces a bundle buildup at CON. (After 3.5 minutes connection remains lost.)
The bundle ping visualization uses ION's watch characters, making it easy to track when bundles are sent out (signified by a single 'a' character in the terminal). When a ping gets through, the time it took gets printed as well. A few seconds after ATK starts the flooding attack, no more bundles from GRC get through to SAT and the output of the bping visualization will just be a long line of "a"'s.
A scenario simulating transmission from ground control to a satellite with multiple attackers flooding the node connecting GC to the satellite with bundles. This effectively halts communication between GC and the satellite. Topology:
ATK
O
O─┼─O
ATK│ATK
O────┐ O─┼─O
GRC │ ATK│ATK
│ │
O─────O─────O
REL CON SAT
GRC = Ground Control, REL = Relay
ATK = Attacker, CON = Connecting node
SAT = Satellite
The outcome is pretty much the same as in the Flooding Scenario, however after a while bundles start to pile up on the attacking nodes, so it seems that ION either slows down spammy connections or can't handle the massive influx of bundles.
A scenario simulating transmission from a monitoring system (e.g. a tsunami warning buoy) to a control center via satellite. A single attacker targets the satellite with a slowloris attack, trying to stop communication between monitoring system and control center. Topology:
SAT
O───────O──┐
MON │ │
│ └─O───O
O──┘ CTL EWS
ATK
EWS = Emergency warning system, MON = Monitoring system
ATK = Attacker, CTL = Control center
SAT = Satellite
Slowloris is an exceptionally effective attack, stopping traffic from MON to CTL almost instantly. It works by opening a huge amount of TCP connections from ATK to SAT and holding them open for as long as possible, exhausting SAT's resources and thus denying MON and CTL the opportunity of opening connections themselves. Another important point is that the attack doesn't use many resources either.
More coming soon, still in development!