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.
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.
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.
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.
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.