added writeup on the experiment setup

README.md

@@ -0,0 +1,102 @@
+# Revealing Guard Nodes via Traffic Induced Watermarking
+
+Revealing the primary guard node used by a party within the
+TOR network can be a significant step in a deanononimization
+attack. This proposed attack attempts to detect the primary
+guard node of a client connecting to a malicious server through
+the TOR network. The attacker attempts to induce high traffic
+volumes on potential guard nodes to watermark traffic forwarded by
+them and then attempts to recognize these watermarks later in
+traffic received from the exit node.
+
+![](attack.svg)
+
+## Experiment Setup
+
+The first experiments purpose is to see, whether recognizable
+watermarks can be introduced into traffic just by controlling
+the load on the guard node. We deploy a network of one victim,
+one private guard node and one malicious server. The victim
+frequently (in 10 second intervals) accesses the server through
+the TOR network, using the private guard node as the first
+component of its circuit. In this first experiment, the guard
+node is known to the server, allowing us to test different
+mechanisms of introducing traffic patterns.
+
+### Network Structure Details
+
+All parties in this experiment are part of one virtual private
+network `10.2.0.0/24`. The network consists of three main
+components as well as an arbitrary number of members running
+experiments.
+
+**Victim**
+
+The victim's IP is `10.2.0.2`. It constructs a circuit with
+the guard node `10.2.0.3` and two random TOR relays and then
+accesses the website `rsca.vanrissenbeck.com` every 10 seconds.
+
+**Guard Node**
+
+The guard node's IP is `10.2.0.3`. It's used by the victim
+as well as by the attacker when attempting to increase the
+traffic load. The guard node is not publicly reachable by
+the TOR network.
+
+**Proxy**
+
+The proxy is the one publicly reachable component of this network.
+It has to be public, because otherwise the exit node which is not
+controlled by us wouldn't be able to reach the malicious service.
+Its internal IP is `10.2.0.4`. Requests to `rsca.vanrissenbeck.com`
+are redirected by a caddy instance running in the Oracle cloud
+to port 8080. To test out a certain attack strategy, port 8080
+of the proxy is further forwarded to a server hosting the actual
+malicious site. This allows researchers to spin up any kind of
+application serving the malicious website independent of the
+network infrastructure (see setup instructions below).
+
+![](architecture.svg)
+
+### Setup Instructions
+
+Experimenting with this network is rather simple: First, you'll
+have to become part of the `10.2.0.0/24` network. I'll send you
+a WireGuard config on request. To install WireGuard, run
+```
+sudo apt install wireguard-tools
+```
+or an equivalent command for your distro. Then install the
+configuration I've sent to you by running
+```
+# replace N with the lowest non-negative integer
+# so that you don't overwrite existing configs
+sudo cp wg-rsca.conf /etc/wireguard/wgN.conf
+```
+and finally boot up the VPN
+```
+sudo wg-quick up wgN
+```
+You can test the configuration by sending a ping
+to `10.2.0.1`.
+
+
+Next you'll have to develop some malicious HTTP service.
+For testing purposes, this could be an instance of python's
+`http.server` module. Run your service, e.g.
+```
+python3 -m http.server 1337
+```
+Finally, you'll make the service publicly available, by
+forwarding port 8080 of the proxy to port 1337 on your
+local device using ssh reverse port forwarding. This
+can be achieved by running
+```
+ssh -NR 8080:127.0.0.1:1337 anon@10.2.0.4
+```
+The password is `rsca2025nA4g1A`. Your malicious HTTP
+service should be publicly visible under the domain
+`rsca.vanrissenbeck.com` and receive requests by the victim
+through the TOR network about every 10 seconds. If you
+used the `http.server` example, a directory listing should
+be visible on that domain.