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

add: batch 4

Browse Source 
* add intro and section text
* correct typos
* wrap long lines
* add labels to section titles
* add references
* add circular arrows graph (tikz)
* add overlapping sets graph (tikz)
This commit is contained in:
surtur 2021-05-16 10:29:20 +02:00
parent ef40e1da6b
commit 64304a851e
Signed by: wanderer
GPG Key ID: 19CE1EC1D9E0486D
1 changed files with 216 additions and 113 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

319
tex/text.tex
View File

@ -1,21 +1,74 @@
% ============================================================================ %
\nn{Introduction}
What we have commonly seen being used in the wild in recent years may be
called "professionalizing", by which I mean that what would typically be available 10
years ago cannot match to practically anything you can get ready in minutes to
cause real harm today.
In this day and age, there has probably been nothing else considered as
inevitable and impactful on one's personal or professional life, media,
politics, culture or science as reliable Internet connection, allowing seemless
interaction and access to information.
Networking infrastructure powering the Internet has been the target of various
attacks almost since day one. While the early network interconnections had
been based on mutual trust and strong sharing spirit for advancement of humanity, with
increasing amount of participants from different backgrounds (essentially
democratization) and proliferating deeds of mischief, trust could no longer be
taken for granted.
Although trolling has always been an integral part of the Internet culture, it
had not taken long until criminals found their way into the online world with
the intention of taking advantage of lacking legislation and collecting easy
(though huge) economic profit. Furthermore, another popular activity has become
causing real harm to anybody on the way with the sense of lawlessness.
It is this willful damage in its many shapes and forms brought upon the
Internet service providers and users that our thesis deals with. What we have
commonly observed as being used in the wild in recent years may be called
attack 'professionalizing', by which we mean that the tools typically available
10 years ago cannot match to practically anything you can get ready in minutes
to cause real harm today. Since the networks compose the medium of
communication, it is essential they remained secured and protected, which in
fact poses a challenging task for us of coming up with new solutions to rapidly
evolving problem.
On the side of the user, unavailability of the service often means inability to
proceed with fulfilling their tasks. For the provider, an attack that cripples
the network or its resources means inability to provide the promised service.
We would like to take a look on some of the conventional methods and tools
which attackers resort to as well as methods and tools both users and network
operators may (and should) utilise to protect the network. The main objectives
of our thesis aim at researching key ways of DoS attack mitigations and
performing a DoS attack and a BGP blackhole reaction simulation.
Our thesis comprises two main parts - theoretical and practical. The
theoretical part discusses relevant context, different types of attack methods
and tools, mitigation attack methods and tools. The practical part describes a
simulated simple topology and an attack in lab conditions.
In the first section of the theoretical part, we were focused on attack
definition. Section \ref{sec:attack-methods} attempts to categorise attack
methods based on several metrics and explain some of the mentioned. The third
section presents a list of some of the popular DoS tools that are available.
Next on, the \autoref{sec:mitigation-methods} traces various ways to mitigate
attacks, both on the user and provider level and the final section of the
theoretical part, \autoref{sec:mitigation-tools}, marks out some of the tools
that can be used to mitigate an attack.
First of the practical part, \autoref{sec:infrastructure-set-up-description} gives an
overview of the tools used to construct the lab infrastructure and configure
the systems, as well as specifics of the configuration. It also focuses on
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.
% ============================================================================ %
\part{Theoretical part}
\n{1}{Definition} \label{sec:definition}
While denial of service can be caused in a multitude of different ways and
impact any part of the stack, we are predominantly going to look at the ones
pertaining internet networks.
\n{1}{Definition}
First we shall define what a denial of service (\it{DoS}) attack \it{is} and that
can be achieved by looking at what it does.
pertaining Internet networks. First, we shall define what a denial of service
(\it{DoS}) attack in fact \it{is} and we can achieve it by understanding what
it does.
A DoS attack is an action that harms a \it{service} in such a way that it can
no longer serve legitimate requests as a result of being occupied by bogus or
@ -24,6 +77,17 @@ excessive requests from the attacker.
A DDoS is a DoS that is distributed among many participant devices (and
operators).
\begin{figure}
\centering
\begin{tikzpicture}
\draw (1,1)[color=red!60,thick,fill=red!15] circle (2.2cm);
\draw (0.4,0.2pt) node[below left] {$DoS$};
\draw (1,1)[dashed,fill=purple!25] circle (1.2cm);
\draw (1,5pt) node[above] {$DDoS$};
\end{tikzpicture}
\caption{Illustration of relationship between DoS and DDoS attacks.}
\end{figure}
The devices participating are generally also victims in this, most of the
attacks are performed with open DNS resolvers, home routers left to rot by
vendors, misconfigured web services or IoT devices as involuntary
@ -33,34 +97,37 @@ start probing and then reap the easy harvest. A quick search for devices
running with port 123 (NTP) open is certain to return a mind-blowing number
\cite{ShodanNTPd}.
\n{1}{Context}
Only in the past decade we have witnessed many large DoS/DDoS attacks, some of them
against critical infrastructure services like cloud hosting, DNS, git hosting
services or CCTV cameras. All of the attacks weaponized poorly managed
endpoints, unpatched IoT devices or
malware-infected-hosts-turned-botnet-zombies. The intensity and frequency has
also been sharply increasing, with the latest of attacks passing over the Tbps
\n{1}{Context} \label{sec:context}
In the last decade only we have witnessed many large DoS/DDoS attacks, some of
them against critical infrastructure services like cloud hosting, DNS, git
hosting services or even CCTV cameras. All of the attacks weaponized poorly
managed endpoints, unpatched IoT devices or
malware-infected-hosts-turned-botnet-zombies. The intensity and frequency have
also been sharply increasing with the latest of attacks passing over the Tbps
threshold (Akamai mitigated a 1.44Tbps DDoS in 2020
\cite{akamai2020ddosretrospect}), data from Cisco noting that overall, there
was a \textbf{776\%} growth in attacks between 100 Gbps and 400 Gbps from 2018 to 2019
and predictions for the total number of DDoS attacks to double from 7.9 million
in 2018 to 15.4 million by 2023 \cite{cisco2020report}. The question is: why?
\cite{akamai2020ddosretrospect}), with data from Cisco Annual Internet Report
showing that overall there was a \textbf{776\%} growth in attacks between 100
Gbps and 400 Gbps from 2018 to 2019, and with predictions for the total number
of DDoS attacks to double from 7.9 million in 2018 to 15.4 million by 2023
\cite{cisco2020report}. The question is: why?
There motifs will probably more often than not stay a mystery, however, a
proliferation of DDoS-for-hire websites \cite{Santanna2018BooterLG} even on
\emph{clearnet} points us to a plausible answer.
The motifs will probably more often than not stay a mystery; however, a
proliferation of DDoS-for-hire websites \cite{Santanna2018BooterLG}, even on
\emph{clearnet}\footnotemark, points us to a plausible answer.
\footnotetext{the surface web; i.e.\ not even attempting to hide}
Somebody is making money selling abusive services that are being used for
putting competitors out of business or just plain extortion. According to
Akamai, extortion attacks have seen a widespread return, with a new wave launching in mid-August
2020 \cite{akamai2021ddos}.
Akamai, extortion attacks have seen a widespread return, with a new wave
launching in mid-August 2020 \cite{akamai2021ddos}.
Akamai went on to note that DDoS attackers are expanding their reach across
geographies and industries, with the number targeted entities now being 57\%
geographies and industries, with the number of targeted entities now being 57\%
higher than the year before that.
\n{1}{Attack methods}
\n{1}{Attack methods} \label{sec:attack-methods}
There are generally several different ways to categorise a method of
attack:
\begin{description}
@ -109,11 +176,12 @@ attack:
\item IP fragmentation
\item SYN flood - a rapid sequence of TCP protocol SYN messages
\item volumetric DDoS attack
\item amplification attack (also called "reflection attack")
\item amplification attack (also called 'reflection attack')
\begin{itemize}
\item memcached exploit (1:51200)
\item DNS (\textasciitilde1:50), with a formula \cite{akamaidnsampl} \[R = answer size / query size\]
\item SNMP
\item memcached (up to 1:51200)
\item DNS with a formula \cite{akamaidnsampl}
\rov[DNSamplificationformula]{R = answer size / query size}
\item SNMP (theoretically 1:650)
\item NTP
\end{itemize}
\item exploits
@ -142,7 +210,8 @@ packets, ideally even accompanied by a buffer overflow that the attacker can
exploit further. Fragmenting TCP segments, on the other hand, targets the TCP
mechanism for reassembly. Reasonably recent Linux kernel implements protection
against this \cite{linuxretransmission}.
In either case, this is a network layer attack, since it targets the way the Internet Protocol requires data to be transmitted and processed.
In either case, this is a network layer attack, since it targets the way the
Internet Protocol requires data to be transmitted and processed.
\n{2}{SYN flood} \label{synfloodattack}
To establish a TCP connection, a \emph{three way handshake} must be
@ -163,7 +232,7 @@ A malicious actor is able to misuse the handshake mechanism by posing as a
legitimate \emph{client} (or rather many legitimate clients) and sending large
number of SYN segments to a \emph{server} willing to establish a connection
(\it{LISTEN} state). The server replies with a [SYN, ACK], which is a combined
acknowledgement of the clients request \it{and} a synchronization request of
acknowledgement of the client's request \it{and} a synchronization request of
its own. The client responds back with an ACK and then the connection reaches
the \it{ESTABLISHED} state.
@ -194,7 +263,8 @@ 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.
As is true for anything, if countermeasures are set up improperly, legitimate traffic could end up being blocked as a result.
As is true for anything, if countermeasures are set up improperly, legitimate
traffic could end up being blocked as a result.
\n{2}{Amplified Reflection Attack}
The name suggests this type of attack is based on two concepts: amplification and
@ -215,8 +285,9 @@ request with (either a bogus but more commonly) a victim IP address as the
source address instead of our own that's present there by default.
The response is then returned \it{back} - not to the actual sender, but simply
according to the source address.\\
Since UDP has no concept of a \it{connection} or any verification mechanism, the response arrives at the door of the victim that has never asked for
it - in the worst case an unsolicited pile of them.
Since UDP has no concept of a \it{connection} or any verification mechanism,
the response arrives at the door of the victim that has never asked for it - in
the worst case an unsolicited pile of them.
This is why the three-way handshake is used with TCP, which was developed later
than UDP, as it reduces the possibility of false connections.
@ -282,7 +353,7 @@ remotely from end hosts without access to routers or the ability to send
traffic directly to them.
\n{1}{Attack tools}
\n{1}{Attack tools} \label{sec:attack-tools}
Believe it or not there actually exists a DDoS attack tools topic on
GitHub
\url{https://github.com/topics/ddos-attack-tools?o=desc\&s=stars}.
@ -311,7 +382,8 @@ 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.
Massive load producing tool sending a packet flood of protocol of choice
towards the target.
\n{2}{ddosim}
DDoS simulator methods of flooding:
@ -323,13 +395,13 @@ DDoS simulator methods of flooding:
\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 security
researchers to automate workflows of probing vulnerable services or devices via
use of so called modules - smaller programs with definable inputs that perform
prefined actions. Modules are often community-contributed and one can even
write a module ourselves.a The SYN-flooding funtionality has been implemented -
\texttt{aux/synflood} an auxiliary module. Auxiliary modules do not execute
payloads and perform arbitrary actions that may not be related to
version and a commercial version (Metasploit Unleashed) available. It enables
security researchers to automate workflows of probing vulnerable services or
devices via use of so called modules - smaller programs with definable inputs
that perform prefined actions. Modules are often community-contributed and one
can even write a module ourselves.a The SYN-flooding funtionality has been
implemented - \texttt{aux/synflood} an auxiliary module. Auxiliary modules do
not execute payloads and perform arbitrary actions that may not be related to
exploitation, such as scanning, fuzzing and denial of service attacks
\cite{metasploit}.
@ -345,15 +417,15 @@ thing as discussed above, the only difference is the malicious intent,
imperceivable to a machine.
\n{1}{Mitigation methods}
\n{1}{Mitigation methods} \label{sec:mitigation-methods}
Drastic times require drastic measures and since a DDoS attacks coming
at us practically every other month classify as
\it{drastic} quite easily, we're forced to act accordingly
\cite{akamai2021ddos}.
Still, it is more reasonable to prepare than to improvise, therefore the
following write-up mentions of commonly used mitigation methods at different levels,
from a hobbyist server to an e-commerce service to an ISP. The list is
following write-up mentions of commonly used mitigation methods at different
levels, from a hobbyist server to an e-commerce service to an ISP. The list is
inconclusive and of course if reading this at a later date, always cross-check
with the current best practices at the time.
@ -380,8 +452,9 @@ For the entire time we're announcing it, the victim host stays unreachable.
We should make sure to announce the smallest possible prefix to minimise the
collateral damage. Generally, a /21 or /22 prefix is assigned to an AS (the
average prefix per AS being 22.7866 as of 11 May 2021 \cite{prefixavgsize}) announcing a black hole
for such a large space would likely cause more damage than the attack itself.
average prefix per AS being 22.7866 as of 11 May 2021 \cite{prefixavgsize})
announcing a black hole for such a large space would likely cause more damage
than the attack itself.
To reduce BGP overhead, prefixes are usually announced aggregated, with the
exception of "a~situation", such as when we wish to only stop receiving traffic
@ -413,10 +486,12 @@ flowing\footnotemark!
Behold, this is what \it{selective black-holing} actually is. Some upstream
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.
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
traffic coming from Europe, would be a perfect example of selective black-holing.
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
from our local area (e.g. Europe) and since our fictitious customer mostly
serves European customers that's fine. Second, outside of the prefedined radius
@ -429,11 +504,12 @@ it is reasonably automated and quick to respond, in combination with other
mitigation methods it can provide a viable protection for the network.
\n{2}{Sinkholing}
Moving on, this method works by diverting only malicious traffic away from its target,
usually using a predefined list of IP addresses known to be part of malicious
activities to identify DDoS traffic. False positives can occur more rarely and
collateral damage is lesser than with black-holing but since botnet IPs can be
also used by legitimate users this is still prone to false positives.
Moving on, this method works by diverting only malicious traffic away from its
target, usually using a predefined list of IP addresses known to be part of
malicious activities to identify DDoS traffic. False positives can occur more
rarely and collateral damage is lesser than with black-holing but since botnet
IPs can be also used by legitimate users this is still prone to false
positives.
Additionally, sinkholing as such is ineffective against IP
spoofing, which is a common feature in network layer attacks.
@ -447,8 +523,8 @@ scrubbing at an inline rate without impacting legitimate users.
If outsourced, the scrubber service has the bandwidth capacity (either
on-demand or permanently) to take the hit that we do not have. There are at
least two ways to go about this - the BGP and the DNS way, we will cover the BGP
one. Once an attack is identified, we stop announcing the prefix that is
least two ways to go about this - the BGP and the DNS way, we will cover the
BGP one. Once an attack is identified, we stop announcing the prefix that is
currently being hit, contact our scrubbing provider (usually
automatically/programatically) to start announcing the subject prefix,
receiving all its traffic (including the attack traffic), the scrubbing service
@ -459,10 +535,10 @@ appliance that has to have sufficient bandwidth (usually on par with upstream).
A poor man's scrubber:
\begin{itemize}
\item hardware accelerated ACLs on switches,
\item switches do simple filtering at \it{inline rate} (ASICs)
\item can be effective when attack protocol is easily distinguishable from real
traffic
\item utilizing hardware accelerated ACLs on switches,
\item switches can do simple filtering at \it{inline rate} (ASICs)
\item this can be effective when attack protocol is easily distinguishable from
real traffic
\item hit by NTP/DNS/SNMP/SSDP amplification attack
\end{itemize}
@ -472,8 +548,12 @@ our network (such as 123 or 53), we start signalling to our upstream
providers, since they can probably handle it better than us and have as much
interest in doing so as us (or should).
One thing we should do no matter whether we are currently suffering an attack (and
scrubbing it ourselves) is to rule out and drop and never receive traffic
Volumetric attacks sending traffic in smaller packet sizes will, however,
still result in higher CPU utilization, especially on non-dedicated networking
equipment.
One thing we should do no matter whether we are currently suffering an attack
(and scrubbing it ourselves) is to rule out and drop and never receive traffic
appearing to come from \it{our own network}, since such traffic could not exist
naturally and is obviously spoofed.
@ -493,10 +573,8 @@ Team Cymru \cite{teamcymru}.
In case we have our own ASN, are connected directly at an IXP, have no
RTBH support upstream and basically have no other choice, we just need
to find out who is sending the malicious traffic, drop the session and receive
traffic from other peers.
64B packet size --> lower throughput, high cpu utilization
to find out who is sending the malicious traffic and, if possible, drop the
session and receive traffic from other peers.
\n{2}{IP masking} \label{ipmasking}
@ -541,7 +619,8 @@ open simultaneously, which can even prevent Slowloris (see \ref{slowloris}).
Rate-limiting is usually set either on a proxy or a WAF, but some form of
rate-limiting can even be built into an app.
A well known rate-limiting pluggable solution that can be used with SSHd, HTTP or multitude of other endpoints is \texttt{Fail2Ban}.
A well known rate-limiting pluggable solution that can be used with SSHd, HTTP
or multitude of other endpoints is \texttt{Fail2Ban}.
\n{2}{Decreased-TIME\_WAIT connection closing}
@ -569,7 +648,7 @@ prevent such a situation from occurring easily. In Nginx this is set with a
single line: \texttt{reset\_timedout\_connection on;}
\n{1}{Mitigation tools}
\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.
@ -584,10 +663,10 @@ There are two main types of firewalls:
\end{itemize}
A software firewall is just another program running on the operating
system, apart from the fact that it is typically running with
system-level privileges. It can be run on a general-purpose computer. In fact
most of the consumer-grade operating systems nowadays incorporate or by default
enable a firewall solution.
system, apart from the fact that it is typically running with system-level
privileges. It can be run on a general-purpose computer. In fact most of the
consumer-grade operating systems nowadays incorporate or by default enable a
firewall solution.
In contrast, an appliance firewall is a dedicated piece of hardware
purpose-build specifically for the sole role of behaving as a firewall and
@ -630,44 +709,42 @@ modules}.
Part of the \texttt{Netfilter} framework responsible for connection tracking is
fittingly named Conntrack. Connection, or a \it{flow} is a tuple defined by a
unique combination of source address, destination address, source port,
destination port a and the transport protocol used [refneeded flow].
destination port a and the transport protocol used.
Conntrack keeps track of the flows in a special fixed-size
(tunable\footnotemark) in-kernel
hash table structure with a fixed upper limit.
\footnotetext{via \texttt{net.netfilter.nf\_conntrack\_buckets}}
On Linux devices functioning as router devices a common issue is the depletion
of space in the conntrack table. Once the maximum number of connection is
reached, Linux simply logs an error message "\texttt{nf\_conntrack: table full,
dropping packet}" to the kernel log and "all further new connection requests
are dropped until the table is below the maximum limit again."
\cite{Westphal2017CT}. That, Westphal further notes, is indeed very
unfortunate, especially in DoS scenarios.
On Linux devices functioning as router devices (especially when you add NAT to
the mix) a common issue is the depletion of space in the conntrack table. Once
the maximum number of connection is reached, Linux simply logs an error message
\texttt{nf\_conntrack: table full, dropping packet} to the kernel log and
"all further new connection requests are dropped until the table is below the
maximum limit again." \cite{Westphal2017CT}. That, as Westphal further notes,
is indeed very unfortunate, especially in DoS scenarios.
Unless the router also functions as a NAT, this can be remedied in two ways:
decreasing the timeout until an established connection is closed and decreasing
the timeout until an inactive connection in the TIME\_WAIT state is evicted from
the conntrack table. By default, the TIME\_WAIT timeout is several hours long
and leaves the router vulnerable to a UDP flood.
and leaves the router vulnerable to packet floods or Slowloris.
Netfilter is here to help again with conntrack treating entries that have not
(yet) seen two-way communication specially – they can be evicted early if
the connection tracking table is full. In case insertion of a new entry fails
because the table is full, "...the kernel searches the next
8 adjacent buckets of the hash slot where the new connection
was supposed to be inserted at for an entry that has not seen a
reply. If one is found, it is discarded and the new connection
entry is allocated."\cite{Westphal2017CT}. Randomised source address in TCP SYN
floods becomes a non-issue because now most entries can be early-evicted
because the TCP connection tracker sets the "assured" flag only once the three-way
handshake has completed.
because the table is full, "...the kernel searches the next 8 adjacent buckets
of the hash slot where the new connection was supposed to be inserted at for an
entry that has not seen a reply. If one is found, it is discarded and the new
connection entry is allocated."\cite{Westphal2017CT}. Randomised source address
in TCP SYN floods becomes a non-issue because now most entries can be
early-evicted because the TCP connection tracker sets the "assured" flag only
once the three-way handshake has completed.
In case of UDP, the assured flag is set once a packet arrives
after the connection has already seen at least one packet in
the reply direction, that is the request/response traffic
does not have the assured bit set and can therefore be early-dropped at any time.
In case of UDP, the assured flag is set once a packet arrives after the
connection has already seen at least one packet in the reply direction, that is
the request/response traffic does not have the assured bit set and can
therefore be early-dropped at any time.
\n{2}{FastNetMon DDoS Mitigation toolkit}
@ -691,8 +768,26 @@ mitigation reactions.
% ============================================================================ %
\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 description}
\n{1}{Infrastructure Set-Up Description} \label{sec:infrastructure-set-up-description}
% TODO
Broader infrastructure description HERE.
@ -738,8 +833,8 @@ defender machines.
\hline
}
The inner (our edge) and the upstream (our transit provider) routers are
each part of different \it{AS}. They are directly connected and communicate using BGP.
The outer router and the inner router are BGP peers.
each part of different \it{AS}. They are directly connected and communicate
using BGP. The outer router and the inner router are BGP peers.
We assume our upstream provider supports RTBH signalling.
In this scenario the attacker is directly connected to our UPSTREAM router,
@ -760,8 +855,6 @@ all that with ansible roles
BIRD for bgp, static routes for a poor man's router
\n{1}{Infrastructure set-up}
\nns{approach 0}
\begin{itemize}
\item KVM
@ -819,12 +912,19 @@ 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}
\n{1}{Mitigation tools set-up} \label{sec:mitigation-tools-set-up}
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 adn v9), sFlow and port
multiple different exporter types, including Netflow (v5 and v9), sFlow and port
mirrors.
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)
BGP black-holing upsides:
\begin{itemize}
\item quick and surgically precise way
@ -832,10 +932,11 @@ BGP black-holing upsides:
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
\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}
\n{1}{Attack tools set-up} \label{sec: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
@ -848,16 +949,18 @@ why we're concerned in the first place).
\n{2}{Metasploit \texttt{aux/synflood module}}
\n{1}{Performing an attack}
\n{1}{Performing an attack} \label{sec:performing-an-attack}
run the tools
\n{1}{Monitoring}
\n{1}{Monitoring} \label{sec:monitoring}
\begin{itemize}
\item fastnetmon metrics
\item packet capture on the router interfaces
\item Netflow signalling
\end{itemize}
juju4/ansible-fprobe netflow role
% ============================================================================ %
\nn{Conclusion}