Schlagwort-Archive: Hacking

Firewall, Funkfeuer, Linux, Raspberry Pi

Wieso wird mein/e … gehackt?

Schreibe einen Kommentar

Ich werde das sehr oft gefragt, daher ist es mir einen Beitrag wert:
„Wieso wurde mein/e … gehackt? Was hat der/die Hacker/in davon? Es ist ja nur ein kleines Gerät im Internet!“

Vor allem aufgrund eines Vorfalls mit Antennen von Uniquiti, die Mitte Mai massenhaft gehackt wurden und mich dazu bewegt haben, einen Blogbeitag zu verfassen, der mittlerweile zu den Meistgelesenen auf dieser Webseite gehört, wurde ich das gefragt.

Die Antwort ist eigentlich ganz einfach, aber schwierig kurz und prägnant zu erklären.

Viele dieser „kleinen“ Geräte, die da gehackt werden – egal ob Antenne, Router, Smartphones oder andere – besitzen ein mächtiges Betriebssystem, und das kann dem Zweck des Hackers nutzen. Es geht also nicht darum, das Gerät vom Netz zu trennen oder die Funktion einzuschränken: es geht darum, Zugrif auf das Gerät zu erlangen und dieses künftig für eigene Zwecke (mit) zu nutzen.

Oft wird die ursprüngliche Funktion des Geräts gar nicht beeinträchtigt – sonst würden die Besitzer ja merken, dass sie gehackt wurden und danach streben, die schadhafte Software zu entfernen. Ist doch praktischer, wenn’s keiner merkt…

Die Geräte werden oft so umprogrammiert (bzw. wird zusätzlich Software installiert), sodass sie auf Arbeitsaufträge („Kommandos“) aus dem Internet horchen und diese dann ausführen. Sie sind dann an sogenannte „Command and Control“-Systeme/-Server angebunden.

Das klingt jetzt noch nicht mächtig, aber wenn man berücksichtigt, dass hunderttausende solcher Geräte, über die Welt verteilt, an so einem System teilhaben, wird klarer, welches Potenzial dadurch entsteht.

Dieses Thema wird sich meiner Einschätzung nach im Zukunft noch zuspitzen: es werden immer mehr Geräte werden ans Internet angebunden und diese werden auch immer leistungsfähiger. Dadurch eignen sie sich immer mehr für solche Aktionen… Man nennt das auch die Ära des Internet of Things (IoT), auf die wir uns rasant zubewegen.

Was kann man dagegen tun? Ein wesentlicher Tipp ist bestimmt, möglichst aktuelle Updates einzuspielen, die häufig Sicherheitslücken beheben, mit denen Angreifer überhaupt die Möglichkeiten bekommen, Zugang zum Gerät zu erlangen und Schadsoftware aufzuspielen. Ansonsten rate ich weiterhin dazu, bewusster zu überlegen, ob wirklich alle Geräte ans Internet angebunden sein müssen bzw. Zugriff darauf haben müssen. Reicht es nicht, wenn zB. Elemente einer Hausautomatisierung mit der Zentrale kommunizieren können? Muss denn jedes Gerät uneingeschränkt mit dem Internet Daten austauschen können?

Mich hat ein aktuelles Ereignis (auch hier sehr gut beschrieben) zu diesem Beitrag inspiriert, außerdem wird dieses Thema nun auch von den Medien verstärkt aufgegriffen und verstanden. In diesem Fall haben hunderttausende Geräte die Kapazität ihrer Internetanbindung genutzt, um die Anbindungen und Bandbreiten großer Webportale lahmzulegen. Das nennt man eine Distributed Denial of Service-Attacke.

App, Firewall, Smartphone, Unterwegs, WLAN

WLAN Hotspots: automatisch mittels App einloggen

3 Kommentare

Ich habe diese App seit Monaten gesucht! Für mein Privathandy habe ich nämlich einen Wertkartenvertrag ohne mobile Datennutzung. Damit bin ich nicht nur im Ausland auf Hotspots angewiesen.

WIFin heißt das Ding. Es ist gratis und hier im Google Play Store zu finden.

Update 3.9.2016: die App heißt nun Neer WiFi, ist aber weiterhin unter dem oben genannten Link zu erhalten.

Screenshot_20160829-174937Screenshot_20160829-174946Die App erkennt WLANs, bei denen vor Akivierung des Internetzugangs noch Nutzungsbedingungen akzeptiert werden müssen. Gängige Captive Portal-Lösungen erkennt die App automatisch und versucht sie freizuschalten – aber erst sobald man das möchte. In Zukunft führt die App die nötigen Schritte dann von selbst für die der App bekannten SSIDs aus.

Es ist schon super, wenn man mit der Schnellbahn fährt und alle 2-3 Stationen synct das Handy mit dem Gratis WLAN am Bahnsteig… Das Ganze funktioniert so flott, dass man quasi mit dem Einfahren in die Station auch schon surfen könnte.

Konfigurieren eines Hotspots

Wenn ein WLAN genutzt wird, das die App noch nicht kennt, zeigt sie dies an.

Screenshot_20160829-174959Indem man auf diese Meldung tippt wird für das aktuelle WLAN eine Konfiguration angelegt. Im ersten Feld fragt die App, ob eine spezielle URL aufgerufen werden soll. Im Zweifelsfall drückt man einfach auf „continue“ und lässt das Feld leer.

Screenshot_20160829-175004Die App analysiert nun im Hintergrund die „Landing Page“, wie die Seite auch genannt wird, auf denen die Nutzungsbedingungen präsentiert werden. Meist ist diese Seite mit einem Button zu bestätigen und manchmal ist auch ein Hakerl zu setzen, um seine Zustimmung zu den Bedingungen zu bestätigen. Die App führt ggf. beide Aktionen aus bestätigt dies mit einer Meldung: „We’re done doing the Math, the rest is history!“. Mit dieser Siegesmeldung bestätigt die App, dass der Internetzugang freigeschaltet ist.

Screenshot_20160829-175018In Zukunft erscheint eine Meldung sobald man sich wieder mit dem WLAN verbindet. Unmittelbar darauf bestätigt die App selbstständig die Nutzungsbedingungen und man ist online.

Im Hauptmenü kann man die SSIDs, zu denen es Konfigurationen gibt, anzeigen und ggf. die Profile/Konfigurationen wieder löschen.

Eine Status-Seite gibt Auskunft zu grundlegenden Parametern der Internet-Verbindung.

Beta Programm

Es gibt ein Beta-Programm, zu dem man sich über’s entsprechende Menü anmelden kann. In der Beta-App habe ich bisher keine Unterschiede festgestellt.

Gleiche SSID aber anderes Captive Portal schlägt fehl

Es gibt Hotspot-Anbieter, die auf verschiedenen Standorten unterschiedliche Captive Portal-Produkte einsetzen, die mit unterschiedlicher Methode funktionieren. Damit hat die App Probleme. Sie erlernt die Methode, die bei der ersten Verbindung erkannt wurde, und versucht auf diesem Weg bei allen gleichnamigen zukünftigen Hotspots vorzugehen. An Standorten, die ein bißerl anders funktionieren, ist sie manchmal erfolglos.

Rechtlicher Gedanke

Die Nutzungsbedingungen haben einen Zweck: der Benutzer soll informiert werden und aufgefordert worden, nichts Unrechtes über dieses Netzwerk zu tätigen; gleichzeitig hält sich der Betreiber in mehrfacher Hinsicht schadlos. Durch das automatisierte Akzeptieren der Nutzungsbedingungen hat man diesen Bedingungen vielleicht nicht rechtsgültig zugestimmt? Selbst wenn man beim ersten „Anlernen“ der Landing Page in der App die Bedingungen gelesen hat, wird man Änderungen ebendieser vermutlich nicht erkennen können. Ich empfehle also, an Standorten, die man besucht, immer wieder bewusst die Nutzungsbedingungen zu reviewen. Welche SSIDs das sind, zeigt die App ja an…

Allgemein, App, Funkfeuer, Smartphone, Unterwegs, WLAN

Sichere SMS?

3 Kommentare

Ich werde oft gefragt, ob ich WhatsApp verwende. Das tu ich nicht, vor allem aus der Überlegung, dass WhatsApp ursprünglich keine zuverlässige Verschlüsselung bzw. Sicherheit geboten hat.

Mittlerweile hat sich die Situation geändert: WhatsApp wurde von Facebook übernommen und WhatsApp bietet nun Verschlüsselung an. Ein Umstieg ist für mich trotzdem kein Thema.

Bitte beachtet, dass ich in diesem Artikel meine persönliche Wahl beschreibe, die ich gerne als Empfehlung weitergebe. Ich habe damit schließlich gute Erfahrungen gemacht. Es gibt in diesem Themenkreis  auch andere Produkte und Lösungen, die eine Berechtigung haben. Ich möchte mit diesem Artikel keine Übersicht über die verfügbaren Lösungen schaffen, sondern meine konkrete Auswahl erklären und begründen.

Was sind also die Alternativen, für die ich mich entschieden habe?

Ich sehe zwei Lösungen die ich hier im Dunstkreis von Instant Messaging, SMS & text messages, Austausch von Video-, Foto-, Dokument-, Standortinformationen oder Kontaktdaten erwähnen würde.

Threema

Als viele User begonnen haben WhatsApp zu nutzen, war mir – wie oben erwähnt – die Verschlüsselung zu unsicher oder hat überhaupt gefehlt, wodurch ich auf Threema als Alternative aufmerksam wurde.

Threema umfasst die für mich wichtigen Funktionen und Eigenschaften. Es wurde einem Schweizer Unternehmen geschaffen, das von Anfang an auf Ende-zu-Ende-Verschlüsselung nach Industriestandards Wert gelegt hat. Eine genaue Beschreibung der Vorteile findet man naturgemäß auf der Webseite von Threema: https://threema.ch/de/

Signal / SecureText

SecureText konkurriert nicht automatisch mit WhatsApp oder Threema. Es ist eigentlich ein Ersatz für die SMS App am lokalen Smartphone. Eingehende SMS-Nachrichten können – entsprechende Konfiguration vorausgesetzt – von SecureText empfangen werden. Sie werden auch über SecureText beantwortet.

Der Clou dabei: wenn der/die Empfänger/in einer SMS auch SecureText installiert hat (das erkennt SecureText automatisch an der Handynummer), wird die Nachricht stark verschlüsselt über das Internet versendet und nicht als SMS. SecureText zeigt das über ein Symbol an (ein verschlossenes Schloss beim Sendeknopf weist auf eine sichere Übertragung über das Internet hin).

Was mir an SecureText gut gefällt ist, dass es ein schöner Ersatz für die Standard-SMS-App ist, keinen Zusatzaufwand produziert und dennoch

  1. Kosten spart (keine SMS-Kosten, wenn nicht nötig, sondern Versand über’s Internet – auch im Ausland interessant)
  2. im Hintergrund automatisch verschlüsselt – wenn es der/die Empfänger/in unterstützt.

SecureText wurde mittlerweile zu „Signal“ umbenannt und ist unter diesem Namen in den App Stores kostenfrei zu finden.

Gibt es auch Nachteile?

Durchaus. Wobei das teilweise auch auf WhatsApp und andere zutrifft.

Kosten

Es wurde schon oft diskutiert: sichere Apps dürfen etwas kosten. Oder umgekehrt gedacht: woran verdienen die Unternehmen, die kostenlose Apps verteilen? Da liegt immer der Verdacht nahe, dass es die Inhalte der User sind, die den Wert darstellen und kommerziell genutzt werden.

Diejenigen, die wirklich so leiwand sind, dass sie gute Produkte kostenfrei zur Verfügung stellen, sind meistens auch so leiwand, dass sie den Source Code zur Verfügung stellen. Und das hat wirklich einen Mehrwert, weil man dann die Sicherheit nachvollziehen kann.

Threema kostet aktuell CHF 2,00 (oder 0,0048 BTC, BitCoins)  auf der Homepage oder € 2,49 im Google Play Store. Bei iOS löhnt man € 2,99 im Apple App Store.

SecureText (heißt jetzt: Signal) ist kostenlos erhältlich.

Proprietär

WhatsApp-Benutzer können nur mit WhatsApp-Benutzern Nachrichten austauschen. Threema-Benutzer können nur mit Threema-Benutzern Nachrichten austauschen. Das ist weitreichend durch die Technologie vorgegeben.

Es zahlt sich also aus, mal im Freundeskreis zu fragen, welche Apps genutzt werden und ob eine Änderung zu Threema denkbar wäre. Die Antwort muss man dann mit den eigenen Sicherheitsbedenken abzuwägen.

Im Zweifelsfall kann man ja mehrere Messaging Apps installieren. Das ist aber nicht mein Weg.

kein Internet = keine Nachrichten

Das ist mir im Fall von Threema unangenehm aufgefallen. Da kann aber Threema eigentlich nichts dafür. Aus Sicht der Nutzbarkeit möchte ich trotzdem darauf hinweisen:

  1. Mein Handy (eigentlich: Smartphone) ist oft tagelang über das Firmen-VPN verbunden. Aus dem Firmen-VPN kann aber leider weder Threema noch SecureText verschlüsselte Nachrichten ins Internet senden oder von dort empfangen. Die Sicherheitssysteme des Unternehmens unterbinden das.
    Die Nachrichten „hängen“ also lange in meinem Handy rum, bis ich irgendwann zB. bei einem öffentlichen Hotspot mit direktem (ungefilterten) Internetzugang befinde. Und dann geht’s rund: plötzlich kommen zahlreiche Nachrichten  aus den letzten Stunden an und meine Nachrichten gehen erst jetzt raus.
    Wenn jemand mit dem Smartphone eh immer oder zumindest regelmäßig direkt mit dem Internet verbunden ist, hat er/sie das Problem aber wahrscheinlich nicht.
  2. Ich bin ja recht engagiert bei Internetprojekten tätig. Oft geht es darum, einen Internetzugang herzustellen (= den gibt es also noch nicht). Und wenn da ein Kollege am Dach ein Problem per Threema beschreibt, kann es sein, dass ich die Nachricht erst erhalte, sobald das Problem behoben ist und die Internetverbindung für uns beide wieder klappt. Das ist zwar auch eine Erkenntnis, war aber nicht hilfreich.
    In solchen Fällen ist eine klassische SMS immer noch gut. Man kann im SecureText das auch einstellen, dass man nun lieber eine SMS versenden möchte, als eine verschlüsselte Nachricht – auch wenn der/die Empfänger/in damit umgehen könnte.
  3. mir fallen da noch mehrere Beispiele ein: im fernen Ausland nutzt man üblicherweise keine permanente mobile Datenverbindung. Entsprechend kommen also auch dort die Nachrichten nicht sofort durch. SMS würden sofort ankommen und der Empfang auch keine – oder geringe? – Kosten verursachen.

Fazit: kein internet = keine Nachrichten. Das sollte einem bewusst sein.

Nachtrag / Update

Ich wurde von mehreren Seiten auf diesen Blogbeitrag angesprochen. Der wesentliche Input war, dass WhatsApp mittlerweile die Verschlüsselung von Signal übernommen hat. Im Gegenzug hat Google eine Alternative („Allo“) gelauncht, die zweifelhafter Weise nur bei Nutzung des Inkognito-Modus verschlüsselt.

2. Nachtrag (August 2016)

Mittlerweile hat Whatsapp angekündigt, weitere Nutzungsdaten und auch die Telefonnummern der User an Facebook weiterzureichen, um damit genauere Profile zu ermöglichen. Widerstand scheint zwecklos, es gibt jedoch die Möglichkeit, die Reichweite der Nutzung dieser Daten einzuschränken – ganz lässt sich die Weitergabe nicht verhindern.

Ich freue mich, dass seit der Ankündigung von WhatsApp/Facebook viele meiner Kommunikationspartner und Freunde zu den in diesem Beitrage beschriebenen Systemen gewechselt sind, die ich auch nutze.

App, Code, Firewall, Funkfeuer, Linux

Lösungsvorschläge für den Ubiquiti AirOS AiRMAX Hack vom Mai 2016 im Netz von Funkfeuer Wien

2 Kommentare

airoslogin-motherAm 13. +14. Mai 2016 wurde eine Sicherheitslücke (vmtl. im Webserver) der Ubiquiti Airmax Antennen mit AirOS Software ausgenutzt. Die Gesamtzahl der Standorte ist von etwa 230 aktiven Knoten auf knapp mehr als 150 Nodes zurückgegangen, die  unmittelbar nach der Attacke noch online waren. Mittlerweile geht die Zahl zum Glück wieder nach oben.

Aus jetziger Sicht platziert der Hack einige Dateien unter /etc/persistent. Außerdem werden die Login-Daten überschrieben und SSH-Keys installiert, mit denen ein Hacker von außen weiterhin auf die Antenne zugreifen kann.

Sollten Spuren des Hacks auf einer Antenne auftauchen, ist es jedenfalls empfehlenswert, per TFTP ein Image neu zu laden und die Antenne neu zu konfigurieren. Die Vorschläge weiter unten in diesem Text sind eher als Sofortmaßnahme gedacht, um die Antennen rasch wieder online zu bekommen.

Auswirkungen / Festellen des Hacks

Ich habe zwei Auswirkungen des Problems auf meinen Antennen festgestellt:

  • Großteils sind die Antennen auf Werkseinstellungen zurückgesetzt und daher über 192.168.1.20 mit Username „ubnt“ und Passwort „ubnt“ erreichbar. Eine Veränderung an den Antennen konnte ich nicht feststellen, wodurch das Einspielen eines Backups bzw. eine Neukonfiguration das Problem rasch löst. Idealerweise flasht man die Antenne per TFTP neu. Leider muss man diese Schritte vmtl. vor Ort durchführen, also hinfahren…
  • ubnt-hackManche Antennen sind noch online, aber ich kann mich nicht mehr mit dem bekannten Passwort anmelden. Wenn die Antenne „erfolgreich“ gehackt ist, wurden Username + Passwort auf „mother“ und „fucker“ geändert. Mein „ubnt“-User hat nicht mehr funktioniert, obwohl er in der /etc/passwd noch enthalten ist. Seit dem Entfernen des Hacks funktioniert mein ubnt-User wieder normal. Das Passwort ändert man zur Sicherheit trotzdem.
    Im Verzeichnis /etc/persistent/ findet man außerdem mehrere Files als Hinweis auf den Hack. Diese Antenne ist somit vom Virus befallen und muss gesäubert werden!

Details zum Hack

Details findet ihr im Forum von Ubiquiti Networks. Aktuell beginnen auch erste Händler entsprechende Hinweise zu posten:

Lösungsstrategien

Zuerst muss man feststellen, ob sich die Antenne im Werkszustand befindet oder nicht. Wenn sie über 192.168.1.20 mit Username „ubnt“ und Passwort „ubnt“ per Webbrowser erreichbar ist, kann man wie gewohnt die Konfiguration durchführen bzw. ein Backup einspielen. Besser ist es, zur Sicherheit per TFTP neu zu flashen. Dann kann man wirklich davon ausgehen, dass kein Schadcode erhalten bleibt.

Wichtig: zum Abschluss muss die Firewall konfiguriert werden, sodass Zugriffe über http und https nur von vertrauenswürdigen IP-Adressen möglich sind. Siehe dazu „Konfiguration der Firewall“.

Entfernen des Virus

Falls die Antenne erreichbar ist, gehört unbedingt geprüft, ob der bisherige Login noch funktioniert. Wenn die Antenne gehackt wurde, muss man ab sofort mit den Daten des Hackers, Username „mother“ und Passwort „fucker“, einloggen.

Es gibt ein Removal Tool, das auf Java basiert, von Ubiquiti zum dem Problem: https://community.ubnt.com/t5/airMAX-General-Discussion/Virus-attack-URGENT-UBNT/m-p/1563869

Alternativ gibt es auf Github ein Script, das aber auch den Standard-Port des Webserver auf 81 setzt: https://github.com/diegocanton/remove_ubnt_mf/

Update 16.5.2016: angeblich verbleiben ein paar ipks installiert, es ist somit ein Reset auf Werkseinstellungen (noch besser: per TFTP neu flashen) dem Entfernen/desinfect-Script zu bevorzugen, siehe auch: https://lists.funkfeuer.at/pipermail/wien/2016-May/012228.html

Update 17.5.2016: Ubiquiti stellt eine Android App – ein Virus Removal Tool – zur Verfügung: https://play.google.com/store/apps/details?id=virusfixer.ubnt.com.ubntvirusremoval

Ich habe mir erlaubt, das desinfect.sh-Script (Ausgangspunkt ist commit #c841d87) von Github zu übernehmen und einige Funktionen anzupassen, damit es für meine Zwecke passt.

Funktionsübersicht:

  • das Script wird lokal auf der Antenne über SSH ausgeführt.
  • das Script überprüft, ob die Antenne infiziert ist.
  • die infizierten/veränderten Files werden gelöscht
  • die Accounts für „mcad“, „mcuser“ und „mother“ in /etc/inittab und /etc/passwd werden gelöscht
  • die Änderungen werden persistent gespeichert
  • Prozesse des Hacks werden gekillt
  • wichtig: danach muss die Firewall (siehe unten) konfiguriert und rebootet werden!

Das angepasste Script findet ihr unten und zum Download hier:

#!/bin/sh
# This script removes the Ubiquiti AirOS hack
# Script is based on this work:
# https://github.com/diegocanton/remove_ubnt_mf
# Colaboration: Alexandre Jeronimo Correa - Onda Internet, PVi1 (Git user)
# modified 2016/05/16 by Stefan Schultheis
FILE=/etc/persistent/mf.tar

# Check virus
if [ -e "$FILE" ] ; then
    echo "Infected :("
    #Access folder
    cd /etc/persistent
    #Remove the virus
    rm mf.tar
    rm -Rf .mf
    rm -Rf mcuser
    rm rc.poststart
    rm rc.prestart
    #Remove mcuser in passwd - by Alexandre
    sed -ir '/mcad/ c ' /etc/inittab
    sed -ir '/mcuser/ c ' /etc/passwd
    sed -ir '/mother/ c ' /etc/passwd
    #Write new config
    cfgmtd -w -p /etc/
    #Kill process - by Alexandre
    kill -HUP `/bin/pidof init`
    kill -9 `/bin/pidof mcad`
    kill -9 `/bin/pidof init`
    kill -9 `/bin/pidof search`
    kill -9 `/bin/pidof mother`
    kill -9 `/bin/pidof sleep`
    echo "Clear Completed :)"
else
    echo "Clear :) No actions"
    exit
fi

Wichtig: zum Abschluss muss die Firewall konfiguriert werden, sodass Zugriffe über http, https und ssh nur von vertrauenswürdigen IP-Adressen möglich sind. Siehe dazu „Konfiguration der Firewall“.

Achtung bei Upgrade zu AirOS 5.6.5

Ubiquiti scheint ein Upgrade zu AirOS 5.6.5 zu empfehlen. Hier ist zu beachten, dass es

  1. keine Unterstützung für den Routing-Daemon OLSRd dort gibt,
  2. keine Custom Scripts (/etc/persistent/rc.*) mehr gibt! Dadurch kann die bestehende Funktion eingeschränkt sein!

Konfiguration der Firewall

Ich schalte mir nur einzelne IP-Adressen für den Zugriff auf die Webinterfaces frei, das mache ich mit folgenden iptables-Regeln. Hier werden künftig nur mehr Zugriffe aus 78.41.113.x und 78.41.113.y zugelassen (bitte eigene IPs einsetzen).

touch /etc/persistent/rc.poststart
echo "iptables -F" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -s 78.41.113.x -j ACCEPT" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -s 78.41.113.y -j ACCEPT" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -p tcp --dport 80 -j DROP 2>/dev/null" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -p tcp --dport 443 -j DROP 2>/dev/null" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -p tcp -i lo --dport 443 -j DROP 2>/dev/null" >> /etc/persistent/rc.poststart
cfgmtd -w -p /etc/

Ich empfehle darüber nachzudenken, ob man nicht die Erreichbarkeit von SSH ebenfalls auf ein paar weniger IPs beschränken möchte.

Nach einem Reboot ist die Antenne nur mehr von den oben eingetragenen IPs erreichbar.

Allgemein, Linux, Unterwegs

Linux: GoPro Videos für einfache Bearbeitung mit ffmpeg konvertieren

Schreibe einen Kommentar

Ich habe mir vor ein paar Wochen eine GoPro Hero 4 Black Edition gekauft und natürlich muss ich seither bei jeder Gelegenheit filmen. Da ich zu Hause nur Linux-Systeme verwende, kann ich zur Verarbeitung der Videos nicht auf das GoPro-Studio zurückgreifen. Auch die von GoPro verwendeten Codecs machen die Sache nicht einfacher.

gopro-ffmpegEinen gute Strategie dafür habe ich auf Github von KonradIT gefunden: https://gist.github.com/KonradIT/ee685aee15ba1c3c44b4#file-convert-multiple-files-md

Ich musste das Script bei mir etwas abändern, damit es funktioniert, aber mit dem Ergebnis bin ich sehr zufrieden. Das Script konvertiert mittels ffmpeg alle .MP4-Dateien aus dem lokalen Verzeichnis in .mov-Dateien mit mpeg4, die von gängigen Programmen angezeigt oder weiterbearbeitet werden können.

Hier das angepasste Script:

for i in *.MP4;
  do name=`echo $i | cut -d'.' -f1`;
  echo $name;
  ffmpeg -i $i -sameq -strict experimental -vcodec mpeg4 $name.mov;
done

Nachtrag Juli 2020: ich habe obiges Script nun im Sommer 2020 probiert. Die Option „-sameq“ wurde mittlerweile von ffmpeg entfernt. Ich habe es durch „-qscale 0“ ersetzt. Für mich hat diese abgeänderte Version des Scripts gut funktioniert:

for i in *.MP4;
do name=`echo $i | cut -d'.' -f1`;
echo $name;
ffmpeg -i $i -qscale 0 -strict experimental -vcodec mpeg4 $name.mov;
done

Dieser Konvertierungsvorgang dauert zwar ziemlich lange – bei mir zirka die 6-7fache Spieldauer des Videos, aber es kann im Hintergrund laufen und beseitigt meine Probleme mit fast allen Programmen.

Mein Beispielvideo habe ich mit 2,7k Auflösung (2704×1520) und 50 fps erstellt. Es hat eine Länge von 40,58 Sekunden und ist 305 MB groß.
Der Konvertierungsvorgang hat 4 Minuten 35 Sekunden gedauert (Prozessor Quad Intel(R) Core(TM)2 Quad CPU Q6600  @ 2.40GHz). Die Ergebnisdatei (.mov-Datei) ist 210 MB groß.

Durch hinzufügen des Parameters „-threads 8“ lassen sich mehrere Prozesse zur Konvertierung von ffmpeg nutzen, also mehrere CPU-Kerne, falls verfügbar. Auf meinem System reduziert sich die Dauer damit um ca. 20%-23%.

Funkfeuer, Linux, Unterwegs

Ubiquiti EdgeRouter X mit PPTP Server und lokaler Authentifizierung

Ein Kommentar

Der Ubiquiti EdgeRouter X SFP sieht nach dem perfekten Gateway für meinen Funkfeuer-Zugang zu Hause aus!

Aufgrund der mipsel-Architektur und den debian-Images als Basis der EdgeRouter-Serie besteht die Möglichkeit, die mipsel-Pakete für olsrd und olsrd-plugins manuell nachzuinstallieren und somit das Routingprotokoll für Funkfeuer direkt mitlaufen zu lassen. Dies funktioniert wunderbar für IPv4 und IPv6!

Außerdem ist das Gerät als softwarebasierter 6-Port-Router (5 + 1 SFP) mit PoE-Unterstützung auf 5 Ports ideal für zu Hause und ich kann einzelne Antennen auch direkt mit Strom versorgen.

PPTP Server

Aber nun zu PPTP. Vorab: PPTP ist wohl das unsicherste VPN-Protokoll, das man wählen kann. Es ist aber auch das am einfachsten zu konfigurierende und bei Windows direkt konfigurierbar (= ohne etwas installieren zu müssen).

Bei den folgenden Schritten habe ich mich stark an diesem Youtube-Video orientiert: https://www.youtube.com/watch?v=XqFcPv2lfDI

Die Konfiguration erfolgt über die Kommandozeile, also per SSH oder indem man in der Weboberfläche (GUI) auf „CLI“ klickt.

configure
set vpn pptp remote-access authentication mode local
set vpn pptp remote-access authentication local-users username meinbenutzer password meinpasswort

Die letzte Zeile wiederholt man für alle Benutzer, denen man Zugang gewähren möchte.

set vpn pptp remote-access client-ip-pool start 192.168.1.81
set vpn pptp remote-access client-ip-pool stop 192.168.1.89
set vpn pptp remote-access outside-address 78.41.113.xxx
set vpn pptp remote-access dns-servers server-1 192.168.1.1
set vpn pptp remote-access dns-servers server-2 208.67.222.222

Einige Firewall-Regeln gehören noch gesetzt:

set firewall name WAN_LOCAL rule 30 action accept
set firewall name WAN_LOCAL rule 30 description allow_PPTP
set firewall name WAN_LOCAL rule 30 destination port 1723
set firewall name WAN_LOCAL rule 30 log disable
set firewall name WAN_LOCAL rule 30 protocol tcp
set firewall name WAN_LOCAL rule 40 action accept
set firewall name WAN_LOCAL rule 40 description allow_PPTP_GRE
set firewall name WAN_LOCAL rule 40 log disable
set firewall name WAN_LOCAL rule 40 protocol GRE

Mit den folgenden Kommandos wird die Änderung aktiviert und gespeichert. Mein erster Test war danach sofort erfolgreich!

commit
save

Test mit Windows 7

Auf meinem Windows7-PC habe ich sofort ein VPN hinzugefügt:

  1. Systemsteuerung -> Netzwerk und Freigabecenter
  2. Neue Verbindung oder neues Netzwerk einrichten
  3. Verbindung mit dem Arbeitsplatz herstellen
  4. Die Internetverbindung (VPN) verwenden
  5. Internetadresse: meine externe IP bzw. Hostname des EdgeRouters
  6. Zielname: frei wählbar, zB. „PPTP EdgeRouter“
  7. Benutzername & Kennwort eingeben, so wie die Authentifizierungsinfo am EdgeRouter programmiert wurde; es muss keine Domäne angegeben werden.
  8. auf „Verbinden“ klicken. Fertig!

Ich war sofort verbunden. Als IP-Adresse habe ich eine IP aus dem konfigurierten Pool erhalten! Internetsurfen war möglich! Ich habe meine IP über http://ip4.me überprüft und dort scheint die externe IP des EdgeRouter auf. Ich bin also über das PPTP-VPN und den EdgeRouter im Internet!

fhem, Hausautomatisierung, Linux, Unifi, WLAN

Unifi Controller in fhem einbinden

Schreibe einen Kommentar

Ich habe bereits über meine Unifi-Installation geschrieben, die sich weiterhin bewährt.

Mit großer Freude habe ich gelesen, dass seit 23. August 2015 auch ein Unifi-Modul für fhem verfügbar ist! (Das Changelog sagt: „added: 74_Unifi.pm for the Ubiquiti Networks (UBNT) – Unifi Controller“)

Das muss ich gleich probieren! Einen Unifi-Controller habe ich laufen, jetzt möchte ich diesen mit fhem verbinden und anhand der Clients im WLAN die Anwesenheitserkennung von fhem nutzen.

Mittlerweile habe ich den Unifi Controller in Version 4.6.6 bei mir laufen. Von Version 3 zu Version 4 hat sich einiges geändert, auch in der Unifi API. Es ist daher verständlich, dass man die Versionnummer angeben muss. Gleichzeitig ist es toll, dass das fhem-Modul sowohl Version 3 als auch Version 4 unterstützt.

Ich habe für den Unifi-Zugriff aus fhem einen eigenen User „fhem“ mit „Read Only“-Berechtigung im Unifi Controller angelegt.

Der Zugriff von fhem war mit einer Zeile erledigt:

define myunifi Unifi 192.168.1.9 443 fhem geheim 30 default 4

Der Syntax lautet gemäß Perl Modul:

define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID> [<version>]]]

In der Commandref stehen auch die Details zur Nutzung des Moduls.

Die Standardwerte dafür sind:

  • interval = 30 Sekunden
  • siteID = default
  • version = 4

Ich habe dennoch alles explizit angegeben. Damit hoffe ich, dass in zukünftigen Versionen keine Problem auftauchen (zB. sobald es Version 5 gibt, etc.).

fhemunifi-siteidZuerst habe ich den angezeigten Namen vom Unifi-Controller meiner Site als siteID anzugeben. Damit habe ich  keine Werte bekommen. Nach kurzer Suche habe ich die Fehlermeldung im Log gefunden:

myunifi (Unifi_GetClients_Receive) - Failed! - state:'error' - msg:'api.err.NoSiteContext' - This error indicates that the <siteID> in your definition is wrong. Try to modify your definition with <sideID> = default.

Folgender Hinweis hilft: in der URL des Controller sieht man, mit welcher siteID man verbunden ist, auch wenn diese einen anderen Namen trägt, der im Controller angezeigt wird:

Es hat dann sofort funktioniert: im „Unsorted“-Bereich habe ich nun das Objekt myunifi und alle verbundenen Endgeräte:fhemunifi1Die Daten, die fhem vom Unifi Controller bezieht sind umfangreich und ermöglichen viele Anwendungen, auch außerhalb der Presence-Funktion. Hier die Details zu einem Client:unifi2

====================================== 
_id = 558XXXXXXXXXXXXXb85ae047 
_is_guest_by_uap = false 
_last_seen_by_uap = 1441082804 
_uptime_by_uap = 33149 
ap_mac = 24:a4:XX:XX:XX:c3 
assoc_time = 1441043174 
authorized = true 
bssid = 2e:a4:XX:XX:XX:c3 
bytes-r = 3 
ccq = 991 
channel = 7 
essid = MeineSSID 
first_seen = 1435052270 
hostname = android-bfeXXXXXXXXX9f0f 
idletime = 24 
ip = 192.168.XXX.103 
is_guest = false 
is_wired = false 
last_seen = 1441082804 
latest_assoc_time = 1441049655 
mac = 60:af:XX:XX:XX:e5 
name = Stefan Samsung XXXX
noise = -94 
note = 
noted = false 
oui = SamsungE 
powersave_enabled = true 
qos_policy_applied = true 
radio = ng 
radio_proto = ng 
roam_count = 2 
rssi = 40 
rx_bytes = 1339759 
rx_bytes-r = 3 
rx_packets = 6309 
rx_rate = 6000 
signal = -54 
site_id = 53ecXXXXXXXXXXXXXXX91e2a 
tx_bytes = 1905377 
tx_bytes-r = 0 
tx_packets = 5576 
tx_power = 30 
tx_rate = 72222 
uptime = 39630 
user_id = 55892XXXXXXXXXXXXX5ae047 
usergroup_id = 
======================================

neue & weitere Funktionen

Das Modul für Unifi ist neu im fhem. Es wird laufend weiterentwickelt, so wurde letzte Nacht wieder um Funktionen erweitert, zB:

  • einen Client disconnecten,
  • einen Access Point restarten
  • die „Locate“-Funktion eines APs ein- & ausschalten (blinken)
  • Alarme am Controller archivieren

Am besten behält man das fhem Changelog im Auge. Dort werden Änderungen & Erweiterungen protokolliert.

APRS, Unterwegs

erste Versuche mit dem GPS Repeater

3 Kommentare

Aufgrund der speziell gedämmten Scheiben im Auto funktionieren meine GPS-Anwendungen wie Navi oder APRS schon bei leichter Bewölkung nicht zuverlässig. Ich habe schon länger überlegt, mich mit einem GPS Verstärker zu beschäftigen.

Auf Ebay habe ich dann eine External Antenna Signal Repeater Amplifier GPS satellite Antenna for navigation um knapp € 25,- gefunden.

20150821_181113

Das Gerät besteht aus mehreren Teilen:

  • 20150821_181015einer externen Empfangs-Antenne, übrigens lt. Aufdruck für Glonass und GPS im Frequenzbereich 1575-1602 MHz geeignet,
  • einem USB-Stecker für die Stromversorgung,
  • einer Sendeantenne für GPS ist lt. Aufdruck für 1575.42 MHz ausgelegt
  • und einer SMA-„Kupplung“, damit das Kabel zB. zum Verlegen getrennt werden kann.

wpid-screenshot_2015-08-21-14-11-46.pngIch habe also bei mir zu Hause im Arbeitszimmer, in dem der GPS-Empfang bei geschlossenem Fenster auch fast unmöglich ist, einen ersten Test unternommen. Die Empfangsantenne habe ich auf den Fenstersims gelegt, das Fenster gekippt, um das durchgeführte Kabel nicht unnötig zu quetschen und den Sender am Tisch platziert. Bevor ich die USB-Verbindung hergestellt habe, habe ich mit der Android App „GPS Status & Toolbox“ getestet und keinen Fix zu einem Satellit erreicht.

wpid-screenshot_2015-08-21-14-16-13.pngNachdem ich den USB-Stecker angesteckt habe, hat man binnen Sekunden eine sanfte Verbesserung in der Empfangsleiste der Satelliten in der App gesehen. Aber die meisten waren immer noch zu schwach. Ich musste mit dem Gerät näher an die Sendeantenne kommen, ab ca. 20 cm wurden dann zahlreiche Satelliten grün angezeigt und es war binnen weniger Sekunden die Position bekannt und ein Fix auf 6/23 Satelliten. Das ist immer noch nicht viel, aber man muss vielleicht wissen, dass mein Fenster nur begrenzt Aussicht hat und der Ausschnitt am Himmel, in dem Satelliten gesehen werden, ist recht klein.

20150821_180959

20150821_181006Der Repeater scheint also wunderbar zu funktionieren, allerdings muss man sehr nahe zum Sender kommen. Für meine Anwendung ist das kein Problem, bei mehr als 50cm Abstand, zeigt der Sender keine Wirkung mehr.

Hier ein Foto mit technischen Daten zum Gerät:

gpsrep-specs

Update Februar 2021: mich hat Thomas OE1TRI angeschrieben – er hat ein anderes (vmtl. neueres?) Gerät probiert, mit dem er sehr zufrieden ist. Die Position ist sehr exakt und im Innenbereich hat er auch bei einer Distanz von 15m zum Sender keine Probleme. Das ist doch erheblich besser als meine Erfahrungen mit dem hier beschriebenen Gerät. Daher möchte ich euch den Link zum von ihm getesteten Gerät nicht vorenthalten: https://www.ebay.at/itm/GPS-Signal-Repeater-Amplifier-Transfer-25M-Antennen-Kit-fur-den-Innenbereich-L1/254094640578?hash=item3b293885c2:g:3v4AAOSwH-RcSps5 (GPS Signal Repeater Amplifier Transfer 25M Antennen-Kit für den Innenbereich L1)