Content

acronyms.tex

@@ -1,58 +1,53 @@
 \DeclareAcronym{html}{
   short = {HTML},
-  long  = {hyper text markup language}
+  long  = {Hyper Text Markup Language}
 }
 
 \DeclareAcronym{p2p}{
   short = {P2P},
-  long = {peer-to-peer}
+  long = {Peer-to-Peer}
 }
 
 \DeclareAcronym{c2}{
   short = {C2},
-  long  = {command and control}
+  long  = {Command and Control}
 }
 
 \DeclareAcronym{irc}{
   short = {IRC},
-  long  = {internet relay chat}
+  long  = {Internet Relay Chat}
-}
-
-\DeclareAcronym{http}{
-  short = {HTTP},
-  long  = {hypertext transfer protocol}
 }
 
 \DeclareAcronym{ddos}{
   short = {DDoS},
-  long  = {distributed denial of service}
+  long  = {Distributed Denial of Service}
 }
 
 \DeclareAcronym{dga}{
   short = {DGA},
-  long  = {domain generation algorithm}
+  long  = {Domain Generation Algorithm}
 }
 
 \DeclareAcronym{dns}{
   short = {DNS},
-  long  = {domain name system}
+  long  = {Domain Name System}
 }
 
 \DeclareAcronym{iot}{
   short = {IoT},
-  long  = {internet of things}
+  long  = {Internet of Things}
 }
 
 \DeclareAcronym{isp}{
   short = {ISP},
-  long  = {internet service provider}
+  long  = {Internet Service Provider}
 }
 
 \DeclareAcronym{spof}{
-  short = {SPOF},
+  short = {SPoF},
-  long  = {single point of failure},
+  long  = {Single Point of Failure},
-  short-plural-form = {SPOF},
+  short-plural-form = {SPoF},
-  long-plural-form  = {single points of failure},
+  long-plural-form  = {Single Points of Failure},
 }
 
 \DeclareAcronym{bms}{
@@ -77,7 +72,7 @@
 
 \DeclareAcronym{grpc}{
   short = {gRPC},
-  long  = {gRPC remote procedure call}
+  long  = {gRPC Remote Procedure Call}
 }
 
 \DeclareAcronym{nat}{

bibliography.bib

@@ -411,4 +411,41 @@
   file = {Full Text:/home/me/Zotero/storage/UGX3MEA7/Böck et al. - 2018 - Next Generation P2P Botnets Monitoring Under Adve.pdf:application/pdf}
 }
 
+@incollection{bib:carnaNetworkTelescope2014,
+  location = {Cham},
+  title = {The Carna Botnet Through the Lens of a Network Telescope},
+  volume = {8352},
+  isbn = {978-3-319-05301-1 978-3-319-05302-8},
+  url = {http://link.springer.com/10.1007/978-3-319-05302-8\_26},
+  pages = {426--441},
+  booktitle = {Foundations and Practice of Security},
+  publisher = {Springer International Publishing},
+  author = {Le Malécot, Erwan and Inoue, Daisuke},
+  editor = {Danger, Jean Luc and Debbabi, Mourad and Marion, Jean-Yves and Garcia-Alfaro, Joaquin and Zincir Heywood, Nur},
+  urldate = {2022-04-16},
+  date = {2014},
+  doi = {10.1007/978-3-319-05302-8_26},
+  note = {Series Title: Lecture Notes in Computer Science}
+}
+
+@incollection{bib:kademlia2002,
+  location = {Berlin, Heidelberg},
+  title = {Kademlia: A Peer-to-Peer Information System Based on the {XOR} Metric},
+  volume = {2429},
+  isbn = {978-3-540-44179-3 978-3-540-45748-0},
+  url = {http://link.springer.com/10.1007/3-540-45748-8_5},
+  shorttitle = {Kademlia},
+  pages = {53--65},
+  booktitle = {Peer-to-Peer Systems},
+  publisher = {Springer Berlin Heidelberg},
+  author = {Maymounkov, Petar and Mazières, David},
+  editor = {Druschel, Peter and Kaashoek, Frans and Rowstron, Antony},
+  editorb = {Goos, Gerhard and Hartmanis, Juris and van Leeuwen, Jan},
+  editorbtype = {redactor},
+  urldate = {2022-04-16},
+  date = {2002},
+  doi = {10.1007/3-540-45748-8_5},
+  note = {Series Title: Lecture Notes in Computer Science}
+}
+
 /* vim: set filetype=bib ts=2 sw=2 tw=0 et :*/

codes/variance.py

@@ -0,0 +1,51 @@
+#!/usr/bin/env python3
+
+from math import sqrt
+# from itertools import islice
+
+def variance(xs):
+    n = len(xs)
+    mu = sum(xs) / n
+    # mu = 265.8
+    # print(sum(map(lambda x: (x - mu)**2, xs)))
+    s = sum(map(lambda x: (x - mu)**2, xs))
+    var = s / n
+    deriv = sqrt(var)
+    # var = sqrt( / len(xs))
+
+    print('\\begin{align*}')
+    print(f'  n &= {n} \\\\')
+    print(f'  \\mu &= \\frac{{{sum(xs)}}}{{n}} = {mu:.1f} \\\\')
+    print(f'  s &= \\sum\\limits_{{i=1}}^{{n}} {{(x_i - \\mu)}}^2 \\\\')
+    # print [mylist[i:i+4] ]
+    first = True
+    for i in range(0, n, 3):
+        symbol = '=' if first else '+'
+        l = xs[i:i+3]
+        a = ' + '.join(map(lambda x: f'{{({x} - {mu:.1f})}}^2', l))
+        first = False
+        print(f'    &{symbol} {a} \\\\')
+
+    print(f'    &= {s:.1f} \\\\')
+
+    # a = ' + '.join(map(lambda x: f'({x} - {mu})^2', xs))
+    print(f'  \\sigma^2 &= \\frac{{s}}{{n}} = {var:.1f} \\\\')
+    print(f'  \\sigma &= \\sqrt{{\\sigma^2}} = {deriv:.1f}')
+    print('\\end{align*}')
+
+    print()
+    print()
+    print()
+    print()
+
+  # \mu &= 1595 / 4 = 398.75 \\
+  # \sigma &= \sqrt{\frac{(403 - 398.75)^2 + (369 - 398.75)^2 + (405 - 398.75)^2 + (418 - 398.75)^2}{4}} = 10.5
+
+def main():
+    # for xs in [[808, 787], [403, 369, 405, 418], [258, 273, 257, 264, 293, 250], [140, 175, 186, 166, 159, 152, 172, 148, 151, 146]]:
+    # for xs in [[258, 273, 257, 264, 293, 250]]:
+    for xs in [[499322, 500678], [249504, 250451, 249818, 250227], [166430, 166861, 166269, 166937, 166623, 166880], [100424, 99650, 99307, 100305, 99403, 100562, 100277, 99875, 99911, 100286]]:
+        variance(xs)
+
+if __name__ == '__main__':
+    main()

content.tex

@@ -16,7 +16,7 @@ We use the Internet to communicate, shop, handle financial transactions, and muc
 Many personal and professional workflows are so dependent on the Internet, that they won't work when being offline, and with the pandemic we are living through, this dependency grew even stronger.
 
 
-In 2021 there were around 10 billion Internet connected \ac{iot} devices and this number is estimated to more than double over the next years up to 25 billion in 2030~\cite{bib:statista_iot_2020}.
+In 2021, there were around 10 billion Internet connected \ac{iot} devices and this number is estimated to more than double over the next years up to 25 billion in 2030~\cite{bib:statista_iot_2020}.
 Many of these devices run on outdated software, don't receive regular updates, and don't follow general security best practices.
 While in 2016 only \SI{77}{\percent} of German households had a broadband connection with a bandwidth of \SI{50}{\mega\bit\per\second} or more, in 2020 it was already \SI{95}{\percent} with more than \SI{50}{\mega\bit\per\second} and \SI{59}{\percent} with at least \SI{1000}{\mega\bit\per\second}~\cite{bib:statista_broadband_2021}.
 Their nature as small, always online devices---often without any direct user interaction---behind Internet connections that are getting faster and faster makes them a desirable target for botnet operators.
@@ -29,26 +29,26 @@ In recent years, \ac{iot} botnets have been responsible for some of the biggest
 
 Botnets consist of infected computers, so called \emph{bots}, controlled by a \emph{botmaster}.
 \emph{Centralized} and \emph{decentralized botnets} use one or more coordinating hosts, called \emph{\ac{c2} servers}, respectively.
-These \ac{c2} servers can use any protocol from \ac{irc} over \ac{http} to Twitter~\cite{bib:pantic_covert_2015} as communication channel with the infected hosts.
+These \ac{c2} servers can use any protocol from \ac{irc} over HTTP to Twitter~\cite{bib:pantic_covert_2015} as communication channel with the infected hosts.
 The abuse of infected systems includes several activities---\ac{ddos} attacks, banking fraud, proxies to hide the attacker's identity, sending of spam emails, just to name a few.
 
 Analyzing and shutting down a centralized or decentralized botnet is comparatively easy since the central means of communication (the \ac{c2} IP addresses or domain names, Twitter handles or \ac{irc} channels), can be extracted from the malicious binaries or determined by analyzing network traffic and can therefore be considered publicly known.
 
 A coordinated operation with help from law enforcement, hosting providers, domain registrars, and platform providers could shut down or take over the operation by changing how requests are routed or simply shutting down the controlling servers/accounts.
 
-To complicate take-down attempts, botnet operators came up with a number of ideas: \acp{dga} use pseudorandomly generated domain names to render simple domain blacklist-based approaches ineffective~\cite{bib:antonakakis_dga_2012} or fast-flux \ac{dns}, where a large pool of IP addresses is assigned randomly to the \ac{c2} domains to prevent IP based blacklisting~\cite{bib:nazario_as_2008}.
+To complicate take-down attempts, botnet operators came up with a number of ideas: \acp{dga} use pseudorandomly generated domain names to render simple domain blacklist-based approaches ineffective~\cite{bib:antonakakis_dga_2012} or fast-flux \ac{dns} entries, where a large pool of IP addresses is randomly assigned to the \ac{c2} domains to prevent IP based blacklisting and hide the actual \ac{c2} servers~\cite{bib:nazario_as_2008}.
 
 %{{{ fig:c2vsp2p
 \begin{figure}[h]
 \centering
 \begin{subfigure}[b]{.5\textwidth}
   \centering
-  \includegraphics[width=1\linewidth]{c2.drawio.pdf}
+  \includegraphics[width=.9\linewidth]{c2.drawio.pdf}
   \caption{Topology of a \ac{c2} controlled botnet}\label{fig:c2}
 \end{subfigure}%
 \begin{subfigure}[b]{.5\textwidth}
   \centering
-  \includegraphics[width=1\linewidth]{p2p.drawio.pdf}
+  \includegraphics[width=.9\linewidth]{p2p.drawio.pdf}
   \caption{Topology of a \ac{p2p} botnet}\label{fig:p2p}
 \end{subfigure}%
 \caption{Communication paths in different types of botnets}\label{fig:c2vsp2p}
@@ -58,9 +58,9 @@ To complicate take-down attempts, botnet operators came up with a number of idea
 A number of botnet operations were shut down like this~\cite{bib:nadji_beheading_2013} and as the defenders upped their game, so did attackers---the concept of \ac{p2p} botnets emerged.
 The idea is to build a distributed network without \acp{spof} in the form of \ac{c2} servers as shown in \Fref{fig:p2p}.
 In a \ac{p2p} botnet, each node in the network knows a number of its neighbors and connects to those. Each of these neighbors has a list of neighbors on its own, and so on.
-The botmaster only needs to join the network to send new commands or receive stolen data.
+The botmaster only needs to join the network to send new commands or receive stolen data but there is no need for a coordinating host, that is always connected to the network.
 Any of the nodes in \Fref{fig:p2p} could be the botmaster but they don't even have to be online all the time since the peers will stay connected autonomously.
-In fact there have been arrests of operators of \ac{p2p} botnets but due to the autonomy offered by the distributed approach, the botnet keeps communicating~\cite{bib:netlab_mozi}.
+In fact, there have been arrests of \ac{p2p} botnet operators but due to the autonomy offered by the distributed approach, the botnet keeps intact and continues operating~\cite{bib:netlab_mozi}.
 Especially worm-like botnets, where each peer tries to find and infect other systems, can keep lingering for many years.
 
 This lack of a \ac{spof} makes \ac{p2p} botnets more resilient to take-down attempts since the communication is not stopped and botmasters can easily rejoin the network and send commands.
@@ -71,16 +71,17 @@ This knowledge can be obtained by monitoring peer activity in the botnet.
 Bots in a \ac{p2p} botnet can be split into two distinct groups according to their reachability: peers that are not publicly reachable (\eg{} because they are behind a \ac{nat} router or firewall) and those, that are publicly reachable, also known as \emph{superpeers}.
 In contrast to centralized botnets with a fixed set of \ac{c2} servers, in a \ac{p2p} botnet, every superpeer might take the roll of a \ac{c2} server and \emph{non-superpeers} will connect to those superpeers when joining the network.
 
-As there is no well known server in a \ac{p2p} botnet, they have to coordinate autonomously.
+As there is no well-known server in a \ac{p2p} botnet, they have to coordinate autonomously.
 This is achieved by connecting the bots among each other.
 Bot \textit{B} is considered a \emph{neighbor} of bot \textit{A}, if \textit{A} knows and connects to \textit{B}.
-Since bots can become unavailable, they have to permanently update their neighbor lists to avoid losing their connection into the botnet.
+Since bots can become unavailable, they have to consistently update their neighbor lists to avoid losing their connection into the botnet.
 This is achieved by periodically querying their neighbor's neighbors.
 This process is known as \emph{\ac{mm}}.
 
-\Ac{mm} comes in two forms: structured and unstructured~\cite{bib:baileyNextGen}\todo{explain structured and unstructured}.
+\Ac{mm} can be distinguished into two categories: \emph{structured} and \emph{unstructured}~\cite{bib:baileyNextGen}
-Structured \ac{p2p} botnets often use a \ac{dht} and strict rules for a bot's neighbors based on its unique ID.
+Structured \ac{p2p} botnets have strict rules for a bot's neighbors based on its unique ID and often use a \ac{dht}, which allows persisting data in a distributed network.
-In unstructured botnets on the other hand, bots ask any peer they know for new peers to connect to, in a process called \emph{peer discovery}.
+The \ac{dht} could contain a ordered ring structure of IDs and neighborhood in the structure also means neighborhood in the network, as is the case in the Kademila botnet~\cite{bib:kademlia2002}.
+In botnets that employ unstructured \ac{mm} on the other hand, bots ask any peer they know for new peers to connect to, in a process called \emph{peer discovery}.
 To enable peers to connect to unstructured botnets, the malware binaries include hardcoded lists of superpeers for the newly infected systems to connect to.
 
 The concept of \emph{churn} describes when a bot becomes unavailable.
@@ -88,7 +89,7 @@ There are two types of churn:
 
 \begin{itemize}
 
-  \item \emph{IP churn}: A bot becomes unreachable because it got assigned a new IP address. The bot is still available but under another address.
+  \item \emph{IP churn}: A bot becomes unreachable because it got assigned a new IP address. The bot is still available but under another IP address.
 
   \item \emph{Device churn}: The device is actually offline, \eg{} because the infection was cleaned, it got shut down or lost its Internet connection.
 
@@ -104,21 +105,21 @@ A \ac{p2p} botnet can be modelled as a digraph
 G &= (V, E)
 \end{align*}
 
-With the set of vertices \(V\) describing the peers in the network and the set of edges \(E\) describing the communication flow between bots.
+With the set of nodes \(V\) describing the peers in the network and the set of edges \(E\) describing the communication flow between bots.
 
-\(G\) is not required to be a connected graph but might consist of multiple disjoint components~\cite{bib:rossow_sok_2013}. Components consisting of peers, that are infected by the same bot, are considered part of the same graph.
+\(G\) is not required to be a connected graph but might consist of multiple disjoint components~\cite{bib:rossow_sok_2013}. Components consisting of peers, that are infected by the same malware, are considered part of the same graph.
 
-For a bot \(v \in V\), the \emph{predecessors} (neighbors) \(\text{pred}(v)\) and \emph{successors} \(\text{succ}(v)\) are defined as:
+For a bot \(v \in V\), the \emph{predecessors} \(\text{pred}(v)\) and \emph{successors} (neighbors) \(\text{succ}(v)\) are defined as:
 
 \begin{align*}
-  \text{succ}(v) &= \{ u \in V \mid (u, v) \in E \} \\
+  \text{succ}(v) &= \{ u \in V \mid (v, u) \in E \} \\
-  \text{pred}(v) &= \{ u \in V \mid (v, u) \in E \}
+  \text{pred}(v) &= \{ u \in V \mid (u, v) \in E \}
 \end{align*}
 
-The set of edges \(\text{pred}(v)\) is also called the \emph{peer list} of \(v\).
+The set of nodes \(\text{succ}(v)\) is also called the \emph{peer list} of \(v\).
 Those are the nodes, a peer will connect to, to request new commands and other peers.
 
-For a vertex \(v \in V\), the in and out degree \(\deg^{+}\) and \(\deg^{-}\) describe how many bots know \(v\) or are known by \(v\) respectively.
+For a node \(v \in V\), the in and out degree \(\deg^{+}\) and \(\deg^{-}\) describe how many bots know \(v\) or are known by \(v\) respectively.
 
 \begin{align*}
   \deg^{+}(v) &= \abs{\text{pred}(v)} \\
@@ -137,12 +138,12 @@ There are two distinct methods to map and get an overview of the network topolog
 %{{{ passive detection
 \subsubsection{Passive Monitoring}
 
-For passive detection, traffic flows are analysed in large amounts of collected network traffic (\eg{} from \acp{isp}).
+For passive detection, traffic flows in large amounts of collected network traffic often obtained from \acp{isp} or network telescopes~\cite{bib:carnaNetworkTelescope2014} are analysed.
-This has some advantages in that it is not possible for botmasters to detect or prevent data collection of that kind, but it is not trivial to distinguish valid \ac{p2p} application traffic (\eg{} BitTorrent, Skype, cryptocurrencies, \ldots) from \ac{p2p} bots.
+This has some advantages: \eg{} it is not possible for botmasters to detect or prevent data collection of that kind, though it is not trivial to distinguish valid \ac{p2p} application traffic (\eg{} BitTorrent, Skype, cryptocurrencies, \ldots) from \ac{p2p} bots.
 \citeauthor{bib:zhang_building_2014} propose a system of statistical analysis to solve some of these problems in~\cite{bib:zhang_building_2014}.
 Also getting access to the required datasets might not be possible for everyone.
 
-As most botnet detection mechanisms, also the passive ones work by building communication graphs and finding tightly coupled subgraphs that might be indicative of a botnet~\cite{bib:botgrep2010}. An advantage of passive detection is, that it is independent of protocol details, specific binaries or the structure of the network (\ac{p2p} vs.\ centralized/decentralized)~\cite{bib:botminer2008}.
+As most botnet detection mechanisms, also the passive ones work by building communication graphs and finding tightly coupled subgraphs that might be indicative of a botnet~\cite{bib:botgrep2010}. An advantage of passive detection is, that it is independent of protocol details, specific binaries, or the structure of the network (\ac{p2p} vs.\ centralized/decentralized)~\cite{bib:botminer2008}.
 
 \begin{itemize}
 
@@ -153,14 +154,14 @@ As most botnet detection mechanisms, also the passive ones work by building comm
 \end{itemize}
 \todo{no context}
 
-Passive monitoring is only mentioned for completeness and not a topic for this thesis.
+Passive monitoring is only mentioned for completeness and not further discussed in this thesis.
 
 %}}} passive detection
 
 %{{{ active detection
 \subsubsection{Active Monitoring}
 
-For active detection, a subset of the botnet protocol and behavior is reimplemented to take part in the network.
+For active detection, a subset of the botnet protocol and behavior is reimplemented to participate in the network.
 To do so, samples of the malware are reverse engineered to unterstand and recreate the protocol.
 This partial implementation includes the communication part of the botnet but ignores the malicious functionality as to not support and take part in illicit activity.
 % The difference in behaviour from the reference implementation and conspicuous graph properties (\eg{} high \(\deg^{+}\) vs.\ low \(\deg^{-}\)) of these sensors allows botmasters to detect and block the sensor nodes.
@@ -172,22 +173,23 @@ To accurately monitor a \ac{p2p} botnet, a hybrid approach of crawlers and senso
 A crawler starts with a predefined list of known bots, connects to those and uses the peer exchange mechanism to request other bots.
 Each found bot is crawled again, slowly building the graph of superpeers on the way.
 Every entry \textit{E} in the peer exchange response received from bot \textit{A} represents an edge from \textit{A} to \textit{E} in the graph.
+\citetitle{bib:andriesse_reliable_2015} describes disinformation attacks, in which bots will include invalid entries in their peer list replies~\cite{bib:andriesse_reliable_2015}.
+Therefore, edges should only be considered valid, if at least one crawler or sensor was able to contact or contacted by peer \textit{E}, thereby confirming, that \textit{E} is an existing participant in the botnet.
 
 A sensor implements the passive part of the botnet's \ac{mm}.
-They cannot be used to create the botnet graph (only edges into the sensor node) but are the only way to enumerate the whole network.
+They cannot be used to create the botnet graph (only edges into the sensor node) or find new peers, but are required to enumerate the whole network, including non-superpeers.
 
 %}}} active detection
 
 %{{{ monitoring prevention
-\subsubsection{Monitoring Prevention Techniques}
+\subsubsection{Anti-Monitoring Techniques}
-\todo{good title}
 
 The constantly growing damage produced by botnets has many researchers and law enforcement agencies trying to shut down these operations~\cite{bib:nadji_beheading_2013, bib:nadji_still_2017, bib:dittrich_takeover_2012, bib:fbiTakedown2014}.
 The monetary value of these botnets directly correlates with the amount of effort botmasters are willing to put into implementing defense mechanisms against take-down attempts.
 
-Some of these countermeasures are explored by \citeauthor{bib:andriesse_reliable_2015} in \citetitle{bib:andriesse_reliable_2015} and include deterrence, which limits the number of allowed bots per IP address or subnet to 1; blacklisting, where known crawlers and sensors are blocked from communicating with other bots in the network (mostly IP based); disinformation, when fake bots are placed in the peer lists, which invalidates the data collected by crawlers; and active retaliation like \ac{ddos} attacks against sensors or crawlers~\cite{bib:andriesse_reliable_2015}.
+Some of these countermeasures are explored by \citeauthor{bib:andriesse_reliable_2015} in \citetitle{bib:andriesse_reliable_2015} and include deterrence, which limits the number of bots per IP address or subnet; blacklisting, where known crawlers and sensors are blocked from communicating with other bots in the network (mostly IP based); disinformation, when fake bots are placed in the peer lists, to invalidate the data collected by crawlers; and active retaliation like \ac{ddos} attacks against sensors or crawlers~\cite{bib:andriesse_reliable_2015}.
 
-In this work we try to find ways to make the monitoring and information gathering phase more efficient and resilient to detection.
+In this work, we try to find ways to make the monitoring and information gathering phase more efficient and resilient to detection.
 
 %}}} monitoring prevention
 
@@ -216,16 +218,17 @@ The implementation of the concepts of this work will be done as part of \ac{bms}
 \footnotetext{\url{https://github.com/Telecooperation/BMS}}
 \Ac{bms} is intended for a hybrid active approach of crawlers and sensors (reimplementations of the \ac{p2p} protocol of a botnet, that won't perform malicious actions) to collect live data from active botnets.
 
-In an earlier project, we implemented different node ranking algorithms (among others \emph{PageRank}~\cite{bib:page_pagerank_1998}) to detect sensor candidates in a botnet, as described in \citetitle{bib:karuppayah_sensorbuster_2017}.
+In an earlier project, we implemented different node ranking algorithms---among others \emph{PageRank}~\cite{bib:page_pagerank_1998} and \emph{SensorRank}---to detect sensor candidates in a botnet, as described in \citetitle{bib:karuppayah_sensorbuster_2017}.
-Both ranking algorithms exploit the differences in \(\deg^+\) and \(\deg^-\) for sensors to weight the nodes.
+Both ranking algorithms exploit the differences in a sensor's or crawler's \(\deg^+\) and \(\deg^-\) to weight the nodes.
-Another way to enumerate candidates for sensors in a \ac{p2p} botnet is to find \acp{wcc} in the graph.
 Sensors will have few to none outgoing edges, since they don't participate actively in the botnet, while crawlers have only outgoing edges.
+Another way to enumerate candidates for sensors in a \ac{p2p} botnet is to find \acp{wcc} in the graph.
+\citeauthor{bib:karuppayah_sensorbuster_2017} call this method \emph{SensorBuster}.
 
-The goal of this work is to complicate detection mechanisms like this for botmasters by centralizing the coordination of the system's crawlers and sensors, thereby reducing the node's rank for specific graph metrics.
+The goal of this work is to complicate detection mechanisms like this for botmasters by coordinating the work of the system's crawlers and sensors, thereby reducing the node's rank for specific graph metrics.
 The coordinated work distribution also helps in efficiently monitoring large botnets where one crawler is not enough to track all peers.
-The changes should allow the current crawlers and sensors to use the new abstraction with as few changes as possible to the existing code.
+The changes should allow the current \ac{bms} crawlers and sensors to use the new abstraction with as few changes as possible to the existing code.
 
-The goal of this work is to show how cooperative monitoring of a \ac{p2p} botnet can help with the following problems:
+We will explore how cooperative monitoring of a \ac{p2p} botnet can help with the following problems:
 
 \begin{itemize}
   \item Impede detection of monitoring attempts by reducing the impact of aforementioned graph metrics
@@ -235,13 +238,13 @@ The goal of this work is to show how cooperative monitoring of a \ac{p2p} botnet
   \item Make crawling more efficient
 \end{itemize}
 
-The final results should be as general as possible and not depend on any botnet's specific behaviour (except for the mentioned anti-monitoring techniques which might be unique to some botnets), but we assume, that every \ac{p2p} botnet has some way of determining a bot's neighbors.
+The final results should be as general as possible and not depend on any botnet's specific behaviour (except for the mentioned anti-monitoring techniques which might be unique to some botnets), but we assume, that every \ac{p2p} botnet has some way of querying a bot's neighbors for the concept of crawlers and sensors to be applicable.
 
 In the current implementation, each crawler will itself visit and monitor each new node it finds.
-The general idea for the implementation of the ideas in this thesis is to report newfound nodes back to the \ac{bms} backend first, where the graph of the known network is created, and a fitting worker is selected to achieve the goal of the according coordination strategy.
+The general idea for the implementation of the concepts in this thesis is to report newfound nodes back to the \ac{bms} backend first, where the graph of the known network is created, and a fitting worker is selected to achieve the goal of the according coordination strategy.
 That worker will be responsible to monitor the new node.
 
-If it is not possible, to select a specific sensor so that the monitoring activity stays inconspicuous, the coordinator can do a complete shuffle of all nodes between the sensors to restore the wanted graph properties or warn if more sensors are required to stay undetected.
+If it is not possible, to select a sensor so that the monitoring activity stays inconspicuous, the coordinator can do a complete shuffle of all nodes between the sensors to restore the wanted graph properties or warn if more sensors are required to fulfill the goal defined by the strategy.
 
 The improved crawler system should allow new crawlers to register themselves and their capabilities (\eg{} bandwidth, geolocation), so the amount of work can be scaled accordingly between hosts.
 
@@ -254,7 +257,7 @@ The coordination protocol must allow the following operations:
 
 \begin{description}
 
-  \item[Register Worker] Register a new worker with capabilities (which botnet, available bandwidth and processing power, \dots{}).
+  \item[Register Worker] Register a new worker with capabilities (which botnet, available bandwidth and processing power, if it is a crawler or sensor, \dots{}).
     This is called periodically and used to determine which worker is still active, when assigning new tasks.
 
   \item[Report Peer] Report found peers.
@@ -310,7 +313,7 @@ The protocol primitives described in \Fref{sec:protPrim} already allow for this
 \subsection{Load Balancing}\label{sec:loadBalancing}
 
 Depending on a botnet's size, a single crawler is not enough to monitor all superpeers.
-While it is possible to run multiple, uncoordinated crawlers, multiple crawlers can find and monitor the same peer, making the approach inefficient with regard to the computing resources at hand.
+While it is possible to run multiple, uncoordinated crawlers, two or more of them can find and monitor the same peer, making the approach inefficient with regard to the computing resources at hand.
 
 The load balancing strategy solves this problem by systematically splitting the crawl tasks into chunks and distributes them among the available crawlers.
 The following load balancing strategies will be investigated:
@@ -338,7 +341,7 @@ With \(G\) being the greatest common divisor of all the crawler's capabilities,
 % The mapping \mintinline{go}{gcd(C)} is the greatest common divisor of all peers in \mintinline{go}{C}, \(\text{maxWeight}(C) = \max \{ \forall c \in C : W(c) \}\).
 The algorithm in \Fref{lst:wrr} distributes the work according to the crawler's capabilities.
 
-\begin{listing}
+\begin{listing}[H]
 \begin{minted}{go}
 func WeightCrawlers(crawlers ...Crawler) map[string]uint {
   weights := []int{}
@@ -381,14 +384,13 @@ The set of crawlers \(\{a, b, c\}\) with the capabilities \(cap(a) = 3\), \(cap(
 
 
 \subsubsection{IP-based Partitioning}\label{sec:ipPart}
-\todo{don't use substrings, bit.int for 128 bit modulo, argumentation why this works}
 
-The output of cryptographic hash functions is uniformly distributed---even substrings of the calculated hash hold this property.
+The output of cryptographic hash functions is uniformly distributed.
-Calculating the hash of an IP address and distributing the work with regard to \(H(\text{IP}) \mod \abs{C}\) creates about evenly sized buckets for each worker to handle.
+Given the hash function \(H\), calculating the hash of an IP address and distributing the work with regard to \(H(\text{IP}) \mod \abs{C}\) creates about evenly sized buckets for each worker to handle.
-For any hash function \(H\), this gives us the mapping \(m(i) = H(i) \mod \abs{C}\) to sort peers into buckets.
+This gives us the mapping \(m(i) = H(i) \mod \abs{C}\) to sort peers into buckets.
 
 Any hash function can be used but since it must be calculated often, a fast function should be used.
-While the \ac{md5} hash function must be considered broken for cryptographic use~\cite{bib:stevensCollision}, it is faster to calculate than hash functions with longer output.
+While the \ac{md5} hash function must be considered broken for cryptographic use~\cite{bib:stevensCollision}, it is faster to calculate than hash functions with longer output.\todo{md5 crypto broken, distribution not?}
 For the use case at hand, only the uniform distribution property is required so \ac{md5} can be used without scarifying any kind of security.
 
 This strategy can also be weighted using the crawlers capabilities by modifying the list of available workers so that a worker can appear multiple times according to its weight.
@@ -405,7 +407,7 @@ The weighting algorithm from \Fref{lst:wrr} is used to create the weighted multi
 The Go standard library includes helpers for arbitrarily sized integers\footnote{\url{https://pkg.go.dev/math/big\#Int}}.
 This helps us in implementing the mapping \(m\) from above.
 
-By exploiting the even distribution offered by hashing, the work of each crawler is also about evenly distributed over all IP subnets, \ac{as} and geolocations.
+By exploiting the even distribution offered by hashing, the work of each crawler is also about evenly distributed over all IP subnets, \acp{as} and geolocations.
 This ensures neighboring peers (\eg{} in the same \ac{as}, geolocation or IP subnet) get visited by different crawlers.
 It also allows us to get rid of the state in our strategy since we don't have to keep track of the last crawler we assigned a task to, making it easier to implement and reason about.
 
@@ -414,37 +416,35 @@ It also allows us to get rid of the state in our strategy since we don't have to
 %{{{ frequency reduction
 \subsection{Reduction of Request Frequency}
 
-The GameOver Zeus botnet deployed a blacklisting mechanism, where crawlers are blocked based in their request frequency~\cite{bib:andriesse_goz_2013}.
+The GameOver Zeus botnet limited the amount of requests a peer was allowed to perform, and blacklisted peers, that exceeded the limit, as an anti-monitoring mechanism~\cite{bib:andriesse_goz_2013}.
-In a single crawler approach, the crawler frequency has to be limited to prevent hitting the request limit.
+In a uncoordinated crawler approach, the crawl frequency has to be limited to prevent hitting the request limit.
 
 %{{{ fig:old_crawler_timeline
 \begin{figure}[h]
 \centering
-\begin{chronology}[10]{0}{100}{0.9\textwidth}
+\begin{chronology}[10]{0}{60}{0.9\textwidth}
   \event{0}{\(C_0\)}
   \event{20}{\(C_0\)}
   \event{40}{\(C_0\)}
   \event{60}{\(C_0\)}
-  \event{80}{\(C_0\)}
-  \event{100}{\(C_0\)}
 \end{chronology}
-\caption{Timeline of crawler events as seen from a peer when crawled by a single crawler}\label{fig:old_crawler_timeline}
+\caption{Timeline of requests as received by a peer when crawled by a single crawler}\label{fig:old_crawler_timeline}
 \end{figure}
 %}}} fig:old_crawler_timeline
 
 Using collaborative crawlers, an arbitrarily fast frequency can be achieved without being blacklisted.
-With \(L \in \mathbb{N}\) being the frequency limit at which a crawler will be blacklisted, \(F \in \mathbb{N}\) being the crawl frequency that should be achieved.
+With \(l \in \mathbb{N}\) being the maximum allowed frequency as defined by the botnet's protocol, \(f \in \mathbb{N}\) being the crawl frequency that should be achieved.
-The amount of crawlers \(C\) required to achieve the frequency \(F\) without being blacklisted and the offset \(O\) between crawlers are defined as
+The amount of crawlers \(n\) required to achieve the frequency \(f\) without being blacklisted and the offset \(o\) between crawlers are defined as
 
 \begin{align*}
-  n &= \left\lceil \frac{F}{L} \right\rceil \\
+  n &= \left\lceil \frac{f}{l} \right\rceil \\
-  o &= \frac{\SI{1}{\request}}{F}
+  o &= \frac{\SI{1}{\request}}{f}
 \end{align*}
 
-Taking advantage of the \mintinline{go}{StartAt} field from the \mintinline{go}{PeerTask} returned by the \mintinline{go}{requestTasks} primitive above, the crawlers can be scheduled offset by \(O\) at a frequency \(L\) to ensure, the overall requests to each peer are evenly distributed over time.
+Taking advantage of the \mintinline{go}{StartAt} field from the \mintinline{go}{PeerTask} returned by the \mintinline{go}{requestTasks} primitive above, the crawlers can be scheduled offset by \(o\) at a frequency \(l\) to ensure, the overall requests to each peer are evenly distributed over time.
 
-Given a limit \(L = \SI{6}{\request\per\minute}\), crawling a botnet at \(F = \SI{24}{\request\per\minute}\) requires \(n = \left\lceil \frac{\SI{24}{\request\per\minute}}{\SI{6}{\request\per\minute}} \right\rceil = 4\) crawlers.
+Given a limit \(l = \SI{6}{\request\per\minute}\), crawling a botnet at \(f = \SI{24}{\request\per\minute}\) requires \(n = \left\lceil \frac{\SI{24}{\request\per\minute}}{\SI{6}{\request\per\minute}} \right\rceil = 4\) crawlers.
-Those crawlers must be scheduled \(o = \frac{\SI{1}{\request}}{\SI{24}{\request\per\minute}} = \SI{2.5}{\second}\) apart at a frequency of \(L\) for an even request distribution.
+Those crawlers must be scheduled \(o = \frac{\SI{1}{\request}}{\SI{24}{\request\per\minute}} = \SI{2.5}{\second}\) apart at a frequency of \(l\) to evenly distribute the requests over time.
 
 
 %{{{ fig:crawler_timeline
@@ -484,11 +484,11 @@ Those crawlers must be scheduled \(o = \frac{\SI{1}{\request}}{\SI{24}{\request\
 \end{figure}
 %}}} fig:crawler_timeline
 
-As can be seen in~\Fref{fig:crawlerTimelineEffective}, each crawler \(C_0\) to \(C_3\) performs only \SI{6}{\request\per\minute} while overall achieving \(\SI{20}{\request\per 100\second}\).
+As can be seen in~\Fref{fig:crawlerTimelineEffective}, each crawler \(C_0\) to \(C_3\) performs only \SI{6}{\request\per\minute} while overall achieving \(\SI{24}{\request\per\minute}\).
 
-Vice versa given an amount of crawlers \(n\) and a request limit \(L\), the effective frequency \(F\) can be maximized to \(F = n \times L\) without hitting the limit \(L\) and being blocked.
+Vice versa given an amount of crawlers \(n\) and a request limit \(l\), the effective frequency \(f\) can be maximized to \(f = n \times l\) without hitting the limit \(l\) and being blocked.
 
-Using the example from above with \(L = \SI{6}{\request\per\minute}\) but now only two crawlers \(n = 2\), it is still possible to achieve an effective frequency of \(F = 2 \times \SI{6}{\request\per\minute} = \SI{12}{\request\per\minute}\) and \(o = \frac{\SI{1}{\request}}{\SI{12}{\request\per\minute}} = \SI{5}{s}\):
+Using the example from above with \(l = \SI{6}{\request\per\minute}\) but now only two crawlers \(n = 2\), it is still possible to achieve an effective frequency of \(f = 2 \times \SI{6}{\request\per\minute} = \SI{12}{\request\per\minute}\) with \(o = \frac{\SI{1}{\request}}{\SI{12}{\request\per\minute}} = \SI{5}{s}\):
 
 %TODO: name
 %{{{ fig:crawler_timeline
@@ -524,11 +524,11 @@ While the effective frequency of the whole system is halved compared to~\Fref{fi
 
 \citetitle*{bib:karuppayah_sensorbuster_2017} describes different graph metrics to find sensors in \ac{p2p} botnets.
 These metrics depend on the uneven ratio between incoming and outgoing edges for crawlers.
-One of those, \enquote{SensorBuster} uses \acp{wcc} since crawlers don't have any edges back to the main network in the graph.
+The \emph{SensorBuster} metric uses \acp{wcc} since naive sensors don't have any edges back to the main network in the graph.
 
-Building a complete graph \(G_C = K_{\abs{C}}\) between the crawlers by making them return the other crawlers on peer list requests would still produce a disconnected component and while being bigger and maybe not as obvious at first glance, it is still easily detectable since there is no path from \(G_C\) back to the main network (see~\Fref{fig:sensorbuster2} and~\Fref{tab:metricsTable}).
+Building a complete graph \(G_C = K_{\abs{C}}\) between the sensors and crawlers by making them return the other known worker on peer list requests would still produce a disconnected component and while being bigger and maybe not as obvious at first glance, it is still easily detectable since there is no path from \(G_C\) back to the main network (see~\Fref{fig:sensorbuster2} and~\Fref{tab:metricsTable}).
 
-With \(v \in V\), \(\text{succ}(v)\) being the set of successors of \(v\) and \(\text{pred}(v)\) being the set of predecessors of \(v\), PageRank is recursively defined as~\cite{bib:page_pagerank_1998}:
+With \(v \in V\), \(\text{succ}(v)\) being the set of successors of \(v\) and \(\text{pred}(v)\) being the set of predecessors of \(v\), \emph{PageRank} is recursively defined as~\cite{bib:page_pagerank_1998}:
 
 \begin{align*}
   \text{PR}_0(v) &= \text{initialRank} \\
@@ -544,7 +544,7 @@ For simplicity---and since it is not required to model human behaviour for autom
   \text{PR}_{n+1}(v) = \sum\limits_{p \in \text{pred}(v)} \frac{\text{PR}_n(p)}{\abs{\text{succ}(p)}}
 \]
 
-Based on this, SensorRank is defined as
+Based on this, \emph{SensorRank} is defined as
 
 \[
   \text{SR}(v) = \frac{\text{PR}(v)}{\abs{\text{succ}(v)}} \times \frac{\abs{\text{pred}(v)}}{|V|}
@@ -553,7 +553,7 @@ Based on this, SensorRank is defined as
 
 Since crawlers never respond to peer list requests, they will always be detectable by the described approach but sensors might benefit from the following technique.
 
-By responding to peer list requests with plausible data, we will try to make those metrics less suspicious, because it produces valid outgoing edges from the sensors.
+By responding to peer list requests with plausible data and thereby producing valid outgoing edges from the sensors, we will try to make those metrics less suspicious.
 The challenge here is deciding which peers can be returned without actually supporting the network.
 The following candidates to place into the neighbor list will be investigated:
 
@@ -567,9 +567,242 @@ The following candidates to place into the neighbor list will be investigated:
 
 \end{itemize}
 
-Knowledge of only \num{90} peers leaving due to IP rotation would be enough to make a crawler look average in Sality\todo{repeat analysis, actual number}.
+% Knowledge of only \num{90} peers leaving due to IP rotation would be enough to make a crawler look average in Sality\todo{repeat analysis, actual number}.
-This number will differ between different botnets, depending on implementation details and size of the network\todo{upper limit for NL size as impl detail}.
+% This number will differ between different botnets, depending on implementation details and size of the network\todo{upper limit for NL size as impl detail}.
 
+\subsubsection{Other Sensors or Crawlers}
+
+Returning all the other sensors when responding to peer list requests, thereby effectively creating a complete graph \(K_\abs{C}\) among the workers, creates valid outgoing edges.
+The resulting graph will still form a \ac{wcc} with now edges back into the main network.
+Also this would leak the information about all known sensors to the botmasters.
+
+%{{{ churned peers
+\subsubsection{Churned Peers After IP Rotation}
+
+Churn describes the dynamics of peer participation of \ac{p2p} systems, \eg{} join and leave events~\cite{bib:stutzbach_churn_2006}.\todo{übergang}
+Detecting if a peer just left the system, in combination with knowledge about \acp{as}, peers that just left and came from an \ac{as} with dynamic IP allocation (\eg{} many consumer broadband providers in the US and Europe), can be placed into the crawler's peer list.\todo{what is an AS}
+If the timing of the churn event correlates with IP rotation in the \ac{as}, it can be assumed, that the peer left due to being assigned a new IP address---not due to connectivity issues or going offline---and will not return using the same IP address.
+These peers, when placed in the peer list of the crawlers, will introduce paths back into the main network and defeat the \ac{wcc} metric.
+It also helps with the PageRank and SensorRank metrics since the crawlers start to look like regular peers without actually supporting the network by relaying messages or propagating active peers.
+
+%}}} churned peers
+
+%{{{ cg nat
+\subsubsection{Peers Behind Carrier-Grade \acs*{nat}}
+
+Some peers show behaviour, where their IP address changes almost after every request.
+Those peers can be used as fake neighbors and create valid looking outgoing edges for the sensor.
+
+%}}} cg nat
+
+%}}} against graph metrics
+
+%}}} strategies
+
+%{{{ evaluation
+\clearpage{}
+\section{Evaluation}
+
+To evaluate the strategies from above, we took a snapshot of the Sality~\cite{bib:falliere_sality_2011} botnet obtained from \ac{bms} over the span of \daterange{2021-04-21}{2021-04-28}.
+
+%{{{ eval load balancing
+\subsection{Load Balancing}
+
+To evaluate the real-world applicability of IP based partitioning, we will partition the dataset containing \num{1595} distinct IP addresses among \num{2}, \num{4}, \num{6} and \num{10} crawlers and verify if the work is about evenly distributed between crawlers.
+
+We will compare the variance \(\sigma^2\) and standard derivation \(\sigma\) to evaluate the applicability of this method.
+
+%{{{ fig:ipPartC02
+\begin{figure}[H]
+\centering
+\includegraphics[width=.7\linewidth]{ip_part_c02.png}
+\caption{IP based partitioning for 2 crawlers}\label{fig:ipPartC02}
+\end{figure}
+%}}}fig:ipPartC02
+
+\begin{align*}
+  n &= 2 \\
+  \mu &= 1595 / n = 797.5 \\
+  s &= \sum\limits_{i=1}^{n} {(x_i - \mu)}^2 \\
+    &= {(808 - 797.5)}^2 + {(787 - 797.5)}^2 \\
+    &= 220.5 \\
+  \sigma^2 &= \frac{s}{n} = 110.2 \\
+  \sigma &= \sqrt{\sigma^2} = 10.5
+\end{align*}
+
+%{{{ fig:ipPartC04
+\begin{figure}[H]
+\centering
+\includegraphics[width=.7\linewidth]{ip_part_c04.png}
+\caption{IP based partitioning for 4 crawlers}\label{fig:ipPartC04}
+\end{figure}
+%}}}fig:ipPartC04
+
+\begin{align*}
+  n &= 4 \\
+  \mu &= 1595 / n = 398.8 \\
+  s &= \sum\limits_{i=1}^{n} {(x_i - \mu)}^2 \\
+    &= {(403 - 398.8)}^2 + {(369 - 398.8)}^2 + {(405 - 398.8)}^2 \\
+    &+ {(418 - 398.8)}^2 \\
+    &= 1312.8 \\
+  \sigma^2 &= \frac{s}{n} = 328.2 \\
+  \sigma &= \sqrt{\sigma^2} = 18.1
+\end{align*}
+
+%{{{ fig:ipPartC06
+\begin{figure}[H]
+\centering
+\includegraphics[width=.7\linewidth]{ip_part_c06.png}
+\caption{IP based partitioning for 6 crawlers}\label{fig:ipPartC06}
+\end{figure}
+%}}}fig:ipPartC06
+
+\begin{align*}
+  n &= 6 \\
+  \mu &= 1595 / n = 265.8 \\
+  s &= \sum\limits_{i=1}^{n} {(x_i - \mu)}^2 \\
+    &= {(258 - 265.8)}^2 + {(273 - 265.8)}^2 + {(257 - 265.8)}^2 \\
+    &+ {(264 - 265.8)}^2 + {(293 - 265.8)}^2 + {(250 - 265.8)}^2 \\
+    &= 1182.8 \\
+  \sigma^2 &= \frac{s}{n} = 197.1 \\
+  \sigma &= \sqrt{\sigma^2} = 14.0
+\end{align*}
+
+%{{{ fig:ipPartC10
+\begin{figure}[H]
+\centering
+\includegraphics[width=.7\linewidth]{ip_part_c10.png}
+\caption{IP based partitioning for 10 crawlers}\label{fig:ipPartC10}
+\end{figure}
+%}}}fig:ipPartC10
+
+\begin{align*}
+  n &= 10 \\
+  \mu &= 1595 / n = 159.5 \\
+  s &= \sum\limits_{i=1}^{n} {(x_i - \mu)}^2 \\
+    &= {(140 - 159.5)}^2 + {(175 - 159.5)}^2 + {(186 - 159.5)}^2 \\
+    &+ {(166 - 159.5)}^2 + {(159 - 159.5)}^2 + {(152 - 159.5)}^2 \\
+    &+ {(172 - 159.5)}^2 + {(148 - 159.5)}^2 + {(151 - 159.5)}^2 \\
+    &+ {(146 - 159.5)}^2 \\
+    &= 1964.5 \\
+  \sigma^2 &= \frac{s}{n} = 196.4 \\
+  \sigma &= \sqrt{\sigma^2} = 14.0
+\end{align*}
+
+\begin{table}[H]
+  \centering
+\begin{tabular}{rSSSS}
+  \(n\) & \(\mu\) & \(\sigma^{2}\) & \(\sigma\) & \(\frac{\sigma}{\mu}\) \\
+  \num{2} & 797.5 & 110.2 & 10.5 & 1.3\% \\
+  \num{4} & 398.8 & 328.2 & 18.1 & 4.5\% \\
+  \num{6} & 265.8 & 197.1 & 14.0 & 5.3\% \\
+  \num{10} & 159.5 & 196.4 & 14.0 & 8.8\% \\
+\end{tabular}
+  \caption{Variance and standard derivation for IP-based partitioning on \num{1595} IP addresses}\label{tab:varSmall}
+\end{table}
+
+\Fref{tab:varSmall} shows that the derivation from the expected even distribution is within \SI{10}{\percent}.
+Since the used sample is not very big, according to the law of big numbers we would expect the derivation to get smaller, the bigger the sample gets.
+Therefore, we simulated the partitioning on a bigger sample of \num{1000000} random IP addresses.
+
+%{{{ fig:randIpPartC02
+\begin{figure}[H]
+\centering
+\includegraphics[width=.8\linewidth]{rand_ip_part_c02.png}
+\caption{IP based partitioning for 2 crawlers on generated dataset}\label{fig:randIpPartC02}
+\end{figure}
+%}}}fig:randIpPartC02
+
+\begin{align*}
+  n &= 2 \\
+  \mu &= \frac{1000000}{n} = 500000.0 \\
+  s &= \sum\limits_{i=1}^{n} {(x_i - \mu)}^2 \\
+    &= {(499322 - 500000.0)}^2 + {(500678 - 500000.0)}^2 \\
+    &= 919368.0 \\
+  \sigma^2 &= \frac{s}{n} = 459684.0 \\
+  \sigma &= \sqrt{\sigma^2} = 678.0
+\end{align*}
+
+
+%{{{ fig:randIpPartC04
+\begin{figure}[H]
+\centering
+\includegraphics[width=.8\linewidth]{rand_ip_part_c04.png}
+\caption{IP based partitioning for 4 crawlers on generated dataset}\label{fig:randIpPartC04}
+\end{figure}
+%}}}fig:randIpPartC04
+
+\begin{align*}
+  n &= 4 \\
+  \mu &= \frac{1000000}{n} = 250000.0 \\
+  s &= \sum\limits_{i=1}^{n} {(x_i - \mu)}^2 \\
+    &= {(249504 - 250000.0)}^2 + {(250451 - 250000.0)}^2 + {(249818 - 250000.0)}^2 \\
+    &+ {(250227 - 250000.0)}^2 \\
+    &= 534070.0 \\
+  \sigma^2 &= \frac{s}{n} = 133517.5 \\
+  \sigma &= \sqrt{\sigma^2} = 365.4
+\end{align*}
+
+%{{{ fig:randIpPartC06
+\begin{figure}[H]
+\centering
+\includegraphics[width=.8\linewidth]{rand_ip_part_c06.png}
+\caption{IP based partitioning for 6 crawlers on generated dataset}\label{fig:randIpPartC06}
+\end{figure}
+%}}}fig:randIpPartC06
+
+\begin{align*}
+  n &= 6 \\
+  \mu &= \frac{1000000}{n} = 166666.7 \\
+  s &= \sum\limits_{i=1}^{n} {(x_i - \mu)}^2 \\
+    &= {(166430 - 166666.7)}^2 + {(166861 - 166666.7)}^2 + {(166269 - 166666.7)}^2 \\
+    &+ {(166937 - 166666.7)}^2 + {(166623 - 166666.7)}^2 + {(166880 - 166666.7)}^2 \\
+    &= 372413.3 \\
+  \sigma^2 &= \frac{s}{n} = 62068.9 \\
+  \sigma &= \sqrt{\sigma^2} = 249.1
+\end{align*}
+
+%{{{ fig:randIpPartC10
+\begin{figure}[H]
+\centering
+\includegraphics[width=1\linewidth]{rand_ip_part_c10.png}
+\caption{IP based partitioning for 10 crawlers on generated dataset}\label{fig:randIpPartC10}
+\end{figure}
+%}}}fig:randIpPartC10
+
+\begin{align*}
+  n &= 10 \\
+  \mu &= \frac{1000000}{n} = 100000.0 \\
+  s &= \sum\limits_{i=1}^{n} {(x_i - \mu)}^2 \\
+    &= {(100424 - 100000.0)}^2 + {(99650 - 100000.0)}^2 + {(99307 - 100000.0)}^2 \\
+    &+ {(100305 - 100000.0)}^2 + {(99403 - 100000.0)}^2 + {(100562 - 100000.0)}^2 \\
+    &+ {(100277 - 100000.0)}^2 + {(99875 - 100000.0)}^2 + {(99911 - 100000.0)}^2 \\
+    &+ {(100286 - 100000.0)}^2 \\
+    &= 1729874.0 \\
+  \sigma^2 &= \frac{s}{n} = 172987.4 \\
+  \sigma &= \sqrt{\sigma^2} = 415.9
+\end{align*}
+
+\begin{table}[H]
+\centering
+\begin{tabular}{rSSSS}
+  \(n\) & \(\mu\) & \(\sigma^{2}\) & \(\sigma\) & \(\frac{\sigma}{\mu}\) \\
+  \num{2} & 500000.0 & 459684.0 & 678.0 & 0.14\% \\
+  \num{4} & 250000.0 & 133517.5 & 365.4 & 0.15\% \\
+  \num{6} & 166666.7 & 62069.9 & 249.1 & 0.15\% \\
+  \num{10} & 100000.0 & 172987.4 & 415.9 & 0.42\% \\
+\end{tabular}
+  \caption{Variance and standard derivation for IP-based partitioning on \num{1000000} IP addresses}\label{tab:varBig}
+\end{table}
+
+As expected, the work is still not perfectly distributed among the crawlers but evenly enough for our use case.
+The derivation for larger botnets is within \SI{0.5}{\percent} of the even distribution.
+This is good enough for balancing the work among workers.
+
+%}}} eval load balancing
+
+%{{{ eval creating edges
+\subsection{Impact of Additional Edges on Graph Metrics}
 
 %{{{ other sensors
 \subsubsection{Use Other Known Sensors}
@@ -616,113 +849,6 @@ The generated \(K_n\) needs to be at least as big as the smallest regular compon
 
 %}}} other sensors
 
-%{{{ churned peers
-\subsubsection{Use Churned Peers After IP Rotation}
-
-Churn describes the dynamics of peer participation of \ac{p2p} systems, \eg{} join and leave events~\cite{bib:stutzbach_churn_2006}.\todo{übergang}
-Detecting if a peer just left the system, in combination with knowledge about \acp{as}, peers that just left and came from an \ac{as} with dynamic IP allocation (\eg{} many consumer broadband providers in the US and Europe), can be placed into the crawler's peer list.\todo{what is an AS}
-If the timing of the churn event correlates with IP rotation in the \ac{as}, it can be assumed, that the peer left due to being assigned a new IP address---not due to connectivity issues or going offline---and will not return using the same IP address.
-These peers, when placed in the peer list of the crawlers, will introduce paths back into the main network and defeat the \ac{wcc} metric.
-It also helps with the PageRank and SensorRank metrics since the crawlers start to look like regular peers without actually supporting the network by relaying messages or propagating active peers.
-
-%}}} churned peers
-
-%{{{ cg nat
-\subsubsection{Peers Behind Carrier-Grade \acs*{nat}}
-
-Some peers show behaviour, where their IP address changes almost after every request.
-Those peers can be used as fake neighbours and create valid looking outgoing edges for the sensor.
-
-%}}} cg nat
-
-%}}} against graph metrics
-
-%}}} strategies
-
-%{{{ evaluation
-\clearpage{}
-\section{Evaluation}
-
-To evaluate the strategies from above, we took a snapshot of the Sality~\cite{bib:falliere_sality_2011} botnet obtained from \ac{bms} over the span of \daterange{2021-04-21}{2021-04-28}.
-
-%{{{ eval load balancing
-\subsection{Load Balancing}
-
-To evaluate the real-world applicability of IP based partitioning, we will partition the dataset containing \num{1595} distinct IP addresses among \num{2}, \num{4}, \num{6} and \num{10} crawlers and verify if the work is about evenly distributed between crawlers.
-
-%{{{ fig:ipPartC02
-\begin{figure}[h]
-\centering
-\includegraphics[width=1\linewidth]{ip_part_c02.png}
-\caption{IP based partitioning for 2 crawlers}\label{fig:ipPartC02}
-\end{figure}
-%}}}fig:ipPartC02
-
-%{{{ fig:ipPartC04
-\begin{figure}[h]
-\centering
-\includegraphics[width=1\linewidth]{ip_part_c04.png}
-\caption{IP based partitioning for 4 crawlers}\label{fig:ipPartC04}
-\end{figure}
-%}}}fig:ipPartC04
-
-%{{{ fig:ipPartC06
-\begin{figure}[h]
-\centering
-\includegraphics[width=1\linewidth]{ip_part_c06.png}
-\caption{IP based partitioning for 6 crawlers}\label{fig:ipPartC06}
-\end{figure}
-%}}}fig:ipPartC06
-
-%{{{ fig:ipPartC10
-\begin{figure}[h]
-\centering
-\includegraphics[width=1\linewidth]{ip_part_c10.png}
-\caption{IP based partitioning for 10 crawlers}\label{fig:ipPartC10}
-\end{figure}
-%}}}fig:ipPartC10
-
-As expected, the work is not perfectly distributed among the crawlers but evenly enough for our use case.
-According to the law of big numbers, the distribution should get closer to even, the more IP addresses there are to distribute.
-Therefore, we simulated the partitioning on a bigger sample of \num{1000000} random IP addresses.
-
-%{{{ fig:randIpPartC02
-\begin{figure}[h]
-\centering
-\includegraphics[width=1\linewidth]{rand_ip_part_c02.png}
-\caption{IP based partitioning for 2 crawlers on generated dataset}\label{fig:randIpPartC02}
-\end{figure}
-%}}}fig:randIpPartC02
-
-%{{{ fig:randIpPartC04
-\begin{figure}[h]
-\centering
-\includegraphics[width=1\linewidth]{rand_ip_part_c04.png}
-\caption{IP based partitioning for 4 crawlers on generated dataset}\label{fig:randIpPartC04}
-\end{figure}
-%}}}fig:randIpPartC04
-
-%{{{ fig:randIpPartC06
-\begin{figure}[h]
-\centering
-\includegraphics[width=1\linewidth]{rand_ip_part_c06.png}
-\caption{IP based partitioning for 6 crawlers on generated dataset}\label{fig:randIpPartC06}
-\end{figure}
-%}}}fig:randIpPartC06
-
-%{{{ fig:randIpPartC10
-\begin{figure}[h]
-\centering
-\includegraphics[width=1\linewidth]{rand_ip_part_c10.png}
-\caption{IP based partitioning for 10 crawlers on generated dataset}\label{fig:randIpPartC10}
-\end{figure}
-%}}}fig:randIpPartC10
-
-%}}} eval load balancing
-
-%{{{ eval creating edges
-\subsection{Impact of Additional Edges on Graph Metrics}
-
 \begin{table}[H]
   \centering
 \begin{tabular}{lllll}
@@ -809,7 +935,7 @@ Therefore, we simulated the partitioning on a bigger sample of \num{1000000} ran
 
 The distribution graphs in \Fref{fig:dist_sr_25}, \Fref{fig:dist_sr_50} and \Fref{fig:dist_sr_75} show that the initial rank has no effect on the distribution, only on the actual numeric rank values.
 
-For all combinations of initial value and PageRank iterations, the rank for a well known crawler is in the \nth{95} percentile, so for our use case, those parameters do not matter.
+For all combinations of initial value and PageRank iterations, the rank for a well-known crawler is in the \nth{95} percentile, so for our use case, those parameters do not matter.
 
 On average, peers in the analyzed dataset have \num{223} successors over the whole week.
 Looking at the data in smaller buckets of one hour each, the average number of successors per peer is \num{90}.\todo{timeline with peers per bucket}
@@ -964,6 +1090,8 @@ This should be investigated and maybe there are ways to mitigate this problem.
 
 Autoscaling features offered by many cloud-computing providers should be evaluated to automatically add or remove crawlers based on the monitoring load, a botnet's size and number of active peers.
 This should also allow create workers with new IP addresses in different geolocations fast and easy.
+The current implementation assumes a immutable set of crawlers.
+For autoscaling to work, efficient reassignment of peers has to be implemented to account for added or removed workers.
 
 %}}} further work
 

report.tex

@@ -32,7 +32,7 @@ headsepline,
 \usepackage{amsfonts}
 \usepackage{mathtools}
 
-\usepackage{tikz}
+% \usepackage{tikz}
 
 % positioning
 \usepackage{float}