From ecac09a00c07dc795a7fee92bb2f401eb14dd747 Mon Sep 17 00:00:00 2001 From: surtur Date: Wed, 12 May 2021 04:04:36 +0200 Subject: [PATCH] add batch 2 * add refs * add and correct abbreviations * add theoretical part [wip] * corrections in practical part [wip] --- prace.tex | 2 +- tex/UTB.tex | 4 +- tex/abbreviations.tex | 13 +- tex/references.bib | 254 ++++++++++++++++ tex/text.tex | 678 ++++++++++++++++++++++++++++++++++++++++-- 5 files changed, 927 insertions(+), 24 deletions(-) diff --git a/prace.tex b/prace.tex index 5e8f86a..b82103d 100644 --- a/prace.tex +++ b/prace.tex @@ -60,7 +60,7 @@ \nastavautora{AM} \nastavnazevcz{} -\nastavnazeven{Protecting internet networks against DoS attacks} % Jen u anglicky psané práce +\nastavnazeven{Protecting Internet Networks Against DoS Attacks} % Jen u anglicky psané práce \nastavabstraktcz{} \nastavabstrakten{} \nastavklicovaslovacz{} diff --git a/tex/UTB.tex b/tex/UTB.tex index 8d5a385..4530540 100644 --- a/tex/UTB.tex +++ b/tex/UTB.tex @@ -27,7 +27,7 @@ \usepackage{afterpage} %\usepackage{layout} % zobrazí nastavení tiskového zrcadla (příkaz \layout) %\usepackage{times} % balíček pro použití fontu times -%\usepackage{verbatim} % vysází text bez formátování, tak jak je zapsán v souboru +\usepackage{verbatim} % vysází text bez formátování, tak jak je zapsán v souboru %\usepackage{indentfirst} % definuje odsazení prvního řádku odstavce %\usepackage{makeidx} % vytvoří rejstřík \usepackage[pdftex,pdfa,hidelinks,breaklinks]{hyperref} % vytváří křížové odkazy @@ -351,7 +351,7 @@ %\cleardoublepage \phantomsection \addcontentsline{toc}{section}{\ifenglish References \else \ifczech Seznam použité literatury \fi \fi} - \bibliography{tex/literatura} + \bibliography{tex/references} } % Příkaz pro přípravu seznamu použitých zkratek a symbolů diff --git a/tex/abbreviations.tex b/tex/abbreviations.tex index 71109cb..ad669c6 100644 --- a/tex/abbreviations.tex +++ b/tex/abbreviations.tex @@ -3,16 +3,21 @@ \seznamzkr \begin{tabular}{ll} -mpps/MPPS & \emph{millions of packets per second}\tabularnewline +Mpps/MPPS & \emph{millions of packets per second}\tabularnewline pps/PPS & \emph{packets per second}\tabularnewline ACL & \emph{access-control list}\tabularnewline +AS & \emph{Autonomous System}\tabularnewline DoS & \emph{Denial of Service}\tabularnewline DDoS & \emph{Distributed Denial of Service}\tabularnewline +HTTP & \emph{Hyper Text Transfer Protocol}\tabularnewline IP & \emph{Internet Protocol}\tabularnewline -LVM & \emph{logical volume management}\tabularnewline +ISP & \emph{Internet Service Provider}\tabularnewline +IXP & \emph{Internet Exchange Point}\tabularnewline +LVM & \emph{Logical Volume Management}\tabularnewline +RFC & \emph{Request For Comment}\tabularnewline TCP & \emph{Transmission Control Protocol}\tabularnewline -ULV & \emph{ultra low voltage}\tabularnewline -VM & \emph{virtual machine}\tabularnewline +ULV & \emph{Ultra Low Voltage}\tabularnewline +VM & \emph{Virtual Machine}\tabularnewline \end{tabular} % ============================================================================ % diff --git a/tex/references.bib b/tex/references.bib index ca921b9..59e8235 100644 --- a/tex/references.bib +++ b/tex/references.bib @@ -1,4 +1,258 @@ % ============================================================================ % +% https://web.eecs.umich.edu/~zmao/Papers/conextDefendHijack07.pdf +@inproceedings{Zhang2007PracticalDA, + title={Practical defenses against BGP prefix hijacking}, + author={Z. Zhang and Y. Zhang and Y. Hu and Z. Morley Mao}, + booktitle={CoNEXT '07}, + doi={10.1145/1364654.1364658}, + year=2007, +} + +@misc{ShodanNTPd, + title={NTPd devices}, + author={Shodan}, + publisher={Shodan}, + howpublished={https://www.shodan.io/search?query=ntpd}, + year=2021, + month=mar, + note={Accessed: 2021-03-06}, +} + +@techreport{rfc4271bgp4, + series={Request for Comments}, + number=4271, + howpublished={RFC 4271}, + institution={Internet Engineering Task Force}, + publisher={Internet Engineering Task Force}, + doi={10.17487/RFC4271}, + url={https://datatracker.ietf.org/doc/html/rfc4271}, + author={Yakov Rekhter and Susan Hares and Tony Li}, + title={{A Border Gateway Protocol 4 (BGP-4)}}, + pagetotal=104, + year=2006, + month=jan, +} + +@techreport{rfc3704multihomed, + series={Request for Comments}, + number=3704, + howpublished={RFC 3704}, + institution={Internet Engineering Task Force}, + publisher={Internet Engineering Task Force}, + doi={10.17487/RFC3704}, + url={https://datatracker.ietf.org/doc/html/rfc4271}, + author={Fred Baker and Pekka Savola}, + title={{Ingress Filtering for Multihomed Networks}}, + pagetotal=16, + year=2004, + month=mar, +} + +@techreport{rfc793tcp, + series={Request for Comments}, + number=793, + howpublished={RFC 793}, + institution={Internet Engineering Task Force}, + publisher={Internet Engineering Task Force}, + doi={10.17487/RFC0793}, + url={https://datatracker.ietf.org/doc/html/rfc793}, + author={}, + title={{Transmission Control Protocol}}, + pagetotal=91, + year=1981, + month=sep, +} + +@techreport{rfc1918, + series={Request for Comments}, + number=1918, + howpublished={RFC 1918}, + institution={Internet Engineering Task Force}, + publisher={Internet Engineering Task Force}, + doi={10.17487/RFC1918}, + url={https://datatracker.ietf.org/doc/html/rfc1918}, + author={Robert Moskowitz and Daniel Karrenberg and Yakov Rekhter and Eliot Lear and Geert Jan de Groot}, + title={{Address Allocation for Private Internets}}, + pagetotal=9, + year=1996, + month=feb, +} + +@techreport{rfc3882, + series={Request for Comments}, + number=3882, + howpublished={RFC 3882}, + institution={Internet Engineering Task Force}, + publisher={Internet Engineering Task Force}, + doi={10.17487/RFC3882}, + url={https://datatracker.ietf.org/doc/html/rfc3882}, + author={Doughan Turk}, + title={{Configuring BGP to Block Denial-of-Service Attacks}}, + pagetotal=8, + year=2004, + month=oct, + abstract={This document describes an operational technique that uses BGP communities to remotely trigger black-holing of a particular destination network to block denial-of-service attacks. Black-holing can be applied on a selection of routers rather than all BGP-speaking routers in the network. The document also describes a sinkhole tunnel technique using BGP communities and tunnels to pull traffic into a sinkhole router for analysis. This memo provides information for the Internet community.}, +} + +@techreport{rfc5735, + series={Request for Comments}, + number=5735, + howpublished={RFC 5735}, + institution={Internet Engineering Task Force}, + publisher={Internet Engineering Task Force}, + doi={10.17487/RFC5735}, + url={https://datatracker.ietf.org/doc/html/rfc5735}, + author={Michelle Cotton and Leo Vegoda}, + title={{Special Use IPv4 Addresses}}, + pagetotal=10, + year=2010, + month=jan, + abstract={This document obsoletes RFC 3330. It describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers. This memo documents an Internet Best Current Practice.}, +} + +@techreport{rfc6598, + series={Request for Comments}, + number=6598, + howpublished={RFC 6598}, + institution={Internet Engineering Task Force}, + publisher={Internet Engineering Task Force}, + doi={10.17487/RFC6598}, + url={https://datatracker.ietf.org/doc/html/rfc6598}, + author={Jason Weil and Victor Kuarsingh and Chris Donley and Christopher Liljenstolpe and Marla Azinger}, + title={{IANA-Reserved IPv4 Prefix for Shared Address Space}}, + pagetotal=11, + year=2012, + month=apr, + abstract={This document obsoletes RFC 3330. It describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers. This memo documents an Internet Best Current Practice.}, +} + + +@misc{prefixavgsize, + title={Average prefix length}, + author={Geoff Huston}, + publisher={potaroo.net}, + url={https://bgp.potaroo.net/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2%2e0%2fbgp%2daverage%2dprefix%2etxt&descr=Average%20prefix%20length&ylabel=Average%20prefix%20length&with=step}, + note={Accessed: 2021-05-11}, +} + +@misc{prefixavgupdatedsize, + title={Average prefix size updated}, + author={Geoff Huston}, + publisher={potaroo.net}, + url={https://bgp.potaroo.net/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2%2e0%2fbgp%2dupd%2davgprefsize%2etxt&descr=Average%20prefix%20size%20updated&ylabel=Average%20prefix%20size%20updated&with=step}, + note={Accessed: 2021-05-11}, +} + +@misc{teamcymru, + title={The Bogon Reference}, + author={}, + publisher={Team Cymru}, + url={https://team-cymru.com/community-services/bogon-reference/}, + note={Accessed: 2021-05-02}, +} + + +@inproceedings{Zhang2007LowRateTD, + title={Low-Rate TCP-Targeted DoS Attack Disrupts Internet Routing}, + author={Y. Zhang and Z. Morley Mao and J. Wang}, + booktitle={NDSS}, + doi={10.1.1.137.5004}, + year=2007, +} + + % cisco +@misc{cisco2020report, + title={Cisco Annual Internet Report (2018–2023) White Paper}, + author={}, + publisher={Cisco}, + url={https://www.cisco.com/c/en/us/solutions/collateral/executive-perspectives/annual-internet-report/white-paper-c11-741490.html}, + year=2020, + month=mar, + note={Accessed: 2021-05-02}, +} + +% akamai +% https://blogs.akamai.com/2015/06/dns-amplification-attacks-and-truncated-responses.html +@misc{akamaidnsampl, + title={DNS Amplification Attacks and Truncated Responses}, + author={}, + publisher={Akamai}, + url={https://blogs.akamai.com/2015/06/dns-amplification-attacks-and-truncated-responses.html}, + year=2015, + month=jun, + note={Accessed: 2021-04-03}, +} + +% akamai 2021 ddoses +% https://blogs.akamai.com/2021/03/in-our-2020-ddos-retrospective +@misc{akamai2021ddos, + title={2021: VOLUMETRIC DDOS ATTACKS RISING FAST}, + author={Tom Emmons}, + publisher={Akamai}, + url={https://blogs.akamai.com/2021/03/in-our-2020-ddos-retrospective}, + year=2021, + month=mar, + note={Accessed: 2021-05-03}, +} + +% https://blogs.akamai.com/2021/01/part-i-retrospective-2020-ddos-was-back-bigger-and-badder-than-ever-before.html +@misc{akamai2020ddosretrospect, + title={PART I: RETROSPECTIVE 2020: DDOS WAS BACK -- BIGGER AND BADDER THAN EVER BEFORE}, + author={Tom Emmons}, + publisher={Akamai}, + url={https://blogs.akamai.com/2021/01/part-i-retrospective-2020-ddos-was-back-bigger-and-badder-than-ever-before.html}, + year=2021, + month=jan, + note={Accessed: 2021-05-03}, +} + +% https://www.akamai.com/us/en/multimedia/documents/ebooks/ddos-defense-in-a-hybrid-cloud-world.pdf +@misc{akamaiddosdefence, + title={DDoS Defense in a +Hybrid Cloud World}, + author={}, + publisher={Akamai}, + howpublished={https://www.akamai.com/us/en/multimedia/documents/ebooks/ddos-defense-in-a-hybrid-cloud-world.pdf}, + note={Accessed: 2021-05-03}, + year=2021, +} + +@inproceedings{Boye2012NetfilterCT, + title={Netfilter Connection Tracking and NAT Implementation}, + author={Magnus Boye}, + year=2012, + note={Accessed: 2021-05-05}, +} + +@inproceedings{Westphal2017CT, + title={improvements to conntrack table overflow handling}, + booktitle={Netdev 2.1, The Technical Conference on Linux Networking}, + author={Florian Westphal}, + howpublished={https://netdevconf.info/2.1/papers/conntrack.pdf}, + year=2017, + month=apr, + note={Accessed: 2021-05-06}, +} + +@phdthesis{Quoitin2006BGPbasedIT, + title={BGP-based interdomain traffic engineering}, + author={Bruno Quoitin}, + school={Université catholique de Louvain}, + year=2006, + month=aug, +} + + +% unused maybe +@article{AbuAmara2014ACS, + title={A combined solution for the Internet access denial caused by malicious Internet service providers}, + author={Marwan Abu-Amara}, + journal={SECURITY AND COMMUNICATION NETWORKS}, + year=2014, + volume={7}, + pages={2078-2093}, + doi={10.1002/sec.92}, +} % ============================================================================ % diff --git a/tex/text.tex b/tex/text.tex index 4513937..d6a2b29 100644 --- a/tex/text.tex +++ b/tex/text.tex @@ -5,11 +5,642 @@ % ============================================================================ % \part{Theoretical part} +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. + +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 +excessive requests from the attacker. + +% TODO +iot devices' role in dos/ddos, unwilling participants, result of +misconfiguration, software bugs, unpatched vulnerabilities (users discipline, +lack of awareness, vendors irresponsible), serving malicious actors as cheap +amplifiers/reflectors + +IoT unpatched devices, Shodan open ports 123 (NTP) +(https://www.shodan.io/search?query=ntp) \cite{ShodanNTPd}. + +\begin{itemize} +\item conntrack table overload +\item rogue cpu process +\item mem-intensive application +\end{itemize} + +\n{1}{History} +first denial of service attacks have been known to have been performed +at least since XXXX, that is the early days of ARPANET? INTERNET? the +motivation could have been anything from curiosity of a teenager to ill +intent of a competing business owner. + + +\n{2}{2000s} + +\n{2}{2010s} + +\n{2}{Present} +Akamai mitigated 1.44Tbps DDoS mitigated in 2020. +\cite{akamai2020ddosretrospect} + +The largest of the last year's attacks were 800+ Gbps assaults: one at 824 +Gbps, the other at 812Gbps, interestingly both during the same day. Another +one has also been observed by Akamai at 594 Gbps attack on 5 March. + +These three attacks targeted a European organization in the gambling industry +and an Asian video game company. Two of them were classified by Akamai as the +two of the largest known DDoS extortion attacks to date and the most complex +ones since the widespread return of extortion attacks that, according to them, +kicked off 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\% +higher than last year. + +cisco stuff \cite{cisco2020report} + +Imperva's records + + +\n{1}{Attack methods} +what we've commonly seen being used in the wild in recent years could +really only be called "professionalizing", by which I mean that +typically what would be available 10 years ago is practically +unmatchable to anything you can get ready in in minutes to cause real +harm today. + +There are generally several different ways to categorise a method of +attack.\\ +by layers, in which the attacks are performed: +\begin{itemize} +\item link layer +\item internet layer +\item transport layer +\item application +\end{itemize} + +by the nature of their distribution: +\begin{itemize} +\item distributed +\item not distributed +\end{itemize} + +by the kind of remoteness necessary to successfully execute the attack: +\begin{itemize} +\item close-proximity (physical engagement, i.e. sabotage) requires physical + 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 +\end{itemize} + +by sth else: +\begin{itemize} +\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") + \begin{itemize} + \item memcached exploit (1:51200) + \item DNS (~1:50), with a formula \cite{akamaidnsampl} \[R = answer size / query size\] + \item SNMP + \item NTP + \end{itemize} +\item exploits + \begin{itemize} + \item 0days + \item simply running unpatched versions of software + \end{itemize} +\item physical network destruction/crippling +\end{itemize} + +\n{2}{IP fragmentation} +An attack whereby an attacker attempts to send a fragmented payload (TCP) that +the client is supposed to reassemble at the destination, by doing of +which their system resources (CPU and mainly memory) would quickly get depleted, +ultimately crashing the host.\\ +This is a transport layer attack. + +\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 - +let's call them TCP A and TCP B - perform, whereby TCP A wanting to talk +sends a \emph{segment} with a SYN control flag, TCP B (assuming also willing to +communicate) responds with a segment with SYN and ACK control flags set and +finally, TCP A answers with a final ACK \cite{rfc793tcp}. + +A malicious actor is able to misuse this 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 its own. +The client responds back with an ACK and then the connection reaches the +\it{ESTABLISHED} state. + +There is a state in which a handshake is in the process but connection has not +yet been ESTABLISHED. These connections are referred to as embryonic +(half-formed) sessions. That is precisely what happens when an attacker sends +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 +deallocated space as the source IP address. Assuming an a source from +deallocated space, What ends up happening is the server responds with a SYN,ACK +and since no response comes from an address that's not currently allocated to a +customer (nobody is using it), TCP just assumes that the packets lost on the +way and attempts packet \it{retransmission} [refneeded TCP retransmission]. +Obviously, this cannot yield a successful result so in the end the server just +added onto the already conesting network. + +Current recommended practice in as per RFC 3704 is to enable +strict mode when possible to prevent IP spoofing from DDoS attacks. If +asymmetric routing or other kind of complicated routing is used, then loose +mode is recommended. \cite{rfc3704multihomed}. +[refneeded Secure use of iptables and connection tracking helpers] + +That way the spoofed traffic never leaves the source network (responsibility of +the transit provider/ISP) and doesn't 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. + +\n{2}{Amplified Reflection Attack} +The name suggest this type of attack is based on two concepts: amplification and +reflection. The amplification part pertains the fact that certain protocols +answer even a relatively small query with a sizable response. +The reflection part is usually taking advantage of session-less protocols. +One such protocol is UDP with session-less meaning that hosts are not required +to first establish a \it{session} to communicate, a response is simply sent +back to the address that the packet arrives from (source address). +Except for the fact that if a malicious player isn't interested in +communication but only wants to cause harm, a packet's source address doesn't +necessarily have to, in fact \it{cannot} (from an attacker's point of view) +correspond to the source address of their machine. + +Since overwriting fields of the packet header (where the information important +to routing reside) is trivial and there's nothing easier than supplying a UDP +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. + +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. + +The goal of the attacker is then clear: get a largest possible response and +have it delivered to the victim (in good faith of the server even). + +Spoofing the source address is done with the purpose of evading detection as a +blocking or rate-limiting mechanism at the destination would likely identify any +above-threshold-number requests coming from a single IP and ban them, thus +decreasing the impact of the attack when the intent was to achieve congestion +at the designated destination - the victim. + +A perfect example for how bad this can get is unpatched or misconfigured +\texttt{memcached} software, that is commonly being used as e.g. a database +caching system and has an option to listen on UDP port. +Cloudflare say they have witnessed amplification factors up to 51200 times. T + +As has already been mentioned in ~\ref{synfloodattack}, this entire suite of issues +could be if not entirely prevented then largely mitigated if the very sound +recommendations of RFC 3704 gained greater adoption among ISPs. + +Until then, brace yourselves for the next assault. + + +\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.\\ +This attack works at the application layer but the principle can easily be +reapplied elsewhere. + +\n{2}{BGP hijacking} +BGP is an inter-Autonomous System routing protocol, whose primary function is +to exchange network reachability information with other BGP systems. +Furthermore, this network reachability information "includes information on the +list of Autonomous Systems (ASes) that reachability information traverses. +This information is sufficient for constructing a graph of AS connectivity for +this reachability, from which routing loops may be pruned and, at the AS level, +some policy decisions may be enforced." \cite{rfc4271bgp4}. + +BGP hijacking, in some places spoken of as prefix hijacking, route hijacking or +IP hijacking is a result of a intentional or unintentional misbehavior in +which, as Zhao et al. brilliantly put it, "a misconfigured or malicious BGP +router originates a route to an IP prefix it does not own" and they find it is +becoming an increasingly serious security problem in the Internet +\cite{Zhang2007PracticalDA}. + +\n{2}{Low-rate DoS on BGP} +As shown by Zhang et al. in their "Low-Rate TCP-Targeted DoS Attack Disrupts +Internet Routing" paper, BGP itself is prone to a variation of slowloris due to +the fact that it runs over TCP for reliability. Importantly, this is a +low-bandwidth attack and a more difficult one to detect because of that. +Beyond the attack's ability to further slow down the already slow BGP +convergence process during route changes it can cause a BGP session reset. For +the BGP session to be reset, the induced congestion by attack traffic needs to +last sufficiently long to cause the BGP Hold Timer to expire. +\cite{Zhang2007LowRateTD}. +On top of all that, this attack is especially hideous in that it can be launched +remotely from end hosts without access to routers or the ability to send +traffic directly to them. + + +\n{1}{Attack tools} +Believe it or not there actually exists a DDoS attack tools topic on +GitHub +\href{https://github.com/topics/ddos-attack-tools?o=desc\&s=stars}{ref}. + +\n{2}{HOIC} +LOIC successor HTTP flooding High Orbit Ion Cannon, affectionately +referred to as "HOIC" is a \it{free software} [refneeded] tool which enables +one to stress-test the robustness of their infrastructure by applying +enormous pressure on the designated target. It operates with HTTP or on the +transport layer with TCP and UDP. + +\n{2}{slowloris.py} +\texttt{slowloris.py} is a python script available from +\url{https://github.com/gkbrk/slowloris} that is able to perform a slowloris +attack. It seeks to extinguish file descriptors needed for opening new +connections on the server and then keeping connections for as long as it can.\\ +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 +(the attack ceases to be). + +\n{2}{iperf3} +Massive load sending a packet flood 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} +\texttt{aux/synflood} module + +\n{2}{Web browser} +Depending on our point of view (more fittingly, our scaling +capabilities), sometimes all that is needed to cause a denial of +service is tons of people behind a web browser.\\ +Numerous requests quickly overload a small server, eventually causing it +respond so slowly that the impact is indistinguishable from a DoS attack. + +That is because in principle \it{a DoS attack} is practically the same +thing as discussed above, the only difference is the malicious intent, +imperceivable to a machine. + + +\n{1}{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 +inconclusive and of course if reading this at a later date, always cross-check +with the current best practices at the time. + +\n{2}{Blackhole routing (black-holing, null routing)} +black-holing is a technique that instructs routers that traffic for a specific +prefix is to be routed to the null interface, i.e. be dropped and is used to +cut attack traffic before it reaches the destination AS.\\ +Assuming the router is properly configured to direct RFC 1918 destined traffic +to a null interface, traffic destined to the attacked network gets dropped, +making the attacked network unreachable to the attacker and everyone else. +Matter of factly, we actually conclude the DoS for the attacker +ourselves.\cite{rfc1918}\cite{rfc3882} + +In case of a DDoS, the traffic is likely to come from all over the world. \cite{akamai2020ddosretrospect} +The idea here is to announce to our upstream (ingress provider) that supports RTBH +(remotely-triggered black hole) signalling (critical) that we don't need any +traffic for the victim IP anymore. They would then propagate the announcement +further and in no time we'd stop seeing malicious traffic coming to a victim IP +in our network. +In fact, we wouldn't see any traffic coming to the victim anymore, because we +just broadcast a message that we don't wish to receive traffic for it. +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) 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 +for one IP address. Smallest possible accepted prefix size tends to be /24 +(which is still a lot) with average prefix size updated being 23.11, however, +some upstream providers might even support a /32 in case of emergency, +effectively dropping traffic only for the victim. +\cite{prefixavgsize}\cite{prefixavgupdatedsize} + +When an attack hits, all we have to do is: +\begin{enumerate} + \item deaggregate prefixes + \item withdraw hit prefixes +\end{enumerate} + +In case our upstream provider didn't support RTBH and we could not lose them +(e.g. the only one around), we could still make use of Team Cymru's new +BGP-based solution that distributes routes to participating networks using only +vetted information about current and ongoing unwanted traffic - the \b{Unwanted +Traffic Removal Service} (UTRS). It is a free community service, currently only +available to operators who have an existing ASN assigned and publicly announce +one or more netblocks with their own originating ASN into the public Internet +BGP routing tables. + +If only there was a way to just shut down the bad traffic but keep the good one +flowing (other than scrubbing)! + +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. +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. +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 +(Europe in this exercise) any traffic destined for our network (of which the +victim IP is a part of) is immediately dropped at the remote IXPs, long before +it ever comes anywhere near our geographical area, let alone our network. + +I believe this approach is superior to indiscriminate black-holing and, given +it's 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. +Additionally, sinkholing as such is ineffective against IP +spoofing, which is a common feature in network layer attacks. + +\n{2}{Scrubbing} +An improvement on arbitrary full-blown sinkholing, during the scrubbing process +all ingress traffic is routed through a security service, which can be +performed in-house or can even be outsourced. Malicious network +packets are identified based on their header content, size, type, point of +origin, etc. using heuristics or just simple rules. The challenge is to perform +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 don't have. There are at +least two ways to go about this - the BGP and the DNS way, we'll 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 +does the cleaning and sends us back the clean traffic \cite{akamaiddosdefence}. + +When performing the scrubbing in-house we have to clean the traffic on our own +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 hit by NTP/DNS/SNMP/SSDP amplification attack +\end{itemize} + +We should be performing network analysis and once higher rates of packets with +source ports of protocols known to be misused for DoS/DDoS start arriving to +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 +appearing to come from \it{our own network}, since such traffic could not exist +naturally and is obviously spoofed. + +Team Cymru has got now a long tradition of maintaining bogons lists called the +\b{Bogon Reference}. Bogon prefixes are routes that should never appear in 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 +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}. + +To get help with bogon ingress and egress filtering, we should set up automated +obtaining of updated and curated bogon lists via HTTP, BGP, RIRs and DNS from +Team Cymru.\cite{teamcymru} + +In case we are 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 + + +\n{2}{IP masking} +This is the CloudFlare approach, in this part relying solely on not divulging sensitive +information, such as your origin IP, to attackers and the capacity of +the \it{fronting} service to withstand the attack. + +\n{2}{Domain shadowing} + +\n{2}{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 sysadmins to craft protection logic in +one place and shield potentially vulnerable applications. This method +works on the application layer of the OSI model and is commonly deployed +as part of a or a module of a web proxy, which means network layer +attacks cannot be handled in this way. While not negligible, as always, +it's crucial to not have any assumptions and know exactly what +\it{layer} of protection using of WAF brings. + +Generally or at least as per CBP (current best practices), applications are not +deployed with ports exposed directly to the Internet. A sane approach of having +access to resources \it{proxied} yields multiple possibilities in terms of +authentication/authorization and protection scenarios and also several ways to +more effectively use resources available. For one, where any web content +\it{caching} is required, it's easily achieved with a \it{caching} proxy +server. It commonly also enables specifying custom access policies. + +\n{2}{Rate-limiting} +As a general precaution it's sane to limit number of connections a client is +able to make in a predefined amount of time (based on the requirements of the +service). The same applies to a limit on how many connections a client can have +open simultaneously, which can even prevent Slowloris (see \ref{slowloris}). + +\n{2}{Decreased-TIME\_WAIT connection closing} +This can help withstand a situation when conntrack table fills up and +the server refuses to accept any new connections. There is absolutely no +reason to keep connections in the conntrack table long after they become +inactive. The Linux kernel's NetFilter actually has a scrubbing mechanism, that +is supposed to be getting the conntrack table rid of the timed-out entries. +Except practice shows they can linger for much longer than necessary. + +When dealing with massive amounts of traffic it's very reasonable not only to +increase the size of the conntrack table (memory trade-off), which is the +generally recommended solution, but also to decrease the TIME\_WAIT timeout to +force-evict connections that have stopped sending data. +It is also an easy way to mitigate slowloris (see \ref{slowloris}). + +More on the workings of conntrack in \ref{netfilter} + +\begin{verbatim} + reset_timedout_connection on; +\end{verbatim} +Nginx proxy uses two FDs (file descriptors) for each connection. The limit of +max open FDs can indeed be increased easily, howerever, we might just be +inefficiently wasting precious compute resources needed when an attack comes. +If nginx is unable to allocate FDs necessary to track a connection, this won't +open. By resetting connections that timed out we prevent such a situation from +occurring easily. + + +\n{1}{Mitigation tools} +No tools are going to remedy for a bad design decision and that applies +equally to physical and internet engineering. + +\n{2}{Firewall} +No matter the specific implementation, it is presumably safe to say that +any firewall is better than no firewall. + +There are two main types of firewalls: +\begin{itemize} +\item + software +\item + appliance (hardware-accelerated) +\end{itemize} + +A software firewall is just another program running on the operating +system, apart from the fact that it's 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 +is typically running a custom and very minimal operating system and no +userspace programs. Usually the system doesn't have a userspace, since it's +vendored to run as an appliance. + +\n{3}{Software firewall} +Solutions available as software firewalls are typically specific to a given +operating system. + +Usually, there exist several tools that enable communication with the core +implementing the logic, commonly by a way of embedding deeply in the networking +stack of the OS or utilizing kernel APIs. In Linux distributions, the Linux +kernel is the one that sees all. Each packet arriving at the network interface +is inspected by the kernel and a decision is made regarding it. + +Historically, \texttt{ipset} and later \texttt{iptables} used to be the de-facto +standard, however, a more recent successor emerged quite some time ago +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} +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 +\texttt{nftables} can be interacted with via a shell utility and since they +also expose APIs of their own, it's common that they have graphical frontends +as additional convenience as well, most notably \texttt{firewalld}, which can +be used in conjunction with both of them. + +Although newer versions of the Linux kernel support both \texttt{iptables} and +\texttt{nftables} just the same, only one of them can be used at a time. This +can be arbitrarily changed at runtime, a reboot is not necessary since they are +userspace tools) and interact with the kernel using \it{loadable kernel +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]. + +Conntrack keeps track of the flows in a special fixed-size (tunable) in-kernel +hash table structure with a fixed upper limit. + +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. + +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. + +Netfilter is here to help again with conntrack treating entries that have not +(yet) seen twa-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 hasn’t 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. + + +\n{2}{WAF} +A web application firewalls add a layer of protection against L7 attacks, not +necessarily DoS/DDoS. + +\n{3}{Mod\_Security toolkit} +Supported proxy programs are \texttt{nginx}, \texttt{apache}. + +\n{3}{Mod\_evasive toolkit} + +\n{2}{FastNetMon DDoS Mitigation toolkit} + +% \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} + +\n{2}{Fail2Ban} + % ============================================================================ % \part{Practical part} -\n{1}{infrastructure description} +\n{1}{Infrastructure description} % TODO Broader infrastructure description HERE. @@ -19,20 +650,40 @@ Broader infrastructure description HERE. \bf{VM name} & \bf{vCPU(s)} & \bf{RAM} & \bf{disk space} & \bf{net ifaces} & \bf{operating system} \\ \hline\hline - edge router & 1 & 1GB & 2GB & {outer,DMZ} & OpenWRT Qemu \\ - inner router & 1 & 1GB & 2GB & {DMZ,inner} & OpenWRT Qemu \\ + upstream router & 1 & 1GB & 2GB & {outer,DMZ} & OpenWRT Qemu \\ + edge router & 1 & 1GB & 2GB & {DMZ,inner} & OpenWRT Qemu \\ victim & 1 & 512MB & 4.3GB & {inner} & Fedora 34 \\ attacker & 1 & 1GB & 4.3GB & {outer} & Fedora 34 \\ defender & 1 & 1GB & 5GB & {DMZ} & Fedora 34 \\ \hline } +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. + +We assume our upstream provider supports RTBH signalling. +In this scenario the attacker is directly connected to our UPSTREAM router, +and while in reality there would probably be a greater distance between us and +them, this is fine for our simulation purposes, since malicious traffic will be +cut before it reaches us. + +If our upstream provider didn't support RTBH signalling, in case we were +attacked we could still use a scrubbing service but it's preferred that such a +provider is picked that has the RTBH capabilities. + +FENIX in CR - trusted peers + +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 -\n{1}{infrastructure set-up} +\n{1}{Infrastructure set-up} \nns{approach 0} \begin{itemize} -\tightlist \item KVM \item \texttt{terraform} with \texttt{libvirt} provider \item \texttt{cloud-init} @@ -41,7 +692,6 @@ Broader infrastructure description HERE. \nns{approach 1} \begin{itemize} -\tightlist \item KVM \item \texttt{terraform} \item \texttt{ignition} @@ -50,7 +700,6 @@ Broader infrastructure description HERE. VMs required: \begin{itemize} -\tightlist \item victim \item router - inner \item router - edge @@ -82,7 +731,7 @@ precise) and a Btrfs subvolume has been created specifically for the libvirt storage pool. Since most of the system images for the VMs come in a QCOW2 format, the CoW (Copy-on-Write) feature of Btrfs has been turned off for the subject subvolume, just as recommended in the Arch -wiki [archwiki btrfs cow ref needed]. +wiki [refneeded archwiki btrfs cow]. Notably, the system has also been using the \texttt{nftables} backend of \texttt{firewalld}, for which, luckily, \texttt{libvirt} was already @@ -90,17 +739,15 @@ prepared. \n{1}{Mitigation tools set-up} An open-source DDOS mitigation toolkit named \texttt{fastnetmon} was -chosen... +picked to serve as an attack detection tool. -BGP blackholing upsides: +BGP black-holing upsides: \begin{itemize} -\tightlist \item quick and surgically precise way \end{itemize} -BGP blackholing weak spots: +BGP black-holing weak spots: \begin{itemize} -\tightlist \item requires for our BGP peers to be available and willing to help/cooperate to advertise smaller subnets \end{itemize} @@ -111,20 +758,17 @@ first "D" of DDOS) attack, instead the objective was mainly to congest the weakest link, which would happen to live inside our network (that's why we're concerned in the first place). -\n{2}{hoic} - \n{2}{iperf3} \n{2}{slowlorispy} -\n{2}{metasploit \texttt{aux/synflood module}} +\n{2}{Metasploit \texttt{aux/synflood module}} \n{1}{Performing an attack} run the tools \n{1}{Monitoring} \begin{itemize} -\tightlist \item fastnetmon metrics \item packet capture on the router interfaces \item Netflow signalling