add: batch 5

prace.tex

@@ -61,10 +61,21 @@
 \nastavautora{AM}
 \nastavnazevcz{}
 \nastavnazeven{Protecting Internet Networks Against DoS Attacks} % Jen u anglicky psané práce
-\nastavabstraktcz{}
+\nastavabstraktcz{V tejto práci sme analyzovali bežné spôsoby prevádzkovania
-\nastavabstrakten{}
+Denial of Service útokov, ako aj niektoré zo známych nástrojov, ktorými sa
-\nastavklicovaslovacz{DDoS, Sítě, BGP, Black-holing}
+útoky vykonávajú. Na druhej strane sme sa pojednávali o regulérne používaných
-\nastavklicovaslovaen{DDoS, Networks, BGP, Black-holing}
+spôsoboch ochrany a to tak z pohľadu sieťových operátorov, ako aj koncových
+užívateľov. Pokúsili sme sa zautomatizovať vytváranie testovacieho laboratória
+a vyskúšali sme si sprevádzkovať útok na jednoduchej topológii s cieľom
+precvičit si black hole techniku.}
+\nastavabstrakten{In the thesis it is explored how Denial of Service attacks
+are usually performed, what techniques are used and some of the popular tools
+used to conduct attacks. On the other side we looked at the commonly used
+mitigation methods with both network operators and end users. We attempted to
+automate creating a testing lab and tried out performing an attack in a simple
+topology with the aim to exercise the black hole technique.}
+\nastavklicovaslovacz{DoS, Sítě, BGP, Black-holing}
+\nastavklicovaslovaen{DoS, Networks, BGP, Black-holing}
 
 % Následující příkaz nastaví standard PDF/A-1b
 \aplikujpdfa

tex/abbreviations.tex

@@ -18,6 +18,7 @@ ISP & \emph{Internet Service Provider}\tabularnewline
 IXP & \emph{Internet Exchange Point}\tabularnewline
 LVM & \emph{Logical Volume Management}\tabularnewline
 RFC & \emph{Request For Comment}\tabularnewline
+SSH & \emph{Secure Shell}\tabularnewline
 TCP & \emph{Transmission Control Protocol}\tabularnewline
 UDP & \emph{User Datagram Protocol}\tabularnewline
 ULV & \emph{Ultra Low Voltage}\tabularnewline

tex/appendices.tex

@@ -1,6 +1,12 @@
 % ============================================================================ %
 
 \listofappendices
+\begin{enumerate}
+  \item ansible-gobgp-master.tar.gz
+  \item fastnetmon-ng-development.tar.gz
+  \item ansible-fprobe-master.tar.gz
+  \item tf-libvirt-main.tar.gz
+\end{enumerate}
 
 
 % ============================================================================ %

tex/references.bib

@@ -259,6 +259,23 @@
 	note={[online] Accessed: 2021-05-10},
 }
 
+@misc{linuxbtrfs,
+	title={Linux Btrfs Sysadmin Guide},
+	author="{The kernel development community}",
+	howpublished={\url{https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Copy_on_Write_.28CoW.29}},
+	note={[online] Accessed: 2021-03-12},
+}
+
+@misc{cloudinit,
+	title={The standard for customising cloud instances},
+	author={Canonical},
+	publisher={GitHub},
+	journal={GitHub repository},
+	howpublished={\url{https://github.com/canonical/cloud-init}},
+	year=2021,
+	note={[online] Accessed: 2021-04-09},
+}
+
 @misc{metasploit,
 	title={Metasploit Framework},
 	author={rapid7},
@@ -269,8 +286,78 @@
 	note={[online] Accessed: 2021-04-03},
 }
 
+@misc{libvirt-tf-provider,
+	title={Terraform provider to provision infrastructure with Linux's KVM using libvirt},
+	author="{Duncan Mac-Vicar P.}",
+	publisher={GitHub},
+	journal={GitHub repository},
+	howpublished={\url{https://github.com/dmacvicar/terraform-provider-libvirt}},
+	year=2021,
+	note={[online] Accessed: 2021-04-08},
+}
+
+@misc{fnm-wayback,
+	title={Archived view of FastNetMon - very fast DDoS sensor with sFlow/Netflow/IPFIX/SPAN support},
+	author="{The Internet Archive}",
+	publisher={Wayback Machine},
+	journal={GitHub repository},
+	howpublished={\url{https://web.archive.org/web/20210330122630/https://github.com/pavel-odintsov/fastnetmon/tree/master}},
+	year=2021,
+	note={[online] Accessed: 2021-04-01},
+}
+
+@misc{fnm-early-wayback,
+	title={Archived view of FastNetMon from January 2021},
+	author="{The Internet Archive}",
+	publisher={Wayback Machine},
+	journal={GitHub repository},
+	howpublished={\url{https://web.archive.org/web/20210111231449/https://github.com/pavel-odintsov/fastnetmon/}},
+	year=2021,
+	note={[online] Accessed: 2021-04-02},
+}
+
+@misc{fnm-search-wayback,
+	title={Archived view of GitHub search for FastNetMon},
+	author="{The Internet Archive}",
+	publisher={Wayback Machine},
+	journal={GitHub repository},
+	howpublished={\url{https://web.archive.org/web/20210330135951/https://github.com/search?utf8=%E2%9C%93&q=fastnetmon}},
+	year=2021,
+	note={[online] Accessed: 2021-04-02},
+}
+
+@misc{fnm-freebsd-wayback,
+	title={Archived view of FreeBSD forum thread on FastNetMon},
+	author="{The Internet Archive}",
+	publisher={Wayback Machine},
+	journal={The FreeBSD Forums},
+	howpublished={\url{https://web.archive.org/web/20210407104407/https://forums.freebsd.org/threads/fastnetmon-open-source-tool-to-detect-ddos-ddos.62032/}},
+	year=2017,
+	note={[online] Accessed: 2021-04-07},
+}
+
+@misc{fnm-fork-wayback,
+	title={FastNetMon - Archived view of Wofbit's fork with preserved history},
+	author="{The Internet Archive}",
+	publisher={Wayback Machine},
+	journal={GitHub repository},
+	howpublished={\url{https://web.archive.org/web/20210516225746/https://github.com/Wofbit/fastnetmon}},
+	year=2021,
+	note={[online] Accessed: 2021-05-16},
+}
+
+@misc{fnm-pulls-wayback,
+	title={Archived view of FastNetMon's closed Pull Requests},
+	author="{The Internet Archive}",
+	publisher={Wayback Machine},
+	journal={GitHub repository},
+	howpublished={\url{https://web.archive.org/web/20210329183006/https://github.com/pavel-odintsov/fastnetmon/pulls?q=is%3Apr+is%3Aclosed}},
+	year=2021,
+	note={[online] Accessed: 2021-03-29},
+}
+
 @misc{fastnetmonorig,
-	title={FasNetMon: Very Fast DDoS Mitigation Toolkit},
+	title={FasNetMon - very fast DDoS sensor with sFlow/Netflow/IPFIX/SPAN support},
 	author={Pavel Odintsov},
 	publisher={GitHub},
 	journal={GitHub repository},

tex/text.tex

@@ -55,8 +55,8 @@ setting up the infrastructure and the tools and processes to achieve a
 reproducible outcome. In \autoref{sec:mitigation-tools-set-up}, we set up
 mitigation tools in preparation of an attack. In
 \autoref{sec:attack-tools-set-up} we go through the process of preparing attack
-tools. Section \ref{sec:performing-an-attack} describes performing the attack
+tools. The final section \ref{sec:performing-an-attack} describes performing the attack
-itself. The final section \ref{sec:monitoring} observes the monitoring feeds.
+itself.
 
 
 % ============================================================================ %
@@ -77,7 +77,7 @@ excessive requests from the attacker.
 A DDoS is a DoS that is distributed among many participant devices (and
 operators).
 
-\begin{figure}
+\begin{figure}[!hbt]
   \centering
 \begin{tikzpicture}
   \draw (1,1)[color=red!60,thick,fill=red!15] circle (2.2cm);
@@ -133,10 +133,10 @@ attack:
 \begin{description}
   \item[By layers, in which the attacks are performed:]\
 \begin{itemize}
-\item link layer
+\item Link layer
-\item internet layer
+\item Internet layer
-\item transport layer
+\item Transport layer
-\item application
+\item Application layer
 \end{itemize}
   \end{description}
 
@@ -166,7 +166,7 @@ attack:
       presence in/near e.g. a datacenter, networking equipment (cutting cables,
       playing a pyro)
     \item[local network access] such as over a WiFi access point or on LAN
-    \item[remote] such as over the internet
+    \item[remote] such as over the Internet
   \end{description}
 \end{description}
 
@@ -243,7 +243,7 @@ many SYNs but stops there and leaves the connection hanging.
 
 One particularly sly method aimed at causing as much network congestion near/at
 the victim as possible is setting a private IP address (these are unroutable,
-or rather, \it{should not be routed} over public internet) or an address from
+or rather, \it{should not be routed} over public Internet) or an address from
 deallocated space as the source IP address. For the sake of the argument
 suppose it is an address from deallocated space, what then ends up happening is
 the server responds with a [SYN, ACK] and since no response comes from an address
@@ -261,7 +261,7 @@ other kind of complicated routing is used, then loose mode is recommended
 That way the spoofed traffic never leaves the source network (responsibility of
 the transit provider/ISP) and does not aggregate on a single host's interface.
 For this to be a reality the adoption rate of the subject RFC recommendations
-would need to see an proper increase.
+would need to see a proper increase.
 
 As is true for anything, if countermeasures are set up improperly, legitimate
 traffic could end up being blocked as a result.
@@ -381,18 +381,6 @@ Legitimate requests cannot be served as a result, since there is no way for the
 server to facilitate them until resources bound by bogus requests are freed,
 i.e. the attack ceases to be.
 
-\n{2}{iperf3}
-Massive load producing tool sending a packet flood of protocol of choice
-towards the target.
-
-\n{2}{ddosim}
-DDoS simulator methods of flooding:
-\begin{itemize}
-\item TCP
-\item UDP
-\item HTTP
-\end{itemize}
-
 \n{2}{Metasploit Framework}
 Metasploit is a penetration testing framework with an open source community
 version and a commercial version (Metasploit Unleashed) available. It enables
@@ -489,7 +477,7 @@ providers define multiple different blackhole communities each followed by a
 predefined action on the upstream. One is able to announce to these communities
 as needed.
 Assume we would announce to a community that would in response announce the
-blackhole to internet exchanges in, say, North America and Asia and but allow
+blackhole to Internet exchanges in, say, North America and Asia and but allow
 traffic coming from Europe, would be a perfect example of selective
 black-holing.
 This causes two things to happen. First, our customer's IP is still reachable
@@ -562,7 +550,7 @@ Team Cymru has got now a long tradition of maintaining bogons lists called the
 Internet routing table. A packet with an address from a bogon range should
 not be routed over the public Internet. These ranges are commonly found as the
 source addresses in DoS/DDoS attacks.\\
-Bogons are netblocks that have not been allocated to a regional internet
+Bogons are netblocks that have not been allocated to a regional Internet
 registry (RIR) by the Internet Assigned Numbers Authority (IANA) and Martian packets
 (private and reserved addresses defined by RFC 1918, RFC 5735, and RFC 6598
 \cite{rfc1918}, \cite{rfc5735}, \cite{rfc6598}).
@@ -650,7 +638,7 @@ single line: \texttt{reset\_timedout\_connection on;}
 
 \n{1}{Mitigation tools} \label{sec:mitigation-tools}
 No tools are going to remedy for a bad design decision and that applies
-equally to physical and internet engineering.
+equally to physical and Internet engineering.
 
 \n{2}{Firewall}
 No matter the specific implementation, it is presumably safe to say that
@@ -691,7 +679,7 @@ backward compatibility has been preserved) the former two - the
 \texttt{nftables} tool.
 
 \n{3}{Netfilter} \label{netfilter}
-The Linux kernel subsystem named \texttt{Netfilter} is part of the internet
+The Linux kernel subsystem named \texttt{Netfilter} is part of the Internet
 protocol stack of the kernel and is responsible for packet manipulation and
 filtering \cite{Boye2012NetfilterCT}. The packet filtering and classification
 rules framework frontend tools \texttt{iptables} as well as the newer
@@ -750,47 +738,23 @@ therefore be early-dropped at any time.
 \n{2}{FastNetMon DDoS Mitigation toolkit}
 Originally created by Pavel Odintsov, this program can serve as a helper on top
 of analysis and metric collection tools, evaluate data and trigger configurable
-mitigation reactions.
+mitigation reactions \cite{fastnetmonorig}, \cite{fastnetmonfork},
-\cite{fastnetmonorig}, \cite{fastnetmonfork}, \cite{fastnetmonng}
+\cite{fastnetmonng}.
 
-% \begin{Shaded}
+FastNetMon can run on most popular architectures an several different
-% \begin{Highlighting}[]
+general-purpose and specialised platforms such as Linux distributions, VyOS,
-    % \CommentTok{// Add host to blackhole}
+FreeBSD or Mikrotik devices. Most of the program is written in C++ but it uses
-    % \DataTypeTok{bool}\NormalTok{ add\_to\_blackhole(TemplateKeyType client\_id, }\DataTypeTok{attack\_details\_t}\NormalTok{ current\_attack) \{}
+many C libraries for additional functionality and also Perl install scripts. It
-        % \BuiltInTok{std::}\NormalTok{lock\_guard\textless{}}\BuiltInTok{std::}\NormalTok{mutex\textgreater{} lock\_guard(structure\_mutex);}
+has got a command line client and an API and analysis server. Its detection
-%
+engine is able to identify many types of flood attacks, fragmentation and
-% \NormalTok{        ban\_list\_storage[client\_id] = current\_attack;}
+amplification attacks. The metrics can be exported into an InfluxDB engine for
-        % \ControlFlowTok{return} \KeywordTok{true}\NormalTok{;}
+visualization. It is capable of interacting directly with BGP-enabled equipment
-% \NormalTok{    \}}
+and even supports Flow Spec.
-% \end{Highlighting}
-% \end{Shaded}
 
 
 % ============================================================================ %
 \part{Practical part}
-The plan:
-\begin{figure}
-  \centering
-  \begin{tikzpicture}
-    \fill[even odd rule,gray!30] circle (2.3) circle (2.2);
-      \arcarrow{2}{2.25}{2.5}{165}{200}{5}{red!50,
-        draw = red!50!black, very thick}{attack}
-      \arcarrow{2}{2.25}{2.5}{210}{260}{5}{blue!50,
-        draw = blue!50!black, very thick}{detection}
-      \arcarrow{2}{2.25}{2.5}{270}{320}{5}{green!50,
-        draw = green!50!black, very thick}{blackhole}
-      \arcarrow{2}{2.25}{2.5}{330}{460}{5}{blue!50,
-        draw = blue!50!black, very thick}{wait {\&} withdraw blackhole}
-      \arcarrow{2}{2.25}{2.5}{470}{515}{5}{blue!50,
-        draw = blue!50!black, very thick}{analysis}
-  \end{tikzpicture}
-  \caption{cunning plan} \label{fig:cunning-plan}
-\end{figure}
-
 \n{1}{Infrastructure Set-Up Description} \label{sec:infrastructure-set-up-description}
-% TODO
-Broader infrastructure description HERE.
-
 The testing was performed in a virtual lab comprised of five virtual machines
 (VMs) running on a KVM-enabled Fedora 34. Since the expectation was to
 frequently tweak various system settings of the guests (VMs) as part of the
@@ -846,95 +810,200 @@ If our upstream provider did not support RTBH signalling, in case we were
 attacked we could still use a scrubbing service but it is preferred that such a
 provider is picked that has the RTBH capabilities.
 
-FENIX in CR - trusted peers
+The cunning plan is to watch for traffic anomalies, when the attack comes
+detect it as soon as possible, trigger a reaction (announce a black hole), wait
+for some time, withdraw the black hole if the attack is gone and reintroduce it
+if it is still going on. Automatically, of course.
 
-Linux router SPAN/mirror ports configuration for packet capture to fastnetmon
+\begin{figure}[!hbt]
-(the only mode that makes nDPI integration possible)
+  \centering
-Linux netflow/sflow configuration for fastnetmon - slow
+  \begin{tikzpicture}
-all that with ansible roles
+    \fill[even odd rule,gray!30] circle (2.3) circle (2.2);
-BIRD for bgp, static routes for a poor man's router
+      \arcarrow{2}{2.25}{2.5}{165}{200}{5}{red!50,
+        draw = red!50!black, very thick}{attack}
+      \arcarrow{2}{2.25}{2.5}{210}{260}{5}{blue!50,
+        draw = blue!50!black, very thick}{detection}
+      \arcarrow{2}{2.25}{2.5}{270}{320}{5}{green!50,
+        draw = green!50!black, very thick}{blackhole}
+      \arcarrow{2}{2.25}{2.5}{330}{460}{5}{blue!50,
+        draw = blue!50!black, very thick}{wait {\&} withdraw blackhole}
+      \arcarrow{2}{2.25}{2.5}{470}{515}{5}{blue!50,
+        draw = blue!50!black, very thick}{analysis}
+  \end{tikzpicture}
+  \caption{The Cunning Plan} \label{fig:cunning-plan}
+\end{figure}
 
+Initially, two approaches for setting up infrastructure were considered.
+While both proposed to use KVM and \texttt{Terraform} with \texttt{libvirt}
+provider \cite{libvirt-tf-provider}, the first one planned to continue
+configuring the VMs with \texttt{cloud-init}, which is compatible with any
+GNU/Linux distribution. The finishing touches would be done using
+\texttt{ansible}. The second one, on the other hand, considered a newer
+technology - Fedora CoreOS, which uses a different paradigm where hosts are
+only customised on initial boot via \texttt{ignition} (although he
+configuration format used is called \it{Butane}, which uses YAML and is then
+transpiled to Ignition's JSON) and ran as configured, by default without a
+separate install disk. This provides the much needed system immutability during
+runtime but also makes it more difficult to configure. Configuration changes
+\it{can} be done during runtime, however, the CoreOS provisioning philosophy
+teaches that there is no need to deploy once and endlessly configure (by hand
+or e.g. with \texttt{ansible}) when boot times are short (Ignition runs before
+the userspace begins to boot) and the system is as minimal as possible
+(container-like).
 
-\nns{approach 0}
+\begin{description}
-\begin{itemize}
+  \item[approach 0:]\
-\item KVM
+  \begin{itemize}
-\item \texttt{terraform} with \texttt{libvirt} provider
+    \item KVM
-\item \texttt{cloud-init}
+    \item \texttt{terraform} with \texttt{libvirt} provider
-\item \texttt{ansible}
+    \item \texttt{cloud-init}
-\end{itemize}
+    \item \texttt{ansible}
+  \end{itemize}
+\end{description}
 
-\nns{approach 1}
+\begin{description}
-\begin{itemize}
+  \item[approach 1:]\
-\item KVM
+  \begin{itemize}
-\item \texttt{terraform}
+    \item KVM
-\item \texttt{ignition}
+    \item \texttt{terraform}
-\item Fedora CoreOS
+    \item \texttt{ignition}
-\end{itemize}
+    \item Fedora CoreOS
+  \end{itemize}
+\end{description}
 
-VMs required:
+We decided to go with the approach 0 as we felt it was more appropriate for our
-\begin{itemize}
+use case, which involves relatively lot of configuration.
-\item victim
+
-\item router - inner
+\begin{description}
-\item router - edge
+  \item[VMs required:]\
-\item attacker
+  \begin{itemize}
-\item defence machine
+    \item victim
-\end{itemize}
+    \item router - inner
+    \item router - edge
+    \item attacker
+    \item defence machine
+  \end{itemize}
+\end{description}
 See tab.~\ref{tab:vmspecifications} for details.
 
-Simulating multiple physical devices performing different roles
+To reiterate, simulating multiple physical devices performing different roles
-(routing, attacking, playing victim) in our attack-defence/mitigation
+(routing, attacking, playing victim) in our attack-defence/mitigation scenario
-scenario has been achieved by creating a test-lab virtual
+has been achieved by creating a test-lab virtual infrastructure.\\
-infrastructure.\\
+The tried-and-true way, state-of-the-art Linux kernel-native virtualization
-The tried-and-true way, state-of-the-art Linux kernel-native
+solution has been chosen to tackle the hypervisor task - the KVM technology.
-virtualization solution has been chosen to tackle the task of running VMs for
-us - the KVM technology.
 
-Testing has been performed on my personal laptop - Dell Latitude 5480
+Testing has been performed on our personal laptop - Dell Latitude 5480
-machine equipped with ULV dual-core Intel i5 Core 6300U processor with
+machine equipped with a ULV dual-core Intel i5 Core 6300U processor with
-\texttt{mitigations=off}, 24GB
+\texttt{mitigations=off}, 24GB (8+16) of RAM and a 512GB SATA SSD (TLC).
-(8+16) of RAM and a 512GB SATA SSD (TLC).
 
-The host operating system from the perspective of
+The host operating system from the perspective of VMs was \texttt{Fedora\ 34}.
-VMs was \texttt{Fedora\ 34}. Both \texttt{updates} and
+Both \texttt{updates} and \texttt{updates-testing} repositories have been
-\texttt{updates-testing} repositories have been enabled, which allowed us to use
+enabled, which allowed us to use latest (at the time) stable Linux kernel
-latest (at the time) stable Linux kernel Fedora had to offer directly without too much
+Fedora had to offer directly without too much of a hassle, as of the time of
-of a hassle, as of the time of writing in version \texttt{5.11.20}.
+writing in version \texttt{5.11.20}.
 
 File system in use on the host was Btrfs on top of LVM (LUKS+LVM to be
 precise) and a Btrfs subvolume has been created specifically for the
-libvirt storage pool. Since all of the system images for our VMs have been
+libvirt storage pool for better logical isolation (subvolumes are omited during
-downloaded in a QCOW2 format, the CoW (Copy-on-Write) feature of Btrfs has been
+snapshotting etc.; that way the lab does not end up in system snapshots. Since
-turned off for the subject subvolume, just as recommended in the Arch wiki
+all of the system images for our VMs have been downloaded in a QCOW2 format,
-[refneeded archwiki btrfs cow] for improved storage performance (and decreased
+the CoW (Copy-on-Write) feature of Btrfs has been turned off for the subject
-flash wear).
+subvolume, just as recommended in the Brfs Sysadmin Guide \cite{linuxbtrfs}
+for improved storage performance (and decreased flash wear).
 
 Notably, the system has also been using the \texttt{nftables} backend of
 \texttt{firewalld}, for which, luckily, \texttt{libvirt} was already
-prepared.
+prepared and played nice together.
+
+The whole infrastructure code resides in a git repository available at
+\url{https://git.dotya.ml/mirre-bt/tf-libvirt}.
+
+\n{2}{Terraform and Cloud-Init}
+Thanks to the \texttt{libvirt} provider for Terraform, VMs could easily be
+brought up and torn down. Terraform works by tracking state of the resources
+that together create the infrastructure, which can be described in numerous ways.
+Every resource that is absent needs to be created. Terraform uses a
+\emph{plan} of the infrastructure as it wants to \emph{apply} changes to the
+current \emph{state}. Every VM or a network, every backing storage is a
+resource that is managed for us, which is very convenient especially for
+testing.
+
+The initial boot configuration has been performed by Cloud-Init
+\cite{cloudinit}. It enabled us to configure users with SSH public keys to
+secure further connections, install packages and create arbitrary files.
+Scenario-role-specific configuration was made really easy thanks to this tool.
+
+\n{2}{Ansible}
+What has not been prepared by either Terraform or Cloud-Init was left to
+Ansible. It was used to deploy configurations of GoBGPd and FastNetMon, as well
+as to install and enable services.
 
 \n{1}{Mitigation tools set-up} \label{sec:mitigation-tools-set-up}
+\n{2}{FastNetMon}
 An open-source DDOS mitigation toolkit named \texttt{fastnetmon} was
 picked to serve as an attack detection tool. It supports analysing traffic from
 multiple different exporter types, including Netflow (v5 and v9), sFlow and port
 mirrors.
+We tried the installer from projects website, however, the
+installation did not appear to succeed. Therefore, we decided to build it from
+sources. That is when we uncovered some curious information.
 
-terraform multi-NIC VMs (or use virsh)\\
+The project's master branch on GitHub, where it is hosted, appears to have been
-ansible-gobgp role on fedora routers to set up bgpd\\
+modified on 22 June 2016 \cite{fnm-wayback} \cite{fastnetmonorig}. Since we
-Netflow exporter to report to fastnetmon\\
+knew about some propagation activities \cite{fnm-freebsd-wayback} and we found
-use iperf3 to attack\\
+the repo as "updated" on 17 Feb 2021 (that is what GitHub shows when e.g. a
-announce to a specified community to shut down the attack (black hole)
+description is updated) \cite{fnm-search-wayback} at the same time as we saw
+the last commit pushed with a 2016 date, we went digging over the project's
+forks to find out what happened to the project. They perfectly preserve it,
+from a point in time when the "fork" (essentially a clone) was created, up
+until the latest updates that have either been integrated from upstream or
+changed by the owner of the fork. While some forks have been abandoned a long
+time ago, several more showed the same tree with the exact same commits,
+referring to a common history.  Furthermore, the one thing giving away what
+apparently happened (not why) with almost certainty is the Pull Requests tab.
+It showed some 164 Closed PRs, some of them \it{merged} as late as 23 Dec 2020
+\cite{fnm-pulls-wayback}. That is, the history \it{has} indeed been overwritten
+and we have no information as to why, but that was also a reason why we chose
+to use one of the latest updated forks \cite{fnm-fork-wayback} \cite{fastnetmonfork}
+as a base for our work \cite{fastnetmonng} instead of the original upstream.
+The claim that the history has been overwritten is also supported by an earlier
+grab (snapshot) of the project by the Internet Archive's awesome \emph{Wayback
+Machine} \cite{fnm-early-wayback}, the rest have been triggered by us to help
+support the arguments in case anything changed.
 
+Ad setup itself, several changes had to be made to the project to make it even
+compile on recent hosts (Fedora 33/34, Arch Linux). A Drone CI build job has
+been set up to help make sure nothing breaks with our changes. Fastnetmon needs
+quite a lot of dependencies for its full functionality and the way to go about
+it in the project was using custom versions of the third party libraries to
+link against, all downloaded using the Perl install script mentioned earlier.
+While that might seem like a sound idea, we feel in the long run it is always
+better to use a reasonably recent distribution with sizable repositories and
+active community that, combined, are able to provide for most developer needs.
+The only major overhaul that had to be done was patching the
+\texttt{CMakeLists.txt} file to instruct CMake/Make to use system locations to
+look for headers and (dynamic) libraries (\texttt{.so} files) instead of
+download location from the install script. Further, to accomodate using newer
+version of \texttt{nDPI} (Open Source Deep Packet Inspection Software Toolkit)
+that aids FastNetMon with traffic sorting (if enabled), an interface and
+\texttt{fast\_dpi.h} header had to be updated. The history of all changes can be
+found in the repository at \url{https://git.dotya.ml/wanderer/fastnetmon-ng}.
 
-BGP black-holing upsides:
+For building and deployment to the defender host, an Ansible role has been
-\begin{itemize}
+created. It makes sure that FastNetMon is built correctly, installed and its
-\item quick and surgically precise way
+\texttt{systemd} service is \it{enabled} (at boot time) and started.
-\end{itemize}
 
-BGP black-holing weak spots:
+\n{2}{GoBGPd}
-\begin{itemize}
+We attempted to peer the two router VMs, however, we were not able to pin down
-  \item requires for our BGP peers to be available and willing to
+the proper configuration that would allow us to define a community tied to a
-    help/cooperate to advertise smaller subnets
+black-holing action.
-\end{itemize}
+
+\n{2}{Netflow}
+FastNetMon supports collecting Netflow metrics, therefore the edge router has
+been configured to listen on the upstream interface and to send traffic
+information to this FastNetMon's collector. The ansible role
+\url{github.com/juju4/ansible-fprobe} has been edited and used to deploy
+the configuration to the edge router.
 
 \n{1}{Attack tools set-up} \label{sec:attack-tools-set-up}
 When considering the way to simulate an attack locally, we weren't
@@ -943,26 +1012,47 @@ first "D" of DDOS) attack, instead the objective was mainly to congest
 the weakest link, which would happen to live inside our network (that's
 why we're concerned in the first place).
 
-\n{2}{iperf3}
-
 \n{2}{slowlorispy}
+With this python script there are a couple of flags to tweak the intended
+behaviour. Flag \texttt{-p} sets the port we want to target,
+\texttt{--sleeptime} allows us to rate-limit the tool so that we open as many
+connections as possible without getting banned. The \texttt{-s} flag specifies
+the number of sockets we want to open.
+
+\n{2}{iperf3}
+This tool works in server-client mode. To receive traffic, it \texttt{runs in
+server mode} and listens on port 5201 by default, although both the traffic
+direction and port and multitude of other parameters can be configured.
+To listen on the victim server, we simply ran \texttt{iperf3 -s -P 8} to
+receive 8 parallel streams.
+Then on the client - the attacker - we entered \texttt{iperf3 -c \{server
+ip\} -P 8} to send 8 parallel streams to the victim. This filled the available
+link bandwidth but, unfortunately, we haven not observed FastNetMon ban action
+even though the threshold has been crossed.
 
-\n{2}{Metasploit \texttt{aux/synflood module}}
 
 \n{1}{Performing an attack} \label{sec:performing-an-attack}
-run the tools
+We were not able to extinguish connections on the server using
+\texttt{slowloris.py}, presumably because the inactive connections were quickly
+being closed. While the number of used sockets steadily grew, after about 5000
+this tool was not able to open any new connections and the server worked fine.
 
-\n{1}{Monitoring} \label{sec:monitoring}
+As per running FastNetMon attack traffic detection, we have experienced
-\begin{itemize}
+unexpected troubles in the form of fastnetmon incorrectly reporting 0pps for
-\item fastnetmon metrics
+both outbound and inbound traffic. We were not able to uncover the root cause
-\item packet capture on the router interfaces
+of the issue.
-\item Netflow signalling
-\end{itemize}
 
-juju4/ansible-fprobe netflow role
 
 % ============================================================================ %
 \nn{Conclusion}
+The goal of our work was to describe some of the popular types of DoS attacks,
+casually used attack methods and tools. In the theoretical part, we also
+outlined mitigation methods available to network operators and end users alike,
+along with their scope and reach. Next, we looked at tools that aid mitigating
+DoS attacks.
+In the practical part, we have arrived at unexpected results, where we were not
+able to fully simulate the black hole propagation among ASes due to
+configuration inconsistencies. Unfortunately, this stays as a challenge for us.
 
 
 % ============================================================================ %