Archive: Month 10, Year 2014

PushOver.net: Scriptgesteuerte Push-Notifications für iOS und Android

30.10.2014 yahe administration code legacy linux

Letztens durfte ich einen relativ langwierigen Download via SFTP vornehmen. Da ich allerdings nicht vor dem Rechner sitzen bleiben und auf die Beendigung warten wollte, bin ich immer wieder an den PC gegangen, um den aktuellen Status zu sehen. Dabei kam mir die Idee, dass es doch toll wäre, einen Dienst zu haben, den man per einfacher REST-API ansprechen könnte, um einen Status mitzuteilen. Der Dienst könnte es dann ermöglichen, diesen Status z.B. über einen Browser abzurufen. @servicecase18 hatte jedoch einen viel besseren Tipp: Er verwendet für soetwas den Dienst PushOver.net, der im Grunde das macht, was ich möchte, nur besser. Sie bieten ebenfalls eine einfache REST-API an, versenden den Status dann jedoch als Push-Notification an ihre iOS- und Android-App. So hat man den Status direkt auf dem Smartphone.

Wenn man sich registriert, erhält der neue Account einen "User Key". Nachrichten, die an den User Key geschickt werden, landen auf jedem Gerät, bei dem man mit dem zugehörigen Account in der App eingeloggt ist. Zudem kann man mit seinem Account auch "Applications" registrieren, wobei jede Application ein "Application Token" erhält. Um nun eine Push-Notification zu senden, übergibt man der REST-API mindestens den User Key, den Application Token und die eigentliche Nachricht. Optional gibt es noch weitere Werte, die man setzen kann.

PushOver-App PushOver-App

Das ganze ist so praktisch, dass im Grunde jeder seiner Anwendungen eine Anbindung an den Dienst spendieren möchte.

Push-Notifications Push-Notifications

Da ich allerdings nicht die Absicht habe, allen Skripten ein eigenes Application Token zu besorgen (obwohl das möglich wäre), habe ich mir etwas anderes überlegt. Ich hole mir pro Server nur ein Application Token und verwende ein Skript, das sich zentral um das Versenden der Push Notifications kümmert. Das hat den zusätzlichen Vorteil, dass nicht jedes kleine Skript wissen muss, wie der Versand funktioniert. Stattdessen gibt es einen Ordner, in das jedes Skript einfach Dateien ablegen kann. Der Name der Datei ist der Titel des Push Notification und der Inhalt der Datei ist auch gleichzeitig der Inhalt der Push Notification. Um das Versandskript Pushinfo nicht als Root laufen lassen zu müssen, habe ich mich dazu entschieden, dass versandte Nachrichten nicht gelöscht werden. Stattdessen wird in einer Statusdatei das letzte Bearbeitungsdatum der Dateien notiert. Sollte sich die Datei ändern (und damit das entsprechende Dateidatum), so wird der Inhalt erneut versendet. Das ganze sollte man nun natürlich regelmäßig ausführen lassen, z.B. per Cron.


PHP Scripte: Chrooten und Privileges droppen

28.10.2014 yahe code legacy linux security

Derzeit bin ich dabei, ein Synchronisationsscript zu schreiben, das, je nach synchronisiertem Ordner mit unterschiedlichsten Dateirechten arbeiten können. Die Synchronisation selbst habe ich in PHP geschrieben. Allerdings war es mir zu heikel, die Synchronisation durchgehend als Root auszuführen. Deshalb habe ich mir mal angesehen, ob PHP in der Lage ist, innerhalb eines Skripts Privilegien zu droppen und sich eventuell sogar Chrooten zu lassen. Und in der Tat, beides ist möglich!

Da ich diese Fähigkeit für sehr sinnvoll halte, habe ich mir das ganze direkt in der kleinen Bibliothek unchroot zusammen gesammelt. Diese enthält die zwei wichtigen Funktionen "force_chroot()" und "force_unroot()". Sollte ein entsprechender Aufruf fehlschlagen, wird das gesamte Skript direkt mit einer Fehlermeldung beendet. Lieber nichts tun, als mit zu vielen Rechten unterwegs zu sein.


Prüfen, ob ein Prozess gechrootet ist

23.10.2014 yahe administration legacy linux security

Ich bin derzeit dabei, Dovecot und Postfix einzurichten und sehe mir dabei auch an, wie die einzelnen Teile ordentlich gechrootet werden können. Beim Chrooten läuft man jedoch immer wieder in das Problem, nicht genau zu wissen, ob das, was man da gerade fabriziert hat, wirklich funktioniert. Wie ich nun lernen durfte, gibt es ein Hilfsmittel, mit denen man die Funktion des Chrootings kontrollieren kann.

Gemeint ist der "/proc/"-Ordner im System. Dort wird für alle laufenden Prozesse ein Unterordner angelegt, der entsprechend der zugehörigen Prozess-ID benannt ist. Dieser Ordner ist durchaus interessant, so entspricht beispielsweise der Besitzer und die Gruppe des Prozessordners der UID und der GID des Prozesses.

In dem Ordner befinden sich drei Symlinks, "cwd", "exe" und "root". Ersterer zeigt auf das aktuelle Arbeitsverzeichnis des Prozesses, zweiterer zeigt auf den Pfad der ausgeführten Datei und letzerer verweist auf das Verzeichnis, in dem der Prozess gechrootet wurde. Es gibt auch ein paar spannende Textdateien, z.B. "cmdline", "environ" und "maps", wobei erstere die Aufrufparameter des Prozesses enthält, zweitere die Umgebungsvariablen, mit denen der Prozess arbeitet und letztere sämtliche Libraries, die vom Prozess angebunden sind. Mit den passenden Rechten kann man sich sogar im "fd/"-Unterordner umsehen. Dort wird auf alle Dateien verwiesen, die von dem Prozess verwendet werden.

Wenn man nun also wissen will, ob das eingerichtete Chrooting wirklich funktioniert, kann man sich die notwendige Prozess-ID besorgen und sich anschließend mit folgendem Befehl das Chroot-Verzeichnis anzeigen lassen:

sudo ls -la /proc/<Prozess-ID>/root

Einfache Firewall-Konfiguration mit UFW

06.10.2014 yahe administration legacy linux security

Lange Zeit hatte ich mich vor dem Aktivieren einer Firewall auf meinen Servern gesträubt, aus Angst, mich selbst von den remote administrierten Systemen auszusperren. Geändert habe ich meine Meinung nun durch Finden des Verwaltungstools UFW. Dabei handelt es sich um die Abkürzung für "Uncomplicated Firewall" und der Name ist Programm, denn das Tool vereinfacht die Verwaltung von iptables-Tables regeln und dürfte für einfache Fälle jedoch mehr als ausreichen.

Um sie zu verwenden, muss sie natürlich zuerst installiert werden:

sudo apt-get install ufw

Direkt nach dem Installieren sind keine Regeln aktiviert, sodass man UFW in Ruhe konfigurieren kann. Als erstes sollte man definieren, was gilt, wenn keine weiterführenden Regeln definiert sind. Dabei kann man zwischen eingehenden und ausgehenden Verbindungen unterscheiden. Für den Anfang kann man z.B. alle eingehenden Verbindungen verbieten und alle ausgehenden Verbindungen erlauben:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Als nächstes definiert man dann die einzelnen Ports, die freigegeben werden sollen. Hier müsst ihr aufpassen. Solltet ihr ein System haben, das ihr remote administrieren könnt, solltet ihr sicher gehen, dass auch der Port freigegeben wird, über den ihr die Administration erreicht (z.B. Port 22 für SSH):

sudo ufw allow in 22
sudo ufw allow in 80
sudo ufw allow in 443

Wenn ihr alle notwendigen Ports freigegeben habt, könnt ihr die Regeln aktivieren:

sudo ufw enable

Das war's auch schon! Wenn ihr euch nicht mehr sicher sein solltet, was ihr genau konfiguriert habt, könnt ihr wie folgt einen Überblick über die definierten Einstellungen verschaffen:

sudo ufw status verbose

Die freigegeben Ports sieht man leider erst, wenn UFW auch tatsächlich aktiviert wurden. Will man schon vorher mal einen Blick Überblick bekommen, dann findet man die iptables-Regeln in den Dateien "/lib/ufw/user.rules" für IPv4 und "/lib/ufw/user6.rules" für IPv6.

Mehr Informationen über die Syntax erhaltet ihr in der Ubuntu Community.


Search

Links

RSS feed

Categories

administration (40)
arduino (12)
calcpw (2)
code (33)
hardware (16)
java (2)
legacy (113)
linux (27)
publicity (6)
review (2)
security (58)
thoughts (21)
windows (17)
wordpress (19)