Datenhaufen zu IT und Elektronik.

Schlagwort: Security (Seite 1 von 4)

GeoGuessr im Cyber-Sicherheitskontext: Wie IP-Kameras zum Risiko werden können

Die meisten von euch werden das Spiel GeoGuessr kennen. Man bekommt ein Google-Street-View-Bild gezeigt, kann sich vielleicht noch ein paar Meter hin- und herbewegen und muss dann auf einer Weltkarte einen Marker setzen, wo man meint, dass dieses Bild aufgenommen wurde. Wer dem Punkt am nächsten kommt, gewinnt.

Eine etwas abgewandelte Version begegnet mir immer mal wieder, wenn ich mich an einem Bug-Bounty-Programm beteilige oder einfach mit offenen Augen durchs Internet spaziere. Damit ist natürlich kein aktives Port-Scanning auf Netzblöcke oder Ähnliches gemeint.

Worum geht es genau?

In den letzten Jahren verbreiten sich immer mehr billige „China-Kameras“ bei Heimanwendern, aber auch bei Unternehmen. Dagegen spricht erst einmal nichts.

Was leider oft übersehen wird, sind die kleinen automatischen Helferlein, die die Einrichtung und den Betrieb einer solchen Kamera möglichst einfach machen sollen. UPnP (Universal Plug and Play) haben manche vielleicht schon mal im Zusammenhang mit Windows 95 oder USB gehört (ja, ich bin alt …). So etwas gibt es aber auch für Router und Firewalls, also für Netzwerke. Bei einer Fritzbox nennt sich das beispielsweise „Automatische Portfreigabe“.

Der eine oder andere ahnt jetzt sicher schon etwas: Es gibt IP-Kameras, die sich so – vielleicht sogar ohne das Wissen des Betreibers – selbst über das Internet erreichbar machen. Das betrifft nicht selten die komplette Weboberfläche. Mal ist diese kennwortgeschützt, mal nicht.

Sehr oft findet sich auch nur der RTSP-Port (Real Time Streaming Protocol) offen im Internet. Per RTSP werfen solche Kameras oft einen einfachen Videostream aus, der die Anbindung an zentrale Videoüberwachungssysteme erlaubt. Auch RTSP-Streams lassen sich mit einer Anmeldung schützen, was aber scheinbar in der Regel werkseitig deaktiviert ist.

Wenn dieser Port offen ist, könnte man sich einfach per ffplay einen solchen Stream anschauen:

ffplay rtsp://1.2.3.4/11

Wenn man sich nicht sicher ist, wie die korrekte RTSP-URL für die jeweilige IP-Kamera lautet, kann nmap zusammen mit dem Script rtsp-url-brute helfen:

nmap --script rtsp-url-brute -p 554 1.2.3.4

Die rechtliche Lage

Nun kann es natürlich rechtlich schwierig sein, bei einer fremden IP-Adresse nach dem offenen Port 554/TCP zu suchen, dort per nmap nach einer nutzbaren RTSP-URL zu scannen und sich den Stream dann live per ffplay, nmap oder vlc anzuschauen. Schließlich hat man nicht das Einverständnis des Betreibers.

Screenshot of shodan search engine, filtering for RTSP Streams.

Natürlich hält das wohl weniger Menschen ab, die ohnehin Schlechtes im Sinn haben. Ebenfalls gibt es verschiedene Dienste, die 24/7 nichts anderes tun. Ein Beispiel ist hier vielleicht shodan.io – dort lässt sich direkt nach solchen Vorschaubildern filtern, ohne dass man selbst eine Verbindung zu betroffenen IPs aufnehmen muss.

Warum ist das alles überhaupt problematisch?

Hat ein Angreifer Böses im Sinn, ist ein Zugriff auf die Überwachungskamera sehr hilfreich. Man kommt so möglicherweise an Insiderinformationen, findet heraus, wo wertvolle Dinge gelagert werden, wann und wie die Öffnungszeiten sind oder sogar mögliche Zugangscodes und Kennwörter. Natürlich auch, welche Kunden sich zu welcher Zeit dort aufhalten usw.

Denkt man an eine Arztpraxis, kann das schnell eine echte Datenschutzkatastrophe werden. Wenn die Kamera im Wohnzimmer oder Schlafzimmer einer Wohnung steht, führt das ebenfalls schnell zu ungewollten Einblicken.

Wenn man einmal außer Acht lässt, dass niemand gerne ohne sein Wissen per Livestream im Internet zu sehen ist, halte ich das Thema Datenschutz für eines der größten Risiken.

In der Vergangenheit sind mir bereits Beispiele begegnet, die das Problem verdeutlichen: Arztpraxen mit Kamerablick von hinten auf die Anmeldung – inklusive direktem Blick auf Patienten, Monitore mit Patientendaten oder Vertragsabschlüsse bei Mobilfunkanbietern. Auch Überwachungskameras in DHL-Filialen, die Bild und Ton in Zoom und 4K aufzeichnen, habe ich gesehen.

Für private Betreiber kann es ebenfalls schnell zu einem Datenschutzproblem werden. Nicht jeder achtet beim eingestellten Bildausschnitt der Kamera darauf, die Vorgaben des Datenschutzes einzuhalten. So werden oft mehr öffentliche Bereiche oder sogar Nachbargrundstücke gefilmt, als zulässig ist.

Wenn diese Daten dann auch noch ohne Schutz und Hürden in die Hände Dritter geraten, wird es heikel. Hier sollte besser jemand mit rechtlichem Hintergrund eine Einschätzung abgeben. Für mich klingt das alles jedenfalls ziemlich unschön.

Was kann man tun?

Eine Abuse-Mail an den jeweiligen ISP (Internet Service Provider) schicken, mit der Bitte, ihre Kunden zu informieren? Kann man machen. Bei kleineren ISPs klappt das oft sogar, und die Betreiber werden informiert. Spricht man aber über einen großen ISP wie die Telekom, verschwinden einzelne Abuse-Mails gefühlt einfach im Nichts.

Sonst jemanden zu finden, der ein Interesse daran hat, den meist unwissenden Betreiber zu informieren, ist nahezu unmöglich. Weder unsere Behörden noch das BSI interessieren sich dafür. Möchte man also den Betreiber darauf hinweisen, bleibt realistisch nur die Möglichkeit, ihn selbst zu kontaktieren.

GeoGuessr in der Praxis

Jetzt sind wir beim Thema GeoGuessr: Man hat also nur das Bild der Kamera, die IP-Adresse mit einer recht groben und nicht immer stimmigen Geolokalisierung und vielleicht noch ein paar weitere Rahmeninfos oder Dienste auf dieser IP-Adresse. Hin und wieder macht es mir daher sogar Spaß, den eigentlichen Betreiber ausfindig zu machen und ihm per E-Mail oder telefonisch kurz auf diesen möglichen Missstand hinzuweisen.

Wenn du das also gerade liest, weil ich dich darauf hingewiesen habe, weißt du jetzt, warum 😀

Natürlich trifft man oft auf Unverständnis – oder das klassisch deutsche „Anzeige ist raus!“ begegnet einem immer mal wieder. Es bietet also auch eine gute Möglichkeit, die eigenen Kommunikationsskills zu erweitern.

Dual Boot mit Linux und Windows: BitLocker für die Systemplatte auf Passwort umstellen

Die Feiertage sind da, und ich hatte tatsächlich etwas Zeit zum Zocken. Früher hatte ich dafür einen eigenen Rechner, heute reicht ein Dual Boot. Gearbeitet wird unter Linux, gezockt unter Windows. Dafür habe ich mein Windows auf einer gesonderten SSD installiert. Natürlich ist diese ebenfalls verschlüsselt, in diesem Fall mit BitLocker.

Illustration eines Dual-Boot-Systems mit Linux und Windows, dargestellt durch die Logos beider Betriebssysteme. Die Windows-Seite zeigt ein BitLocker-Schloss-Symbol, das auf die Verschlüsselung der Systemplatte hinweist.

Warum erzähle ich das? Na, weil die SSD irgendwann aufgegeben hat und ich mein Windows neu installieren darf. Ein Backup spare ich mir, da es eh nur zum Zocken ist.

Windows 11 war „schnell“ wieder installiert. Dann noch alle Treiber usw. – Gott, ist das noch immer alles aufwendig… Wie auch immer: Windows 11 und die Games sind drauf. Los geht’s!

Nun fragt mich mein BitLocker bei jedem Start der Betriebssystemfestplatte nach dem BitLocker-Wiederherstellungsschlüssel, wenn ich vorher in meinem Linux war. Da zuckt so eine Erinnerung durch mein Hirn: Das gleiche hatte ich schon mal, am gleichen Rechner. Wie hatte ich das damals gelöst? Ich habe nichts darüber geschrieben, also ist es einfach weg. Diesen Fehler mache ich nicht noch mal. Also liest du gerade etwas darüber. 😄

Der Ausgangspunkt: Ein Windows 11 Pro, installiert auf einer SSD, inkl. BitLocker-Verschlüsselung und TPM mit PIN. Warum PIN? Ich fühle mich einfach besser, wenn es noch eine manuelle Hürde zur Entschlüsselung gibt; Ist auch egal, soll ja nun weg.

Terminal als Administrator ausführen und dann:

C:\Windows\System32> manage-bde -status
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Datenträgervolumes, die mit BitLocker-Laufwerkverschlüsselung
geschützt werden können:
Volume "C:" [System]
[Betriebssystemvolume]

    Größe:                        465,00 GB
    BitLocker-Version:            2.0
    Konvertierungsstatus:         Nur verwendeter Speicherplatz ist verschlüsselt
    Verschlüsselt (Prozent):      100,0 %
    Verschlüsselungsmethode:      XTS-AES 128
    Schutzstatus:                 Der Schutz ist aktiviert.
    Sperrungsstatus:              Entsperrt
    ID-Feld:                      Unbekannt
    Schlüsselschutzvorrichtungen:
        Numerisches Kennwort
        TPM und PIN
        TPM
C:\Windows\System32>

Schlüsselschutzvorrichtungen sind also numerisches Kennwort, TPM und PIN, sowie TPM. Was fehlt? Richtig, das Password. Da ich nur das Password möchte, kann im Grunde alles weg. Damit Windows 11 mir erlaubt, TPM von meinem Betriebssystemvolume zu entfernen, muss ich vorher noch eine Gruppenrichtlinie anpassen.

Dafür einfach die Tastenkombination Win + S drücken und nach Gruppenrichtlinie bearbeiten suchen.

Editor für lokale Gruppenrichtlinien mit geöffneter Einstellung 'Zusätzliche Authentifizierung beim Start anfordern' unter 'Computerkonfiguration > Administrative Vorlagen > BitLocker-Laufwerkverschlüsselung > Betriebssystemlaufwerke'. Die Option ist aktiviert, um die BitLocker-Verschlüsselung ohne TPM zu ermöglichen.
Detailansicht der Gruppenrichtlinieneinstellung 'Zusätzliche Authentifizierung beim Start anfordern'. Die Option 'BitLocker ohne kompatibles TPM zulassen' ist aktiviert, und die Konfiguration für TPM-Start, Systemstartschlüssel und PIN wird angezeigt. Die Beschreibung auf der rechten Seite erläutert die Auswirkungen der Richtlinie.

Dann zu:
ComputerkonfigurationAdministrative VorlagenBitLocker-LaufwerkverschlüsselungBetriebssystemlaufwerkeZusätzliche Authentifizierung beim Start anfordern.

Hier die Einstellung so ändern, dass der Haken bei „BitLocker ohne kompatibles TPM zulassen“ gesetzt ist.

Im Anschluss sicherstellen, dass die neue Gruppenrichtlinie auch angewendet wird. Dazu im Administrator-Terminal einfach ein kurzes:

PS C:\WINDOWS\system32> gpupdate /force
Die Richtlinie wird aktualisiert...

Die Aktualisierung der Computerrichtlinie wurde erfolgreich abgeschlossen.
Die Aktualisierung der Benutzerrichtlinie wurde erfolgreich abgeschlossen.

PS C:\WINDOWS\system32>

So, jetzt wird’s spannend. Erstmal alle Schlüsselschutzvorrichtungen deaktivieren, dann löschen, die neue Schlüsselschutzvorrichtung Password hinzufügen und alles wieder aktivieren. Das Ganze natürlich im Administrator-Terminal. Ich starte damit, alle Schlüsselschutzvorrichtungen zu deaktivieren:

C:\Windows\System32>manage-bde -protectors -disable C:
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Die Schlüsselschutzvorrichtungen für Volume "C:" sind deaktiviert.

Als Nächstes schaue ich nach, welche Schlüsselschutzvorrichtungen auf meinem Betriebssystemvolume eingerichtet sind.

C:\Windows\System32>manage-bde -protectors -get C:
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Volume "C:" [System]
Alle Schlüsselschutzvorrichtungen

    Numerisches Kennwort:
      ID: {AF6C0AAD-B337-4519-8D66-C06386994D97}
      Kennwort:
        673101-147301-650001-335379-291368-420618-438350-305327
      Sicherungstyp:
        In Datei gespeichert

    TPM und PIN:
      ID: {D5F87162-5556-4C27-82F9-25B389DBAF1B}
      PCR-Validierungsprofil:
        0, 2, 4, 11

    TPM:
      ID: {CA1BF147-2C40-4934-9161-660FBB44BA2C}
      PCR-Validierungsprofil:
        0, 2, 4, 11

Jetzt lösche ich alle Schlüsselschutzvorrichtungen anhand ihrer IDs:

C:\Windows\System32>manage-bde -protectors -delete C: -id {D5F87162-5556-4C27-82F9-25B389DBAF1B}
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Volume "C:" [System]
Schlüsselschutzvorrichtung mit ID {D5F87162-5556-4C27-82F9-25B389DBAF1B}

    TPM und PIN:
      ID: {D5F87162-5556-4C27-82F9-25B389DBAF1B}
      PCR-Validierungsprofil:
        0, 2, 4, 11

Die Schlüsselschutzvorrichtung mit der ID "{D5F87162-5556-4C27-82F9-25B389DBAF1B}" wurde gelöscht.

C:\Windows\System32>manage-bde -protectors -delete C: -id {CA1BF147-2C40-4934-9161-660FBB44BA2C}
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Volume "C:" [System]
Schlüsselschutzvorrichtung mit ID {CA1BF147-2C40-4934-9161-660FBB44BA2C}

    TPM:
      ID: {CA1BF147-2C40-4934-9161-660FBB44BA2C}
      PCR-Validierungsprofil:
        0, 2, 4, 11

Die Schlüsselschutzvorrichtung mit der ID "{CA1BF147-2C40-4934-9161-660FBB44BA2C}" wurde gelöscht.

C:\Windows\System32>manage-bde -protectors -delete C: -id {AF6C0AAD-B337-4519-8D66-C06386994D97}
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Volume "C:" [System]
Schlüsselschutzvorrichtung mit ID {AF6C0AAD-B337-4519-8D66-C06386994D97}

    Numerisches Kennwort:
      ID: {AF6C0AAD-B337-4519-8D66-C06386994D97}
      Kennwort:
        673101-147301-650001-335379-291368-420618-438350-305327
      Sicherungstyp:
        In Datei gespeichert

Die Schlüsselschutzvorrichtung mit der ID "{AF6C0AAD-B337-4519-8D66-C06386994D97}" wurde gelöscht.

Wenn ich jetzt noch einmal kontrolliere, welche Schlüsselschutzvorrichtungen ich habe, sollten dort keine mehr stehen.

C:\Windows\System32>manage-bde -protectors -get C:
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Volume "C:" [System]
Alle Schlüsselschutzvorrichtungen

FEHLER: Es wurden keine Schlüsselschutzvorrichtungen gefunden.

Damit kann ich jetzt meine neue, gewünschte Schlüsselschutzvorrichtung Passwort hinzufügen.

C:\Windows\System32>manage-bde -protectors -add C: -password
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Geben Sie das Kennwort ein, das zum Schützen des Volumes verwendet werden soll:

Bestätigen Sie das Kennwort durch erneute Eingabe:

Hinzugefügte Schlüsselschutzvorrichtungen:

    Kennwort:
      ID: {4D141862-4C75-4321-AA6D-8BABB89C601C}

Bleibt nur noch, diese auch zu aktivieren.

C:\Windows\System32>manage-bde -protectors -enable C:
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Die Schlüsselschutzvorrichtungen für Volume "C:" sind aktiviert.

Wenn ich jetzt den BitLocker-Status prüfe, ist alles aktiv, und es gibt nur noch die Schlüsselschutzvorrichtung Kennwort / Password!

C:\Windows\System32>manage-bde -status
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Datenträgervolumes, die mit BitLocker-Laufwerkverschlüsselung
geschützt werden können:
Volume "C:" [System]
[Betriebssystemvolume]

    Größe:                        465,00 GB
    BitLocker-Version:            2.0
    Konvertierungsstatus:         Nur verwendeter Speicherplatz ist verschlüsselt
    Verschlüsselt (Prozent):      100,0 %
    Verschlüsselungsmethode:      XTS-AES 128
    Schutzstatus:                 Der Schutz ist aktiviert.
    Sperrungsstatus:              Entsperrt
    ID-Feld:                      Unbekannt
    Schlüsselschutzvorrichtungen:
        Kennwort

Starte ich meinen Computer und wähle im Grub Windows aus, werde ich danach nach meinem BitLocker-Kennwort gefragt, und das System fährt sauber hoch.

Fragen? Dann fragen 🙂

FreeBSD SSH-Server mit MFA/2FA: Sicherheit leicht gemacht

Dass man eigentlich keinen reinen Kennwort-Login für seine Anmeldung an einem SSH-Server haben möchte, ist sicherlich bei fast allen angekommen. Kennwörter lassen sich einfacher mittels eines Brute-Force-Angriffes herausfinden. Ebenso gehen diese auch mal verloren. SSH-Keys werden die meisten ebenfalls bereits aufseiten des Clients mit einem zweiten Faktor geschützt haben. Dies kann ein MFA-Token sein oder einfach eine Passphrase.

Hin und wieder lässt es sich aber nicht vermeiden, dass man seinen Login nur mit einer einfachen Kombination aus Benutzername und Kennwort sichert. Um dieses dennoch etwas aufzuwerten, lässt sich dieses ebenfalls mit MFA ausstatten. In diesem kurzen Beispiel geht es dabei um einen SSH-Server auf einem FreeBSD-System, welches nach der Authentifizierung mittels Benutzername/Kennwort noch nach einem Auth-Code vom Google Authenticator fragt.

Clientseitig ist eigentlich nichts weiter zu beachten. Auf Serverseite muss das Paket pam_google_authenticator installiert werden:

pkg install pam_google_authenticator

Ist die Installation abgeschlossen, müssen wir nun unsere PAM-Konfiguration für den SSHD-Password-Login erweitern. Oh, ja… Auf demselben Weg lässt sich dieses ebenfalls für den normalen Login an der Konsole, für su, ftp usw. einbinden. Selbstverständlich ebenfalls für den Login per SSH-Keys. Wir bleiben aber hier nun beim Login mit User/Pass. Meine /etc/pam.d/sshd sieht damit wie folgt aus:

#
#
# PAM configuration for the "sshd" service
#

# auth
#auth		sufficient	pam_krb5.so		no_warn try_first_pass
#auth		sufficient	pam_ssh.so		no_warn try_first_pass
auth		required	pam_unix.so		no_warn try_first_pass
auth            required        /usr/local/lib/pam_google_authenticator.so

# account
account		required	pam_nologin.so
#account	required	pam_krb5.so
account		required	pam_login_access.so
account		required	pam_unix.so

# session
#session	optional	pam_ssh.so		want_agent
session		required	pam_permit.so

# password
#password	sufficient	pam_krb5.so		no_warn try_first_pass
password	required	pam_unix.so		no_warn try_first_pass

Ebenfalls muss die folgende Option in der /etc/ssh/sshd_config aktiviert sein:

ChallengeResponseAuthentication yes

Das war es auch schon fast. Wenn man nun auf seinem Smartphone noch schnell den Google Authenticator installiert, können wir schon damit beginnen, den zweiten Faktor zu erstellen. Dafür einfach mit dem gewünschten Nutzer in dessen Home-Verzeichnis: „cd ~“ den google-authenticator aufrufen und den Anweisungen folgen:

Dieses nur noch mit der Authenticator-App am Smartphone scannen, den Code einmal eingeben und schon wird man bei jedem Kennwort-Login nach seinem aktuellen Code gefragt.

Oh, sehr ähnlich ist die Einrichtung unter Linux 🙂

Linux Mint und Ubuntu: DNSSEC aktivieren und sicher surfen

Heute habe ich versucht, mich von meiner neuen Linux Mint Installation aus mit einem meiner SSH-Server zu verbinden. Mein SSH-Client hat mich direkt mit der Frage begrüßt, ob ich dem neuen Hostkey vertrauen möchte oder nicht.

ssh username@hostname.kernel-error.org
The authenticity of host 'hostname.kernel-error.org (2a01:5a8:362:4416::32)' can't be established.
ED25519 key fingerprint is SHA256:kTRGVCMRLiHfvJunW2CbW5H3NZmn3Wkx2KnHJXl3iJu.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Für viele mag diese Meldung bekannt und vollkommen normal erscheinen. In der Regel antwortet man initial mit „yes“ und sieht sie nie wieder. Aber diese Meldung hat ihren Grund. Beim initialen Aufbau einer Verbindung zu einem SSH-Server wird einem der Fingerprint des HostKeys angezeigt. So hat man die Möglichkeit, den Fingerprint mit dem erwarteten Fingerprint abzugleichen, um sicherzustellen, dass man sich wirklich mit dem gewünschten SSH-Server verbindet und nicht etwa ein Angreifer Zugangsdaten abfischt. Wenn man eh immer nur „JA“ sagt, könnte man diesen Check auch direkt in seiner ~/.ssh/config mit folgendem Eintrag deaktivieren:

Host *
    StrictHostKeyChecking no

Warum erzähle ich das alles? Nun, weil es für mich eigentlich nicht normal ist, diese Meldung zu sehen. Denn es gibt die Möglichkeit, die Fingerprints der erwarteten HostKeys in seiner DNS-Zone zu hinterlegen und seinen SSH-Client mit der folgenden Konfiguration in seiner ~/.ssh/config anzuweisen, dies einfach selbst zu überprüfen, sofern der SSH-Client eine vertrauenswürdige Antwort vom DNS-Server erhält.

Host *
   VerifyHostKeyDNS yes

Vertrauenswürdige Antwort vom DNS-Server… Hier sind wir schon bei DNSSEC angekommen. Meine DNS-Server, einschließlich des lokalen Resolvers auf meinem Router, unterstützen alle DNSSEC. Meine SSH-Client-Konfiguration ist korrekt und dennoch erscheint die Meldung…. Also habe ich den Verbindungsaufbau mit etwas mehr Debugging-Output gestartet, was bei ssh einfach die zusätzliche Option -vvv bedeutet:

ssh usermane@hostname.kernel-error.org -vvv
[...]
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:kTRGVCMRLiHfvJunW2CbW5H3NZmn3Wkx2KnHJXl3iJu
debug3: verify_host_key_dns
debug1: found 2 insecure fingerprints in DNS
debug3: verify_host_key_dns: checking SSHFP type 4 fptype 1
debug1: verify_host_key_dns: matched SSHFP type 4 fptype 1
debug3: verify_host_key_dns: checking SSHFP type 4 fptype 2
debug1: verify_host_key_dns: matched SSHFP type 4 fptype 2
debug1: matching host key fingerprint found in DNS
[...]

Zu meiner Überraschung sehe ich:

debug1: found 2 insecure fingerprints in DNS

Hm… „insecure“… Er hat also die passenden Einträge in der DNS-Zone gefunden, kann diesen aber nicht vertrauen, weil… ja, warum? Die Antwort des DNS-Servers ist nicht vertrauenswürdig? OK, das lässt sich einfach mit dig und der Option +dnssec testen. Wir suchen einfach im Header nach „ad„:

dig +dnssec hostname.kernel-error.org @8.8.8.8

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> +dnssec hostname.kernel-error.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48645
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
[...]

@8.8.8.8 gibt an, dass direkt der öffentliche DNS-Server von Google gefragt wird. Dieser wird natürlich meine Server fragen usw., einfach um sicherzugehen, dass meine eigentlichen DNS-Server, die für die Zone zuständig sind, sauber konfiguriert sind. Ich sehe ein „ad„, also ist dort schon mal alles gut. Im Anschluss habe ich den Test noch mit meinem lokalen DNS-Resolver auf dem Router durchgeführt. Also einfach @192.168.0.1 oder was auch immer euer lokaler Router ist. Gleiches Ergebnis…. Aber warum will dann mein Linux Mint nicht? Sollte Linux Mint etwa kein DNSSEC können?

dig +dnssec hostname.kernel-error.org

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> +dnssec hostname.kernel-error.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1789
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
[...]

Öhhh ähhh… Ja, öhm, geht nicht… Aber warum? Was steht denn in meiner /etc/resolv.conf? 127.0.0.53? Ohhhhhhhh, stimmt! systemd-resolv! OK, ok… Ich könnte also in meiner /etc/systemd/resolved.conf nun einfach DNSSEC=yes setzen und mit einem systemctl restart systemd-resolved sollte dann… Nope, leider nicht. Nun geht überhaupt keine DNS-Auflösung mehr. Es scheint am eingesetzten Stub-Resolver zu liegen, den man ebenfalls noch ändern kann usw… Nennt mich etwas oldschool, aber für meine Zwecke reicht der klassische Weg über die vom NetworkManager gepflegte resolv.conf. Um also systemd-resolved zu deaktivieren und auf den NetworkManager zu wechseln, sind die folgenden Schritte nötig:

sudo systemctl disable systemd-resolved
sudo systemctl stop systemd-resolved
sudo rm /etc/resolv.conf

Dann in die Konfigurationsdatei vom NetworkManager /etc/NetworkManager/NetworkManager.conf in der [main]-Sektion die folgende Option setzen:

dns=default

Nun nur noch den NetworkManager neu starten und schon sollte die /etc/resolv.conf mit den DNS-Informationen gefüttert werden:

sudo systemctl restart NetworkManager
cat /etc/resolv.conf
# Generated by NetworkManager
search kernel-error.local
nameserver 10.10.88.1
nameserver fd00:424e:6eff:f525:454e:6eff:f525:4241

Perfekt! Also los, noch ein Versuch mit dem SSH-Client und… nichts… DNS-Auflösung funktioniert, aber es ist noch immer „insecure„. Stimmt! Es fehlt etwas in meiner resolv.conf. Wir brauchen bestimmt noch die folgende Option:

options edns0

Jetzt aber! HA, dig ist schon mal glücklich, ich sehe ein „ad“. Ähm, aber der SSH-Client noch immer nicht?! Was zum… OK, OK… Irgendwas um SSH muss ich vergessen haben. Aber was? Wie macht SSH das überhaupt? Vielleicht gibt mir das eine Idee. Also, mal kurz in den Code geschaut, C bekomme ich gerade noch hin:

        /* Check for authenticated data */
        if (ldns_pkt_ad(pkt)) {
                rrset->rri_flags |= RRSET_VALIDATED;
        } else { /* AD is not set, try autonomous validation */
                ldns_rr_list * trusted_keys = ldns_rr_list_new();

                debug2("ldns: trying to validate RRset");
                /* Get eventual sigs */
                rrsigs = ldns_pkt_rr_list_by_type(pkt, LDNS_RR_TYPE_RRSIG,
                    LDNS_SECTION_ANSWER);

                rrset->rri_nsigs = ldns_rr_list_rr_count(rrsigs);
                debug2("ldns: got %u signature(s) (RRTYPE %u) from DNS",
                       rrset->rri_nsigs, LDNS_RR_TYPE_RRSIG);

                if ((err = ldns_verify_trusted(ldns_res, rrdata, rrsigs,
                     trusted_keys)) == LDNS_STATUS_OK) {
                        rrset->rri_flags |= RRSET_VALIDATED;
                        debug2("ldns: RRset is signed with a valid key");
                } else {
                        debug2("ldns: RRset validation failed: %s",
                            ldns_get_errorstr_by_id(err));
                }

                ldns_rr_list_deep_free(trusted_keys);
        }

Aaaaaaaaaaaaaaaaaaaaaaa… ldns… woher bekommt er wohl die Trust Keys? Genau… woher? Da fehlt also NOCH etwas in meiner resolv.conf:

options edns0 trust-ad

Und? genau… geht 😀

ssh usermane@hostname.kernel-error.org -vvv
[...]
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:kTRGVCMRLiHfvJunW2CbW5H3NZmn3Wkx2KnHJXl3iJu
debug3: verify_host_key_dns
debug1: found 2 secure fingerprints in DNS
debug3: verify_host_key_dns: checking SSHFP type 4 fptype 1
debug1: verify_host_key_dns: matched SSHFP type 4 fptype 1
debug3: verify_host_key_dns: checking SSHFP type 4 fptype 2
debug1: verify_host_key_dns: matched SSHFP type 4 fptype 2
debug1: matching host key fingerprint found in DNS
[...]

Pfff… nun habe ich natürlich die Optionen von Hand in meine resolv.conf eingetragen, der NetworkManager wird diese Option also spätestens beim nächsten Boot rauswerfen. Also muss ich noch meinem NetworkManager beibringen, dass er bitte diese Option ebenfalls in meine resolv.conf schreibt, wenn das jeweilige Netzwerkprofil aktiviert ist. Dazu gibt es aber leider keinen Menüpunkt in der GUI vom NetworkManager, also muss das per CLI gemacht werden. Dieses für IPv4 und IPv6 gleichermaßen, sonst greift es leider nicht!

nmcli conn modify DEINE-PROFIL-UUID ipv4.dns-options edns0,trust-ad
nmcli conn modify DEINE-PROFIL-UUID ipv6.dns-options edns0,trust-ad

Oh, ein nmcli conn show listet die bestehenden und vor allem das aktive Profil inkl. der UUID auf. Davon abgesehen, klappt es nun so und ist rebootfest.

So und nun ihr! Ich bin mit meinem FreeBSD-Wissen an das Thema herangegangen. Wie macht man das als Hardcore-Linux-User und mit systemd-resolved richtig und funktionierend?

Cloudflare Deal: YubiKeys für nur 10-11 USD – Sichere deine Online-Konten

Es gibt aktuell einen EEEECCCHHHTTTT guten Deal um günstig an bis zu 10 YubiKeys 5 NFC und/oder 5C NFC zu kommen.

Man benötigt dafür einen Cloudflare Account, der ist ja schnell geklickt. Dann klickt man ein paar Links und wartet auf eine E-Mail mit seinem Discount Code.

Da die Keys in der Regel etwas um die 50€ Kosten, ist dieses schon eine extreme Ersparnis.

Oh der Link: https://www.reddit.com/r/yubikey/comments/xrcly7/cloudflare_deal_for_1011_keys/

Screenshot der Bestellübersicht für den YubiKey 5 NFC und YubiKey 5C NFC

BIND 9.18: DoH und DoT einrichten für sichere DNS-Abfragen

Über die Techniken DoT (DNS over TLS) habe ich bereits im Zusammenhang mit Bind 9.16 geschrieben. Ebenfalls DoH (DNS over HTTPS) gibt es einen kleinen Beitrag.

Bilder der Bind 9 TLS Konfiguration

Zu diesem Zeitpunkt bracht BIND 9 die Unterstützung für DoH und DoT noch nicht selbst mit. Daher waren zu diesem Zeitpunkt noch Umwege über stunnel oder nginx zusammen mit doh-proxy nötig.

Zum Glück kommt die letzte stable Version 9.18.0 (26. Januar 2022) mit dem nötigen Support.

named now supports securing DNS traffic using Transport Layer Security (TLS). TLS is used by both DNS over TLS (DoT) and DNS over HTTPS (DoH).

Warum möchte man noch gleich DoH oder DoT benutzen? Ganz einfach… Über diese Techniken werden DNS Abfragen verschlüsselt übertragen. Dieses ist ein weiterer Schutz davor manipulierte Antworten zu bekommen und selbstverständlich, damit die eigenen DNS Abfragen erst überhaupt nicht mitgelesen werden. Denn wenn von einem Gerät im Netzwerk die DNS Abfrage zu z.B.: www.tagesschau.de kommt, könnte man davon bereits Dinge ableiten.

Wie die meisten Bind Konfigurationen ist dieses ebenfalls straightforward. Ab Version 9.18 bringt Bind alles Nötige mit. Da wir nun TLS mit dem Bind sprechen möchten, benötigen wir natürlich ein gültiges Zertifikat, wie z.B. beim nginx für seine Webseite.

Ebenfalls sollte man ein paar frische Diffie-Hellmann Parameter generieren:

openssl dhparam -out dhparam.pem 4096

Die eigentliche bind Konfiguration kann in der named.conf.options geschehen:

options {
        [...]
        listen-on port 853 tls local-tls { 37.120.183.220; };
        listen-on-v6 port 853 tls local-tls { 2a03:4000:38:20e::853; };
        listen-on port 443 tls local-tls http default { 37.120.183.220;  };
        listen-on-v6 port 443 tls local-tls http default { 2a03:4000:38:20e::853; };
        [...]
        allow-recursion-on { 127.0.0.0/8; ::1/128; 2a03:4000:38:20e::853; 37.120.183.220; };
        [...]
};

Da der bind auf weiteren Ports lauschen soll erweitert man diese für IPv4 und IPv6. Der Default Port für DoH ist dabei 443 und der default Port für DoT ist 853, beides TCP.

listen-on sowie listen-on-v6 sind wohl selbsterklärend.
port ist der TCP Port und erklärt sich ebenfalls.
tls sagt dem Bind das wir tls sprechen möchten.
local-tls verweißt auf den gleichnamigen tls Block über welchen man seine TLS Konfiguration vornimmt.
http ist für DoH.
default gibt den eigentlichen endpoint für die DoH Abfragen an, im default ist es /dns-query

Da der Server unsere DNS Abfragen erledigen soll, müssen wir ihm dieses noch per allow-recursion-on auf den jeweiligen Adressen erlauben.

Als nächstes wird die eigentliche TLS Terminierung konfiguriert (das lässt sich ebenfalls auslagern, wenn gewünscht). Dafür wird der folgende Block, außerhalb der Options Blocks, ergänzt:

tls local-tls {
    cert-file "/usr/local/etc/ssl/wild.kernel-error.de/2022/ecp/chain.crt";
    key-file "/usr/local/etc/ssl/wild.kernel-error.de/2022/ecp/http.key";
    dhparam-file "/usr/local/etc/ssl/dhparam.pem";
    protocols { TLSv1.2; TLSv1.3; };
    ciphers "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256";
    prefer-server-ciphers yes;
    session-tickets no;
};

local-tls ist dabei der name des Blocks. Auf diesen verweisen wir oben.
cert-file ist der Pfad zum Zertifikat. Ich habe dort nicht nur das Zertifikat, sondern die gesamte Chain, also mit Intermediate und Root.
key-file ist der Pfad zum Key des Zertifikates.
dhparam-file ist der Pfad zu den Diffie-Hellman Parametern.
protocols definiert die zu verwendenden TLS Protokolle. In diesem Beispiel TLS1.2 sowie TLS1.3.
ciphers definiert die zu verwendenden cipher. Es soll ja „sicher“ bleiben.
prefer-server-ciphers übermittelt dem Client die Information, in welcher Reihenfolge protokoll/cipher Kombinationen probiert werden sollen um einen Match zu finden. Erst das vermeintlich sicherste und dann immer „schlechter“.
session-tickets regelt ob eine Wiederaufnahme von TLS Sessions erlaubt ist oder nicht. Da ich forward secrecy nutzen möchte, ist es deaktiviert.

Damit ist die Konfiguration schon abgeschlossen (Firewall ggf. nicht vergessen!). Also testen….

Ein einfaches Tool dafür ist dog, oder natürlich dig aus den bind-tools aber Version 9.18. Für bind gibt es dann die Optionen +https oder auch +tls

dig +https @dns.kernel-error.de www.kernel-error.de A
dig +tls @dns.kernel-error.de www.kernel-error.de A

Der gleiche Test mit dog, sieht wie folgt aus:

dog www.kernel-error.de --tls "@dns.kernel-error.de"
A www.kernel-error.de. 6h00m00s   148.251.40.23
dog www.kernel-error.de --https "@https://dns.kernel-error.de/dns-query"
A www.kernel-error.de. 6h00m00s   148.251.40.23

Das war es auch schon! Viele Spaß mit einem „besseren“ DNS und wenn es noch Fragen gibt, einfach fragen 🙂

Windows Server 2012 R2: Sichere Cipher für RRAS konfigurieren

RRAS Routing und RAS Icon.

Wenn ich schon bei den ganzen Microsoft Themen bin, warum nicht gleich noch „sicheres“ RRAS Routing- und RAS  mit einem Windows Server 2012 R2?! Im speziellen Beispiel an einem L2TP IPsec VPN für Clientsysteme.

Hat mein alles im Routing und RAS konfiguriert verbinden sich die Clients im Standard mit etwas wie: SHA-1 3DES und der DH Group 2 was ein modp1024 (1024-bit) ist. Pfffffff SHA-1 ja, ok… 3DES muss nicht unbedingt und modp1024 möchte man auch nicht oder?

Screenshot der Windows-Firewall mit erweiterter Sicherheit und angezeichnetem Klickpfad um die Sichereheitsmethoden zu konfigurieren.

Wie konfiguriert man dieses nun also „weg“? Ich muss zugeben dafür einige Zeit gelesen zu haben. Dann ich hätte erwartet dieses irgendwo in der Nähe vom Routing und RAS konfigurieren zu müssen. Dem ist aber nicht so. Die Konfiguration dieser Parameter findet man über die Windows-Firewall mit erweiterter Sicherheit auf dem Windows Server. Irgendeinen Grund wird es schon haben es dort zu ~verstecken~ und sicher ist dieser absolut einleuchtend, wenn man sich näher damit auskennt. Ich hätte dort von alleine sicher niemals gesucht. Man findet es also über: Windows Firewall ==> recht Maus: Windows-Firewall mit erweiterter Sicherheit ==> Eigenschaften ==> IPsec-Einstellungen ==> IPsec-Standardeinstellungen Button „Anpassen“ ==> Schlüsselaustausch.

Hier kann man nun die Einstellungen konfigurieren… *kopfschüttel* Windows Firewall…. Hat jemand eine Idee warum es ausgerechnet da ist? Wie auch immer…

Screenshot der Windows-Firewall mit erweiterter Sicherheit und angezeichnetem Klickpfad um die Datenschutzeinstellungen zu konfigurieren.

Steht der Windows RRAS hinter einem NAT sollte man ebenfalls noch UDP Encapsulation aktivieren. Dafür habe ich folgendes Registry File für euch:

Nach diesen Änderungen sollte man natürlich ganz Windowslike den Server einmal durchstarten. Baut man nun von einem Windows Client eine neue VPN Verbindung auf kann man auf diesem natürlich per PowerShell (bitte mit erweiterten Rechten) prüfen ob seine Änderungen gegriffen haben:

Get-NetIPsecMainModeSA | Select-Object -First 1
Screenshot des Kommandos Get-NetIPsecMainModeSA | Select-Object -First 1 inkl Konsolenausgabe.

Wichtig sind dann:

CipherAlgorithm
HashAlgorithm
GroupId

Im Standard wäre es:

Encryption: 3DES
Authentication/Integrity: SHA-1
Key Size: DH Group 2 (1024 bit)

Nach unseren Änderungen:

Encryption: AES256
Authentication/Integrity: SHA-1
Key Size: DH Group 20 (384-bit elliptic curve group)

Windows Firewall…. Pfff… Ja natürlich lässt sich das Thema mit Gruppenrichtlinien erschlagen, nur ist dieses noch einmal ein Thema für sich, hm? Vor allem habe ich mich sehr schwer damit getan hier die Reihenfolge korrekt vorzugeben.

Fragen? Dann wie immer fragen 🙂

Windows Server 2012 R2 mit Exchange 2016: SSL Labs A-Rating erreichen

Qualis A+ Icon.

Ich habe hier einen Windows Server 2012 R2 mit einem Exchange 2016. Out of the Box spricht das Ding TLS 1.0, SSLv3 und RC4. Da gehen einem schnell die Haare hoch, oder?

Kann man so ein System auf ein A+ im Qualys Rating bekommen und es arbeitet dann noch? Kleiner Spoiler, ja geht!

Ich muss zugeben, Microsoft Produkte strengen mich in dieser Hinsicht immer sehr an. Auch wenn sie ganz sicher ihre Daseinsberechtigung haben.

Nun gut… Für ein A+ benötigen wir neben brauchbaren ciphern, sauberen Protokollen usw. noch HTTP Strict Transport Security (https://de.wikipedia.org/wiki/HTTP_Strict_Transport_Security). Dieses ist im Grunde nur ein http response header und dieses konfigurieren wir im IIS Manager. Das besagte Testsystem kümmert sich nur um den Exchangeserver, daher konfiguriere ich es ganz oben (so wird es überall hin vererbt).

IIS-Manager ==> HTTP-Antwortheader ==> Hinzufügen

Screenshot der Internetinformationsdienste (IIS)-Manager.

Name: strict-transport-security
Wert: max-age=31536000; includeSubdomains

Wie auch im Bild zu sehen.

Qualis A+ Wertung.

Jetzt der spannende Teil. Man muss einige Änderungen in der Registrierung vornehmen um MD5, RC4 usw. zu deaktivieren. Ich habe da etwas vorbereitet um dieses zu tun. Ebenfalls wird SSLv3, TLS 1.0, TLS 1.1 deaktiviert. TLS 1.2 und TLS 1.3  wird aktiviert (TLS 1.3 dabei nur für die Zukunft). Ebenfalls werden super schwache Cipher deaktiviert. Die bestmöglichen dafür aktiviert und es wird auch eine Cipherorder vorgegeben. Das File einfach herunterladen, ausführen und im Anschluss den Server durchstarten (Microsoft halt…).

Aber dann sollte man sein A+ haben. Auch wenn ich gerne noch schönere Cipher hätte :-/ aber mehr ging nicht, bzw. habe ich nicht hin bekommen!

Qualis Wertung mit Blick auf Cipher Suites und Protocols.

Oh natürlich… Das Registry Snippet zum Download:

Fragen? Dann fragen…

TLS Cipher Suite erklärt: ECDHE mit AES-256-GCM-SHA384

TLS_AES_256_CGM_SHA384 oder TLS_ECDHE_ECDHE_WITH_AES_256_GCM_SHA384 liest man immer mal wieder, wenn man sich etwas mit Transportverschlüsselung beschäftigt. Was genau dieses bedeutet ist nicht immer ganz klar. Daher möchte ich einmal probieren es etwas aufzuschlüsseln.

Um dieses nachvollziehen zu können, müssen vorher noch die folgenden Begriffe geklärt werden:

  • Key exchange
    Damit ist der Schlüsselaustausch gemeint.
  • Certificate verification
    Hier geht es um das eigentliche Zertifikat vom Server.
  • Bulk encryption
    Die eigentliche Verschlüsselung welche am Ende genutzt wird um die Daten auf ihrem Weg zu verschlüsseln.
  • Hashing
    Die eingesetzten Prüfsummen um sicherstellen zu können, das alles „richtig“ ist.
Verschlüsselung-cipher

Ebenfalls muss man wissen, dass es seit TLSv1.3 einen Unterschied in der Schreibweise der cipher suite gibt. Bei <= TLSv1.2 tauchen in der cipher suite als erstes das Protokoll auf, dann der Algorithmus für den Schlüsselaustausch, nun die digitalen Signaturen des Serverzertifikates gefolgt vom „Rest“. Die Menge möglicher Kombinationen ist jetzt schon sehr hoch. Damit diese „Liste“ nicht in ihrer Länge explodiert hat man bei TLSv1.3 die beiden Punkte Key exchange und Certificate verification aus der Schreibweise entfernt.

Mit diesem Wissen kann man nun anfangen die beiden Zeichenkennten zu „zerlegen“.

TLS_ECDHE_ECDHE_WITH_AES_256_GCM_SHA384

  • TLS
    Nicht schwer, das eingesetzte Protokoll TLS (Transport Layer Security)
  • ECDHE
    Key exchange in diesem Fall ECDHE
  • ECDHE
    Certificate verification bei mir inzwischen ECDHE, sehr oft aber RSA
  • WITH_AES_256_GCM
    Bulk encryption also die eigentliche Verschlüsselung der Daten. In diesem Fall AES (Advanced Encryption Standard) mit der maximalen Länger von 256bit und GCM (Galois/Counter Mode).
  • SHA384
    Das eingesetzte Hashing SHA (Secure Hash Algorithm) in Version 2 mit einer Länge von 384bit.

TLS_AES_256_CGM_SHA384 schafft nun jeder allein, oder?

Sprechen wir noch kurz über den Key exchange. In diesem ist spezifiziert, wie sich Client und Server auf einen eigenen Schlüssel für ihre verschlüsselte Kommunikation einigen. Brauchbar sind dabei Kombinationen aus DHE (wenn sie >= 2048bit sind) und besser noch ECDHE, dabei stehe EC für elliptische Kurven DHE ist Diffie-Hellman. Diffie-Hellmann hat nämlich eine Möglichkeit aufgeführt, wie man für die Verschlüsselung einer Verbindung temporäre Schlüssel einsetzten kann. Denn es lassen sich auch verschlüsselte Verbindungen aufzeichnen. Natürlich kann man so noch immer nicht den Inhalt sehen.. Kommt man an den eingesetzten Schlüssel für die Kommunikation kann man diese damit entschlüsseln. Setzte man also auf einen temporären Schlüssel, gibt es diesen nur für eine gewisse Zeit und dann verschwindet er. Die Zeit, um an diesen Schlüssel zu kommen, ist daher extrem begrenzt und sorgt für eine zusätzliche Sicherheit. „Früher“ hat es gereicht sich einfach irgendwann/irgendwie den Schlüssel vom Server zu besorgen und man konnte mit diesem die Aufgezeichneten Verbindungen entschlüsseln. Bugs wie Heartbleed haben dieses noch vereinfacht. DHE minimiert also etwas das Risiko von Bugs und ergaunerten privat Keys vom Server. Man möchte für seine Verbindungen also nur DHE, besser noch ECDHE! Am besten bietet der Server nichts anders an, da sonst ggf. ein Angreifer versuchen könnte die Verbindung auf etwas „schlechteres“ herunter zu stufen, um so doch am Ende wieder an etwas kommen zu können.

Wenn wir dabei sind… Certificate verification. Nur eine verschlüsselte Verbindung alleine hilft ja nicht, wenn man sich mit dem falschen Server unterhält. Ich meine damit, dass ein Angreifer einfach dafür sorgt, dass wir nicht mit dem gewünschten Server sprechen, sondern mit seinem und dieser vielleicht einfach nur alle Daten durchreicht. Um dieses möglichst zu erschweren gibt es eine ganze Reihe verschiedener Möglichkeiten. Eine davon ist die Certificate verification. Der Server hat also ein Zertifikat, welches vielleicht noch von einer CA signiert wurde, dessen Prüfsumme im DNSsec geschützten DNS liegt, zu dem es HPKP (http Public Key Pinning) gibt oder oder… Dieses Zertifikat sollte daher ebenfalls so gebaut sein, dass man es nicht einfach „nachmachen“ kann. Daher sollte es >=2048bit RSA (asymmetrisches kryptographisches Verfahen) sein, besser noch 4096bit RSA. Hier sieht man schon ein „Problem“. Die Systeme „rechnen“ schneller und damit wird die Bitzahl erhört und die zu übertragenden Daten und das errechnen der Clients usw.. Insg. keine sehr schöne Lösung. ECDHE Zertifikate sind deutlich kleiner, damit schneller zu übertragen und zudem noch für den Client schneller zu prüfen.

Als Beispiel:
Ein Zertifikat mit elliptischen Kurven und einer Länge von 256bit ist grob vergleichbar mit einem RSA Zertifikat mit 3072bit. Wenn jemand daher auf elliptische Kurven setzt, sollten diese nicht kleiner als <=secp256r1 sein. secp224r1 liegt schon zu nahe an 1024bit RSA und fliegt bald weg. secp384r1 ist ganz vorne mit dabei, hat aktuell keinen besonderen Vorteil.

Bulk encryption, tjo die eingesetzte Verschlüsselung. Hier gibt es verschiedene Kombinationen, welche als „sicher“ gelten. Alle zu erklären sprengt sicher den Rahmen. April 2020 kann man sicher merken:

Kombinationen aus AES >=128bit mit GCM oder ChaCha20 mit Poly1305 sind ganz gut. OK ist im Moment noch AES >=128bit mit CBC. 3DES sollte man in keiner Kombination mehr nutzen, das fliegt bald aus der „Sicher“ Liste raus, so wie <= TLSv1.2. Von allen anderen Kombinationen sollte man tunlichst die Finger lassen!

Das Hashing bei der Bulk encryption (das Hashing für Key exchange und Certificate verification hängt am Serverzertifikat, unterliegt den gleichen Merkpunkten) sollte etwas um >= 256bit SHA 2 sein. Ein ganz guter Mittelweg ist hier SHA-384. SHA1 „geht“ wohl dabei ebenfalls noch. Ich würde davon und von allem anderen dennoch die Finger lassen. Wenn ihr irgendwo MD5 RC4 oder ähnliches seht, rennt weg!

Habe ich etwas vergesse, ist etwas falsch oder es gibt Fragen? Dann einfach E-Mail bitte!

« Ältere Beiträge

© 2025 -=Kernel-Error=-

Theme von Anders NorénHoch ↑