review 2
This commit is contained in:
parent
f868efe7ea
commit
a1e1544e8a
43
doc/review_2/chapters/1-einleitung.tex
Normal file
43
doc/review_2/chapters/1-einleitung.tex
Normal file
@ -0,0 +1,43 @@
|
||||
\documentclass[../review_2.tex]{subfiles}
|
||||
\graphicspath{{\subfix{../img/}}}
|
||||
\begin{document}
|
||||
|
||||
\chapter{Einleitung}\thispagestyle{fancy}
|
||||
|
||||
\section{Problemstellung}
|
||||
Denial-of-Service-Angriffe stellen eine ernstzunehmende Bedrohung dar.
|
||||
Im digitalen Zeitalter sind viele Systeme über das Internet miteinander verbunden. Viele Unternehmen, Krankenhäuser 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ße Schaden bei deutlich leistungsfähigeren Empfängern auslösen. In Botnetzen können die Angriffe von mehreren Computern gleichzeitig koordiniert werden 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}.
|
||||
|
||||
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.
|
||||
|
||||
\section{Überblick}
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.85\linewidth]{img/projektstrukturplan.pdf}
|
||||
\caption{Projektstrukturplan}
|
||||
\label{projektstrukturplan}
|
||||
\end{figure}
|
||||
|
||||
Das Softwareprojekt wurde vom zuständigen Fachgebiet in drei Teile aufgeteilt. Die Planungs- und Entwicklungsphase, die Implementierungsphase und die Validierungsphase dauern jeweils einen Monat und werden durch ein Review abgeschlossen. Zu diesen Reviews werden die Ergebnisse der vergangenen Phase vorgestellt und die erforderlichen Review-Dokumente abgegeben.
|
||||
|
||||
Zu Beginn des Projekts wurde sich auf den Unified Process als Vorgehensmodell geeinigt, damit sowohl ein gewisser Grad an Flexibilität als auch die Planbarkeit der Ergebnisse gewährleistet werden kann. Prinzipiell besteht dieses Vorgehensmodell aus vier Phasen, von denen die Konzeption und die Ausarbeitung beide in der Planungs- und Entwurfsphase lagen. Die Konstruktionsphase und die Inbetriebnahme decken sich zeitlich mit der Implementierungs- und der Validierungsphase.
|
||||
|
||||
Dieses zweite Review-Dokument bezieht sich auf die Implementierungsphase (bzw. Konstruktionsphase bei Verwendung der Begriffe des Unified Processes). Das heißt, dass es auf den Ergebnissen der vorhergehenden Phase und dem ersten Review-Dokument vom 26. Mai 2021 aufbaut.
|
||||
|
||||
Das erste Review-Dokument enthält die gängigen Inhalte eines Pflichtenhefts wie die funktionalen und nichtfunktionalen Anforderungen, eine Aufwands- und Risikoanalyse und Überlegungen zum Vorgehen und der internen Organisation. Außerdem umfasste es eine Entwurfsdokumentation für den Grobentwurf, die Anforderungsanalyse, ein Kapitel zu den Technologien und Entwicklungswerkzeugen, Ergebnisse zu den Machbarkeitsanalysen und Beispielrealisierungen und ein Testdrehbuch.
|
||||
|
||||
Im Kapitel zum Grobentwurf werden nun zusätzlich zur erneuten Erläuterung der grundlegenden Architektur die für den Unified Process üblichen Überarbeitungen des Grobentwurfs dargestellt und begründet. Dabei wird, genauso wie beim darauffolgenden Feinentwurf, Paket für Paket vorgegangen. Schließlich werden in einem Bug-Review die offenen Anforderungen und Fehler beschrieben und die mittels des Tools Kimai erfassten Arbeitszeiten ausgewertet.
|
||||
|
||||
Es bleibt anzumerken, dass einige Teile dieses Dokuments wie die Problemstellung oder der ursprüngliche Grobentwurf dem ersten Review-Dokument entnommen sind, weil dies vom Fachgebiet empfohlen wurde und dadurch die Veränderungen besonders gut dargestellt werden können.
|
||||
|
||||
Die Erstellung dieses Review-Dokuments stellt allerdings nur einen Teil der in dieser Phase erledigten Aufgaben dar. Hauptsächlich ging es um die Implementierung des bisher geplanten Systems unter Berücksichtigung aller Muss-Anforderungen, aber auch um die Erstellung einer Entwicklungsdokumentation mittels Doxygen. Im Projektstrukturplan in Abb. \ref{projektstrukturplan} lässt sich das und auch die Aufgaben der letzten Phase, der Validierungsphase, gut erkennen.
|
||||
|
||||
\end{document}
|
||||
189
doc/review_2/chapters/2-grobentwurf.tex
Normal file
189
doc/review_2/chapters/2-grobentwurf.tex
Normal file
@ -0,0 +1,189 @@
|
||||
\documentclass[../review_2.tex]{subfiles}
|
||||
\graphicspath{{\subfix{../img/}}}
|
||||
\begin{document}
|
||||
|
||||
\chapter{Grobentwurf}\thispagestyle{fancy}
|
||||
|
||||
|
||||
Dieses Kapitel behandelt zunächst den Grobentwurf, wie er in der Planungs- und Entwurfsphase des Projekts erarbeitet wurde. Schließlich wird auf dessen Überarbeitung und dazugehörige Diagramme eingegangen.
|
||||
|
||||
\section{Grundlegende Architektur}
|
||||
|
||||
In folgendem Unterkapitel werden die grundlegenden Entscheidungen des Entwurfs erklärt und durch die Rahmenbedingungen begründet. Ein intuitiver Einstieg soll schrittweise an das System heranführen über Erklärung des Netzwerkaufbaus, dem grundlegenden Aufbau der Software, dem Kontrollfluss eines Pakets und verwendeter Verfahren.
|
||||
|
||||
\subsection{Netzwerkaufbau}
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=1.0\linewidth]{img/Netzwerkplan-Real}
|
||||
\caption{Realaufbau unter Verwendung eines Angreifers}
|
||||
\label{fig:netzwerkplan-real}
|
||||
\end{figure}
|
||||
Die Abbildung \ref{fig:netzwerkplan-real} zeigen den typischen, zu erwartenden Netzwerkaufbau, welcher in dieser Form im Internet und in der Produktivumgebung vorkommt. 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.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=0.7\linewidth]{img/Netwerkplan-Versuch}
|
||||
\caption{Versuchsaufbau}
|
||||
\label{fig:Versuchsaufbau}
|
||||
\end{figure}
|
||||
|
||||
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 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 demselben 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, das sich in der Abbildung \ref{fig:Versuchsaufbau} auf der rechten Seite befindert, 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.
|
||||
|
||||
|
||||
\subsection{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 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 auf den Kontrollfluss innerhalb des Programms, auf den Einsatz von parallelen Threads und auf die einzelnen Komponenten näher eingegangen.
|
||||
|
||||
\subsubsection{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 insgesamt zu verringern.
|
||||
|
||||
Dabei stellt sich die Frage, wozu die Threads im Programm genau zuständig sind. 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{Kontrollfluss eines Paketes}
|
||||
|
||||
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.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[angle=270, width=0.8\linewidth]{img/activity_control_flow.pdf}
|
||||
\caption{Schematische Darstellung des Kontrollflusses}
|
||||
\label{fig:control_flow}
|
||||
\end{figure}
|
||||
|
||||
\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. Mit ,,Port'' im Folgenden entweder der physische Steckplatz einer Netzwerkkarte gemeint oder jener Teil der Netzwerkadresse, die eine Zuordnung zu einem bestimmten Prozess bewirkt. Die Bedeutung erschließt sich aus dem Kontext.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=0.95\linewidth]{img/Receive-Side-Scaling.png}
|
||||
\caption{Beispielhafte Paketverarbeitung mit Receive Side Scaling}
|
||||
\label{fig:Receive-Side-Scaling}
|
||||
\end{figure}
|
||||
|
||||
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 der selben Zuordnung auf dessen RX-Queues aufgeteilt werden, wie die auf dem anderen Port ankommenden Pakete auf dessen RX-Queues. Dabei ist die Zuordnung auf dem einen Port ,,symmetrisch'' zu der auf dem anderen Port. Das heißt, wenn bei Port 0 ein Paket mit \texttt{Src-IP: a, Dst-IP: b, Src-Port: x, Dst-Port: y} ankommt, wird es genauso dessen RX-Queues zugeteilt, wie ein Paket mit \texttt{Src-IP: b, Dst-IP: a, Src-Port: y, Dst-Port: x} auf RX-Queues von Port 1. 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 (Transmit-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. An dieser Stelle soll auch kurz auf eine Besonderheit von DPDK eingegangen werden: Im Linux-Kernel empfängt ein Programm Pakete durch Interrupt-Handling. Gegensätzlich dazu werden bei DPDK alle empfangenen Pakete, die sich derzeit in den RX-Queues der Netzwerkkarte befinden auf einmal von der Anwendung gepollt. In der zu entwickelnden Software geschieht dieses Polling durch den einzelnen Thread stets zu Beginn eines Pipeline-Durchlaufes.
|
||||
|
||||
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, weil das Tupel aus besagten Adressen der Schlüssel der RSS-Hash-Funktion sind.
|
||||
|
||||
|
||||
|
||||
|
||||
\section{Überarbeiteter Grobentwurf}
|
||||
|
||||
Die in diesem Abschnitt erläuterten Änderungen wurden im Laufe der Implementierungsphase vorgenommen. Für das bei diesem Softwareprojekt genutzte Vorgehensmodell des Unified Process ist es typisch, dass sich auch während der Implementierung Änderungen am Entwurf ergeben. Für die Teammitglieder ist es besonders aufgrund der geringen Erfahrung bezüglich der Thematik des Projekts unerlässlich, wichtige Verbesserungen direkt vornehmen zu können.
|
||||
|
||||
\subsection{Paketdiagramm}
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.95\linewidth]{img/2-grobentwurf/packet_diagram.pdf}
|
||||
\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. Diese Komponente beinhaltet Klassen zur Paketrepräsentation für das Treatment und die Inspection. Sie liefert Operationen zum Löschen, Senden, Empfangen und Bearbeiten von Paketen. In der PacketDissection werden auch Informationen aus den einzelnen Headern eines Netzwerkpakets extrahiert.
|
||||
|
||||
Die extrahierten 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 für die Abwehrwehrmaßnahmen der verschiedenen Angriffe zuständig ist, verwendet hierzu die von der Inspection bereitgestellten Ergebnisse und Informationen. Für das Versenden und Verwerfen von Pakten, sowie den Aufbau und das Terminieren von Verbindungen, verwendet das Treatment die PacketDissection, welche die Anweisung an das NicManagement weitergibt.
|
||||
|
||||
Sowohl Treatment, als auch Inspection und PacketDissection verwenden das ConfigurationManagement, welches Parameter für die Programmbestandteile in Form von Konfigurationsdateien vorhält. Das ConfigurationManagement bietet die Möglichkeit für den Nutzer, aktiv Einstellungen am System vorzunehmen.
|
||||
|
||||
|
||||
\subsection{NicManagement}
|
||||
Das NicManagement übernimmt wie im letzten Review-Dokument erwähnt das Senden, das Pollen und das Löschen von Paketen. Das Paket wurde eingeführt, um bestimmte Funktionen und Initialisierungsschritte vom DPDK zu kapseln. Es hat sich allerdings herausgestellt, dass die Operationen ,,Senden'', ,,Empfangen'' und ,,Löschen'' in der Implementierung sehr wenig Aufwand bereiten. Das Zusammenbauen von Paketen wird von der Komponente PacketDissection übernommen. Der aufwändigere Teil ist die Initialisierung des DPDK, insbesondere die Ermöglichung von Multithreading und die Konfigurierung von symmetric Receive-Side-Scaling. Die dazu notwendigen Schritte werden jedoch von Initializer bzw in der main.cpp-Datei vor dem Starten der einzelnen Threads durchgeführt und sind nicht mehr Teil des NicManagements.
|
||||
|
||||
Aus diesem Grund und weil jeder nicht notwendige Funktionsaufruf Rechenzeit kostet könnte das NicManagement aufgelöst und die bereitgestellten Funktionen an anderer Stelle implementiert werden. Die einzige Klasse, die das NicManagement zum jetzigen Zeitpunkt verwendet ist die PacketContainer-Klasse in der Komponente PacketDissection. Es wäre möglich, den Inhalt der NicManagement-Aufgaben in diese Klasse zu verschieben.
|
||||
|
||||
|
||||
\subsection{ConfigurationManagement}
|
||||
Das Paket \glqq ConfigurationManagement \grqq{} kümmert sich um die Initialisierung der Software und desweiteren werden hier die ablaufenden Threads konfiguriert und verwaltet. Grundlegend ist das Paket in drei Klassen eingeteilt, Configurator, Initializer und Thread.
|
||||
|
||||
Die Klasse \glqq Configurator\grqq{} bietet eine Schnittstelle zu der Konfigurationsdatei, welche im Projekt liegt und die grundelegenden Einstellungen der Software enthält. An anderer Stelle kann dann über verschiedene Methoden auf Konfigurationsinformationen zugegriffen werden.
|
||||
|
||||
Die Klasse \glqq Initializer\grqq{} dient dazu die für die Bibliothek DPDK notwendigen Vorrausetzungen zu schaffen.
|
||||
|
||||
Die Klasse \glqq Thread\grqq{} enthält den Ablaufplan für die Workerthreads des Systems.
|
||||
|
||||
\subsection{PacketDissection}
|
||||
Der Zweck dieses Pakets ist, sämtliche Daten, die Analyser und Treatment für ihre Arbeit brauchen, aus den Paketen zu extrahieren.
|
||||
|
||||
Dafür war geplant, in dieser Komponente die Repräsentation eines Paketes - die Klasse ,,PacketInfo'' - unterzubringen. Jedes Paket sollte einzeln repräsentiert durch die Pipeline des Programmes gereicht werden. Es hat sich herausgestellt, dass dieses Vorgehen ineffizient ist. Näheres dazu ist im Feinentwurfskapitel beschrieben.
|
||||
|
||||
Aus diesem Grund wurde eine neue Klasse namens ,,PacketContainer'' eingeführt. Diese dient als Repräsentation einer Folge von Paketen, die empfangen wurden. Enthalten sind sowohl die Pointer auf die tatsächlichen Pakete als auch Metadaten in Form mehrerer Objekte der PacketInfo-Klasse. Auf dem PacketContainer ist es möglich, Pakete zu entnehmen, hinzuzufügen und zu löschen. Weiterhin gibt es jeweils eine Methode zum pollen neuer Pakete und zum senden aller vorhandener Pakete. %Näheres zur Implementierung findet sich im Feinentwurfskapitel.
|
||||
|
||||
Die PaketInfo Klasse stellt immernoch alle relevanten Header-Informationen eines Paketes zur Verfügung. Allerdings werden Informationen nur noch auf Abruf extrahiert. Hierbei werden für die IP Versionen 4 und 6, sowie die Layer 4 Protokolle TCP, UDP und ICMP unterstützt. Darüber hinaus soll sie auch das verändern einzelner Informationen im Header ermöglichen.
|
||||
|
||||
|
||||
Die letzte Klasse in der PacketDissection ist der namensgebende HeaderExtractor. Seine Aufgabe wandelte sich vom Extrahieren der Informationen zum Vorbereiten des Extrahieren auf Bedarf.
|
||||
|
||||
\subsection{Inspection}
|
||||
|
||||
Die zuvor globale Auswertung von Angriffen aller Threads durch eine einzige Instanz wurde ersetzt durch eine lokale threadeigene Auswertung. Berechnete Zahlen und Statistiken wie Paketrate und Angriffsrate werden per Interthreadkommunikation nur noch an eine globale Statistikinstanz gesendet. Dadurch können die Threads unabhängig voneinander agieren und reagieren, die implementation der Methoden ist deutlich einfacher ausgefallen und die Interthreadkommunikation konnte auf ein einwegiges minimum begrenzt werden was der Auswertungsgeschwindigkeit jedes Inspection-Threads zugute kommt.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=.6\linewidth]{img/Inspection_old.png}
|
||||
\caption{Altes Klassendiagramm der Inspection aus der Implementierungsphase}
|
||||
\label{InspectionOld}
|
||||
\end{figure}
|
||||
|
||||
Durch den Einsatz von symetric Receive Side Scaling ist sowohl die Auslastung jeder Inspektion ausgeglichen und zusätzlich werden gleiche Paketströme (selbe Paketquelle und -Empfänger) durch denselben Thread verarbeitet. Dies erleichtert die Erkennung legitimer Pakete, da diese über eine eigene Patchmap für bestimmte Fälle von großteilig illegitimen Verkehr unterscheidbar ist und die Variationen geringer sind.
|
||||
|
||||
Die Statistik wird statt durch eine eigene Klasse direkt in der Inspection erstellt und das Ergebnis an eine globale Statistik Instanz gesendet, um diese an den Nutzer auszugeben. Die Inspection Klasse ist dadurch schlanker und folgt einem linearen Pipelinemodell für Paketverarbeitung.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=.2\linewidth]{img/Inspection_new.png}
|
||||
\caption{Aktuelles Klassendiagramm der Inspection aus der Planungs- und Entwurfsphase}
|
||||
\label{AnalyzerNew}
|
||||
\end{figure}
|
||||
|
||||
% TODO: neue globale Statistik
|
||||
|
||||
|
||||
\subsection{Treatment}
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{img/classdia_treatment.pdf}
|
||||
\caption{Aktuelles Klassendiagramm des Treatments aus der Implementierungsphase}
|
||||
\label{Treatmentclassdia}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=0.7\linewidth]{img/package_Treatment.png}
|
||||
\caption{Altes Paket Treatments mit verschiedenen Klassen aus der Planungs- und Entwurfsphase}
|
||||
\label{Treatmentclassdia2}
|
||||
\end{figure}
|
||||
|
||||
Abbildung \ref{Treatmentclassdia} zeigt das während der Implementierungsphase überarbeitete Klassendiagramm. Auf den ersten Blick unterscheidet sich dieses stark vom Grobentwurf des \texttt{Treatments} aus der Planungs- und Entwurfsphase (vgl. Abb. \ref{Treatmentclassdia2}).
|
||||
|
||||
Das \texttt{Treatment} hat fortan die Aufgabe, die Implementierung von TCP-SYN-Cookies sowie die Realisierung eines TCP-Proxies zu übernehmen. Zur Realisierung des TCP-Proxies gehört insbesondere die Sequenznummernanpassung zwischen internen und externen Verbindungen.
|
||||
|
||||
Es fällt auf, dass keine Vererbung mehr verwendet wird. Das heißt, dass nicht mehr zwischen \texttt{TcpTreatment} und \texttt{UdpTreatment} unterschieden wird. Der Grund hierfür ist die Auslagerung des UDP-Treatments in den \texttt{Analyzer} (Paket \texttt{Inspection}). Es wird allerdings nicht nur das UDP-Treatment ausgelagert, sondern auch die Behandlung der SYN-FIN-Attacke sowie des TCP-Small- und Zero-Window-Angriffs. Dies ist darin begründet, dass bereits im \texttt{Analyzer} alle hierzu benötigten Informationen und Funktionalitäten bereitstehen. Dies führt letztlich dazu, dass Funktionsaufrufe oder function calls reduziert werden, welches es dem Programm ermöglicht, insgesamt eine bessere Performanz aufzuweisen.
|
||||
Durch den Wegfall der Klasse \texttt{UdpTreatment} entfällt die Notwendigkeit der Vererbung und die gesamte Implementierung des Treatments kann in einer einzigen Klasse erfolgen.
|
||||
|
||||
Das ursprüngliche Attribut \texttt{tcp\_connection\_table} wurde umbenannt in \texttt{\_densemap}. Der Unterstrich vor dem Variablennamen zeigt, dass es sich um eine Member-Variable handelt. Durch die Umbennenung wird deutlich, dass es sich um eine Google-Densemap handelt und nicht um eine beliebige Map.
|
||||
Hinzu kommt zusätzlich die \texttt{\_ackmap}, bei der es sich ebenfalls um eine Densemap handelt. Die ACK-Map hat zur Aufgabe, diejenigen Pakete zwischenzuspeichern, welche im letzten ACK des externen Verbindungsaufbaus am System ankommen und nach erfolgreichem Verbindungaufbau mit dem internen System an ebendieses weitergeleitet werden müssen.
|
||||
Der Wegfall von \texttt{load\_rate\_limit} und \texttt{timeout\_value} ist ähnlich wie beim \texttt{UdpTreatment} durch die Auslagerung in den \texttt{Analyzer} zu begründen.
|
||||
Die Variable \texttt{\_timestamp}, die in der Implementierungsphase hinzugekommen ist, wird benötigt, um das Alter der ACKs, welche als Reaktion auf ein SYN-ACK erhalten werden, zu bestimmen.
|
||||
Das \texttt{\_cookie\_secret} wird im SYN-Cookie verwendet, um es einem potentiellen Angreifer schwieriger zu machen, eine illegitime Verbindung zum System aufzubauen, indem den Cookies ein weiterer schwieriger zu erratender Wert hinzugefügt wird.
|
||||
Bei den Variablen \texttt{\_packet\_to\_inside} und \texttt{\_packet\_to\_outside} handelt es sich um Pointer zu \texttt{PacketContainern}. Diese speichern die dem Treatment im Konstruktor übergebenen \texttt{PacketContainer}-Pointer für den weiteren internen Gebrauch.
|
||||
|
||||
Um ein Objekt der Klasse \texttt{Treatment} zu erzeugen, muss der Konstruktor aufgerufen werden und die beiden Parameter \texttt{pkt\_to\_inside} und \texttt{pkt\_to\_outside} vom Typ \texttt{PacketContainer*} übergeben werden.
|
||||
|
||||
Die Sequenznummernzuordnung, die ursprünglich in der Methode \texttt{do\_seq\_num\_mapping()} vorgenommen werden sollte, ist nun Teil der Methode \texttt{treat\_packets()}, welche allumfassend für das gesamte Verbindungsmanagement des TCP-Verkehrs zuständig ist.
|
||||
Der Inhalt der Methode \texttt{manage\_syn\_cookies()} wurde mit der Überarbeitung auf verschiedene Methoden aufgeteilt: Der Hash-Wert des TCP-SYN-Cookies wird in der Methode \texttt{calc\_cookie\_hash()} berechnet. Das dazu benötigte Cookie-Secret ist der globale Wert \texttt{\_cookie\_secret}, der durch den Rückgabewert der Methode \texttt{create\_cookie\_secret()} initialisiert wird. Dieser Wert ändert sich während des Ablaufs des Programms nicht. \texttt{Check\_syn\_cookie()} vergleicht den Cookie eines ankommenden, zum Verbindungsaufbau gehörenden ACKs mit dem für diese Verbindung erwarteten Wert.
|
||||
Die Methode \texttt{manage\_timeout()} wurde aus oben genannten Effizienzgründen und der Zugehörigkeit zur Behandlung der Sockstress-Attacken (TCP-Small- bzw. TCP-Zero-Window) ebenfalls in den \texttt{Analyzer} verschoben.
|
||||
Die Methode \texttt{manage\_server\_connection()} wurde mit der Methode \texttt{treat\_packets()} konsolidiert, um auch hier Funktionsaufrufe einzusparen.
|
||||
|
||||
\end{document}
|
||||
219
doc/review_2/chapters/3-feinentwurf.tex
Normal file
219
doc/review_2/chapters/3-feinentwurf.tex
Normal file
@ -0,0 +1,219 @@
|
||||
\documentclass[../review_2.tex]{subfiles}
|
||||
\graphicspath{{\subfix{../img/}}}
|
||||
\begin{document}
|
||||
|
||||
\chapter{Feinentwurf}\thispagestyle{fancy}
|
||||
|
||||
\begin{itemize}
|
||||
\item falls wir es nicht in ein extra Paket packen, wird hier alles erklärt, was im Root-Ordner liegt. Also Thread (WorkerThread) und das was in main.cpp passiert. Also der Initialisierungskram
|
||||
\item Außerdem: Klassendiagramm der ganzen Software, ohne Methoden, Attribute, nur die Namen der Klassen und die Beziehungen zwischen den Klassen, vielleicht visuell angeordnet nach Paketen (hübsch mit gestrichelten Linien wenn möglich)\\
|
||||
|
||||
\item Initialisierung:
|
||||
\begin{itemize}
|
||||
\item init\_dpdk (wird im Allgemeinen nicht genauer erklärt)
|
||||
\item symmetric rss
|
||||
\item Starten von Threads
|
||||
\end{itemize}
|
||||
|
||||
\end{itemize}
|
||||
|
||||
\section{NicManagement}
|
||||
- Klassendiaramm, doxygen
|
||||
|
||||
\section{ConfigurationManagement}
|
||||
\subsection{Configurator}
|
||||
Für die Software gibt es eine Konfigurationsdatei, ,,config.json'', welche innerhalb dieser Klasse eingelesen wird und diese Informationen global zur Verfügung stellt. Von der Klasse soll es im ganzen Programmablauf nur ein Objekt geben, damit keine Inkonsistenzen entstehen können.
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=0.98\linewidth]{img/configurator.pdf}
|
||||
\caption{Klassendiagramm Configurator}
|
||||
\label{Class_Configurator}
|
||||
\end{figure}
|
||||
Aufgrund dieser Anforderungen kann ein spezielles Entwurfsmuster verwendet werden, der Singleton. Der Singleton ist ein Erzeugungsmuster, welches automatisch dafür sorgt, dass nur eine Instanz des Configurator existieren kann, und stellt ähnlich globalen Variablen Informationen global dar. Der Vorteil des Singleton diesen gegenüber besteht darin, dass der Singleton nur dann verwendet wird, wenn er wirklich benötigt wird. Die Klasse des Configurator hat nur einen privaten Konstruktor, welcher in der zum Singleton gehörigen Methode der Instanziesierung, verwendet wird. In der ersten Verwendung des Configurators wird die Methode, ,,read\_config()'', zur Einlesung der Daten ausgeführt.Falls die Configurationsdatei nicht findbar ist, so wird eine Exception geworfen, da die Software ohne diese nicht ablaufen kann. Die ausgelesenen Daten werden dann in einem privaten json-Objekt hinterlegt. Hierzu wichtig zu erwähnen ist, dass nlohmann::json verwendet wird. Die Informationen der json-Datei werden über eine Schnittstelle ,,get\_config(Datentyp)'' anderen Klassen zur Verfügung gestellt, wobei es unterschiedliche Methode je nach Datentyp gibt. Der explizite Aufruf des Auslesens erfolgt über die Methode ,,instance()'', mithilfe jener ein Zeiger auf das Configurator-Objekt zurückgegeben wird.
|
||||
|
||||
|
||||
\subsection{Initializer}
|
||||
Die Klasse Initializer dient dazu, dass grundlegende Initialisierungen für ,,DPDK'' vorgenommen werden, hierzu gibt es die Methode ,,init\_dpdk(int argc, char** argv)''.
|
||||
|
||||
\subsection{Thread}
|
||||
Diese Klasse dient dazu, dass parallele Threads erzeugt werden können, welche dann die gesamte Paketbehandlung des Systems durchlaufen. Hierzu werden jedem Thread zwei PacketContainer übergeben. Ein PacketContainer dient zum annehmen von Paketen welche von außerhalb des Netzwerkes in das Netzwerk kommen und der andere analog dazu mit Paketen, welche von innerhalb des Netzwerkes nach außen sollen. Die run-Methode der Thread-klasse besteht daraus, dass eine bestimmte Anzahl an Paketen gepollt wird mittels der Methode ,,poll\_packets(int number)''. Dies gilt für beide PacketContainer. Nachdem die Pakete behandelt wurden, was innerhalb dieses Pollings passiert, werden die restlichen Pakete nun in jeweilige Richtung weitergeschickt mittels ,,send\_packets()''.
|
||||
|
||||
\subsection{Initializer}
|
||||
Die Klasse Initializer dient dazu, dass grundlegende Initialisierungen für ,,DPDK'' vorgenommen werden, hierzu gibt es die Methode ,,init\_dpdk(int argc, char** argv)''.
|
||||
\section{PacketDissection}
|
||||
Die Aufgabe der PacketDissection ist es, Informationen über die zu untersuchenden Pakete bereitzustellen. Zusätzlich wird auch die Kommunikation mit dem NicManagement über die PacketDissection geleitet.
|
||||
|
||||
Im Diagramm \ref{Sequenzdiagramm_PacketDissection} wird das Polling von Paketen unter Benutzung des PacketContainers dargestellt. Der PacketContainer fungiert hierbei als zentrales Element, dass den Ablauf steuert.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{img/SequenceDiagramPacketDissection2.pdf}
|
||||
\caption{Sequenzdiagramm zum polling von Paketen über den PacketContainer}
|
||||
\label{Sequenzdiagramm_PacketDissection}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Thread}
|
||||
Diese Klasse dient dazu, dass parallele Threads erzeugt werden können, welche dann die gesamte Paketbehandlung des Systems durchlaufen. Hierzu werden jedem Thread zwei PacketContainer übergeben. Ein PacketContainer dient zum annehmen von Paketen welche von außerhalb des Netzwerkes in das Netzwerk kommen und der andere analog dazu mit Paketen, welche von innerhalb des Netzwerkes nach außen sollen. Die run-Methode der Thread-klasse besteht daraus, dass eine bestimmte Anzahl an Paketen gepollt wird mittels der Methode ,,poll\_packets(int number)''. Dies gilt für beide PacketContainer. Nachdem die Pakete behandelt wurden, was innerhalb dieses Pollings passiert, werden die restlichen Pakete nun in jeweilige Richtung weitergeschickt mittels ,,send\_packets()''.
|
||||
|
||||
\section{PacketDissection}
|
||||
\subsection{PacketContainer}
|
||||
DPDK liefert beim Pollen von Paketen ein Array von Pointern auf sogenannte \texttt{mbuf}-Strukturen. Auch beim Senden muss dem Framework ein solches Array übergeben werden, denn die \texttt{mbuf}-Strukturen repräsentieren Pakete innerhalb von DPDK. Um nur die PacketInfo-Objekte durch das Programm reichen zu müssen, wäre das Array von \texttt{mbuf}-Strukturen zu durchlaufen und die Pointer jeweils in die PacketInfo-Objekte zu schreiben. Ein \texttt{mbuf} (Paket) gehört dabei genau einer PacketInfo. Wenn dann am Ende der Pipeline Pakete gesendet werden, müssten die Pointer der \texttt{mbuf}-Strukturen den PacketInfo-Objekten wieder entnommen und in ein Array geschrieben werden. Dies ist überflüssiger Aufwand, da es möglich ist, das empfangene \texttt{mbuf}-Array beizubehalten. Dies setzt der PacketContainer um.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{img/PacketContainerClass.pdf}
|
||||
\caption{Klassendiagramm PacketContainer}
|
||||
\label{Klassendiagramm_PacketContainer}
|
||||
\end{figure}
|
||||
|
||||
Der PacketContainer ist keine aktive Klasse und wird aufgerufen um spezielle, in Dagramm \ref{Klassendiagramm_Packet} angegebene Aufgaben umzusetzen. Eine dieser Aufgaben ist das polling von Paketen, der Ablauf wird im Sequenzdiagramm \ref{Sequenzdiagramm_PacketDissection} dargestellt. Eine weitere Aufgabe ist das verwerfen von Paketen, welches durch \textit{drop\_packet(int index)} umgesetzt wird. Hierbei wird dem NetworkPacketHandler mitgeteilt, welcher \texttt{mbuf} verworfen werden soll und die Referenzen im PacketContainer selbst gelöscht. Es ist aber auch möglich, mittels \textit{take\_packet(int Index):PacketInfo*} Pakete aus dem PacketContainer zu entfernen, ohne sie zu löschen. Dafür werden nur die PacketContainer internen Referenzen auf den \texttt{mbuf} und seine PacketInfo zu Nullreferenzen gesetzt und die PacketInfo zurückgegeben. Diese entnommenen Pakete können später wieder mit \textit{add\_packet(PacketInfo* pkt\_info):int} eingefügt werden. Dafür wird dieses Paket hinter die bereits existenten Pakete im \texttt{mbuf}-Array gespeichert. Selbiges wird für die zugehörige PacketInfo gemacht. Zurückgegeben wird der Index, unterdem das neue Paket zukünftig erreichbar sein wird. Es können nicht nur zuvor entnommene Pakete einem PacketContainer hinzugefügt werden, sondern auch komplett neue. Dieses erstellen von Paketen ist mit dem Befehl \textit{get\_empty\_packet(PacketType pkt\_type):PacketInfo*} möglich. Hierbei wird für einen neuen \texttt{mbuf} Speicher aus einem \texttt{mempool} alloziert und eine zugehörige PacketInfo vom gewünschten PacketType erstellt. Mithilfe dieser PacketInfo, kann der Paket Kopf im Anschluss befüllt werden. Zuletzt müssen all diese Pakete auch wieder mit \textit{send\_packets()} versendet werden. Dafür wird das \texttt{mbuf}-Array falls notwendig umsortiert, da durch \textit{drop\_packet(int Index)} Lücken entstehen können und DPDK nicht mit Nullreferenzen umgehen kann. Zuletzt wird das Array über den NetworkPacketHandler an DPDK zur Versendung übergeben.
|
||||
|
||||
Auch wenn bisher immer nur von je einem Array für \texttt{mbuf}s und PacketInfos gesprochen wurde, können es mehrere werden. Es gibt bei DPDK eine sogenannte BurstSize, welche angibt wie viel Pakete maximal auf einmal entgegengenommen und wieder versendet werden. Daran sind auch die Arrays größentechnisch angepasst. Da es aber durch Maßnahmen des Treatments und Analysers zur Erzeugung von neuen Paketen kommen kann, gibt es zusätzliche Arrays falls die ersten bereits voll sind. Die Verwaltung dieser Arrays ist in allen Funktionen enthalten und hat nach außen keinen sichtbaren Effekt.
|
||||
|
||||
\subsection{PacketInfo}
|
||||
Die genaue Umsetzung, sowie die daraus resultierende Befüllung hat sich im Laufe der Entwicklungsphase sehr stark verändert. Dies hatte vor allem Performance-Gründe. In der aktuellen Variante ist die PacketInfo selbst nur für die Verwaltung des \texttt{mbuf}s sowie das Speichern seines Layer 3 und 4 Protokolls verantwortlich.
|
||||
|
||||
Um ausschließich notwendigen Informationen zu speichern, wird diese PacketInfo in eine protokollspezifische Variante gecastet. Diese spezialisierten Varianten erben von der eigentlichen PacketInfo und erweitern sie um Getter- und Setterfunktionen für die relevanten Header-Informationen ihrer jeweiligen Protokolle.
|
||||
|
||||
Auch wenn in Diagramm \ref{Klassendiagramm_Packet} PacketInfos mit IPv6 aufgeführt werden, sind diese noch nicht funktionsfähig. Es wurde sich entsprechend der Anforderungen zuerst auf IPv4 konzentriert.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{img/PacketInfoInheritance.pdf}
|
||||
\caption{Klassendiagramm aller PacketInfo Varianten}
|
||||
\label{Klassendiagramm_PacketInfo}
|
||||
\end{figure}
|
||||
|
||||
\subsection{HeaderExtractor}
|
||||
Wie bereits erwähnt, wurde die Extraktion der Header Informationen dezentralisiert und wird nur bei Abruf entsprechender Informationen durchgeführt. Dies führte zu einer Verringerung von Code für den HeaderExtractor im Laufe der Entwicklung, weshalb er in den PacketContainer integriert wurde. In obigen Sequenzdiagramm stellt er die Funktionen \textit{extract\_header\_info()} und \textit{fill\_info(rte\_mbuf* mbuf, PacketInfo* pkt\_inf)}.
|
||||
|
||||
Dabei wird in \textit{extract\_header\_info()} über die einzelnen Elemente des PacketContainers iteriert und für jeden \texttt{mbuf} die Funktion \textit{fill\_info(rte\_mbuf* mbuf, PacketInfo* pkt\_inf)} aufgerufen. Welche wiederum den PacketInfoCreator ausführt und den \texttt{mbuf} mit der zugehörigen PacketInfo verknüpft.
|
||||
|
||||
\subsection{PacketInfoCreator}
|
||||
Diese Klasse ist ein Hilfsmittel, um Vererbungsketten zu vermeiden. Ihre Aufgabe ist es die zum Paket passende PacketInfo Version zu erzeugen. Dabei ließt der PacketInfoCreator die Layer 3 und Layer 4 Protokoll IDs aus, legt die entsprechenden structs auf den Speicher und speichert sie in der frisch erzeugten PacketInfo.
|
||||
|
||||
\section{Inspection}
|
||||
Die Inspection ist für die Erkennung böswilliger IP Pakete zuständig und untersucht diese daher auf verdächtige Strukturen und Muster. Dazu wird auch eine eigene lokale Statistik erstellt, zur Auswertung genutzt und zur Informationsweitergabe mit einer globalen Statistik geteilt.
|
||||
|
||||
Der Initializer erstellt für jeden genutzten Thread eine eigene Inspektion welche alle Pakete dieses Threads analysiert und DDoS Attacken erkennt. Dazu wird der Inspection jeweils ein PacketContainer übergeben, der eine Menge von Paketen enthält, die über das NIC Management eingegangen sind.
|
||||
|
||||
Die Erkennung basiert auf einer Mustererkennung von zeitlich aufeinanderfolgenden Paketen nach einer Auftrennung in die Protokolle UDP, TCP und ICMP. UDP und ICMP Pakete werden rein mit einem vorher festgelegten Threshold geprüft, der sich an eine selbst berechnete Angriffsrate anpasst. TCP Pakete werden zusätzlich auf Zero und Small Window sowie auf SYN-FIN und SYN-FIN-ACK Muster überprüft.
|
||||
|
||||
Der Ablauf und Reihenfolge der Prüfungen der Inspection ist aus einer Versuchdurchführung mit einem DecisionTree für DDoS-Abwehr enstanden um einen möglichst schnellen und effizienten Ablauf zu finden. Implementiert wurde eine statische, nicht veränderliche Pipeline, die nach größten auzuschließenden Faktoren jedes Pakets vorgeht.
|
||||
|
||||
Der Ablauf kann grob in drei Filterstufen, auch Security Layers genannt, unterteilt werden.
|
||||
\begin{enumerate}
|
||||
\item RFC Compliance
|
||||
\item Static Rules
|
||||
\item Dynamic Rules
|
||||
\end{enumerate}
|
||||
Ob ein Paket dem RFC Standard entspricht wird bereits bei der PacketInfo klar. Die Inspection bietet die Möglichkeit, bestimmte Fehler zuzulassen oder Pakete mit bestimmten Fehlern zu blockieren und zu löschen.
|
||||
|
||||
Die zweite Stufe der Filter setzt sich aus fest definierten Angriffen und Angriffsmustern zusammen. So sind zum Beispiel bei SYN-FIN und SYN-FIN-ACK Angriffen immer die Flags SYN und FIN oder SYN, FIN und ACK gesetzt, können sofort erkannt und das Paket verworfen werden. Weitere Angriffe die in der statischen Abwehr erkannt werden sind Zero- und Small-Window Angriffe.
|
||||
|
||||
In der dynamischen Filterstufe werden die Filterregeln entsprechend dem aktuellen Netzwerkverkehr und vorher eingegangenen Paketen angepasst. So dient ein Limit der Paketrate (engl. Threshold) dazu, UDP und TCP Floods abzuwehren. Eigene Verbindungstabellen der ausgehenden Netzwerkverbindungen lassen jedoch legitime Pakete die als Antwort auf eine bestehende Verbindung dienen weiterhin zu, um den legitimen Netzwerkverkehr nicht einzuschränken.
|
||||
|
||||
Die Verknüpfung und Ablauf der Filterung wird in dem folgenden Diagramm vereinfacht dargestellt.
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{img/Security_Layers.png}
|
||||
\caption{Stufen der Sicherheit}
|
||||
\label{security_layers}
|
||||
\end{figure}
|
||||
|
||||
Im Diagramm zu Unterscheiden gilt: die Computer 1 bis 3 sind Angreifer mit unterschiedlichen Angriffen, die ebenso in unterschiedlichen Filterstufen als Angriff erkannt werden und Computer 4 als Nutzer mit legitimen Anfragen an den Server, die den Filterregeln entsprechen.
|
||||
Ausgehender Verkehr aus dem internen System wird grundsätzlich vertraut und nicht zusätzlich gefiltert. Jedoch wird ausgehender Verkehr analysiert um die dynamischen Regeln anzupassen.
|
||||
|
||||
Nach jedem Durchlauf eines PacketContainer werden die lokalen und globalen Statistiken aktualisiert. Die Weitergabe der Informationen an die Statistik erfolgt über einen eigenen interthread Kommunikationskanal zum globalen Statistik-Thread. Die globale Statistik führt alle einzelnen Informationen zusammen und macht sie dem Nutzer in einfacher weise abrufbar.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{img/inspection_ablauf.png}
|
||||
\caption{Aktivitätsdiagramm der Methode \texttt{analyzePacket()} der Inspection}
|
||||
\label{inspection_activity}
|
||||
\end{figure}
|
||||
|
||||
|
||||
\section{Treatment}
|
||||
|
||||
Das \texttt{Treatment}, welches für die Behandlung der SYN-Flut zuständig ist, erhält vom \texttt{Thread} zwei Pointer auf \texttt{PacketContainer}. Für jede Senderichtung, sowohl von Intern nach Extern als auch umgekehrt, existiert einer dieser Container. Der Ablauf in der Behandlung von Paketen unterscheidet sich basierend auf deren Senderichtung. Jedes Paket wird im \texttt{Treatment} zwar einzeln, allerdings im Kontext der gesamten Verbindung betrachtet. Die Behandlung im \texttt{Treatment} beginnt mit dem Iterieren über die Einträge im jeweiligen \texttt{PacketContainer}. Hierbei wird zugleich geprüft, ob das gerade betrachtete Paket bereits gelöscht wurde, oder von einem Typ ist, welcher nicht im \texttt{Treatment} behandelt wird. Dies ist auch im globalen Ablauf der Funktion \texttt{treat\_packets()} in Abbildung \ref{Aktivität_treat_packet_0} sowie \ref{Aktivität_treat_packet_1} zu erkennen. Sollte dies der Fall sein, wird ebendieser Eintrag übersprungen. Sollte es sich bei dem gerade betrachteten Paket beispielsweise um ein UDP Paket handeln, so wird dieses im Treatment nicht weiter betrachtet, da dies bereits im \texttt{Analyzer} geschah.
|
||||
|
||||
Nach diesen ersten Tests findet jeweils eine Fallunterscheidung statt. Für Pakete, welche von extern nach intern geschickt werden sollen, gilt:
|
||||
|
||||
Falls es sich bei dem Paket um ein TCP-SYN-Paket handelt, so wird als Antwort hierauf ein SYN-ACK generiert, dessen Sequenznummer durch einen, vom Programm berechneten, SYN-Cookie ersetzt wird. Hierzu existiert die Methode \texttt{calc\_cookie\_hash()}, welche 24 der 32 Bit langen Sequenznummer generiert, welche später mit 8 Bit Timestamp in der Methode \texttt{treat\_packets()} aufgefüllt werden. Dieser SYN-Cookie enthält Informationen über die Verbindungsentitäten, sowie zur Verbesserung der Effektivität einen Zeitstempel und ein Secret. Dieser SYN-Cookie ermöglicht es, im Verlauf des Verbindungsaufbaus auf das Speichern von Informationen über die Verbindung zu verzichten. Somit wird die Angriffsfläche von SYN-Floods effektiv minimiert.
|
||||
|
||||
Sollte ein ACK als Reaktion auf dieses SYN-ACK erhalten werden, so ist durch die Funktion \texttt{check\_syn\_cookie()} zu überprüfen, ob der empfangene Cookie in Form der Sequenznummer plausibel ist (Siehe Abb. \ref{check_syn_cookie}). Das bedeutet, dass der Zeitstempel maximal eine Zeiteinheit alt ist, welche in diesem Programm 64 Sekunden dauert, und der restliche Cookie mit dem erwarteten Cookie übereinstimmt. Der Cookie setzt sich insgesamt zusammen aus 8 Bit Timestamp, sowie 24 Bit Hashwert über externe und interne IP-Adresse, externe und interne Portnummer sowie dem Timestamp und dem Cookie\_Secret.
|
||||
Desweiteren ist eine Verbindung mit dem internen Server, spezifiziert in der DestIP des ACK-Paketes, aufzubauen. Zudem muss die dem ACK hinzugefügten Payload gespeichert werden, auch dies geschieht in einer separaten Map, der ACKmap. Dieses ACK-Paket muss nach erfolgreichem Verbindungsaufbau mit dem internen Server an ebendiesen verschickt werden.
|
||||
|
||||
Wird ein SYN-ACK von extern empfangen, so ist dies ohne Veränderung an das interne Netz zuzustellen. Allerdings muss hier ein Eintrag in der Offsetmap erzeugt werden, wobei der Offset realisierungsbedingt null ist.
|
||||
|
||||
Werden Pakete ohne gesetzte Flags, beziehungsweise nur mit gesetztem ACK-Flag verschickt, so findet eine Sequenznummernzuordnung und eine Anpassung von Sequenznummern statt. Hierzu wird eine Densemap mit individueller Hashfunktion, in diesem Fall XXH3, verwendet. Bei der Densemap handelt es sich um eine besonders effiziente Hashmap, welche ein Einfügen, Suchen und Löschen in bis zu vier mal weniger Zeit als eine unordered\_map ermöglicht. Die Auswahl der Hashfunktion XXH3 ist dadurch motiviert, dass sie extrem schnell ist und dennoch kaum Kollisionen erzeugt. Insbesondere werden durch sie bereits auf handelsüblichen Computersystemen Hashraten von bis zu 31.5 Gbit/s erzielt.
|
||||
|
||||
Der Ablauf bei Empfang eines solchen Paketes ist wie folgt: Bei eingehenden Paketen wird ein zuvor berechneter Offset, welcher in der Offsetmap für jede Verbindung gespeichert ist, von der ACK-Nummer subtrahiert.
|
||||
|
||||
Wird ein ACK empfangen, welches zu einer Verbindung gehört, in deren Info finseen auf true gesetzt ist, so muss die ACK-Nummer angepasst, das Paket an den internen Server geschickt und der Eintrag in der Densemap verworfen werden.
|
||||
|
||||
Falls ein Paket mit gesetzem RST-Flag von extern empfangen wird, wird der Eintrag in der Densemap gelöscht und das empfangene Paket an den internen Server weitergeleitet. Hierbei muss keine Anpassung der ACK-Nummer vorgenommen werden.
|
||||
|
||||
Sollte ein FIN empfangen werden, so muss im Info-Struct, welches Teil der Offsetmap ist, der Wert finseen auf true gesetzt werden. In diesem Fall ist das Paket nach Anpassung der ACK-Nummer weiterzuleiten.
|
||||
|
||||
|
||||
|
||||
Im zweiten Fall der übergeordneten Fallunterscheidung erhält das Programm den \texttt{PacketContainer} der Pakete, welche das Netz von intern nach extern verlassen wollen. Auch hier wird, bevor ein Paket der Behandlung unterzogen wird, geprüft, ob das Paket nicht bereits gelöscht wurde, oder es sich um ein Paket falschen Typs handelt.
|
||||
|
||||
Falls ein Paket mit gesetzem RST-Flag von extern empfangen wird, wird der Eintrag in der Densemap gelöscht und das empfangene Paket an den internen Server weitergeleitet. Hierbei muss keine Anpassung der ACK-Nummer vorgenommen werden.
|
||||
|
||||
Sollte ein FIN empfangen werden, so muss im Info-Struct, welches Teil der Offsetmap ist, der Wert finseen auf true gesetzt werden. In diesem Fall ist das Paket nach Anpassung der ACK-Nummer weiterzuleiten.
|
||||
|
||||
|
||||
|
||||
Im zweiten Fall der übergeordneten Fallunterscheidung erhält das Programm den \texttt{PacketContainer} der Pakete, welche das Netz von intern nach extern verlassen wollen. Auch hier wird, bevor ein Paket der Behandlung unterzogen wird, geprüft, ob das Paket nicht bereits gelöscht wurde, oder es sich um ein Paket falschen Typs handelt.
|
||||
|
||||
Erhält das System ein SYN-Paket von einem internen Server, so wird dieses an das im Paket spezifizierte Ziel weitergeleitet. Eine Anpassung der Sequenznummer findet in diesem Fall nicht statt.
|
||||
|
||||
Erhält das System ein SYN-ACK aus dem internen Netz, so muss das System die Differenz aus der ACK-Nummer dieses Pakets, und der des in der ACKmap gespeicherten Paketes berechnen, und den Wert als Offset in der Offsetmap eintragen. Das von intern empfangene SYN-ACK Paket muss verworfen werden.
|
||||
Das zuvor in der ACKmap zwischengespeicherte Paket muss nun mit angepasster ACK-Nummer intACK = extACK-offset an den internen Host geschickt werden.
|
||||
|
||||
Wird ein Paket ohne gesetzte Flags oder mit gesetztem ACK-Flag von Intern nach Extern verschickt, so findet eine weitere Fallunterscheidung statt.
|
||||
Im Fall, dass finseen bereits auf true gesetzt ist, muss der Offset in der Offsetmap nachgeschlagen werden, der Eintrag daraufhin gelöscht werden und das empfangene Paket mit extSeq = intSeq + offset verschickt werden.
|
||||
Gesetzt den Fall, dass noch kein Eintrag in der Offsetmap existiert, muss ein neuer Eintrag in dieser erstellt werden. Der Offsetwert muss auf null, und finseen auf false gesetzt werden. Das empfangene Paket muss hiernach nach Intern weitergeleitet werden.
|
||||
Trifft keiner der beiden obigen Fälle ein, so muss der Offset in der Offsetmap nachgeschlagen werden und das empfangene Paket nach Intern weitergeschickt werden. Vor dem Versenden muss hierbei die Sequenznummer wie folgt angepasst werden: extSeq = intSeq + offset.
|
||||
|
||||
Sollte ein Paket mit gesetzem FIN-Flag erkannt werden, so ist diese Information in der Info an Stelle Key = Hash(extip, intip, extport, intport) mit dem Vermerk finseen = true, zu speichern. Das empfangene Paket ist durch das System nach extern mit extSeq = intSeq + offset weiterzuschicken.
|
||||
|
||||
Wird ein RST erhalten, so ist eine Anpassung der Sequenznummer vorzunehmen, das Paket entsprechend weiterzuleiten und der Eintrag in der Offsetmap an entsprechender Stelle zu entfernen.
|
||||
|
||||
Desweiteren könnte es unter Umständen erforderlich werden, die Einträge mit einem Timestamp zu versehen, welcher speichert, wann dieser Eintrag zuletzt verwendet wurde, sollte es zu Situationen kommen, in denen sowohl Sender als auch Empfänger die Verbindung nicht korrekt terminieren können. Dies ist bisweilen allerdings nicht implementiert, die Idee wird allerdings basierend auf den Ausgängen der Tests auf dem Testbed weiter verfolgt oder verworfen.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=0.98\linewidth]{img/treat_packets_0.pdf}
|
||||
\caption{Aktivitätsdiagramm der Methode \texttt{treat\_packets()}, Teil: Pakete nach Intern}
|
||||
\label{Aktivität_treat_packet_0}
|
||||
\end{figure}
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=0.96\linewidth]{img/treat_packets_1.pdf}
|
||||
\caption{Aktivitätsdiagramm der Methode treat\_packets(), Teil: Pakete nach Extern}
|
||||
\label{Aktivität_treat_packet_1}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[t]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{img/check_typ_syn_cookie_neu.pdf}
|
||||
\caption{Aktivitätsdiagramm der Methode check\_syn\_cookie()}
|
||||
\label{check_syn_cookie}
|
||||
\end{figure}
|
||||
Nachdem ein ACK als Reaktion auf ein SYN-ACK bei dem zu entwerfenden System angekommen ist, wird die Methode \texttt{check\_typ\_syn\_cookie()} aufgerufen.
|
||||
Grundsätzlich wird hier überprüft, ob der Hash-Wert aus dem empfangenen Paket mit dem eigens berechneten Hash-Wert übereinstimmt. Falls dies nicht der Fall ist oder die Differenz der Zeitstempel zu groß ist, wird ein Paket mit gesetzten Reset-Flag (RST) an den Sender geschickt. Dieses Flag zeigt an, dass die Verbindung beendet werden soll. Andernfalls wird die Verbindung als legitim erkannt und das Paket in der ACKmap zwischengespeichert, bis die Verbindung mit dem internen System erfolgreich war.
|
||||
|
||||
|
||||
\begin{figure}[t]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{img/create_cookie_secret_neu.pdf}
|
||||
\caption{Aktivitätsdiagramm der Methode \textit{create\_cookie\_secret()}}
|
||||
\label{createcookiesecret}
|
||||
\end{figure}
|
||||
Abbildung \ref{createcookiesecret} zeigt die parameterlose Methode \texttt{create\_cookie\_secret()}. Zu Beginn werden drei 16-Bit lange Zufallszahlen generiert, wobei auf cie Funktion \textit{rand()} aus der C Standardbibliothek zugegriffen wird. Der erste mit \texttt{rand()} generierte Wert wird um 48 Bit nach links verschoben, der zweite um 32 Bit. Diese beiden Werte werden danach bitweise ODER miteinander verknüpft. Dieser verknüpfte Wert wird dann wiederum mit der dritten zufälligen 16-Bit Zahl bitweise ODER verknüpft. Das Ergebnis dieser Verknüpfung ist eine 64-Bit lange Zufallszahl, die von der Methode zurückgegeben wird.
|
||||
|
||||
\end{document}
|
||||
35
doc/review_2/chapters/4-bugreview.tex
Normal file
35
doc/review_2/chapters/4-bugreview.tex
Normal file
@ -0,0 +1,35 @@
|
||||
\documentclass[../review_2.tex]{subfiles}
|
||||
\graphicspath{{\subfix{../img/}}}
|
||||
\begin{document}
|
||||
|
||||
\chapter{Bug-Review}\thispagestyle{fancy}
|
||||
|
||||
In diesem Bug-Review werden verschiedene Fehler gesammelt. Dabei wird auf die Datei, in der sie auftreten, auf eine Beschreibung und eine Kategorisierung eingegangen. Major Bugs sind versionsverhindernd, critical bugs können auch zur Arbeitsunfähigkeit anderer führen und minor bugs haben eine geringe Auswirkung und somit eine niedrige Priorität.
|
||||
|
||||
\begin{longtable} [h] {p{3cm} p{8.7cm} l}
|
||||
\toprule
|
||||
\textbf{Datei} & \textbf{Beschreibung} & \textbf{Kategorie} \\ \endhead
|
||||
\midrule
|
||||
|
||||
PacketInfoIpv4Icmp &
|
||||
Wenn von einem Paket die Header extrahiert werden soll (fill\_info), wird zuerst der mbuf in der PacketInfo verlinkt, dann IP version (IPv4) und Layer 4 Protokol (ICMP) ermittelt. Danach wird die PaketInfo in die entsprechende protokolspezifische PacketInfo gecastet. Auf dieser verwandelten PacketInfo wird set\_ip\_hdr ausgeführt und es kommt zum segmentation fault, der im Abbruch des Threads mündet. &
|
||||
critical bug \\
|
||||
|
||||
%Ist dieser Bug nun gelöst?
|
||||
%PacketInfo &
|
||||
%Wenn in der internen IP-Pakete-Weiterleitungstabelle Änderungen vorgenommen werden, kommt %es beim nächsten Paket im Zuge der Headerextraction zu einem segmentation fault. &
|
||||
%minor bug \\
|
||||
|
||||
Initializer &
|
||||
Die maximale Anzahl an Threads ist 16. Das stellt kein Problem dar, weil wir nur 12 Threads brauchen. mlx5\_pci: port 1 empty mbuf pool; mlx5\_pci: port 1 Rx queue allocation failed: Cannot allocate memory.
|
||||
|
||||
Dieser Fehler tritt beim Ausführen von rte\_eth\_dev\_start(port) auf. Womöglich handelt es sich dabei um ein mempool problem.
|
||||
& minor bug \\
|
||||
|
||||
\bottomrule
|
||||
|
||||
\end{longtable}
|
||||
|
||||
Schon während der Implementierungsphase wurden Bugs wenn möglich behoben. An den in dieser Tabelle genannten Problemen wird noch gearbeitet. Die Fehlerliste wird auch in der Validierungsphase laufend erweitert, sodass im Idealfall für das abschließende Review-Dokument eine vollständige Bug-Statistik erstellt werden kann.
|
||||
|
||||
\end{document}
|
||||
207
doc/review_2/chapters/5-kimai.tex
Normal file
207
doc/review_2/chapters/5-kimai.tex
Normal file
@ -0,0 +1,207 @@
|
||||
\documentclass[../review_2.tex]{subfiles}
|
||||
\begin{document}
|
||||
|
||||
\chapter{Auswertung der erfassten Arbeitszeiten}\thispagestyle{fancy}
|
||||
|
||||
Mithilfe des Zeiterfassungssystems Kimai können Arbeitszeiten der Teammitglieder erfasst werden. Dabei werden nicht nur der Beginn und das Ende der Bearbeitung einer Projektaufgabe von der Software aufgenommen, sondern es wird dieser auch eine passende Aktivitätskategorie und fakultativ ein kurzer Text hinzugefügt. Die verschiedenen Kategorien sind in diesem Projekt:
|
||||
\begin{itemize}
|
||||
\setlength{\parskip}{-0.2pt}
|
||||
\item Administration (z.B. Aktualisieren des Gantt-Diagramms)
|
||||
\item Entwurf (z.B. Erstellen des Klassendiagramms oder der Aktivitätsdiagramme)
|
||||
\item Dokumentation (z.B. Arbeiten am Review-Dokument)
|
||||
\item Implementierung (z.B. Ausprogrammieren einer konkreten Klasse)
|
||||
\item Installation (z.B. Herunterladen von DPDK)
|
||||
\item Meetings (z.B. Montagsmeeting mit dem Betreuer um 18:30 Uhr)
|
||||
\item Präsentationsvorbereitung (z.B. Erstellen der Präsentationsfolien)
|
||||
\item Recherche (z.B. Vergleichen verschiedener Maps durch Reports im Internet)
|
||||
\item Test (z.B. Ausführen von Unit Tests und anderen Tests)
|
||||
\end{itemize}
|
||||
Mithilfe dieses Tools kann somit jedes Teammitglied regelmäßig einen Überblick erhalten, was es wann wie lange für das Software-Projekt gemacht hat. \\
|
||||
Am Ende jeder der drei Phasen (Planung- und Entwurf, Implementierung, Validierung) werden die vom Kimai erfassten Daten ausgewertet. Dies ermöglicht, Probleme zu identifizieren und so eventuell später aufkommende Komplikationen vorzubeugen. Falls sich somit in der Auswertung Probleme zeigen, werden Verbesserungsvorschläge und Gegenmaßnahmen entwickelt. \\
|
||||
In diesem Kapitel werden die bisher erfassten Zeiten analysiert und in Diagrammen dargestellt. Diese Diagramme wurden automatisch aus den Daten einer Excel-Datei generiert. Diese Daten stimmen mit denen aus dem Kimai überein. %was bedeutet stand?
|
||||
|
||||
Wir haben den drei Phasen folgende Kalenderwochen zugeordnet:
|
||||
\begin{itemize}
|
||||
\item Planungs- und Enturfsphase: KW 17 - KW 21
|
||||
\item Implementierungsphase: KW 22 - KW 24
|
||||
\item Validierungsphase: KW 25 - KW 29
|
||||
\end{itemize}
|
||||
Die Phasen werden in den folgenden Kapiteln einzeln ausgewertet und deren Ergebnisse am Ende verglichen.
|
||||
\section{Planungs- und Entwurfsphase}
|
||||
|
||||
\begin{figure} [h]
|
||||
\centering
|
||||
\includegraphics[width = \linewidth]{img/Kimai1.pdf}
|
||||
\caption{Planungs- und Entwurfsphase (KW 17-21): Anteile der Aufgabenkategorien an der insgesamt aufgebrachten Zeit}
|
||||
\label{kategorien}
|
||||
\end{figure}
|
||||
|
||||
Das Diagramm \ref{kategorien} zeigt, dass die Zeit in der Planungs- und Entwurfsphase vorwiegend für \textbf{Meetings} aufgewendet wurde. Der Grund dafür könnten die häufigen langen Diskussionen in den Meetings mit allen Teammitgliedern sein. Zudem wurde oft die gemeinsame Arbeit an Aufgaben ebenfalls als Meeting gebucht, auch wenn eine andere Kategorie besser gepasst hätte. Beispielsweise wurde das Klassendiagramm in den wöchentlichen Meetings gemeinsam entworfen. Diese Entwurfsaktivität wurde hier aber unter Meetings und nicht unter Entwurf verbucht. Lösungsideen sind, Meetings themenspezifischer zu buchen und diese nach Möglichkeit in kleineren Gruppen abzuhalten, falls die Themen nicht alle Mitglieder betreffen. Jedoch ist zu beachten, dass hierbei die Konsistenz gewahrt wird. Das bedeutet, dass die \glqq großen\grqq{} Meetings mit dem gesamten Team weiterhin unter Meetings verbucht werden müssen. Dies wurde sowohl bei einem Meeting als auch durch einen Eintrag im Wiki allen Teilnehmern des Projekts kommuniziert. Weiterhin könnten weniger bzw. kürzere Meetings gehalten werden und detaillierte Fragen direkt mit den zuständigen Personen geklärt werden. Dies dann entweder in einem eigenen Meeting oder über die Plattform Zulip.
|
||||
|
||||
Außerdem wurde mit 26\% viel Zeit für die Kategorie \textbf{Dokumentation} in Anspruch genommen. Ein möglicher Grund dafür ist, dass auch die Arbeit am Entwurf (z.B. am Klassen- oder Paketdiagramm) und die dazugehörige Entwurfsdokumentation nur unter der Kategorie Dokumentation, nicht aber unter der Kategorie Entwurf gebucht wurde. Daraus ergibt sich, dass das Team in Zukunft detaillierter buchen soll und die Kategorien womöglich angepasst werden muss.
|
||||
Die für die \textbf{Recherche} aufgebrachte Zeit ist tendenziell verhältnismäßig und bedarf keiner Änderung.
|
||||
|
||||
Es fällt auf, dass für die \textbf{Vorbereitung} von Präsentationen mit 11\% in dieser Projektphase vergleichsweise viel Zeit aufgewendet wurde. Dies resultiert daruas, dass jedes Teammitglied in der ersten Woche eine Präsentation zu verschiedenen Themen wie DoS-Angriffen oder DPDK gehalten hat und ein Template für Präsentationen erarbeitet werden musste. Im weiteren Verlauf des Projektes sollte dieser Anteil sinken, da dann nur noch eine Präsentation pro Phase gehalten werden muss. Zudem müssen womöglich weniger Grafiken für das Review erstellt werden und das Präsentationsdesign kann wiederverwendet werden.
|
||||
|
||||
Für die \textbf{Installation} sind 6\% der Zeit aufgebracht worden. Auch dieser Wert sollte im Verlauf sinken, weil ein Großteil der Installationen bereits erfolgt sind.
|
||||
|
||||
In der Planungs- und Entwurfsphase war der Zeitaufwand für die \textbf{Implementierung} sehr gering, was zu Beginn des Projektes allerdings kein Problem darstellt, da hier lediglich ein erster Prototyp mit stark reduziertem Funktionsumfang entwickelt wurde. Zudem kann es daraus resultieren, dass in dieser Phase mit der Implementierung lediglich zwei der acht Teammitglieder beauftragt waren. Es wird erwartet, dass mit Beginn der Implementierungsphase der für die Implementierung erfasste Aufwand sprunghaft ansteigt.
|
||||
|
||||
Der geringe Anteil des \textbf{Administrationsaufwandes} ist positiv zu bewerten, weil er auf eine effiziente Planung und Verwaltung hinweist.
|
||||
|
||||
Die 3\% der erfassten Zeit, die der \textbf{Entwurf} in Anspruch genommen hat, sind zu wenig. Das ist wahrscheinlich darauf zurückzuführen, dass andere Kategorien für Arbeiten am Entwurf beim Buchen verwendet wurden, beispielsweise Dokumentation oder Meetings (Erklärung siehe oben).
|
||||
|
||||
\begin{figure} [h]
|
||||
\centering
|
||||
\includegraphics[width = \linewidth]{img/Kimai2.pdf}
|
||||
\caption{Planungs- und Entwurfsphase (KW 17-21): Vergleich des theoretischen Aufwands mit dem tatsächlichen Aufwand}
|
||||
\label{sollist}
|
||||
\end{figure}
|
||||
|
||||
Im Balkendiagramm in \ref{sollist} wird dem theoretischen Zeitaufwand pro Woche der tatsächliche Aufwand gegenübergestellt. Die hier angegebenen tatsächlichen Zeiten ergeben sich aus der Addition der wöchentlichen Zeiten aller Teammitglieder.
|
||||
Während Informatiker und Ingenieurinformatiker für das Softwareprojekt acht Leistungspunkte angerechnet bekommen, beträgt diese Punktzahl bei Wirtschaftsinformatiker lediglich sechs. Deshalb wird als Richtwert für die aufzubringende Zeit pro Woche zwischen den Studiengängen unterschieden: Bei Informatikern und Ingenieurinformatikern beträgt dieser Wert 20 Wochenstunden, bei Wirtschaftsinformatikern dagegen nur 15 Wochenstunden.
|
||||
Da das Team aus vier Informatikern, zwei Ingenieurinformatikern und zwei Wirtschaftsinformatikern besteht, beträgt der Soll-Wert pro Woche 150h.
|
||||
\begin{equation*}
|
||||
2\cdot 20h + 4\cdot 20h + 2\cdot 15h = 150h
|
||||
\end{equation*}
|
||||
In Woche 17 liegt Soll-Wert nicht bei 150h, sondern bei 75h, da das Projekt erst am Donnerstag begonnen hat und somit diese Woche kürzer als die anderen war.
|
||||
|
||||
In dieser Kalenderwoche liegt der Ist-Wert fast 20h unter diesen 75h, nämlich bei 55h 9min. Dieses Defizit ist darin zu begründen, dass in dieser ersten Woche das Zeiterfassungssystem den Teammitgliedern noch nicht zur Verfügung stand. Deshalb mussten die Zeiten in der kommenden Woche nachgetragen werden, was jedoch nicht vom gesamten Team gemacht wurde.
|
||||
|
||||
In der Kalenderwoche 18 und der Kalenderwoche 19 liegt der tatsächliche Wert nur noch knapp unter den angestrebten 150 Stunden.
|
||||
|
||||
In den beiden letzten Wochen der ersten Phase werden diese 150h sogar stark übertroffen.
|
||||
Somit lässt sich generell ein positiver Trend ablesen. Es wird jedoch erwartet, dass der in der kommenden Projektphase aufgebrachte Aufwand nicht weiter stark ansteigen wird, da es neben dem Softwareprojekt noch zahlreiche andere Aufgaben für das Studium zu erledigen gibt. Somit ist es für die meisten Studierende kaum möglich, mehr als 20 bis 30 Stunden für dieses Projekt in Anspruch zu nehmen.
|
||||
|
||||
\begin{figure} [h]
|
||||
\centering
|
||||
\includegraphics[width = \linewidth]{img/Kimai3.pdf}
|
||||
\caption{Planungs- und Entwurfsphase (KW 17-21): Zeitaufwand der einzelnen Teammitglieder}
|
||||
\label{teammitglieder}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure} [h]
|
||||
\centering
|
||||
\includegraphics[width = \linewidth]{img/Kimai4.png}
|
||||
\caption{Planungs- und Entwurfsphase (KW 17-21): Tabelle zum Zeitaufwand der einzelnen Teammitglieder}
|
||||
\label{teammitglieder2}
|
||||
\end{figure}
|
||||
|
||||
Den Abbildungen \ref{teammitglieder} und \ref{teammitglieder2} ist zu entnehmen, dass teilweise große Unterschiede zwischen den Teammitgliedern in Bezug auf die wöchentlich aufgebrachten Stunden für das Softwareprojekt bestehen. \footnote{\noindent Jede Linienfarbe in einem Projektmitglied zugeordnet. Auf die Beschriftung der einzelnen Linien wurde jedoch verzichtet, um die Anonymität der einzelnen Personen zu wahren.}
|
||||
Aus dem Diagramm geht hervor, dass in Kalenderwoche 17 noch nicht jeder seine Arbeitszeiten in das Kimai eingetragen hat, da es zu diesem Zeitpunkt Ihnen noch nicht zur Verfügung stand und sie diese hätten nachtragen müssen. Somit liegt bei zwei Personen der Wert in KW17 bei 0.
|
||||
Es ist ein positiver Trend zu sehen, was auch in der Abbildung \ref{sollist} deutlich wurde.
|
||||
Es ist hervorzuheben, dass einzelne Mitglieder weit über 20 Stunden pro Woche für das Softwareprojekt aufwenden. In der Kalenderwoche 20 liegt diese beispielsweise bei einem Teammitglied über 52 Stunden.
|
||||
|
||||
|
||||
\section{Implementierungsphase}
|
||||
\begin{figure} [h]
|
||||
\centering
|
||||
\includegraphics[width = \linewidth]{img/kimai5.pdf}
|
||||
\caption{Implementierungsphase (KW 22-24): Anteile der Aufgabenkategorien an der insgesamt aufgebrachten Zeit}
|
||||
\label{kimai5}
|
||||
\end{figure}
|
||||
Wie in Abbildung \ref{kimai5} zu sehen ist, wurde fast die Hälfte der Zeit dieser Projektphase für die \textbf{Implementierung} verwendet. Dieser Anteil ist durchaus angemessen, weil in der Implementierungsphase der größte Teil des Systems programmiert werden soll.
|
||||
|
||||
\textbf{Meetings} stellen mit 14\% die zweithäufigste Kategorie dar. Diese Größe bedarf nicht zwangsläufig einer Änderung, da die Meetings in dieser Phase lediglich wichtige Themen umfasst haben und so kurz wie möglich gehalten wurden. Außerdem bleibt zu erwähnen, dass in zwei Meetings ein Code-Review durchgeführt wurde, wodurch alle Teammitglieder voneinander lernen konnten und das System insgesamt sowie von anderen entwickelte Komponenten besser verstanden werden konnten.
|
||||
|
||||
Die Kategorien \textbf{Recherche} und \textbf{Dokumentation} nahmen beide ein Zehntel der insgesamt aufgebrachten Zeit in Anspruch und gehen somit mit einem angemessenen Anteil in das Projekt ein.
|
||||
|
||||
Die 6\%, die dem \textbf{Entwurf} zugeordnet werden können, sind relativ wenig. Möglicherweise wurde für diese Kategorie aufgebrachte Zeit auch in andere Kategorien wie Dokumentation oder Implementierung gebucht.
|
||||
|
||||
Positiv zu bewerten ist, dass die restlichen Kategorien, also \textbf{Präsentationsvorbereitung}, \textbf{Test}, \textbf{Administration} und \textbf{Installation}, höchstens 5\% der Zeit in Anspruch genommen haben. Trotzdem ist es wichtig, dass die den Tests zugeordnete Zeit in der kommenden Validierungsphase sprunghaft ansteigt. In der Implementierungsphase hat es sich dabei vor allem um Unit-Tests gehandelt, die für die gesamte Validierung nicht ausreichen
|
||||
werden.
|
||||
|
||||
\begin{figure} [h]
|
||||
\centering
|
||||
\includegraphics[width = \linewidth]{img/kimai7.pdf}
|
||||
\caption{Implementierungsphase (KW 22-24): Vergleich des theoretischen Aufwands mit dem tatsächlichen Aufwand}
|
||||
\label{kimai7}
|
||||
\end{figure}
|
||||
Abbildung \ref{kimai7} macht deutlich, dass in jeder einzelnen Woche der Implementierungsphase (KW 22 - 24) der tatsächliche Zeitaufwand über dem theoretischen Zeitaufwand lag. Die vorgegebenen 150h Stunden Zeitaufwand pro Woche wurden in der Kalenderwoche 23 sogar um über 38h überschritten. Wenn man diese 38h durch die Anzahl der Teammitglieder teilt, die bei acht liegt, wird deutlich, dass in dieser Woche im Durchschnitt jedes Teammitglied 4h und 45min mehr Zeit für das Softwareprojekt aufgewendet hat als vorgegeben.
|
||||
\begin{figure} [h]
|
||||
\centering
|
||||
\includegraphics[width = \linewidth]{img/kimai9.pdf}
|
||||
\caption{Implementierungsphase (KW 22-24): Zeitaufwand der einzelnen Teammitglieder}
|
||||
\label{kimai9}
|
||||
\end{figure}
|
||||
|
||||
Aus Abbildung \ref{kimai9} lässt sich grundsätzlich kein starker Anstieg der Zeit, die jeder einzelne Beteiligte für das Softwareprojekt aufgewendet hat, erkennen. Bei sechs der acht Teammitglieder liegt ihr persönliches Maximum in diesem Zeitraum in KW 23. Hier liegt auch der Punkt, mit dem größten Wert in der Implementierungsphase. Der dazugehörige Wert beträgt 32h 30min (vgl. Abb. \ref{kimai11}).
|
||||
Bei einigen Teammitglieder kann erkannt werden, dass die empfohlene Zeit von 15 bzw. 20 Stunden in einzelnen Fällen unterschritten wird. Üblicherweise wird auf die gesamte Zeit bezogen der Soll-Wert allerdings erfüllt, was man auch in Abbildung \ref{kimai7} erkennen kann.
|
||||
|
||||
|
||||
\begin{figure} [h]
|
||||
\centering
|
||||
\includegraphics[width = 0.8\linewidth]{img/kimai11.png}
|
||||
\caption{Implementierungsphase (KW 22-24): Tabelle mit den erfassten Zeiten}
|
||||
\label{kimai11}
|
||||
\end{figure}
|
||||
|
||||
\section{Vergleich der Projektphasen}
|
||||
\begin{figure} [h]
|
||||
\centering
|
||||
\includegraphics[width = 0.8\linewidth]{img/kimai6.pdf}
|
||||
\caption{Planungs- und Entwurfsphase und Implementierungsphase (KW 17-24): Anteile der Aufgabenkategorien an der insgesamt aufgebrachten Zeit}
|
||||
\label{kimai6}
|
||||
\end{figure}
|
||||
In Abbildung \ref{kimai7} wird die Verteilung der Kategorien bezogen auf den gesamten Projektzeitraum dargestellt.
|
||||
|
||||
Bei einem Vergleich der Anteile der Kategorien an der insgesamt aufgebrachten Zeit zwischen Planungs- und Entwurfsphase und Implementierungsphase fällt als erstes auf, dass sich die für die \textbf{Implementierung} aufgebrachte Zeit vervielfacht hat. Dieser sprunghafte Anstieg wurde auch prognostiziert, weil die Implementierung in der ersten Phase lediglich einen ersten Prototyp umfasste und der zentrale Bestandteil der jetzt abgeschlossenen Phase ist.
|
||||
|
||||
Weiterhin ist der Anteil der \textbf{Meetings} von 29 auf 14\% gesunken. Da dieser Anteil im ersten Abschnitt des Softwareprojekts viel zu hoch war und schließlich auf einen adäquaten Wert gesenkt werden konnte, kann geschlussfolgert werden, dass die richtigen Maßnahmen getroffen wurden. So wurden Diskussionen, die nicht alle Teammitglieder betroffen haben, von den wöchentlichen Treffen in kleinere Gruppen verlagert und dann in der entsprechenden Kategorie themenbezogen gebucht.
|
||||
|
||||
Die \textbf{Dokumentation} hat während der Implementierungsphase ebenfalls weniger Zeit in Anspruch genommen als in der Planungs- und Entwurfsphase. Das umfassende Reviewdokument der ersten Phase, bestehend aus dem Pflichtenheft und einer Entwurfsdokumentation, stellte im ersten Monat des Projekts eine der Hauptaufgaben dar, während ihm in dieser Phase lediglich eine mittelhohe Priorität zugeordnet wurde.
|
||||
|
||||
Der \textbf{Rechercheaufwand} ist leicht gesunken, da sich zu Beginn des Projekts besonders viel Wissen angeeignet werden musste, welches im Laufe des Projekts dann zunehmen angewendet werden musste. Da fast alle Teammitglieder zu Beginn des Projekts recht unerfahren waren, scheinen die 11\% der im gesamten Projektzeitraum aufgebrachten Zeit ein geeigneter Anteil zu sein.
|
||||
|
||||
Insgesamt wurden 9\% der Zeit für die Vorbereitung von \textbf{Präsentationen} verwendet, was ebenfalls positiv zu bewerten ist. An dieser Stelle muss angemerkt werden, dass die Zeiterfassung der Implementierungsphase lediglich die Zeiten bis KW 24 umfasst, wodurch die letzten drei Tage vor der Präsentation nicht abgedeckt wurden. In dieser Zeit wird vermutlich noch eine nicht zu vernachlässigende Menge an Zeit für die Vorbereitung des zweiten Reviews investiert werden. Aus diesem Grund und weil jedes Teammitglied in der ersten Woche des Projekts eine Präsentation zu einem bestimmten Thema ausgearbeitet hat, ist der Wert von 11\% auf 5\% zurückgegangen.
|
||||
|
||||
Der \textbf{Entwurf} umfasste insgesamt 5\% der Zeit und wurde in beiden Phasen tendenziell zu wenig beziehungsweise in anderen, ähnlichen Kategorien erfasst.
|
||||
|
||||
Für die \textbf{Installation} musste sogar in der ersten Phase nur 5\% der Zeit verwendet werden. In der Implementierungsphase sank dieser Anteil auf 2\%. Da fast alle benötigten Komponenten bereits installiert sein sollten, lässt sich vermuten, dass der Anteil dieser Kategorie in der letzten Projektphase weiter gegen null geht.
|
||||
|
||||
Der \textbf{Administrationsaufwand} konnte schon in der ersten Phase des Projekts gering gehalten werden und ging auch in der Implementierungsphase in einem geeigneten Maß ein.
|
||||
|
||||
In der zweiten Phase hat sich der \textbf{Testaufwand} von 2 auf 4\% verdoppelt. Das zeigt, dass die Projektverlauf zunehmende Bedeutung des Testens erkannt wurde. Wichtig ist allerdings, dass beim Testen in der nächsten Phase ein sprunghafter Anstieg ähnlich wie bei der Implementierung zwischen erster und zweiter Phase zu erkennen ist.
|
||||
|
||||
\begin{figure} [h]
|
||||
\centering
|
||||
\includegraphics[width = \linewidth]{img/kimai8.pdf}
|
||||
\caption{Planungs- und Entwurfsphase und Implementierungsphase (KW 17-24): Vergleich des theoretischen Aufwands mit dem tatsächlichen Aufwand}
|
||||
\label{kimai8}
|
||||
\end{figure}
|
||||
Folgendes lässt sich in Abbildung \ref{kimai8} erkennen:
|
||||
Während in den ersten drei Wochen des Softwareprojekts (KW 17-18) der tatsächliche Zeitaufwand noch leicht unter dem theoretischen Wert liegt, ändert sich dies in den darauffolgenden Wochen dahingehend, dass der tatsächliche Zeitaufwand den theoretischen (zum Teil stark) übersteigt.
|
||||
Die Feststellung, dass mehr Zeit aufgewendet wird bzw. werden muss als vorgegeben, stimmt mit der Aufwandsschätzung aus dem ersten Reviewdokument überein.
|
||||
Denn wenn die theoretischen Werte aller bisherigen Wochen (KW 17-24) aufaddiert werden, ergibt sich ein Wert von 1289h 56min (vgl. Abb. \ref{kimai12}). Diesem stehen 1125h entgegen:
|
||||
\begin{align*}
|
||||
1 \cdot 75h+7 \cdot 150h= 1125h
|
||||
\end{align*}
|
||||
In der ersten Aufwandssschätzung schätzten wir den Aufwand des gesamten Projekts auf 2107h.
|
||||
Würden wir in den kommenden Wochen (KW 25-29) \glqq lediglich\grqq{} den theoretische berechnete Zeit brauchen, wären das zu den bisher benötigten 1289h 56min noch 675h, also insgesamt 1964h 56min. Dieser Wert kommt dem Schätzwert aus der Aufwandsschätzung sehr nahe.
|
||||
\begin {align*}
|
||||
4 \cdot 150h + 1 \cdot 75h = 675h
|
||||
\end{align*}
|
||||
|
||||
\begin{figure} [h]
|
||||
\centering
|
||||
\includegraphics[width = \linewidth]{img/kimai10.pdf}
|
||||
\caption{Planungs- und Entwurfsphase und Implementierungsphase (KW 17-24): Zeitaufwand der einzelnen Teammitglieder}
|
||||
\label{kimai10}
|
||||
\end{figure}
|
||||
|
||||
Die Abbildung \ref{kimai10} zeigt den Zeitaufwand der einzelnen Teammitglieder in den Kalenderwochen 17 bis 24. In den Kalenderwochen 17 bis 21 (Planungs- und Entwurfsphase) ist grundsätzlich ein Anstieg bei den meisten Teammitgliedern zu sehen. In den folgenden Wochen (Implementierungsphase) ist dieser nicht mehr so stark zu erkennen. Auch nimmt in den Kalenderwochen 22 bis 24 der Abstand zwischen den einzelnen Punkte in der Abb. \ref{kimai10} ab. Das heißt, dass der Zeitaufwand der einzelnen Teammitglieder sich nicht mehr so stark unterscheidet wie das zum Beispiel in KW 20 der Fall ist. So liegt etwa die Spannweite in KW 20 bei über 39h, während in KW 22 diese bei unter 13h liegt.
|
||||
\begin{align*}
|
||||
R_{KW20} = 52h\: 1min - 12h\: 25min = 39h\: 36min
|
||||
\end{align*}
|
||||
\begin{align*}
|
||||
R_{KW22} = 28h\: 10min - 15h\: 19min = 12h\: 51min
|
||||
\end{align*}
|
||||
Der maximale Wert an Wochenstunden pro Person bleibt in KW 20 mit über 52h (vgl. Abb. \ref{kimai12}).
|
||||
|
||||
\begin{figure} [h]
|
||||
\centering
|
||||
\includegraphics[width = \linewidth]{img/kimai12.png}
|
||||
\caption{Planungs- und Entwurfsphase und Implementierungsphase (KW 17-24): Tabelle mit den erfassten Zeiten}
|
||||
\label{kimai12}
|
||||
\end{figure}
|
||||
\end{document}
|
||||
15
doc/review_2/chapters/6-abkuerzungsverzeichnis.tex
Normal file
15
doc/review_2/chapters/6-abkuerzungsverzeichnis.tex
Normal file
@ -0,0 +1,15 @@
|
||||
\documentclass[../review_2.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[KW] Kalenderwoche
|
||||
\item[Mpps] Million packets per second
|
||||
\end{description}
|
||||
|
||||
\end{document}
|
||||
33
doc/review_2/chapters/7-glossar.tex
Normal file
33
doc/review_2/chapters/7-glossar.tex
Normal file
@ -0,0 +1,33 @@
|
||||
\documentclass[../review_2.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}
|
||||
BIN
doc/review_2/img/2-grobentwurf/packet_diagram.pdf
Normal file
BIN
doc/review_2/img/2-grobentwurf/packet_diagram.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/DoS_Paketdiagramm.png
Normal file
BIN
doc/review_2/img/DoS_Paketdiagramm.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
BIN
doc/review_2/img/Inspection_new.png
Normal file
BIN
doc/review_2/img/Inspection_new.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 15 KiB |
BIN
doc/review_2/img/Inspection_old.png
Normal file
BIN
doc/review_2/img/Inspection_old.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 105 KiB |
BIN
doc/review_2/img/Kimai1.pdf
Normal file
BIN
doc/review_2/img/Kimai1.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/Kimai2.pdf
Normal file
BIN
doc/review_2/img/Kimai2.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/Kimai3.pdf
Normal file
BIN
doc/review_2/img/Kimai3.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/Kimai4.png
Normal file
BIN
doc/review_2/img/Kimai4.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 155 KiB |
BIN
doc/review_2/img/Netwerkplan-Versuch.png
Normal file
BIN
doc/review_2/img/Netwerkplan-Versuch.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 140 KiB |
BIN
doc/review_2/img/Netzwerkplan-Real.png
Normal file
BIN
doc/review_2/img/Netzwerkplan-Real.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 191 KiB |
BIN
doc/review_2/img/PacketContainerClass.pdf
Normal file
BIN
doc/review_2/img/PacketContainerClass.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/PacketInfoInheritance.pdf
Normal file
BIN
doc/review_2/img/PacketInfoInheritance.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/Receive-Side-Scaling.png
Normal file
BIN
doc/review_2/img/Receive-Side-Scaling.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 50 KiB |
BIN
doc/review_2/img/Security_Layers.png
Normal file
BIN
doc/review_2/img/Security_Layers.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 83 KiB |
BIN
doc/review_2/img/SequenceDiagramPacketDissection2.pdf
Normal file
BIN
doc/review_2/img/SequenceDiagramPacketDissection2.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/activity_control_flow.pdf
Normal file
BIN
doc/review_2/img/activity_control_flow.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/aegis_logo.pdf
Normal file
BIN
doc/review_2/img/aegis_logo.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/aegis_logo_with_name.pdf
Normal file
BIN
doc/review_2/img/aegis_logo_with_name.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/calc_sequencenumber.pdf
Normal file
BIN
doc/review_2/img/calc_sequencenumber.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/calc_sequencenumber_neu.pdf
Normal file
BIN
doc/review_2/img/calc_sequencenumber_neu.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/check_typ_syn_cookie.pdf
Normal file
BIN
doc/review_2/img/check_typ_syn_cookie.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/check_typ_syn_cookie__.pdf
Normal file
BIN
doc/review_2/img/check_typ_syn_cookie__.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/check_typ_syn_cookie_neu.pdf
Normal file
BIN
doc/review_2/img/check_typ_syn_cookie_neu.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/classdia_treatment (Kopie).pdf
Normal file
BIN
doc/review_2/img/classdia_treatment (Kopie).pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/classdia_treatment.pdf
Normal file
BIN
doc/review_2/img/classdia_treatment.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/configurator.pdf
Normal file
BIN
doc/review_2/img/configurator.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/create_cookie_secret__.pdf
Normal file
BIN
doc/review_2/img/create_cookie_secret__.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/create_cookie_secret_neu.pdf
Normal file
BIN
doc/review_2/img/create_cookie_secret_neu.pdf
Normal file
Binary file not shown.
57
doc/review_2/img/inspection_ablauf.plantuml
Normal file
57
doc/review_2/img/inspection_ablauf.plantuml
Normal file
@ -0,0 +1,57 @@
|
||||
@startuml
|
||||
\startuml
|
||||
start
|
||||
:erstelle temporäre Zähler für Statistik;
|
||||
:Packetindex auf 0 setzten;
|
||||
while
|
||||
(PacketContainer Größe kleiner als aktueller Paketindex)
|
||||
:extrahiere PacketInfo aus PacketContainer bei gegebenem Paketindex;
|
||||
if (liegt UDP Protokoll vor) then (ja)
|
||||
:erhöhe UDP Zähler;
|
||||
if(UDP Threshold übertreten) then (ja)
|
||||
#FF0000:erkannte UDP Flood;
|
||||
:Angriffs-Zähler erhöhen;
|
||||
:Paket aus PacketContainer entfernen;
|
||||
else (nein)
|
||||
:Paket wird zugelassen;
|
||||
endif
|
||||
elseif (liegt TCP Protokoll vor) then (ja)
|
||||
:erhöhe TCP Zähler;
|
||||
:Caste PacketInfo in PacketInfoIpv4TCP;
|
||||
if(TCP Threshold übertreten) then (ja)
|
||||
#FF0000:erkannte TCP Flood;
|
||||
:Angriffs-Zähler erhöhen;
|
||||
:Paket aus PacketContainer entfernen;
|
||||
else (nein)
|
||||
endif
|
||||
if(WindowSize kleiner als vorgegeben) then (ja)
|
||||
#FF0000:erkannte Small/Zero Window;
|
||||
:Angriffs-Zähler erhöhen;
|
||||
:Paket aus PacketContainer entfernen;
|
||||
else (nein)
|
||||
endif
|
||||
if(SYN und FIN oder SYN, FIN und ACK Flags gesetzt) then (ja)
|
||||
#FF0000:erkannte SYN-FIN(-ACK);
|
||||
:Angriffs-Zähler erhöhen;
|
||||
:Paket aus PacketContainer entfernen;
|
||||
else (nein)
|
||||
:Paket wird zugelassen;
|
||||
endif
|
||||
elseif (liegt ICMPv4 Protokoll vor) then (ja)
|
||||
:erhöhe ICMP Zähler;
|
||||
if(ICMP Threshold übertreten) then (ja)
|
||||
#FF0000:erkannte ICMP Flood;
|
||||
:Angriffs-Zähler erhöhen;
|
||||
:Paket aus PacketContainer entfernen;
|
||||
else (nein)
|
||||
:Paket wird zugelassen;
|
||||
endif
|
||||
else (kein Protokoll von Interesse)
|
||||
:Paket wird zugelassen;
|
||||
endif
|
||||
endwhile
|
||||
:lokale Statistik mit temorären Zählern erneuern;
|
||||
:lokale Statistik an globale Statistik senden;
|
||||
end
|
||||
\enduml
|
||||
@enduml
|
||||
BIN
doc/review_2/img/inspection_ablauf.png
Normal file
BIN
doc/review_2/img/inspection_ablauf.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 119 KiB |
BIN
doc/review_2/img/kimai10.pdf
Normal file
BIN
doc/review_2/img/kimai10.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/kimai11.png
Normal file
BIN
doc/review_2/img/kimai11.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 132 KiB |
BIN
doc/review_2/img/kimai12.png
Normal file
BIN
doc/review_2/img/kimai12.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 189 KiB |
BIN
doc/review_2/img/kimai5.pdf
Normal file
BIN
doc/review_2/img/kimai5.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/kimai6.pdf
Normal file
BIN
doc/review_2/img/kimai6.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/kimai7.pdf
Normal file
BIN
doc/review_2/img/kimai7.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/kimai8.pdf
Normal file
BIN
doc/review_2/img/kimai8.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/kimai9.pdf
Normal file
BIN
doc/review_2/img/kimai9.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/package_Treatment.png
Normal file
BIN
doc/review_2/img/package_Treatment.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 116 KiB |
BIN
doc/review_2/img/projektstrukturplan.pdf
Normal file
BIN
doc/review_2/img/projektstrukturplan.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/treat_packets_0.pdf
Normal file
BIN
doc/review_2/img/treat_packets_0.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/treat_packets_1.pdf
Normal file
BIN
doc/review_2/img/treat_packets_1.pdf
Normal file
Binary file not shown.
BIN
doc/review_2/img/tu_ilmenau_logo.png
Normal file
BIN
doc/review_2/img/tu_ilmenau_logo.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 36 KiB |
69
doc/review_2/references.bib
Normal file
69
doc/review_2/references.bib
Normal file
@ -0,0 +1,69 @@
|
||||
% 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}
|
||||
}
|
||||
|
||||
@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}
|
||||
}
|
||||
|
||||
@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{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{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}}
|
||||
}
|
||||
|
||||
@misc{projectshield,
|
||||
AUTHOR = {ProjectShield},
|
||||
TITLE = {ProjectShield Webseite},
|
||||
NOTE = {Aufgerufen 23.05.2021},
|
||||
HOWPUBLISHED = {Website},
|
||||
URL = {{https://projectshield.withgoogle.com/landing}},
|
||||
YEAR = {2021}
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
\endinput
|
||||
%%
|
||||
%% End of file `sample.bib'.
|
||||
BIN
doc/review_2/review_2.pdf
Normal file
BIN
doc/review_2/review_2.pdf
Normal file
Binary file not shown.
101
doc/review_2/review_2.tex
Normal file
101
doc/review_2/review_2.tex
Normal file
@ -0,0 +1,101 @@
|
||||
\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}
|
||||
\setcounter{secnumdepth}{3}
|
||||
|
||||
\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}
|
||||
\fancyhf{}
|
||||
\fancyhead[EL]{\leftmark}
|
||||
\fancyhead[OL]{\includegraphics[height=25pt]{img/aegis_logo_with_name.pdf}}
|
||||
\fancyhead[OR]{\rightmark}
|
||||
\fancyfoot[EL]{\thepage}
|
||||
\fancyfoot[ER]{SWP2021 AntiDoS}
|
||||
\fancyfoot[OL]{Zweites Reviewdokument}
|
||||
\fancyfoot[OR]{\thepage}
|
||||
\renewcommand{\headrulewidth}{0.2pt} %fügt eine Linie unter der Kopfzeile ein
|
||||
|
||||
\renewcommand{\arraystretch}{1.3} %sorgt für größeren Abstand zwischen Zeilen in Tabellen
|
||||
|
||||
\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}
|
||||
Zweite Review zum Thema\\
|
||||
\vspace{1em}
|
||||
\Large\textsc{Abwehr von Denial-of-Service-Angriffen \\durch effiziente User-Space Paketverarbeitung}\\
|
||||
\vspace{0.5em}
|
||||
\Large\textsc{Codename: AEGIS}\\
|
||||
\vspace{0.5cm}
|
||||
\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 23. Juni 2021
|
||||
\end{center}
|
||||
\end{titlepage}
|
||||
\pagebreak
|
||||
|
||||
\tableofcontents {\protect\thispagestyle{fancy}
|
||||
|
||||
\subfile{chapters/1-einleitung}
|
||||
\subfile{chapters/2-grobentwurf}
|
||||
\subfile{chapters/3-feinentwurf}
|
||||
\subfile{chapters/4-bugreview}
|
||||
\subfile{chapters/5-kimai}
|
||||
\subfile{chapters/6-abkuerzungsverzeichnis}
|
||||
\subfile{chapters/7-glossar}
|
||||
|
||||
|
||||
\bibliography{references}
|
||||
\bibliographystyle{ieeetr}
|
||||
|
||||
\listoffigures {\protect\thispagestyle{fancy} % Abbildungsverzeichnis
|
||||
|
||||
\end{document}
|
||||
Loading…
Reference in New Issue
Block a user