chore: improve last section and conclusion

tex/text.tex

@@ -611,7 +611,7 @@ 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}
+\n{2}{Decreased-TIME\_WAIT connection closing} \label{decreased-timewait}
 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
@@ -1032,27 +1032,94 @@ even though the threshold has been crossed.
 
 
 \n{1}{Performing an attack} \label{sec:performing-an-attack}
+As mentioned previously, the attack was planned to be performed in the
+controlled environment of a virtual lab with practically no natural traffic
+occuring, that would generally be present on a reasonably large ISP network and
+thus with essentially no load on the network equipment/virtual devices.
+However, it should not have had any major impact on the results of the subject
+attack and our chosen way to mitigate.
+
+As is the case when using e.g. a selective blackhole technique, the suspect
+traffic first has to be identified as highly abnormal/malicious, either by
+analysing network metrics over a period of time as collected by sFlow or
+Netflow protocols, or by direct packet capture and inspection aided by tools
+such as nDPI.
+The analysis and detection mechanism in our scenario is left to FastNetMon and
+so is the reaction (mitigation) logic.
+
+With the first attack we performed, we basically attempted to naively overflow
+the conntrack table of our server host.
 We were not able to extinguish connections on the server using
 \texttt{slowloris.py}, presumably because the inactive connections were quickly
 being closed. While the number of used sockets steadily grew, after about 5000
 this tool was not able to open any new connections and the server worked fine.
+The key was to set the
+\texttt{net.netfilter.nf\_conntrack\_tcp\_timeout\_time\_wait} parameter to a lower
+value, such as 10 or 5 and the
+\texttt{net.netfilter.nf\_conntrack\_tcp\_timeout\_established} parameter to
+somewhere between 300 and 1200 (we chose 600). Both values are seconds and they
+are set either in the global \emph{sysctl} file (\texttt{/etc/sysctl.conf} or
+they can be placed in an arbitrary complementary file inside the sysctl include
+directory at \texttt{/etc/sysctl.d/}. The \emph{TIME\_WAIT} timeout value
+affects for how long the connections in the TIME\_WAIT (see
+\ref{decreased-timewait}) TCP state are kept before they are completely cleared
+and stop consuming resources. The ESTABLISHED timeout merely sets for
+how long the \emph{established} connections are kept in the ESTABLISHED state
+before processing them further.
 
 As per running FastNetMon attack traffic detection, we have experienced
-unexpected troubles in the form of fastnetmon incorrectly reporting 0pps for
+unexpected issues in the form of FastNetMon incorrectly reporting 0pps for
 both outbound and inbound traffic. We were not able to uncover the root cause
-of the issue.
+of the issue, which might very well even be attributed to a configuration error.
+Due to this and the fact that we could not establish BGP peering in our virtual
+lab, neither the other attack nor the mitigation could be properly performed.
 
 
 % ============================================================================ %
 \nn{Conclusion}
+Recent past has seen an immense increase in the number of DoS attacks of all
+kinds. A large part of these attacks flood service resources and ultimately end
+up blocking or delaying responses for legitimate user requests. As we touched
+on in the beginning, the motivations for these attacks can range all from a
+business model with extortion plans to hacktivism to simply somebody choosing a
+wrong place to have fun.
+
 The goal of our work was to describe some of the popular types of DoS attacks,
-casually used attack methods and tools. In the theoretical part, we also
-outlined mitigation methods available to network operators and end users alike,
-along with their scope and reach. Next, we looked at tools that aid mitigating
-DoS attacks.
-In the practical part, we have arrived at unexpected results, where we were not
-able to fully simulate the black hole propagation among ASes due to
-configuration inconsistencies. Unfortunately, this stays as a challenge for us.
+including DDoS, casually used attack methods, techniques and tools most popular
+and most widely used among attackers to annoy Internet users, harm businesses
+and worry Internet service providers with small to medium capacities. We have
+dived a little into the workings of several potential attack vectors, but have
+not stayed there.
+
+Further in the theoretical part, we also outlined various mitigation methods
+readily available to network operators and end users alike, along with their
+scope and reach. Several pros and cons of black-holing, selective black-holing,
+scrubbing and rate-limiting were considered in section
+\ref{sec:mitigation-methods} - Mitigation methods. Next, we looked at some of
+the concrete tools that aid mitigating DoS attacks.
+
+In the practical part, we set out to build a virtual lab using tools like
+Libvirt, Terraform, Cloud-Init and Ansible on top of KVM in an automated
+manner by applying the \emph{infrastructure as code} principles. The virtual
+lab was running on a Fedora 34 host, each virtual machine has been provisioned
+using Terraform, pre-configured using Cloud-Init and further configured with
+Ansible after the initial configuration has finished.
+We explored setting up both the mitigation tools used to protect Internet
+networks and tools used by adversaries.
+
+Finally, we have attempted to perform several attacks in our controlled
+virtual environment, which has been described in the practical part of this
+work. The attempts were partially successful in that our proposed mitigation
+methods showed that a certain kind of attack \emph{can} easily be mitigated and
+the unhappy consequences averted.\\
+Sadly, in the next part of attack simulation we have arrived at unexpected
+results, where we were not able to fully simulate the black hole propagation
+among ASes due to configuration inconsistencies, presumably on multiple levels.
+
+This, as well as improving and potentially reworking the virtual lab stays as a
+challenge for us for the future, and I believe performing these attack
+simulations could aid us in better understanding the threats and preparing for
+what we \emph{surely are} going to face.
 
 
 % ============================================================================ %