Zusammenfassung

  • Eine erfolgreiche Konfigurationsannahme und die tatsächlich verwendeten Einstellungen sind unterschiedliche Nachweise. Die Datenspeicherarchitektur unterscheidet beabsichtigte von angewandter Konfiguration. Für eine Dienstfreigabe muss zusätzlich eine passende Anwendungsoperation über den vorgesehenen Weg erfolgreich sein. Die architektonische Grundlage liefert RFC 8342.
  • Auch nach erfolgreicher Proxy-Anmeldung bleiben Weiterleitungsbefugnis, Gegenstellenidentität und Anwendungsergebnis getrennt zu prüfen. Ein früherer Teilerfolg darf nicht als späterer ausgegeben werden. Diese Trennung folgt aus dem SOCKS5-Verfahren nach RFC 1928 und der TLS-Dienstidentifikation nach RFC 9525.

Die falsche Freigabe beginnt an der Verwaltungsschnittstelle

Die konkrete Fehlentscheidung lautet: Die neue Proxy-Konfiguration wurde angenommen, also kann die Anwendung ihren entfernten Dienst benutzen. Wird daraufhin eine Umstellung abgeschlossen, eine Abhängigkeit als verfügbar markiert oder eine weitere Automatisierung gestartet, fehlt der entscheidende Nachweis: dass gerade diese Anwendung mit ihren Berechtigungen über den vorgesehenen Vermittler die vorgesehene Operation ausführen kann.

Das ist kein Einwand gegen Konfigurationsmodelle. Eine erfolgreiche Verwaltungsoperation beantwortet eine notwendige, aber begrenzte Frage. Bei NETCONF bestätigt <ok/> den Erfolg der betreffenden Operation, sofern diese keine Daten zurückliefert und keine Fehler oder Warnungen aufgetreten sind. Dies beschreibt RFC 6241 in Abschnitt 4.4. Eine solche Antwort auf eine Konfigurationsänderung ist keine Bestätigung jeder künftig davon abhängigen Anwendungsfunktion.

Schon deshalb sollte eine Freigabe nicht an einem unbeschrifteten Erfolgswert hängen. Zu einer Konfigurationsbestätigung gehören der betroffene Datenspeicher, die konkrete Instanz und die Änderung. Zu einer Dienstbestätigung gehören dagegen ein Verbindungsversuch, seine Gegenstellen und das Ergebnis einer Operation. Ohne diese Zuordnung kann selbst eine richtige Einzelmeldung die falsche Entscheidung begründen.

Die folgenden Prüf- und Organisationsvorschläge sind betriebliche Schlussfolgerungen aus diesen Beleggrenzen. Sie sind weder zusätzliche normative Anforderungen der RFCs noch Aussagen über eine getestete Implementierung.

Drei Gruppierungen, kein vollständiger Betriebsnachweis

ietf-tcp-common enthält tcp-common-grouping für gemeinsame Parameter, insbesondere Keepalives. ietf-tcp-client liefert mit tcp-client-grouping Zielangaben, optionale lokale Bindung und Proxyparameter. ietf-tcp-server beschreibt durch tcp-server-grouping lokale Empfangsbindungen sowie gemeinsame Parameter. Eigene config false-Zustandsknoten oder Benachrichtigungen definiert RFC 9643 nicht.

Wichtig ist die Bedeutung einer Gruppierung. Nach RFC 7950, Abschnitte 7.12 und 7.13 ist sie eine wiederverwendbare Definition, die allein noch keine Knoten im Schemabaum erzeugt. Erst ihre Verwendung durch uses schafft den konkreten Zusammenhang. Ein Modulname bezeichnet deshalb weder einen feststehenden Verwaltungspfad noch eine bereits laufende Clientinstanz.

Auch der angebotene Funktionsumfang muss berücksichtigt werden. YANG erlaubt mit feature und if-feature bedingte Modellbestandteile; diese Mechanismen erläutert RFC 7950 in Abschnitt 7.20. Für eine Prüfung empfiehlt sich daher, das tatsächlich verwendete Anwendungsmodell, seine Revision und die unterstützten Funktionsmerkmale gemeinsam festzuhalten.

Eine Produktbeschreibung mit dem Stichwort „YANG“ ersetzt diese Eingrenzung nicht. Ebenso wenig wird die Selbstbeschreibung eines Systems dadurch zu einem unabhängigen Laufzeittest. Sie hilft zunächst festzustellen, welche Konfiguration sinnvoll geprüft werden kann. Ob diese Konfiguration im konkreten Zugriff die erwartete Wirkung entfaltet, bleibt eine andere Frage.

Beabsichtigt ist nicht angewandt

Die Datenspeicherarchitektur liefert dafür präzise Begriffe. <running> kann noch umzuformende Einstellungen enthalten. <intended> bezeichnet die daraus hervorgehende Konfiguration, deren Anwendung das System versucht. <operational> enthält Systemzustand und tatsächlich verwendete Konfiguration. Fehlende Ressourcen können die Anwendung verhindern; bisherige Einstellungen können während eines Übergangs noch wirksam bleiben. Diese Unterschiede beschreibt RFC 8342 in den Abschnitten 5.1.3 bis 5.3.2.

Für den Betreiber folgt daraus eine zweistufige Prüfung. Zunächst ist festzustellen, was angenommen wurde. Danach ist zu ermitteln, welche Werte die betreffende Clientinstanz tatsächlich verwendet. Ein erneutes Auslesen desselben Konfigurationsspeichers beantwortet nicht automatisch die zweite Frage.

Auch ein sauberer Datenspeichervergleich bleibt begrenzt. Er ist eine Aussage des verwalteten Systems über seine Einstellungen, kein Mitschnitt eines Verbindungsversuchs. Die Architektur erlaubt zudem, Konfigurationsknoten aus dem operativen Schema auszulassen, wenn der Server sie nicht zuverlässig berichten kann; siehe RFC 8342, Abschnitt 5.3. Fehlende Informationen verlangen deshalb auch eine Prüfung des angebotenen Schemas und der Zugriffsrechte.

Für eine Umstellung empfiehlt sich ein zeitlich zugeordneter Neuverbindungsversuch. Eine zuvor aufgebaute Sitzung eignet sich nicht ohne Weiteres als Beleg dafür, welchen Weg eine neue Sitzung unter geänderten Einstellungen nehmen wird. Der Prüfauftrag sollte ausdrücklich benennen, ob Bestandsverbindungen, Neuverbindungen oder beide bewertet werden.

Zwei Adressen mit demselben Feldnamen

proxy-server ist optional und setzt proxy-connect voraus; SOCKS4, SOCKS4a und SOCKS5 sind funktionsabhängige Alternativen. Außerhalb des Proxycontainers benennen remote-address und remote-port das Ziel; innerhalb der Proxyparameter bezeichnen sie den Vermittler. Der Proxyport ist mit 1080 vorbelegt; für den Zielport fehlt ein allgemeiner Vorgabewert. Als Proxyadresse verwendet der SOCKS4-Zweig inet:ip-address, während SOCKS4a und SOCKS5 inet:host zulassen. Maßgeblich ist RFC 9643, Abschnitt 3.3.

Ein Prüfbericht sollte deshalb nicht lediglich „Remote-Adresse erreichbar“ melden. Er muss erkennen lassen, ob er den Vermittler oder den beabsichtigten Dienst meint. Ebenso sollte er den tatsächlich verwendeten Zielport ausweisen, statt ihn aus dem Proxyport abzuleiten. Die Erreichbarkeit des falschen Ports wird durch eine richtige Adressangabe nicht zum Dienstnachweis.

Für SOCKS5 unterscheidet das Anforderungsformat IPv4-Adressen, Domänennamen und IPv6-Adressen; siehe RFC 1928, Abschnitte 4 und 5. Die Auswahl eines Protokollzweigs sollte daher nicht als bloße Schreibvariante behandelt werden. Insbesondere ist die Adressierung des Vermittlers von der Adressform zu trennen, mit der dieser das Ziel ansprechen soll.

Für konfigurierte Zielnamen beschreibt das Clientmodell eine Auflösung bei jedem Verbindungsversuch und das Ausprobieren mehrerer Adressen nach lokaler Präferenz. Das steht in RFC 9643, Abschnitt 3.3.

Für die Beweissicherung sollte daraus keine unüberprüfte Behauptung über den tatsächlich beobachteten Auflösungsort entstehen. Festzuhalten sind vielmehr der konfigurierte Name, die an den Vermittler übergebene Adressform und die beobachtbare Zielauswahl. Was auf der Proxyseite nicht einsehbar ist, bleibt eine benannte Sichtbarkeitsgrenze. Eine erfolgreiche Verbindung unter irgendeiner aufgelösten Adresse beantwortet außerdem noch nicht die Identitätsfrage.

Anmeldung und Weiterleitungsbefugnis sind verschiedene Entscheidungen

Für SOCKS5 ist authentication-parameters optional. Wird er eingerichtet, ist eine unterstützte Variante auszuwählen: GSS-API oder Benutzername/Passwort. Der GSS-API-Container bleibt für Erweiterungen leer. Das ergibt sich aus RFC 9643, Abschnitt 3.3.

Die konfigurierte Auswahl ist noch keine beobachtete Aushandlung. SOCKS5 beginnt mit TCP zum Proxy, gefolgt von Methodenauswahl und gegebenenfalls Authentifizierungsunteraushandlung. Danach bewertet der Proxy die Weiterleitungsanfrage. „Keine Authentifizierung erforderlich“ ist eine eigene Methodenwahl. Dies beschreibt RFC 1928 in Abschnitt 3.

Daher sollten drei Feststellungen getrennt bleiben: welche Methode vorgesehen war, welche tatsächlich vereinbart wurde und ob die Zielanfrage erlaubt wurde. Ein fehlender Konfigurationseintrag liefert keinen Mitschnitt dieser Entscheidungen. Eine erfolgreiche Anmeldung darf insbesondere nicht als uneingeschränkte Befugnis verstanden werden, beliebige Ziele anzusprechen.

Bei Benutzername und Passwort besitzt die Unteraushandlung einen eigenen Erfolgsstatus. Außerdem trägt die Anfrage das Passwort im Klartext. Beides ist in RFC 1929, Abschnitte 2 und 3 festgehalten. Die Sicherheitsbewertung muss deshalb zwischen der Annahme von Zugangsdaten und ihrem Schutz während der Übertragung unterscheiden.

Hier ist die kryptographische Modellierung unmittelbar relevant. Die password-grouping aus RFC 9640, Abschnitt 2.1.4.2 unterscheidet Klartext- und verschlüsselte Passwortwerte für die Anmeldung an entfernten Systemen. Sie beschreibt damit die Darstellung des Geheimnisses im Datenmodell, nicht automatisch den Schutz des späteren SOCKS-Austauschs. Ein verschlüsselter Konfigurationswert ist kein Nachweis vertraulicher Weitergabe. Ebenso schützt eine erst nach der Proxy-Anmeldung aufgebaute TLS-Verbindung zum Zieldienst diese Anmeldung nicht rückwirkend.

GSS-API verlangt eine andere Betrachtung. RFC 1961, Abschnitte 3 und 4 beschreibt die Einrichtung eines Sicherheitskontexts und eine zusätzliche Aushandlung des Nachrichtenschutzes. Integrität und Vertraulichkeit sind unterschiedliche Leistungen; ein für den Client unzureichendes vereinbartes Schutzniveau führt zum Verbindungsabbruch. Für einen belastbaren Nachweis ist deshalb das Ergebnis dieses Verfahrens entscheidend, nicht allein die Bezeichnung „GSS-API“ in der Konfiguration.

Die Weiterleitungsantwort besitzt wiederum eine eigene Bedeutung. SOCKS5 unterscheidet regelbedingte Ablehnung, unerreichbares Netz oder Ziel und zurückgewiesene Verbindung. Bei CONNECT bezeichnet BND.ADDR eine zugehörige Adresse des Proxys, nicht die Identität des Zielservers. Siehe RFC 1928, Abschnitt 6.

Ein Erfolgscode ist somit zunächst eine Protokollaussage des Vermittlers. Er sollte weder unterschlagen noch überdehnt werden: Er hilft bei der Eingrenzung, ersetzt aber nicht die nachfolgende Prüfung durch den Client. Ohne diesen Unterschied kann ein technisch richtiger Proxybericht eine sachlich falsche Dienstfreigabe stützen.

Die TCP-Gegenstelle ist noch nicht die Dienstidentität

TCP stellt einen zuverlässigen, geordneten Bytestrom bereit. Sein Verbindungszustand beschreibt jedoch keine Berechtigung zur Nutzung einer bestimmten Anwendungsfunktion. Diese Transportaufgabe ist in RFC 9293, Abschnitt 2.2 beschrieben.

Im betrachteten Proxyaufbau sind deshalb Client–Proxy und Proxy–Ziel getrennt zu betrachten. Ein lokaler TCP-Erfolg muss zunächst der richtigen Verbindung zugeordnet werden. Die Aussage über das entfernte Anwendungsprotokoll entsteht erst durch dessen Kommunikation. Ein bloßer Zustandsname ohne Gegenstellenbezug lässt die wichtigste Frage offen: Wer hat hier tatsächlich geantwortet?

Die Modellfamilie hält Identitätsfragen entsprechend gesondert fest. RFC 9644, insbesondere Abschnitt 3.1.2.1 beschreibt für SSH Clientidentität und Serverauthentifizierung. RFC 9645, insbesondere Abschnitt 3.1.2.1 trennt diese Bereiche auch für TLS; dort kann die Clientauthentifizierung zudem auf einer höheren Protokollebene erfolgen. Proxyanmeldung, serverseitiger Identitätsnachweis und Nutzungsberechtigung gehören deshalb nicht in denselben Erfolgswert.

Bei SSH verbindet der in RFC 4253, Abschnitt 8 beschriebene Schlüsselaustausch die Prüfung der Hostschlüsselzuordnung mit der Signaturprüfung. Das Dokument warnt vor aktiven Angriffen, wenn die Zuordnung ungeprüft akzeptiert wird. Eine verschlüsselte Sitzung ist daher als Nachweis der beabsichtigten Gegenstelle unvollständig, wenn unbekannt bleibt, wie deren Identität geprüft wurde.

Beim zertifikatsbasierten TLS-1.3-Handshake belegt CertificateVerify den Besitz des zum Zertifikat gehörenden privaten Schlüssels; Finished bestätigt die Handshake-Integrität und die berechneten Schlüssel. Diese Funktionen beschreibt RFC 8446, Abschnitte 4.4.3 und 4.4.4. Für die Bewertung sollten die verwendeten Vertrauensgrundlagen und das Ergebnis der Zertifikatsprüfung nachvollziehbar bleiben, statt lediglich das Vorhandensein eines Zertifikats zu melden.

Davon zu unterscheiden ist der Abgleich mit der erwarteten Dienstidentität. RFC 9525, Abschnitt 6 verlangt, akzeptable Referenzidentifikatoren unabhängig von den vom Server präsentierten Identifikatoren zu bestimmen und anschließend auf Übereinstimmung zu prüfen. Der erwartete Dienstname darf also nicht nachträglich durch irgendeinen Namen ersetzt werden, unter dem eine Verbindung gelungen ist.

Für den Betrieb ist außerdem festzulegen, an welcher Gegenstelle die gewünschte Sicherheitsbeziehung enden soll. Ist in einer Architektur eine autorisierte TLS-Terminierung durch einen Vermittler vorgesehen, sollte der Freigabenachweis offenlegen, was damit über den dahinterliegenden Dienst noch nicht gezeigt wurde. Das ist eine Grenze des Prüfauftrags, kein durch Verschlüsselung automatisch gelöstes Zuordnungsproblem.

Erst eine konkrete Operation macht den Nachweis anwendungsbezogen

Ein sinnvoller Nachweis lässt sich an einer NETCONF-Leseoperation verdeutlichen, ohne einen realen Einsatz zu unterstellen. <get> fragt laufende Konfiguration und Gerätezustand ab. Eine erfolgreiche Antwort enthält die abgefragten Daten in <data>; Fehler können als <rpc-error> erscheinen. Die message-id ordnet innerhalb der Sitzung die Antwort der Anfrage zu. Grundlage sind die Abschnitte 4.2, 4.3 und 7.7 von RFC 6241.

Eine daraus abgeleitete Dienstprüfung sollte eine begrenzte, freigegebene Abfrage über dieselbe Clientinstanz ausführen, deren Erreichbarkeit behauptet wird. Als Erfolg zählen nicht beliebige empfangene Bytes, sondern eine zuordenbare Antwort mit dem vorher festgelegten Inhalt. Identität, Berechtigungsrolle und zulässige Antwortzeit gehören zum Prüfauftrag. Die Abfrage dient hier als Test der entfernten Anwendung; sie ersetzt nicht die gesonderte Prüfung der angewandten Clientkonfiguration.

Selbst eine formal richtige Antwort verlangt Interpretation. Das Zugriffsmodell NACM lässt Datenknoten und ihre Nachfahren, für die Leserechte fehlen, stillschweigend aus der Antwort weg. Diese Regel steht in RFC 8341, Abschnitt 3.2.4. Ein leerer oder unvollständiger Datenausschnitt muss daher nicht bedeuten, dass die Verbindung gescheitert ist. Er kann aber den geforderten Nutzungsnachweis verfehlen.

Die belastbare Aussage ist entsprechend eng: Diese Operation lieferte unter diesen Berechtigungen über diesen beobachteten Weg zu diesem Zeitpunkt das erwartete Ergebnis. Daraus folgen weder die Verfügbarkeit aller Funktionen noch eine dauerhafte Erreichbarkeitsgarantie. Ein solcher begrenzter Nachweis ist aussagekräftiger als eine umfassend klingende, aber unbestimmte Verfügbarkeitsmeldung.

Keepalives prüfen nicht, ob die Arbeit erledigt wird

idle-time, max-probes und probe-interval beschreiben Leerlauf, Fehlversuche und Prüfintervall. Als ungefähre Abbruchzeit nennt RFC 9643, Abschnitt 2.3 idle-time + max-probes × probe-interval.

TCP-Keepalives provozieren auf einer ruhenden Verbindung eine Antwort des TCP-Partners. Sofern implementiert, müssen sie pro Verbindung abschaltbar und standardmäßig ausgeschaltet sein. Der Standardwert des Leerlaufintervalls beträgt mindestens zwei Stunden; ein einzelner Antwortausfall darf nicht als tote Verbindung interpretiert werden. Diese Anforderungen enthält RFC 9293, Abschnitt 3.8.4.

Für die Clientverbindung zum SOCKS-Proxy bleibt der geprüfte TCP-Partner zunächst der Proxy. Eine Antwort auf dieser Ebene belegt weder die Verarbeitung einer Anfrage im Zieldienst noch deren fachlichen Erfolg. Auch die errechnete Abbruchzeit ist keine zugesagte Frist, innerhalb derer eine Anwendungsstörung erkannt wird.

Als betriebliche Konsequenz sollten Transportüberwachung und Anwendungsprüfung nebeneinander bestehen. Die erste hilft, Verbindungsprobleme einzugrenzen und Ressourcen zu verwalten. Die zweite muss jene Arbeit prüfen, auf deren erfolgreiche Ausführung sich die Freigabe bezieht. Kürzere Prüfintervalle lösen den Bedeutungsunterschied nicht; ihre Auswahl sollte zusätzlich die entstehende Prüfbelastung berücksichtigen.

Was nach der Konfigurationsannahme noch zu beweisen bleibt

Eine belastbare Freigabe verbindet Einstellungen und Beobachtungen, ohne sie gleichzusetzen. Sie ordnet der angewandten Konfiguration einen konkreten Verbindungsversuch zu, hält die Entscheidung des Vermittlers fest, prüft die erforderliche Gegenstellenidentität und bewertet eine passende Anwendungsantwort.

Welche dieser Beobachtungen ein bestimmtes Produkt tatsächlich bereitstellt, lässt sich aus den untersuchten Normtexten nicht ermitteln. Fehlende Proxyprotokolle, nicht sichtbare Zielauflösung oder eine unbekannte Identitätsprüfung sind daher keine stillschweigend bestandenen Prüfungen. Sie begrenzen den Umfang der möglichen Aussage.

Die entscheidende Verbesserung besteht nicht darin, möglichst viele Erfolgsanzeigen zu sammeln. Sie besteht darin, jeder Anzeige eine überprüfbare Bedeutung zu geben und keinen Übergang zur nächsten Stufe ohne passenden Nachweis vorzunehmen.