Julian Joswig: IT Blog

Zeige alle Artikel im Tag WLAN

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:


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!


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: