wieerwill/aegis-dos-protection
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

review 1

Browse Source
This commit is contained in:
Robert Jeutter 2021-10-23 18:31:19 +02:00
parent 11a083d73f
commit f868efe7ea
78 changed files with 2270 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
doc/review_1/chapters/1-problemstellung.tex Normal file
View File

@ -0,0 +1,17 @@
\documentclass[../review_1.tex]{subfiles}
\graphicspath{{\subfix{../img/}}}
\begin{document}
\chapter{Problemstellung}\thispagestyle{fancy}
% Ausgangssituation?
\vspace{-0.5cm}
Denial-of-Service-Angriffe stellen eine ernstzunehmende Bedrohung dar.\\
Im digitalen Zeitalter sind viele Systeme über das Internet miteinander verknüpft. Viele Unternehmen, Krankenhäusern und Behörden sind dadurch zu beliebten Angriffszielen geworden\cite{infopoint_security_cyber_angriffe}. Motive für solche Angriffe sind finanzielle oder auch politische Gründe.\\
Bei DoS\footnote{Denial of Service, dt.: Verweigerung des Dienstes, Nichtverfügbarkeit des Dienstes}- und DDoS\footnote{Distributed Denial of Service}-Attacken werden Server und Infrastrukturen mit einer Flut sinnloser Anfragen so stark überlastet, dass sie von ihrem normalen Betrieb abgebracht werden. Daraus kann resultieren, dass Nutzer die angebotenen Dienste nicht mehr erreichen und Daten bei dem Angriff verloren gehen können.\\
Hierbei können schon schwache Rechner großen Schaden bei deutlich leistungsfähigeren Empfängern auslösen. In Botnetzen können die Angriffe von mehreren Computern gleichzeitig, koordiniert und aus verschiedensten Netzwerken stammen \cite{tecchannel_gefahr_botnet}.\\
Das Ungleichgewicht zwischen Einfachheit bei der Erzeugung von Angriffsverkehr gegenüber komplexer und ressourcenintensiver DoS-Abwehr verschärft das Problem zusätzlich. Obwohl gelegentlich Erfolge im Kampf gegen DoS-Angriffe erzielt werden (z.B. Stilllegung einiger großer ,,DoS-for-Hire'' Webseiten), vergrößert sich das Datenvolumen durch DoS-Angriffe stetig weiter. Allein zwischen 2014 und 2017 hat sich die Frequenz von DoS-Angriffen um den Faktor 2,5 vergrößert und das Angriffsvolumen verdoppelt sich fast jährlich \cite{neustar_ddos_report}. Die Schäden werden weltweit zwischen 20.000 und 40.000 US-Dollar pro Stunde geschätzt \cite{datacenterknowledge_study}.\\
% Für einen effektiven (D)DoS-Schutz ist es wichtig, vorgegebene regelbasierte Muster hinter Paketen und Netzwerkverkehr zu erkennen, wie zum Beispiel ähnliche Absenderadressen oder unvollständige Paketdaten.\\
Im Bereich kommerzieller DoS-Abwehr haben sich einige Ansätze hervorgetan (z.B. Project Shield\cite{projectshield}, Cloudflare\cite{cloudflare}, AWS Shield\cite{aws_shield}). Der Einsatz kommerzieller Lösungen birgt einige Probleme, etwa mitunter erhebliche Kosten oder das Problem des notwendigen Vertrauens, welches dem Betreiber einer DoS-Abwehr entgegengebracht werden muss. Folglich ist eine effiziente Abwehr von DoS-Angriffen mit eigens errichteten und gewarteten Mechanismen ein verfolgenswertes Ziel - insbesondere wenn sich dadurch mehrere Systeme zugleich schützen lassen.\\
Ziel des Softwareprojekts ist es, ein System zwischen Internet-Uplink und internem Netzwerk zu schaffen, das bei einer hohen Bandbreite und im Dauerbetrieb effektiv (D)DoS Angriffe abwehren kann, während Nutzer weiterhin ohne Einschränkungen auf ihre Dienste zugreifen können. Die entstehende Anwendung implementiert einen (D)DoS-Traffic-Analysator und einen intelligenten Regelgenerator, wodurch interne Netzwerke vor externen Bedrohungen, die zu einer Überlastung des Systems führen würden, geschützt sind. Es enthält Algorithmen zur Verkehrsanalyse, die bösartigen Verkehr erkennen und ausfiltern können, ohne die Benutzererfahrung zu beeinträchtigen und ohne zu Ausfallzeiten zu führen.
\end{document}

43
doc/review_1/chapters/10-machbarkeitsanalyse.tex Normal file
View File

@ -0,0 +1,43 @@
\documentclass[../review_1.tex]{subfiles}
\graphicspath{{\subfix{../img/}}}
\begin{document}
\chapter{Ergebnisse der Machbarkeitsanalysen und Beispielrealisierungen}\thispagestyle{fancy}
%Die folgenden Kapitel sind speziell für den Unified Process gedacht:
Zur Machbarkeitsanalyse wurde zunächst die Testumgebung vorbereitet. Diese besteht aus drei Rechnern: Einem Angreifer, einem Server, der das zu schützende Netzwerk repräsentiert und der Mitigation-Box selbst. Auf allen Computern wurde Ubuntu 20.04 LTS installiert. Sie sind zum Ersten untereinander über extra eingebaute Netzwerkkarten verbunden, zum Zweiten besteht über die interne Netzwerkkarte jedes Computers Kontakt zum Internet, sodass man via SSH auf die Computer zugreifen kann. Zum jetzigen Zeitpunkt ist die Testumgebung bereits vollständig in einem Labor des Fachgebietes ,,Telematik/Rechnernetze'' aufgebaut. Eine Illustrierung ist bei~\ref{fig:Versuchsaufbau} auf Seite~\pageref{fig:Versuchsaufbau} zu finden.
Der Server ist über eine 10Gbps-Leitung mit der Mitigation-Box verbunden. Zwischen Mitigation Box und Angreifer besteht eine 25Gbps-Verbindung. Um legitimen Datenverkehr zu simulieren, besteht zwischen zwei Netzwerkkarten-Ports des Angreifers eine Verbindung mit einer maximalen Datenrate von 10Gbps. Von dem Computer auf dem der angreifende Prozess läuft werden also legitime Pakete mit einem Prozess gesendet, der nicht der angreifende ist. Diese gelangen über eine Eigenschleife von einer Netzwerkkarte zu einer anderen. Auf das zweite Interface hat das Angreiferprogramm Zugriff, welches den legitimen dann zusammen mit dem bösartigen Verkehr zu der Mitigation Box weiterleitet. Laut Pflichtenheft soll die Mitigation-Box mit bis zu 20-25Gbps eingehenden Traffic (von Seiten des Internets und des Angreifers) umgehen können. Von der Mitigation Box zum Server soll eine 10Gbps-Verbindung bestehen.
Zumindest im Nicht-Angriffsfall sollen Pakete mit insgesamt 10Gbps zum Server möglichst ohne Verzögerung weitergeleitet werden. Um zu beurteilen ob das realisierbar ist, kann man sich die Benchmarks \cite{ryzen_benchmarks}, \cite{mellanox_nic_benchmark} für Mellanox-Karten bzw. \cite{intel_nic_benchmark} für Intel-Karten ansehen.
% Im Idealfall würde man für legitimen und bösartigen Traffic zwei verschiedene Maschinen verwenden. Das Softwareprodukt soll allerdings mit einer eingehenden Datenrate von 20 bis 25 Gbit/s funktionieren und dementsprechend getestet werden. Weil kein entsprechender Switch nur ein Port bei der Mitigation Box zur Verfügung steht, die eine solche Datenrate gewährleisten kann, müssen wir den gesamten eingehenden Traffic über die Verbindung zwischen Angreifer und Mitigation-Box leiten.Aus diesem Grund geht sowohl legitimer als auch bösartiger Datenverkehr vom Angreifer aus.
In \cite{mellanox_nic_benchmark} ist ein Test beschrieben, der die Leistung einer Mellanox ConnectX-5 25GbE beschreibt. Diese Netzwerkkarte wird in der Mitigation-Box für das empfangen und senden der Pakete genutzt. Laut Test 2 erreicht das Interface eine Frame Rate von 74,4Mpps (Million packets per second) bei einer Frame Size von 64Byte. Umgerechnet in Gbps sind das \(74,4 \cdot 10^6 Pakete \cdot 64 \cdot 8 bit = 38092Mbps = 38,092Gbps\). In \cite{mellanox_nic_benchmark} wurde ein Prozessor mit 24 Kernen und einer Taktfrequenz von 2,70GHz verwendet. In der Mitigation-Box ist ein AMD Ryzen 9 5900X verbaut, welcher nach \cite{ryzen_benchmarks} 12 Kerne (halb so viel) und eine Basistaktfrequenz von 3,7GHz (um Faktor 1,3 schneller) beinhaltet. Angenommen, es wird die gleiche Anzahl von Queues auf der Netzwerkkarte, wie bei \cite{mellanox_nic_benchmark} (4 pro Port), verwenden, dann wäre bei dem gleichen Test einen Durchsatz von \(38Gbps \cdot 0,5 \cdot 1,3 = 24,7Gbps\) erzielbar. Bei Test 2 wurde das weiterleiten von Paketen getestet. Angenommen, es wird zwischen Angriffsfall und Nicht-Angriffsfall unterschieden und in ersteren werden die Pakete in jedem Fall weiter geleitet und werten parallel die Daten aus um einen Angriffsfall zu erkennen, dann ist der erforderte Durchsatz von 10Gbps realistisch. Befände sich das System dann aber im Angriffsfall, sodass nahezu jedes Paket untersucht werden müsste, ist es noch unklar, ob eine solch hohe Datenrate erreicht werden kann. Ein Teil der Abwehrmaßnahmen besteht daraus, Headerinformationen eines Paketes auszulesen und auf deren Basis das Paket zu löschen oder weiterzuleiten. Ein aufwändigeres Verfahren ist die Abwehr von SYN-Flood-Angriffen. Rechnet man mit einer Halbierung bis Drittelung der Datenrate, so ist ausgehender Verkehr von 10Gbps in Richtung des Servers bei von außen kommender Datenrate von 25Gbps gerade noch denkbar, das wird dabei allerdings stark von der Implementierung abhängen.
In dem System werden Datenstrukturen benötigt, um z.B. Headerinformationen abzuspeichern oder um Sequenznummern zu mappen. Da das System eine möglichst geringe Verzögerung des Datenverkehrs zu erreichen versucht, müssen sehr effiziente Strukturen verwendet werden. Hierzu werden Dictionaries bzw. \texttt{unordered\_maps} verwendet, da diese mit Hash-Verfahren eine sehr gute Zugriffs- und Einfügzeit bieten. \texttt{unordered\_maps} sind um einiges schneller als maps, da diese keine Ordnung von Schlüsseln benötigen, was in diesem System nicht notwendig ist.
Die Standard-Biblihotek stellt die \texttt{std::unordered\_maps} zur Verfügung, welche in diesem Projekt jedoch nicht verwendet wird, da es außerhalb der Standardbibliothek effizientere bzw. schnellere \texttt{unordered\_maps} gibt. Andere, wie z.B. \texttt{Robin\_Hood\_unordered\_map} und Patchmap bieten aufgrund schnellerer, bzw. besserer Hash-Verfahren eine sehr gute alternative zur \texttt{std::unordered\_map}. Siehe hierzu die Benchmarks für \texttt{Robin:Hood\_unordered\_mas} \cite{RobinHoodMap} und patchmaps \cite{Patchmap}. Ein weiterer Vorteil dieser Maps ist, dass diese relativ ähnlich wie \texttt{std::unordered\_maps} zu verwenden sind, und nur über ein Header-File eingebunden werden müssen.
%Innerhalb unseres Systems müssen sehr schnelle Datenstrukturen verwendet werden, um eine Abbildung von eingehenden Sequenznummern von TCP-Paketen auf dann ausgehende Sequenznummern zu realisieren. Hierzu wollen wir patchmaps verwenden, welche generell eine sehr gute Zugriffsgeschwindigkeit haben, wenn die Kapazität der Map nicht nahezu ausgelastet ist.
%Für eine pauschale Rechnung der vom System zu verarbeitende Daten können wir grob annehmen, dass für TCP/IP-Verbindungen, die Netzwerkpakete ca. 1500Byte groß sind. Um die Datenstrukturen am weitesteten zu testen, nehmen wir auch noch an, dass es nahezu kaum UDP-Verkehr gibt. Insgesamt macht dies dann auf Angreifer-Seite eine Anzahl von (25.000.000.000 Gbps/8)/1500 Byte \(\approx 2 \cdot 10^6\) Paketen pro Sekunde. Anhand dieser Größe sehen wir schon, dass wir eine riesige Menge an Daten verarbeiten bzw. Sequenznummern berechnen müssen. Damit wir auch unseren Speicherplatz nicht zu stark ausreißen, nehmen wir an, dass wir eine sehr hohe Speicherbelegung der zu verwendenden patchmaps vorliegt. Um noch gute Zugriffszeiten zu erreichen, möchten wir eine Auslastung der Map von ca. 0,7 bzw. 70 Prozent nicht überschreiten. Unter all diesen Annahmen, benötigt eine patchmap ca. 65ns an Zeit um eine lookup-Operation auszuführen.
% Die zur Entwicklung erforderliche Bibliotheksammlung DPDK und für die Netzwerkkarte notwendige Treiber sind auf dem angreifenden Rechner installiert. Einige Testprogramme von DPDK wurden dort erfolgreich ausgeführt.
% Als nächstes wird ein Beispielprogramm geschrieben, welches auf einem Netzwerkkartenport eingehende Pakete empfangen, analysieren und auf einem anderen Port versenden kann.
% TODO: Daten von anderen Leuten ansehen; ob man mit dem was wir haben und DPDK die Datenrate haben die wir wollen
% Grobe Milchmädchenrechnung: Attack Traffic, bekomm ich das vom interface runter? bekomm ich das gehasht? BEkomm ich das vom Arbeitsspeicher runter...
% Dies und das aber nicht einschätzbar deshalb später aufgreifen
% wo finde ich sowas?
% Datenstruktur-menschen
% Es ist nicht klar ob wir DS brauchen. Wenn ich gucken möchte nach leistungsdaten von DPDK
% Trex, Paketgenerator, von Cisco. Schauen wie viel Traffic er schafft. Schaffen wir das auch mit unserer Single Core performance?
% Mellanox-Connects: n HW-Queues. schaff ich das mit so und so vielen cores. Benchmarks
% http://fast.dpdk.org/doc/perf/DPDK_20_02_Intel_NIC_performance_report.pdf
% https://fast.dpdk.org/doc/perf/DPDK_20_05_Mellanox_NIC_performance_report.pdf
% https://www.amd.com/en/products/cpu/amd-ryzen-9-5900x
\end{document}

98
doc/review_1/chapters/11-testdrehbuch.tex Normal file
View File

@ -0,0 +1,98 @@
\documentclass[../review_1.tex]{subfiles}
\graphicspath{{\subfix{../img/}}}
\begin{document}
\chapter{Testdrehbuch}\thispagestyle{fancy}
Wann immer Software entwickelt wird, ist es notwendig zu überprüfen, ob diese Software wie geplant funktioniert. Im Verlauf der Implementierungsphase werden allgemeine Tests durchgeführt, welche die grundlegene Funktionen auf Funktionstüchtigkeit überprüfen. Diese Tests sollten so gestaltet sein, dass sie einzelne Teile des Programms überprüfen. Dadurch kann sichergestellt werden, dass diese Elemente den Belastungen gewachsen sind.
In der Validierungsphase werden die meisten Tests durchgeführt. Diese konzentrieren sich auf das Finden von Fehlern und das Ermitteln von optimierbaren Komponenten. Falls in dieser Phase aber noch grundlegene Fehler gefunden und behoben werden, müssen auch die Tests aus der Implementierungsphase wiederholt werden.
\section{Wichtige Testfälle}
Es ist geplanen den Großteil der nichtfunktionalen und einzelne der funktionalen Anforderungen mit Tests zu überprüfen. Dabei wird mit der grundlegenden Funktionen der Mitigation-Box begonnen, zu den komplexeren vortgeschritten, bevor die gewünschten Leistungsparametern überprüft werden.
Zuerst muss das System in der Lage sein, Pakete zu empfangen und weiterzuleiten. Danach wird die Analysefähigkeit der Mitigation-Box getestet, indem überprüft wird, ob sie erkennen kann, dass sie angegriffen wird und dann auch zwischen den einzelnen Angriffsarten unterscheiden kann.
Parallel finden Tests statt, wie viel Datenverkehr der Server verarbeiten kann und welche Attacke diesen wie schnell zum Betriebsausfall bringt.
Im Folgenden soll überprüft werden, ob die Mitigation-Box die verschiedenen (D)DoS-Varianten einzeln, sowie gemischt und verkettet abwehren kann. Insbesondere sollen die sämtliche SYN-Paket basierten Attaken vollständig abgewehrt werden.
Da die Mitigation-Box den Betrieb des zu schützenden Systems nicht einschränken soll, wird auch überprüft, wie stark die zu entwickelnde Software den Datenverkehr verlangsamt und wie viele legitime Pakete sie verwirft.
Zum Schluss wird getestet, ob das System selbst anfällig gegen (D)DoS-Attacken ist. Außerdem wird sein Leistungslimit in Hinsicht auf Daten- und Paketrate geprüft.
\section{Testplanung}
\subsection{Test 1: Paketweiterleitung}
Zunächst wird das simple Weiterleiten von Paketen getestet. Dafür werden Pakete mit DPDK von einem Port der Netzwerkkarte entgegengenommen und auf den anderen Port weitergegeben. Danach wird begonnen, einzelne Ping-Anfragen vom äußeren System über die Mitigation-Box zum Server laufen zu lassen. Darauf aufbauend wird ein erster kleiner Lasttest durchgeführt. Dabei wird möglichst viel Traffic an den Server gesendet. Dieser Teil des Tests gilt als erfolgreich, wenn am Server die Netzwerkkarte ausgelastet ist oder der Server aufgrund von zu hoher Datenlast abstürzt. Währenddessen darf die Mitigation-Box selbst nicht ausfallen. Die Auslastung der Netzwerkkarte lässt sich serverseitig mit dem vorinstallierten System-Monitor überprüfen.
Der Erfolg in beiden Teiltests ist Voraussetzung für alle weiteren Tests.
\subsection{Test 2: Lasttest Server}
Nachdem Test 1 erfolgreich abgeschlossen wurde, kann damit begonnen werden, Angriffe zu erzeugen und auszuloten wie viel der Test-Server verkraften kann. Dies wird über den Verlauf des Projekts mehrfach wiederholt, um das System mit komplexeren und potenteren Angriffen konfrontieren zu können. So wird auch ein Vergleichsmaß erzeugt, mit dem die Effektivität der Abwehrmaßnahmen abgeschätzt werden kann.
\subsection{Test 3: (D)DoS Erkennung}
Parallel zu Test 2 wird getestet, ob das System die verschieden (D)DoS-Angriffe erkennen kann. Hierfür wird zu Anfang ein Strom legitimen Verkehrs etabliert und später (D)DoS-Pakete beigemischt. Es wird mit simplen Attacken wie Syn-Flood gestartet. Später werden die Attacken um komplexere Angriffe erweitert.
Dieser Test gilt als erfolgreich, wenn die Mitigation-Box alle Angriffe erkennen kann. Er dient dabei auch der Schärfung der Entscheidungsgrenzen, ab wann ein Angriff als wie gefährlich eingestuft wird und folglich abgeschwächt werden muss.
In einem zweiten Schritt wird das System mit mehreren parallelen und sich abwechselnden Strategien angegriffen. Dabei verzeichnet der Angreifer die einzelnen Attacken in einer log-Datei. Sobald die Mitigation-Box einen Angriff feststellt, trägt sie diesen in ihre log-Datei ein. Beide log-Dateien werden zur Abschätzung der Fehlerrate miteinander verglichen.
\subsection{Test 4: (D)DoS Abwehr}
Dieser Test setzt den Abschluss von Test 3 voraus. Hier wird die Effektivität der Abwehrmaßnahmen getestet. Beginnend mit den einzelnen Attacken, wird die Wirksamkeit der Verteidigungsmaßnahmen getestet.
Dabei gibt es zwei Maßzahlen für die Effektivität: Einerseits die Responsivität der Mitigation-Box und andererseits der herausgefilterte Anteil an schädlichen Paketen. Letzteres lässt sich durch Vergleichen von Sende- und Empfangslogs des Servers und Angreifers überprüfen. Hingegen wird die Responsivität nur am legitimen Sender geprüft. Dieser wird ein log führen, in welchem aufgeschrieben wird, zu welchem Zeitpunkt ein Paket gesendet wird und wann die Antwort eingeht.
In späteren Iterationen dieses Test soll der Server mit mehreren parallelen Angriffen konfrontiert werden.
Dieser Test ist nicht als Stresstest konzipiert, sondern lediglich zum Überprüfen der Abwehrmaßnahmen gedacht. Es sollen Fragen geklärt werden wie: Sind die Maßnahmen effektiv genug? Müssen höhere Verluste an legitimen Paketen in kauf genommen werden? Kann mehr Verkehr durchgelassen werden, ohne die Verfügbarkeit des Servers zu gefährden?
\subsection{Test 5: Transparenz}
In diesem Test soll der Einfluss der Mitigation-Box auf legitimen Verkehr getestet werden. Es gibt zweierlei Arten, wie das System auf diese Verbindungen einwirken kann: Einerseits, indem es Pakete verzögert, bis sie als legitim deklariert wurden, und andererseits, indem legitime Pakete als bösartig deklariert und gelöscht werden.
Ersteres kann nur im Leerlauffall, d.h. ohne beigemischte (D)DoS-Pakete, gemessen werden. Da es nicht möglich ist, verlässliche RTTs bei laufendem (D)DoS-Angriff auf einen ungeschützten Server zu messen. Trotzdem wird versucht, die RTT während aller Durchläufe dieses Tests zu messen. Dafür wird ein Anfragen-Pool bestimmt, dessen Anfragen in jedem Test abgesendet werden. Diese Anfragen werden zusammen mit der Wartezeit auf die Antwort in einer log-Datei verzeichnet. Ein Vergleich der unterschiedlichen log-Dateien ergibt die Verzögerung. Die Wegwerfrate ergibt sich aus dem Anteil der Anfragen, die keine oder keine vollständige Antwort erhalten.
Dieser Test wird mehrfach mit unterschiedlichen Angriffslasten, aber konstanter Nutzlast durchgeführt. Der erste Testlauf wird ohne Angriffslast und ohne die Mitigation-Box durchgeführt um Vergleichswerte zu ermitteln. Danach werden mehrere Iterationen mit dem System zwischen Angreifer und Server folgen. Bei diesen Testläufen wird die Angriffslast von 0 Gbit/s schrittweise auf 20 Gbit/s erhöht.
\subsection{Test 6: Eigensicherheit}
In diesem Test wird das Ziel sämtlicher Angriffe direkt oder indirekt die Mitigation-Box selbst sein.
Dafür findet dieser Test in zwei Teilen statt. Im ersten werden die (D)DoS Angriffe auf die Mitigation-Box und nicht auf den Server gerichtet sein. Im zweiten Teil werden die (D)DoS-Angriffe so gestaltet, dass sie maximalen Arbeitsaufwand im System benötigen.
In diese Angriffe soll auch Wissen über Implementierungsdetails einfließen. Alles ist erlaubt, solange es nicht den Link zur Mitigation-Box überlastet.
Das System soll trotz allem in der Lage sein, legitimen Datenverkehr zu ermöglichen. Der Eingang von Antworten am legitimen Sender ist hierbei Erfolgskriterium.
\subsection{Test 7: Paketflut}
Zuletzt soll die maximal verarbeitbare Paketrate getestet werden. Hiefür wird das System mit einer steigenden Rate von SYN, SYN-FIN und SYN-FIN-ACK Paketen angegriffen. Dabei werden nicht nur für den Angriff, sondern auch für den legitimen Verkehr ausschließlich kleine TCP-Pakete, die Verbindungen auf- und abbauen, verwendet, um die Paketrate zu maximieren.
Die maximale Paketrate gilt als überschritten, wenn kein Verbindungsaufbau mehr zustande kommt.
In diesem Test werden TCP-SYN-Pakete verwendet, obwohl es für die Mitigation-Box aufwendigere Angriffe gibt. Dies ist eine Idealisierung, um ein absolutes Maximum an Paketen zu ermitteln, die das System verarbeiten kann.
Implizit fungiert dieser Test auch als Beweis, dass die verschiedenen TCP-SYN-Angriffe vollständig abgewehrt werden können.
\subsection{Test 8: Datenrate}
Dieser Test ist kein richtiger Test, denn er wird in jedem Test durchgeführt, in dem diesen Bestimmungen nicht ausdrücklich widersprochen wird.\\
Die Soll-Datenrate für legitimen, zum Server gesendeten Verkehr liegt bei 5 Gbit/s.
Der Sollwert für die Datenrate von Angriffspaketen liegt bei 20 Gbit/s.
Bei den tatsächlichen Werte können während der Test Schwankungen auftreten . Ursache wird z.B. der maximale Durchsatz des Links zwischen Mitigation-Box und Angreifer sein, da dieser Pakete in beide Richtungen leiten muss.
\section{Tabellarische Übersicht}
\begin{longtable}[ht] {l p{3cm} p{6.5cm} p{2.5cm}}
\textbf{Test} & \textbf{Name} & \textbf{Kurzbeschreibung} & \textbf{getestete \newline Anforderungen} \\ \toprule \endhead
Nr 1 & Paketweiterleitung & reines weiterleiten von Paketen & F07 \\
Nr 2 & (D)DoS-Angriffe & Effektivität von (D)DoS-Angriffen testen & \\
Nr 3 & (D)DoS Erkennung & Kalibrierung von (D)DoS Erkennung & F05 \\
Nr 4 & (D)DoS Abwehr & Überprüfung Abwehrmaßnahmen & F03, F09 \\
Nr 5 & Transparenz & Analyse Effekt auf Verbindungen & NF02, NF05, NF07, NF09 \\
Nr 6 & Eigensicherheit & Überprüfung Widerstandsfähigkeit der Miditation-Box & F02 \\
Nr 7 & Paketrate & Ermittlung maximaler Paketrate & NF04, NF06 \\
Nr 8 & Datenrate & allgemeine Bestimmungen & NF03 \\ \bottomrule
\end{longtable}
\end{document}

14
doc/review_1/chapters/12-abkuerzungsverzeichnis.tex Normal file
View File

@ -0,0 +1,14 @@
\documentclass[../review_1.tex]{subfiles}
\graphicspath{{\subfix{../img/}}}
\begin{document}
\chapter{Abkürzungsverzeichnis}\thispagestyle{fancy}
\begin{description}
\item[DDoS] Distributed Denial-of-Service
\item[DoS] Denial-of-Service
\item[DRoS] Distributed Reflected Denial-of-Service
\item[Gbps] Giga bit pro sekunde
\item[Mpps] Million packets per second
\end{description}
\end{document}

32
doc/review_1/chapters/13-glossar.tex Normal file
View File

@ -0,0 +1,32 @@
\documentclass[../review_1.tex]{subfiles}
\graphicspath{{\subfix{../img/}}}
\begin{document}
%\chapter{Glossar}\thispagestyle{fancy}
% polling
% NIC
% Thread
% RX/TX Queues
% Vtable
% Middlebox Mitigation Box
%\begin{description}
%Bitte alphabetisch ordnen
% \item \textbf{DDoS-Attacke:}
% \item \textbf{DoS-Attacke:}
% \item \textbf{DRoS-Attacke:}
% \item \textbf{Ping of Death:}
% \item \textbf{Ping Flood:}
% \item \textbf{Land-Attacke:} Bei einer LAND-Attack (LAND = Local Area Networt Denial) sendet der Angreifer ein gespooftes TCP-SYN-Packet, bei welchem er zuvor sowohl die Quell- alsu auch die Ziel-IP mit der IP des Zielsystems versehen hat. Das Opfer antwortet sich stets selbst (Loop).
% \item \textbf{Sockstress:} Diese Angriffsart beinhaltet eine Vielzahl an Variationen. Beim Zero Windows Connection Stress öffnet der Angreifer die Verbindung und verkündet eine Fenstergröße von 0. Das Zielsystem muss solange testen, ob etwas geht, bis der Client (= Angreifer) das Fenster vergrößert. Das Problem hierbei ist, dass die Sockets unendlich lange offen bleiben, wenn dies durch sonstige Einstellungen nicht untersagt wird. Die Grundidee des Small Window Stress ist ähnlich: Der Angreifer öffnet die Verbindung und setzt die Fenstergröße möglichst klein, zum Beispiel auf 4 Bytes. Er forderr ein Paket mit großer TCP-Payload an, wobei die Fenstergröße klein bleibt. Dies führt zu einer zunehmenden Füllung des kernel memorys, da die gesamte Anwort auf winzige (4 Byte-) Blöcke aufgeteilt werden muss.
% \item \textbf{SYN-FIN-Attack:}
% \item \textbf{SYN-Flooding:} Dieser Angriff verwendet den Verbindungsaufbau des TCP-Transportprotokolls. Der Angreifer sendet ein hohes Volumen an SYN-Pakete an das Zielsystem. Oftmals sind die IP-Adressen der Pakete gefälscht. Das Zielsystem antwortet auf jede dieser Verbindungsanforderungen. Wenn die IP-Adressen gefälscht sind, dann geht diese Antowrt in Richtung der gespooften IP-Adressse. Zusätzlich allokiert das Zielsystem Speicher. Indem der Angreifer die letzte ACK-Nachricht unterschlägt ??? %fehlt
% \item \textbf{SYN-Frag-Attack:} Es handelt sich bei diesem Angriff um eine Variation des SYN-Floodings %fehlt
% \item \textbf{Teardrop:} Bei dieser Attacke sendet der Angreifer IP-Fragmente mit überlappenden Offset-Feldern, was beim Zusammensetzen der Fragmente zu Abstürzen führen kann.
% \item
% \item \textbf{UDP-Flooding:}
% \item
%\end{description}
\end{document}

86
doc/review_1/chapters/2-anforderungen.tex Normal file
View File

@ -0,0 +1,86 @@
\documentclass[../review_1.tex]{subfiles}
\graphicspath{{\subfix{../img/}}}
\begin{document}
\chapter{Anforderungen}
\noindent Im folgenden Kapitel werden die funktionalen und die nicht-funktionalen Anforderungen an das zu entwickelnde System beschrieben. Diese Anforderungen grenzen den Projektumfang eindeutig ein und legen fest, welche Eigenschaften das zu entwickelnde System haben soll. Dafür wird die \textbf{MuSCoW}-Methode verwendet, welche einführend kurz erläutert wird.
\section{Priorisierung der Anforderungen}\thispagestyle{fancy}
Um Anforderungen zu strukturieren und nach Wichtigkeit zu priorisieren, wird in der Regel ein System zur Klassifizierung der Eigenschaften verwendet. Hier wurde eine Priorisierung nach der \textbf{MuSCoW}-Methode vorgenommen:
\begin{description}
\item{\textbf{Must}:} Diese Anforderungen sind unbedingt erforderlich und nicht verhandelbar. Sie sind erfolgskritisch für das Projekt.
\item{\textbf{Should}:} Diese Anforderungen sollten umgesetzt werden, wenn alle Must-Anforderungen trotzdem erfüllt werden können.
\item{\textbf{Could}:} Diese Anforderungen können umgesetzt werden, wenn die Must- und Should-Anforderungen nicht beeinträchtigt werden. Sie haben geringe Relevanz und sind eher ein \glqq Nice to have\grqq.
\item{\textbf{Won't}:} Diese Anforderungen werden im Projekt nicht explizit umgesetzt, werden aber eventuell für die Zukunft vorgemerkt.
\end{description}
\section{Funktionale Anforderungen}
% Sie beschreiben das Systemverhalten durch Spezifikation der erwarteten Input-/Output-Beziehungen
% --> Was soll umgesetzt werden?
Funktionale Anforderungen legen konkret fest, was das System können soll. Hier wird unter anderem beschrieben, welche Funktionen das System bieten soll. Die folgende Tabelle zeigt diese funktionalen Anforderungen.
\begin{longtable} [h] {p{1cm} p{4cm} p{7cm} l}
\textbf{ID} & \textbf{Name} & \textbf{Beschreibung} & \textbf{MuSCoW} \\ \toprule \endhead
F01 & Lokale Administration & Das System muss lokal per Command-Line-Interface administriert werden können. & Must \\
F02 & Angriffsarten & Das System muss die Folgen der aufgelisteten (D)DoS-Angriffe abmildern können: \begin{itemize} \setlength{\parskip}{-2pt}
\item SYN-Flood
\item SYN-FIN Attack
\item SYN-FIN-ACK Attack
\item TCP-Small-Window Attack
\item TCP-Zero-Window Attack
\item UDP-Flood
\end{itemize}
Dabei ist vorausgesetzt, dass das Ziel eines Angriffes eine einzelne Station in einem Netzwerk ist und kein Netzwerk von Stationen. Es sind also direkte Angriffe auf einzelne Server, Router, PC, etc. gemeint. & Must \\
F03 & Keine zusätzliche Angriffsfläche & Besonders darf das System den unter ,,Angriffsarten'' spezifizierten Angriffen keine zusätzliche Angriffsfläche bieten, d.h. es darf es auch nicht durch Kenntnis der Implementierungsdetails möglich sein, das System mit diesen Angriffen zu umgehen. & Must \\
F04 & L3/ L4 Protokolle & Das System muss mit gängigen L3/ L4 Protokollen klarkommen. & Must \\
F05 & Modi & Passend zum festgestellten Angriffsmuster muss das System eine passende Abwehrstrategie auswählen und ausführen. & Must \\
F06 & Position & Das System soll zwischen dem Internet-Uplink und dem zu schützenden System oder einer Menge von Systemen platziert werden. & Must \\
F07 & Weiterleiten von Paketen & Das System muss legitime Pakete vom externen Netz zum Zielsystem weiterleiten können. & Must \\
F08 & Installation und Deinstallation & Das System muss durch Befehle in der Kommandozeile zu installieren und zu deinstallieren sein. Hilfsmittel hierzu sind: Installationsanleitung, Installationsskript, Meson und Ninja. & Must \\
F09 & Mehrere Angriffe nacheinander und zeitgleich & Das System muss mehreren Angriffen nacheinander und zeitgleich standhalten, hierbei muss berücksichtigt werden, dass auch verschiedene Angriffsarten und Muster zur gleichen Zeit erkannt und abgewehrt werden müssen. & Must \\
F10
& IPv4 & Das System muss mit IPv4-Verkehr zurechtkommen. & Must \\
F11 & Hardware & Das System soll nicht Geräte- bzw. Rechnerspezifisch sein. & Should \\
F12 & Zugriff & Der Zugriff auf das lokale System soll per SSH oder Ähnlichem erfolgen, um eine Konfiguration ohne Monitor zu ermöglichen. & Should \\
F13 & Betrieb & Das System soll auf Dauerbetrieb ohne Neustart ausgelegt sein. & Should \\
F14 & Privacy & Das System soll keine Informationen aus der Nutzlast der ihm übergebenen Pakete lesen oder verändern. & Should \\
F15 & Konfiguration & Der Administrator soll die Konfiguration mittels Konfigurationsdateien ändern können. & Can \\
F16 & Abrufen der Statistik & Der Administrator soll Statistiken über das Verhalten des Systems abrufen können. & Can \\
F17 & Starten und Stoppen des Systems & Der Administrator soll das System starten und stoppen können. & Can \\
F18 & Informieren des Anwenders & Der Anwender soll über Angriffe informiert werden. & Can \\
F19 & Administration über graphische Oberfläche & Das System soll über eine graphische Oberfläche administriert werden können. & Can \\
F20 & IPv6 & Das System soll mit IPv6-Verkehr zurechtkommen können & Can \\
F21 & Weitere Angriffsarten & Das schützt weder vor anderen außer den genannten DoS-Angriffen (siehe F02 \glqq Angriffsarten\grqq)-insbesondere nicht vor denjenigen, welche auf Anwendungsebene agieren-, noch vor anderen Arten von Cyber-Attacken, die nicht mit DoS in Verbindung stehen.
So bleibt ein Intrusion Detection System weiterhin unerlässlich. & Won't \\
F22 & Anzahl der zu schützenden Systeme & Das System wird nicht mehr als einen Server, Router, PC, etc. vor Angriffen schützen. & Won't \\
F23 & Fehler des Benutzers & Das System soll nicht vor Fehlern geschützt sein, da es durch eine nutzungsberechtigte Person am System ausgeführt wird. So sollen beispielsweise Gefährdungen, welche aus fahrlässigem Umgang des Administrators mit sicherheitsrelevanten Softwareupdates resultieren, durch das zu entwickelnde System nicht abgewehrt werden. & Won't \\
F24 & Softwareupdates & Das System soll keine Softwareupdates erhalten und soll nicht gewartet werden. & Won't \\
F25 & Router-/Firewall-Ersatz & Das System soll nicht als Router oder als Firewall-Ersatz verwendet werden. & Won't \\
F26 & Hardware-Ausfälle & Das System soll keine Hardwareausfälle (zum Beispiel auf den Links) beheben. & Won't \\
F27 & Fehler in Fremdsoftware & Das System kann nicht den Schutz des Servers bei Fehlern in Fremdsoftware garantieren. & Won't \\
\bottomrule
\end{longtable} %fehlt: Pakete weiterleiten, Pakete verwerfen
\section{Nichtfunktionale Anforderungen}
% beschreiben qualitative, aber auch quantitative Faktoren des zu entwickelnden Zielsystems
% --> Wie sollen die funktionalen Anforderungen umgesetzt werden?
Nichtfunktionale Anforderungen gehen über die funktionalen Anforderungen hinaus und beschreiben, wie gut das System eine Funktion erfüllt. Hier sind zum Beispiel Messgrößen enthalten, die das System einhalten soll. Im folgenden werden diese nichtfunktionalen Anforderungen beschrieben.
\begin{longtable}[ht] { p{1cm} p{4cm} p{7cm} l }
\textbf{ID} & \textbf{Name} & \textbf{Beschreibung} & \textbf{MuSCoW} \\ \toprule \endhead
NF01 & Betriebssystem & Die entwickelte Software muss auf einer Ubuntu 20.04 LTS Installation laufen. DPDK muss in Version 20.11.1 vorliegen und alle Abhängigkeiten erfüllt sein. & Must \\
NF02 & Verfügbarkeit & Die Verfügbarkeit des Systems soll bei mindestens 98\% liegen. Verfügbarkeit heißt hier, dass das System in der Lage ist, auf legitime Verbindungsanfragen innerhalb von 10 ms zu reagieren. & Must \\
NF03 & Datenrate & Die anvisierte Datenrate, welche vom externen Netz durch das zu entwickelnde System fließt, muss bei mindestens 20 Gbit/s liegen. & Must \\
NF04 & Paketrate & Die anvisierte Paketrate, welche vom zu entwickelnden System verarbeitet werden muss, muss bei mindestens 30 Mpps liegen. & Must \\
NF05 & Transparenz & Der Anwender soll das Gefühl haben, dass die Middlebox nicht vorhanden ist. & Should \\
NF06 & Abwehrrate SYN-Flood & Die für die Angriffe anvisierten Abwehrraten sind für die SYN-Flood, SYN-FIN und SYN-FIN-ACK jeweils 100\%. & Should \\
NF07 & False Positive & Der maximale Anteil an fälschlicherweise nicht herausgefiltertem und nicht verworfenem illegitimen Traffic, bezogen auf das Aufkommen an legitimem Traffic, soll 10\% im Angriffsfall und 5\% im Nicht-Angriffsfall nicht überschreiten. & Should \\
NF08 & False Negative & Der maximale Anteil an fälschlicherweise nicht verworfenem bösartigem Traffic, bezogen auf das Gesamtaufkommen an bösartigem Traffic, soll 5\% nicht überschreiten. & Should \\
NF09 & Round Trip Time & Die Software soll die Round-Trip-Time eines Pakets um nicht mehr als 10 ms erhöhen. & Should \\
\bottomrule
\end{longtable}
\end{document}

25
doc/review_1/chapters/3-anforderungsanalyse.tex Normal file
View File

@ -0,0 +1,25 @@
\documentclass[../review_1.tex]{subfiles}
\graphicspath{{\subfix{../img/}}}
\begin{document}
\chapter{Anforderungsanalyse}\thispagestyle{fancy} %Kopf- und Fußzeile an
\vspace{-1.5cm}
\begin{figure}[h]
\centering
\includegraphics[height = 8cm]{usecase1.png}
\caption{UML-konformes Use-Case-Diagramm}
\label{usecase1}
\end{figure}
\noindent Es wurde sich dafür entschieden, auch Akteure in das unten stehende Use-Case-Diagramm (siehe Abb. \ref{usecase2}) aufzunehmen, die nach den UML-Standards nicht in einem Use-Case-Diagramm (siehe Abbi. \ref{usecase1}) vorkommen.\\
Dadurch können auch Use-Cases modellieren werden, die über das Installieren und die grundlegenden administrativen Aufgaben hinausgehen.\\
So agiert beispielsweise der Angreifer in Abb. \ref{usecase1} nicht mit dem System. Jedoch ist er für das Verständnis, welche Schutzmechanismen ergriffen werden müssen, unerlässlich. Deshalb ist er in Abb. \ref{usecase2} hinzugekommen.\\
Der normale Nutzer soll möglichst wenig bis gar nichts vom Abwehrsystem mitbekommen, weswegen er nur mit wenigen Anwendungsfällen in Beziehung steht. \\
Somit ist dieses Anwendungsfalldiagramm ein Beispiel dafür, dass die Diagramme in diesem Projekt eine Sonderrolle einnehmen.
\begin{figure}[ht]
\centering
\includegraphics[width=13cm]{usecase2.png}
\caption{nicht UML-konformes Use-Case-Diagramm}
\label{usecase2}
\end{figure}
\end{document}

89
doc/review_1/chapters/4-aufwandsschaetzung.tex Normal file
View File

@ -0,0 +1,89 @@
\documentclass[../review_1.tex]{subfiles}
\graphicspath{{\subfix{../img/}}}
\begin{document}
\chapter{Aufwandsschätzung}\thispagestyle{fancy} %oder besser Aufwandsschätzung?
Zur Schätzung des Aufwands in einem IT-Projekt liegen verschiedene Verfahren vor. Methoden, wie beispielsweise das Analogieverfahren, bei welchem der Aufwand durch Analogieschlüsse aus anderen, bereits abgeschlossenen Entwicklungsprojekten geschätzt wird, sind für das vorliegende Projekt jedoch wenig geeignet. Denn für diese Art der Aufwandsschätzung müssen Aufwandsdaten bereits abgeschlossener Entwicklungsprojekte vorliegen. Diese Projekte sollen zudem in Punkten wie inhaltliches Ziel, Produktumfang, personelle und zeitliche Ressourcen oder Vorgehensweise sehr ähnlich sein. Solche Daten liegen zu diesem Projekt nicht vor.\\
Auch das Function Point Verfahren ist hier nicht anwendbar, da bei diesem nur mithilfe einer auf Erfahrung beruhenden Tabelle Functions Points in Aufwand umgerechnet werden können. Eine solche Tabelle liegt hier ebenfalls nicht vor. Zudem lassen sich viele der Anforderungen nicht eindeutig in die fünf Kategorien \glqq Eingabedaten\grqq, \glqq Ausgabedaten\grqq, \glqq Abfragen\grqq, \glqq Datenbestände\grqq{} und \glqq Referenzdateien\grqq{} einordnen. Allgemein werden im Function Point Verfahren nicht (oder nur indirekt) die Komplexität der Algorithmen und der Aufwand für unterstützende Aktivitäten wie Projektmanagement, Qualitätsprüfung oder Dokumentation berücksichtigt. Somit ist dieses Verfahren lediglich für betriebliche und kaufmännische Systeme gut geeignet, weniger aber für technische Anwendungen wie hier.\\
Anmerkung: Nachfolgende Aufwandsschätzungen werden während des Projektverlaufs weiter aktualisiert (zum Beispiel bei Änderungen von Anforderungen und/oder Meilensteinen).
\section{Parkinson's law}
Eine sehr bekannte, jedoch ironisierende Methode zur Aufwandsschätzung ist das Parkinsonsche Gesetz (engl.: \glqq Parkinson's law\grqq). Dieses lautet wie folgt: \glqq Work expands so as to fill the time available for its completion\grqq. Laut diesem Gesetz nimmt somit die Dauer der Arbeit genau die Zeit an, die ihr zur Verfügung steht. \\
Da für die Bearbeitung des Softwareprojekts drei Monate zur Verfügung stehen und das Projektteam aus acht Personen besteht, beträgt der Aufwand nach diesem Gesetz 24 Personenmonate.\\ \newline
\textbf{Interpretation des Ergebnisses:}\\ \newline
Das Ergebnis dieser Schätzung sollte nicht zur Planung und Kontrolle des Projektfortschritts verwendet werden, da es zum Aufschieben von Arbeit veranlasst und so die Effizienz reduziert. Dieses Gesetz spiegelt vielmehr den britischen Humor wieder, als es einen sinnvollen Beitrag zur Projektplanung leistet.\\
Um dem Aufschieben von Aufgaben entgegenzuwirken, zeigt jedoch das Parkinsonsche Gesetz indirekt eine einfache Lösung auf: Es müssen knappe Deadlines gesetzt werden. Das erhöht die Disziplin, die Aktivität und die Produktivität im Team. Der Goal-Gradient-Effekt bestärkt dies zusätzlich. So besagt dieses Gesetz, dass der Aufwand, den man in eine Sache investiert, umgekehrt proportional zur verbleibenden Zeit steigt.
\section{COCOMO II}
Bei COCOMO II (COnstrucitve COst MOdel), welches bereits 1981 durch den Softwareingenieur Barry W. Boehm entwickelt wurde, handelt sich es um ein algorithmisches Modell zur Aufwandsschätzung von Software. In diesem Modell werden zahlreiche Einflussfaktoren wie Quantität, Qualität oder Produktivität berücksichtigt. Zudem besteht COCOMO II aus drei Teilmodellen, welche sich unter anderem in den Skalenfaktoren oder den Modellkonstanten unterscheiden. Im Folgenden wird sich auf \textit{\glqq The Early Design Model\grqq{}} (Die frühe Entwicklungsstufe) bezogen, da diese Stufe stark zum derzeitigen Projektstand passt. Auf dieser Stufe liegen schon sowohl die Anforderungen als auch ein erster Grobentwurf vor.\\
Das Modell baut im Wesentlichen auf folgender Formel auf:
\begin{align}
PM = A \cdot \text{Größe}^E \cdot M
\label{formel1}
\end{align}
Für den Koeffizienten A wird der Erfahrungswert 2,5 angenommen.\\
Die Größe wird in KLSLOC (kilo source lines of code) angegeben. Sie beträgt hier 3,6. Als Referenzprojekt dient POSEIDON\cite{testFab}.
In diesem Projekt wurde eine DDoS-Abwehr durch ungefähr 3600 C/C++-Codezeilen implementiert. Im Unterschied zu der hier zu entwickelnden Software wurde jedoch ein komplettes Endprodukt entwickelt und kein Prototyp, wie es in dem vorliegenden Projekt der Fall ist.\\
Um den steigenden Aufwand bei wachsender Projektgröße zu berücksichtigen, wird der Exponent E, dessen Wert zwischen 1,01 und 1,26 liegt, verwendet. Durch die Bewertung unterschiedlicher Skalierungsfaktoren wird E berechnet. \\ \newline
\begin{tabular}[h] {l c p{8.0cm}}
\textbf{Faktor} & \textbf{Punkte} & \textbf{Bemerkungen} \\ \toprule
Neuartigkeit & 2 & Bei einzelnen Teammitgliedern liegt noch geringe Erfahrungmit dieser Art von Projekten vor. Dies ist oftmals begründet durch das junge Alter. Jedoch gibt es online schon Lösungen zu ähnlichen Problemen vor, an denen man sich orientieren kann. \\
Entwicklungsflexibilität & 2 & Zwar liegen einige Vorgaben zum Ablauf des SW-Projektes vor (z.B. die Einteilung in drei Hauptphasen), jedoch erlaubt das Vorgehensmodell Unified Process noch eine gewisse Flexibilität im Entwicklungsprozess. \\
Architektur/ Risikoauflösung & 3 & Die Risiken wurden rechtzeitig identifiziert und Maßnahmen überlegt. Jedoch könnten aufgrund der geringen Erfahrung noch Risiken unendeckt geblieben sein. \\
Teamzusammenhalt & 1 & Die Vertrautheit und Zusammenarbeit im Team ist optimal. \\
Ausgereiftheit des Prozesses & 5 & Der Prozess ist noch wenig ausgereift. \\
\end{tabular} \\ \newline
E lässt sich nun berechnen, indem man auf den fixen Wert 1,01 ein Hundertstel von der Summe der Punkte addiert.
\begin{align*}
E = 1,01 + \frac{2+2+3+1+5}{100}= 1,01 + 0,13 = 1,14
\end{align*}
M ergibt sich durch die Multiplikation folgender Projekt- und Prozessfaktoren:
\begin{itemize}
\setlength\itemsep{-1mm}
\item RCPX: Product Reliability and Complexity
\item RUSE: Developed for Resuability
\item PDIF: Platform Difficulty
\item PERS: Personnel Capability
\item PREX: Personnel Experience
\item FCIL: Facilities
\item SCED: Required Developement Schedule
\end{itemize}
Mithilfe der unteren Skala werden die einzelnen Projekt- und Prozessfaktoren bewertet. In der Farbe Rot sind diejenigen Faktoren gekennzeichnet, die auf das vorliegende Projekt am besten zutreffen.
\begin{center}
\begin{tabular} [h] {|l|c|c|c|c|c|c|c|}
\hline & \textbf{- - -} & \textbf{- -} & \textbf{-} & \textbf{\textasciitilde} & \textbf{+} & \textbf{++} & \textbf{+++} \\ \hline
RCPX & 0,49 & 0,60 & 0,83 & 1 & \textcolor{red}{1,33} & 1,91 & 2,72 \\ \hline
RUSE & & & \textcolor{red}{0,95} & 1 & 1,07 & 1,15 & 1,24 \\\hline
PDIF & & & \textcolor{red}{0,87} & 1 & {1,29} & 1,81 & 2,61 \\ \hline
PERS & 2,12 & 1,62 & {1,26} & \textcolor{red}{1} & 0,83 & 0,63 & 0,50 \\ \hline
PREX & 1,59 & \textcolor{red}{1,33} & 1,22 & 1 & 0,87 & 0,74 & 0,63 \\ \hline
FCIL & 1,43 & 1,30 & 1,10 & \textcolor{red}{1} & 0,87 & 0,73 & 0,62 \\ \hline
SCED & & 1,43 & {1,14} & \textcolor{red}{1} & 1 & 1 & n/a \\ \hline
\end{tabular}
\end{center}
Nun lässt sich der Multiplikator M berechnen:
\begin{align*}
M = PERS \cdot RCPX \cdot RUSE \cdot PDIF \cdot PREX \cdot FCIL \cdot SCED = 1,33 \cdot 0,95 \cdot 0,87 \cdot1 \cdot 1,33 \cdot 1 \cdot 1 \approx 1,22
\end{align*}
Jetzt sind alle Werte gegeben, um mithilfe der Formel \ref{formel1} den Aufwand in Personenmonate zu schätzen.
\begin{align*}
PM = A \cdot \text{Größe}^E \cdot M = 2,5 \cdot 3,6 \textsuperscript{1,14} \cdot1,22 \approx 13,17
\end{align*}
Nun kann der Aufwand in Personenmonat in Personenstunden umgerechnet werden die Folgende:
\begin{align*}
PS= 13,17 \cdot 160h = 2107h
\end{align*}
Das Team besteht aus zwei Wirtschaftsinformatiker, die jede Woche 15h für das Softwareprojekt aufwenden sollen, und sechs Informatiker und Ingenieurinformatiker, deren Wochenstundenanzahl bei 20h liegt. Das Softwareprojekt soll innerhalb von 12 Wochen beendet werden.\\
Somit ist die zur Verfügung stehende Zeit:
\begin{align*}
(2\cdot15 h+6\cdot20 h)\cdot12=1800h
\end{align*}
\textbf{Interpretation der Ergebnisse:}\\ \newline
Der Wert von 2107h liegt ca. 300h über dem angestrebten Wert von 1800h. Es kann unterschiedliche Gründe für diese Abweichung geben.\\
Ein Grund dafür könnte sein, dass im zu entwickelnden System kein schlüsselfertiges Produkt entwickeln wird, sondern vielmehr ein Prototyp. Somit könnte der Schätzwert von 3600 Codezeilen zu hoch gegriffen sein.\\
Durch die Komplexität des Projektes kann es zudem vorkommen, dass die 15 beziehungsweise 20 Wochenstunden nicht immer ausreichend sind und somit mehr Arbeitszeit aufgewendet werden muss.\\
Zudem muss keine Zeit zur Berücksichtigung von Support vorgesehen werden, da es nach den 12 Wochen als abgeschlossen angesehen werden kann.\\
Bereits kleine Änderungen an den Projekt- und Prozessfaktoren haben große Auswirkungen. Falls bereits einer dieser oben aufgeführten Faktoren ungenau geschätzt wurde, kann das Ergebnis verfälscht sein.\\
Abschließend kann noch angemerkt werden, dass es sich um eine Schätzung handelt. Schätzungen sind (fast) immer mit Ungenauigkeiten verbunden.
\end{document}

32
doc/review_1/chapters/5-risikoanalyse.tex Normal file
View File

@ -0,0 +1,32 @@
\documentclass[../review_1.tex]{subfiles}
\graphicspath{{\subfix{../img/}}}
\begin{document}
\chapter{Risikoanalyse}\thispagestyle{fancy}
\section{Risikoidentifikation}
Durch Befragung des gesamten Projektteams wurden sowohl fachliche, kaufmännische und planerische Risiken identifiziert. Indem Teammitglieder mit unterschiedlichen Erfahrungen und Fachkompetenzen miteinbezogen wurden, konnten Risiken aus verschiedenen Blickwinkeln identifiziert werden. In der folgenden Tabelle werden sowohl die verschiedenen Risiken als auch deren Eintrittswahrscheinlichkeit\footnote{Wert zwischen 0\% und 100\%. 0\% entspricht dem unmöglichen Ereignis, 100\% dem sicheren Ereignis. Ereignisse mit Werten nahe 0\% sind unwahrscheinlich, Ereignisse mit Werten nahe 100\% wahrscheinlich.}, Auswirkung und Maßnahmen kurz beschrieben.\\ Die dort beschriebenen Maßnahmen verfolgen das Ziel, die Eintrittswahrscheinlichkeit zu verringern und bei Eintritt die Auswirkungen abzuschwächen.\\
\textbf{Hinweis}: Die unten stehenden Tabelle wird im Laufe des Projektes noch weiter ergänzt, da die Risikoanalyse keine einmalige, sondern fortlaufende Aktivität im Projekt darstellt. So können beispielsweise neue Risiken auftauchen, die zu Beginn des Projektes noch nicht vorhanden waren oder übersehen wurden. Auch Eintrittswahrscheinlichkeiten können sich noch ändern. Außerdem ist es möglich, dass Auswirkungen und Maßnahmen hinzukommen oder verschwinden.
\begin{longtable}[h]{l p{2,5cm} p{2,5cm} p{3,5cm} p{3,5cm}}
\textbf{ID} & \textbf{Risiko} & \textbf{Eintrittswahr-scheinlichkeit} & \textbf{Auswirkung} & \textbf{Maßnahmen} \\ \toprule \endhead
R01 & Software wird unzureichend dokumentiert. & 30\% & Sicherheitslücken, falsch aufgefasste Anforderungen, Softwareanomalien, schwierige Wartung, Software kann nicht richtig getestet werden u. v. m. & Motivation der Teammitglieder dazu, dass diese gewissenhaft Dokumentation führen; Erklären der Wichtigkeit der Dokumentation; Einführen von Konventionen zur Dokumentation; Verwendung automatischer Dokumentationswerkzeuge \\
R02 & Unzureichende Erfahrung des Projektteams bezüglich neuer Tools (z. B. DPDK, Ninja, Meson) und der Programmiersprache C++ & 80\% & Zeitverzögerung (v. a. längere Dauer der Implementierung durch umfassende Einarbeitungsphase) & Gute Einarbeitung; Erstellen und Halten von Präsentationen zu schwierigen Themen; Gegenseitige Hilfe; Festlegen von Ansprechpartner für die einzelnen Themenbereiche \\
R03 & Weniger Austausch und weniger effiziente Zusammenarbeit durch Online-Lehre & 70\% & Probleme werden später oder nicht sichtbar; schwieriger Überblick über den Arbeitsstand bei anderen Teammitgliedern; Statusmeldungen fehlen; Geringes Teamgefühl & regelmäßige Treffen ohne Zeitdruck; möglichst organisierte Kommunikation (z.B. über Zulip oder Webex) \\
R04 & Hardware-Probleme (z. B. Ausfall oder andere Defekte) & 20\% & Zeitverzögerung, finanzielle Kosten & sorgfältiger Umgang mit der Hardware \\
R05 & Testbed nicht optimal konfigurierbar (aufgrund der verringerten Geräteanzahl und beschränkter Optionen ist nicht jede vorteilhafte Konstellation möglich) & 60\% & erschwerte Implementierung, Zeitverzögerung, Nichterfüllen einzelner Anforderungen, finanzielle Kosten beim Kauf zusätzlicher Hardware & möglichst effiziente Nutzung der vorhandenen Hardware; Kauf zusätzlicher Hardware; Entwicklung eines Netzwerkplans \\
\end{longtable}
\section{Risikomatrix}
\noindent Die folgende Risikomatrix (auch Risikoportfolio, Risikodiagramm oder Risiko-Map, siehe Abbildung 5.1) visualisiert die Projektrisiken R01 bis R06, indem sie die Eintrittswahrscheinlichkeiten und die dazugehörigen Schadensausmaße ins Verhältnis setzt. Je weiter man sich im Diagramm nach rechts bewegt, desto höher ist die Eintrittswahrscheinlichkeit. Während diese Wahrscheinlichkeit ganz links bei 0\% liegt, beträgt sie am rechten Rand 100\%. Je weiter oben sich das Risiko im Diagramm befindet, desto größer ist das Schadensausmaß.\\
Bei den Risiken, die sich im grünen Bereich befinden, sind keine zusätzlichen Maßnahmen zur Risikominimierung notwendig, wohingegen die Risiken im gelben Bereich so weit wie möglich abgemindert werden sollen. Die gefährlichsten Risiken befinden sich im roten Bereich. Für diese Risiken müssen geeignete Präventionsmaßnahmen getroffen werden, um sie in den gelben Bereich zu bewegen.\\
Ebenso kann man aus der Position der Risiken ableiten, wie dringend Präventionsmaßnahmen eingeführt werden müssen.\\
\begin{figure} [h]
\centering
\includegraphics[width=9cm]{risikomatrix.pdf}
\caption{Risikomatrix mit den Risiken R01 bis R06}
\end{figure}
\\ \newline Aus der Grafik lässt sich erkennen, dass vor allem für die Risiken R02, R03 und R05 geeignete Maßnahmen zur Minimierung der Risiken eingeführt werden müssen.
\section{Verbindung zum Vorgehensmodell}
Indem sich für den Unified Process als Vorgehensmodell entschieden wurde, werden in dem Projekt Risiken schon frühzeitig adressiert. Zudem werden zu Beginn jeder Phase jeweils die Punkte mit den größten Risiken zuerst bearbeitet.
\end{document}

117
doc/review_1/chapters/6-vorgehen.tex Normal file
View File

@ -0,0 +1,117 @@
\documentclass[../review_1.tex]{subfiles}
\graphicspath{{\subfix{../img/}}}
\begin{document}
\chapter{Vorgehen}\thispagestyle{fancy}
\section{Vorgehensmodell und die Anpassung des Vorgehens}
% damit ist v. a. die Anpassung an den Unified Process als Vorgehensmodell gemeint
Ein Vorgehensmodell legt einen bestimmten Ansatz für die Art der Durchführung und die Reihenfolge der Teilaufgaben der Systementwicklung maßgeblich fest. Erst mit einem Vorgehensmodell wird ein komplexer Softwareentwicklungsprozess übersichtlich, plan- und strukturierbar. Die Wahl des Vorgehensmodells ist deshalb von enormer Bedeutung.\\
Im \textbf{Wasserfallmodell} sind zwar Planung, Kontrolle und Steuerung vergleichsweise einfach, jedoch erfordern Rücksprünge einen hohen Änderungsaufwand in allen Dokumenten. Somit zeigt sich dieses sequentielle Modell unflexibel gegenüber Projekten, bei denen sich die Anforderungen an das zu entwickelnde Projekt oft verändern. Dies ist jedoch hier, da durch die Komplexität des Themas eventuell erst einige Anforderungen später identifiziert werden. \\
Es wurde gegen ein \textbf{agiles Vorgehen} gestimmt, da unter anderem das Projektmanagement in diesem Vorgehensmodell durch das chaotische Vorgehen sehr schwierig ist. Außerdem hat die Planbarkeit des Ergebnisse hohe Priorität.\\
Letztlich wurde sich für den \textbf{Unified Process} (siehe Abb. \ref{up}) entschieden. Dieses Vorgehensmodell nutzt die UML als Notationssprache.
\vspace{-0.3cm}
\begin{figure} [h]
\centering
\includegraphics[height = 6.5cm]{UnifiedProcess.pdf}
\caption{Angepasstes Vorgehensmodell (Unified Process)}
\label{up}
\end{figure}
\\ \newline Grundsätzlich besteht dieses iterative und inkrementelle Vorgehensmodell aus vier Phasen. Zu Beginn des Projekts werden in der \textbf{Konzeptionsphase} (inception phase) die zentralen Anforderungen ermittelt, der Projektumfang definiert und möglichst viele Projektrisiken entdeckt. Diese Phase stellt die Kürzeste dar. Sie endet mit dem Milestone lifecycle objective.\\
Auf die Konzeptionsphase folgt die \textbf{Ausarbeitungsphase} (elaboration phase), in der unter anderem die Systemanforderungen vervollständigt und die Entwurfsspezifikation entwickelt werden. Hier wird auch ein erster Protoptyp erarbeitet. In diesem Projekt umfasst diese Phase sowohl den Entwurf, als auch große Teile der Planung. Diese Phase besteht aus drei Iteration, wobei die Iterationen unterschiedlich lange sind. In jeder Iteration wird das vorherige Ergebnis verfeinert. \\
In der \textbf{Konstruktionsphase} (construction phase) findet ein Großteil der Implementierung, aber auch des Testens statt.\\
Die letzte Phase ist die \textbf{Inbetriebnahme} (transition phase). Die Auslieferung der Software an den Kunden wird im vorliegenden Projekt sehr kurz ausfallen. Jedoch wird in dieser Phase zusätzlich verstärkt getestet.\\
In den Phasen laufen verschiedene Kernprozesse zu unterschiedlichen Anteilen parallel ab. Man kann die einzelnen Phasen wie folgt ins Deutsche übersetzen: Business Modelling $\widehat{=}$ Geschäftsprozessmodellierung, Requirements $\widehat{=}$Anforderungsanalyse, Analysis and Design $\widehat{=}$ Analyse und Design, Implementation $\widehat{=}$ Implementierung, Test $\widehat{=}$ Test, Developmenent $\widehat{=}$ Auslieferung. \\
Aus dem agilen Vorgehen wurden für das Projekt einige Prinzipien übernommen: Zum einen die \textbf{häufigen Meetings} und \textbf{kurzen Statusmeldungen}, damit jedes Teammitglied genau weiß, wo die anderen Mitglieder stehen und was deren derzeitigen Probleme sind.\\
Zudem ist durch Gitlab ein \textbf{Kanbanboard} (siehe Abb. \ref{board}) verfügbar. Mit diesem agilen Projektmanagement-Tool werden die Aufgaben visualisiert. Es hilft dem Projektteam, die Arbeit zu strukturieren und so deren Effizienz zu steigern.\\
\vspace{-0.5cm}
\begin{figure} [h]
\centering
\includegraphics[height = 8cm]{kanban.png}
\caption{Board auf Gitlab (Datum des Screenshots: 15.05.2021)}
\label{board}
\end{figure} \\
\noindent Auch wurde sich innerhalb des Projektteams auf (agile) \textbf{Werte} geeinigt, um eine bestmögliche Zusammenarbeit zu gewährleisten (siehe Abb. \ref{werte}).
\begin{figure} [H]
\centering
\includegraphics[height = 5cm]{Werte.pdf}
\caption{Werte}
\label{werte}
\end{figure}
Jedes Teammitglied zeigt \textbf{Respekt} gegenüber die anderen und schätzt diese. Außerdem zeigen es jedem Verständnis, wenn beispielsweise jemand ein Problem hat. Zudem wird auch auf die Schwächeren Rücksicht genommen.\\
\textbf{Offenheit} bedeutet hier, dass neue Informationen und Erfahrungen bewusst aufgenommen werden und nicht vorschnell als unwichtig bewertet werden. Jeder darf seine Meinung frei äußern, um Missverständnissen und Auseinandersetzungen vorzubeugen. Ebenso soll Transparenz herrschen und Problemen sollen sofort auf den Grund gegangen werden. \\
Der Wert \textbf{Verpflichtung} kann so interpretiert werden, dass alle Teammitglieder sich der Projektaufgabe verbunden fühlen sollen.\\
Außerdem sind \textbf{Toleranz} und Vielfalt zentrale Werte. Personen mit anderen Sichtweisen werden nicht etwa als Konkurrenten gesehen, sondern vielmehr als Bereicherung für das Team.\\
Der \textbf{Fokus} liegt im Projekt vor allem auf den Aufgaben und auf den gemeinsamen Zielen. Verschwenden von Zeit und Kapazitäten und Ablenkungen sollen vermieden werden. Zudem hat die Fertigstellung einer bereits begonnen Aufgabe Vorrang gegenüber den Start einer neuen Aufgabe.\\
Indem in den Meetings regelmäßig der derzeitige Stand aufgezeigt wird, kann sich jedes Teammitglied individuelles \textbf{Feedback} von den anderen Beteiligten holen.\\
Zusätzlich soll jedes Teammitglied \textbf{Mut} aufweisen, indem es zum Beispiel neue Aufgaben übernimmt, die vielleicht zuerst als schwer machbar und komplex erscheinen. Außerdem erfordert es Mut zu sagen, wenn man Hilfe benötigt, aber auch mitzuteilen, dass man hinter dem Zeitplan liegt. Auch das Ausprobieren neuer Lösungswege fällt unter den Wert Mut.\\
Zudem ist die tägliche \textbf{Kommunikation} mit den Teammitgliedern für eine gute Zusammenarbeit erforderlich. So sollte jeder beispielsweise mehrmals täglich nach neuen Zulip-Nachrichten schauen und dort auf Fragen antworten. Außerdem wurde gemeinsam beschlossen, dass man bei Änderungen an den Dokumenten andere benachrichtigt.
\section{Projektplan}
Der Projektplan besteht aus verschiedenen Objekten: Dem Projektstrukturplan und einem Ablaufplan (hier Gantt-Diagramm).\\
Der \textbf{Projektstrukturplan}, welcher in Abb. \ref{projektstrukturplan} zu sehen ist, gliedert und strukturiert das Projekt hierarchisch. Er ist die Grundlage für die Ablaufplanung.
\begin{figure} [h]
\centering
\includegraphics[height = 12.5cm]{projektstrukturplan.pdf}
\caption{Projektstrukturplan}
\label{projektstrukturplan}
\end{figure} \\
Der \textbf{Ablaufplan} dient zur zeitlichen Darstellung des Projektablaufes. Die hier gewählte Darstellung ist das Gantt-Diagramm. Mittels Microsoft Project Professional wird so nicht nur das Projekt geplant, gesteuert und überwacht, sondern auch das Gantt-Diagramm erstellt.\\ In den Meetings wird regelmäßig der aktuelle Stand der einzelnen Teammitglieder abgefragt. Somit wird die Werte des Ganntt-Diagramms kontinuierlich aktualisiert. Die Gantt-Diagramme zu den verschiedenen Phasen sind in den Abbildungen \ref{vm1}, \ref{vm2}, \ref{vm3} und \ref{vm4} zu finden. Dort sind zudem die Abhängigkeiten zwischen den einzelnen Aufgaben zu sehen (zum Beispiel Anfang-zu-Anfang- oder Ende-zu-Anfang-Beziehungen)\\
%MS Project generiert zudem automatisch einen \textbf{Netzplan}, in dem Abhängigkeiten zwischen den einzelnen Teilaufgaben sichtbar werden (vgl. \ref{netzplan}).\\
\begin{figure} [h]
\centering
\includegraphics[width=7cm]{gantt_chart_projektvorbereitung.pdf}
\caption{Ausschnitt des Gantt-Diagramms für die Projektvorbereitungsphase (Stand: 14.05.2021)}
\label{vm1}
\end{figure}\\
\begin{figure} [h]
\centering
\vspace{-1cm}
\includegraphics[width=10cm]{gantt_chart_planung_entwurf.pdf}
\caption{Ausschnitt des Gantt-Diagramms für die Planungs- und Entwurfsphase (Stand: 14.05.2021)}
\label{vm2}
\end{figure}
\begin{figure} [h]
\centering
\vspace{-0.5cm}
\includegraphics[width=12cm]{gantt_chart_implementierung.pdf}
\caption{Ausschnitt des Gantt-Diagramms für die Implementierungsphase (Stand: 14.05.2021)}
\label{vm3}
\end{figure}
\begin{figure} [h]
\centering
\includegraphics[width=12cm]{gantt_chart_validierung.pdf}
\caption{Ausschnitt des Gantt-Diagramms für die Validierungssphase (Stand: 14.05.2021)}
\label{vm4}
\end{figure}
%\begin{figure} [h]
% \centering
% \includegraphics[width=\linewidth, height = 6cm]{netzplan.png}
% \caption{Ausschnitt des Netzplanes (Stand: 14.05.2021)}
% \label{netzplan}
%\end{figure}
\section{Meilensteine}
An dieser Stelle kommt zunächst die Frage auf, was ein Meilenstein eigentlich genau ist. Dabei handelt es sich um einen besonders wichtigen Punkt im Projektverlauf, an dem etwas überprüft wird. Ein Meilenstein kann ein Ereignis sein, an dem etwas abgeschlossen ist, etwas begonnen wird oder über die weitere Vorgehensweise entschieden wird.\\
Meilensteine umfassen nie eine Zeitdauer, sondern sind Zeitpunkte und werden meist am Ende von Projektphasen definiert. Es kann allerdings auch innerhalb einzelner Phasen zusätzliche Meilensteine geben.\\
Am 27.05.2021, am 24.06.2021 und am 21.07.2021 finden Reviews für das Softwareprojekt statt, bei denen die Ergebnisse der letzten Phase mit Unterstützung einer Präsentation durch ein oder zwei Studierende vorgestellt werden. Außerdem müssen bis zu diesen drei Tagen die jeweiligen Review-Dokumente fertiggestellt und eingereicht worden sein. Nach der Präsentation und Verteidigung der Ergebnisse werden diese bewertet. Da es sich dabei um Prüfpunkte handelt, stellt ein erfolgreich absolviertes Review die Erreichung eines Meilensteins dar. Außerdem wurde sich passend zum Unified Process für einen Meilenstein am Ende der ersten Konzeptionsphase entschieden.\\
Die vier Meilensteine des hier durchgeführten Projekts sind also die folgenden:
\begin{enumerate}
\item lifecycle objective
\item end\_elaboration
\item end\_construction
\item end\_transition
\end{enumerate}
Diese sind auch im GitLab erstellt und dein einzelnen Issues zugeordnet. Es bleibt noch anzumerken, dass das Erreichen des letzten Meilensteins gleichzeitig den Projektabschluss darstellt.\\
Außerdem können den drei Projektphasen Elaboration, Construction und Transmission noch jeweils drei Meilensteine mit Bezug zu den Review-Dokumenten zugeordnet werden. Diese sind:
\begin{enumerate}
\item end\_first\_version
\item end\_internal\_revision
\item end\_last\_revision
\end{enumerate}
Damit ist der Abschluss verschiedener Phasen der Erstellung der Review-Dokumente gemeint. Das Ziel lautet bei allen drei Phasen, circa eineinhalb Wochen vor der Abgabe eine erste Fassung erstellt zu haben. Wenn das geschafft wurde, ist der Meilenstein end\_first\_version erreicht. In den darauffolgenden Tagen wird diese Fassung intern, also durch alle Teammitglieder, überarbeitet und verbessert. Dieses überarbeitete Dokument wird dann eine Woche vor der endgültigen Abgabe bei Martin Backhaus eingereicht und der Meilenstein end\_internal\_revision ist erreicht. Schließlich wird in der Woche vor der Abgabe Feedback von Martin Backhaus eingearbeitet und letzte Verbesserungen werden vorgenommen. Mit der Abgabe des Dokuments ist auch der letzte Meilenstein end\_last\_revision erreicht.\\
\end{document}

45
doc/review_1/chapters/7-interne-organisation.tex Normal file
View File

@ -0,0 +1,45 @@
\documentclass[../review_1.tex]{subfiles}
\graphicspath{{\subfix{../img/}}}
\begin{document}
\chapter{Interne Organisation}\thispagestyle{fancy} \section{Rollen}
% Welche Rollen gibt es, wie sind sie besetzt und für was ist welche Rolle verantwortlich?
Abhängig von individuellen Fähigkeiten und Interessen der einzelnen Teammitglieder wurden zu Beginn folgende Rollen zugeteilt:
\begin{table} [h]
\centering
\begin{tabular} {lll}
\textbf{Rolle} & \textbf{Name} & \textbf{Studiengang} \\ \toprule
Projektleiterin & Fabienne Göpfert & Wirtschaftsinformatik \\
Systemarchitekt & Robert Jeutter & Informatik \\
DPDK-Chief & Jakob Lerch & Ingenieurinformatik \\
Redakteur & Tim Häußler & Wirtschaftsinformatik \\
Dokumentation & Leon Leisten & Informatik \\
Build Engineer & Johannes Lang & Informatik \\
Qualitätsmanager bzw. Tester & Tobias Scholz & Ingenieurinformatik \\
Angreifer & Felix Hußlein & Informatik \\
Entwickler & alle Teammitglieder & - \\
\end{tabular}
\end{table}
\\Im Folgenden werden die Rollen und die dazugehörigen Aufgaben näher beschrieben. \\
Die \textbf{Projektleitung} übernimmt im Projekt die operative organisatorische Leitung. Dabei ist sie nicht nur verantwortlich für die Koordination der Mitglieder, der Organisation des Ablaufs oder der Kontrolle und Bewertung des Projektergebnisses, sondern muss auch \glqq jedem Teammitglied das Gefühl [geben], es habe selbst entschieden\grqq (Daniel Goeudevert). Zudem stellt die Projektleitung die Schnittstelle zur Umgebung des Projekts dar, was sich zum Beispiel in der Kommunikation mit Stakeholdern widerspiegelt. Um diese Rolle bestmöglich erfüllen zu können, ist Kommunikationsfähigkeit, große Zuverlässigkeit und hohes Verantwortungsbewusstsein erforderlich. Auch sind Erfahrung bei der Organisation, Planung und Steuerung hilfreich, die zumindest durch theoretische Veranstaltungen wie \glqq IT-Projektmanagement\grqq{} oder \glqq Geschäftsprozessmanagement\grqq{} Wirtschaftsinformatiker und -informatikerinnen vorweisen können. \\
Das Überblicken aller Komponenten und der Zusammenarbeit derer ist die Aufgabe des \textbf{Systemarchitekten}. Zudem ist er für die Entwicklung der Architektur des Systems und die Erweiterung vorhandener Architekturen zuständig. Vor allem im Systementwurf und der Systemspezifikation ist diese Rolle stark von Bedeutung. Um all diese Aufgaben zu erfüllen, sind Fähigkeiten wie ein tiefes Verständnis im technischen Bereich, Kenntnis in Methodenentwicklung und Kommunikationsfähigkeit erforderlich.\\
Die Rolle des \textbf{DPDK-Chiefs} ist stark projektspezifisch. DPDK steht dabei für Data Plane Development Kit, wobei es sich um ein schnelles Paketverarbeitungsframework auf Benutzerseite speziell für leistungsintensive Anwendungen handelt. Die Rolle des DPDK-Chiefs muss DPDK tiefer verstehen und dieses gewonnene Verständnis auch mit seinen Teammitgliedern kommunizieren. Zudem steht er diesen als ständiger Ansprechpartner zu diesem Thema zur Verfügung.\\
Zu den Aufgaben eines \textbf{Redakteur} gehört das Konzipieren, Erstellen und Überprüfen von Dokumentationen. Solche Dokumente können zum Beispiel die Installationsanleitung, das Pflichtenheft oder die Entwicklerdokumentation sein. Um diese Aufgaben erfüllen zu können, muss der Redakteur im stetigen Austausch mit den Entwicklern stehen.\\
Zur \textbf{Dokumentation}: Diese Rolle ist dafür zuständig, ein Softwaredokumentationswerkzeug auszuwählen und festzulegen, was genau auf welche Weise dokumentiert werden soll. Weiterhin ist er der Ansprechpartner für alle Fragen zur Dokumentation und kümmert sich um die Voll- ständigkeit der Code-Dokumentation.\\ Der \textbf{Build Engineer} plant das Build System und die Unit Tests. Außerdem ist er für die Versionierung zuständig.\\
Die Rolle des \textbf{Qualitätsmanagers und Testers} hat zahlreiche Aufgaben. Der Tester definiert verschiedene Testfälle. Er leitet diese Testfälle sowohl aus der Spezifikation (funktionale Testverfahren), als auch aus der Struktur des Quellprogramms ab (strukturelle Testverfahren). Daraufhin wählt der Tester verschiedene Testdatenkombinationen aus und definiert das erwartete Softwareverhalten. Nachdem er das Testobjekt mit einer Testdatenkombination ausgeführt hat, vergleicht er das erwartete mit dem tatsächlichen Verhalten. Das Testergebnis wird anschließend dokumentiert. Falls Fehler erkannt wurden, müssen diese an die Entwickler zur Fehlerbehebung weitergegeben werden. Nachdem diese Rolle auch das Qualitätsmanagement umfasst, kommen noch folgende Aufgaben hinzu: die Qualitätsplanung, d.h. die Planung der Anforderungen an ein Produkt (bzw. an das Projekt); die Qualitätsplanung, d.h. das steuernde Eingreifen bei Abweichungen von den Anforderungen; die Qualitätssicherung, d.h. Vertrauen schaffen, dass die Qualitätsanforderungen eingehalten werden; Qualitätsverbesserung, d.h. die kontinuierliche Verbesserung des Ausmaßes der Erfüllung von Anforderungen.\\
Aufgaben wie das Vorbereiten von Angriffen und das Ausführen von Tests gehören zu den Aufgaben des \textbf{Angreifers}. Der Angreifer versucht, das Programm durch gezielte Angriffe zu einem Zustand der Nichtfunktionalität zu bringen. Dabei baut der Angreifer nicht nur eine einzelne Verbindung vom Angriffsrechner zum Server auf, wie es bei DoS-Attacken der Fall ist, sondern er kann auch eine Vielzahl (dezentraler) Quellen für den Angriffstraffic nutzen. Dies erschwert es, den Angriff abzudämmen. Eine solche Attacke, welche in der Praxis von Bot-Netzen ausgeht, nennt man DDoS-Attacke (DDoS steht hierbei für \glqq Distributed Denial of Service\grqq). Zur weiteren Aufgabe des Angreifers zählt es, die Software auf neue Angriffspotentiale zu untersuchen. Außerdem soll er Informationen bereitstellen, um diese Angriffe zu verhindern.
\section{Kommunikationswege}
Das meist genutzte Kommunikationstool ist das Open Source-Tool \textbf{Zulip}. Dabei handelt es sich um ein Gruppen-Chatsystem, das vom Fachgebiet Telematik betrieben wird und zur Kommunikation aller Teammitglieder untereinander und mit dem Betreuer Martin Backhaus verwendet wird.\\
Wesentliche Vorteile von Zulip sind im Folgenden kurz beschrieben: Clients sind für alle gängigen Plattformen verfügbar und man kann sowohl Gruppen- als auch Direktnachrichten versenden. Weiterhin braucht man sich nicht mit fragwürdigen Datenschutzbestimmungen beschäftigen. Außerdem unterstützt die Software Markdown und Syntaxhervorhebung und einzelne Personen lassen sich mit \glqq @\grqq{} markieren, wodurch eine direkte und effiziente Kommunikation möglich wird.\\
Bezüglich der Organisation gibt es mehrere Streams, also themenspezifische Gruppenchats. Es gibt einen Haupt-Stream und einige weniger genutze Streams. Weiterhin wird ein Stream in mehrere Topics (Themen) unterteilt, z. B. für die Agenda eines bestimmten Treffens, konkrete Fragen zum Installieren von DPDK oder zum Git-Workflow. Es ist möglich, sich entweder alle Nachrichten oder nur die Nachrichten einer bestimmten Topic anzeigen zu lassen und somit mehrere Diskussionen gleichzeitig zu führen.\\
Für die Meetings wird auf \textbf{Cisco Webex Meetings} zurückgegriffen. Das ist ein Tool für Videokonferenzen, das von der Universität bereitgestellt wird. Über einen Link, den alle Teammitglieder vor dem Meeting erhalten, kann sich jeder einwählen. Die Software steht für alle gängigen Betriebssysteme zur Verfügung und bietet das Feature, den Bildschirm zu teilen, um Präsentationen zu zeigen oder gemeinsam an einem Dokument zu arbeiten. Bei technischen Schwierigkeiten mit Webex oder für interne Treffen wird auch teilweise auf \textbf{Jitsi} zurückgegriffen.\\
Eine weitere Form der Kommunikation stellt \textbf{GitLab} dar. Dabei handelt es ich um ein Open Source-Versionsverwaltungssystem, das für das Projekt benutzt wird. Issues, Labels und Branches sollen aussagekräftig benannt werden. Außerdem besteht für das Projekt ein Wiki, über das verschiedenste Informationen ausgetauscht werden, z.B. Protokolle für jedes Meeting, nützliche Links, der Git-Workflow, verwendete Software u.v.m.\\
Die gemeinsam beschlossenen Bennenungskonventionen besagen, dass z.B. Branch-, Issue-, Ordner- und Dateinamen klein geschrieben werden. Des weiteren soll nur ASCII und nur die englische Sprache benutzt werden, mit Ausnahme des Wikis, der Präsentationen und der Review-Dokumente.
\section{Weitere organisatorische Festlegungen}
% umfasst z. B. die Anzahl und Art der Gruppentreffen
Das komplette Projektteam trifft sich zweimal wöchentlich für circa 90 Minuten mit seinem Betreuer Martin Backhaus. Zu diesen Treffen ist pünktliches Erscheinen erfordert. Diese Treffen werden durch zweimal wöchentliche interne Team-Meetings ergänzt. Der zeitliche Umfang dieser Meetings variiert je nach Bedarf. Zu jedem Meeting wird im Vorhinein eine Agenda erstellt. Regelmäßig wird in diesen Meetings der derzeitige Stand abgefragt, Zudem werden wichtige Entscheidungen protokolliert und in das Gitlab-Wiki übertragen. In diesem Wiki werden außerdem nützliche Links geteilt und Wissen weitergegeben.\\
Um den Einstieg in das Projekt zu erleichtern, wurde am 06.05.2021 von je zwei Teammitgliedern eine Präsentation halten. Die Themen der Präsentationen umfassten DPDK, Denial-of-Service-Angriffe, effizienten Datenstrukturen, Git und Latex.
\end{document}

320
doc/review_1/chapters/8-doku-geplanter-entwurf.tex Normal file
View File

@ -0,0 +1,320 @@
\documentclass[../review_1.tex]{subfiles}
\graphicspath{{\subfix{../img/}}}
\begin{document}
\chapter{Dokumentation des geplanten Entwurfs}\thispagestyle{fancy}
In folgendem Kapitel werden die grundlegenden Entscheidungen des Entwurfs erklärt und durch die Rahmenbedingungen begründet. Ein intuitiver Einstieg soll durch das Schrittweise heranführen an das System über Erklärung des Netzwerkaufbaus, der Angriffsarten sowie Abwehrmechanismen, hin zu den UML-Diagrammen geboten werden.
\section{Netzwerkaufbau}
Die Abbildung \ref{fig:netzwerkplan-real} zeigen den typischen, zu erwartenden Netzwerkaufbau, welcher in dieser Form im Internet und in der Produktivumgebung vorkommen würde. Das System untergliedert sich grob in drei Teile. Links im Bild ist jeweils das Internet zu erkennen, in diesem sind verschiedene Netzwerke mit jeweils verschiedenen Computern miteinander verbunden. Unter den vielen Computern im Internet, welche für Serversysteme teilweise harmlos sind, befinden sich allerdings auch einige Angreifer. Hier ist ganz klar eine Unterscheidung vorzunehmen zwischen dem Angriff eines einzelnen Angreifers, oder einer Menge von einem Angreifer gekapterten und gesteuerten Computer, also eines Botnets.
Wird das Internet, hin zum zu schützenden Netzwerk, verlassen, so wird zuerst ein Router vorgefunden, welcher Aufgaben wie die Network Address Translation vornimmt. Hinter diesem Router befände sich im Produktiveinsatz nun das zu entwickelnde System. Router und zu entwickelndes System sind ebenfalls über eine Verbindung mit ausreichend, in diesem Fall 25Gbit/s, Bandbreite verbunden. Das System selbst agiert als Mittelsmann zwischen Router, also im Allgemeinen dem Internet, und dem internen Netz. Um mehrere Systeme gleichzeitig schützen zu können, aber dennoch die Kosten gering zu halten, ist dem zu entwickelnden System ein Switch nachgeschaltet, mit welchem wiederum alle Endsysteme verbunden sind.
Leider ist durch Begrenzungen im Budget, der Ausstattung der Universität sowie der Unmöglichkeit das Internet in seiner Gesamtheit nachzustellen ein exakter Nachbau des Systems für dieses Projekt nicht möglich, weswegen ein alternativer Aufbau gefunden werden musste, der allerdings vergleichbare Charakteristika aufweisen muss.
Der für das Projekt verwendete Versuchsaufbau untergliedert sich ebenfalls in drei Teile, auch hier beginnt die Darstellung \ref{fig:Versuchsaufbau} ganz links mit dem System, welches Angreifer und legitimen Nutzer in sich vereint. Um also die Funktionalität von Angreifer und Nutzer gleichzeitig bereitstellen zu können, setzt der Projektstab in diesem Fall auf das Installieren zweier Netzwerkkarten in einem Computer. Eine 10Gbit/s Netzwerkkarte ist mit der Aufgabe betraut, legitimen Verkehr zu erzeugen. Da aufgrund der Hardwarerestriktionen keine direkte Verbindung zur Middlebox aufgebaut werden kann, wird der ausgehende Verkehr dieser Netzwerkkarte in einen Eingang einer zweiten, in dem selben System verbauten Netzwerkkarte mit einer maximalen Datenrate von 25Gbit/s eingeführt. Von dieser führt ein 25Gbit/s Link direkt zur Middlebox. Intern wird nun im System der rechten Seite sowohl legitimer Verkehr erzeugt als auch Angriffsverkehr kreiert, wobei diese beiden Paketströme intern zusammengeführt werden, und über den einzigen Link an die Middlebox gemeinsam übertragen werden. Die Middlebox selbst ist nicht nur mit dem externen Netz verbunden, sondern hat über die selbe Netzwerkkarte auch noch eine Verbindung ins interne Netz. Das gesamte interne Netz wird im Versuchsaufbau durch einen einzelnen, mit nur 10Gbit/s angebundenen Computer realisiert.
Die Entscheidung zur Realisierung in dieser Art fiel, da insbesondere der Fokus darauf liegen soll, ein System zu erschaffen, welches in der Lage ist, mit bis zu 25Gbit/s an Angriffsverkehr und legitimen eingehenden Verkehr zurechtzukommen. Aus diesem Grund ist es ausreichend, eine Verbindung zum internen Netz mit nur 10Gbit/s aufzubauen, da dieses System bei erfolgreicher Abwehr und Abschwächung der Angriffe mit eben diesen maximalen 10Gbit/s an legitimen Verkehr zurecht kommen muss. Ursächlich für die Verwendung der 10Gbit/s Netzwerkkarte im externen Rechner, welcher hierüber den legitimen Verkehr bereitstellen soll, ist, dass der Fokus bei einem solchen Schutzmechanismus natürlich darauf beruht, die Datenrate des Angreifers zu maximieren, um das zu entwickelnde System in ausreichendem Maße belasten und somit Stresstests unterwerfen zu können.
\begin{figure}[t]
\centering
\includegraphics[width=1.0\linewidth]{Netzwerkplan-Real}
\caption{Realaufbau unter Verwendung eines Angreifers}
\label{fig:netzwerkplan-real}
\end{figure}
\begin{figure}[t]
\centering
\includegraphics[width=0.6\linewidth]{Netwerkplan-Versuch}
\caption{Versuchsaufbau}
\label{fig:Versuchsaufbau}
\end{figure}
\section{Angriffsvarianten und Abwehrmechanismen}
Das zu entwickelnde System muss Schutz bieten, gegen die bereits in der Analyse erwähnten Angriffe. Hierunter fallen die SYN-Flut, der SYN-FIN beziehungsweise SYN-FIN-ACK Angriff, sowie die beiden Ausformungen des Sockstress, TCP Small- und TCP Zero-Window. Des weiteren muss Schutz gegen die UDP Flut geboten werden.
Zur Verhinderung der Angriffe ist im Aufbau \ref{fig:Versuchsaufbau} vorgesehen, dass sich eine Middlebox zwischen dem zu schützenden System und dem externen Netz befindet. Um einen effektiven Schutz gegen oben genannte Angriffe bieten zu können, wird eine Inspektion der Verbindungsströme zum Einsatz kommen. Prinzipiell ist vorgesehen, dass die Middlebox alle gesendeten Pakete abfängt, inspiziert, klassifiziert und bei Erkennung von Angriffen auf diese reagiert, sowie legitimen Verkehr an die entsprechenden Server und Nutzer weiterleitet. Die Detektion und Klassifizierung geschieht dabei individuell nach Angriffsmuster.
\subsection{SYN-FIN und SYN-FIN-ACK Attacke}
\begin{figure}[t]
\centering
\includegraphics[width=0.5\linewidth]{SYN-FIN}
\caption{Schematische Darstellung der SYN-FIN Attacke}
\label{fig:SYN-FIN}
\end{figure}
Eine SYN-FIN-(ACK) Attacke zeichnet sich dadurch aus, dass ein Angreifer, oftmals in Form eines Botnets, in Abbildung \ref{fig:SYN-FIN} auf der rechten Seite zu sehen, unablässig TCP Pakete mit gesetztem SYN und FIN Flag an das Opfer schickt. In Folge dessen ist es möglich, dass der Server in einem Close\_Wait Zustand gefangen ist, und in Folge dessen betriebsunfähig wird.
Zur Erkennung einer SYN-FIN sowie SYN-FIN-ACK Attacke werden die gesetzten TCP Flags verwendet, sobald in einem TCP Paket sowohl SYN als auch FIN oder in zweitem Fall zusätzlich noch das ACK-Flag gesetzt sind, klassifiziert die Software das Paket als verdächtig und verwerfen dieses in Folge der Abwehrstrategie.
Abbildung \ref{fig:seqsynfinack} zeigt den wohl einfachsten Ablauf einer Abwehrstrategie, bei der SYN-FIN-(ACK) Attacke reicht der Analyzer selbst aus um die Abwehr zu realisieren. Zuerst erhält der Analyzer die Paketinfos in Form eines rte\_ring Pointers, es folgt die Detektion des Angriffs, sobald ein Paket erkannt wurde, welches die Angriffscharakteristika aufweist, wird dieses gedroppt.
\subsection{SYN-Flut}
\begin{figure}[t]
\centering
\includegraphics[width=0.5\linewidth]{SYN-Flood}
\caption{Schematische Darstellung der SYN-Flut Attacke}
\label{fig:SYN-Flood}
\end{figure}
Eine SYN-Flut Attacke läuft prinzipiell wie folgt ab. Der Angreifer, in Abbildung \ref{fig:SYN-Flood} mittig dargestellt, schickt viele TCP Pakete mit gesetztem SYN-Flag an das Opfer, und bekundet somit den Wunsch eine Verbindung aufzubauen. Der Server antwortet mit TCP Pakten mit gesetzten SYN-ACK Flags und speichert erste Informationen über die sich im Aufbau befindende Verbindung, welche allerdings aufgrund von gefälschten IP Absenderadressen oder einer Verwerfstrategie am Angriffsrechner nie mit dem vom Server erwarteten TCP Paket mit ACK Flag beantwortet wird. Der Server hält also Informationen für Verbindungen vor, welche nie korrekt aufgebaut wurden und werden. Dies führt im schlechtesten Fall zu abgelehnten Verbindungen von legitimen Nutzern oder einem Totalausfall des Servers.
Die Erkennung einer SYN-Flut beruht auf der Zählung der eingehenden TCP Pakete, welche das SYN-Flag gesetzt haben, den ausgehenden Paketen, welche das SYN und ACK Flag gesetzt haben, sowie der Anzahl an zu den Verbindungsaufbauanfragen gehörenden ACKs, also den letztendlich gelungenen Verbindungsaufbauten.
Um einer SYN-Flut standzuhalten, setzt das zu entwickelnde System auf die Verwendung von SYN-Cookies, hierbei speichert die Middlebox keine Informationen über halboffene Verbindungen, sondern lagert diese Informationen in den Paketheader aus. Die Sequenznummer eines Paketes enthält nun das Ergebnis einer Hashfunktion, welche die Informationen, welche vorher gespeichert waren, kodiert. Dies beschreibt wie sich die Middlebox selbst vor einer SYN-Flut schützt. Um allerdings die dahinterliegenden Server zu schützen, übernimmt die Middlebox auch eine weitere Funktion. Sie baut für alle zu schützenden Systeme die TCP Verbindungen mit externen Hosts auf, sobald dies erfolgreich geschehen ist, wird durch das zu entwickelnde System eine weitere Verbindung mit dem Zielrecher des ursprünglich von außen ankommenden Pakets auf, und leitet fortan Pakete von der externen Verbindung an die Interne weiter. Dies geschieht unter anderem durch eine Anpassung von Sequenznummern mittels eines verbindungsspezifischen Offsets, nicht zu vergessen ist hierbei die Anpassung der Checksumme und anderer Headerfelder.
Abbildung \ref{fig:SYN-Flood-Abwehr} soll den geplanten Aufbau nochmals verdeutlichen und insbesondere zum besseren Verständnis des Sequenznummermappings beitragen. Wie in der Abbildung angedeutet, findet zuerst ein Verbindungsaufbau zwischen Middlebox und externem System statt, sobald die Middlebox ein passendes ACK vom externen Nutzer erhalten hat, wird von der Middlebox eine Verbindung zum eigentlichen Ziel aufgebaut. In Folge dessen muss nun für jedes nachfolgende Paket, unabhängig davon, ob dieses von Innen nach Außen oder umgekehrt geschickt wird, eine Anpassung der Sequenznummern vorgenommen werden. Anzumerken ist hierbei, dass in Abbildung \ref{fig:SYN-Flood-Abwehr}, die Payload X als Anfrage, und die Payload Y als Antwort hierauf zu verstehen ist.
\begin{figure}[t]
\centering
\includegraphics[width=0.5\linewidth]{SYN-Flood-Abwehr}
\caption{Schematische Darstellung des Abwehr der SYN-Flood}
\label{fig:SYN-Flood-Abwehr}
\end{figure}
% Sollte die Kombination aus diesen beiden Verhinderungsstrategien widererwartens nicht ausreichend sein, wäre auch eine zusätzliche SYN-Authentication denkbar
\subsection{Zero-Window}
\begin{figure}[t]
\centering
\includegraphics[width=0.5\linewidth]{Zero-Window}
\caption{Schematische Darstellung der Zero-Window Attacke}
\label{fig:Zero-Window}
\end{figure}
Die TCP-Zero-Window Attacke, siehe Abbildung \ref{fig:Zero-Window} beruht darauf, dass ein Angreifer mehrere Verbindungen zu einem Opferserver aufbaut, und sein Empfangsfenster auf Größe 0 setzt. Somit werden auf dem Server Ressourcen für eine Verbindung verbraucht, welche keinen legitimen Zweck hat.
Werden sehr viele solcher Verbindungen aufgebaut, kann es gar geschehen, dass ein Server keinerlei legitime Verbindungen mehr aufbauen kann. Allerdings kann es auch in legitimen Verbindungen kurzzeitig dazu kommen, dass das Empfangsfenster des Nutzers auf die Größe null gesetzt wird.
Um die TCP Zero Window Attacke zu erkennen, wird unter Anderem die Zählung aller Verbindungen, welche ein Zero-Window ankündigen, verwendet. Da dies alleine allerdings zur Erkennung nicht ausreichend ist, muss eine zeitliche Statistik über diese Verbindungen geführt werden. Sobald eine TCP Verbindung über einen gewissen Zeitraum ein Zero-Window ankündigt und dies nie verändert, wird die Verbindung als auffällig erkannt. Bei genauerer Kenntnis der zu schützenden Systeme wäre es ebenfalls möglich zu zählen, wie viele TCP-Verbindungen zu einem gewissen System mit Fenstergröße null aufgebaut sind. Hierdurch könnte nun bei Kenntnis der maximal erlaubten konkurrierenden Verbindungen eines Webservers, errechnet werden, ob die Anzahl der Verbindungen mit Fenstergröße null einen kritischen Anteil erreicht. Als Lösungsstrategie ist hier ein Timeout für TCP-Verbindungen mit Fenstergröße 0 vorgesehen, sowie eine Ratenbegrenzung von TCP-Verbindungen pro Zielsystem.
\subsection{Small-Window}
\begin{figure}[t]
\centering
\includegraphics[width=0.55\linewidth]{Small-Window}
\caption{Schematische Darstellung der Small-Window Attacke}
\label{fig:Small-Window}
\end{figure}
Ein TCP-Small Window Angriff, siehe \ref{fig:Small-Window} beruht prinzipiell darauf, das ein Angreifer eine TCP Verbindung zu einem Server aufbaut und direkt eine sehr große Datei anfordert. Hierbei setzt der Angreifer gleichzeitig sein Empfangsfenster auf eine sehr kleine Größe, sodass der sendende Server die angeforderte Ressource zuvor in viele kleine Fragmente aufteilen muss. Dies kostet nicht nur Speicherplatz, sondern auch Rechenleistung. Als Resultat ist es möglich, dass der Server Speicherüberläufe erleidet und gänzlich abstürzt.
Die Erkennungsstrategie von TCP Small Window stellt sich als schwieriger zu Realisieren dar, hier sind bislang verschiedene Optionen im Gespräch. Eine Auffälligkeit, welche ein Angreifer aber leicht umgehen könnte, sind der konstante Einsatz von nur einer Fenstergröße. Unter Umständen lässt sich die Erkennung noch verbessern, wenn das zu entwerfende System eine Übersicht über alle abrufbaren Ressourcen der zu schützenden Systeme besitzt.
Die Verhinderung oder Abschwächung von TCP Small Window Angriffen beruht auf dem Setzen eines absoluten Verbindungstimeout, dessen Wert sich an der mittleren Verbindungsdauer für diesen Server oder dieses Netzwerk orientiert. Um den Schutz noch effektiver zu gestalten wird des Weiteren eine minimale, nicht zu unterschreitende Datenrate definiert. Fallen mehrere Verbindung unter diese Rate, so sind die ältesten als nicht legitim zu erachten und zu beenden.
\subsection{UDP-Flood}
\begin{figure}[t]
\centering
\includegraphics[width=0.55\linewidth]{UDP-Flood}
\caption{Schematische Darstellung der UDP-Flood}
\label{fig:UDP-Flood}
\end{figure}
Die UDP-Flut, siehe Abbildung \ref{fig:UDP-Flood}, zeichnet sich durch eine hohe Anzahl an UDP-Nachrichten an einzelne Zielsysteme aus. Für jede Nachricht prüft das Opfersystem, ob gerade eine Anwendung auf diesem Port lauscht, ist dies nicht der Fall, so reagiert es mit Port unreachable Nachrichten. Die Überprüfung und der Versand dieser Nachrichten benötigt Rechenleistung und Zeit. Im schlechtesten Fall wird durch diesen Angriff der Verkehr komplett zum Erliegen gebracht.
Zur Erkennung dieser würde auf die Verbindungsstatistik, welche darstellt, auf welchen Zielrechnern vermehrt Ports angefragt werden, gesetzt. Wird bei einem zu schützenden Server eine fest definierte Abfragerate überschritten, würde das System eine UDP Flood erkennen. Da dies allerdings im angestrebten Abwehrszenario nicht benötigt wird, um den Angriff abzuwehren, findet im System diese Erkennung ausschließlich zu statistischen Zwecken statt. Um die UDP-Flut allerdings erfolgreich Abwehren zu können, setzt das System auf eine Ratenlimitierung für UDP Traffic pro zu schützendem System.
%\subsection{Zusätzlich} %TODO
%Im Allgemeinen wäre es in diesem System unter Umständen auch sinnvoll, White- und Blacklists einzusetzen, welche gewissen externen IPs Zugriff gestatten oder komplett verweigern. Um den Rechenaufwand auf dem System zu verringern, wäre es auch von Vorteil diese Listen, mit der Möglichkeit IPs temporär in solche einzutragen, zu gestalten.
% !TODO
% Ziel
% - 25Gbps = $\frac{25*10^9 \frac{bit}{sec}}{(64 +20,2)*8 bit}$ = 37.1 Mpps
% - pro Paket $2.7^{-8}$ Sekunden Verarbeitungszeit
\section{Grundlegender Aufbau der Software} \label{section:basic_structure}
Das Grundprinzip der zu entwickelten Software soll sein, Pakete auf einem Port der Netzwerkkarte zu empfangen und diese zu einem anderen Port weiterzuleiten. Zwischen diesen beiden Schritten werden die Pakete untersucht, Daten aus diesen extrahiert und ausgewertet. Im weiteren Verlauf des Programms werden Pakete, welche einem Angriff zugeordnet werden verworfen, und legtime Pakete zwischen dem interen und externen Netz ausgetauscht. Es bietet sich an, hier ein Pipelinemodell zu verwenden wobei die einzelnen Softwarekomponenten in Pakete aufgeteilt werden. Im ConfigurationManagement werden die initialen Konfigurationen vorgenommen. Das NicManagement ist eine Abstraktion der Netzwerkkarte und sorgt für das Empfangen und Senden eines von Paketen. Die PacketDissection extrahiert Daten von eingehenden Paketen. Die Inspection analysiert diese Daten und bestimmt, welche Pakete verworfen werden sollen. Das Treatment behandelt die Pakete nach entsprechenden Protokollen. Um die Abarbeitung dieser Pipeline möglichst effizient zu gestalten soll diese jeweils von mehreren Threads parallel und möglichst unabhängig voneinander durchschritten werden.
In den folgenden Sektionen wird näher auf den Kontrollfluss innerhalb des Programms, auf den Einsatz von parallelen Threads und auf die einzelnen Pakete näher eingegangen.
\subsection{Kontrollfluss eines Paketes}
\begin{figure}[H]
\centering
\includegraphics[angle=270, width=0.8\linewidth]{activity_control_flow.pdf}
\caption{Schematische Darstellung des Kontrollflusses}
\label{fig:control_flow}
\end{figure}
In diesem Abschnitt soll veranschaulicht werden, wie die Behandlung eines Paketes vom NicManagement bis zum Treatment erfolgt. Dabei werden die Pakete selbst als Akteure angesehen und noch nicht deren Klassen. Hinweis: Ein Thread soll später mehrere Pakete auf einmal durch die Pipeline führen. In diesem Diagramm wird zur Übersichtlichkeit jedoch nur der Fluss eines Paketes gezeigt. Dieser lässt sich dann einfach auf eine größere Menge von Paketen anwenden. Ein Aktivitätsdiagramm ist unter Abbildung \ref{fig:control_flow} am Ende der Sektion \ref{section:basic_structure} zu finden. Die Aktion ,,Paket nach TCP behandeln'' ist auf Abbildung \ref{fig:tcp_treatment_rough} genauer veranschaulicht.
\subsection{Einsatz von parallelen Threads}
Zunächst ist jedoch ein wichtiger Aspekt der Architektur hervorzuheben. Von der Mitigation-Box wird gefordert, eine hohe Paket- und Datenlast verarbeiten zu können. Das Hardwaresystem, auf welchem das zu entwickelnde Programm laufen wird, besitzt eine Multicore-CPU, d.h. das System ist in der Lage, Aufgaben aus unterschiedlichen Threads parallel zu bearbeiten. Dies hat das Potential, die Rechengeschwindigkeit zu vervielfachen und so die Bearbeitungszeit für jedes Paket zu verringern.
Dabei stellt sich die Frage, was die Threads im Programm genau tun. Es wäre zum Beispiel möglich, dass jeder Thread eine Aufgabe übernimmt, d.h. es gäbe einen Thread, der nur Daten analysiert oder einen Thread, der nur Paketinformationen extrahiert. Eine solche Aufteilung würde allerdings zu einem hohen Grad an Inter-Thread-Kommunikation führen. Diese ist nicht trivial und kann einen Großteil der verfügbaren Ressourcen benötigen, was den durch die Parallelisierung erzielten Gewinn wieder zunichte machen könnte. Um dieses Risiko zu vermeiden soll stattdessen jeder Thread die gesamte Pipeline durchlaufen. So ist kaum Inter-Thread-Kommunikation notwendig. Außerdem ist es dann verhältnismäßig einfach, den Entwurf skalierbar zu gestalten: Wenn ein Prozessor mit größerer Anzahl an Kernen verwendet werden würde, könnten mehr Pakete parallel bearbeitet werden ohne dass die Architektur geändert werden muss.
\subsubsection{Verwendung von Receive-Side-Scaling}
Ein weiterer grundlegender Vorteil ergibt sich durch das von der Netzwerkkarte und von DPDK unterstützte Receive Side Scaling (RSS), siehe Abbildung \ref{fig:Receive-Side-Scaling}: Ein auf einem Port eingehendes Paket wird einer von mehreren sogenannten RX-Queues zugeordnet. Eine RX-Queue gehört immer zu genau einem Netzwerkkartenport, ein Port kann mehrere RX-Queues besitzen. Kommen mehrere Pakete bei der Netzwerkkarte an, so ist die Zuordnung von Paketen eines Ports zu seinen RX-Queues gleich verteilt - alle RX-Queues sind gleich stark ausgelastet. Diese Zuordnung wird durch eine Hashfunktion umgesetzt, in die Source und Destination Port-Nummer und IP-Adresse einfließen. Das führt dazu, dass Pakete, die auf einem Port ankommen und einer bestimmten Verbindung zugehören immer wieder zu der selben RX-Queue dieses Ports zugeordnet werden.
Ferner besteht die Möglichkeit, Symmetric RSS einzusetzen. Dieser Mechanismus sorgt dafür, dass die Pakete, die auf dem einen Port der Netzwerkkarte ankommen nach genau dem selben Prinzip auf dessen RX-Queues aufgeteilt werden, wie die auf dem anderen Port ankommenden Pakete auf dessen RX-Queues. So ergeben sich Paare von RX-Queues, die jeweils immer Pakete von den gleichen Verbindungen beinhalten. Angenommen, die RX-Queues sind mit natürlichen Zahlen benannt und RX-Queue 3 auf Port 0 und RX-Queue 5 auf Port 1 sind ein korrespondierendes RX-Queue-Paar. Wenn nun ein Paket P, zugehörig einer Verbindung V auf RX-Queue 3, Port 0 ankommt, dann weiß man, dass Pakete, die auf Port 1 ankommen und der Verbindung V angehören immer auf RX-Queue 5, Port 1 landen.
Neben RX-Queues existieren auch TX-Queues (Tranceive-Queues), die ebenfalls zu einem bestimmten Port gehören. Darin befindliche Pakete werden von der Netzwerkkarte auf den entsprechenden Port geleitet und gesendet.
Auf Basis dieses Mechanismus sollen die Threads wie folgt organisiert werden: Einem Thread gehört ein Paar von korrespondierenden RX-Queues (auf verschiedenen Ports) und daneben eine TX-Queue auf dem einen und eine TX-Queue auf dem anderen Port. Das bringt einige Vorteile mit sich: Es müssen zwei Arten von Informationen entlang der Pipeline gespeichert, verarbeitet und gelesen werden: Informationen zu einer Verbindung und Analyseinformationen/Statistiken. Daher ist kaum Inter-Thread-Kommunikation nötig, weil alle Informationen zu einer Verbindung in Datenstrukturen gespeichert werden können, auf die nur genau der bearbeitende Thread Zugriff haben muss. Bei Analyseinformationen ist das leider nicht der Fall. Diese müssen zumindest teilweise global gespeichert werden. Hier bietet es sich an, einen Thread für das Management dieser globalen Informationen zu verwenden, der dann mit den restlichen Threads kommuniziert. So müssen zumindest nur mehrere Threads mit genau einem Thread Informationen austauschen und nicht alle Threads untereinander.
Im Falle eines Angriffes ist die Seite des Angreifers (entsprechender Port z.B. ,,Port 0'') viel stärker belastet, als die Seite des Servers (z.B. ,,Port 1''). Wegen der gleich verteilten Zuordnung des eingehenden Traffics auf die RX-Queues und weil ein Thread von RX-Queues von beiden Ports regelmäßig Pakete pollt, sind alle Threads gleichmäßig ausgelastet und können die Pakete bearbeiten. Ein günstiger Nebeneffekt bei DDOS-Angriffen ist, dass die Absenderadressen von Angriffspaketen oft sehr unterschiedlich sind. Das begünstigt die gleichmäßige Verteilung von Paketen auf RX-Queues.
\begin{figure}[t]
\centering
\includegraphics[width=0.95\linewidth]{Receive-Side-Scaling.png}
\caption{Beispielhafte Paketverarbeitung mit Receive Side Scaling}
\label{fig:Receive-Side-Scaling}
\end{figure}
\subsection{Paketdiagramm}
\begin{figure}[t]
\centering
\includegraphics[width=0.7\linewidth]{DoS_Paketdiagramm}
\caption{Paketdiagramm}
\label{fig:dospaketdiagramm}
\end{figure}
Grundsätzlich ist es angedacht, wie im Paketdiagramm \ref{fig:dospaketdiagramm} ersichtlich, die zu entwickelnde Software in insgesamt 5 Teile zu untergliedern.
Das NicManagement wird eingesetzt, um die Kommunikation und Verwaltung der Netzwerkkarten und Ports zu ermöglichen, hier finden Operationen wie der Versand und Empfang von Paketen statt. Verwendet wird das NicManagement von der PacketDissection, welche ihrerseits dazu zuständig ist, die für die Erkennung und Klassifizierung von Angriffen benötigten, Informationen aus den einzelnen Headern eines Netzwerkpakets zu extrahieren. Die hieraus gewonnenen Informationen werden von der Inspection verwendet um sowohl Angriffe erkennen zu können, als auch über den allgemeinen Zustand des Systems in Form von Statistiken Auskunft zu geben. Das Treatment, welches sich um die Abwehrwehrmaßnahmen der verschiedenen Angriffe kümmert, verwendet hierzu die durch die Inspection bereitgestellten Ergebnisse und Informationen. Für das Versenden und Verwerfen von Pakten, sowie den Aufbau und das Terminieren von Verbindungen, verwendet das Treatment wiederum das NicManagement. Sowohl Treatment, als auch Inspection sowie PacketDissection verwenden den ConfigurationManagement, welches nicht nur die Aufgaben des Programmstarts übernimmt und für die Initialisierung sorgt, sondern auch wichtige Paramter für andere Programmbestandteile in Form von Konfigurationsdateien vorhält und einpflegt. Zudem ist das ConfigurationManagement die einzige Möglichkeit für den Nutzer, um aktiv Einstellungen am System vorzunehmen.
\subsection{Klassendiagramm}
Das Klassendiagramm untergliedert sich grundlegend in die selben Bestandteile wie das Paketdiagramm, siehe Bild \ref{fig:dospaketdiagramm}.
\subsubsection{NicManagement}
\begin{figure} [t]
\centering
\includegraphics[width=0.6\linewidth]{package_NicManagement}
\caption{Klasse NetworkPacketHandler im Package NicManagement}
\label{fig:NetworkPacketHandler}
\end{figure}
Das NicManagement, siehe Abbildung \ref{fig:NetworkPacketHandler}, ist eine Abstraktion der Netzwerkkarte. Hier werden die Pakete von dem Interface gepollt und in den Speicher geschrieben. Um später mit diesen Paketen in anderen Paketen weiterarbeiten zu können, übergibt das NicManagement Pointer auf die Speicherbereiche, in denen sich die Pakete befinden. Der NetworkPacketHandler verwendet einen packet\_store rte-ring zum Abspeichern der empfangenen und zu versendenden Pakete.
Als Funktionalitäten stellt der NetworkPacketHandler sowohl send\_packets(pkt\_info\_arr:PacketInfo*[]) mit Rückgabetyp void, als auch poll\_packets() mit Rückgabetyp rte\_mbuf*[] bereit.
rte\_mbuf*[] in der Methode poll\_packets() steht für ein Array aus Pointern, die jeweils auf ein mbuf-Objekt zeigen. Hier ist nicht relevant, ob dies später auch wirklich als Array implementiert wird. Es soll vielmehr gezeigt werden, dass mehrere mbuf-Pointer auf einmal zurückgegeben werden.
\subsubsection{ConfigurationManagement}
\begin{figure} [t]
\centering
\includegraphics[width=0.5\linewidth]{package_ConfigurationManagement}
\caption{Klasse Initializator im Package ConfigurationManagement}
\label{fig:Initializator}
\end{figure}
Im Paket ConfigurationManagement, Abbildung \ref{fig:Initializator} findet die Initialisierung des Programms, sowie die Verwaltung der Konfigurationsdateien statt.
Als Attribut ist hier ausschließlich eine Konfigurationsdatei config\_file vom Typ conf vorgesehen.
Die Operationen beschränken sich auf configure(config\_file:file), wobei der Nutzer hier die Möglichkeit hat, über die Eingabe einer Konfigurationsdatei einzelne Parameter anzupassen.
\subsubsection{PacketDissection}
\begin{figure} [t]
\centering
\includegraphics[width=0.7\linewidth]{package_PackageDissection}
\caption{Klassen HeaderExtractor und PacketInfo im Package PackageDissection}
\label{fig:HeaderExtractor}
\end{figure}
Die PacketDissection, Abbildung \ref{fig:HeaderExtractor} nimmt Pointer auf Pakete entgegen und extrahiert daraus die für die Erkennung und Behandlung wichtigen Headerinformationen. Weitergegeben werden dann Zeiger auf von der PacketDissection angelegte PacketInfo-Strukturen, genau eine für jedes Paket. Diese Struktur beinhaltet die extrahierten Informationen und den Pointer auf das zugehörige Paket, der vom NicManagement erhalten wurde.
Hierzu werden zwei Klassen verwendet, HeaderExtractor kümmert sich um das Extrahieren der Headerinformationen, PacketInfo wiederum wird als eigener Datentyp verwendet.
Die Klasse HeaderExtractor verwendet vorerst keinerlei Attribute und bietet nur die Methode
extract\_info(pkt\_buffer\_arr: rte\_mbuf*[]): PacketInfo*[] bereit, welche ihrerseits ein Array aus rte\_mbuf Pointern erhält und als Resultat ein Array aus PacketInfo Pointern zurückgibt.
Die Klasse PacketInfo ist als Kapselung mehrerer individueller Informationen aus den Netzwerkpaketen gedacht, hierunter fallen beispielsweise die Ziel-IP oder Paketgröße.
\subsubsection{Inspection}
\begin{figure} [t]
\centering
\includegraphics[width=0.6\linewidth]{package_inspection.pdf}
\caption{Klassen StatisticsGenerator, Analyzer und StatInfo im Package Inspection}
\label{fig:Inspection}
\end{figure}
Die Inspektion, siehe Abbildung \ref{fig:Inspection}, nimmt die bereitgestellten PacketInfo-Strukturen entgegen. Aus den beinhalteten Daten werden Statistiken und Regeln erstellt und ausgewertet. Gegebenenfalls sind manche Regeln dynamisch anzupassen. In der Inspektion wird beurteilt, ob ein Paket legitim ist oder nicht. Ist es nicht legitim, wird es gelöscht. Wenn es nicht gelöscht wird, wird der Pointer auf die entsprechende PacketInfo-Struktur der Treatment-Komponente übergeben. Dieser Pointer ist die einzige Schnittstelle zwischen Inspektion und Treatment.
Weitere Anweisungen, wie mit dem Paket im Treatment verfahren werden soll können über die PacketInfo-Struktur mitgeteilt werden. Diese Möglichkeit wird genutzt, wenn eine TCP-Verbindung zu beiden Seiten abgebaut werden soll. Es wird eine entsprechende Direktive in die PacketInfo-Struktur geschrieben, die von der Treatment-Komponente ausgewertet wird.
Die Klasse Analyzer nutzt einen packet\_info\_buf vom Typ Patchmap zum Speichern der PacketInfo Daten, und enthält einen stat\_generator vom Typ StatisticsGenerator sowie statistics vom Typ StatInfo. Die Operation analyze(pkt\_info\_arr: PacketInfo*[]): PacketInfo*[] ist für die Verwaltung und den Aufruf aller weiterer detect-Methoden zuständig. Die jeweiligen detect-Methoden sollen je eine Angriffsart erkennen, und gegebenenfalls bereits erste, als schädlich erkannte Pakete mittels der drop\_packet-Methode verwerfen.
Die Klasse StatisticsGenerator ist für die Generierung von Statistiken zuständig, hierzu verwendet es einen packet\_info\_buf des Typs Patchmap, sowie eine Variable observed\_time, welche die bisher verstrichene Zeit speichert.
Die Operation generate\_statistic() wird dafür eingesetzt, Statistiken für die Analyse durch den Analyzer zu erstellen, sowie informative Daten für den Administrator zu erheben.
generate\_plot() erzeugt aus den ausgewerteten Daten anschauliche Diagramme, welche dem Administrator des Systems einen grundsätzlichen Überblick über den Zustand des Systems gewährt.
dump\_statistics() speichert die angefertigten Statistiken dann persistent auf dem System.
Die Klasse StatInfo dient als Speicherkonstrukt für die erhobenen Daten, welche beim Erzeugen und Auswerten einer Statistik anfallen.
Das Paket Inspection könnte, wenn nötig, außerdem eine Tabelle zu jeder Verbindung beinhalten (ähnlich der im TCP-Treatment). Aber es soll auf keinen Fall dieselbe Tabelle wie im TCP-Treatment genutzt werden, um die UML-Pakete zu kapseln.
\subsection{Treatment}
\begin{figure} [t]
\centering
\includegraphics[width=0.6\linewidth]{package_Treatment}
\caption{Klassen StatisticsGenerator, Analyzer und StatInfo im Package Inspection}
\label{fig:Treatment}
\end{figure}
Das Paket Treatment, siehe Abbildung \ref{fig:Treatment}, hat zur Aufgabe, die zum Schutz der Server benötigten Operationen auszuführen. Hierbei werden zwei Klassen genutzt, wovon sich eine rein um die Behandlung von TCP-Paketen, eine andere nur um die Behandlung von UDP-Paketen vornimmt.
Das Treatment nimmt PacketInfo-Struktur-Pointer entgegen und behandelt das Paket nach dem entsprechende Transportprotokoll.
Die Klasse TcpTreatment nutzt als Attribute eine tcp\_connection\_table vom Typ Hashmap, welche alle Informationen zu den einzelnen Verbindungen enthält, ein load\_rate\_limit des Typs double, sowie einen timeout\_value des Typs double.
Die Operation manage\_syn\_cookies() mit Rückgabetyp void erledigt jede, zur Verwaltung der SYN-Cookies benötigte, Aufgabe, wie das Berechnen des Hashwertes oder das Eintragen dieses in den Paketheader.
manage\_server\_connection() übernimmt alle Aufgaben, welche sich mit der Verwaltung der Verbindungen zu internen Servern befassen. Diese Methode wiederum verwendet die Methode do\_seq\_num\_mapping(), um die Verbindungen von externen Servern zur Middlebox, sowie die Verbindungen von internen Servern zur Middlebox zusammenzuführen.
Die Funktionen limit\_rate() und manage\_timeout() werden verwendet, um Angriffen wie TCP-Zero- und Small-Window-Angriffen entgegenzuwirken.
Die Klasse UdpTreatment hat einen packet\_buf des Typs rte\_ring, ein rate\_limit des Typs double, sowie ein udp\_state\_file des Typs hash\_dictionary als Attribute.
Als Funktionen stehen hier manage\_udp\_state zur Verfügung, welches aus dem eigentlich stateless UDP-Protokoll einen State zuweist. Des weiteren ist auch hier die Funktion limit\_rate() sowie manage\_timeout() verfügbar.
\section{Sequenzdiagramme}
In folgendem Abschnitt finden sich Sequenzdiagramme, welche den genauen Ablauf der Behandlung verdeutlichen sollen.
\subsection{SYN-FIN-ACK}
Abbildung \ref{fig:seqsynfinack} beschreibt den Ablauf der Erkennung und Behandlung eines SYN-FIN Angriffs. Zuerst erhält der Analyzer die Paketinformationen und überprüft diese auf Vorhandensein der Flagkombination, welche zur Detektion benötigt wird. Ist ein Paket als schädlich erkannt, so wird es bereits hier verworfen.
\begin{figure}[t]
\centering
\includegraphics[width=0.5\linewidth]{Sequence_SYN-FIN-ACK}
\caption{Sequenzdiagramm der SYN-FIN-ACK-Abwehr}
\label{fig:seqsynfinack}
\end{figure}
\subsection{SYN-Flood}
Abbildung \ref{fig:sequencesyn-flood} beschreibt den Ablauf der Erkennung und Behandlung einer SYN-Flut. Zuerst erhält der Analyzer die Paketinformationen in Form eines rte\_ring Pointers. Die Funktion detect\_syn\_level() verwendet die dann vom StatisticsGenerator angeforderten StatInfos um das Level eines SYN-Angriffs zu informativen Zwecken zu berechnen. Es folgt die Übergabe der Packetinfos an das TCP-Treatment, welches seinerseits parallel das Management der SYN-Cookies sowie der internen Serververbindung vornimmt. Das Management der internen Serververbindungen selbst verwendet die Funktion do\_seq\_num\_mapping() um die Verbindungen zueinander führen zu können.
\begin{figure}[t]
\centering
\includegraphics[width=0.95\linewidth]{Sequence_SYN-Flood}
\caption{Sequenzdiagramm der SYN-Flood-Abwehr}
\label{fig:sequencesyn-flood}
\end{figure}
\subsection{Small Windows}
Das Diagramm \ref{fig:sequence-smallwin} zeigt, wie das System Zero-Window- und Small-Window-Angriffe erkennt. Zunächst werden für eine Menge an Paketen die Methoden ,,detect\_zero\_window()'' und ,,detect\_small\_window()'' aufgerufen. Wenn ein Angriff erkannt wird, werden die entsprechenden Pakete verworfen. Danach werden alle gültigen Pakete zur normalen Weiterbehandlung and das Treatment weitergegeben.
\begin{figure}[t]
\centering
\includegraphics[width=0.8\textwidth]{zero-window__small-window_sequence_diagram.png}
\caption{Sequenzdiagramm der Small-Window Abwehr}
\label{fig:sequence-smallwin}
\end{figure}
\subsection{UDP Flood}
Bei der Abwehr eines UDP-Flood-Angriffes muss der Angriff zunächst erkannt werden, zu sehen in Abbildung \ref{fig:UDP-Flood-Erkennung}. Dies geschieht über die Methode ,,detect\_udp\_flood()''. Wird eine UDP-Flood erkannt, verwirft das Analyzer-Objekt das Paket, ansonsten wird dieses einem UdpTreatent-Objekt übergeben und gesendet.
\begin{figure}[t]
\centering
\includegraphics[width=0.7\linewidth]{sequence_udp_flood.pdf}
\caption{Sequenzdiagramm der UDP-Flood-Erkennung}
\label{fig:UDP-Flood-Erkennung}
\end{figure}
\end{document}
\section{Aktivitätsdiagramme}
\subsection{Behandlung eines Paketes nach TCP} \label{section:tcp_treat}
Unter Abbildung \ref{fig:tcp_treatment_rough} ist der Ablauf der Aktivität ,,Paket nach TCP behandeln'' zu finden. Die Idee hierbei ist, dass ein Paket-Pointer zusammen mit Informationen über das Paket, die sowohl aus dem Header extrahiert als auch von der Inspektion hinzugefügt wurden dem TcpTreatment übergeben wird. Das Paket wird dann anhand verschiedener Kriterien kategorisiert (SYN-Paket, ACK-Paket, FIN-Paket...) und infolgedessen entsprechend behandelt. Hier wird auch der SYN-Cookie-Mechanismus umgesetzt, welcher vor SYN-Flood-Attacken schützen soll.
Im Diagramm wird folgender Aufbau angenommen: A ist der Initiator eines Verbindungsauf- oder abbaus, B ist derjenige, der auf die Anfrage reagiert. M ist die Mitigation Box. Bei Verbindungsauf- und abbau ist also derjenige, der das erste SYN- bzw. FIN-Paket geschickt hat ,,A''. Der andere Kommunikationsteilnehmer ist demzufolge ,,B''. Hierbei wird nicht nach Angreifer und nicht-Angreifer unterschieden, es geht nur um die Kommunikation über TCP. Wenn bei einer Aktion ,,A<-M'' steht, bedeutet das, dass das die erwähnte Nachricht von M nach A geschickt wird. Wenn bei einem Pin (A->M) steht, bedeutet das, dass das entsprechende Paket von A gekommen ist.
Mit \textbf{,,initiales ACK''} ist das dritte Paket eines 3-Way-Handshakes gemeint, also das erste, das beim Verbindungsaufbau Nutzdaten enthält. \textbf{,,SN''} ist eine Abkürzung für ,,Sequenznummer''. \textbf{,,V-Tabelle''} steht für ,,Verbindungstabelle'', in einem Tupel stehen alle Daten zu genau einer Verbindung; zum Beispiel die Differenz der Sequenznummern von A und B für die Sequenznummerzuordnung. Das Wort ,,V-Tabelle'' ist nicht allgemein und ist nur eine Abkürzung. Im weiteren Entwurf soll diese Tabelle bzw. die entsprechende Datenstruktur einen passenden englischen Namen erhalten.
Um bestimmte Mechanismen auseinanderzuhalten werden zusammengehörige Aktionen farblich gekennzeichnet. \textbf{Grün} repräsentiert das Sequenznummermapping, \textbf{Hellgrün} das Zwischenspeichern und senden der Nutzdaten aus dem initialen ACK-Paket und \textbf{Cyan} das SYN-Cookie-Management.
\begin{figure}[t]
\centering
\includegraphics[angle=270, width=0.8\linewidth]{activity_tcp_treatment.pdf}
\caption{Paketbehandlung nach TCP}
\label{fig:tcp_treatment_rough}
\end{figure}

27
doc/review_1/chapters/9-technologien.tex Normal file
View File

@ -0,0 +1,27 @@
\documentclass[../review_1.tex]{subfiles}
\graphicspath{{\subfix{../img/}}}
\begin{document}
\chapter{Technologien und Entwicklungswerkzeuge}\thispagestyle{fancy}
\section{Hardware}
Die Software hat eine Mindestanforderung an ihre zu verwendende Hardware, hierzu gehört, dass eine sehr gute CPU vorliegt, wie z.B. ein Ryzen 9 5900X. Des weiteren wird ein genügend großer Arbeitsspeicher benötigt, dass heißt ab einer Speicherkapazität von 32GB un mehr, und genügend viel Speicherplatz, dass heißt ab 200GB aufwärts. Um das System gut einsetzen zu können müssen auch genügend schnelle Netzwerkkarten vorliegen (z.B. 25GbE), welche DPDK unterstützten.
\section{Programmiersprache und Bibliotheken}
Die für die Software verwendete Programmiersprache ist C++ auf der Version 17 und wird auf dem Betriebssystem Ubuntu entwickelt. Als Programmiereditor und IDE wird VSCodium verwendet, welches eine Community betriebene, frei lizenzierte Distribution der Microsoft IDE VSCode ist. Zur Unterstützung der Entwicklung werden zusätzliche Erweiterungspakete für VSCodium verwendet, unter anderem Meson (1.3.0) und das C/C++ Extension Pack (1.0.0).
Es wurde die Programmiersprache C++ gewählt, da die Mitglieder dieses Projektes innerhalb ihres Studiums schon Erfahrungen mit dieser Sprache gewonnen haben, sei es in Form von Praktika oder aus eigenen Bedürfnissen.
Ein Hauptbestandteil des Projektes ist die Verwendung des \textit{Data Plane Development Kit} (kurz \textit{DPDK}), auf der LTS-Version 20.11, das aus Bibliotheken zur Beschleunigung von Paket-verarbeitungs-Workload besteht, die auf einer Vielzahl von CPU-Architekturen laufen. Es ermöglicht die Entwicklung von Hochgeschwindigkeits-Datenpaket-Netzwerkanwendungen durch Kernel Bypässe. Mit einer Reihe von Bibliotheken ist es möglich Netzwerkschnittstellen-Controller-Treiber für den Polling-Modus zu verwenden, um die Paketverarbeitung statt im Betriebssystem-Kernel auf Anwendungen im Userspace zu ermöglichen. Durch den Einsatz von DPDK kann ein höherer Paketdurchsatz erreicht werden, als mit der Linux Nativen interruptgesteuerten Verarbeitung im Kernel. Dies ist für dieses Projekt wichtig, da hohe Übertragungsraten erreicht werden sollen.
\begin{figure}[H]
\centering
\includegraphics[width=0.7\linewidth]{mit-ohne-DPDK}
\caption{Kernel Bypass mit DPDK gegenüber Kernel Verarbeitung}
\label{fig:with_without_dpdk}
\end{figure}
\section{Entwicklungswerkzeuge}
Das Buildsystem wird mit Meson erstellt. Meson ist ein Open-Source-Build-System, das sowohl extrem schnell als auch benutzerfreundlich ist (im Vergleich zu CMake). Meson unterstützt viele Plattformen und nutzt Ninja für extrem schnelle vollständige und inkrementelle Builds ohne Einbußen bei der Korrektheit. Dazu gehören unterschiedliche Funktionen wie Unit-Tests, Code-Coverage-Reporting, vorkompilierte Header und dergleichen.
\section{Tools}
Für die Dokumentation wird Doxygen und Latex verwendet und für die Visualisierung von Grafiken VisualParadigm und Inkscape.
\end{document}

BIN
doc/review_1/img/DoS_Paketdiagramm.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 26 KiB

BIN
doc/review_1/img/Hugepages - VP Online.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 30 KiB

BIN
doc/review_1/img/Netwerkplan-Versuch.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 140 KiB

BIN
doc/review_1/img/Netzwerkplan-Real-Botnet.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 189 KiB

BIN
doc/review_1/img/Netzwerkplan-Real.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 191 KiB

BIN
doc/review_1/img/Netzwerkplan.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 100 KiB

BIN
doc/review_1/img/Receive-Side-Scaling.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 50 KiB

BIN
doc/review_1/img/SYN-FIN.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 108 KiB

BIN
doc/review_1/img/SYN-Flood-Abwehr.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 468 KiB

BIN
doc/review_1/img/SYN-Flood.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 222 KiB

BIN
doc/review_1/img/Security Layers - VP Online.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 83 KiB

BIN
doc/review_1/img/Sequence_SYN-FIN-ACK.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 52 KiB

BIN
doc/review_1/img/Sequence_SYN-Flood.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 91 KiB

BIN
doc/review_1/img/Small-Window.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 150 KiB

BIN
doc/review_1/img/UDP-Flood.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 277 KiB

BIN
doc/review_1/img/UnifiedProcess.pdf Normal file
View File

Binary file not shown.

BIN
doc/review_1/img/Werte.pdf Normal file
View File

Binary file not shown.

BIN
doc/review_1/img/Zero-Window.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 113 KiB

BIN
doc/review_1/img/activity_control_flow.pdf Normal file
View File

Binary file not shown.

BIN
doc/review_1/img/activity_tcp_treatment.pdf Normal file
View File

Binary file not shown.

BIN
doc/review_1/img/aegis_logo.pdf Normal file
View File

Binary file not shown.

267
doc/review_1/img/aegis_logo.svg Normal file
View File

@ -0,0 +1,267 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
xmlns:osb="http://www.openswatchbook.org/uri/2009/osb"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="210mm"
height="297mm"
viewBox="0 0 210 297"
version="1.1"
id="svg8"
inkscape:version="1.0.2 (e86c8708, 2021-01-15)"
sodipodi:docname="aegis_logo.svg">
<defs
id="defs2">
<inkscape:path-effect
effect="spiro"
id="path-effect1617"
is_visible="true"
lpeversion="1" />
<inkscape:path-effect
effect="bspline"
id="path-effect1615"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect1613"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect1026"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect1022"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect1018"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect1014"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="spiro"
id="path-effect967"
is_visible="true"
lpeversion="1" />
<inkscape:path-effect
effect="bspline"
id="path-effect951"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect947"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<linearGradient
id="linearGradient910"
osb:paint="solid">
<stop
style="stop-color:#39bd12;stop-opacity:1;"
offset="0"
id="stop908" />
</linearGradient>
<linearGradient
id="linearGradient904"
osb:paint="solid">
<stop
style="stop-color:#ffffff;stop-opacity:1;"
offset="0"
id="stop902" />
</linearGradient>
<linearGradient
id="linearGradient858"
osb:paint="solid">
<stop
style="stop-color:#000000;stop-opacity:1;"
offset="0"
id="stop856" />
</linearGradient>
<linearGradient
id="linearGradient852"
osb:paint="solid">
<stop
style="stop-color:#ff0000;stop-opacity:1;"
offset="0"
id="stop850" />
</linearGradient>
<linearGradient
inkscape:collect="always"
xlink:href="#linearGradient910"
id="linearGradient912"
x1="4.6835933"
y1="144.22475"
x2="204.94859"
y2="144.22475"
gradientUnits="userSpaceOnUse"
gradientTransform="translate(0.45862088,-7.389106)" />
</defs>
<sodipodi:namedview
id="base"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="1.037524"
inkscape:cx="55.03207"
inkscape:cy="424.28106"
inkscape:document-units="mm"
inkscape:current-layer="layer1"
inkscape:document-rotation="0"
showgrid="false"
inkscape:snap-center="true"
inkscape:window-width="1438"
inkscape:window-height="787"
inkscape:window-x="0"
inkscape:window-y="25"
inkscape:window-maximized="0"
showguides="true"
inkscape:guide-bbox="true">
<sodipodi:guide
position="-26.314547,302.84769"
orientation="0,-1"
id="guide867" />
</sodipodi:namedview>
<metadata
id="metadata5">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title></dc:title>
</cc:Work>
</rdf:RDF>
</metadata>
<g
inkscape:groupmode="layer"
id="layer3"
inkscape:label="Layer 3" />
<g
inkscape:groupmode="layer"
id="layer2"
inkscape:label="Layer 2" />
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1">
<circle
style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient912);stroke-width:5;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
id="path12"
cx="105.27471"
cy="136.83565"
r="100" />
<path
style="fill:none;stroke:#ffffff;stroke-width:6.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 202.46225,163.81581 c 4.30755,-16.83969 4.26177,-34.7736 -0.13171,-51.59107 -4.39348,-16.81748 -13.12517,-32.482238 -25.11875,-45.063344 -3.85478,-4.043612 -8.03902,-7.773061 -12.49761,-11.139229"
id="path965"
inkscape:path-effect="#path-effect1617"
inkscape:original-d="M 202.46225,163.81581 C 194.04569,131.59795 185.62888,99.379814 177.21179,67.161396 168.79471,34.942975 168.88031,59.735522 164.71418,56.022167" />
<path
style="fill:none;stroke:#ffffff;stroke-width:0.765;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 200.75748,174.10079 3.08422,-9.72267 -1.53064,-0.33198 z"
id="path1028" />
<path
style="fill:none;stroke:#39bd12;stroke-width:5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="M 164.69568,56.017541 H 129.60354 V 204.72938 h 49.74226"
id="path927" />
<path
style="fill:none;stroke:#39bd12;stroke-width:5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="M 129.22135,54.909272 34.751991,208.06048"
id="path929" />
<path
style="fill:none;stroke:#39bd00;stroke-width:5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="M 198.42648,172.31053 H 57.127381"
id="path931" />
<path
style="fill:none;stroke:#39bd12;stroke-width:5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 24.595171,77.861154 c -3.108584,19.990233 -6.217072,39.979846 7.221192,49.777996 13.438265,9.79815 43.421906,9.40427 74.507727,9.46675 31.08582,0.0625 63.2713,0.58127 78.8053,6.52557 15.53399,5.9443 14.41494,17.3134 13.29588,28.68249"
id="path949"
inkscape:path-effect="#path-effect1613"
inkscape:original-d="m 24.595171,77.861154 c -3.10828,19.99028 -6.21677,39.979896 -9.32565,59.970046 29.98511,-0.39364 59.968752,-0.78751 89.952729,-1.18166 32.18766,0.5191 64.37314,1.03789 96.56026,1.55645 -1.11884,11.36981 -2.23789,22.73891 -3.35724,34.10797"
sodipodi:nodetypes="ccccc" />
<path
style="fill:none;stroke:#39bd12;stroke-width:0.765;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 165.6753,54.120116 -1.33744,4.283193 0.006,-2.537549 z"
id="path986" />
<path
style="fill:none;stroke:#ffffff;stroke-width:0.465;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 200.04382,176.63132 c 0.85764,-4.31295 1.71532,-8.6261 1.63924,-13.31592 -0.0761,-4.68982 -1.08597,-9.7562 -2.09595,-14.82299"
id="path1016"
inkscape:path-effect="#path-effect1615"
inkscape:original-d="m 200.04382,176.63132 c 0.85794,-4.31289 1.71562,-8.62604 2.57304,-12.93947 -1.00967,-5.06631 -2.01957,-10.13269 -3.02975,-15.19944" />
<path
style="fill:none;stroke:#ffffff;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 201.93574,163.62325 v 0.57864"
id="path1032" />
<path
style="fill:none;stroke:#ffffff;stroke-width:0.765;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 203.01483,164.53031 -1.14165,4.72298"
id="path1034" />
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 9.4 KiB

BIN
doc/review_1/img/aegis_logo_neu.pdf Normal file
View File

Binary file not shown.

313
doc/review_1/img/aegis_logo_neu.svg Normal file
View File

@ -0,0 +1,313 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
xmlns:osb="http://www.openswatchbook.org/uri/2009/osb"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="210mm"
height="297mm"
viewBox="0 0 210 297"
version="1.1"
id="svg8"
inkscape:version="1.0.2 (e86c8708, 2021-01-15)"
sodipodi:docname="logo_neu.svg">
<defs
id="defs2">
<inkscape:path-effect
effect="bspline"
id="path-effect910"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect906"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect902"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect898"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect894"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect890"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="spiro"
id="path-effect873"
is_visible="true"
lpeversion="1" />
<inkscape:path-effect
effect="spiro"
id="path-effect1617"
is_visible="true"
lpeversion="1" />
<inkscape:path-effect
effect="bspline"
id="path-effect1615"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect1613"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect1026"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect1022"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect1018"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect1014"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="spiro"
id="path-effect967"
is_visible="true"
lpeversion="1" />
<inkscape:path-effect
effect="bspline"
id="path-effect951"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect947"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<linearGradient
id="linearGradient910"
osb:paint="solid">
<stop
style="stop-color:#39bd12;stop-opacity:1;"
offset="0"
id="stop908" />
</linearGradient>
<linearGradient
id="linearGradient904"
osb:paint="solid">
<stop
style="stop-color:#ffffff;stop-opacity:1;"
offset="0"
id="stop902" />
</linearGradient>
<linearGradient
id="linearGradient858"
osb:paint="solid">
<stop
style="stop-color:#000000;stop-opacity:1;"
offset="0"
id="stop856" />
</linearGradient>
<linearGradient
id="linearGradient852"
osb:paint="solid">
<stop
style="stop-color:#ff0000;stop-opacity:1;"
offset="0"
id="stop850" />
</linearGradient>
</defs>
<sodipodi:namedview
id="base"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="1"
inkscape:cx="513.21351"
inkscape:cy="508.4009"
inkscape:document-units="mm"
inkscape:current-layer="layer1"
inkscape:document-rotation="0"
showgrid="false"
inkscape:snap-center="true"
inkscape:window-width="2188"
inkscape:window-height="1195"
inkscape:window-x="0"
inkscape:window-y="164"
inkscape:window-maximized="0"
showguides="true"
inkscape:guide-bbox="true">
<sodipodi:guide
position="-26.314547,302.84769"
orientation="0,-1"
id="guide867" />
</sodipodi:namedview>
<metadata
id="metadata5">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title />
</cc:Work>
</rdf:RDF>
</metadata>
<g
inkscape:groupmode="layer"
id="layer3"
inkscape:label="Layer 3" />
<g
inkscape:groupmode="layer"
id="layer2"
inkscape:label="Layer 2" />
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1">
<path
style="fill:none;stroke:#39bd12;stroke-width:5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="M 164.31365,56.017541 H 129.60354 V 204.72938 h 49.20074"
id="path927" />
<path
style="fill:none;stroke:#39bd12;stroke-width:5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="M 129.22135,54.909272 34.751991,208.06048"
id="path929" />
<path
style="fill:none;stroke:#39bd00;stroke-width:5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="M 198.42648,172.31053 H 57.127381"
id="path931" />
<path
style="fill:none;stroke:#39bd12;stroke-width:5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 24.595171,77.861154 c -3.108584,19.990233 -6.217072,39.979846 7.221192,49.777996 13.438265,9.79815 43.421906,9.40427 74.507727,9.46675 31.08582,0.0625 63.2713,0.58127 78.8053,6.52557 15.53399,5.9443 14.41494,17.3134 13.29588,28.68249"
id="path949"
inkscape:path-effect="#path-effect1613"
inkscape:original-d="m 24.595171,77.861154 c -3.10828,19.99028 -6.21677,39.979896 -9.32565,59.970046 29.98511,-0.39364 59.968752,-0.78751 89.952729,-1.18166 32.18766,0.5191 64.37314,1.03789 96.56026,1.55645 -1.11884,11.36981 -2.23789,22.73891 -3.35724,34.10797"
sodipodi:nodetypes="ccccc" />
<path
style="fill:none;stroke:#39bd12;stroke-width:0.765;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 165.6753,54.120116 -1.33744,4.283193 0.006,-2.537549 z"
id="path986" />
<path
style="fill:none;stroke:#39bd12;stroke-width:5;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;stroke-miterlimit:4;stroke-dasharray:none"
d="m 198.42648,172.31053 c -10.21056,26.31893 -32.13503,47.8398 -58.63912,57.55964 -26.50408,9.71984 -57.143833,7.47586 -81.948985,-6.00176 C 33.033223,210.3908 14.478152,185.9053 8.2110463,158.37959 1.9439403,130.85387 8.0697706,100.74898 24.595171,77.861154 39.983389,56.548331 64.113294,41.752255 90.08701,37.702592 c 25.97372,-4.049663 53.46264,2.698322 74.60867,18.314948"
id="path871"
inkscape:path-effect="#path-effect873"
inkscape:original-d="M 198.42648,172.31053 C 140.48297,140.82767 82.539204,109.34454 24.595171,77.861154 -33.348863,46.377764 117.99577,63.299008 164.69568,56.01754" />
<path
style="fill:none;stroke:#39bd12;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 200.42393,172.42743 c -0.0114,0.11918 -0.0227,0.2381 -0.0482,0.34849 -0.0255,0.11039 -0.0651,0.21232 -0.10473,0.31412"
id="path900"
inkscape:path-effect="#path-effect902"
inkscape:original-d="m 200.42393,172.42743 c -0.0111,0.1192 -0.0224,0.23813 -0.034,0.35679 -0.0394,0.10221 -0.079,0.20415 -0.11893,0.30582" />
<path
style="fill:none;stroke:#39bd12;stroke-width:0.465;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;stroke-miterlimit:4;stroke-dasharray:none"
d="m 198.42648,172.31053 1.55338,0.37139 -0.24026,0.14416 -1.31312,-0.51555"
id="path912" />
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 10 KiB

BIN
doc/review_1/img/aegis_logo_with_name.pdf Normal file
View File

Binary file not shown.

253
doc/review_1/img/aegis_logo_with_name.svg Normal file
View File

@ -0,0 +1,253 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
xmlns:osb="http://www.openswatchbook.org/uri/2009/osb"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="420mm"
height="297mm"
viewBox="0 0 420 297"
version="1.1"
id="svg8"
inkscape:version="1.0.2 (e86c8708, 2021-01-15)"
sodipodi:docname="aegis_logo_with_name.svg">
<defs
id="defs2">
<rect
x="205.51764"
y="106.16519"
width="206.65309"
height="91.404257"
id="rect871" />
<inkscape:path-effect
effect="bspline"
id="path-effect1026"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect1022"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect1018"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect1014"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="spiro"
id="path-effect967"
is_visible="true"
lpeversion="1" />
<inkscape:path-effect
effect="bspline"
id="path-effect951"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect947"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<linearGradient
id="linearGradient910"
osb:paint="solid">
<stop
style="stop-color:#39bd12;stop-opacity:1;"
offset="0"
id="stop908" />
</linearGradient>
<linearGradient
id="linearGradient904"
osb:paint="solid">
<stop
style="stop-color:#ffffff;stop-opacity:1;"
offset="0"
id="stop902" />
</linearGradient>
<linearGradient
id="linearGradient858"
osb:paint="solid">
<stop
style="stop-color:#000000;stop-opacity:1;"
offset="0"
id="stop856" />
</linearGradient>
<linearGradient
id="linearGradient852"
osb:paint="solid">
<stop
style="stop-color:#ff0000;stop-opacity:1;"
offset="0"
id="stop850" />
</linearGradient>
<linearGradient
inkscape:collect="always"
xlink:href="#linearGradient910"
id="linearGradient912"
x1="4.6835933"
y1="144.22475"
x2="204.94859"
y2="144.22475"
gradientUnits="userSpaceOnUse"
gradientTransform="translate(5.4831073)" />
</defs>
<sodipodi:namedview
id="base"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="0.62281391"
inkscape:cx="731.89833"
inkscape:cy="446.21446"
inkscape:document-units="mm"
inkscape:current-layer="layer1"
inkscape:document-rotation="0"
showgrid="false"
inkscape:snap-center="true"
inkscape:window-width="1438"
inkscape:window-height="787"
inkscape:window-x="0"
inkscape:window-y="25"
inkscape:window-maximized="0">
<inkscape:grid
type="xygrid"
id="grid867" />
</sodipodi:namedview>
<metadata
id="metadata5">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title />
</cc:Work>
</rdf:RDF>
</metadata>
<g
inkscape:groupmode="layer"
id="layer3"
inkscape:label="Layer 3">
<circle
style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient912);stroke-width:5;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
id="path12"
cx="110.2992"
cy="144.22475"
r="100" />
</g>
<g
inkscape:groupmode="layer"
id="layer2"
inkscape:label="Layer 2">
<path
style="fill:none;stroke:#ffffff;stroke-width:6.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 207.48674,171.20492 c 4.30755,-16.83969 4.26177,-34.7736 -0.13171,-51.59108 -4.39348,-16.81747 -13.12517,-32.482232 -25.11875,-45.063338 -3.85478,-4.043612 -8.03902,-7.773061 -12.49761,-11.139229"
id="path965"
inkscape:path-effect="#path-effect967"
inkscape:original-d="M 207.48674,171.20492 C 199.07018,138.98706 190.65337,106.76892 182.23628,74.550502 173.8192,42.332081 173.9048,67.124628 169.73867,63.411273" />
<path
style="fill:none;stroke:#ffffff;stroke-width:0.765;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 205.78197,181.4899 3.08422,-9.72267 -1.53064,-0.33198 z"
id="path1028" />
</g>
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1">
<path
style="fill:none;stroke:#39bd12;stroke-width:5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="M 169.72017,63.406647 H 134.62803 V 212.11849 h 49.74226"
id="path927" />
<path
style="fill:none;stroke:#39bd12;stroke-width:5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="M 134.24584,62.298378 39.776484,215.44959"
id="path929" />
<path
style="fill:none;stroke:#39bd00;stroke-width:5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="M 203.45097,179.69964 H 62.151872"
id="path931" />
<path
style="fill:none;stroke:#39bd12;stroke-width:5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 29.619662,85.25026 c -3.108583,19.99023 -6.217071,39.97985 7.221191,49.778 13.438263,9.79815 43.421905,9.40427 74.507727,9.46675 31.08582,0.0625 63.2713,0.58127 78.8053,6.52557 15.53399,5.9443 14.41494,17.3134 13.29588,28.68249"
id="path949"
inkscape:path-effect="#path-effect951"
inkscape:original-d="m 29.619662,85.25026 c -3.108285,19.99028 -6.216772,39.9799 -9.325649,59.97005 29.985106,-0.39364 59.968749,-0.78751 89.952727,-1.18166 32.18766,0.5191 64.37314,1.03789 96.56026,1.55645 -1.11884,11.36981 -2.23789,22.73891 -3.35724,34.10797"
sodipodi:nodetypes="ccccc" />
<path
style="fill:none;stroke:#39bd12;stroke-width:0.765;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 170.69979,61.509222 -1.33744,4.283193 0.006,-2.537549 z"
id="path986" />
<path
style="fill:none;stroke:#ffffff;stroke-width:0.465;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 205.06831,184.02043 c 0.85764,-4.31295 1.71532,-8.6261 1.63924,-13.31592 -0.0761,-4.68982 -1.08597,-9.7562 -2.09595,-14.82299"
id="path1016"
inkscape:path-effect="#path-effect1018"
inkscape:original-d="m 205.06831,184.02043 c 0.85794,-4.31289 1.71562,-8.62604 2.57304,-12.93947 -1.00967,-5.06631 -2.01957,-10.13269 -3.02975,-15.19944" />
<path
style="fill:none;stroke:#ffffff;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 206.96023,171.01236 V 171.591"
id="path1032" />
<path
style="fill:none;stroke:#ffffff;stroke-width:0.765;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 208.03932,171.91942 -1.14165,4.72298"
id="path1034" />
<text
xml:space="preserve"
id="text869"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:63.50000000000000000px;line-height:1.25;font-family:Futura;-inkscape-font-specification:Futura;white-space:pre;shape-inside:url(#rect871);fill:#39bd12;fill-opacity:1;stroke:none;"
transform="translate(16.892532,-1.4815799)"><tspan
x="205.51758"
y="162.39325"><tspan
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:63.5px;font-family:Futura;-inkscape-font-specification:Futura;fill:#39bd12;fill-opacity:1">AEGIS</tspan></tspan></text>
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 9.4 KiB

BIN
doc/review_1/img/aegis_logo_with_name_neu.pdf Normal file
View File

Binary file not shown.

253
doc/review_1/img/aegis_logo_with_name_neu.svg Normal file
View File

@ -0,0 +1,253 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
xmlns:osb="http://www.openswatchbook.org/uri/2009/osb"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="420mm"
height="297mm"
viewBox="0 0 420 297"
version="1.1"
id="svg8"
inkscape:version="1.0.2 (e86c8708, 2021-01-15)"
sodipodi:docname="aegis_logo_with_name_neu.svg">
<defs
id="defs2">
<rect
x="205.51764"
y="106.16519"
width="206.65309"
height="91.404257"
id="rect871" />
<inkscape:path-effect
effect="bspline"
id="path-effect1026"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect1022"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect1018"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect1014"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="spiro"
id="path-effect967"
is_visible="true"
lpeversion="1" />
<inkscape:path-effect
effect="bspline"
id="path-effect951"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="bspline"
id="path-effect947"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<linearGradient
id="linearGradient910"
osb:paint="solid">
<stop
style="stop-color:#39bd12;stop-opacity:1;"
offset="0"
id="stop908" />
</linearGradient>
<linearGradient
id="linearGradient904"
osb:paint="solid">
<stop
style="stop-color:#ffffff;stop-opacity:1;"
offset="0"
id="stop902" />
</linearGradient>
<linearGradient
id="linearGradient858"
osb:paint="solid">
<stop
style="stop-color:#000000;stop-opacity:1;"
offset="0"
id="stop856" />
</linearGradient>
<linearGradient
id="linearGradient852"
osb:paint="solid">
<stop
style="stop-color:#ff0000;stop-opacity:1;"
offset="0"
id="stop850" />
</linearGradient>
<inkscape:path-effect
effect="bspline"
id="path-effect1613"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
<inkscape:path-effect
effect="spiro"
id="path-effect873"
is_visible="true"
lpeversion="1" />
<inkscape:path-effect
effect="bspline"
id="path-effect902"
is_visible="true"
lpeversion="1"
weight="33.333333"
steps="2"
helper_size="0"
apply_no_weight="true"
apply_with_weight="true"
only_selected="false" />
</defs>
<sodipodi:namedview
id="base"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="0.62281391"
inkscape:cx="735.10956"
inkscape:cy="557.73299"
inkscape:document-units="mm"
inkscape:current-layer="layer1"
inkscape:document-rotation="0"
showgrid="false"
inkscape:snap-center="true"
inkscape:window-width="1789"
inkscape:window-height="977"
inkscape:window-x="0"
inkscape:window-y="25"
inkscape:window-maximized="0">
<inkscape:grid
type="xygrid"
id="grid867" />
</sodipodi:namedview>
<metadata
id="metadata5">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title />
</cc:Work>
</rdf:RDF>
</metadata>
<g
inkscape:groupmode="layer"
id="layer3"
inkscape:label="Layer 3" />
<g
inkscape:groupmode="layer"
id="layer2"
inkscape:label="Layer 2" />
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1">
<path
style="fill:none;stroke:#39bd12;stroke-width:5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="M 173.63256,64.681524 H 138.92245 V 213.39336 h 49.20074"
id="path927" />
<path
style="fill:none;stroke:#39bd12;stroke-width:5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="M 138.54026,63.573258 44.070902,216.72446"
id="path929" />
<path
style="fill:none;stroke:#39bd00;stroke-width:5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="M 207.74539,180.97451 H 66.446292"
id="path931" />
<path
style="fill:none;stroke:#39bd12;stroke-width:5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 33.914082,86.525144 c -3.108584,19.990226 -6.217071,39.979836 7.221193,49.777986 13.438264,9.79815 43.421903,9.40427 74.507725,9.46675 31.08582,0.0625 63.2713,0.58127 78.8053,6.52557 15.53399,5.9443 14.41494,17.3134 13.29588,28.68249"
id="path949"
inkscape:path-effect="#path-effect1613"
inkscape:original-d="m 33.914082,86.525144 c -3.10828,19.990276 -6.21677,39.979886 -9.32565,59.970036 29.98511,-0.39364 59.96875,-0.78751 89.952728,-1.18166 32.18766,0.5191 64.37314,1.03789 96.56026,1.55645 -1.11884,11.36981 -2.23789,22.73891 -3.35724,34.10797"
sodipodi:nodetypes="ccccc" />
<path
style="fill:none;stroke:#39bd12;stroke-width:0.765;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 174.99421,62.784102 -1.33744,4.283192 0.006,-2.53755 z"
id="path986" />
<path
style="fill:none;stroke:#39bd12;stroke-width:5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 207.74539,180.97451 c -10.21056,26.31893 -32.13503,47.83979 -58.63911,57.55964 -26.50408,9.71984 -57.143835,7.47586 -81.948987,-6.00175 C 42.352142,219.05478 23.797071,194.56929 17.529964,167.04358 11.262856,139.51786 17.388684,109.41297 33.914082,86.525144 49.302299,65.21232 73.432203,50.416242 99.405919,46.366578 c 25.973711,-4.049664 53.462641,2.69832 74.608671,18.314946"
id="path871"
inkscape:path-effect="#path-effect873"
inkscape:original-d="M 207.74539,180.97451 C 149.80188,149.49165 91.858112,118.00852 33.914082,86.525144 -24.029951,55.04175 127.31468,71.962994 174.01459,64.681524" />
<path
style="fill:none;stroke:#39bd12;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 209.74284,181.09141 c -0.0114,0.11918 -0.0227,0.2381 -0.0482,0.34849 -0.0255,0.11039 -0.0651,0.21232 -0.10473,0.31412"
id="path900"
inkscape:path-effect="#path-effect902"
inkscape:original-d="m 209.74284,181.09141 c -0.0111,0.1192 -0.0224,0.23813 -0.034,0.35679 -0.0394,0.10221 -0.079,0.20415 -0.11893,0.30582" />
<path
style="fill:none;stroke:#39bd12;stroke-width:0.465;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 207.74539,180.97451 1.55338,0.37139 -0.24026,0.14416 -1.31312,-0.51555"
id="path912" />
<text
xml:space="preserve"
id="text869"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:63.50000000000000000px;line-height:1.25;font-family:Futura;-inkscape-font-specification:Futura;white-space:pre;shape-inside:url(#rect871);fill:#39bd12;fill-opacity:1;stroke:none;"
transform="translate(16.892532,-1.4815799)"><tspan
x="205.51758"
y="162.39325"><tspan
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:63.5px;font-family:Futura;-inkscape-font-specification:Futura;fill:#39bd12;fill-opacity:1">AEGIS</tspan></tspan></text>
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 9.2 KiB

BIN
doc/review_1/img/angriffe - VP Online.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 50 KiB

BIN
doc/review_1/img/gantt_chart_implementierung.pdf Normal file
View File

Binary file not shown.

BIN
doc/review_1/img/gantt_chart_planung_entwurf.pdf Normal file
View File

Binary file not shown.

BIN
doc/review_1/img/gantt_chart_projektvorbereitung.pdf Normal file
View File

Binary file not shown.

BIN
doc/review_1/img/gantt_chart_validierung.pdf Normal file
View File

Binary file not shown.

BIN
doc/review_1/img/kanban.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 144 KiB

BIN
doc/review_1/img/mit-ohne-DPDK.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 42 KiB

BIN
doc/review_1/img/netzplan.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 219 KiB

BIN
doc/review_1/img/package_ConfigurationManagement.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 27 KiB

BIN
doc/review_1/img/package_Inspection.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 105 KiB

BIN
doc/review_1/img/package_NicManagement.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 45 KiB

BIN
doc/review_1/img/package_PackageDissection.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 119 KiB

BIN
doc/review_1/img/package_Treatment.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 116 KiB

BIN
doc/review_1/img/package_conf_mgmt.pdf Normal file
View File

Binary file not shown.

BIN
doc/review_1/img/package_inspection.pdf Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 175 KiB

BIN
doc/review_1/img/package_nic_mgmt.pdf Normal file
View File

Binary file not shown.

BIN
doc/review_1/img/package_packet_dissection.pdf Normal file
View File

Binary file not shown.

BIN
doc/review_1/img/phase1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 98 KiB

BIN
doc/review_1/img/phase2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 344 KiB

BIN
doc/review_1/img/phase3.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 192 KiB

BIN
doc/review_1/img/phase4.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 214 KiB

BIN
doc/review_1/img/projektstrukturplan.pdf Normal file
View File

Binary file not shown.

BIN
doc/review_1/img/projektstrukturplan.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 313 KiB

BIN
doc/review_1/img/risikomatrix.pdf Normal file
View File

Binary file not shown.

BIN
doc/review_1/img/risikomatrix.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 103 KiB

BIN
doc/review_1/img/sequence_udp_flood.pdf Normal file
View File

Binary file not shown.

BIN
doc/review_1/img/tu_ilmenau_logo.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 36 KiB

BIN
doc/review_1/img/unifiedprocess.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 160 KiB

BIN
doc/review_1/img/use_case_diagram_1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 175 KiB

BIN
doc/review_1/img/use_case_diagram_2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 179 KiB

BIN
doc/review_1/img/usecase1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 171 KiB

BIN
doc/review_1/img/usecase2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 175 KiB

BIN
doc/review_1/img/werte.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 125 KiB

BIN
doc/review_1/img/zero-window__small-window_sequence_diagram.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 79 KiB

139
doc/review_1/references.bib Normal file
View File

@ -0,0 +1,139 @@
% Encoding: UTF-8
@Comment{jabref-meta: databaseType:bibtex;}
@misc{aws_shield,
AUTHOR = {Amazon },
TITLE = {AWS Shield},
NOTE = {Aufgerufen 23.05.2021},
HOWPUBLISHED = {Website},
URL = {{https://aws.amazon.com/de/shield/}},
YEAR = {2021}
}
@online{blog-selectel,
AUTHOR = {Andrej Yemelianov},
TITLE = {Introduction to DPDK: Architecture and Principles},
NOTE = {Aufgerufen 02.05.2021},
DATE = {2016-11-26},
URL = {{https://blog.selectel.com/introduction-dpdk-architecture-principles/}},
YEAR = {2016}
}
@misc{cloudflare,
AUTHOR = {Cloudflare},
TITLE = {Cloudflare DDoS Protection},
NOTE = {Aufgerufen 23.05.2021},
HOWPUBLISHED = {Website},
URL = {{https://www.cloudflare.com/ddos/}},
YEAR = {2021}
}
@misc{datacenterknowledge_study,
AUTHOR = {datacenterknowledge.com},
TITLE = {Study: Number of Costly DoS-Related Data Center Outages Rising},
NOTE = {Aufgerufen 23.05.2021},
URL = {{https://www.datacenterknowledge.com/archives/2016/05/13/number-of-costly-dos-related-data-center-outages-rising}},
YEAR = {2016}
}
@online{DPDK.org,
AUTHOR = {DPDK Project. LF Projects},
TITLE = {DPDK Webseite},
NOTE = {Aufgerufen 01.05.2021},
URL = {{https://www.dpdk.org/}}
}
@online{github.com/DPDK/dpdk,
AUTHOR = {DPDK Project},
TITLE = {DPDK on Github},
NOTE = {Aufgerufen 01.05.2021},
URL = {{https://github.com/DPDK/dpdk}}
}
@misc{infopoint_security_cyber_angriffe,
AUTHOR = {infopoint-security},
TITLE = {Cyber-Angriffe auf deutsche Krankenhäuser sind um 220 Prozent gestiegen},
NOTE = {Aufgerufen 23.05.2021},
URL = {{https://www.infopoint-security.de/cyber-angriffe-auf-deutsche-krankenhaeuser-sind-um-220-prozent-gestiegen/a26177/}},
YEAR = {2021}
}
@misc{intel_nic_benchmark,
TITLE = {DPDK Intel NIC Performance ReportRelease 20.02},
HOWPUBLISHED = {Website},
URL = {{http://fast.dpdk.org/doc/perf/DPDK_20_02_Intel_NIC_performance_report.pdf}},
NOTE = {Zugriff: 2021-05-17}
}
@misc{mellanox_nic_benchmark,
TITLE = {Mellanox NIC’s Performance Report with DPDK 20.05},
URL = {{https://fast.dpdk.org/doc/perf/DPDK_20_05_Mellanox_NIC_performance_report.pdf}},
HOWPUBLISHED = {Website},
NOTE = {Zugriff: 2021-05-17}
}
@misc{neustar_ddos_report,
AUTHOR = {NEUSTAR},
TITLE = {2016 DDoS Report},
NOTE = {Aufgerufen 23.05.2021},
HOWPUBLISHED = {Website},
URL = {{https://ns-cdn.neustar.biz/creative_services/biz/neustar/www/resources/whitepapers/it-security/ddos/2016-apr-ddos-report.pdf}}
}
@manual{pakkanen_meson_build_system,
AUTHOR = {Jussi Pakkanen},
TITLE = {The Meson Build System},
HOWPUBLISHED = {Website},
URL = {{https://mesonbuild.com/Getting-meson.html}}
}
@misc{Patchmap,
AUTHOR = {Wolfgang Brehm},
TITLE = {Memory Efficient Hash Tables and Pseudorandom Ordering},
DATE = {2020-11-16},
URL = {{https://1ykos.github.io/patchmap/#Publication}}
}
@misc{projectshield,
AUTHOR = {ProjectShield},
TITLE = {ProjectShield Webseite},
NOTE = {Aufgerufen 23.05.2021},
HOWPUBLISHED = {Website},
URL = {{https://projectshield.withgoogle.com/landing}},
YEAR = {2021}
}
@misc{RobinHoodMap,
AUTHOR = {Thibaut Goetghebuer-Planchon},
TITLE = {Benchmark of major hash maps implementations},
DATE = {2020-06-22},
URL = {{https://tessil.github.io/2016/08/29/benchmark-hopscotch-map.html}}
}
@misc{ryzen_benchmarks,
TITLE = {Ryzen Website},
HOWPUBLISHED = {Website},
URL = {{https://www.amd.com/en/products/cpu/amd-ryzen-9-5900x}},
NOTE = {Zugriff: 2021-05-17}
}
@misc{tecchannel_gefahr_botnet,
AUTHOR = {tecchannel},
TITLE = {Trend Micro: Latente Gefahr durch Botnet SDBOT},
NOTE = {Aufgerufen 23.05.2021},
HOWPUBLISHED = {Website},
URL = {{https://www.tecchannel.de/a/trend-micro-latente-gefahr-durch-botnet-sdbot,2024687}},
YEAR = {2009}
}
@misc{testFab,
AUTHOR = {Menghao Zhang et al.},
TITLE = {Mitigating Volumetric DDoS Attacks with programmable Switches},
YEAR = {2000},
HOWPUBLISHED = {Website},
NOTE = {Aufgerufen 11.05.2021},
URL = {{https://www.ndss-symposium.org/wp-content/uploads/2020/02/24007-paper.pdf"}}
}
\endinput
%%
%% End of file `sample.bib'.

BIN
doc/review_1/review_1.pdf Normal file
View File

Binary file not shown.

100
doc/review_1/review_1.tex Normal file
View File

@ -0,0 +1,100 @@
\documentclass[a4paper,10pt, twoside]{report} % Format A4, Schriftgröße 10, zweiseitige Ausrichtung
\usepackage[utf8]{inputenc}
\usepackage[ngerman]{babel} % Sprache: Deutsch nach neuer Rechtschreibung
\usepackage[T1]{fontenc}
\usepackage{lmodern} % andere Schriftart
\usepackage{geometry}
\usepackage{float}
\usepackage{amsmath,amsthm,amsfonts,amssymb} % Mathematik
\usepackage{color,graphicx,overpic}
\usepackage{listings} % Codefragmente
\usepackage{fancyhdr} % Kopf- und Fußzeilen
\usepackage[dvipsnames]{xcolor}
\usepackage{booktabs}
\usepackage[hidelinks,pdfencoding=auto]{hyperref} % Links & Verlinkung
\usepackage{longtable}
\usepackage{cite}
\usepackage[section]{placeins} % Bilder auf der richtigen Seite darstellen
\usepackage{enumitem}
\usepackage{subfiles}
\usepackage{parskip}
\setlength{\headheight}{28.7pt}
\pdfinfo{
/Title (SWP2021 AntiDoS - Entwurfsdokumentation)
/Creator (TeX)
/Producer (pdfTeX 3.14)
/Author (Fabienne Göpfert, Leon Leisten, Felix Husslein, Robert Jeutter, Jakob Lerch, Tim Häußler, Johannes Lang, Tobias Scholz)
/Subject (Abwehr von Denial-of-Service-Angriffen durch effiziente User-Space Paketverarbeitung)
}
%% Kopf- und Fußzeilen
\pagestyle{fancy}
\lhead{\leftmark} %aktuelles Kapitel
\chead{}
\rhead{ \includegraphics[height=25pt]{img/aegis_logo_with_name.pdf}}
\lfoot{SWP2021 AntiDoS - Pflichtenheft}
\cfoot{}
\rfoot{\thepage}
\renewcommand{\headrulewidth}{0.2pt} %fügt eine Linie unter der Kopfzeile ein
\begin{document}
\begin{titlepage} %Beginn der Titelseite
\begin{center} %zentriert
Technische Universität Ilmenau\\
Fakultät Informatik und Automatisierung \\
Fachgebiet Telematik/Rechnernetze\\
%Technische Universität Ilmenau\\
\vspace{2em}
\includegraphics[width=0.35\linewidth]{img/tu_ilmenau_logo.png}\\
%Technische Universität Ilmenau\\
\vspace{2em}
Erste Review zum Thema\\
\vspace{1em}
\Large\textsc{Abwehr von Denial-of-Service-Angriffen \\durch effiziente User-Space Paketverarbeitung}\\
\vspace{0.5em}
\Large\textsc{AEGIS}\\
\includegraphics[width=0.35\linewidth]{img/aegis_logo.pdf}\\
\normalsize
\vspace{2em}
Autoren:\\
\begin{table}[h]
\centering
\begin{tabular}{l r}
Fabienne Göpfert & Tim Häußler \\
Felix Husslein & Robert Jeutter \\
Johannes Lang & Leon Leisten \\
Jakob Lerch & Tobias Scholz \\
\end{tabular}
\end{table}
\vspace{1em}
\normalsize {Betreuer:} Martin Backhaus\\
\vspace{1em}
Entwurf 26.Mai 2021
\end{center}
\end{titlepage}
\pagebreak
\tableofcontents {\protect\thispagestyle{fancy}
\subfile{chapters/1-problemstellung}
\subfile{chapters/2-anforderungen}
\subfile{chapters/3-anforderungsanalyse}
\subfile{chapters/4-aufwandsschaetzung}
\subfile{chapters/5-risikoanalyse}
\subfile{chapters/6-vorgehen}
\subfile{chapters/7-interne-organisation}
\subfile{chapters/8-doku-geplanter-entwurf}
\subfile{chapters/9-technologien}
\subfile{chapters/10-machbarkeitsanalyse}
\subfile{chapters/11-testdrehbuch}
\subfile{chapters/12-abkuerzungsverzeichnis}
\subfile{chapters/13-glossar}
\bibliography{references}
\bibliographystyle{ieeetr}
\listoffigures {\protect\thispagestyle{fancy} % Abbildungsverzeichnis
\end{document}