diff --git a/Network Security - Cheatsheet.pdf b/Network Security - Cheatsheet.pdf index 027ba41..d8c2fe6 100644 --- a/Network Security - Cheatsheet.pdf +++ b/Network Security - Cheatsheet.pdf @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:830d4b89ae7003c703d9a00ccfcb039722e9e18fb9f2362802e8ba24a9fb8890 -size 1243895 +oid sha256:ef26a887ca305af2ce7e8d625200740a9bdfa08d162a6e5c406ce1c3d8ae1f34 +size 1266146 diff --git a/Network Security - Cheatsheet.tex b/Network Security - Cheatsheet.tex index 97b4a9b..bc24b54 100644 --- a/Network Security - Cheatsheet.tex +++ b/Network Security - Cheatsheet.tex @@ -2649,117 +2649,100 @@ \columnbreak \section{Integration von Sicherheitsdiensten in Kommunikationsarchitekturen} - \subsection{Motivation: Was ist wo zu tun?} \begin{itemize*} - \item Analog zur Methodik der Sicherheitsanalyse gibt es zwei Dimensionen, die bei der Integration von Sicherheitsdiensten in Kommunikationsarchitekturen zu beachten sind: + \item Analog zur Methodik der Sicherheitsanalyse gibt es zwei Dimensionen, die bei der Integration von Sicherheitsdiensten in Kommunikationsarchitekturen zu beachten sind \item Dimension 1: Welcher Sicherheitsdienst soll in welchem Knoten realisiert werden? - % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-Security-service-dim-1.png} + \includegraphics[width=.6\linewidth]{Assets/NetworkSecurity-Security-service-dim-1.png} \item Dimension 2: Welcher Sicherheitsdienst sollte in welcher Schicht realisiert werden? - % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-Security-service-dim-2.png} + \includegraphics[width=.6\linewidth]{Assets/NetworkSecurity-Security-service-dim-2.png} \end{itemize*} \subsection{Ein pragmatisches Modell für sicheres und vernetztes Rechnen} - \begin{itemize*} - %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-Sicheres-Netz-Modell.png} - \item Anwendung: Ein Stück Software, das eine bestimmte Aufgabe erfüllt, z.B. elektronische E-Mail, Webdienst, Textverarbeitung, Datenspeicherung usw. - \item Endsystem: - \begin{itemize*} - \item Ein Gerät, das vom Personal Computer über den Server bis zum Großrechner reicht. - \item Für Sicherheitszwecke hat ein Endsystem in der Regel eine einzige Richtlinienautorität. - \end{itemize*} - \item Teilnetz: - \begin{itemize*} - \item Eine Sammlung von Kommunikationseinrichtungen, die unter der Kontrolle einer Verwaltungsorganisation stehen, z.B. ein LAN, ein Campusnetz, ein WAN usw. - \item Für Sicherheitszwecke hat ein Teilnetz in der Regel eine Richtlinienkompetenz. - \end{itemize*} - \item Internet: - \begin{itemize*} - \item Eine Sammlung von miteinander verbundenen Teilnetzen - \item Im Allgemeinen haben die Teilnetze, die in einem Inter-Netzwerk verbunden sind, unterschiedliche Richtlinienautoritäten - \end{itemize*} - \item Es gibt vier Ebenen, auf denen unterschiedliche Anforderungen an Sicherheitsprotokollelemente gestellt werden: - \begin{itemize*} - \item Anwendungsebene: Sicherheitsprotokollelemente, die anwendungsabhängig sind - \item Endsystem-Ebene: Bereitstellung von Schutz auf einer Endsystem-zu-Endsystem-Basis - \item Teilnetzebene: Bereitstellung von Schutz über ein Teilnetz oder ein Zwischennetz, das als weniger sicher gilt als andere Teile der Netzumgebung - \item Verbindungsebene: Bereitstellung von Schutz innerhalb eines Teilnetzes, z.B. über eine Verbindung, die als weniger vertrauenswürdig gilt als andere Teile der Teilnetzumgebung - \end{itemize*} - \end{itemize*} + \begin{description*} + %\item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-secure-network-model.png} + \item[Anwendung] Ein Stück Software, das eine bestimmte Aufgabe erfüllt%, z.B. elektronische E-Mail, Webdienst, Textverarbeitung, Datenspeicherung + \item[Endsystem] Ein Gerät, das vom Personal Computer über den Server bis zum Großrechner reicht + %\item Für Sicherheitszwecke hat ein Endsystem in der Regel eine einzige Richtlinienautorität + \item[Teilnetz] Eine Sammlung von Kommunikationseinrichtungen, die unter der Kontrolle einer Verwaltungsorganisation stehen, z.B. LAN, Campusnetz + %\item Für Sicherheitszwecke hat ein Teilnetz in der Regel eine Richtlinienkompetenz + \item[Internet] Eine Sammlung von miteinander verbundenen Teilnetzen + %\item Im Allgemeinen haben die Teilnetze, die in einem Inter-Netzwerk verbunden sind, unterschiedliche Richtlinienautoritäten + \end{description*} + Es gibt vier Ebenen, auf denen unterschiedliche Anforderungen an Sicherheitsprotokollelemente gestellt werden + \begin{description*} + \item[Anwendungsebene] Sicherheitsprotokollelemente, die anwendungsabhängig sind + \item[Endsystem-Ebene] Bereitstellung von Schutz auf einer Endsystem-zu-Endsystem-Basis + \item[Teilnetzebene] Bereitstellung von Schutz über ein Teilnetz oder ein Zwischennetz, das als weniger sicher gilt als andere Teile der Netzumgebung + \item[Verbindungsebene] Bereitstellung von Schutz innerhalb eines Teilnetzes, z.B. über eine Verbindung, die als weniger vertrauenswürdig gilt als andere Teile der Teilnetzumgebung + \end{description*} \subsection{Beziehungen zwischen Schichten und Anforderungsniveaus} \begin{itemize*} \item Die Beziehungen zwischen den Protokollschichten und den Stufen der Sicherheitsanforderungen für die Protokollelemente sind nicht eins-zu-eins - \item Sicherheitsmechanismen, die sowohl die Anforderungen der Endsystem- als auch der Teilnetzebene erfüllen, können entweder in der Transport- und/oder in der Netzwerkschicht realisiert werden. - \item Die Anforderungen der Verbindungsebene können durch die Integration von Sicherheitsmechanismen oder durch die Verwendung von ,,speziellen Funktionen'' der Verbindungsschicht und/oder der physikalischen Schicht erfüllt werden. + \item Sicherheitsmechanismen, die sowohl die Anforderungen der Endsystem- als auch der Teilnetzebene erfüllen, können entweder in der Transport- und/oder in der Netzwerkschicht realisiert werden + \item Die Anforderungen der Verbindungsebene können durch die Integration von Sicherheitsmechanismen oder durch die Verwendung von ,,speziellen Funktionen'' der Verbindungsschicht und/oder der physikalischen Schicht erfüllt werden % \item \includegraphics[width=\linewidth]{Assets/NetworkSecurity-Layer-relationship.png} \end{itemize*} - \subsection{Allgemeine Überlegungen zur architektonischen Platzierung} + \subsection{Überlegungen zur architektonischen Platzierung} \begin{itemize*} - \item Verkehrsvermischung: + \item Verkehrsvermischung \begin{itemize*} \item Infolge des Multiplexing besteht auf niedrigeren Ebenen eine größere Tendenz, Datenelemente von verschiedenen Quell-/Ziel-Benutzern und/oder Anwendungen in einem Datenstrom zu vermischen - \item Ein Sicherheitsdienst, der auf einer Schicht/Ebene realisiert wird, behandelt den Verkehr dieser Schicht/Ebene gleich, was zu einer unzureichenden Kontrolle der Sicherheitsmechanismen für Benutzer und Anwendungen führt. + \item Ein Sicherheitsdienst, der auf einer Schicht/Ebene realisiert wird, behandelt den Verkehr dieser Schicht/Ebene gleich, was zu einer unzureichenden Kontrolle der Sicherheitsmechanismen für Benutzer und Anwendungen führt \item Wenn eine Sicherheitspolitik eine differenziertere Behandlung erfordert, sollte sie besser auf einer höheren Ebene realisiert werden \end{itemize*} - \item Wissen über die Route: + \item Wissen über die Route \begin{itemize*} - \item Auf niedrigeren Ebenen ist in der Regel mehr Wissen über die Sicherheitseigenschaften der verschiedenen Routen und Verbindungen vorhanden. + \item Auf niedrigeren Ebenen ist in der Regel mehr Wissen über die Sicherheitseigenschaften der verschiedenen Routen und Verbindungen vorhanden \item In Umgebungen, in denen diese Merkmale stark variieren, kann die Platzierung von Sicherheit auf niedrigeren Ebenen Vorteile in Bezug auf Effektivität und Effizienz haben - \item Geeignete Sicherheitsdienste können auf der Basis von Teilnetzen oder Verbindungen ausgewählt werden, so dass keine Kosten für Sicherheit anfallen, wenn der Schutz unnötig ist. + \item Geeignete Sicherheitsdienste können auf der Basis von Teilnetzen oder Verbindungen ausgewählt werden, so dass keine Kosten für Sicherheit anfallen, wenn der Schutz unnötig ist \end{itemize*} - \item Anzahl der Schutzpunkte: + \item Anzahl der Schutzpunkte \begin{itemize*} - \item Wenn die Sicherheit auf der Anwendungsebene angesiedelt wird, muss die Sicherheit in jeder sensiblen Anwendung und jedem Endsystem implementiert werden. - \item Sicherheit auf der Verbindungsebene bedeutet, dass am Ende jeder Netzverbindung, die als weniger vertrauenswürdig gilt, Sicherheit implementiert werden muss. - \item Wenn die Sicherheit in der Mitte der Architektur angesiedelt wird, müssen die Sicherheitsmerkmale an weniger Stellen installiert werden. + \item Wenn die Sicherheit auf der Anwendungsebene angesiedelt wird, muss die Sicherheit in jeder sensiblen Anwendung und jedem Endsystem implementiert werden + \item Sicherheit auf der Verbindungsebene bedeutet, dass am Ende jeder Netzverbindung, die als weniger vertrauenswürdig gilt, Sicherheit implementiert werden muss + \item Wenn die Sicherheit in der Mitte der Architektur angesiedelt wird, müssen die Sicherheitsmerkmale an weniger Stellen installiert werden \end{itemize*} - \item Schutz der Protokoll-Header: + \item Schutz der Protokoll-Header \begin{itemize*} - \item Der Sicherheitsschutz auf höheren Ebenen kann die Protokollköpfe der unteren Protokollschichten nicht schützen. - \item Die Netzwerkinfrastruktur muss möglicherweise ebenfalls geschützt werden. + \item Der Sicherheitsschutz auf höheren Ebenen kann die Protokollköpfe der unteren Protokollschichten nicht schützen + \item Die Netzwerkinfrastruktur muss möglicherweise ebenfalls geschützt werden \end{itemize*} - \item Quelle/Senke-Bindung: + \item Quelle/Senke-Bindung \begin{itemize*} - \item Sicherheitsdienste wie die Authentifizierung der Datenherkunft und die Unleugbarkeit hängen von der Zuordnung der Daten zu ihrer Quelle oder Senke ab. - \item Dies wird am effizientesten auf höheren Ebenen erreicht, insbesondere auf der Anwendungsebene. + \item Sicherheitsdienste wie die Authentifizierung der Datenherkunft und die Unleugbarkeit hängen von der Zuordnung der Daten zu ihrer Quelle oder Senke ab + \item Dies wird am effizientesten auf höheren Ebenen erreicht, insbesondere auf der Anwendungsebene \end{itemize*} \end{itemize*} \subsection{Überlegungen zu bestimmten Ebenen} \begin{itemize*} - \item Anwendungsebene: + \item Anwendungsebene \begin{itemize*} - \item Diese Stufe kann die einzige geeignete Stufe sein, zum Beispiel weil: - \begin{itemize*} - \item Ein Sicherheitsdienst ist anwendungsspezifisch, z.B. die Zugriffskontrolle für einen vernetzten Dateispeicher - \item Ein Sicherheitsdienst muss Anwendungs-Gateways durchqueren, z.B. Integrität und/oder Vertraulichkeit von elektronischer Post - \item Die Semantik der Daten ist wichtig, z.B. für Nichtabstreitbarkeitsdienste - Es liegt außerhalb der Reichweite eines Benutzers/Anwendungsprogrammierers, Sicherheit auf einer niedrigeren Ebene zu integrieren - \end{itemize*} + \item Diese Stufe kann die einzige geeignete Stufe sein + \item Ein Sicherheitsdienst ist anwendungsspezifisch%, z.B. die Zugriffskontrolle für einen vernetzten Dateispeicher + \item Ein Sicherheitsdienst muss Anwendungs-Gateways durchqueren%, z.B. Integrität und/oder Vertraulichkeit von elektronischer Post + \item Die Semantik der Daten ist wichtig, z.B. für Nichtabstreitbarkeitsdienste %- Es liegt außerhalb der Reichweite eines Benutzers/Anwendungsprogrammierers, Sicherheit auf einer niedrigeren Ebene zu integrieren \end{itemize*} - \item Endsystem-Ebene: + \item Endsystemebene \begin{itemize*} - \item Diese Ebene ist geeignet, wenn davon ausgegangen wird, dass die Endsysteme vertrauenswürdig sind und das Kommunikationsnetz als nicht vertrauenswürdig angesehen wird. - \item Weitere Vorteile der Sicherheit auf Endsystemebene: - \begin{itemize*} - \item Die Sicherheitsdienste sind für die Anwendungen transparent. - \item Die Verwaltung von Sicherheitsdiensten kann leichter in die Hände eines Systemadministrators gelegt werden. - \end{itemize*} + \item Diese Ebene ist geeignet, wenn davon ausgegangen wird, dass die Endsysteme vertrauenswürdig sind und das Kommunikationsnetz als nicht vertrauenswürdig angesehen wird + \item Die Sicherheitsdienste sind für die Anwendungen transparent + \item Die Verwaltung von Sicherheitsdiensten kann leichter in die Hände eines Systemadministrators gelegt werden \end{itemize*} - \item Teilnetzebene: + \item Teilnetzebene \begin{itemize*} - \item Auch wenn die auf dieser Ebene implementierte Sicherheit in der gleichen Protokollschicht wie auf der Endsystemebene implementiert werden kann, sollten diese nicht verwechselt werden: - \begin{itemize*} - \item Mit der auf der Subnetzebene implementierten Sicherheit wird in der Regel der gleiche Schutz für alle Endsysteme dieses Subnetzes realisiert - \end{itemize*} - \item Es ist sehr üblich, dass ein Teilnetz in der Nähe eines Endsystems als ebenso vertrauenswürdig angesehen wird, da es sich in denselben Räumlichkeiten befindet und von denselben Behörden verwaltet wird. - \item In den meisten Fällen gibt es weit weniger zu sichernde Teilnetz-Gateways als Endsysteme. + \item Auch wenn die auf dieser Ebene implementierte Sicherheit in der gleichen Protokollschicht wie auf der Endsystemebene implementiert werden kann, sollten diese nicht verwechselt werden + \item Mit der auf der Subnetzebene implementierten Sicherheit wird in der Regel der gleiche Schutz für alle Endsysteme dieses Subnetzes realisiert + \item Es ist sehr üblich, dass ein Teilnetz in der Nähe eines Endsystems als ebenso vertrauenswürdig angesehen wird, da es sich in denselben Räumlichkeiten befindet und von denselben Behörden verwaltet wird + \item In den meisten Fällen gibt es weit weniger zu sichernde Teilnetz-Gateways als Endsysteme \end{itemize*} - \item Verbindungsebene: + \item Verbindungsebene \begin{itemize*} - \item Wenn es relativ wenige nicht vertrauenswürdige Verbindungen gibt, kann es ausreichend und zudem einfacher und kostengünstiger sein, das Netz auf der Verbindungsebene zu schützen. - \item Darüber hinaus können auf der Verbindungsebene spezielle Schutztechniken eingesetzt werden, z.B. Spreizspektrum oder Frequenzsprungverfahren. - \item Die Vertraulichkeit des Verkehrsflusses erfordert in der Regel einen Schutz auf Verbindungsebene. + \item Wenn es relativ wenige nicht vertrauenswürdige Verbindungen gibt, kann es ausreichend und zudem einfacher und kostengünstiger sein, das Netz auf der Verbindungsebene zu schützen + \item Darüber hinaus können auf der Verbindungsebene spezielle Schutztechniken eingesetzt werden %z.B. Spreizspektrum oder Frequenzsprungverfahren. + \item Die Vertraulichkeit des Verkehrsflusses erfordert in der Regel einen Schutz auf Verbindungsebene \end{itemize*} \end{itemize*} @@ -2769,60 +2752,44 @@ \item Solche Interaktionen passen in keine der bisher vorgestellten Architekturoptionen, da der Benutzer außerhalb der Kommunikationseinrichtungen steht. \item Die Kommunikation zur Unterstützung der Authentifizierung kann auf eine der folgenden Weisen erfolgen: \begin{itemize*} - \item Örtlich: + \item Örtlich \begin{itemize*} \item Der menschliche Benutzer authentifiziert sich gegenüber dem lokalen Endsystem \item Das Endsystem authentifiziert sich gegenüber dem entfernten Endsystem und teilt die Identität des Benutzers mit \item Das entfernte System muss dem lokalen Endsystem vertrauen \end{itemize*} - \item Unter Einbeziehung von Protokollelementen auf der Anwendungsschicht: + \item Unter Einbeziehung von Protokollelementen auf der Anwendungsschicht \begin{itemize*} \item Der Benutzer gibt einige Authentifizierungsinformationen an das lokale System weiter, die sicher an das entfernte System weitergeleitet werden \end{itemize*} - \item Kombination der oben genannten Mittel. Beispiel: Kerberos + \item Kombination der oben genannten Mittel, Bsp Kerberos \end{itemize*} \end{itemize*} \subsection{Integration in untere Protokollschichten vs. Anwendungen} - \begin{itemize*} - \item Vorteile der Integration von Sicherheitsdiensten in niedrigere Netzwerkschichten - \item Sicherheit: - \begin{itemize*} - \item Auch das Netz selbst muss geschützt werden - \item Sicherheitsmechanismen, die in den Netzelementen (insbesondere in der Hardware) realisiert sind, sind für die Netznutzer oft schwerer angreifbar - \end{itemize*} - \item Anwendungsunabhängigkeit: - \begin{itemize*} - \item Grundlegende Netzsicherheitsdienste müssen nicht in jede einzelne Anwendung integriert werden - \end{itemize*} - \item Dienstgüte (QoS): - \begin{itemize*} - \item Die QoS-erhaltende Planung des Kommunikationssubsystems kann auch die Verschlüsselung nebeneinander bestehender Datenströme planen. - \item Beispiel: gleichzeitiger Sprachanruf und FTP-Übertragung - \end{itemize*} - \item Effizienz: - \begin{itemize*} - \item Hardware-Unterstützung für rechenintensive Ver-/Entschlüsselung kann leichter in die Protokollverarbeitung integriert werden - \end{itemize*} - \end{itemize*} + Vorteile der Integration von Sicherheitsdiensten in niedrigere Netzwerkschichten + \begin{description*} + \item[Sicherheit] Auch das Netz selbst muss geschützt werden + \item[] Sicherheitsmechanismen, die in den Netzelementen (insbesondere in der Hardware) realisiert sind, sind für die Netznutzer oft schwerer angreifbar + \item[Anwendungsunabhängigkeit] Grundlegende Netzsicherheitsdienste müssen nicht in jede einzelne Anwendung integriert werden + \item[Dienstgüte (QoS)] Die QoS-erhaltende Planung des Kommunikationssubsystems kann auch die Verschlüsselung nebeneinander bestehender Datenströme planen + %\item Beispiel: gleichzeitiger Sprachanruf und FTP-Übertragung + \item[Effizienz] Hardware-Unterstützung für rechenintensive Ver-/Entschlüsselung kann leichter in die Protokollverarbeitung integriert werden + \end{description*} \subsection{Integration in Endsysteme vs. Zwischensysteme} + Integration in Endsysteme \begin{itemize*} - \item Integration in Endsysteme: - \begin{itemize*} - \item Kann im Allgemeinen entweder auf der Anwendungs- oder der Endsystemebene erfolgen - \item In einigen speziellen Fällen kann auch ein Schutz auf Verbindungsebene angebracht sein, z.B. bei der Verwendung eines Modems zur Verbindung mit einem bestimmten Gerät - \end{itemize*} - \item Integration in Zwischensysteme - \begin{itemize*} - \item Kann auf allen vier Ebenen erfolgen: - \begin{itemize*} - \item Anwendungs-/,,Endsystem,,-Ebene: zur Sicherung der Verwaltungsschnittstellen von Zwischenknoten, nicht zur Sicherung des Nutzdatenverkehrs - \item Teilnetz-/Link-Ebene: zur Sicherung des Nutzdatenverkehrs - \end{itemize*} - \end{itemize*} - \item Je nach den Sicherheitszielen kann eine Integration sowohl in Endsystemen als auch in Zwischensystemen sinnvoll sein + \item Kann im Allgemeinen entweder auf der Anwendungs- oder der Endsystemebene erfolgen + \item In einigen speziellen Fällen kann auch ein Schutz auf Verbindungsebene angebracht sein, z.B. Modem %bei der Verwendung eines Modems zur Verbindung mit einem bestimmten Gerät \end{itemize*} + Integration in Zwischensysteme + \begin{itemize*} + \item Kann auf allen vier Ebenen erfolgen + \item Anwendungs-/Endsystem-Ebene: zur Sicherung der Verwaltungsschnittstellen von Zwischenknoten, nicht zur Sicherung des Nutzdatenverkehrs + \item Teilnetz-/Link-Ebene: zur Sicherung des Nutzdatenverkehrs + \end{itemize*} + Je nach den Sicherheitszielen kann eine Integration sowohl in Endsystemen als auch in Zwischensystemen sinnvoll sein %\subsection{Beispiel: Authentifizierungsbeziehungen in Inter-Netzwerken} % \includegraphics[width=\linewidth]{Assets/NetworkSecurity-Authentication-relation-in-inter-networks.png} @@ -2852,9 +2819,10 @@ \begin{itemize*} \item Anwendungs-/Endsystem-/Subnetz-/Link-Ebene \end{itemize*} - \item Da es verschiedene Gründe für und gegen jede Option gibt, gibt es keine einheitliche Lösung für dieses Designproblem. - \item In diesem Kurs werden wir daher einige Beispiele für die Integration von Sicherheitsdiensten in Netzarchitekturen untersuchen, um die Auswirkungen der getroffenen Designentscheidungen besser zu verstehen + \item Da es verschiedene Gründe für und gegen jede Option gibt, gibt es keine einheitliche Lösung für dieses Designproblem + %\item In diesem Kurs werden wir daher einige Beispiele für die Integration von Sicherheitsdiensten in Netzarchitekturen untersuchen, um die Auswirkungen der getroffenen Designentscheidungen besser zu verstehen \end{itemize*} + \columnbreak \section{Sicherheitsprotokolle der Datenübertragungsschicht} \begin{itemize*}