Julian Joswig: IT Blog

Zeige alle Artikel im Tag Netzwerk

Raspberry PI (Raspbian) Einrichtung ohne Tastatur und Monitor (headless)

Geschrieben am 30. Sep 2018, 09:30

Die initiale Einrichtung eines Raspberry PI mit Raspbian ohne Monitor und externer Tastatur gestaltet sich - wie in meinem Fall - manchmal etwas schwierig. Die Herausforderung besteht darin, die Installation so vorzubereiten, dass der Raspberry beim ersten Hochfahren idealerweise die Netzwerkverbindung automatisch herstellt und einen SSH-Server startet. Glücklicherweise gibt es jedoch Möglichkeiten, dies out-of-the-box erreichen zu können.

Raspberry PI 3 Von Make Magazin - Eigenes Werk, CC BY-SA 4.0, Link

Wie genau das funktioniert, zeige ich in folgendem Artikel.

Die Ersteinrichtung mit WiFi und SSH-Konfiguration

Der Raspberry PI muss in meinem Fall so vorbereitet werden, dass er die folgenden zwei Funktionen direkt beim Hochfahren ausführt:

  • Herstellen einer WiFi-Verbindung, welche mit WPA2 abgesichert ist
  • Starten des SSH-Servers

Glücklicherweise bin ich im Netz auf eine Anleitung gestoßen, welche dieses sog. "Headless"-Setup mit beiden oben genannten Funktionen beschreibt: https://desertbot.io/blog/headless-raspberry-pi-3-bplus-ssh-wifi-setup

Letzte Herausforderung: IP-Adresse

Fährt der Raspberry PI nun hoch, stellt erfolgreich WiFi-Verbindung her und startet den SSH-Server, so bleibt noch eine letzte Herausforderung. Da kein Monitor am Raspberry PI angeschlossen ist, kennt man die IP-Adresse des Gerätes nicht, um sich per SSH verbinden zu können. Hier gibt es zwei Möglichkeiten:

  • In meinem Fall, ein Netzwerk mit AVM Fritz!Box Router, besitzt der Raspberry PI einen Standard-Hostnamen, der normalerweise auflösbar ist: raspberrypi.fritz.box
  • Funktioniert die oben genannte Namensauflösung nicht, so kann man bspw. noch im Router des heimischen Netzwerks nachschauen, welche IP-Adresse vom DHCP-Server an den Raspberry PI verteilt wurde. Alternativ kann man das Netzwerk scannen mit entsprechenden Tools. Für Linux/macOS bietet sich zum Beispiel der Netzwerkscanner "nmap" an, für mobile Geräte gibt es Apps wie "Fing"

Fazit: Konfiguration ohne Monitor und Tastatur ist herausfordernd, aber nicht unmöglich

Die Einrichtung mit Monitor und Tastatur ist zwar immer noch die einfachste Variante. Nichts desto trotz stehen Möglichkeiten zur Verfügung, auch ohne die entsprechenden Geräte einen Raspberry PI einzurichten.


"Wi-Fi Password Sharing" in iOS 11 kann ggf. Risiko für Unternehmen sein

Geschrieben am 20. Jan 2018, 17:41

Apple hat im Januar 2018 den iOS Security Guide aktualisiert und Inhalte zu neuen Funktionen in iOS 11 ergänzt (siehe auch Apple aktualisiert iOS Security Guide für iOS 11). Ein neuer wesentlicher Absatz findet sich im Dokument, welcher in der Dokumentenrevision nicht erwähnt wird: "Wi-Fi Password Sharing". Die Funktion, welche für den Privateinsatz sehr hilfreich sein kann, kann für Unternehmensnetzwerke unter bestimmten Bedingungen Risiken erzeugen. Welche das sind, wird im Folgenden erläutert.

Erläuterungen zu "Wi-Fi Password Sharing"

"Wi-Fi Password Sharing" ermöglicht es, ein W-LAN Passwort zwischen befreundeten Geräten zu übertragen, so dass ein etwaiges W-LAN Passwort nicht erneut eingegeben werden muss. Dazu ist es notwendig, dass Bluetooth aktiviert, beide Personen sich jeweils in den Kontakte angelegt haben und die beiden Geräte nahe beinander sind (maximaler Abstand ca. 1 Meter). Nach Freigabe der Übertragung auf dem Gerät des Senders wird der W-LAN-Zugang zum Empfängergerät übertragen. Ein W-LAN-Zugriff ist fortan möglich. Die Funktion erscheint somit auf den ersten Blick hinsichtlich Komfort einen großen Mehrwert für den Nutzer zu bringen. Die Übertragung des W-LAN-Passworts (PSK, Pre Shared Key) geschieht per Bluetooth, wie die Erklärung von Apple aus dem Dokument aufzeigt: "Once identify is proven, the grantor sends the requestor the 64 character PSK, which can also be used to join the network." Der Umstand, dass lediglich der PSK (Pre Shared Key) des W-LAN übertragen wird, lässt darauf schließen, dass mit Zertifikaten abgesicherte W-LAN's (wie üblich in Unternehmen) davon nicht betroffen sind und somit potenziell keine Gefahr für die Sicherheit davon ausgeht. Eine Deaktivierung dieses Features lässt sich, laut dem Security Guide, mittels einer Mobile Device Management Lösung (MDM) erreichen: "Organizations can restrict the use of Wi-Fi password sharing for devices or apps being managed by using an MDM solution." Eine offizielle Einstellung dazu gibt es für die iOS-Konfigurationsprofile nicht. Eine Recherche meinerseits hat jedoch ergeben, dass zur Deaktivierung der Funktion AirDrop auf dem Gerät vollständig deaktiviert sein muss.

Risiko: W-LAN PSK in Konfigurationsprofilen

Wie oben erläutert, wird beim "Wi-Fi Password Sharing" der Pre-Shared-Key eines W-LANs auf ein befreundetes Gerät per Bluetooth übertragen. Einer Recherche nach trifft dies ebenfalls auf W-LANs zu, welche per Konfigurationsprofil und einer Mobile Device Management Lösung auf das Gerät gespielt wurden (vgl.: https://www.jamf.com/jamf-nation/discussions/25413/ios-11-wifi-sharing). Dies kann für W-LANs in Unternehmen ein Problem darstellen, sofern diese nicht per Zertifikat, sondern per PSK abgesichert sind. Die Risiken sind:

  • Wenn ein per MDM gemanagtes Gerät den PSK im iOS Konfigurationsprofil auf ein befreundetes Gerät überspielt, kann selbst bei Unkenntnis des W-LAN PSK somit ein fremdes Gerät dem Unternehmensnetzwerk beitreten.
  • Erhält ein befreundetes, aber nicht per MDM gemanagtes Gerät den W-LAN PSK, wird dieser über die iCloud Synchronisation auf fremde Gerät, bspw. ein macOS-Gerät übertragen. Das Passwort kann dann in der macOS Keychain eingesehen werden. Der W-LAN PSK ist damit nicht mehr sicher.

In beiden Fällen kann davon ausgegangen werden, dass entweder sich fremde Geräte in einem Netz befinden oder das Passwort für den Zugang bekannt wird. Eine Sicherheit ist dann nicht mehr gewährleistet.

Abhilfe nur durch AirDrop-Deaktivierung oder Umstellung auf zertifikatsbasierte Authentifizierung

Es gibt zwei mögliche Ansätze zur Behebung der Sicherheitsrisiken, wobei jedoch eine der beiden lediglich als Workaround zu sehen ist.

  • Workaround: Eine kurzfristige Eindämmung des Risiko's bringt die Deaktivierung von AirDrop auf gemanagten Geräten. Dazu sieht die iOS Konfiguration einen Parameter "allowAirdrop" vor, welcher AirDrop auf einem Gerät vollständig deaktiviert. Dann lässt sich "Wi-Fi Password Sharing" nicht mehr benutzen und ein W-LAN-Passwort somit nicht auf ein fremdes Gerät übertragen. Voraussetzung ist jedoch, dass das entsprechende iOS-Gerät "Supervised" ist, was nicht automatisch gegeben ist.
  • Langfristlösung: Aus Sicherheitsgründen sollte erwogen werden, ob der Zugriff zu einem Firmennetzwerk überhaupt noch auf einem Passwort basieren sollte oder ob die Umstellung auf zertifikatsbasierte Authentifizierung das Mittel der Wahl ist. Die Funktion "Wi-Fi Password Sharing" überträgt nach aktueller Wissenslage keine Zertifikate. Der Zugriff zu einem W-LAN wäre daher nicht gefährdet. Zudem bringt eine zertifikatsbasierte Authentifizierung weitere Vorteile mit sich, die insbesondere in Unternehmensnetzwerken Vorteile bringen (bspw. Widerruf einzelner Zertifikate, höhere Sicherheit).

Quellen:


iOS-Geräte provisorisch zum Apple Device Enrollment Program hinzufügen

Geschrieben am 24. Sep 2017, 15:34

Mit der Veröffentlichung von iOS 11 sowie der gleichzeitigen Bereitstellung des Apple Configurator 2 (Version 2.5) am 19. September 2017 gibt es nun die Möglichkeit, iOS-Geräte provisorisch zum Apple Device Enrollment Program (DEP) einzubinden. Diese Möglichkeit bietet insbesondere für Unternehmen neue Chancen.

Was ist das Apple Device Enrollment Program (DEP)?

Dieser Apple Service richtet sich an Unternehmen und Schulen. Zentral beschaffte iOS-Geräte können im Apple DEP-Portal mit einem Mobile Device Management (MDM) Server verknüpft werden, was die Inbetriebnahme des Geräts durch automatisches Einhängen in den MDM-Server deutlich vereinfacht und größtmöglich automatisiert. Durch Nutzung von DEP in Verbindung mit MDM, kann zudem der so genannte "Supervised" Modus auf den Geräten Over-the-Air, d. h. ohne Betreuung durch die IT-Organisation, aktiviert werden. Supervised erlaubt es beispielsweise, die Geräte von Apple ID's zu entkoppeln und damit den Activation Lock auszuschalten. Dies erlaubt eine Wiederverwendung des Geräts, selbst wenn der Zugriff zur Apple ID nicht mehr vorliegen sollte. Weitere Informationen zu DEP gibt es hier: https://www.apple.com/business/dep/

Weshalb ist die neue provisorische DEP-Verknüpfung hilfreich?

iOS-Geräte konnten bisher nur über die folgenden zwei Wege in den DEP-Service integriert werden:

  • Beschaffung der Geräte über einen akkreditierten Apple-Reseller oder Mobilfunkprovider (leider gibt es keine öffentlich verfügbare Liste) ODER
  • Beschaffung der Geräte über Apple direkt

Zusätzlich steht der DEP-Service nur in einer geringen Anzahl von Ländern (siehe hier) zur Verfügung, was die Nutzung erheblich einschränkt. Beispielhaft sei mit Stand von heute (24. September 2017) erwähnt, dass Russland nicht zu diesen Ländern gehört und daher DEP dort nicht genutzt werden kann. Mit der neuen provisorischen DEP-Verknüpfung ist es nun möglich, iOS-Geräten in den DEP-Service von Apple einzuhängen, auch wenn diese nicht über einen der beiden oben genannten Wege bezogen wurden. Im Falle von Schulen können beipielsweise gespendete Geräte dann dem DEP-Bestand hinzugefügt werden.

Wie funktioniert die provisorische DEP-Verknüpfung?

Die provisorische DEP-Verknüpfung kann derzeit nur unter folgenden Bedingungen angewendet werden:

  • das iOS-Gerät ist mit iOS 11 ausgestattet und
  • der Apple Configurator 2 (in Version 2.5) wird verwendet.

Das iOS-Gerät wird unter Verwendung des Apple Configurator 2 zum DEP hinzugefügt. Das Hinzufügen zum DEP geschieht auf provisorischer Basis. Im Folgenden bedeutet dies:

  • Das iOS-Gerät erhält ein DEP Enrollment Profile und wird beim ersten Starten mit dem DEP-Server sowie dem hinterlegten MDM-Server verbunden.
  • Das DEP-Profil hat eine Gültigkeitsfrist von 30 Tagen (deshalb "provisorisch"). Innerhalb des Zeitraums kann das DEP-Profil vom Nutzer gelöscht werden (eine Löschung hat einen Factory Reset zur Folge).
  • Läuft der Gültigkeitszeitraum von 30 Tagen ab und das Profil wurde nicht vom Gerät entfernt, wird das Gerät dauerhaft dem DEP-Service hinzugefügt. Alle weiteren DEP-Funktionalitäten sind nun dauerhaft und in vollem Umfang zu nutzen.

Wie kann nun ein Gerät provisorisch zu DEP hinzugefügt werden?

Die folgende Bilderserie veranschaulicht den Enrollment-Prozess. Achtung: Durchführung des DEP-Enrollments mit einem iOS-Gerät und dem Apple Configurator führt zu einem Factory-Reset, bei dem alle Daten auf dem Gerät unwiederbringlich gelöscht werden! [gallery ids="151,156,152,153,154,155"] Nach Einhängen des Geräts in das DEP-System, zeigt sich bei der Inbetriebnahme ein neuer Installationsschritt 'Remote Management': [gallery ids="158,159"]

Was ist abschließend zu tun?

Nach Durchführung aller obigen Schritte gibt es keine weiteren Tätigkeiten. Nach Ablauf des 30-tägigen Gültigkeitszeitraums wird das Gerät permanent in das DEP-System bei Apple aufgenommen und alle Funktionen sind vollumfänglich nutzbar. Fazit: Das provisorische Hinzufügen von iOS-Geräten zum DEP-System bei Apple schließt eine bisher vorhandene Lücke. Durch den bis dato bestehenden Zwang, iOS-Geräte über akkreditierte Apple-Reseller oder Mobilfunkprovider beziehen zu müssen, war es Unternehmen nicht möglich, vorhandene iOS-Geräte dem DEP-System zu zuführen. Es ergeben sich nun folgende neue Möglichkeiten im Bereich der iOS-Nutzung für Unternehmen:

  • Es bestehen somit Migrationspfade, um eine bestehende iOS-Landschaft 'DEP-fähig' zu machen.
  • Unternehmen in Ländern, welche keine Möglichkeiten haben, Geräte von akkreditierten Apple-Resellern zu beziehen (bspw. Russland), können Geräte zu bestehenden DEP-Accounts hinzufügen.

Die von Apple hier geschaffene Möglichkeit scheint in erster Linie positiv zu sein, da sie es Unternehmen ermöglicht, von DEP auch kurzfristig zu profitieren. Ob jedoch der oben vorgestellte Weg hinsichtlich Geschwindigkeit und Flexibilität bei großen iOS-Landschaften mit mehreren tausend iOS-Geräten hinreichend gut skaliert, muss im Einzelfall erwogen werden. Quellen:


D-Link Omna 180 (v1.4) und AVM Fritz!Box (> v7.01) Mesh Probleme sind behoben

Geschrieben am 30. Jun 2019, 10:02

Seit der Veröffentlichung von Fritz!OS Version 7 durch den Hersteller AVM, und die damit verbundene Einführung von Mesh, gab es Probleme bei der Einbindung der Homekit-kompatiblen Kamera D-Link Omna 180 CAM HD. Die Ursache lag in der Instabilität des WPA2/WPA-Handshakes zwischen der Kamera sowie der Fritz!Box seit der Einführung von Mesh durch AVM. Verschiedene Medien berichteten über die Inkompatibilität (siehe u. a. https://www.golem.de/news/wlan-d-link-kameras-haben-probleme-mit-fritzbox-mesh-1901-138610.html).

AVM Fritz!Box 7490 D-Link Omna 180 CAM HD

Mich betrafen diese Probleme ebenfalls, weshalb die Kamera häufig die W-LAN-Verbindung verlor und damit nicht benutzbar war. Verschiedene diskutierte Workarounds, bspw. die Abschaltung von WPA & WPA2 im Parallelmodus, halfen zumindest bei mir nicht.

Nach einiger Zeit, welche nun vergangen ist, habe ich eine erneute Inbetriebnahme der Kamera gestern versucht. Damit verbunden war gleichzeitig eine Aktualisierung der entsprechenden Firmware:

  • D-Link Omna 180 CAM HD: Version 1.4 (alte bekannte und imkompatible Version: 1.3)
  • Fritz!Box: Fritz!OS Version 7.11 (alte bekannte und imkompatible Version: 7.01)

Zumindest seit der Aktualisierung der Software-Versionen beider Geräte, Kamera wie auch Netzwerk-Router, kann ich zumindest berichten, dass seit dem keine Verbindungsprobleme mehr auftraten.

Man kann nun also hoffen, dass das Problem beidseitig nachhaltig behoben wurde. Ich jedenfalls erfreue mich an meiner Kamera!


FRITZ!Box: Nicht funktionierende LAN-LAN-Kopplung (Routing) bei fehlerhafter VPN-Konfiguration

Geschrieben am 03. Jan 2021, 12:17

Seit einigen Jahren bieten die weit verbreiteten AVM FRITZ!Boxen die Möglichkeit, VPN-Tunnel zwischen mehreren FRITZ!Boxen aufbauen zu können. Ich hatte geplant, mein eigenes Heimnetz mit dem meiner Eltern zu koppeln, um regelmäßig Backups von den Computern meiner Eltern erstellen zu können. Durch die VPN-Kopplung, auch LAN-LAN-Kopplung genannt, wäre eine Datenübertragung sicher und verschlüsselt möglich gewesen. Bei der Einrichtung der Konfiguration bin ich jedoch auf einen Fehler gestoßen, welcher zwar einen Verbindungsaufbau ermöglicht hat, jedoch kein Datentransfer zwischen den Netzen möglich war. Wie ich das Problem gelöst habe, möchte ich hier beschreiben.

Das Setup

Mein Setup sah in aller Kürze wie folgt aus:

  • Netzwerk 1 (Mein Heimnetz):
    • FRITZ!Box 1 (private Adresse: 192.168.178.1): FRITZ!Box 7490 mit OS-Version 07.21 (aktuelle Version bis dato)
    • Netzwerkkonfiguration: 192.168.178.0/24
    • Verfügt über öffentliche IPv4-Adresse sowie DNS-Name über Myfritz.net
  • Netzwerk 2 (Heimnetz einer Eltern):
    • FRITZ!Box 2 (private Adresse: 192.168.0.1): FRITZ!Box 7390 mit OS-Version 06.86 (aktuelle Version bis dato)
    • Netzwerkkonfiguration: 192.168.0.0/24
    • Verfügt über öffentliche IPv4-Adresse sowie DNS-Name über Myfritz.net

In den jeweiligen Netzwerken (Netzwerk 1 & 2) befinden sich jeweils eine Vielzahl von Geräten. Das Ziel war, einen Computer im Netzwerk 2 regelmäßig auf einen weiteren Computer in Netzwerk 1 zu sichern.

Das Problem

Die Einrichtung des VPN-Tunnels (LAN-LAN-Kopplung) zwischen den zwei FRITZ!Boxen war erfolgreich und eine Verbindung konnte aufgebaut werden. Trotz des erfolreichen Aufbaus konnte jedoch kein Datentransfer stattfinden. Das Symptom war ein Routing, welches fehlerhaft schien, der der Verbindungsversuch aus dem Netzwerk 1 in das Netzwerk 2 hinein nicht klappte. 

Ich begab mich also auf Fehlersuche.

Die Lösung

Bei der Diagnose der Konfiguration und der so genannten Ereignis-Logs auf den FRITZ!Boxen fiel mir auf der entfernten Box ein wiederkehrender Fehler auf:

03.01.21 10:36:49 VPN-Fehler: 95.91.247.201, IKE-Error 0x2027 [4 Meldungen seit 03.01.21 10:35:11]

Der oben hervorgehobene IKE-Error 0x2027 bedeutet grundsätzlich erstmal nichts anderes, als das beim Aufbau eines Tunnels ein Timeout erfolgte (Quelle: https://service.avm.de/help/de/FRITZ-Box-Fon-WLAN-7390/016/hilfe_syslog_122). Mir fiel jedoch auf, dass die hier genannte IP-Adresse (95.91.247.201) nicht zu der öffentlichen IPv4-Adresse der beiden FRITZ!Boxen gehörte.

Es stellt sich heraus, dass dies ein Relikt aus einem früheren Versuch war, einen VPN-Tunnel einzurichten. Nach Löschen der Konfiguration, welche regelmäßig den Timeout erzeugte, klappte der Datentransfer der just eingerichteten LAN-LAN-Kopplung.

Das Fazit

Es scheint, als wenn die VPN-Komponente von FRITZ!OS bei einer fehlerhaften Konfiguration, welche zu einem Timeout beim Versuch eines Verbindungsaufbaus führt, alle weiteren eingerichteten VPN-Konfigurationen stört.

Meine Empfehlung ist daher, bei nicht ordnungsmäß funktionierenden VPN-Tunneln die Konfiguration der anderen VPN-Tunnel, sofern es welche gibt, zu prüfen.


Julian Joswig

Julian Joswig Facebook Julian Joswig LinkedIn Julian Joswig Twitter Julian Joswig XING

Über diesen Blog

Was ist der Inhalt dieses Blogs, fragt ihr euch vielleicht? Mein Name ist Julian Joswig und ich bin großer Fan von IT und Technologie (hauptsächlich Linux, Server, Netzwerke und alle damit verbundenen Themen). Manchmal beiße ich mir an schwierigen Sachverhalten fast die Zähne aus. Habe ich jedoch eine Lösung gefunden, möchte ich diese mit der Welt teilen. Beruflich arbeite ich als Management Consultant in Deutschland mit Fokus auf IT und Business.

Neueste Artikel:

Artikelarchiv:

Twitter Timeline: