Empirische Untersuchung zur M2M-Authentifizierung
Die M2M-Authentifizierung (Machine-to-Machine) ist ein entscheidender Aspekt in der Internet der Dinge (IoT), da sie es Geräten ermöglicht, sichere Kommunikation miteinander zu führen. In dieser empirischen Untersuchung wurden verschiedene Authentifizierungsprotokolle untersucht, darunter LDAP, SAML, OAuth2 und Kerberos.
Code-Teile für dieses Projekt können auf GitLab gefunden werden.
LDAP
LDAP (Lightweight Directory Access Protocol) ist ein weit verbreitetes Verzeichnisdienstprotokoll, das zum Speichern und Abrufen von Informationen verwendet wird. Es kann jedoch komplex sein, insbesondere wenn es um die Einrichtung geht. Trotzdem bietet es eine robuste und flexible Lösung für die Authentifizierung.
Zum Aufsetzen des LDAP Servers wurde diese Anleitung verwendet. Da allerdings das Anlegen einer Gruppe beziehungsweise eines Nutzers mit .ldif-Dateien sehr fehleranfällig ist, ist es empfehlenswert einen Apache2 Server zu installieren und die Accounts über die GUI zu managen (siehe Link). Allerdings lässt sich einem erstellten Nutzeraccount kein Passwort über die GUI hinzufügen, weshalb zusätzlich ein weiters CLI-Tool notwendig ist. Bei diesem führt die Standardkonfiguration leider zu vielen Bugs, weshalb diese durch diese ersetzt werden muss.
Um die Public Key Authentication zu nutzen, muss zunächst ein Schlüsselpaar generiert werden. Dies kann mit dem ssh-keygen Befehl erreicht werden. Nachdem das Schlüsselpaar erzeugt wurde, kann es mit dem ldapadd Befehl zum LDAP-Server hinzugefügt werden. Der private Schlüssel bleibt auf dem Gerät, während der öffentliche Schlüssel auf dem LDAP-Server hinterlegt wird. Bei der Authentifizierung wird dann der öffentliche Schlüssel gegen den privaten Schlüssel auf dem Gerät geprüft.
Interessant ist, dass ein nicht authentifizierter Nutzer mit dem Befehl ldapsearch -x -LLL -H ldap://ldap.wfp2.example.com -b dc=wfp2,dc=example,dc=com dn alle Einträge des LDAP Servers abrufen und so die Struktur der Gruppen und deren Nutzer einsehen kann. Hier muss angemerkt werden, dass ein DNS Server mit der Domaine wfp2-example.com aufgesetzt wurde.
Im Gegensatz zu dem oben angeführten Befehl kann mit ldapwhoami -x -H ldap://ldap.wfp2.example.com -D "cn=ubuntumachine1001,ou=people,dc=wfp2,dc=example,dc=com" -W ein User in der CLI authentifiziert und anschließend autorisiert werden. Bei diesem Befehl ist zusätzlich anzumerken, dass der Parameter -W eine Eingabe des Passwortes in extra anfordert. Wird stattdessen -w verwendet, so kann das Passwort direkt in dem Befehl angegeben werden (-w <Passwort>).
Mit dem Befehl ldapsearch -x -H ldap://ldap.wfp2.example.com -D "cn=ubuntumachine1001,ou=people,dc=wfp2,dc=example,dc=com" -W -b "dc=wfp2,dc=example,dc=com" fragt der User ubuntumachine1001 alle verfügbaren LDAP Accounts ab. Anzumerken ist hier, dass ubuntumachine1001 kein Admin-User ist.
Eine M2M Authentifizierung mittels LDAP mithilfe eines Passwortes ist also möglich, ist allerdings nicht zu empfehlen. LDAP bietet auch die Möglichkeit einen User mithilfe eines asymmetrischen Schlüssels zu authentifizieren. Ebenfalls unterstützt das Protokoll Challenge-Response-Verfahren.
Bezüglich der Sicherheit von LDAP ist anzumerken, dass mit hoher Wahrscheinlichkeit der Apache2 Server die größte Schachstelle aufweist. Da Usernamen unautorisiert ausgelesen werden können, kann hier mit Brute-Force-Verfahren gearbeitet werden.
SAML
SAML (Security Assertion Markup Language) ist ein XML-basiertes Standard, der zur Authentifizierung und Autorisierung verwendet wird. Es wurde festgestellt, dass SAML schwer einzurichten ist, besonders wenn es darum geht, einen eigenen SAML Identity Provider zu erstellen. Da dies auch mithilfe von diversen Online-Anleitungen nicht funktioniert hat wurde als Alternative Auth0 verwendet. Auth0 ist ein Cloud-basierter Identitätsverwaltungsdienst, welcher eine benutzerfreundliche Oberfläche bietet und alle gängigen Authentifizierungsmethoden (Passwort, Token, Challenge-Response, Public-Key-Crypto) unterstützt.
Für die Public Key Authentication in SAML wird ein X.509-Zertifikat verwendet. Der private Schlüssel bleibt (wie üblich) auf dem Client-Gerät, während das Zertifikat vom SAML Identity Provider ausgestellt und anschließend hinterlegt wird. Bei der Authentifizierung wird dann das Zertifikat gegen den privaten Schlüssel auf dem Gerät geprüft
Anmerkung 1: Bei einer Token basierten Authentifizierung müssen verschiedene Parameter (client_id, client_secret, audience, grant_type) übermittelt werden. Da diese - wie ein Passwort - auf der Maschine gespeichert werden müssen, ist neben der höheren Sicherheit gegenüber Brute-Force-Angriffen kein Mehrwert vorhanden.
Anmerkung 2: Die Konfiguration von SAML ist langwierig, da durch die verschiedenen Schlüssel und Endpoints sehr viele Fehlerquellen vorhanden sind. Zusätzlich werden in jedem Request beziehungsweise in jedem Response sehr viele Daten mitgegeben, welche in einer Produktions-Umgebung aus Sicherheitsgründen verarbeitet werden sollten.
OAuth2
OAuth2 ist ein Autorisierungsframework, das es Benutzern ermöglicht, ihren Zugang zu ihren Daten auf sichere Weise mit Drittanbieter-Anwendungen zu teilen. In diesem Fall wurde im ersten Fall GitHub und im zweiten Fall Auth0 als Autorisierungsserver verwendet. Den Autorisierungsserver lokal zu hosten war nicht möglich, da es keine Open-Source Bibliotheken gibt. Im Vergleich zu SAML ist OAuth2 sehr benutzerfreundlich. Das Aufsetzen des Servers hat bei GitHub als auch Auth0 sehr schnell und einfach funktioniert. GitHub hat allerdings den Nachteil, dass nur die Zugangsdaten für vorhandene GitHub-Konten verwendet werden können. Dies bedeutet für eine M2M Authentifizierung, dass nur eine Passwort Authentifizierung möglich ist. Bei Auth0 können - wie bei SAML - alle gängigen Authentifizierungsmöglichkeiten verwendet werden.
In OAuth2 wird die Public Key Authentication durch die Verwendung von JWT (JSON Web Tokens) erreicht. Ein JWT enthält einen Header, der Informationen über den verwendeten Algorithmus enthält, und einen Body, der die tatsächlichen Daten enthält. Der Header und der Body werden dann mit dem privaten Schlüssel des Geräts signiert. Beim Überprüfen der Gültigkeit des Tokens wird das Token mit dem öffentlichen Schlüssel des Geräts überprüft.
mTLS
mTLS (Mutual Transport Layer Security) ist eine Methode für gegenseitige Authentifizierung, die sicherstellt, dass beide Parteien, die Informationen austauschen, wer sie behaupten zu sein, tatsächlich sind, indem überprüft wird, ob sie beide den richtigen privaten Schlüssel haben.
Im Detail funktioniert mTLS sehr ähnlich wie das TLS-Protokoll. Es gibt jedoch einen zusätzlichen Schritt vor dem Schlüsselaustausch. Der Client sendet seinen öffentlichen Schlüssel und Zertifikat an den Server, der diese vom Server aus identifiziert, um zu bestätigen, dass die Anfrage von einem bekannten Client kommt und den privaten Schlüssel besitzt, der zum geteilten öffentlichen Schlüssel des Clients entspricht.
Um mTLS zu implementieren, wird im Gegensatz zu TLS eine interne Zertifizierungsstelle benötigt. Diese stellt die X.509 Zertifikate für alle Clients und Server aus, wodurch jedes Zertifikat das gleiche Stamm-Zertifikat besitzt. Anhand dieser Übereinstimmung findet die Authentifizierung statt. Das Stamm-Zertifikat ist in diesem Fall selbstsigniert. Der Vorteil von mTLS ist, dass diverse Angriffe wie zum Beispiel On-Path-Angriffe, Credential Stuffing, erfolglos verlaufen.
Kerberos
Kerberos ist ein Netzwerkauthentifizierungsprotokoll, das auf einem Ticket-Granting-Ticket-System basiert. Obwohl es für das Windows Active Directory entwickelt wurde, ist es in Ubuntu einfach zum einrichten und zum verwenden. Kerberos verlangt allerdings die Verwendung von Domain-Namen. es werden keine IP Adressen akzeptiert, weshalb zusätzlich ein DNS-Server aufzusetzen ist.
Für die Konfiguration vom Kerbers Server wurden die Schritte in dieser Anleitung durchgeführt. Der Client benötigt diese Library, um ein Ticket beantragen zu können. Mit dem Befehl kinit <username> kann ein Ticket vom Kerberos Key Distribution Center (KDC) beantragt und mit klist angezeigt werden.
Offiziell unterstützt Kerberos nur eine Passwort-Authentifizierung. Mit zusätzlichen "Plug-In"s lässt sich dies um ein Challenge-Response-Verfahren oder eine Public-Key Cryptography erweitern.
Bezüglich Kerberos ist auch zu erwähnen, dass es das Tool Kerbrute gibt, welches Kerberos Account auslesen und mithilfe von beispielsweise Dictionary-Attacks Passwörter auslesen kann. Allerdings kann Kerberos so konfiguriert werden, dass nach einer bestimmten Anzahl an Falscheingaben der Account gesperrt wird.
Fwknop
Fwknop (Firewall Knocking Operation) ist ein Tool, das es ermöglicht, den Zugriff auf einen Server zu steuern, indem es "knocks" an den Server sendet, um einen temporären Port öffnen zu lassen. Dies ist besonders nützlich in Umgebungen, in denen Zero Trust-Prinzipien angewendet werden. fwknop ist im Gegensatz zu vielen anderen Servicen ein Programm, welches keinen Port benötigt, weshalb es gegenüber Schwachstellen von außen sehr gut geschützt ist.
Der sogenannte "knock" besteht dabei aus genau einem IPv4 Packet, welches zum Server geschickt und von diesem gedroppt wird, da keine entsprechende FW-Regel vorhanden ist. fwknop nimmt dieses gedroppte Packet und überprüft, ob die zur Verfügung gestellten Schlüssel gültig sind. Sind diese gültig, wird eine IP-Tables Regel für eine bestimmte Zeit (z.B. 5sec) geöffnet, in welcher der Client Zeit hat sich mit dem Service zu verbinden. Der Nachteil von fwknop ist, dass durch die begrenzte Anzahl an Byte in einem IPV4 Packet Schlüssel wie RSA4096 neben den anderen Parametern keinen Platz haben.
Für die M2M Kommunikation ist dieses Tool grundsätzlich eine tolle Idee. Allerdings muss auch gesagt werden, dass fwknop nicht mehr weiter entwickelt wurde, weshalb es nur auf Ubuntu16 Maschinen funktioniert.
Zusammenfassung
Diese empirische Untersuchung hat gezeigt, dass es viele verschiedene Möglichkeiten zur Authentifizierung in M2M-Umgebungen gibt, jede mit ihren eigenen Vor- und Nachteilen. Es ist wichtig, die spezifischen Anforderungen und Bedingungen Ihrer Umgebung zu berücksichtigen, um die beste Lösung für Ihre Bedürfnisse zu finden.
| Protokoll | Einrichtungskomplexität | Sicherheitslücken | Benutzerfreundlichkeit | Authentifizierungsmethoden | Kommentare |
|---|---|---|---|---|---|
| LDAP | Mittel | nmap <LDAP Server> hat ausschließlich Schwachstellen beim Apache Server (2.4.52) gefunden | CLI ist nicht benutzerfreundlich / Weboberfläche ist benutzerfreundlich | Passwörter, Challenge/Response-Verfahren, Public-Key-Kryptografie | Funktioniert gut, wenn es einmal funktioniert |
| SAML | Mittel | Nicht relevant | Hohe Benutzerfreundlichkeit | Passwörter, Challenge/Response-Verfahren, Public-Key-Kryptografie | Einrichtung des Identity Providers über Auth0 hat schnell und problemlos funktioniert |
| Hoch | N/A | N/A | N/A | der Versuch den Identity Provider lokal zu hosten wurde nach vielen Fehlversuchen aufgegeben | |
| OAuth2 | Niedrig | Nicht relevant | Benutzerfreundlich | Passwörter, Challenge/Response-Verfahren, Public-Key-Kryptografie | Einfache Einrichtung, wenn GitHub oder Auth0 als Autorisierungsserver verwendet werden |
| Kerberos | Niedrig | Kerbrute (Brute-Force-Angriffe) | Benutzerfreundlich | Passwörter | Einfache Einrichtung, aber speziell für Windows Active Directory entwickelt |
| Fwknop | Mittel | N/A | Benutzerfreundlich | Passwörter, Public-Key-Kryptografie mit Schlüsseln bis 2048 Bit | Einfache Einrichtung, aber nur in Ubuntu16 funktioniert |
Felder, welche mit "Nicht relevant" markiert wurden, bedeuten, dass die Verantwortung bei den externen Identity Providern und nicht bei den internen Service Providern liegt.
Use-Case 1 - alle Maschinen haben die gleichen Rechte und werden von einer Gruppe verwaltet
In dem Fall, dass alle Maschinen die gleichen Berechtigungen haben, kann mTLS verwendet werden, um beide Seiten gegenseitig authentifizieren zu können. Dies funktioniert allerdings nur, wenn keine Services von Dritten (z.B. Azure) in Anspruch genommen werden. In diesem Fall würden die Zertifikate nicht zusammenpassen, wodurch die Maschine die Verbindung zu Azure ablehnen würde.
Zusätzlich kann in diesem Use-Case das Zero Trust (ZT) Prinzip umgesetzt werden, sodass eine Maschine nur jene Services anderer Maschinen sieht, die sich auch wirklich benötigt. Dies könnte mit Port Knocking erreicht werden.
Use-Case 2 - Maschinen sind an unterschiedlichen Standorten und werden von unterschiedlichen Gruppen verwaltet
In diesem Fall ist mTLS nicht möglich, weshalb eine Authentifizierung über SAML oder OAuth2 empfehlenswert ist. Wie mit LDAP lassen sich mit SAML oder OAuth2 die Rechte einzelner Maschinen feingranular konfigurieren. Empfehlenswert ist die Verwendung von OAUth2 , da diese deutlich schneller und mit weniger Fehlerquellen zu implementieren ist.
Im Fall von OAuth2 ist allerdings das Service von Auth0 zu verwenden, da es aktuell keine Open-Source Lösungen gibt, weshalb Kosten anfallen können.
Im Fall von SAML ist die Installation sehr langwierig, da es keine Wheels zum Installieren gibt.