Content

acronyms.tex

@@ -80,4 +80,9 @@
   long  = {gRPC remote procedure call}
 }
 
+\DeclareAcronym{nat}{
+  short = {NAT},
+  long  = {network access translation}
+}
+
 % vim: set filetype=tex ts=2 sw=2 tw=0 et :

content.tex

@@ -475,23 +475,6 @@ Based on this, SensorRank is defined as
 
 \todo{percentage of botnet must be crawlers to make a significant change}
 
-% TODO: caption, label
-\begin{figure}[H]
-\centering
-\begin{subfigure}[b]{.5\textwidth}
-  \centering
-  \includegraphics[width=1\linewidth]{sensorbuster1.pdf}
-  \caption{\acp{wcc} for independent crawlers}\label{fig:sensorbuster1}
-\end{subfigure}%
-\begin{subfigure}[b]{.5\textwidth}
-  \centering
-  \includegraphics[width=1\linewidth]{sensorbuster2.pdf}
-  \caption{\acp{wcc} for collaborated crawlers}\label{fig:sensorbuster2}
-\end{subfigure}%
-  \caption{Differences in graph metrics}\label{fig:sensorbuster}
-\end{figure}
-\todo{these examples suck; chose better examples}
-
 Applying SensorRank 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}
@@ -615,16 +598,73 @@ Looking at the data in smaller buckets of one hour each, the average number of s
 \todo{use better data?}
 %}}}fig:avg_out_edges
 
+Since crawlers never respond to neighbourhood list requests, they will always be detectable by the described approach but sensors might benefit from the following technique.
+
+By responding to neighbourhood 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.pdf}
+  \caption{\acp{wcc} for independent crawlers}\label{fig:sensorbuster1}
+\end{subfigure}%
+\begin{subfigure}[b]{.5\textwidth}
+  \centering
+  \includegraphics[width=1\linewidth]{sensorbuster2.pdf}
+  \caption{\acp{wcc} for collaborated crawlers}\label{fig:sensorbuster2}
+\end{subfigure}%
+  \caption{Differences in graph metrics}\label{fig:sensorbuster}
+\end{figure}
+\todo{these examples suck; chose better examples}
+
+
+%}}} 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 neighbourhood 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 neighbourhood 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.
 
-Knowledge of only \num{90} peers leaving due to IP rotation would be enough to make a crawler look average in Sality.
+%}}} churned peers
-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}
+%{{{ 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