From 64304a851e12ec9e61f40b24be5608d35f5d3a03 Mon Sep 17 00:00:00 2001 From: surtur Date: Sun, 16 May 2021 10:29:20 +0200 Subject: [PATCH] add: batch 4 * 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) --- tex/text.tex | 329 +++++++++++++++++++++++++++++++++------------------ 1 file changed, 216 insertions(+), 113 deletions(-) diff --git a/tex/text.tex b/tex/text.tex index a3b58f8..f9ff5df 100644 --- a/tex/text.tex +++ b/tex/text.tex @@ -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,9 +210,10 @@ 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} +\n{2}{SYN flood} \label{synfloodattack} To establish a TCP connection, a \emph{three way handshake} must be performed.\\ That is the opening sequence of a TCP connection that any two machines - @@ -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. @@ -243,7 +314,7 @@ recommendations of RFC 3704 gained greater adoption among ISPs. Until then, brace yourselves for the next assault. -\n{2}{Slowloris}\label{slowloris} +\n{2}{Slowloris} \label{slowloris} The principle of this attack is to first open as many connections as possible, aiming to fill the capacity of the server, and then keep them open for as long as possible by sending periodic keep-alive packets.\\ @@ -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,13 +573,11 @@ 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} +\n{2}{IP masking} \label{ipmasking} This is technique is widely used (e.g. CloudFlare flagship service), relying solely on not divulging sensitive information - in this case server IP - to attackers and the capacity of the \it{fronting} service to withstand the attack @@ -511,7 +589,7 @@ other service performs TLS termination in our behalf and \textbf{sees everything} (that was encrypted only \emph{in transit} and is not additionally encrypted) that \emph{anyone} sends us, before finally forwarding it back. -\n{2}{WAF}\label{waf} +\n{2}{WAF} \label{waf} WAF - \it{Web Application Firewall} - is an appliance used to protect (as name suggests) web applications. In this day and age, this is especially necessary and enables system administrators to craft protection @@ -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 @@ -611,7 +690,7 @@ and is replacing (in modern distributions has replaced, although backward compatibility has been preserved) the former two - the \texttt{nftables} tool. -\n{3}{Netfilter}\label{netfilter} +\n{3}{Netfilter} \label{netfilter} 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 @@ -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}