Big restructure part 1
This commit is contained in:
parent
6bcf002889
commit
cdab9397d5
131
MA-Inhalt.tex
131
MA-Inhalt.tex
|
|
@ -600,25 +600,79 @@ Für die Bereitstellung der öffentlichen Daten der PKI wird ein Apache httpd al
|
|||
Damit die CRL der PKI aktualisiert wird, wird ein Cronjob auf dem CA-Server eingerichtet, der diese Aufgabe übernimmt und die aktuelle CRL anschließend über den Webserver veröffentlicht.
|
||||
Auf dem VPN-Server kommt ein weiterer Cronjob zum Einsatz, um die aktuelle CRL vom Webserver auf dem CA-Server zu beschaffen und in die Konfiguration des OpenVPN-Servers zu integrieren.
|
||||
|
||||
Firewallregeln.
|
||||
|
||||
\begin{draft}
|
||||
\paragraph{Konfigurationsplanung für OpenVPN:}
|
||||
\section{OpenVPN-Server} \label{sct:plan_openvpn_server}
|
||||
In diesem Abschnitt werden die in Kapitel~\ref{cpt:service_concept} bereits beschlossenen Konzepte für den VPN-Dienst auf die gewählte VPN-Software OpenVPN zugeschnitten.
|
||||
Die durch OpenVPN gegebenen Funktionen und Einschränkungen werden hierbei berücksichtigt, um später eine funktionsfähige Konfiguration für OpenVPN aus dieser Planung abzuleiten.
|
||||
|
||||
Als Transportprotokoll kommt UDP zum Einsatz.
|
||||
\paragraph{VPN-Transportprotokoll:}
|
||||
OpenVPN bietet UDP und TCP als mögliche Transportprotokolle für den VPN-Datenverkehr an.
|
||||
Für diesen VPN-Dienst wird das UDP-Protokoll gewählt, weil das TCP-Protokoll in Kombination mit stark ausgelasteten Netzwerken oder beim Transport von TCP-Paketen durch den VPN-Tunnel Performanceeinbußen verursachen kann \cite[][Option \texttt{--proto}]{man:openvpn}.
|
||||
Bei Interesse kann eine detaillierte Analyse der Probleme der TCP-in-TCP-Situation in \cite[][]{analysis:tcpintcp} nachgelesen werden.
|
||||
|
||||
Der VPN-Tunnel überträgt Datenverkehr auf OSI-Schicht~3.
|
||||
\paragraph{OSI-Schicht des VPN-Tunnels:}
|
||||
OpenVPN unterstützt den Aufbau eines VPN-Tunnels auf OSI-Schicht~2 und OSI-Schicht~3.
|
||||
Im Prinzip könnten beide Tunnelvarianten für den Anwendungsfall dieser Arbeit verwendet werden.
|
||||
Da im Rahmen dieser Arbeit nur die Erreichbarkeit über IPv4 und IPv6 relevant ist, wird ein VPN-Tunnel auf OSI-Schicht~2 nicht benötigt.
|
||||
Zusätzlich würde ein VPN-Tunnel auf OSI-Schicht~2 mehr Bandbreite benötigen: IP-Pakete würden inklusive der dazugehörigen Ethernet-Frames übermittelt.
|
||||
Aus diesen Gründen fällt die Wahl auf VPN-Tunnel auf OSI-Schicht~3.
|
||||
|
||||
Verschlüsselung von Datenverkehr mit TLS-Chiffre und so - keine Verhandlungen, alles statisch.
|
||||
Warum?
|
||||
\paragraph{Kompression des VPN-Verkehrs:}
|
||||
Auf die Kompression des VPN-Datenverkehrs wird aufgrund der in diesem Absatz aufgeführten Punkte verzichtet.
|
||||
Am 03.06.2018 wurden Hinweise in der Manpage von OpenVPN eingefügt\footnote{\url{https://github.com/OpenVPN/openvpn/commit/6795a5f3d55f658fc1a28eb9f3b11d1217e3329c}}, in denen vor der Verwendung von Kompression gewarnt wird.
|
||||
Diese Hinweise sind in der Manpage von OpenVPN in Version~2.4.6 noch nicht enthalten, da diese Version von den Entwicklern bereits am 19.04.2018\footnote{\url{https://github.com/OpenVPN/openvpn/releases/tag/v2.4.6}} freigegeben wurde.
|
||||
Zusätzlich wird in der \enquote{Best Current Practice} RFC~7525 zur Deaktivierung der Kompression von TLS geraten \cite[Vergleich][Kapitel 3.3]{RFC7525}.
|
||||
|
||||
TLS-Rolle für Server/Client
|
||||
Auf der DEFCON~26 wurde mit \enquote{VORACLE} ein in diesem Kontext relevanter Angriff auf OpenVPN vorgestellt\footnote{\url{https://media.defcon.org/DEF\%20CON\%2026/DEF\%20CON\%2026\%20presentations/Nafeez/DEFCON-26-Nafeez-Compression-Oracle-attacks-on-VPN-Networks.pdf}}, der auf aktivierter Kompression aufbaut.
|
||||
|
||||
\paragraph{Kryptografische Parameter:}
|
||||
Wie in Kapitel~\ref{ssct:openvpn} bereits erläutert wurde, unterscheidet OpenVPN bei der Kommunikation zwischen zwei OpenVPN-Prozessen zwischen Datenkanal für Nutzdaten und Kontrollkanal für Steuernachrichten.
|
||||
Während OpenVPN im TLS-Modus über den Kontrollkanal den TLS-Sitzungsaufbau durchführt und den Kontrollkanal anschließend über TLS absichert, wird für den Datenkanal eine separat konfigurierbare, symmetrische Chiffre verwendet.
|
||||
Das gemeinsame Geheimnis für den Schutz des Datenkanals wird dabei über den durch TLS geschützten Kontrollkanal ausgetauscht.
|
||||
Mit den in diese Absatz definierten Parametern soll die Kommunikation zwischen Clients und Server unabhängig von den verwendeten Betriebssystemen einheitlich geschützt werden.
|
||||
|
||||
Die TLS-Kommunikation wird nach Empfehlung des BSI über TLS-Version~1.2 oder höher durchgeführt \cite[][Abschnitt 2.3]{bsi:tls-checkliste}.
|
||||
Zur Absicherung des Kontrollkanals wird die TLS-Chiffre \texttt{TLS-DHE-RSA-WITH-AES-256-GCM-SHA384} ausgewählt.
|
||||
|
||||
Diese Chiffre verwendet \textit{Ephemeral Diffie Hellman} (DHE) für den Schlüsselaustausch \cite[][Abschnitt A.5]{RFC5246}, RSA als Signaturalgorithmus zur Authentisierung \cite[][Abschnitt A.5]{RFC5246}, AES-256-GCM für die Verschlüsselung und SHA384 als Funktion für Pseudozufallszahlen für den \textit{Keyed-Hash Message Authentication Code} (HMAC) \cite[][Kapitel 5]{RFC5246}.
|
||||
Durch die Verwendung von DHE kann \textit{Perfect Forward Secrecy} (PFS) gewährleistet werden \cite[][Abschnitt F.1.1.2]{RFC5246}.
|
||||
|
||||
Die gewählte TLS-Chiffre stammt aus der Liste der empfohlenen Chiffren in RFC~7525 \cite[][Abschnitt 4.2]{RFC7525}.
|
||||
Laut BSI kann diese Chiffre durch Dienstanbieter optional unterstützt werden \cite[][Kapitel 3]{bsi:tls-checkliste}.
|
||||
Die eng verwandte Chiffre TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 setzt PFS mit ECDHE anstelle von DHE um, und wird laut BSI für Dienstanbieter empfohlen \cite[][Kapitel 3]{bsi:tls-checkliste}, wodurch sich unter der Voraussetzung, dass ECDHE und DHE einen vergleichbar sicheren Schlüsselaustausch ermöglichen, auch für die gewählte TLS-Chiffre eine Eignung für die langfristige Verwendung ableiten lässt.
|
||||
Diese Voraussetzung wird durch einen aktuellen Bericht der ECRYPT-CSA\footnote{Siehe \url{http://www.ecrypt.eu.org/csa/}} vom Februar 2018 untermauert diese Voraussetzung \cite[][Kapitel 8.1]{ecrypt-csa:algorithms}.
|
||||
|
||||
\textbf{Anmerkung}: TLS-Chiffren mit Ephemeral-Diffie-Hellman-Verfahren auf Basis von elliptischen Kurven (ECDHE) können im Rahmen dieser Arbeit nicht verwendet werden.
|
||||
Grund dafür sind Kompatibilitätsprobleme zwischen OpenVPN und OpenSSL~1.1.x auf der Clientseite\footnote{Siehe \url{https://community.openvpn.net/openvpn/ticket/963}}.
|
||||
|
||||
OpenVPN verwendet einen HMAC mit einem zuvor ausgetauschtem, gemeinsamen Geheimnis um für Daten- und Kontrollkanal eingehende Datenpakete vor ihrer Verarbeitung zu authentisieren.
|
||||
Die im HMAC als Quelle für Pseudozufallszahlen verwendete Hashfunktion wird auf SHA-256 festgelegt, weil SHA-1, trotz seiner weiterhin bestehenden theoretischen Eignung zur Verwendung in einem HMAC, laut BSI nicht mehr verwendet werden sollte \cite[][Abschnitt 1.4, Punkt 3]{bsi:tr-02102-1}.
|
||||
|
||||
Für die Verschlüsselung des Datenkanals wird auf Basis der zuvor gewählten TLS-Chiffre die Chiffre AES-256-GCM ausgewählt.
|
||||
Diese Chiffre ist eine \textit{Authenticated Encryption with Associated Data} (AEAD)-Chiffre.
|
||||
Deshalb wird die Authentisierungsfunktion der Chiffre anstelle der zuvor beschriebenen HMAC-Funktion für den Datenkanal benutzt \cite[][Option \texttt{--auth}]{man:openvpn}.
|
||||
|
||||
Durch die Verwendung der selben Chiffre zur Verschlüsselung von Daten- und Kontrollkanal muss ein Angreifer für einen erfolgreichen Angriff - egal auf welchen Kanal - diese Chiffre brechen.
|
||||
Gelingt es einem Angreifer den Kontrollkanal zu dechiffrieren, so erhält er Kenntnis über die Schlüssel, mit denen der Datenkanal verschlüsselt wird.
|
||||
Gelingt es einem Angreifer den Kontrollkanal zu dechiffrieren, so erhält er Kenntnis über alle übertragenen Daten.
|
||||
Die Vertraulichkeit der über den VPN-Dienst übertragenen Daten hängt demnach von der Verschlüsselung beider Kanäle ab.
|
||||
Der logische Schluss daraus ist die Verwendung der selben Chiffre zur Verschlüsselung beider Kanäle.
|
||||
|
||||
Damit alle VPN-Sitzungen die zuvor erläuterten, kryptografischen Parametern einhalten, werden diese Parameter in Client- und Serverkonfiguration hinterlegt.
|
||||
Zusätzlich wird die Aushandlung der Chiffren auf dem OpenVPN-Server explizit deaktiviert, um unsichere VPN-Sitzungen zu verhindern.
|
||||
|
||||
\textbf{Erweiterbarkeit:} Sollten die hier gewählten, kryptografischen Parameter einzeln oder insgesamt nicht mehr als sicher gelten, so sollten \textbf{alle} diese Parameter nach aktuellem Stand der Technik und unter Berücksichtigung der verschiedenen Clientbetriebssysteme neu ausgewählt werden.
|
||||
In diesem Zuge ist es notwendig, alle aktiven VPN-Benutzer über die Änderungen der Parameter zu benachrichtigen und eine aktuelle Vorlage für die OpenVPN-Clientkonfiguration bereitzustellen.
|
||||
|
||||
Dieser Ansatz wird gewählt, damit (1) all VPN-Sitzungen einheitlich geschützt werden, und (2) zusätzliche Komplexität durch flexible Verwendung von Chiffren und deren Aushandlung vermieden wird.
|
||||
|
||||
Keine Kompression aus Sicherheitsgründen
|
||||
|
||||
|
||||
Es sollen Routen in Netze gepusht werden; es sollen Routen aus dem alten VPN-Dienst übernommen werden für die Aufwärtskompatibilität; IPV6-Netze sollen dann hinzugefügt werden.
|
||||
\end{draft}
|
||||
|
||||
|
||||
\section{PKI-Server} \label{sct:plan_pki_server}
|
||||
|
||||
|
||||
|
||||
\chapter{Konfiguration des OpenVPN-Servers} \label{cpt:implement_vpn_server}
|
||||
|
|
@ -695,15 +749,8 @@ proto udp
|
|||
remote vpn-test.inform.hs-hannover.de 1194
|
||||
\end{lstlisting}
|
||||
|
||||
Das UDP-Protokoll wird verwendet, weil das TCP-Protokoll in Kombination mit stark ausgelasteten Netzwerken oder beim Transport von TCP-Paketen durch den VPN-Tunnel Performanceeinbußen verursachen kann \cite[][Option \texttt{--proto}]{man:openvpn}.
|
||||
Bei Interesse kann eine detaillierte Analyse der Probleme der TCP-in-TCP-Situation in \cite[][]{analysis:tcpintcp} nachgelesen werden.
|
||||
|
||||
\paragraph{OSI-Schicht des VPN-Tunnels:}
|
||||
OpenVPN unterstützt den Aufbau eines VPN-Tunnels auf OSI-Schicht~2 und OSI-Schicht~3.
|
||||
Im Prinzip könnten beide Tunnelvarianten für den Anwendungsfall dieser Arbeit verwendet werden.
|
||||
Da im Rahmen dieser Arbeit nur die Erreichbarkeit über IPv4 und IPv6 relevant ist, wird ein VPN-Tunnel auf OSI-Schicht~2 nicht benötigt.
|
||||
Zusätzlich würde ein VPN-Tunnel auf OSI-Schicht~2 mehr Bandbreite benötigen: IP-Pakete würden inklusive der dazugehörigen Ethernet-Frames übermittelt.
|
||||
Aus diesen Gründen fällt die Wahl auf VPN-Tunnel auf OSI-Schicht~3 und wird mit der folgenden Anweisung in \textbf{Client- und Serverkonfiguration} eingestellt.
|
||||
In \textbf{Client- und Serverkonfiguration} wird mit angegeben, dass eine virtuelle Netzwerkkarte auf OSI-Schicht~3 als Endpunkt für das VPN verwendet wird:
|
||||
\begin{lstlisting}
|
||||
dev tun
|
||||
\end{lstlisting}
|
||||
|
|
@ -755,14 +802,6 @@ push "route-ipv6 2001:638:614:1744::/64 2001:638:614:1750::1" # experimental ipv
|
|||
\end{lstlisting}
|
||||
Da der Platzhalter \texttt{vpn\_gateway} für IPv6-Routen leider nicht funktioniert, muss hier die IPv6-Adresse des VPN-Servers im VPN direkt als Ziel der Route angegeben werden.
|
||||
|
||||
\paragraph{Kompression:}
|
||||
Auf die Kompression des VPN-Datenverkehrs wird aufgrund der in diesem Absatz aufgeführten Punkte verzichtet.
|
||||
Am 03.06.2018 wurden Hinweise in der Manpage von OpenVPN eingefügt\footnote{\url{https://github.com/OpenVPN/openvpn/commit/6795a5f3d55f658fc1a28eb9f3b11d1217e3329c}}, in denen vor der Verwendung von Kompression gewarnt wird.
|
||||
Diese Hinweise sind in der Manpage von OpenVPN in Version~2.4.6 noch nicht enthalten, da diese Version von den Entwicklern bereits am 19.04.2018\footnote{\url{https://github.com/OpenVPN/openvpn/releases/tag/v2.4.6}} freigegeben wurde.
|
||||
Zusätzlich wird in der \enquote{Best Current Practice} RFC~7525 zur Deaktivierung der Kompression von TLS geraten \cite[Vergleich][Kapitel 3.3]{RFC7525}.
|
||||
|
||||
Auf der DEFCON~26 wurde mit \enquote{VORACLE} ein in diesem Kontext relevanter Angriff auf OpenVPN vorgestellt\footnote{\url{https://media.defcon.org/DEF\%20CON\%2026/DEF\%20CON\%2026\%20presentations/Nafeez/DEFCON-26-Nafeez-Compression-Oracle-attacks-on-VPN-Networks.pdf}}, der auf aktivierter Kompression aufbaut.
|
||||
|
||||
\paragraph{Zertifikatgestützte Authentisierung:}
|
||||
Um die in Kapitel~\ref{sct:user_concept} beschriebene Zertifizierungsstelle zur Benutzerauthentisierung zu verwenden und die VPN-Kommunikation nach Anforderung~\ref{req:traffic} aus Kapitel~\ref{par:requirements} abzusichern, wird OpenVPN im TLS-Modus betrieben.
|
||||
|
||||
|
|
@ -788,53 +827,29 @@ remote-cert-tls client
|
|||
\end{lstlisting}
|
||||
|
||||
\paragraph{Kryptografische Parameter:}
|
||||
Wie in Kapitel~\ref{ssct:openvpn} bereits erläutert wurde, unterscheidet OpenVPN bei der Kommunikation zwischen zwei OpenVPN-Prozessen zwischen Datenkanal für Nutzdaten und Kontrollkanal für Steuernachrichten.
|
||||
Während OpenVPN im TLS-Modus über den Kontrollkanal den TLS-Sitzungsaufbau durchführt und den Kontrollkanal anschließend über TLS absichert, wird für den Datenkanal eine separat konfigurierbare, symmetrische Chiffre verwendet.
|
||||
Das gemeinsame Geheimnis für den Schutz des Datenkanals wird dabei über den durch TLS geschützten Kontrollkanal ausgetauscht.
|
||||
Mit den in diese Absatz definierten Parametern soll die Kommunikation zwischen Clients und Server unabhängig von den verwendeten Betriebssystemen einheitlich geschützt werden.
|
||||
Um Konfigurationsprobleme durch abweichende Konfiguration von Client und Server auszuschließen, werden alle folgenden Parameter in \textbf{Client- und Serverkonfiguration} eingetragen.
|
||||
|
||||
Die TLS-Kommunikation wird nach Empfehlung des BSI über TLS-Version~1.2 oder höher durchgeführt \cite[][Abschnitt 2.3]{bsi:tls-checkliste}.
|
||||
Die TLS-Kommunikation wird über TLS Version~1.2 oder höher durchgeführt:
|
||||
\begin{lstlisting}
|
||||
tls-version-min "1.2"
|
||||
\end{lstlisting}
|
||||
|
||||
\todo{ECRYPT-CSA integrieren.}
|
||||
|
||||
Der letzte Bericht der ENISA\footnote{Siehe \url{https://www.enisa.europa.eu/about-enisa}} zu Algorithmen, Schlüssellängen und Protokollen von 2014 \cite[][]{enisa:algorithms} wird durch einen aktuellen Nachfolger \cite[][]{ecrypt-csa:algorithms} der ECRYPT-CSA\footnote{Siehe \url{http://www.ecrypt.eu.org/csa/}} vom Februar 2018 abgelöst \cite[][Kapitel 1, \enquote{Executive Summary}]{ecrypt-csa:algorithms}.
|
||||
Empfehlungen zu TLS finden sich in \cite[][Kapitel 8.1]{ecrypt-csa:algorithms}.
|
||||
|
||||
Aus der Liste der in RFC~7525 empfohlenen Chiffren \cite[][Abschnitt 4.2]{RFC7525} wird die TLS-Chiffre TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 gewählt.
|
||||
Diese Chiffre verwendet \textit{Ephemeral Diffie Hellman} (DHE) für den Schlüsselaustausch \cite[][Abschnitt A.5]{RFC5246}, RSA als Signaturalgorithmus zur Authentisierung \cite[][Abschnitt A.5]{RFC5246}, AES-256-GCM für die Verschlüsselung und SHA384 als Funktion für Pseudozufallszahlen für den \textit{Keyed-Hash Message Authentication Code} (HMAC) \cite[][Kapitel 5]{RFC5246}.
|
||||
|
||||
Durch die Verwendung von DHE kann \textit{Perfect Forward Secrecy} (PFS) gewährleistet werden \cite[][Abschnitt F.1.1.2]{RFC5246}.
|
||||
|
||||
Die gewählte Chiffre kann vom BSI \cite[][Kapitel 3]{bsi:tls-checkliste} durch Dienstanbieter optional unterstützt werden.
|
||||
Die eng verwandte Chiffre TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 setzt PFS mit ECDHE anstelle von DHE um und wird laut BSI für Dienstanbieter empfohlen \cite[][Kapitel 3]{bsi:tls-checkliste}.
|
||||
|
||||
\textbf{Anmerkung}: TLS-Chiffren mit Ephemeral-Diffie-Hellman-Verfahren auf Basis von elliptischen Kurven (ECDHE) können im Rahmen dieser Arbeit nicht verwendet werden.
|
||||
Grund dafür sind Kompatibilitätsprobleme zwischen OpenVPN und OpenSSL~1.1.x auf der Clientseite\footnote{Siehe \url{https://community.openvpn.net/openvpn/ticket/963}}.
|
||||
|
||||
Somit wird die zuvor genannte TLS-Chiffre mit DHE-Verfahren verwendet:
|
||||
Die für den Kontrollkanal verwendete TLS-Chiffre wird konfiguriert:
|
||||
\begin{lstlisting}
|
||||
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
|
||||
\end{lstlisting}
|
||||
|
||||
OpenVPN verwendet einen HMAC mit einem zuvor ausgetauschtem, gemeinsamen Geheimnis um für Daten- und Kontrollkanal eingehende Datenpakete vor ihrer Verarbeitung zu authentisieren.
|
||||
|
||||
Die im HMAC als Quelle für Pseudozufallszahlen verwendete Hashfunktion wird auf SHA-256 festgelegt, weil SHA-1, trotz seiner weiterhin bestehenden theoretischen Eignung zur Verwendung in einem HMAC, laut BSI nicht mehr verwendet werden sollte \cite[][Abschnitt 1.4, Punkt 3]{bsi:tr-02102-1}.
|
||||
Als Quelle für Pseudozufallszahlen im HMAC für Kontroll- und Datenkanal kommt SHA-256 zum Einsatz:
|
||||
\begin{lstlisting}
|
||||
auth SHA256
|
||||
\end{lstlisting}
|
||||
|
||||
Zur Verschlüsselung des Datenkanals kommt AES-256-GCM zum Einsatz.
|
||||
Wird eine Chiffre mit \textit{Authenticated Encryption with Associated Data} (AEAD) gewählt, so wird die Authentisierungsfunktion der Chiffre anstelle der zuvor beschriebenen HMAC-Funktion für den Datenkanal benutzt \cite[][Option \texttt{--auth}]{man:openvpn}.
|
||||
Das ist bei AES-256-GCM der Fall.
|
||||
Zur Verschlüsselung des Datenkanals kommt die Chiffre AES-256-GCM zum Einsatz.
|
||||
\begin{lstlisting}
|
||||
cipher AES-256-GCM
|
||||
\end{lstlisting}
|
||||
|
||||
Um zu verhindern, dass eine veränderte Clientkonfiguration zu einer möglicherweise weniger sicheren VPN-Sitzung führt, wird die Aushandlung der mit \texttt{cipher} konfigurierten Chiffre in der \textbf{Serverkonfiguration} deaktiviert:
|
||||
Um zu verhindern, dass fehlerhaft konfigurierte VPN-Clients eine weniger sichere Verschlüsselung des Datenkanals aushandeln, wird in der \textbf{Serverkonfiguration} die Aushandlung der Chiffre zur Verschlüsselung des Datenkanals abgeschaltet.
|
||||
\begin{lstlisting}
|
||||
ncp-disable
|
||||
\end{lstlisting}
|
||||
|
|
@ -896,8 +911,10 @@ auth-nocache
|
|||
|
||||
\paragraph{Protokollierung:}
|
||||
Um den Detailgrad der Protokolle von OpenVPN zu steuern, können in der \textbf{Client- und Serverkonfiguration} die Parameter \texttt{verb} und \texttt{mute} verwendet werden.
|
||||
Der Parameter \texttt{verb} steuert dabei den Detailgrad der protokollierten Meldungen über einen Bereit von 0 (keine Meldungen) über 1-4 (normale Meldungen), 5 (Für jedes verarbeitete Paket wird ein Buchstabe in das Log geschrieben) bis hin zu 6-11 (Für Fehlersuche in der Entwicklung).
|
||||
Standardmäßig wird der Wert~1 verwendet; der Wert~3 wird für übersichtliche Protokolle mit mehr Informationen empfohlen.
|
||||
Der Parameter \texttt{verb} steuert dabei den Detailgrad der protokollierten Meldungen.
|
||||
Der Bereich reicht von 0 (keine Meldungen) über 1-4 (normale Meldungen), 5 (Für jedes verarbeitete Paket wird ein Buchstabe in das Log geschrieben) bis hin zu 6-11 (Für Fehlersuche in der Entwicklung).
|
||||
|
||||
Für DSGVO-konforme Protokolle wird der Wert~0 in der \textbf{Serverkonfiguration} verwendet; der Wert~3 wird für übersichtliche Protokolle mit mehr Informationen in der \textbf{Clientkonfiguration} empfohlen.
|
||||
Der Parameter \texttt{mute} gibt an, wie viele aufeinander folgende Nachrichten aus der selben Kategorie protokolliert werden sollen.
|
||||
Damit können aufeinander folgende, ähnliche Nachrichten unterdrückt werden, die sich wiederholen.
|
||||
Um einen guten Überblick zu erhalten, werden die folgenden Parameter gewählt:
|
||||
|
|
|
|||
Loading…
Reference in New Issue