mirre-bt/bc-thesis
1
0
Fork 0
Code Issues Pull Requests Releases Activity

chore: update table, add infra info, reword stuff

Browse Source
This commit is contained in:
surtur 2021-05-13 01:43:46 +02:00
parent f5e42160d0
commit a01e1a2621
Signed by: wanderer
GPG Key ID: 19CE1EC1D9E0486D
1 changed files with 20 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
tex/text.tex
View File

@ -664,17 +664,26 @@ Supported proxy programs are \texttt{nginx}, \texttt{apache}.
% TODO % TODO
Broader infrastructure description HERE. Broader infrastructure description HERE.
The disk sizes of the VMs were determined by the size of their base image.
The VM naming convention is specified as follows: a prefix \texttt{r\_} for
routers and \texttt{h\_} for other hosts, in our case the attacker, victim and
defenter machines.
\n{2}{VM specifications} \n{2}{VM specifications}
\tab{VM specifications}{tab:vmspecifications}{0.75}{ |c|r|r|r|r|c| }{ \tab{VM specifications}{tab:vmspecifications}{0.75}{ |c||rrrrc| }{
\hline \hline
\bf{VM name} & \bf{vCPU(s)} & \bf{RAM} & \bf{disk space} & \bf{net ifaces} & \bf{VM name} & \bf{vCPU(s)} & \bf{RAM} & \bf{disk space} & \bf{net ifaces} &
\bf{operating system} \\ \bf{operating system} \\
\hline\hline \hline\hline
upstream router & 1 & 1GB & 2GB & {outer,DMZ} & OpenWRT Qemu \\ r\_upstream & 1 & 768MB & 4.3GB & {outer,DMZ} & Fedora 33 \\
edge router & 1 & 1GB & 2GB & {DMZ,inner} & OpenWRT Qemu \\ \hline
victim & 1 & 512MB & 4.3GB & {inner} & Fedora 34 \\ r\_edge& 1 & 768MB & 4.3GB & {DMZ,inner} & Fedora 33 \\
attacker & 1 & 1GB & 4.3GB & {outer} & Fedora 34 \\ \hline
defender & 1 & 1GB & 5GB & {DMZ} & Fedora 34 \\ h\_victim & 1 & 768MB & 11GB & {inner} & CentOS 8 \\
\hline
h\_attacker & 1 & 1GB & 5.37GB & {outer} & Fedora 34 \\
\hline
h\_defender & 1 & 1GB & 5.37GB & {DMZ} & Fedora 34 \\
\hline \hline
} }
The inner (our edge) and the upstream (our transit provider) routers are The inner (our edge) and the upstream (our transit provider) routers are
@ -744,14 +753,14 @@ The host operating system from the perspective of
VMs was \texttt{Fedora\ 34}. It had \texttt{updates} and VMs was \texttt{Fedora\ 34}. It had \texttt{updates} and
\texttt{updates-testing} repositories enabled, which allowed us to use \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 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}. of a hassle, as of the time of writing in version \texttt{5.11.19}.
File system in use on the host has been Btrfs on top of LVM (LUKS+LVM to be 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 precise) and a Btrfs subvolume has been created specifically for the
libvirt storage pool. Since most of the system images for the VMs come libvirt storage pool. Since most of the system images for our VMs have been
in a QCOW2 format, the CoW (Copy-on-Write) feature of Btrfs has been downloaded 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 turned off for the subject subvolume, just as recommended in the Arch wiki
wiki [refneeded archwiki btrfs cow]. [refneeded archwiki btrfs cow].
Notably, the system has also been using the \texttt{nftables} backend of Notably, the system has also been using the \texttt{nftables} backend of
\texttt{firewalld}, for which, luckily, \texttt{libvirt} was already \texttt{firewalld}, for which, luckily, \texttt{libvirt} was already