Verschlüsselung der .env Datei

In modernen Anwendungen wie z.B. Laravel, werden häufig „.env“ Dateien verwendet, um Zugangsdaten für die Datenbanken, API-Token oder andere Zugangsschlüssel zu speichern (siehe https://dotenv.org/). Dies hat den Vorteil, dass diese nicht im Quellcode der Anwendung hinterlegt werden müssen und so an einer zentralen Stelle gespeichert werden. Außerdem kommen sie so nicht in die Versionskontrolle wo sie ggf. von Personen außerhalb des Projektes gelesen werden könnten.

Sobald ein neuer Wert in dieser Datei hinterlegt wird, muss dieser auch bei allen Entwickler im Team hinterlegt werden oder in die produktive Umgebung eingespielt werden. Gerade wenn es hierfür keinen richtigen Prozess gibt, wie die Zugangsdaten dann verteilt werden, könnte dies wieder unsicher übertragen werden. Vielleicht wird hier eine Rundmail geschrieben oder mit einer Message via Slack, Teams oder gar in WhatsApp verschickt. Und sollten sich die Werte auch nicht in Produktion automatisch oder per Deployment aktualisieren, dann muss hier auch immer händisch noch der richtige Wert hinterlegt werden.

Eine Lösung hierfür kommt von Dotenv selbst und bietet eine Synchronisierung. Doch wer Kosten sparen möchte oder eine Cloud Lösung nicht in Frage kommt, der steht wieder vor dem Ausgangsproblem.

Darum habe ich ein kleines Package gebaut, mit dem man die .env Datei sicher im Repository hinterlegen kann, ohne das es hier zu Bedenken der Sicherheit kommt. Mit dem Package lässt sich die lokale .env Datei sicher verschlüsseln und damit auch in das Repository einchecken. Andere Personen im Team können diese dann auschecken und dann wieder entschlüsseln. Das gleiche geht auch für die produktive Umgebung. So muss nur noch der geheime Schlüssel bekannt sein, welcher nur für ausgewählte Personen im Team bekannt ist.

Das Package findest du wie immer bei GitHub. Es befindet sich noch in der aller ersten Version: https://github.com/TobyMaxham/laravel-envcrypter

Sitealarm: Self hosted Checks

Wir haben ein wirklich cooles neues Feature in unsere Sitealarm App integriert. Es gibt nun die Möglichkeit, eigene Checks zu definieren und diese über unsere API abfragen zu lassen.

Sitealarm kann genutzt werden, um den Status deiner Website zu überprüfen, die SSL Zertifikate zu überwachen und deine regelmäßigen Jobs auf Ausführung zu beobachten. Doch was ist eigentlich mit Serverseitigen Prozessen, auf die Sitealarm keinen Zugriff hat. Wie kann z.B. der Status der Datenbanken oder ob noch genügend freier Disk Space vorhanden ist?

Unser neuer Monitor ruft regelmäßig einen bestimmten Endpunkt bei dir auf und prüft die Antwort deines Systems. Dabei muss kein Skript auf deinem Server von uns installiert werden und wir benötigen auch keinen Zugriff auf deinen Server. In der Rückmeldung von deinem System sind dann die einzelnen Services aufgeführt und haben einen entsprechenden Status. Mehr dazu findest du auch in unserer Dokumentation.

Die Prüfung deiner Services übernimmst du also selbst. Wir validieren dann das Ergebnis und informieren dich, sollte etwas nicht stimmen oder dein Endpunkt nicht erreichbar sein. Es gibt fünf verschiedene Status Typen: ok, warning, crashed, failed und skipped.

Je nach Status bzw. vorherigem Status senden wir dir dann eine entsprechende Mitteilung über den hinterlegten Notification Channel. So verpasst du nie wieder, wenn ein Service in deiner Infrastruktur nicht mehr ordnungsgemäß funktioniert.

I’m nächsten Schritt wollen wir ein Package entwickeln, welches du in deiner Anwendung hinterlegen kannst, damit diese Überwachung automatisch ausgeführt werden kann.

Wechsel zu MySQL wegen PHP MSSQL – Verbindungsproblem

In der Zhylon Cloud haben wir historisch einen MSSQL Server für die Abarbeitung der Jobs in einer Queue im Einsatz. Leider hatten wir in der Vergangenheit immer wieder Probleme beim Einsatz des SQL Servers von Microsoft. So auch der folgende Fehler, der einen Teil der Anwendung am vergangenen Wochenende lahm gelegt hat.

Nach einer Routinewartung hatten wir plötzlich Probleme, das die Anwendung sich mit dem Server Verbinden konnte. Wir haben hier, wie fast überall, Laravel 9 in der Standardkonfiguration im Einsatz und haben dann folgenden Fehler erhalten:

Fatal error: Cannot connect to server: 192.168.1.95\ZHYLONBD,3306 : SQLSTATE: 08001
code: 10054
message: [Microsoft][ODBC Driver 17 for SQL Server] TCP Provider: Error code 0x2746
SQLSTATE: 08001
code: 10054
message: [Microsoft][ODBC Driver 17 for SQL Server] Client unable to establish connection in DbConnector.php on line 110

Eine Lösung dafür haben wir schnell gefunden und wird von yitam auf GitHub im Repository vom microsoft/msphpsql beschrieben. Das Problem war wohl, das Versäumnis auf eine neuere Version des SQL Servers umzusteigen. Ein paar Tests mit Docker und dem SQL Server 2017 und 2019 waren erfolgreich und hatten keine Probleme. Allerdings hatten wir nicht geplant hier ein Upgrade auszuführen, da hiermit auch deutlich höher Kosten entstehen würden und wir sehr kritisch und auch unzufrieden mit dem SQL Server sind.

Wir haben uns daher kurzerhand dazu entschieden, die alte MSSQL Datenbank durch eine MySQL Datenbank zu ersetzen. Dies ging tatsächlich relativ schnell und es waren kaum Anpassungen notwendig. Ein paar Migrations mussten angepasst werden, da die Syntax nicht kompatibel war. Außerdem mussten wir für eine relativ alte Datenbank einmal alle Migrationen „rückwärts“ erstellen, da es hierfür keine Migrations gab. Wir haben hierfür das Package Xethron/migrations-generator verwendet, welches zwar nicht länger aktualisiert wird, es für diese einmalige Nutzung aber völlig ausreichend war.

Als Review zu dem Thema haben wir uns nun festgelegt, dass wir in den nächsten Monaten noch die ein oder andere ältere Struktur ablösen und modernisieren werden. Außerdem haben wir einen Prozess angestoßen, der zukünftig dafür sorgen soll, dass Updates und Upgrades zeitnah ausgeführt werden.

SSL Zertifikate mit Let’s Encrypt

Seit dem Frühjahr 2016 ist Let’s Encrypt aus der Beta Version raus. Viele Sponsoren haben ihre Verträge verlängert und durch eine einfache Implementierung findet es auch immer größer Verwendung.

Das Unternehmen hat sich zum Ziel gesetzt, das Web auf HTTPS umzustellen. Ungeschützte Seiten sollen dann Geschichte sein. Um das zu erreichen haben Sie bereits einen Meilenstein erreicht. Sie sind bereits eines der größten CA auf dem Markt. Zusammen mit den prominenten Sponsoren wie Google Chrome, Mozilla oder Ciso gilt Let’s Encrypt auch weiterhin als sehr vertrauenswürdig. Darum spricht hier auch nichts gegen den Produktiven Einsatz.

Let’s Encrypt. Kostenlos!

Was ich in den letzten Monaten auch beobachten konnte: Viele Hosting-Anbieter bieten zusätzlich zu den Standard Paketen noch einen kostenlosen Service um die SSL-Zertifikate von Let’s Encrypt anzubinden. Wenn man das so sieht wird klar, dass damit die Anzahl an unverschlüsselten Verbindungen tatsächlich abnehmen wird.

Doch warum muss man für andere Zertifikate etwas bezahlen? Nun das hat primär mit zwei Dingen zu tun. Zum einen wird Let’s Encrypt von einigen großen Sponsoren unterstützt. Somit rechnet sich das dann zumindest wieder finanziell. Zum anderen hat es dann doch noch etwas mit der Sicherheit zu tun. Es gibt mittlerweile Zertifikate (z.B. im Bankenumfeld) die eine hohe Verschlüsselung garantieren. Das diese dann nicht günstig oder gar kostenlos sind ist eigentlich klar. Doch auch Let’s Encrypt bietet ein hohes Maß an Verschlüsselung. Der Trend geht auf jeden Fall in die Richtung, das kostenlose Zertifikate angeboten werden. So gibt es diese z.B auch bei CloudFlare und StartSSL.

Ausblick

Für 2018 hat Let’s Encrypt bereits die lang ersehnten Wildcard Zertifikate angekündigt. Somit kann man für alle Subdomains noch einfacher die Zertifikate erstellen.

Ich selbst nutze mittlerweile nur noch die Zertifikate von CloudFlare da ich meine Domains schon darüber konfiguriert habe. Doch wer diese Möglichkeit nicht hat, für den ist Let’s Encrypt wirklich zu empfehlen.

In einem weiteren Beitrag werde ich zeigen, wie einfach die Implementierung zusammen mit der automatischen Verlängerung ist. Dies werde ich an einem Beispiel demonstrieren.

Ping: Zeitüberschreitung der Anforderung und Zielhost nicht erreichbar

Haben wir vermutlich alle schon einmal ausgeführt. Ping. Doch was ist Ping? Ping ist das Netzwerk Troubleshooting Tool Nummer 1. Ping sendet ICMP Pakete an ein IP fähiges Gerät. Meist in der Hoffnung, dass dieses Gerät auch antwortet. Aber was bedeutet „Zeitüberschreitung der Anforderung“ und wie unterscheidet es sich mit „Zielhost nicht erreichbar“?

Ich pinge einen Rechner in meinem Netzwerksegment.

Ping Ok
Ping Ok

Der Rechner antwortet auf das 32 Bytes große Paket in 50-55 ms und der TTL Wert ist 62 (Anzahl der max. Hops). Alles Ok soweit, das Gerät ist erreichbar.

ZEITÜBERSCHREITUNG DER ANFORDERUNG

So, jetzt wird es interessant: Ein Computer mit der IP 192.168.1.4 ist offensichtlich im Netzwerk nicht erreichbar. Meine IP ist 192.168.1.54/24. Die zu testende IP ist 192.168.1.4/24. Das bedeutet, dass sich beide Geräte im gleichen Subnetz und in der gleichen Broadcast Domäne befinden.

Ping Zeitüberschreitung
Ping Zeitüberschreitung

Was kann man nun daraus schließen? Viele gehen jetzt davon aus, dass das Gerät nicht erreichbar ist, sprich „kaputt“, ausgeschalten oder nicht mehr im Netzwerk ist.

Zeitüberschreitung der Anforderung im lokalen Subnetz bedeutet, dass das Gerät keine ICMP Pakete in einer gewissen Zeitspanne sendet. Sonst nichts. Es kann mithilfe dieser Information auf nichts anderes geschlossen werden, als auf die Tatsache, dass das Gerät nicht auf einen Ping antwortet.

Ich erkenne mit arp -a, dass die MAC Adresse mithilfe ARP ermittelt wurde. Das heißt zwar nicht zwangsläufig, dass der Computer online ist (ARP Cache), aber ich habe vorher mit arp -d den ARP Cache geleert.

ARP
ARP

Meist lässt die Windows Firewall ICMP eingehend nicht zu, d.h. das Gerät ist funktionsfähig. Hier die Ansicht in wf.msc:

Firewall Einstellung
Firewall Einstellung

Beim Aktivieren der IPv4 Regeln antwortet das Gerät.

ZIELHOST NICHT ERREICHBAR

Ich bekomme als Antwort auf einen Ping an einen Computer im lokalen Subnetz die Information: Zielhost nicht erreichbar.

Ping Nicht erreichbar
Ping Nicht erreichbar

Was kann ich daraus schließen? Hier sieht die Sache anders aus. Meist ist der Computer nicht online und auch der ARP Cache zeigt keine MAC Adresse des Zielcomputers. Das bedeutet, dass auch der ARP Request fehlgeschlagen ist. Es kann in den meisten Fällen davon ausgegangen werden, dass der Computer tatsächlich offline ist.