masterthesis/content.tex

%{{{ introduction
\section{Introduction}

The internet has become an irreplaceable part of our day-to-day lives.
We are always connected via numerous \enquote{smart} and \ac{iot} devices.
We use the internet to communicate, shop, handle financial transactions, and much more.
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.

%{{{ motivation
% \subsection{Motivation}

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.
In recent years, \ac{iot} botnets have been responsible for some of the biggest \ac{ddos} attacks ever recorded---creating up to \SI{1}{\tera\bit\per\second} of traffic~\cite{bib:ars_ddos_2016}.

A botnet is a network of infected computers with some means of communication to control the infected systems.
Centralized botnets use one or more coordinating hosts called \ac{c2} servers.
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.
The abuse of infected systems includes several activities---\ac{ddos} attacks, banking fraud, as proxies to hide the attacker's identity, send spam emails\dots{}

Analyzing and shutting down a centralized botnet is comparatively easy since the central means of communication (the \ac{c2} IP address or domain name, Twitter handle or \ac{irc} channel), can be extracted from the malicious binaries and are therefore 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}.

%{{{ fig:c2vsp2p
\begin{figure}[h]
\centering
\begin{subfigure}[b]{.5\textwidth}
  \centering
  \includegraphics[width=1\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}
  \caption{Topology of a \ac{p2p} botnet}\label{fig:p2p}
\end{subfigure}%
\caption{Communication paths in different types of botnets}\label{fig:c2vsp2p}
\end{figure}
%}}}fig:c2vsp2p

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 \autoref{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 bot master only needs to join the network to send new commands or receive stolen data.
Any of the nodes in \autoref{fig:p2p} could be the bot master 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}.
Especially worm-like botnets, where each peer tries to find and infect other systems, the network 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 bot masters can easily rejoin the network and send commands.

%}}} motivation

\section{Background}

%{{{ formal model
\subsection{Definition and Formal Model of \Acs*{p2p} Botnets}

Botnets consist of infected computers, so called \textit{bots}, controlled by a \textit{botmaster}.
Bots can be split into two distinct groups according to their reachability: publicly reachable peers, also known as \textit{superpeers}, and those, that are not (\eg{} because they are behind a \ac{nat} router or firewall).
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.

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 \textit{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.
This is achieved by periodically querying their neighbor's neighbors.
This process is known as \textit{\ac{mm}}.

The concept of \textit{churn} describes when a bot becomes unavailable.
There are two types of churn:

\begin{itemize}

  \item \textit{IP churn}: A bot becomes unreachable because it got a new IP address assigned. The bot is still available but under another address.

  \item \textit{Device churn}: The device is actually offline, \eg{} because the infection was cleaned, it got shut down or lost its internet connection.

\end{itemize}

A \ac{p2p} botnet can be modelled as a digraph

\begin{align*}
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.

\(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.

For a bot \(v \in V\), the \textit{predecessors} (neighbors) \(\text{pred}(v)\) and \textit{successors} \(\text{succ}(v)\) are defined as:

\begin{align*}
  \text{succ}(v) &= \{ u \in V \mid (u, v) \in E \} \\
  \text{pred}(v) &= \{ u \in V \mid (v, u) \in E \}
\end{align*}

The set of edges \(\text{pred}(v)\) is also called the \textit{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.

\begin{align*}
  \deg^{+}(v) &= \abs{\text{pred}(v)} \\
  \deg^{-}(v) &= \abs{\text{succ}(v)}
\end{align*}

\todo{more details}

%}}} formal model

%{{{ detection techniques
\subsection{Monitoring Techniques for \Acs*{p2p} Botnets}

There are two distinct methods to map and get an overview of the network topology of a \ac{p2p} botnet:

%{{{ passive detection
\subsubsection{Passive Monitoring}

For passive detection, traffic flows are analysed in large amounts of collected network traffic (\eg{} from \acp{isp}).
This has some advantages in that it is not possible for bot masters 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.
\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 detection botnet 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)~\cite{bib:botminer2008}.

\begin{itemize}

  \item Large scale network analysis (hard to differentiate from legitimate \ac{p2p} traffic (\eg{} BitTorrent), hard to get data, knowledge of some known bots required)~\cite{bib:zhang_building_2014}

  \item Heuristics: Same traffic patterns, same malicious behaviour

\end{itemize}
\todo{no context}

Passive monitoring is only mentioned for completeness and not a topic for 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.
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 bot masters to detect and block the sensor nodes.

There are two subtypes of active detection: \textit{sensors} wait to be contacted by other peers, while \textit{crawlers} actively query known bots and recursively ask for their neighbors~\cite{bib:karuppayah_sensorbuster_2017}.
Obviously crawlers can only detect superpeers and therefore only see a small subset of the network, while sensors are also contacted by peers in private networks and behind firewalls.
To accurately monitor a \ac{p2p} botnet, a hybrid approach of crawlers and sensors is required.

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.

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.

%}}} active detection

%{{{ anti-monitoring
\subsubsection{Anti-Monitoring}
\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 bot masters 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}.

Successful take-downs of a \ac{p2p} botnet requires intricate knowledge over the network topology, protocol characteristics and participating peers.
In this work we try to find ways to make the monitoring and information gathering phase more efficient and resilient to detection.

%}}} anti-monitoring

%}}} detection techniques

%%{{{ detection criteria
%\subsection{Detection Criteria}

%\begin{itemize}

%  \item \ac{p2p} online time vs host online time

%  \item neighbourhood lists

%  \item no/few \ac{dns} lookups; instead direct lookups from routing tables

%\end{itemize}
%%}}} detection criteria

%}}} introduction


%{{{ methodology
\section{Methodology}

The implementation of the concepts of this work will be done as part of \ac{bms}\footnotemark, a monitoring platform for \ac{p2p} botnets described by \citeauthor{bib:bock_poster_2019} in \citetitle{bib:bock_poster_2019}.
\footnotetext{\url{https://github.com/Telecooperation/BMS}}
\Ac{bms} uses 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, I implemented different node ranking algorithms (among others \enquote{PageRank}~\cite{bib:page_pagerank_1998}) to detect sensors and crawlers in a botnet, as described in \citetitle{bib:karuppayah_sensorbuster_2017}.
Both ranking algorithms use the \(\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.

The goal of this work is to complicate detection mechanisms like this for bot masters by centralizing the coordination 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 sensor is not enough to track all peers.
The changes should allow the current sensors to use the new abstraction with as few changes as possible to the existing code.

The final results should be as general as possible and not depend on any botnet's specific behaviour, but it assumes, that every \ac{p2p} botnet has some kind of \enquote{getPeerList} method in the protocol, that allows other peers to request a list of active nodes to connect to.

In the current implementation, each crawler will itself visit and monitor each new node it finds.
The idea for this work 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 sensor 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.

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.
Further work might even consider autoscaling the monitoring activity using some kind of cloud computing provider.

%}}} methodology

%{{{ primitives
\subsection{Protocol Primitives}

The coordination protocol must allow the following operations:

\subsubsection{Register Worker}

\mintinline{go}{register(capabilities)}: Register new worker with capabilities (which botnet, available bandwidth, \ldots). This is called periodically and used to determine which worker is still active, when splitting the workload.

\subsubsection{Report Peer}

\mintinline{go}{reportPeer(peers)}: Report found targets. Both successful and failed attempts are reported, to detect as soon as possible, when a peer became unavailable.

\subsubsection{Report Edge}

\mintinline{go}{reportEdge(edges)}: Report found edges. Edges are found by querying the peer list of known peers. This is how new peers are detected.

\subsubsection{Request Tasks}

\mintinline{go}{requestTasks() []PeerTask}: Receive a batch of crawl tasks from the coordinator. The tasks consist of the target peer, if the crawler should start or stop the operation, when it should start and stop monitoring and the frequency.

\begin{minted}{go}
type Peer struct {
  BotID string
  IP    string
  Port  uint16
}
type PeerTask struct {
  Peer         Peer
  StartAt      *Time
  StopAt       *Time
  Frequency    uint
  StopCrawling bool
}
\end{minted}

%}}} primitives

%}}} methodology

%{{{ strategies
\section{Coordination Strategies}

Let \(C\) be the set of available crawlers.
Without loss of generality, if not stated otherwise, I assume that \(C\) is known when \ac{bms} is started and will not change afterward.
There will be no joining or leaving crawlers.
This assumption greatly simplifies the implementation due to the lack of changing state that has to be tracked while still exploring the described strategies.
A production-ready implementation of the described techniques can drop this assumption but might have to recalculate the work distribution once a crawler joins or leaves.

%{{{ load balancing
\subsection{Load Balancing}\label{sec:loadBalancing}

This strategy simply splits the work into chunks and distributes the work between the available crawlers.
The following sharding strategy will be investigated:

\begin{itemize}
  \item Round Robin. See~\autoref{sec:rr}

  \item Assuming IP addresses are evenly distributed and so are infections, take the IP address as an \SI{32}{\bit} integer modulo \(\abs{C}\). See~\autoref{sec:ipPart}
    Problem: reassignment if a crawler joins or leaves
\end{itemize}

Load balancing in itself does not help prevent the detection of crawlers but it allows better usage of available resources.
No peer will be crawled by more than one crawler and it allows crawling of bigger botnets where the current approach would reach its limit and could also be worked around with scaling up the machine where the crawler is executed.
Load balancing allows scaling out, which can be more cost-effective.

\subsubsection{Round Robin Distribution}\label{sec:rr}

\subsubsection{Even Work Distribution}\label{sec:ewd}
\todo{weighted round robin}

Work is evenly distributed between crawlers according to their capabilities.
For the sake of simplicity, only the bandwidth will be considered as capability but it can be extended by any shared property between the crawlers, \eg{} available memory, CPU speed.
For a given crawler \(c_i \in C\) let \(B(c_i)\) be the total bandwidth of the crawler.
The total available bandwidth is \(b = \sum\limits_{c \in C} B(c_i)\).
The weight \(W(c_i) = \frac{B}{B(c_i)}\)\todo{proper def for weight} defines which percentage of the work gets assigned to \(c_i\).
The set of target peers \(P = <p_0, p_1, \ldots, p_{n-1}>\), is partitioned into \(|C|\) subsets according to \(W(c_i)\) and each subset is assigned to its crawler \(c_i\).
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 following algorithm distributes the work according to the crawler's capabilities:

\begin{minted}{go}
func WeightCrawlers(crawlers ...Crawler) map[string]uint {
  weights := []int{}
  totalWeight := 0
  for _, crawler := range crawlers {
    totalWeight += crawler.Bandwith
    weights = append(weights, crawler.Bandwith)
  }
  gcd := Fold(Gcd, weights...)
  weightMap := map[string]uint{}
  for _, crawler := range crawlers {
    weightMap[crawler.ID] = uint(crawler.Bandwith / gcd)
  }
  return weightMap
}

func WeightedCrawlerList(crawlers ...Crawler) []string {
  weightMap := WeightCrawlers(crawlers...)
  didSomething := true
  crawlerIds := []string{}
  for didSomething {
    didSomething = false
    for k, v := range weightMap {
      if v != 0 {
        didSomething = true
        crawlerIds = append(crawlerIds, k)
        weightMap[k] -= 1
      }
    }
  }
  return crawlerIds
}
\end{minted}

This creates a list of crawlers where a crawler can occur more than once, depending on its capabilities.
The set of crawlers \(\{a, b, c\}\) with capabilities \(cap(a) = 3, cap(b) = 2, cap(c) = 1\) would produce \(<a, b, c, a, b, a>\), allocating two and three times the work to crawlers \(b\) and \(a\) respectively.

The following weighted round-robin algorithm distributes the work according to the crawlers' capabilities:

\begin{minted}{go}
work := make(map[string][]strategy.Peer)
commonWeight := 0
counter := -1
for _, peer := range peers {
  for {
    counter += 1
    if counter <= mod {
      counter = 0
    }
    crawler := crawlers[counter]
    if counter == 0 {
      commonWeight = commonWeight - gcd(weightList...)
      if commonWeight <= 0 {
        commonWeight = max(weightList...)
        if commonWeight == 0 {
          return nil, errors.New("invalid common weight")
        }
      }
    }
    if weights[crawler] >= commonWeight {
      work[crawler] = append(work[crawler], peer)
      break
    }
  }
}
\end{minted}
\todo{reference for wrr}


\subsubsection{IP-based Partitioning}\label{sec:ipPart}

The output of cryptographic hash functions is uniformly distributed---even substrings of the calculated hash hold this property.
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.

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.
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.

\begin{figure}[H]
  \centering
  \includegraphics[width=1\linewidth]{./md5_ip_dist.png}
  \caption{Distribution of the lowest byte of \ac{md5} hashes over IPv4}\label{fig:md5IPDist}
\end{figure}
\todo{remove this?}

\ac{md5} returns a \SI{128}{\bit} hash value.
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 evenly distributed over all IP subnets, \ac{as} and geolocations.
This ensures neighboring peers (\eg{} in the same \ac{as}, geolocation or IP subnet) get visited by different crawlers.

%}}} load balancing

%{{{ 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}.
In a single crawler approach, the crawler frequency has to be limited to prevent being hitting the request limit.

%{{{ fig:old_crawler_timeline
\begin{figure}[h]
\centering
\begin{chronology}[10]{0}{100}{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}
\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.
The amount of crawlers \(C\) required to achieve the frequency \(F\) without being blacklisted and the offset \(O\) between crawlers are defined as

\begin{align*}
  C &= \left\lceil \frac{F}{L} \right\rceil \\
  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.

Given a limit \(L = \SI{5}{\request\per 100\second}\), crawling a botnet at \(F = \SI{20}{\request\per 100\second}\) requires \(C = \left\lceil \frac{\SI{20}{\request\per 100\second}}{\SI{5}{\request\per 100\second}} \right\rceil = 4\) crawlers.
Those crawlers must be scheduled \(O = \frac{\SI{1}{\request}}{\SI{20}{\request\per 100\second}} = \SI{5}{\second}\) apart at a frequency of \(L\) for an even request distribution.


%{{{ fig:crawler_timeline
\begin{figure}[h]
\centering
\begin{chronology}[10]{0}{100}{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\)}

  \event{5}{\(C_1\)}
  \event{25}{\(C_1\)}
  \event{45}{\(C_1\)}
  \event{65}{\(C_1\)}
  \event{85}{\(C_1\)}

  \event{10}{\(C_2\)}
  \event{30}{\(C_2\)}
  \event{50}{\(C_2\)}
  \event{70}{\(C_2\)}
  \event{90}{\(C_2\)}

  \event{15}{\(C_3\)}
  \event{35}{\(C_3\)}
  \event{55}{\(C_3\)}
  \event{75}{\(C_3\)}
  \event{95}{\(C_3\)}
\end{chronology}
\caption{Timeline of crawler events as seen from a peer when crawled by multiple crawlers}\label{fig:crawler_timeline}
\end{figure}
%}}} fig:crawler_timeline

As can be seen in~\autoref{fig:crawler_timeline}, each crawler \(C_0\) to \(C_3\) performs only \SI{5}{\request\per 100\second} while overall achieving \(\SI{20}{\request\per 100\second}\).

Vice versa given an amount of crawlers \(C\) and a request limit \(L\), the effective frequency \(F\) can be maximized to \(F = C \times L\) without hitting the limit \(L\) and being blocked.

Using the example from above with \(L = \SI{5}{\request\per 100\second}\) but now only two crawlers \(C = 2\), it is still possible to achieve an effective frequency of \(F = 2 \times \SI{5}{\request\per 100\second} = \SI{10}{\request\per 100\second}\) and \(O = \frac{\SI{1}{\request}}{\SI{10}{\request\per 100\second}} = \SI{10}{s}\):

%TODO: name
%{{{ fig:crawler_timeline
\begin{figure}[h]
\centering
\begin{chronology}[10]{0}{100}{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\)}

  \event{10}{\(C_1\)}
  \event{30}{\(C_1\)}
  \event{50}{\(C_1\)}
  \event{70}{\(C_1\)}
  \event{90}{\(C_1\)}

\end{chronology}
% \caption{Timeline of crawler events as seen from a peer}\label{fig:crawler_timeline}
\end{figure}
%}}} fig:crawler_timeline

While the effective frequency of the whole system is halved compared to~\autoref{fig:crawler_timeline}, it is still possible to double the frequency over the limit.

%}}} frequency reduction

%{{{ against graph metrics
\subsection{Creating Outgoing Edges for Crawlers and Sensors}

\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.

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~\autoref{fig:sensorbuster2} and~\autoref{fig:metrics_table}).

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}:

\begin{align*}
  \text{PR}_0(v) &= \text{initialRank} \\
  \text{PR}_{n+1}(v) &= \text{dampingFactor} \times \sum\limits_{p \in \text{pred}(v)} \frac{\text{PR}_n(p)}{\abs{\text{succ}(p)}} + \frac{1 - \text{dampingFactor}}{\abs{V}}
\end{align*}

For the first iteration, the PageRank of all nodes is set to the same initial value. When iterating often enough, any value can be chosen~\cite{bib:page_pagerank_1998}.

The dampingFactor describes the probability of a person visiting links on the web to continue doing so, when using PageRank to rank websites in search results.
For simplicity---and since it is not required to model human behaviour for automated crawling and ranking---a dampingFactor of \(1.0\) will be used, which simplifies the formula to

\[
  \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

\[
  \text{SR}(v) = \frac{\text{PR}(v)}{\abs{\text{succ}(v)}} \times \frac{\abs{\text{pred}(v)}}{|V|}
\]

\todo{percentage of botnet must be crawlers to make a significant change}

Applying PageRank once with an initial rank of \(0.25\) once on the example graphs above results in:

\todo{pagerank, sensorrank calculations, proper example graphs, proper table formatting}
\begin{table}[H]
  \centering
\begin{tabular}{llllll}
  Node & \(\deg^{+}\) & \(\deg^{-}\) & In \ac{wcc}? & PageRank & SensorRank \\
  n0 & 0/0 & 4/4 & no & 0.75/0.5625 & 0.3125/0.2344 \\
  n1 & 1/1 & 3/3 & no & 0.25/0.1875 & 0.0417/0.0313 \\
  n2 & 2/2 & 2/2 & no & 0.5/0.375 & 0.3333/0.25 \\
  c0 & 3/5 & 0/2 & yes (1/3) & 0.0/0.125 & 0.0/0.0104 \\
  c1 & 1/3 & 0/2 & yes (1/3) & 0.0/0.125 & 0.0/0.0104 \\
  c2 & 2/4 & 0/2 & yes (1/3) & 0.0/0.125 & 0.0/0.0104 \\
\end{tabular}
\caption{Values for metrics from~\autoref{fig:sensorbuster} (a/b)}\label{fig:metrics_table}
\end{table}

While this works for small networks, the crawlers must account for a significant amount of peers in the network for this change to be noticeable.
The generated \(K_n\) needs to be at least as big as the smallest regular component in the botnet, which is not feasible.

In our experiments on 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} even 1 iteration were enough to get distinct enough values to detect sensors and crawlers.

\begin{table}[H]
  \centering
\begin{tabular}{lllll}
  \textbf{Iteration} & \textbf{Avg. PR} & \textbf{Crawler PR} & \textbf{Avg. SR} & \textbf{Crawler SR} \\
  1 & 0.24854932 & 0.63277194 & 0.15393478 & 0.56545578 \\
  2 & 0.24854932 & 0.63277194 & 0.15393478 & 0.56545578 \\
  3 & 0.24501068 & 0.46486353 & 0.13810930 & 0.41540997 \\
  4 & 0.24501068 & 0.46486353 & 0.13810930 & 0.41540997 \\
  5 & 0.24233737 & 0.50602884 & 0.14101354 & 0.45219598 \\
\end{tabular}
  \caption{Values for PageRank iterations with initial rank \(\forall v \in V : \text{PR}(v) = 0.25\)}\label{fig:pr_iter_table_25}
\end{table}

\begin{figure}[H]
  \centering
\begin{subfigure}[b]{.5\textwidth}
  \centering
  \includegraphics[width=1\linewidth]{0.25_1_sr.png}
  \caption{Distribution after 1 iteration}\label{fig:dist_sr_25_1}
\end{subfigure}%
\begin{subfigure}[b]{.5\textwidth}
  \centering
  \includegraphics[width=1\linewidth]{0.25_5_sr.png}
  \caption{Distribution after 5 iterations}\label{fig:dist_sr_25_5}
\end{subfigure}%
  \caption{SensorRank distribution with initial rank \(\forall v \in V : \text{PR}(v) = 0.25\)}\label{fig:dist_sr_25}
\end{figure}

\begin{table}[H]
  \centering
\begin{tabular}{lllll}
  \textbf{Iteration} & \textbf{Avg. PR} & \textbf{Crawler PR} & \textbf{Avg. SR} & \textbf{Crawler SR} \\
  1 & 0.49709865 & 1.26554389 & 0.30786955 & 1.13091156 \\
  2 & 0.49709865 & 1.26554389 & 0.30786955 & 1.13091156 \\
  3 & 0.49002136 & 0.92972707 & 0.27621861 & 0.83081993 \\
  4 & 0.49002136 & 0.92972707 & 0.27621861 & 0.83081993 \\
  5 & 0.48467474 & 1.01205767 & 0.28202708 & 0.90439196 \\
\end{tabular}
  \caption{Values for PageRank iterations with initial rank \(\forall v \in V : \text{PR}(v) = 0.5\)}\label{fig:pr_iter_table_5}
\end{table}

\begin{figure}[H]
  \centering
\begin{subfigure}[b]{.5\textwidth}
  \centering
  \includegraphics[width=1\linewidth]{0.50_1_sr.png}
  \caption{Distribution after 1 iteration}\label{fig:dist_sr_50_1}
\end{subfigure}%
\begin{subfigure}[b]{.5\textwidth}
  \centering
  \includegraphics[width=1\linewidth]{0.50_5_sr.png}
  \caption{Distribution after 5 iterations}\label{fig:dist_sr_50_5}
\end{subfigure}%
  \caption{SensorRank distribution with initial rank \(\forall v \in V : \text{PR}(v) = 0.5\)}\label{fig:dist_sr_50}
\end{figure}

\begin{table}[H]
  \centering
\begin{tabular}{lllll}
  \textbf{Iteration} & \textbf{Avg. PR} & \textbf{Crawler PR} & \textbf{Avg. SR} & \textbf{Crawler SR} \\
  1 & 0.74564797 & 1.89831583 & 0.46180433 & 1.69636734 \\
  2 & 0.74564797 & 1.89831583 & 0.46180433 & 1.69636734 \\
  3 & 0.73503203 & 1.39459060 & 0.41432791 & 1.24622990 \\
  4 & 0.73503203 & 1.39459060 & 0.41432791 & 1.24622990 \\
  5 & 0.72701212 & 1.51808651 & 0.42304062 & 1.35658794 \\
\end{tabular}
  \caption{Values for PageRank iterations with initial rank \(\forall v \in V : \text{PR}(v) = 0.75\)}\label{fig:pr_iter_table_75}
\end{table}

\begin{figure}[H]
  \centering
\begin{subfigure}[b]{.5\textwidth}
  \centering
  \includegraphics[width=1\linewidth]{0.75_1_sr.png}
  \caption{Distribution after 1 iteration}\label{fig:dist_sr_75_1}
\end{subfigure}%
\begin{subfigure}[b]{.5\textwidth}
  \centering
  \includegraphics[width=1\linewidth]{0.75_5_sr.png}
  \caption{Distribution after 5 iterations}\label{fig:dist_sr_75_5}
\end{subfigure}%
  \caption{SensorRank distribution with initial rank \(\forall v \in V : \text{PR}(v) = 0.75\)}\label{fig:dist_sr_75}
\end{figure}

The distribution graphs in \autoref{fig:dist_sr_25}, \autoref{fig:dist_sr_50} and \autoref{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.

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}

%{{{ fig:avg_out_edges
\begin{figure}[h]
\centering
\includegraphics[width=1\linewidth]{./avg_out_edges.png}
\caption{Average outgoing edges per peer per hour}\label{fig:avg_out_edges}
\end{figure}
\todo{use better data?}
%}}}fig:avg_out_edges

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, one can move make those metrics less suspicious, because it produces valid outgoing edges from the sensors.
The hard part is deciding which peers can be returned without actually supporting the network.
The following candidates to place into the NL will be investigated:

\begin{itemize}

  \item Return the other known sensors, effectively building an complete graph \(K_{\abs{C}}\) containing all sensors

  \item Detect churned peers from \ac{as} with dynamic IP allocation

  \item Detect peers behind carrier-grade \ac{nat} that rotate IP addresses very often and pick random IP addresses from the IP range

\end{itemize}

Knowledge of only \num{90} peers leaving due to IP rotation would be enough to make a crawler look average in Sality.
This number will differ between different botnets, depending on implementation details and size of the network.

Adding edges from the known crawler to \num{90} random peers to simulate the described strategy gives the following rankings:\todo{table, distribution with random edges}


%{{{ other sensors
\subsubsection{Use Other Known Sensors}

By connecting the known sensors and effectively building a complete graph \(K_{\abs{C}}\) between them creates \(\abs{C} - 1\) outgoing edges per sensor.
In most cases this won't be enough to reach the amount of edges that would be needed.
Also this does not help against the \ac{wcc} metric since this would create a bigger but still disconnected component.

% TODO: caption, label
\begin{figure}[H]
\centering
\begin{subfigure}[b]{.5\textwidth}
  \centering
  \includegraphics[width=1\linewidth]{sensorbuster1.drawio.pdf}
  \caption{\acp{wcc} for independent crawlers}\label{fig:sensorbuster1}
\end{subfigure}%
\begin{subfigure}[b]{.5\textwidth}
  \centering
  \includegraphics[width=1\linewidth]{sensorbuster2.drawio.pdf}
  \caption{\acp{wcc} for collaborated crawlers}\label{fig:sensorbuster2}
\end{subfigure}%
  \caption{Differences in graph metrics}\label{fig:sensorbuster}
\end{figure}


%}}} 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

Experiments were performed, in which a fixed amount of random outgoing edges were added to the known sensor and the data was plotted:

\begin{figure}[H]
\centering
  \begin{subfigure}[b]{.5\textwidth}
    \centering
    \includegraphics[width=1\linewidth]{./assets/30_pr_percentiles.png}
    \caption{PageRank with \num{30} additional edges}\label{fig:30_pr_percentiles}
  \end{subfigure}
  \begin{subfigure}[b]{.4\textwidth}
    \centering
    \includegraphics[width=1\linewidth]{./assets/30_sr_percentiles.png}
    \caption{SensorRank with \num{30} additional edges}\label{fig:30_sr_percentiles}
  \end{subfigure}
  \caption{Ranking with \num{30} additional edges}\label{fig:30_percentiles}
\end{figure}

\begin{figure}[H]
\centering
  \begin{subfigure}[b]{.4\textwidth}
    \centering
    \includegraphics[width=1\linewidth]{./assets/40_pr_percentiles.png}
    \caption{PageRank with \num{40} additional edges}\label{fig:40_pr_percentiles}
  \end{subfigure}
  \begin{subfigure}[b]{.4\textwidth}
    \centering
    \includegraphics[width=1\linewidth]{./assets/40_sr_percentiles.png}
    \caption{SensorRank with \num{40} additional edges}\label{fig:40_sr_percentiles}
  \end{subfigure}
  \caption{Ranking with \num{40} additional edges}\label{fig:40_percentiles}
\end{figure}

\begin{figure}[H]
\centering
  \begin{subfigure}[b]{.4\textwidth}
    \centering
    \includegraphics[width=1\linewidth]{./assets/50_pr_percentiles.png}
    \caption{PageRank with \num{50} additional edges}\label{fig:50_pr_percentiles}
  \end{subfigure}
  \begin{subfigure}[b]{.4\textwidth}
    \centering
    \includegraphics[width=1\linewidth]{./assets/50_sr_percentiles.png}
    \caption{SensorRank with \num{50} additional edges}\label{fig:50_sr_percentiles}
  \end{subfigure}
  \caption{Ranking with \num{50} additional edges}\label{fig:50_percentiles}
\end{figure}

%}}} against graph metrics

%}}} strategies

%{{{ implementation
\section{Implementation}

Crawlers in \ac{bms} report to the backend using \acp{grpc}\footnote{\url{https://www.grpc.io}}.
Both crawlers and the backend \ac{grpc} server are implemented using the Go\footnote{\url{https://go.dev/}} programming language, so to make use of existing know-how and to allow others to use the implementation in the future, the coordinator backend and crawler abstraction were also implemented in Go.

\Ac{bms} already has an existing abstraction for crawlers.
This implementation is highly optimized but also tightly coupled and grown over time.
The abstraction became leaky and extending it proved to be complicated.
A new crawler abstraction was created with testability, extensibility and most features of the existing implementation in mind, which can be ported back to be used by the existing crawlers.

%{{{ fig:crawler_arch
\begin{figure}[h]
\centering
\includegraphics[width=1\linewidth]{architecture.drawio.pdf}
\caption{Architecture of the new crawler}\label{fig:crawler_arch}
\end{figure}
%}}}fig:crawler_arch

The new implementation consists of three main interfaces:

\begin{itemize}
  \item \mintinline{go}{FindPeer}, to receive new crawl tasks from any source

  \item \mintinline{go}{ReportPeer}, to report newly found peers

  \item \mintinline{go}{Protocol}, the actual botnet protocol implementation used to ping a peer and request its peer list
\end{itemize}

Currently there are two sources \mintinline{go}{FindPeer} can use: read peers from a file on disk or request them from the \ac{grpc} BMS coordinator.
The \mintinline{go}{ExactlyOnceFinder} delegate can wrap another \mintinline{go}{FindPeer} instance and ensures the source is only requested once.
This is used to implement the bootstrapping mechanism of the old crawler, where once, when the crawler is started, the list of bootstrap nodes is loaded from a textfile.
\mintinline{go}{CombinedFinder} can combine any amount of \mintinline{go}{FindPeer} instances and will return the sum of requesting all the sources.

The \mintinline{go}{PeerTask} instances returned by \mintinline{go}{FindPeer} contain the IP address and port of the peer, if the crawler should start or stop the operation, when to start and stop crawling and in which interval the peer should be crawled.
For each task, a \mintinline{go}{CrawlPeer} and \mintinline{go}{PingPeer} worker is started or stopped as specified in the received \mintinline{go}{PeerTask}.
These tasks use the \mintinline{go}{ReportPeer} interface to report any new peer that is found.

Current report possibilities are \mintinline{go}{LoggingReport} to simply log new peers to get feedback from the crawler at runtime, and \mintinline{go}{BMSReport} which reports back to \ac{bms}.
\mintinline{go}{BatchedReport} delegates a \mintinline{go}{ReportPeer} instance and batch newly found peers up to a specified batch size and only then flush and actually report.
\mintinline{go}{AutoCommitReport} will automatically flush a delegated \mintinline{go}{ReportPeer} instance after a fixed amount of time and is used in combination with \mintinline{go}{BatchedReport} to ensure the batches are written regularly, even if the batch limit is not reached yet.
\mintinline{go}{CombinedReport} works analogous to \mintinline{go}{CombinedFinder} and combines many \mintinline{go}{ReportPeer} instances into one.

\mintinline{go}{PingPeer} and \mintinline{go}{CrawlPeer} use the implementation of the botnet \mintinline{go}{Protocol} to perform the actual crawling in predefined intervals, which can be overwritten on a per \mintinline{go}{PeerTask} basis.

The server-side part of the system consists of a \ac{grpc} server to handle the client requests, a scheduler to assign new peers, and a \mintinline{go}{Strategy} interface for modularity over how work is assigned to crawlers.

%{{{ fig:bachend_arch
\begin{figure}[h]
\centering
\includegraphics[width=1\linewidth]{backend_architecture.drawio.pdf}
\caption{Architecture of the \ac{grpc} backend}\label{fig:bachend_arch}
\end{figure}
%}}}fig:bachend_arch

%}}} implementation

%{{{ conclusion
\section{Conclusion, Lessons Learned}\todo{decide}

Collaborative monitoring of \ac{p2p} botnets allows circumventing some anti-monitoring efforts.
It also enables more effective monitoring systems for larger botnets, since each peer can be visited by only one crawler.
The current concept of independent crawlers in \ac{bms} can also use multiple workers but there is no way to ensure a peer is not watched by multiple crawlers thereby using unnecessary resources.


%}}} conclusion

%{{{ further work
\section{Further Work}

Following this work, it should be possible to rewrite the existing crawlers to use the new abstraction.
This might bring some performance issues to light which can be solved by investigating the optimizations from the old implementation and applying them to the new one.

Another way to expand on this work is automatically scaling the available crawlers up and down, depending on the botnet size and the number of concurrently online peers.
Doing so would allow a constant crawl interval for even highly volatile botnets.

%}}} further work

%{{{ acknowledgments
\section*{Acknowledgments}

In the end, I would like to thank

\begin{itemize}
  \item Prof.\ Dr.\ Christoph Skornia for being a helpful supervisor in this and many earlier works of mine

  \item Leon Böck for offering the possibility to work on this research project, regular feedback and technical expertise

  \item Valentin Sundermann for being available for insightful ad hoc discussions at any time of day for many years

  \item Friends and family who pushed me into continuing this path
\end{itemize}

%}}} acknowledgments

% vim: set filetype=tex ts=2 sw=2 tw=0 et foldmethod=marker spell :