Alle Beiträge von Malte

Nextcloud: Der HTTP-Header „X-Frame-Options“ ist nicht als „SAMEORIGIN“ konfiguriert (obwohl er konfiguriert ist)

Linux, ,

Eine interessante Anekdote aus meiner Arbeit mit Nextcloud. Im Backend wird ein „Sicherheits- und Konfigurationscheck“ angeboten, der einige Tipps und Empfehlungen für die Nextcloud-Serverinstanz vorschlägt.

Nachdem ich alle aufgeführten Aufgaben erledigt hatte, blieb eine bestehen:

Der HTTP-Header „X-Frame-Options“ ist nicht als „SAMEORIGIN“ konfiguriert. Dies stellt ein potenzielles Sicherheits- oder Datenschutzrisiko dar, und wir empfehlen, diese Einstellung zu ändern.

NEXTCLOUD ADMIN BACKEND -> OVERVIEW

Da dies eine einfache Überprüfung ist, habe ich die Entwicklerkonsole meines Browsers geöffnet und überprüft, ob der Header gesetzt war. Und das war er. Seltsam? Zu diesem Zeitpunkt war ich mir ziemlich sicher, dass etwas mit der Erkennung dieses Headers nicht stimmte, aber ich konnte nicht sofort erkennen wo und wie genau.

Nachdem ich im Internet recherchiert und mindestens eine Stunde lang damit herumgespielt hatte, entschied ich mich, den Sicherheitsscanner scan.nextcloud.com zu verwenden, um sicherzustellen, dass die Warnung auch dort angezeigt wird. Jetzt kommt der lustige Teil: Der Scanner zeigte die Warnung ebenfalls an, allerdings mit zwischengespeicherten Daten vom letzten Jahr. Nach einem erneuten Scan und einem A+ auf dem Scanresultat, verschwand die Warnung auch im Nextcloud-Backend.

Wahrscheinlich stützt sich die Nextcloud-Backend-Prüfung auf denselben Datensatz, den scan.nextcloud.com verwendet, und indem ich die Sicherheitsprüfung auf scan.nextcloud.com manuell wiederholte, verschwand die Warnung. Es ist nicht nötig, an irgendwelchen Webserver-Konfigurationen herumzufummeln, da Nextcloud in allen neueren Versionen den X-Frame-Options-Header von sich aus korrekt setzt.

Segfaults in imapproxy durch falsche/fehlende Konfiguration

Linux

In den letzten Tagen hatte ich ein bisschen mit imapproxy zu tun. Im Original von den SquirrelMail-Entwicklern entwickelt, stellt imapproxy eine Art Proxy für das Handling von IMAP-Verbindungen zum jeweiligen IMAP-Backend bereit. So muss die Webanwendung, welche nicht in der Lage ist, Verbindungen lange geöffnet zu halten, nicht immer wieder Netzwerkumläufe anstellen, die je nach Situation viel Zeit kosten können. Eine Art persistente Verbindung für IMAP.

imapproxy ist genau so alte und zurückgelassene Software wie SquirrelMail selbst. Das Interface alt, die Codebase veraltet, letzte Aktualisierung der Gnade Ende 2021 um PHP 8-Kompatibilität herzustellen.

Derzeit erhält man imapproxy noch in den Debian- und Ubuntu-Repositories und der Code ist unter salsa.debian.org zu erhalten. Die offizielle imapproxy.org-Seite ist nicht mehr erreichbar.

Bei der Erstellung einer Minimalkonfiguration ist mir direkt aufgefallen, dass es für die Konfiguration praktisch kein Errorhandling gibt. Das heißt, dass bei fehlenden, nicht-optionalen Optionen imapproxy generell einfach mit SIGSEGV aussteigt. Debugging-Tool der Wahl ist hierbei dann strace.

Daraufhin erarbeitete ich mir eine passende Minimalkonfiguration, ein Teilnehmer der Dovecot-Mailingliste empfahl ebenfalls eine solche:

Segfaults in imapproxy durch falsche/fehlende Konfiguration weiterlesen →

Funktionierende Lösung zur Installation von Ubuntu 22.04 über iPXE mit cloud-init, subiquity, auto-install, curtin

Linux

Ich entschuldige mich vorab für den folgenden polemischen Beitrag. Aber was Canonical da abgeliefert hat ist ehrlichgesagt eine einzige Katastrophe. Seit 22.04 gibt es den Legacy-Debian-Installer nicht mehr, welcher bei 20.04 noch verfügbar war. Möchte man sauber Hosts über PXE komissionieren, ist bei Ubuntu nun cloud-init, subiquity, auto-install oder wie auch immer sie den Unsinn nennen, angesagt. Hauptsache die Buzzword-Quote stimmt, Funktionalität ist nunmehr nebensächlich. „Cloud-init is the industry standard multi-distribution method for cross-platform cloud instance initialization“…

Die neue YAML-Syntax sollte Verbesserungen bringen, aber das Chaos ist dadurch nur noch größer. root-User lassen sich im „identity“ Dictionary nicht anlegen, automatische Updates im Installationsprozess lassen sich nur mit einem Hack abstellen, die Referenzierung auf user-data und user-meta Files ist völlig undurchdacht, die YAML-Files erfordern nicht-YAML-konforme Syntax um zu funktionieren (wer hat sich die bescheuerte Erfordernis von „#cloud-config“ in der ersten Zeile der user-data YAML ausgedacht?), der Installationsprozess wird ewig in die Länge gezogen, ISO-Images sind zusätzlich zum Kernel und der Initramdisk nun auch bei Installation nötig und als wäre das nicht genug, werden diese in der Standardkonfiguration auch noch doppelt geladen (2×1,3GB) sodass eine Installation mindestens 3GB RAM erfordert, mit Hack dann 2GB. Schöne neue Welt.

Funktionierende Lösung zur Installation von Ubuntu 22.04 über iPXE mit cloud-init, subiquity, auto-install, curtin weiterlesen →

WordPress-Seiten im Nginx + PHP-FPM Stack mit wenig Aufwand effizient cachen

Linux, WordPress, , ,

Die Zeiten sind doppelplusungut, um kein Blatt vor den Mund zu nehmen, möchte ich sagen, sie sind beschissen. Die aktuellen Energiekosten sind eine Katastrophe und dazu zählt letztlich auch der Strompreis. Ein Grund mehr im Webserver- und IT-Bereich auf Sparsamkeit zu achten, denn letztlich kommt ihr zwar nicht unmittelbar für VPS-, Dedicated- oder Webhosting auf, aber euer ISP schon – und der wird bei entsprechenden Ausgaben dann auch die Einnahmen steigern müssen (früher oder später).

Zudem erlaubt effizientes Caching trotz bequemer Webinterfaces bei Webanwendungen wie WordPress eine gute Seitenperformance, wenn man nicht einen von 1000 mittelprächtig entwickelten und gewarteten statischen Seitengeneratoren nutzen möchte.

Schauen zu uns zunächst mal an, was unser Ziel ist:

WordPress-Seiten im Nginx + PHP-FPM Stack mit wenig Aufwand effizient cachen weiterlesen →

Hetzner Storage Box Sub-Account via sshfs über Port 23 auf Linux-System mounten

Allgemein

Leider macht Hetzner keine Anstalten, diese Information in Ihre Dokumentation aufzunehmen. Möchte man seine Hetzner Storage Box via sshfs mounten, so ist zwingend dem Pfad beim Mount-Vorgang ein /home voranzustellen.

Systemd-Unit-Beispiel:

[Unit]
Description=Hetzner Storage Box sshfs mount
Requires=network-online.target
After=network-online.service

[Install]
WantedBy=multi-user.target

[Mount]
What=u123456-sub1@u123456-sub1.your-storagebox.de:/home
Where=/mnt
Type=sshfs
Options=_netdev,allow_other,x-systemd.automount,IdentityFile=/home/user/.ssh/id_rsa,reconnect,uid=33,gid=33,default_permissions,ssh_command=ssh -4 -p 23

Im vorgenannten Beispiel werden so der Dateieigner mit der UID 33 und GID 33 gesetzt, ssh mittels IPv4 forciert und der Port 23 spezifiziert. Die Daten zur Authentifikation liegen im unter „IdentityFile“ angegeben Pfad.

Im Beispiel wird das Wurzelverzeichnis des Sub-Accounts der Storage Box entsprechend nach /mnt gemountet. Möchte man Unterverzeichnisse mounten, so ist /home/unterverzeichnis zu verwenden.

SSH reverse tunneling / Rückwärtstunnel einrichten

Allgemein, , , , ,

Kürzlich probierte ich für eine Webseite, die eigentlich bei einem (mittlerweile) relativ guten Webhoster lag, ein sogenanntes Reverse-Proxying mit SSL-Offloading einzurichten. Leider schlug der Versuch nach einiger Zeit fehl, da die Firewall des Webhosters die gesammelten und dauerhaften Requests seitens des Reverse-Proxy bemerkte und sperrte.

Es war also klar, dass die Seite in jedem Fall migriert werden müsse, um einen vernünftigen Betrieb und SSL mit LetsEncrypt (das ist der Punkt, an dem es beim besagten Webhoster leider auch in 2021 immernoch hapert) zu gewährleisten.

SSH reverse tunneling / Rückwärtstunnel einrichten weiterlesen →