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

add: batch 5

Browse Source
This commit is contained in:
surtur 2021-05-17 21:10:50 +02:00
parent 5003c8a036
commit 847fca9f9e
Signed by: wanderer
GPG Key ID: 19CE1EC1D9E0486D
5 changed files with 336 additions and 141 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
prace.tex
View File

@ -61,10 +61,21 @@
\nastavautora{AM}
\nastavnazevcz{}
\nastavnazeven{Protecting Internet Networks Against DoS Attacks} % Jen u anglicky psané práce
\nastavabstraktcz{}
\nastavabstrakten{}
\nastavklicovaslovacz{DDoS, Sítě, BGP, Black-holing}
\nastavklicovaslovaen{DDoS, Networks, BGP, Black-holing}
\nastavabstraktcz{V tejto práci sme analyzovali bežné spôsoby prevádzkovania
Denial of Service útokov, ako aj niektoré zo známych nástrojov, ktorými sa
útoky vykonávajú. Na druhej strane sme sa pojednávali o regulérne používaných
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

1
tex/abbreviations.tex
View File

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

6
tex/appendices.tex
View File

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

89
tex/references.bib
View File

@ -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},

324
tex/text.tex
View File

@ -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
itself. The final section \ref{sec:monitoring} observes the monitoring feeds.
tools. The final section \ref{sec:performing-an-attack} describes performing the attack
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 internet layer
\item transport layer
\item application
\item Link layer
\item Internet layer
\item Transport layer
\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.
\cite{fastnetmonorig}, \cite{fastnetmonfork}, \cite{fastnetmonng}
mitigation reactions \cite{fastnetmonorig}, \cite{fastnetmonfork},
\cite{fastnetmonng}.
% \begin{Shaded}
% \begin{Highlighting}[]
% \CommentTok{// Add host to blackhole}
% \DataTypeTok{bool}\NormalTok{ add\_to\_blackhole(TemplateKeyType client\_id, }\DataTypeTok{attack\_details\_t}\NormalTok{ current\_attack) \{}
% \BuiltInTok{std::}\NormalTok{lock\_guard\textless{}}\BuiltInTok{std::}\NormalTok{mutex\textgreater{} lock\_guard(structure\_mutex);}
%
% \NormalTok{ ban\_list\_storage[client\_id] = current\_attack;}
% \ControlFlowTok{return} \KeywordTok{true}\NormalTok{;}
% \NormalTok{ \}}
% \end{Highlighting}
% \end{Shaded}
FastNetMon can run on most popular architectures an several different
general-purpose and specialised platforms such as Linux distributions, VyOS,
FreeBSD or Mikrotik devices. Most of the program is written in C++ but it uses
many C libraries for additional functionality and also Perl install scripts. It
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
amplification attacks. The metrics can be exported into an InfluxDB engine for
visualization. It is capable of interacting directly with BGP-enabled equipment
and even supports Flow Spec.
% ============================================================================ %
\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,32 +810,72 @@ 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
(the only mode that makes nDPI integration possible)
Linux netflow/sflow configuration for fastnetmon - slow
all that with ansible roles
BIRD for bgp, static routes for a poor man's router
\begin{figure}[!hbt]
\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{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}
\item[approach 0:]\
\begin{itemize}
\item KVM
\item \texttt{terraform} with \texttt{libvirt} provider
\item \texttt{cloud-init}
\item \texttt{ansible}
\end{itemize}
\end{description}
\nns{approach 1}
\begin{description}
\item[approach 1:]\
\begin{itemize}
\item KVM
\item \texttt{terraform}
\item \texttt{ignition}
\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
use case, which involves relatively lot of configuration.
\begin{description}
\item[VMs required:]\
\begin{itemize}
\item victim
\item router - inner
@ -879,62 +883,127 @@ VMs required:
\item attacker
\item defence machine
\end{itemize}
\end{description}
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.
To reiterate, 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 hypervisor task - 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 with
\texttt{mitigations=off}, 24GB
(8+16) of RAM and a 512GB SATA SSD (TLC).
Testing has been performed on our personal laptop - Dell Latitude 5480
machine equipped with a ULV dual-core Intel i5 Core 6300U processor with
\texttt{mitigations=off}, 24GB (8+16) of RAM and a 512GB SATA SSD (TLC).
The host operating system from the perspective of
VMs was \texttt{Fedora\ 34}. Both \texttt{updates} and
\texttt{updates-testing} repositories have been 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.20}.
The host operating system from the perspective of VMs was \texttt{Fedora\ 34}.
Both \texttt{updates} and \texttt{updates-testing} repositories have been
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.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
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 wiki
[refneeded archwiki btrfs cow] for improved storage performance (and decreased
flash wear).
libvirt storage pool for better logical isolation (subvolumes are omited during
snapshotting etc.; that way the lab does not end up in system snapshots. Since
all of the system images for our VMs have 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 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)\\
ansible-gobgp role on fedora routers to set up bgpd\\
Netflow exporter to report to fastnetmon\\
use iperf3 to attack\\
announce to a specified community to shut down the attack (black hole)
The project's master branch on GitHub, where it is hosted, appears to have been
modified on 22 June 2016 \cite{fnm-wayback} \cite{fastnetmonorig}. Since we
knew about some propagation activities \cite{fnm-freebsd-wayback} and we found
the repo as "updated" on 17 Feb 2021 (that is what GitHub shows when e.g. a
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:
\begin{itemize}
\item quick and surgically precise way
\end{itemize}
For building and deployment to the defender host, an Ansible role has been
created. It makes sure that FastNetMon is built correctly, installed and its
\texttt{systemd} service is \it{enabled} (at boot time) and started.
BGP black-holing weak spots:
\begin{itemize}
\item requires for our BGP peers to be available and willing to
help/cooperate to advertise smaller subnets
\end{itemize}
\n{2}{GoBGPd}
We attempted to peer the two router VMs, however, we were not able to pin down
the proper configuration that would allow us to define a community tied to a
black-holing action.
\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}
\begin{itemize}
\item fastnetmon metrics
\item packet capture on the router interfaces
\item Netflow signalling
\end{itemize}
As per running FastNetMon attack traffic detection, we have experienced
unexpected troubles in the form of fastnetmon incorrectly reporting 0pps for
both outbound and inbound traffic. We were not able to uncover the root cause
of the issue.
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.
% ============================================================================ %