%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% Descr: Vorlage für Berichte der DHBW-Karlsruhe, Ein Kapitel %% Author: Prof. Dr. Jürgen Vollmer, vollmer@dhbw-karlsruhe.de %% $Id: kapitel1.tex,v 1.24 2020/03/13 16:02:34 vollmer Exp $ %% -*- coding: utf-8 -*- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Architekur} Die Architektur des Route Injection Service besteht aus drei wesentlichen Bestandteilen, welche entweder direkt verbunden sind oder mittels Hashicorp Consul Daten austauschen können. \begin{figure}[H] \centering \fbox{\includegraphics[width=\textwidth]{images/ri-structure}} \caption{\label{ri-structure}Route Injection Architektur} \centering{Quelle: Firmenintern} \end{figure} \newpage \section{\ac{API}} Die \ac{API} ist dafür verantwortlich die Eingaben des Users, welche über die Engine übermittelt wurden zu überprüfen und zu validieren. Sind die Eingaben nicht korrekt, so gibt die \ac{API} eine entsprechende Fehlermeldung zurück. In der Zukunft wird die \ac{API} auch dafür verantwortlich sein entsprechende Monitoring Endpunkte zur Verfügung zu stellen, sodass der allgemeine Status des Service überwacht werden kann. \section{Hashicorp Consul} Hashicorp Consul, im weiteren Verlauf nur `Consul` genannt, wird als Zwischenspeicher für Routen und deren injizierte \ac{BGP}-Communities verwendet. Des Weiteren können Injectoren hier Ihren `Heartbeat` abspeichern. \section{Injector} Der Injector bezieht periodisch(alle 5 Sekunden) die in Consul gespeicherten Routen. Sollte es hier eine Änderung gegeben haben, wird eine Konfigurationsdatei für den Bird Routingdaemon neu erstellt. Anschließend wird über das 'Bird Controlsocket' der Befehl zum Neuladen der Konfiguration gegeben. \section{Router} Als Router wird der Bird Routingdaemon eingesetzt. Dieser stellt eine \ac{BGP}-Session mit einem physischen Router her, welcher die von Bird zu Verfügung gestellten Router importiert und innerhalb des \ac{BGP}-Netzwerks weitergibt. \newpage \section{Router Architektur} Ist kein Blackholing aktiv, sieht die Netzwerkinfrastruktur in stark vereinfachter Form wie folgt aus: \begin{figure}[H] \centering \includegraphics[width=\textwidth]{images/network-normal} \caption{\label{blackholing-normal}Normalbetrieb: Blackholing inaktiv} \centering{Quelle: Eigene Abbildung} \end{figure} Wird eine \ac{VM} oder ein Server aus dem Internet über einen \ac{DDoS}-Angriff angegriffen, wird die Netzwerkinfrastruktur stark belastet. Dies kann zur Folge haben, dass das attackierte Ziel nicht mehr erreichbar ist, oder gänzlich den Dienst verweigert. \begin{figure}[H] \centering \includegraphics[width=\textwidth]{images/network-under-attack} \caption{\label{network-under-attack}Aktiver Angriff: Blackholing inaktiv} \centering{Quelle: Eigene Abbildung} \end{figure} Wird nun über den Route Injection Service eine Blackhole Route angelegt, injiziert ein Injector diese in den angebundenen internen Router. Dieser gibt die Routeninformationen dann über \ac{iBGP} an den Edge Router weiter. \begin{figure}[H] \centering \includegraphics[width=\textwidth]{images/network-under-attack-with-blackholing} \caption{\label{network-under-attack-with-blackholing}Aktiver Angriff: Blackholing aktiv} \centering{Quelle: Eigene Abbildung} \end{figure} Der grüne Pfeil stellt das Injizieren der Routen dar. Idealerweise wird der boshafte Datenverkehr schon am Router des \ac{ISP} verworfen. Dies setzt jedoch voraus, dass dieser RFC7999~\cite{rfc7999} implementiert hat und ein solches Routen Announcement zulässt. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \endinput %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%