# Verschlüsselung und verschlüsselter Verkehr (FAQ)

> 40 Fragen zu Verschlüsselung und verschlüsselter Verkehr, verständlich beantwortet: was zu prüfen ist, was NetSenX zeigt und was ein Sensor nicht sieht.

Source page: https://netsenx.com/de/faq/encryption

## Erkennt NetSenX Bedrohungen in verschlüsseltem Verkehr?

Ja, anhand von Metadaten — verschlüsselter Verkehr wird nie entschlüsselt. NetSenX wertet Flow-Metadaten und einige Protokollfelder aus — Zeitverhalten, Volumen, Ziele und den TLS-Handshake —, sodass Beaconing und ungewöhnliche Datenübertragungen sichtbar bleiben, ohne die Verschlüsselung aufzubrechen oder Inhalte zu lesen.

https://netsenx.com/de/faq/can-netsenx-detect-threats-in-encrypted-traffic

## Kann NDR Bedrohungen in verschlüsseltem Verkehr ohne Entschlüsselung erkennen?

Ja, anhand von Metadaten. Zeitverhalten, Volumen, Ziele und der TLS-Handshake bleiben sichtbar, wenn der Inhalt verschlüsselt ist; Beaconing zu einem C2-Server und ungewöhnliche Datenübertragungen lassen sich daher erkennen, ohne die Verschlüsselung aufzubrechen. Unsichtbar bleibt der Inhalt der Sitzung.

https://netsenx.com/de/faq/can-ndr-detect-threats-in-encrypted-traffic-without-decrypting-it

## Was liest NetSenX aus einer verschlüsselten Verbindung?

Flow-Metadaten (wer sich mit wem verbindet, wann, wie oft und wie viele Daten fließen) und einige Protokollfelder: den Servernamen und die Parameter des TLS-Handshakes sowie die Antworten auf DNS-Anfragen. NetSenX entschlüsselt die Sitzung nie und liest ihren verschlüsselten Inhalt nicht.

https://netsenx.com/de/faq/what-does-netsenx-read-from-an-encrypted-connection

## Brauche ich TLS-Entschlüsselung, um Bedrohungen zu erkennen?

Für viele nicht. Wer mit wem spricht, wann, wie oft und wie viel, zusammen mit dem unverschlüsselten TLS-Handshake und DNS-Antworten, bleibt ohne Entschlüsselung sichtbar. Das reicht, um Beaconing zu einem Command-and-Control-Server, Scans, laterale Bewegung zwischen internen Hosts und ungewöhnliche Uploads zu erkennen, also Schritte, die die meisten Angriffe gehen, bevor sie Schaden anrichten. Entschlüsselung braucht es, um Inhalte zu sehen, etwa eine Schaddatei in einem Download oder den Text eines Befehls, und sie hat ihren Preis: ein Abfang-Proxy, der Schlüssel und entschlüsselte Daten hält, ein Firmenzertifikat auf jedem verwalteten Gerät, Apps, die nicht mehr funktionieren, Fragen zu Datenschutz und Betriebsrat und blinde Flecken bei nicht verwalteten Geräten. Viele Unternehmen fahren besser mit Endpoint-Schutz für Dateien und Prozesse auf jedem Rechner plus Netzwerkerkennung für das Verhalten aller Geräte. NetSenX entschlüsselt nie Verkehr: Die Kernerkennungen laufen in jedem Plan, TLS-Fingerprints ab dem Starter-Plan, wo der Agent Pakete mitschneidet.

https://netsenx.com/de/faq/do-i-need-tls-decryption-to-detect-threats

## Warum TLS-Verkehr nicht zur Inspektion entschlüsseln?

Entschlüsselung macht Inhalte sichtbar, bedeutet aber einen Abfangpunkt, der Schlüssel hält, ein Abfangzertifikat auf jedem Gerät und den Umgang mit entschlüsselten Inhalten, die personenbezogene Daten enthalten können. Seit TLS 1.3 kann ein passiver Sensor Sitzungen nicht mehr mit einer Kopie des privaten Serverschlüssels entschlüsseln.

https://netsenx.com/de/faq/why-not-decrypt-tls-traffic-for-inspection

## Was macht TLS-Inspection auf der Firewall kaputt?

Mehr, als viele erwarten. Um HTTPS zu prüfen, beendet die Firewall oder der Proxy jede Verbindung, entschlüsselt und untersucht sie und baut eine neue verschlüsselte Verbindung zum echten Server auf, wobei sie ein eigenes Zertifikat vorlegt, signiert von einer Firmen-Stammzertifizierungsstelle, die auf jedem verwalteten Gerät installiert ist. Die Nebenwirkungen: Apps mit Certificate Pinning, viele Updater, manche Banking- und Gesundheits-Apps und Teile von Cloud-Diensten lehnen das Ersatzzertifikat ab, die Ausnahmelisten wachsen also ständig; nicht verwaltete Geräte, Gäste und Maschinen lassen sich gar nicht prüfen; der Proxy wird zu einem Ort, der entschlüsselten Verkehr samt personenbezogener Daten hält, was Fragen zu DSGVO und Betriebsrat aufwirft; ältere Proxys unterstützen neuere TLS-Funktionen oder die neuen hybriden Post-Quanten-Gruppen womöglich nicht und schwächen Verbindungen still; und die Prüfung kostet Leistung. Sie hat trotzdem ihren Platz, etwa zum Scannen von Downloads auf verwalteten Laptops. Viele Bedrohungen sind aber auch ohne sie sichtbar. Diesen Weg geht NetSenX: Es entschlüsselt nie und arbeitet mit Metadaten und dem unverschlüsselten Handshake.

https://netsenx.com/de/faq/what-does-tls-inspection-on-a-firewall-break

## Funktioniert Deep Packet Inspection bei verschlüsseltem Verkehr?

Nur bei den Teilen, die nicht verschlüsselt sind, es sei denn, Sie entschlüsseln. Deep Packet Inspection (DPI) bedeutet, über die Paketköpfe hinaus in den Inhalt zu lesen. Bei TLS ist der Inhalt verschlüsselt, klassische Signaturen, die nach einer Schaddatei oder einem Befehl im Datenstrom suchen, greifen also nicht mehr. Lesbar bleiben die unverschlüsselten Handshake-Nachrichten mit TLS-Version, Wahl von Chiffre und Schlüsselaustausch, einem Client-Fingerprint und meist dem Servernamen sowie die DNS-Antworten vor der Verbindung. Zusammen mit Flow-Metadaten, also wer, wann, wie oft und wie viel, reicht das für viele Erkennungen: Beaconing zu einem Command-and-Control-Server, Scans, laterale Bewegung und ungewöhnliche Uploads. Um Inhalte zu sehen, brauchen Sie einen Abfang-Proxy, der Verkehr entschlüsselt und neu verschlüsselt, mit eigenen Kosten und Risiken. NetSenX liest die Handshake-Felder dort, wo sein Agent Pakete mitschneidet, unter Linux oder als SPAN/TAP-Sensor, nicht im Basismodus unter macOS, und entschlüsselt nie Verkehr.

https://netsenx.com/de/faq/can-deep-packet-inspection-work-on-encrypted-traffic

## Lässt sich Schadsoftware allein an Flow-Statistiken erkennen?

Oft ja, denn Schadsoftware muss sich auf bestimmte Weise verhalten, um nützlich zu sein, und dieses Verhalten zeigt sich in den Flows. Flow-Datensätze beschreiben jede Verbindung: Quelle und Ziel, Ports, Startzeit, Dauer sowie Bytes und Pakete in jede Richtung. Ein kompromittiertes Gerät, das sich in regelmäßigen Abständen bei seinem Steuerserver meldet, erzeugt einen erkennbaren Rhythmus, das Beaconing; eines, das das Netz erkundet, berührt in kurzer Zeit viele interne Hosts und Ports, also Scans und laterale Bewegung; eines, das Daten stiehlt, sendet weit mehr als sonst, oft nachts. Nichts davon braucht Entschlüsselung, und die Forschung zur Analyse verschlüsselten Verkehrs zeigt seit Jahren, dass Zeit- und Größenmuster viel Information tragen. Die Grenzen: Eine einzelne Verbindung zu einem bekannten Cloud-Dienst kann harmlos aussehen, und geduldige Angreifer versuchen, unauffällig zu bleiben. Deshalb funktioniert Flow-Analyse am besten gegen eine Basislinie dessen, was für jedes Gerät normal ist. NetSenX erkennt Beaconing, Scans, laterale Bewegung und ungewöhnliches ausgehendes Datenvolumen in jedem Plan, auch im Free-Plan.

https://netsenx.com/de/faq/can-malware-be-detected-from-flow-statistics

## Kann verschlüsselter Verkehr verraten, was darin steckt?

Nicht den Inhalt, aber mehr darüber, als viele annehmen. Verschlüsselung verbirgt Wörter, Dateien und Tastenanschläge, doch Größe, Zeitpunkt und Richtung der Pakete verraten Muster: Ein Videoanruf, ein großer Upload, eine Remote-Desktop-Sitzung und ein Software-Update haben jeweils eine erkennbare Form. Forscher zeigen seit Jahren, dass solche Verkehrsanalyse besuchte Websites oder genutzte Anwendungen mit unterschiedlicher Genauigkeit erkennen kann, sogar durch ein VPN. Für die Verteidigung ist das nützlich: So kann ein Netzwerksensor eine interaktive Sitzung von einer automatischen Rückmeldung unterscheiden oder einen Server bemerken, der plötzlich Gigabytes sendet, ohne etwas zu entschlüsseln. Für den Datenschutz ist es eine Erinnerung, dass Verschlüsselung keine Unsichtbarkeit ist. Was Verkehrsanalyse nicht kann: eine Nachricht lesen, sehen, welche Datei hochgeladen wurde, oder wissen, was jemand in einen KI-Chatbot getippt hat. NetSenX nutzt Flow-Metadaten und den unverschlüsselten Handshake, entschlüsselt nie Sitzungen und rekonstruiert keine Inhalte.

https://netsenx.com/de/faq/can-encrypted-traffic-reveal-what-is-inside

## Sind Netzwerk-Metadaten personenbezogene Daten nach der DSGVO?

Sie können es sein. Der Gerichtshof der EU hat in der Rechtssache Breyer (C-582/14, 19. Oktober 2016) entschieden, dass eine dynamische IP-Adresse ein personenbezogenes Datum sein kann. NetSenX veröffentlicht einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO und speichert Kundendaten in der EU.

https://netsenx.com/de/faq/is-network-metadata-personal-data-under-gdpr

## Kann man sich über eine HTTPS-Website Schadsoftware einfangen?

Ja. HTTPS bedeutet, dass die Verbindung verschlüsselt ist und der Server ein gültiges Zertifikat für den Namen in der Adresszeile hat; es sagt nichts darüber, ob die Website oder ihre Downloads sicher sind. Angreifer nutzen HTTPS so selbstverständlich wie alle anderen, weil Zertifikate kostenlos und automatisiert sind, und viel Phishing und Malware-Verteilung läuft darüber. Das Schloss schützt Sie davor, dass jemand den Verkehr unterwegs liest oder verändert, nicht vor dem Inhalt am anderen Ende. Schutz vor schädlichen Downloads bieten Endpoint-Schutz auf dem Gerät, Filter in Browser und E-Mail, aktuelle Software und Beschränkungen, wer Programme installieren darf. Auf Netzwerkseite verbirgt die Verschlüsselung die Datei, nicht aber das Verhalten, das meist auf eine Infektion folgt: ein Gerät, das plötzlich in regelmäßigen Abständen ein neues Ziel kontaktiert, interne Hosts scannt oder ungewöhnliche Datenmengen sendet. NetSenX erkennt diese Muster in jedem Plan, aus Flow-Metadaten und ohne Verkehr zu entschlüsseln.

https://netsenx.com/de/faq/can-you-get-malware-from-an-https-website

## Kann HTTPS-Verkehr durch einen Man-in-the-Middle abgefangen werden?

Nur wenn man den Client dazu bringt, dem Abfangenden zu vertrauen. Ein Man-in-the-Middle-Angriff auf HTTPS braucht ein Zertifikat, das der Client für den Zielnamen akzeptiert, einen Nutzer, der die Warnung wegklickt, oder eine Anwendung, die Zertifikate nicht richtig prüft. Unternehmen tun das absichtlich mit TLS-Inspection-Proxys, indem sie ein eigenes Stammzertifikat auf verwalteten Geräten installieren. Angreifer versuchen dasselbe, indem sie per Schadsoftware ein falsches Stammzertifikat einschleusen, Nutzer zum Akzeptieren von Warnungen bewegen oder Apps mit fehlerhafter Zertifikatsprüfung ausnutzen. Abwehr: Gewöhnen Sie Mitarbeitende nie daran, Zertifikatswarnungen wegzuklicken, kontrollieren Sie, welche Stammzertifikate auf Firmengeräten installiert sind, halten Sie Apps aktuell und setzen Sie auf Ihren Websites HTTP Strict Transport Security (HSTS) ein, damit Browser unverschlüsselte Verbindungen ablehnen. Certificate Pinning in manchen Apps weist jeden Abfangenden ab, auch Ihren eigenen Proxy. In TLS 1.3 ist das Serverzertifikat verschlüsselt, ein passiver Netzwerksensor kann also nicht prüfen, wer es ausgestellt hat; diese Prüfung gehört auf das Gerät oder in Proxy-Logs.

https://netsenx.com/de/faq/can-https-traffic-be-intercepted

## Was ist JA4-TLS-Fingerprinting?

Wenn ein Programm eine TLS-Verbindung öffnet, nennt seine erste Nachricht die unterstützten Versionen, Cipher und Erweiterungen in einer charakteristischen Reihenfolge. Ein Fingerprint wie JA4 verdichtet diese Nachricht zu einer kurzen Zeichenkette, sodass dieselbe Client-Software über viele Verbindungen hinweg erkannt werden kann, ohne etwas zu entschlüsseln. Das hilft, ungewöhnliche Clients zu erkennen, etwa ein Skript, das sich als Browser ausgibt. NetSenX berechnet TLS-Fingerprints aus dem Handshake ab dem Starter-Plan, mit eigener Implementierung. Der Handshake ist nur sichtbar, wo der Agent Pakete mitschneidet: unter Linux oder als Sensor an einem SPAN- oder TAP-Port, nicht im Basismodus unter macOS.

https://netsenx.com/de/faq/what-is-ja4-tls-fingerprinting

## Was ist der Unterschied zwischen JA3 und JA4?

Beide erstellen einen Fingerprint der Client-Seite eines TLS-Handshakes, aber JA4 kommt mit dem Verhalten moderner Browser zurecht. JA3, 2017 veröffentlicht, bildet einen Hash über die Felder des ClientHello in der Reihenfolge, in der sie erscheinen. Seit Anfang 2023 mischt Chrome die Reihenfolge der TLS-Erweiterungen bei jeder Verbindung, was den JA3-Wert jedes Mal ändert und ihn zum Erkennen von Browsern viel weniger brauchbar macht. JA4, 2023 veröffentlicht, sortiert die Felder vor dem Hashen, ergänzt TLS-Version, Transport (TCP oder QUIC) und das erste angebotene Anwendungsprotokoll und erzeugt eine lesbare Zeichenkette, deren Teile sich einzeln vergleichen lassen. Keiner beweist für sich böse Absicht: Viele Programme teilen einen Fingerprint, und Schadsoftware kann einen Browser imitieren. Nützlich sind sie, um einen Client zu erkennen, der nicht zum Gerät passt, etwa ein Skript auf einem Server, das sich als Browser ausgibt. NetSenX berechnet TLS-Fingerprints ab dem Starter-Plan, mit eigener Implementierung, wo sein Agent Pakete mitschneidet: unter Linux oder als SPAN/TAP-Sensor, nicht im Basismodus unter macOS.

https://netsenx.com/de/faq/what-is-the-difference-between-ja3-and-ja4

## Was ist SNI, und warum ist es für die Überwachung wichtig?

Server Name Indication (SNI) ist ein Feld im TLS-ClientHello, in dem der Client die gewünschte Website nennt, etwa login.example.com, weil sich viele Websites eine IP-Adresse teilen und der Server wissen muss, welches Zertifikat er vorlegen soll. Es wird vor Beginn der Verschlüsselung gesendet, jeder auf dem Weg kann es also lesen. Für die Überwachung ist es eines der nützlichsten Felder im verschlüsselten Verkehr: Es benennt den Dienst hinter einer IP-Adresse und hilft so, einen KI-Assistenten, einen Filesharing-Dienst oder eine bekannte Geschäftsanwendung von einem unbekannten Server zu unterscheiden, ohne Inhalte zu lesen. Die meisten Webfilter und viele Firewalls stützen sich ebenfalls darauf. Zwei Dinge schmälern seinen Wert: Verbindungen direkt zu einer IP-Adresse tragen keinen sinnvollen Namen, und Encrypted Client Hello (ECH) verbirgt den echten Namen hinter einem öffentlichen Vorschaltnamen. Dann zählen DNS-Antworten und die Vorgeschichte jedes Ziels mehr. NetSenX liest den Servernamen aus dem Handshake, wo sein Agent Pakete mitschneidet, unter Linux oder als SPAN/TAP-Sensor.

https://netsenx.com/de/faq/what-is-sni-and-why-does-it-matter-for-monitoring

## Was ist Encrypted Client Hello (ECH)?

ECH ist eine TLS-Erweiterung, die den sensiblen Teil des ClientHello einschließlich des echten Servernamens mit einem öffentlichen Schlüssel verschlüsselt, den die Website im DNS veröffentlicht. Auf der Leitung sieht ein Beobachter nur ein äußeres ClientHello mit einem gemeinsamen öffentlichen Namen, meist dem des Content-Delivery-Netzes, das die Website hostet, statt der eigentlichen Website. Entworfen wurde es für den Datenschutz: Niemand auf dem Weg, vom Café-WLAN bis zum Internetanbieter, soll erfahren, welche Website Sie besuchen. Große Browser unterstützen es, und einige große Content-Delivery-Netze bieten es an, sodass ein Teil des Webverkehrs es bereits nutzt, während die meisten Unternehmens- und internen Server es nicht tun. ECH kommt meist zusammen mit verschlüsseltem DNS, weil der Name sonst trotzdem über die DNS-Abfrage durchsickern würde. Zertifikat und Sitzungsinhalt waren unter TLS 1.3 schon verschlüsselt; ECH schließt eines der letzten lesbaren Felder. Für Sicherheitsteams heißt das: weniger Namen, mehr Verlass auf Verhalten.

https://netsenx.com/de/faq/what-is-encrypted-client-hello

## Macht Encrypted Client Hello die Netzwerküberwachung blind?

Teilweise. Mit ECH sieht ein Sensor den echten Servernamen im Handshake nicht mehr, namensbasierte Regeln, Webfilter und einfache Schatten-IT-Listen verlieren also bei Websites, die es nutzen, an Genauigkeit. Übrig bleibt viel: die Ziel-IP-Adresse und wer sie betreibt, der äußere öffentliche Name, meist der eines großen Content-Delivery-Netzes, DNS-Antworten, wenn DNS nicht durchgehend verschlüsselt ist, Zeitpunkt, Volumen und Richtung jedes Flows sowie der Client-Fingerprint. Verhaltensbasierte Erkennungen wie Beaconing, Scans, laterale Bewegung und ungewöhnliche Uploads hängen nicht vom Servernamen ab und funktionieren weiter. Interner Verkehr ist selten betroffen, weil interne Server kaum ECH-Schlüssel veröffentlichen. Bei verwalteten Geräten haben Sie Einfluss: Lassen Sie sie Ihren eigenen DNS-Resolver nutzen und setzen Sie die Unternehmensrichtlinien des Browsers ein, mit denen sich ECH und verschlüsseltes DNS steuern lassen. Die namensbasierte Sichtbarkeit von KI- oder Filesharing-Diensten wird für Websites hinter ECH bei jedem Netzwerksensor, auch bei NetSenX, weniger vollständig.

https://netsenx.com/de/faq/does-encrypted-client-hello-blind-network-monitoring

## Machen QUIC und HTTP/3 Firewalls blind?

Sie verringern, was ältere Firewalls sehen, machen Verkehr aber nicht unsichtbar. QUIC (RFC 9000, 2021) ist der Transport unter HTTP/3. Es läuft über UDP-Port 443 und verschlüsselt fast alles, auch vieles, was TCP lesbar ließ, etwa Paketnummern und Bestätigungen. Seine ersten Pakete tragen ein TLS-1.3-ClientHello, das nur mit Schlüsseln geschützt ist, die jeder ableiten kann; ein Sensor, der QUIC versteht, kann daher weiterhin Servernamen und Handshake-Parameter lesen. Firewalls und Proxys, die für TCP gebaut sind, können QUIC oft gar nicht prüfen. Üblich ist in Unternehmen, die auf TLS-Inspection oder Webfilter setzen, UDP-Port 443 zu sperren, sodass Browser unbemerkt auf HTTP/2 über TCP zurückfallen. Ohne eine solche Regel erscheint QUIC einfach als UDP-Flows mit Zeitpunkt und Volumen wie jeder andere Verkehr, und Flow-basierte Erkennungen wie Beaconing und ungewöhnliches Upload-Volumen greifen weiterhin. Prüfen Sie, ob Ihre Firewall QUIC meldet, bevor Sie annehmen, dass es abgedeckt ist.

https://netsenx.com/de/faq/do-quic-and-http3-blind-firewalls

## Kann DNS over HTTPS Verkehr vor der Sicherheitsüberwachung verbergen?

Es kann die DNS-Abfragen verbergen, nicht aber die Verbindungen, die darauf folgen. DNS over HTTPS (DoH, RFC 8484) und DNS over TLS (DoT, RFC 7858) verschlüsseln die Fragen, die ein Gerät seinem Resolver stellt. Nutzen Browser oder Apps einen externen DoH-Resolver, sehen Ihr Firmen-DNS-Server und seine Logs nicht mehr, welche Namen nachgeschlagen werden, was DNS-basierte Filter und Untersuchungen schwächt. Schadsoftware kann DoH aus demselben Grund nutzen. Die Verbindungen zu den eigentlichen Zielen laufen weiter mit IP-Adressen, Zeitpunkt und Volumen über das Netz, oft mit dem Servernamen im TLS-Handshake. Praktische Schritte: Betreiben Sie einen eigenen Resolver oder nutzen Sie den eines Anbieters, der verschlüsseltes DNS unterstützt, und lassen Sie verwaltete Geräte ihn verwenden; verhindern Sie per Browser- und Betriebssystemrichtlinien andere Resolver; und achten Sie auf Geräte, die direkt mit öffentlichen DoH-Diensten sprechen. DoT ist leicht zu erkennen, weil es Port 853 nutzt; DoH sieht aus wie gewöhnliches HTTPS. NetSenX alarmiert bei DNS-Tunneling; es filtert oder sperrt kein DNS.

https://netsenx.com/de/faq/can-dns-over-https-hide-traffic-from-security-monitoring

## Wie entschlüssele ich TLS-Verkehr zur Fehlersuche?

Auf einem Rechner, den Sie kontrollieren, lassen Sie am einfachsten den Client seine Sitzungsschlüssel in eine Datei schreiben und laden diese in Wireshark. Browser und viele Kommandozeilenwerkzeuge auf Basis von OpenSSL oder NSS beachten die Umgebungsvariable SSLKEYLOGFILE: Setzen Sie sie, stellen Sie das Problem nach, während Sie mit Wireshark oder tcpdump mitschneiden, und tragen Sie das Schlüssel-Log in den TLS-Einstellungen von Wireshark ein. Das funktioniert auch bei TLS 1.3, wo der private Schlüssel des Servers nicht mehr ausreicht. Auf einem eigenen Server können manche Webserver und Proxys ebenfalls Schlüssel protokollieren, oder Sie testen gegen eine Testkopie mit eingeschalteter Protokollierung. Behandeln Sie Schlüssel-Logs wie Passwörter: Wer Datei und Mitschnitt hat, kann den Verkehr lesen; löschen Sie daher beides danach und sammeln Sie sie nie ohne klare Grundlage und Wissen der Betroffenen von fremden Geräten. Für die tägliche Überwachung ist Entschlüsselung selten nötig: Flow-Metadaten und der unverschlüsselte Handshake beantworten die meisten Fragen, wer mit wem wie kommuniziert.

https://netsenx.com/de/faq/how-to-decrypt-tls-for-troubleshooting

## Wie funktioniert ein TLS-Handshake?

Bei TLS 1.3 braucht es einen Hin- und Rückweg, bevor Daten fließen. Der Client sendet ein ClientHello mit den unterstützten TLS-Versionen, Cipher-Suites und Gruppen für den Schlüsselaustausch, einem Schlüsselanteil für seine bevorzugte Gruppe und meist dem Namen des gewünschten Servers (SNI). Der Server antwortet mit einem ServerHello, das Version, Chiffre und Gruppe wählt, und seinem eigenen Schlüsselanteil. Aus beiden Anteilen leiten beide Seiten dasselbe Geheimnis ab, und ab diesem Moment ist alles verschlüsselt, auch das Serverzertifikat und der Nachweis, dass der Server den passenden privaten Schlüssel besitzt. Der Client prüft das Zertifikat gegen die Zertifizierungsstellen, denen er vertraut, und die Anwendungsdaten beginnen. ClientHello und ServerHello laufen unverschlüsselt, deshalb kann ein passiver Sensor die TLS-Version, die gewählte Gruppe für den Schlüsselaustausch, etwa klassisch X25519 oder hybrid X25519MLKEM768, und einen Client-Fingerprint sehen, ohne etwas zu entschlüsseln. Mit Encrypted Client Hello wird auch ein Teil des ClientHello, einschließlich des Servernamens, verborgen.

https://netsenx.com/de/faq/how-does-a-tls-handshake-work

## Was hat sich zwischen TLS 1.2 und TLS 1.3 geändert?

TLS 1.3 (RFC 8446, 2018) ist schneller und entfernt die schwachen Optionen, die hinter den meisten früheren TLS-Angriffen standen. Der Handshake ist nach einem statt zwei Hin- und Rückwegen fertig. Es bleiben nur Schlüsselaustausche mit Forward Secrecy, sodass Aufzeichnen und späteres Stehlen des privaten Serverschlüssels vergangene Sitzungen nicht mehr entschlüsselt. Alte Chiffren und Modi wie RC4, 3DES, CBC-Suites und statischer RSA-Schlüsselaustausch fallen weg, übrig bleibt eine kurze Liste moderner authentifizierter Chiffren. Und mehr vom Handshake ist verschlüsselt, auch das Serverzertifikat. Für die Überwachung folgt zweierlei. Ein passives Gerät kann Sitzungen nicht mehr mit einer Kopie des privaten Serverschlüssels entschlüsseln; Inspection braucht nun einen aktiven Abfang-Proxy. Und weniger ist im Klartext sichtbar: Das Zertifikat ist verborgen, während die Hello-Nachrichten, die gewählte Gruppe und der Servername, sofern kein Encrypted Client Hello genutzt wird, sichtbar bleiben. Bevorzugen Sie überall TLS 1.3 und behalten Sie TLS 1.2 nur mit starken Cipher-Suites für ältere Clients.

https://netsenx.com/de/faq/what-changed-between-tls-1-2-and-tls-1-3

## Sollten wir TLS 1.0 und 1.1 abschalten?

Ja. Beide sind von der IETF seit RFC 8996 (März 2021) formell abgekündigt, große Browser akzeptieren sie nicht mehr, und sie beruhen auf alten Hashfunktionen und Chiffre-Konstruktionen mit bekannten Schwächen. Sind sie auf einem Server noch aktiv, ist das Risiko weniger ein direkter Angriff als ein Downgrade-Pfad und ein Zeichen von Vernachlässigung, das Prüfer, Versicherer und Scanner bemängeln. Finden Sie vor dem Abschalten heraus, wer sie noch nutzt: alte Drucker, Scanner, Industriegeräte, Altanwendungen und eingebettete Clients sind die üblichen Verdächtigen, und ein Abschalten ohne Prüfung kann eine Produktionslinie oder ein Kartenterminal stoppen. Sehen Sie in Server-Logs nach, die die TLS-Version festhalten, prüfen Sie öffentliche Dienste mit einem externen Scanner und schauen Sie im internen Netz auf die TLS-Versionen in den Handshakes. Schalten Sie dann ab oder isolieren Sie, was sich nicht aktualisieren lässt, in einem eigenen Segment mit einem Plan für den Ersatz. Dieselbe Bestandsaufnahme dient später Ihrer Post-Quanten-Arbeit.

https://netsenx.com/de/faq/should-we-disable-tls-1-0-and-1-1

## Welche TLS-Chiffren sollten wir abschalten?

Alles ohne Forward Secrecy oder authentifizierte Verschlüsselung und alles von den alten Listen. Konkret: Schalten Sie RC4 ab, das RFC 7465 in TLS verbietet, ebenso 3DES und andere 64-Bit-Blockchiffren, Export- und NULL-Chiffren, statischen RSA-Schlüsselaustausch und CBC-Suites mit SHA-1, soweit Ihre Clients es zulassen. Behalten Sie die TLS-1.3-Suites AES-GCM und ChaCha20-Poly1305 und nutzen Sie für TLS 1.2 ECDHE-Schlüsselaustausch mit AES-GCM oder ChaCha20-Poly1305. Verwenden Sie veröffentlichte Konfigurationsleitfäden, statt eigene zu erfinden: Die Server-Side-TLS-Empfehlungen von Mozilla und die Technischen Richtlinien von Behörden wie dem BSI liefern erprobte Profile für moderne und ältere Clients. Prüfen Sie vor einer Änderung an einem Produktivserver, welche Clients sich verbinden und was sie anbieten, aus Server-Logs oder einem Blick auf die Handshakes, damit Sie kein altes Gerät aussperren. Testen Sie danach von außen mit einem TLS-Scanner und aktivieren Sie die hybride Gruppe X25519MLKEM768, wo Ihre Software sie unterstützt.

https://netsenx.com/de/faq/which-tls-ciphers-should-we-turn-off

## Was ist Forward Secrecy?

Forward Secrecy bedeutet, dass jede Sitzung einen frischen, temporären Schlüssel nutzt, der danach verworfen wird; wer später den langfristigen privaten Schlüssel eines Servers stiehlt, kann früher aufgezeichnete Sitzungen nicht entschlüsseln. Sie entsteht durch ephemere Schlüsselaustausche wie ECDHE oder X25519: Der langfristige Schlüssel belegt nur die Identität des Servers, der Sitzungsschlüssel kommt aus Wegwerfwerten beider Seiten. Ältere TLS-Konfigurationen mit statischem RSA-Schlüsselaustausch hatten sie nicht, sodass ein einziger gestohlener Schlüssel Jahre aufgezeichneten Verkehrs öffnen konnte. TLS 1.3 schreibt Forward Secrecy vor, und gut konfigurierte TLS-1.2-Server bieten sie ebenfalls. Das erklärt auch, warum es bei „Harvest now, decrypt later“ um den Schlüsselaustausch geht: Forward Secrecy schützt vor einem künftigen Schlüsseldiebstahl, nicht aber vor einem künftigen Quantencomputer, der den ephemeren Austausch auf elliptischen Kurven selbst bricht. Hybrider Post-Quanten-Schlüsselaustausch behält Forward Secrecy und ergänzt den fehlenden Schutz. Prüfen Sie Ihre Server mit einem TLS-Scanner: Jede angebotene Suite sollte sie haben.

https://netsenx.com/de/faq/what-is-forward-secrecy

## Was ist Verschlüsselung, einfach erklärt?

Verschlüsselung verwandelt lesbare Daten in durcheinandergebrachte Daten, die nur jemand mit dem richtigen Schlüssel zurückverwandeln kann. Das Verfahren, der Algorithmus, ist öffentlich; geheim ist der Schlüssel. Gute Verschlüsselung heißt: Ohne Schlüssel kann selbst ein leistungsstarker Computer die Daten in keiner brauchbaren Zeit wiederherstellen. Sie nutzen sie täglich: HTTPS auf Websites, das VPN ins Büro, Messenger, Festplattenverschlüsselung auf Laptops und Telefonen und Backups. Sie schützt Daten unterwegs vor jedem, der im Netz mithören kann, und gespeicherte Daten vor jedem, der die Festplatte stiehlt. Sie schützt Daten nicht vor jemandem, der den Schlüssel schon hat oder ein Gerät kontrolliert, auf dem die Daten entschlüsselt werden, etwa Schadsoftware auf einem angemeldeten Laptop. Deshalb steht Verschlüsselung neben Zugriffskontrolle, Patches und Überwachung, statt sie zu ersetzen. Ein Netzwerksensor sieht, dass verschlüsselte Verbindungen stattfinden, mit ihren Metadaten, nicht aber ihren Inhalt.

https://netsenx.com/de/faq/what-is-encryption-in-plain-terms

## Was ist der Unterschied zwischen symmetrischer und asymmetrischer Verschlüsselung?

Symmetrische Verschlüsselung nutzt einen gemeinsamen Schlüssel zum Ver- und Entschlüsseln; asymmetrische oder Public-Key-Verschlüsselung nutzt ein Paar: einen öffentlichen Schlüssel, den jeder kennen darf, und einen privaten, den nur der Inhaber hat. Symmetrische Algorithmen wie AES sind schnell und verschlüsseln fast alle echten Daten. Ihr Schwachpunkt ist die sichere Weitergabe des Schlüssels. Das lösen Public-Key-Verfahren wie RSA, Diffie-Hellman auf elliptischen Kurven und ihre Post-Quanten-Nachfolger: Zwei Parteien, die sich nie begegnet sind, können über ein offenes Netz einen frischen symmetrischen Schlüssel vereinbaren, und mit einem privaten Schlüssel lassen sich Daten so signieren, dass jeder mit dem öffentlichen Schlüssel sie prüfen kann. Echte Protokolle kombinieren beides. Eine TLS-Verbindung nutzt im Handshake Public-Key-Kryptografie, um einen Schlüssel zu vereinbaren und die Identität des Servers zu belegen, und wechselt dann für die Daten zu AES oder ChaCha20. Diese Aufteilung erklärt auch die Quantengeschichte: Shors Algorithmus bedroht den Public-Key-Teil, symmetrische Verschlüsselung mit 256-Bit-Schlüsseln bleibt stark.

https://netsenx.com/de/faq/what-is-the-difference-between-symmetric-and-asymmetric-encryption

## Wie lang sollte ein Schlüssel sein?

Das hängt von der Art des Algorithmus ab, denn Längen lassen sich zwischen den Arten nicht vergleichen. Bei symmetrischer Verschlüsselung gilt AES-128 weiterhin als stark, AES-256 bietet zusätzlichen Spielraum, auch gegenüber künftigen Quantencomputern; nutzen Sie 256 Bit für Daten, die viele Jahre geheim bleiben müssen. Bei RSA sind heute 2048 Bit das übliche Minimum, und Behörden wie das BSI empfehlen für längeren Schutz mindestens 3000 Bit. Schlüssel auf elliptischen Kurven sind bei gleicher Stärke viel kürzer: Eine 256-Bit-Kurve wie P-256 oder X25519 entspricht ungefähr RSA mit rund 3000 Bit. Zum Hashen nutzen Sie SHA-256 oder stärker. Zwei Vorbehalte zählen mehr als die Zahlen. Schlüssellänge hilft nicht, wenn der Schlüssel schlecht erzeugt, in einem Skript abgelegt oder nie gewechselt wird. Und RSA und elliptische Kurven jeder Länge fallen einem großen Quantencomputer zum Opfer; ihr langfristiger Ersatz sind daher Post-Quanten-Algorithmen, nicht längere Schlüssel. Genaue Werte entnehmen Sie den aktuellen Technischen Richtlinien Ihrer nationalen Behörde.

https://netsenx.com/de/faq/how-long-should-an-encryption-key-be

## Was ist eine Hashfunktion?

Eine Hashfunktion verwandelt beliebig viele Daten in einen kurzen Fingerabdruck fester Länge, etwa die 256-Bit-Ausgabe von SHA-256. Dieselbe Eingabe ergibt immer denselben Hash, eine winzige Änderung einen völlig anderen, und niemand kann aus dem Hash auf die Eingabe zurückschließen oder zwei Eingaben mit demselben Hash finden. Deshalb eignen sich Hashes, um zu prüfen, dass ein Download oder Backup unverändert ist, für digitale Signaturen, die den Hash eines Dokuments signieren, zur sicheren Speicherung von Passwörtern und für die Integritätsprüfungen in TLS. Alte Funktionen sind gescheitert: MD5 und SHA-1 sind für Sicherheitszwecke gebrochen, 2017 wurde eine öffentliche SHA-1-Kollision vorgeführt; behandeln Sie sie überall als Altlast, wo sie noch auftauchen, etwa in alten Zertifikaten oder Dateiprüfungen. SHA-256, SHA-384 und SHA-3 sind aktuelle Wahl. Ein Hash ist keine Verschlüsselung: Es gibt keinen Schlüssel und nichts zu entschlüsseln. Quantencomputer schwächen Hashfunktionen nur moderat.

https://netsenx.com/de/faq/what-is-a-hash-function

## Ist Hashen bei Passwörtern dasselbe wie Verschlüsseln?

Nein, und bei Passwörtern ist Hashen die richtige Wahl. Verschlüsselung lässt sich mit einem Schlüssel umkehren; wer verschlüsselte Passwörter samt Schlüssel stiehlt, hat alle Passwörter zurück. Einen Hash kann man nicht umkehren, das System speichert also nur den Hash und vergleicht ihn bei der Anmeldung. Gewöhnliche schnelle Hashes wie SHA-256 sind für Passwörter trotzdem eine schlechte Wahl, weil Angreifer mit einer gestohlenen Datenbank auf Grafikkarten enorme Mengen Versuche pro Sekunde durchprobieren können. Nutzen Sie eine Funktion, die für Passwörter gebaut ist, absichtlich langsam und mit einem zufälligen Salt pro Nutzer: Argon2id, scrypt oder bcrypt, wie es der OWASP-Leitfaden zur Passwortspeicherung empfiehlt. Speichert ein Lieferant oder eine Altanwendung Passwörter verschlüsselt oder nur mit MD5 oder SHA-1 gehasht, behandeln Sie das als zu behebenden Befund. Für Ihre eigenen Mitarbeitenden liegt der größere Gewinn woanders: Mehr-Faktor-Authentisierung (MFA), ein Passwortmanager und das Sperren wiederverwendeter Passwörter. Ein Netzwerksensor sieht nicht, wie ein Server Passwörter speichert; das gehört in eine Anwendungsprüfung.

https://netsenx.com/de/faq/is-hashing-the-same-as-encryption-for-passwords

## Was ist eine digitale Signatur?

Eine digitale Signatur ist ein Wert, der mit einem privaten Schlüssel aus Daten berechnet wird und den jeder mit dem passenden öffentlichen Schlüssel prüfen kann. Gelingt die Prüfung, ist zweierlei belegt: Die Daten stammen vom Inhaber dieses privaten Schlüssels, und sie wurden seit dem Signieren nicht verändert. Signaturen schützen vieles, worauf Sie sich verlassen, ohne es zu merken: Software-Updates und Treiber, die TLS-Zertifikate, die die Identität einer Website belegen, signierte PDFs und E-Rechnungen, mit S/MIME signierte E-Mails und den Code, den Ihre Entwickler ausliefern. In der EU haben qualifizierte elektronische Signaturen nach der eIDAS-Verordnung zudem rechtliche Wirkung. Eine Signatur ist nur so vertrauenswürdig wie ihr privater Schlüssel: Wird er gestohlen, kann ein Angreifer Schadsoftware signieren, die echt aussieht; deshalb gehören Signaturschlüssel in Hardware-Sicherheitsmodule oder ähnlich geschützte Speicher, und nur wenige Personen sollten sie nutzen können. Heutige Signaturen nutzen RSA oder elliptische Kurven, die ein großer Quantencomputer brechen würde; ihre Post-Quanten-Nachfolger sind ML-DSA und SLH-DSA.

https://netsenx.com/de/faq/what-is-a-digital-signature

## Was ist ein TLS-Zertifikat?

Ein TLS-Zertifikat ist ein signiertes Dokument, das einen öffentlichen Schlüssel an einen Namen bindet, etwa www.example.com, damit ein Browser oder Client prüfen kann, dass er mit dem echten Server spricht und nicht mit einem Betrüger. Die Signatur stammt von einer Zertifizierungsstelle (CA), der der Client bereits vertraut, meist über eine Kette: eine Stamm-CA, eine Zwischen-CA und dann das eigene Zertifikat des Servers. Im Handshake legt der Server sein Zertifikat vor und belegt, dass er den passenden privaten Schlüssel besitzt. Zertifikate haben ein Ablaufdatum und können widerrufen werden. Was ein Zertifikat nicht belegt: dass die Website sicher oder ehrlich ist. Eine Phishing-Seite kann ein völlig gültiges Zertifikat haben, weil CAs meist nur die Kontrolle über die Domain prüfen, nicht das Unternehmen dahinter. In Unternehmen stellt oft eine interne CA Zertifikate für Server, VPNs und Geräte aus. Führen Sie ein Inventar aller Zertifikate mit Verantwortlichen und Ablaufdaten; vergessene verursachen Ausfälle und verbergen schwache Schlüssel.

https://netsenx.com/de/faq/what-is-a-tls-certificate

## Was passiert, wenn ein TLS-Zertifikat abläuft?

Clients vertrauen dem Server nicht mehr: Browser zeigen eine ganzseitige Warnung, und Apps, APIs, VPN-Clients und Geräte verweigern die Verbindung meist ganz. Für Nutzer sieht es wie ein Ausfall aus, und praktisch ist es einer: Bezahlseiten, Kundenportale, Mailserver und Maschine-zu-Maschine-Verbindungen können im Moment des Ablaufs ausfallen, oft nachts oder am Wochenende. Abgelaufene Zertifikate gewöhnen Mitarbeitende außerdem daran, Warnungen wegzuklicken, genau das, was ein Angreifer beim Abfangen von Verkehr will. Die Lösung ist Prozess, nicht Heldentum: ein Inventar jedes Zertifikats mit Verantwortlichem und Ablaufdatum, frühzeitige Warnungen und automatische Erneuerung über das ACME-Protokoll (RFC 8555), wo immer die Plattform es unterstützt. Vergessen Sie nicht die Zertifikate in Appliances, Druckern, internen Diensten und der Code-Signierung, die externe Scanner nie sehen. Ein Blick auf die TLS-Handshakes im internen Netz hilft, Server zu finden, die niemand aufgelistet hat, wobei bei TLS 1.3 das Zertifikat selbst verschlüsselt ist und auf dem Server geprüft werden muss.

https://netsenx.com/de/faq/what-happens-when-a-tls-certificate-expires

## Warum werden TLS-Zertifikate immer kürzer gültig?

Weil kürzere Laufzeiten den Schaden durch einen gestohlenen Schlüssel oder ein falsch ausgestelltes Zertifikat begrenzen und alle zur Automatisierung der Erneuerung drängen. Im April 2025 hat das CA/Browser Forum, das Gremium aus Zertifizierungsstellen und Browserherstellern, das die Regeln für öffentliche TLS-Zertifikate festlegt, den Beschluss SC-081 angenommen: Die maximale Laufzeit sinkt von 398 auf 200 Tage ab 15. März 2026, auf 100 Tage ab 15. März 2027 und auf 47 Tage ab 15. März 2029. Die Regeln gelten für öffentlich vertrauenswürdige Zertifikate, nicht für solche aus Ihrer eigenen internen CA. Für ein Unternehmen, das Zertifikate noch einmal im Jahr von Hand erneuert, ändert das den Aufwand: Erneuerungen werden häufig, und manuelle Abläufe werden scheitern. Die Antwort ist Automatisierung über ACME (RFC 8555) oder die Werkzeuge Ihres Anbieters, ein Inventar jedes öffentlichen Zertifikats und seines Einsatzorts, einschließlich Load Balancern und Appliances, sowie eine Überwachung der Ablaufdaten. Sehen Sie es als Übung in Krypto-Agilität: Dieselbe Disziplin hilft beim Post-Quanten-Übergang.

https://netsenx.com/de/faq/why-are-tls-certificate-lifetimes-getting-shorter

## Sind selbstsignierte Zertifikate auf internen Servern ein Problem?

Nicht weil sie selbstsigniert sind, sondern wegen dessen, was meist mit ihnen einhergeht. Ein selbstsigniertes Zertifikat verschlüsselt so gut wie jedes andere; das Problem ist das Vertrauen. Clients können es nicht gegen eine bekannte Stelle prüfen, also lernen Nutzer und Admins, Warnungen wegzuklicken oder die Prüfung in Skripten abzuschalten, und dieselbe Gewohnheit lässt ein echtes Abfangen unbemerkt. Selbstsignierte Zertifikate auf Appliances haben oft schwache oder voreingestellte Schlüssel, keine Ablaufverfolgung und keinen Verantwortlichen. Besser ist eine interne Zertifizierungsstelle, die nach Möglichkeit automatisiert ausstellt, deren Stammzertifikat auf verwaltete Geräte verteilt ist, mit einem Inventar aller Zertifikate und ihrer Ablaufdaten. Bei Geräten, die nur mit selbstsignierten Zertifikaten kommen, etwa Druckern oder Steuerungen, ersetzen Sie das Zertifikat, wo das Gerät es erlaubt, und halten das Gerät in einem Segment mit eingeschränktem Zugriff. Selbstsignierte Zertifikate gehören auch in Ihr Post-Quanten-Inventar: Jedes hat einen Schlüsseltyp und eine Länge, die eines Tages wechseln müssen.

https://netsenx.com/de/faq/are-self-signed-certificates-on-internal-servers-a-problem

## Was ist Mutual TLS (mTLS)?

Mutual TLS bedeutet, dass beide Seiten einer Verbindung Zertifikate vorlegen: Der Server weist dem Client seine Identität nach und der Client dem Server. Bei gewöhnlichem HTTPS hat nur der Server ein Zertifikat, und der Nutzer weist sich später mit Passwort oder Token aus. Bei mTLS braucht der Client einen privaten Schlüssel und ein Zertifikat einer Stelle, der der Server vertraut, was sich schwer phishen und leicht widerrufen lässt. Verbreitet ist es zwischen Diensten in Microservice-Architekturen, bei APIs zwischen Unternehmen, für Geräteidentitäten in IoT und OT und in manchen Zero-Trust-Produkten für den Fernzugriff. Die Kosten sind Zertifikatsverwaltung im großen Maßstab, also Ausstellen, Rotieren und Widerrufen von Client-Zertifikaten, und Fehlersuche, wenn etwas abläuft. Im Netz sieht mTLS wie normales TLS aus. Bei TLS 1.3 ist das Client-Zertifikat verschlüsselt; ein passiver Sensor sieht also, dass die Verbindung besteht, und ihre Handshake-Parameter, nicht aber, welches Client-Zertifikat verwendet wurde.

https://netsenx.com/de/faq/what-is-mutual-tls

## Verschlüsselt ein VPN alles, was wir senden?

Es verschlüsselt den Verkehr zwischen Ihrem Gerät und dem VPN-Gateway, nicht den ganzen Weg bis zum Ziel. Hinter dem Gateway läuft der Verkehr ins Büronetz oder ins Internet weiter, geschützt nur durch das, was die Anwendung selbst nutzt, etwa HTTPS. Ein Firmen-VPN schützt Mitarbeitende im Hotel- oder Café-WLAN also vor lokalem Mithören und gibt ihnen Zugang zu internen Systemen; es macht eine unverschlüsselte interne Anwendung nicht sicher und verbirgt nichts vor dem Firmennetz, das den Verkehr empfängt. Split Tunneling schickt nur einen Teil des Verkehrs durch das VPN und den Rest direkt, was der Leistung hilft, aber bedeutet, dass die Überwachung im Unternehmen nur einen Teil sieht. Ein kommerzieller VPN-Dienst verlagert Ihr Vertrauen vom Internetanbieter auf den VPN-Anbieter. VPN-Gateways selbst sind häufige Angriffsziele und brauchen schnelle Patches und Mehr-Faktor-Authentisierung (MFA). Im Netz sind VPN-Tunnel als Verbindungen zum Gateway sichtbar, mit Zeitpunkt und Volumen, nicht mit ihrem Inhalt.

https://netsenx.com/de/faq/does-a-vpn-encrypt-everything-we-send

## Wie finde ich alle SSH-Server in unserem Netz, auch vergessene?

Kombinieren Sie einen aktiven Scan mit passiver Beobachtung, denn jedes findet, was das andere übersieht. Ein genehmigter Scan Ihrer Adressbereiche auf Port 22 und andere übliche SSH-Ports, mit einem Werkzeug wie Nmap, listet jeden antwortenden Host und die Softwareversion, die er ankündigt. Prüfen Sie Cloud-Konsolen und DNS-Einträge auf Server außerhalb der Büro-Adressbereiche. Passive Beobachtung ergänzt, was Scans übersehen: SSH auf ungewöhnlichen Ports, Server, die nur aus bestimmten Segmenten erreichbar sind, und wie SSH tatsächlich genutzt wird, also welche Clients sich wann mit welchen Servern verbinden. Gehen Sie die Liste dann mit den Verantwortlichen durch: Jeder Server braucht eine benannte Person, einen Grund zu existieren und einen Patch-Plan, und was niemand beansprucht, wird nach einer Ankündigungsfrist abgeschaltet. Beschränken Sie SSH auf Admin-Netze oder einen Jump-Host und nutzen Sie Schlüssel statt Passwörter. NetSenX alarmiert in jedem Plan, wenn ein Host beginnt, viele interne Hosts auf Administrationsports wie SSH zu erreichen, denn so sehen Scans und laterale Bewegung aus.

https://netsenx.com/de/faq/how-to-find-all-ssh-servers-on-the-network

## Wie prüfe ich, welche Server eine von einer neuen CVE betroffene OpenSSH-Version nutzen?

Beginnen Sie mit der Version, die jeder Server ankündigt, und bestätigen Sie sie dann am Patch-Stand des Herstellers, denn die Ankündigung allein kann täuschen. Jeder SSH-Server sendet vor allem anderen eine Kennung wie SSH-2.0-OpenSSH_9.6p1, die ein Scanner oder eine einfache Verbindung anzeigt. Vergleichen Sie diese Version mit dem Bereich in der Sicherheitsmeldung. Für regreSSHion (CVE-2024-6387) nannte etwa die von Qualys am 1. Juli 2024 veröffentlichte Meldung OpenSSH ab 8.5p1 bis ausschließlich 9.8p1 auf glibc-basiertem Linux. Prüfen Sie dann die Paketversion auf jedem Server: Linux-Distributionen portieren Sicherheitskorrekturen oft in eine ältere Versionsnummer zurück; ein Server, der eine betroffene Version ankündigt, kann also schon gepatcht sein, und maßgeblich ist der Security-Tracker der Distribution. Patchen Sie über den Paketmanager, starten Sie den Dienst neu und prüfen Sie erneut. Führen Sie eine Liste der SSH-Server in Ihrem Inventar, damit die nächste Meldung Minuten statt Tage kostet.

https://netsenx.com/de/faq/how-to-check-openssh-versions-against-a-new-cve

## Beweist ein SSH-Versionsbanner, dass ein Server verwundbar ist?

Nein. Es ist ein starker Hinweis, kein Beweis, und zwar in beide Richtungen. Das Banner ist der Text, den ein Server über seine Software ankündigt, etwa OpenSSH_8.9p1 Ubuntu-3ubuntu0.10. Linux-Distributionen beheben Sicherheitslücken oft, indem sie die alte Version patchen, statt auf die neue Upstream-Version zu wechseln; ein Server kann also eine als betroffen gelistete Version ankündigen und trotzdem sicher sein, worüber das Paketsuffix der Distribution und ihr Security-Tracker Auskunft geben. Das Banner kann auch von einem Administrator geändert oder verborgen werden, und manche Appliances melden irreführende Zeichenketten. Umgekehrt schließt eine aktuelle Versionsnummer Konfigurationsprobleme nicht aus, etwa Passwort-Anmeldungen, die aus dem Internet erreichbar sind, oder schwache Host-Schlüssel. Nutzen Sie das Banner, um Server in zuerst zu prüfende und vermutlich unkritische einzuteilen, und bestätigen Sie dann auf dem Host mit dem Paketmanager oder einem authentifizierten Schwachstellenscan. Melden Sie der Geschäftsleitung einen Server nie allein aufgrund seines Banners als kompromittiert oder verwundbar.

https://netsenx.com/de/faq/does-an-ssh-version-banner-prove-a-server-is-vulnerable

FAQ: https://netsenx.com/de/faq