Kategorie: Proxer

In diesem Sommer haben sich ein zwei Probleme auf Proxer angehäuft:

• Der Speicher vom Datenbank-Server ist voll
• Es gibt eine neue Debian-Version

Aus diesem Grund habe ich beschlossen, neue Server zu bestellen und mal eine vollständige Neuinstallation der zwei Hauptserver durchzuführen. Ich habe mich für den folgenden Server für Proxer entschieden:

Fujitsu PRIMERGY RX2510 M2 1U Rack
2x Intel Xeon E5-2620v4 2.4GHz
32GB ECC DDR4 RAM
Drive 1 :240GB SSD
Drive 2 :1TB HDD
Drive 3: 1TB HDD

Auf der SSD läuft das Betriebssystem, die 2 HDDs sind in einem Raid 1-Verbund (Hardware) und dienen dazu, regelmäßig die Backups zwischenzuspeichern, aber auch um größere Daten zu lagern, die immer wieder mal auftreten.

Welche Software kommt bei diesen Proxer-Servern ins Spiel?

• nginx + php: Für den Webserver
• htop, iftop, vnstat, screen: kleinere Tools
• rsync: Zum Synchronisieren von Daten mit dem Backup-Server
• git: Versionsverwaltung
• munin-node: Monitoring
• mysql-server: Für die Datenbank.
• gd3: Bildverarbeitung.
• zip, unzip: (Ent-)Packen von Zip-Dateien.

Um keine Angriffsfläche zu bieten, ist es von Nöten, dass man den Server möglichst minimal belässt. Die oben genannten Pakete inklusive der bereits bei Debian 9 enthaltenen Pakete (und abhängige) reichen für Proxer vollkommen aus. Alles weitere findet auf der Webserver-Anwendungsebene statt, die im Grunde durch das Deaktivieren vieler PHP-Funktionen wie eine Sandbox ist. Meine Techniker-Kollegen beschweren sich deswegen, weil ich für Git beispielsweise aus diesem Grund keine Web-Oberfläche zur Verfügung stellen kann, mit der sie bei Änderungen einfach git-pull machen können 😀 Die Sicherheit wiegt für mich jedoch an dieser Stelle mehr als der Nutzen einer PHP-Funktion, die Systemfunktionen ausführen kann.

Durch den Wechsel auf Debian 9 (Stretch) kamen ein paar Änderungen. Seit heute nutzt Proxer nicht mehr Mysql, sondern MariaDB. Es sollte keine große Änderung darstellen, ich bin gespannt, wie sich der Wechsel auf die Performance auswirken wird.

Am Meisten Zeit nimmt das Einspielen des Datenbank-Dumpes ein. Dies ist 35GB groß und nimmt eingespielt unter Mysql um die 100GB an Speicherplatz ein (wegen den ganzen Indexen usw). Es gibt hier durchaus viel Freiraum für Verbesserungen, doch ich bekomme es noch nicht so richtig auf die Reihe aufgrund der großen Datenbank-Größe. Demnächst werde ich mal Optimierungsarbeiten daran durchführen.

Sonst ist es das gleiche Spiel: Konfigurationen prüfen, und in dem neuen Server einbauen. Es gibt bei neuen Betriebssystem-Versionen oft Änderungen an Einstellungen. Hier müssen ehemalige Änderungen nachgeschlagen werden. Gibt es eine Änderung des Variablennamen? Gibt es die Variable überhaupt? Gabs diesbezüglich intern Änderungen?

Alles in allem macht mir jeder Serverumzug sehr viel Spaß. Ich lerne mit der Zeit immer neues, und ich habe hier die Möglichkeit dieses Wissen sauber einzubauen.

„Es könnte der schlechteste Code sein, den ich jemals gesehen habe“

Puuuh… Gut dass sie den Proxer Code noch nicht gesehen haben 😀

Quelle des Zitats: https://www.golem.de/news/tizen-betriebssystem-koennte-der-schlechteste-code-sein-den-ich-je-gesehen-habe-1704-127133.html

Am letzten Wochenende habe ich mich mit der Zwei-Faktor-Authentifizierung von Proxer beschäftigt. Dieses Wort ist jedes Mal soooo anstrengend zu schreiben. Daher kürze ich es ab und nenne es nur noch 2FA.

Am Freitag wurde öffentlich, dass Cloudflare einen Softwarefehler hatte, und dieser dafür gesorgt hat, dass durch ein Speicherleck viele persönliche Daten und Passwörter geleaket wurden.

Ich war da relativ locker. Passiert halt, lässt sich nicht vermeiden. Und da ich mein Passwort auf Proxer ohnehin regelmäßig ändere und Zufallspasswörter nutze, war die Gefahr relativ niedrig für mich. Jedoch habe ich am nächsten Tag eine ganze Menge Mitteilungen bekommen. E-Mails, PNs und Skype-Nachrichten über diesen Fall. Auch kamen Supportanfragen im Forum. Nicht jeder hat so eine sichere Passwortpolicy wie ich. Aus diesem Grund habe ich beschlossen im Rahmen dieses Falles die 2FA für Proxer zu priorisieren. Ich war auch zwei ganze Tage da dran, und habe versucht zu entschlüsseln, wie die 2FA im Joomla-Core gelöst ist. Darauf aufbauend habe ich das Ganze dann auf Proxer implementiert, sodass sie mit Joomla kompatibel ist. Ich denke, dass ich mit dieser Konsequenz ausreichend auf die Sorgen eingegangen bin. Wer 2FA nutzt, wird in Zukunft sicher sein.

Es gab jedoch ein kleines Problem: Für die 2FA wird ein weiteres Feld für den Geheimschlüssel benötigt. Wie ich Nutzer so kenne, werden seeeeehr viele verwirrt sein, wenn neben Benutzername und Passwort ein drittes Feld erscheint. Das heißt, dass das dritte Feld nur dann erscheinen darf, wenn 2FA bei dem Benutzer aktiv ist, der sich gerade einloggt. Das war jedoch mit der altem alten Login-Formular nicht möglich. Dieses gibt im Fehlerfalle keinerlei Nachrichten zurück, und ist wirklich stupide einfach programmiert. Aus diesem Grund musste das ganze Login-Feld umgebaut werden. Das klingt leicht, aber war es tatsächlich nicht. Wie bei der 2FA auch, habe ich auf Joomla-Core aufbauend die ganze Login-Routine neu entwickelt. Ich bin die Joomla-Core abläufe unzählige Male durchgegangen, um zu verstehen, wie Joomla die Login-Routine macht. Es war verdammt interessant, und im Großen und Ganzen ist das sehr schön gelöst. War auf jeden Fall ein sehr guter Einblick.

Das neue Login-Formular gibt Fehlermeldungen aus, falls beispielsweise Benutzername/Passwort falsch sind. Es aktiviert auch das dritte Feld, falls 2FA aktiv ist. Ich war endlich fertig! Nun kam das nächste Problem. Mir ist dann aufgefallen, dass Logindaten auf der nicht-SSL-Seite ungeschützt an den Server weitergeleitet werden. Um dem zu entgehen, habe ich erst den naiven Ansatz probiert: Einfach den AJAX-Link angepasst und SSL erzwungen. Wie nicht anders zu erwarten funktioniert das nicht. Es kommt die folgende Meldung:

Quellübergreifende (Cross-Origin) Anfrage blockiert: Die Gleiche-Quelle-Regel verbietet das Lesen der externen Ressource auf https://proxer.me/. (Grund: CORS-Kopfzeile ‚Access-Control-Allow-Origin‘ fehlt).

Nun musste eine Lösung dafür her! Als erstes habe ich mich an Jsonp rangewagt. Das wurde auch auf Stackoverflow als eine mögliche Lösung empfohlen. Erstmal die Json-Schnittstellen überarbeiten, sodass sie auch Jsonp fähig sind. Ich hatte das bisher nie gebraucht. Das ist eine erstaunlich nützliche Technik ist mir aufgefallen.

Nachdem das fertig war, hats immer noch nicht funktioniert. Die Login-Daten wurden nicht an den Server übermittelt. Sie Browserkonsole  gab die Antwort: Jsonp unterstützt keine POST-Parameter. Ihr könnt euch vorstellen wie verärgert ich in dem Moment nach Stundenlangem friemeln war xD Dann hat mir ein Teammember CORS empfohlen. Damit kann man serverseitig Cross-Origin-Anfragen whitelisten. Damit war das Problem am Ende dann auch mit einfachen json-Anfragen gelöst. Login-Daten auf der nicht-SSL Seite wurden nun auch verschlüsselt an den Server übertragen. Ich war damit sehr glücklich 🙂 Ich weiß, schlussendlich war der Ganze Aufwand meiner eigenen Dummheit zu verdanken. Ich muss noch so viel lernen… Es war aber eine wundervolle Erfahrung. Ich habe mich damit in 2FA (Google Authenticate), Jsonp, CORS und Joomla-Authentifizierungs-Routinen eingearbeitet.

Fazit: Es gibt seit gestern die 2FA auf Proxer. Wer sich dies einrichtet, ist auch bei zukünftigen Passwort-Leaks geschützt. Einrichten kann man sich das unter „Profil bearbeiten“. Da ein paar Abhängigkeiten für die Umsetzung gebunden waren, habe ich ganze zwei Tage für diese Umsetzung benötigt.

Im Laufe der Woche wird die Ankündigung auf Proxer veröffentlicht. Ich bearbeite hier den Link ein, sobald dieser öffentlich ist. Edit: Hier ist die Ankündigung.