chore: add initial bits of the practical part

tex/text.tex

@@ -9,6 +9,126 @@
 % ============================================================================ %
 \part{Practical part}
 
+\n{1}{infrastructure description}
+% TODO
+Broader infrastructure description HERE.
+
+\n{2}{VM specifications}
+\tab{VM specifications}{tab:vmspecifications}{0.75}{ |c|r|r|r|r|c| }{
+  \hline
+  \bf{VM name} & \bf{vCPU(s)} & \bf{RAM} & \bf{disk space} & \bf{net ifaces} &
+  \bf{operating system} \\
+  \hline\hline
+  edge router & 1 & 1GB & 2GB & {outer,DMZ} & OpenWRT Qemu \\
+  inner router & 1 & 1GB & 2GB & {DMZ,inner} & OpenWRT Qemu \\
+  victim & 1 & 512MB & 4.3GB & {inner} & Fedora 34 \\
+  attacker & 1 & 1GB & 4.3GB & {outer} & Fedora 34 \\
+  defender & 1 & 1GB & 5GB & {DMZ} & Fedora 34 \\
+  \hline
+}
+
+
+\n{1}{infrastructure set-up}
+
+\nns{approach 0}
+\begin{itemize}
+\tightlist
+\item KVM
+\item \texttt{terraform} with \texttt{libvirt} provider
+\item \texttt{cloud-init}
+\item \texttt{ansible}
+\end{itemize}
+
+\nns{approach 1}
+\begin{itemize}
+\tightlist
+\item KVM
+\item \texttt{terraform}
+\item \texttt{ignition}
+\item Fedora CoreOS
+\end{itemize}
+
+VMs required:
+\begin{itemize}
+\tightlist
+\item victim
+\item router - inner
+\item router - edge
+\item attacker
+\item defence machine
+\end{itemize}
+See tab.~\ref{tab:vmspecifications} for details.
+
+Simulating multiple physical devices performing different roles
+(routing, attacking, playing victim) in our attack-defence/mitigation
+scenario has been achieved by creating a test-lab virtual
+infrastructure.\\
+The tried-and-true way, state-of-the-art Linux kernel-native
+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
+machine equipped with ULV dual-core Intel i5 Core 6300U processor, 24GB
+(8+16) of RAM and a 512GB SATA SSD (TLC).
+
+The host operating system from the perspective of
+VMs was \texttt{Fedora\ 34}. It had \texttt{updates} and
+\texttt{updates-testing} repositories enabled, which allowed us to use
+latest (at the time) stable Linux kernel Fedora had to offer directly without too much
+of a hassle, as of the time of writing in version \texttt{5.11.16}.
+
+File system in use on the host has been Btrfs on top of LVM (LUKS+LVM to be
+precise) and a Btrfs subvolume has been created specifically for the
+libvirt storage pool. Since most of the system images for the VMs come
+in a QCOW2 format, the CoW (Copy-on-Write) feature of Btrfs has been
+turned off for the subject subvolume, just as recommended in the Arch
+wiki [archwiki btrfs cow ref needed].
+
+Notably, the system has also been using the \texttt{nftables} backend of
+\texttt{firewalld}, for which, luckily, \texttt{libvirt} was already
+prepared.
+
+\n{1}{Mitigation tools set-up}
+An open-source DDOS mitigation toolkit named \texttt{fastnetmon} was
+chosen...
+
+BGP blackholing upsides:
+\begin{itemize}
+\tightlist
+\item quick and surgically precise way
+\end{itemize}
+
+BGP blackholing weak spots:
+\begin{itemize}
+\tightlist
+\item requires for our BGP peers to be available and willing to help/cooperate to advertise smaller subnets
+\end{itemize}
+
+\n{1}{Attack tools set-up}
+When considering the way to simulate an attack locally, we weren't
+primarily looking for a tool, which would enable a decentralised (the
+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}{hoic}
+
+\n{2}{iperf3}
+
+\n{2}{slowlorispy}
+
+\n{2}{metasploit \texttt{aux/synflood module}}
+
+\n{1}{Performing an attack}
+run the tools
+
+\n{1}{Monitoring}
+\begin{itemize}
+\tightlist
+\item fastnetmon metrics
+\item packet capture on the router interfaces
+\item Netflow signalling
+\end{itemize}
 
 % ============================================================================ %
 \nn{Conclusion}