Backup-Shellscript für diesen Webserver

Vor einem Monat fiel diese Seite ja einem WordPress Redirect Hack zum Opfer. Ein verwendbares Backup war gut zwei Jahre alt, was insofern für mich gut war, dass ich der Manipulation des Blogs nachgegangen bin und selber wieder korrigieren konnte. Hätte ich ein aktuelles Backup gehabt, dann hätte ich vermutlich recht schnell den Restore durchgeführt und wäre dann wieder auch wieder in dasselbe Problem gerannt. Aber, es ist trotzdem wichtig, dass man regelmäßig Backups erstellt. Da durch die Piwigo-Fotogalerie die ich als Unterverzeichnis vom Blog angelegt habe, das gesamte Verzeichnis nun sehr viel Speicherplatz benötigt, komme ich mit der kostenlos-Variante vom WordPress-Plugin Duplicator nicht mehr weiter. – Mal ganz davon abgesehen, dass ich den Einsatz von Plugins doch von Anfang an etwas kritisch gesehen habe und mit dem Hack diese Haltung eher noch verstärkt hat.

Da ich mir für dieses Blog bei meinem Hoster nun keinen reinen Webspace, sondern eine virtuelle Computerinstanz mit einem Linux gebucht habe, stehen mir dadurch auch alle üblichen Kommandozeilenwerkzeuge und Programme zur Verfügung, mit denen ich mir mein eigenes Backup-Programm in Form eines kleinen Shellscripts basteln kann. Das ist dann spätestens jetzt die Gelegenheit sie auch mal zu nutzen. Und so habe ich inzwischen einen ersten funktionierten Entwurf im chaos.expert GitLab veröffentlicht, in der Hoffnung, dass ich es schaffe, mit der Zeit etwas auszubauen und zu optimieren. – Auf jedem Fall wird dieses Shellscript mittels einen Cron-Jobs einmal wöchentlich aufgerufen und es sollen immer die letzten vier Archive für einen Restore auf der Instance lokal gespeichert bleiben. Sprich: Kommt ein neues Archiv hinzu – es muss dann schon wenigstens das „Fünfte“ sein, wird dann das älteste Archiv wieder gelöscht.

Für den Fall dass die komplette virtuelle Linux-Server-Instanz ohne Ersatz offline geht und bei meinem Hoster gekündigt wird, muss ich mir noch ein Konzept für die dezentrale Speicherung der Archive überlegen, falls ich zu einem späteren Zeitpunkt den Webserver mit den alten Inhalten wieder online bringen möchte. Es soll also spannend bleiben!

Links:

Fixing WordPress Redirect Hack

Letzte Woche hatte es auch mich und meinem Server erwischt, dass dieser durch eine Sicherheitslücke mit Schadcode in Form eines kleinen Skripts kompromittiert wurde. Durch diesen „WordPress Redirection Hack“ wird im Allgemeinen ein Webbrowser beim Aufrufen (m)einer URL dann dazu genötigt, auf eine fremde URL zu verweisen, wo für den PC des Benutzers die eigentliche Malware zum Download bereitsteht, die den User durch weitere Angriffsformen schädigt. Es gibt da mehrere Möglichkeiten, wo so ein Skript für die Weiterleitungen versteckt werden kann. Bei mir war es die Variante, bei der ein Skript durch eine SQL-Injektion in die WordPress-Datenbank eingeschleust wurde. Konkret wurde die Entwicklung und Pflege des von mir eingesetzten WordPress-Plugins für die DSGVO-konforme Cookie-Information eingestellt. Dadurch blieb wohl mindestens eine Sicherheitslücke im Programmcode des Plugins, mit der die SQL-Injektion durchgeführt werden konnte. Bei meiner Recherche im Internet, den kompromittierenden Code im WordPress aufzuspüren, bin ich direkt auf einen guten Ansatz gestoßen, wie man bei der SQL-Injektion die fremden Schadskripte auch wieder loswird.

  • Am besten eignet sich hierfür der Mozilla Firefox Webbrowser. In einem neuen, leeren Tab trägt man in der Adressleiste view-source:, gefolgt von der zu untersuchenden Website ein. In meinem Fall also view-source:http://sommteck.net. Dabei holt sich der Firefox den Quellcode der Seite, tut ihn aber nicht interpretieren und ausführen, sondern nur darstellen.
Volltextsuche HTML-Sourcecode
Volltextsuche im HTML-Sourcecode
  • Jetzt muss man Ausschau halten und die eingeschleusten Skripte mit den fremden URLs – auf die für die Angreifer weiter geleitet werden soll – finden. Hilfreich ist, vielleicht erstmal eine Volltextsuche über das gesamte HTML-Dokument mit dem Stichwort script durchzuführen. Mit 45 Treffern waren das gar nicht mal so viele Ergebnisse wie ich erwartet hätte. Jetzt gilt es zu prüfen, ob die mit dem HTML-Tag script versehenen URLs plausibel sind. Schon nach rund der Hälfte der Tags hatte ich auch schon eine URL auf die verwiesen wurde, die als Sub-Domain einen „store“ zugewiesen bekommen hat und als Top-Level-Domain .ga besaß. Die Top-Level-Domain .ga steht für das afrikanische Land Gabun. Ich hatte in meinem Fall zwar im Hinterkopf, dass das DSGVO-Plugin gegen Bezahlung erst noch weitere Funktionen angeboten hatte, aber auf der Homepage, beziehungsweise im PHP-Quellcode einer Standard-WordPress-Installation ist eine solche Domain und URL als unseriös zu betrachten. Das vollständige Skript, in das die URL eingepackt ist, sollte man sich in die Zwischenablage kopieren. Aber hier ist noch anzumerken, dass die Kommentierungen vor und nach den HTML-Tags schon verraten haben, wie sie in den Quellcode gelangt sind. In meinem Fall ist es das WordPress-Plugin für das Cookie-Banner gewesen.
  • Im nächsten Schritt wird mit dem in die Zwischenablage gespeichertem Skript eine Volltextsuche über die gesamte Datenbank durchgeführt. Am besten geht das zum Beispiel mit der PhpMyAdmin Web-Oberfläche. Wird hier nun als Ergebnis mindestens ein Treffer aufgezeigt, dann sollte klar sein, dass der Redirection Hack mindestens über eine SQL-Injektion in die Webseite platziert wurde.
Volltextsuche SQL-Datenbank
Aufspüren von fremd eingeschleusten Code
  • Jetzt kann man in den oder die einzelnen Datenbankeinträge gehen und das Script entfernen. Danach konnte vom Webbrowser die HTML-Seite wieder ganz normal interpretiert und dargestellt werden.
Eingeschleustes Skript entfernen
Eingeschleustes Skript aus einem Datenbankeintrag entfernen
  • Zuletzt sollte man das nicht mehr gepflegte und lückenhafte WordPress-Plugin deaktivieren und löschen.

In der Konsequenz hat der WordPress Redirect Hack bei mir dazu geführt, dass ich nochmals kritisch das Thema WordPress-Plugins überdacht habe. Plugins bieten für ein Online Content-Management-System durchaus einen Mehrwert, in dem sie es um neue nicht vorhandene Funktionen erweitern. Plugins sind aber auch zusätzliche Software, die auch zusätzlich Programmierfehler mit sich bringen können. Wenn ein Plugin nicht mehr kompatibel ist und in der Konsequenz auch nicht mehr funktioniert, weil es nicht mehr weiterentwickelt und gepflegt wird, dann ist das vielleicht das geringere Problem. Es ist eben aber auch möglich, dass es noch voller Programmierfehler steckt, die das Plugin zu einem Sicherheitsrisiko für die gesamte Webseite macht. Meine Einstellung zu Plugins war sowieso schon immer: so viele wie nötig, so wenig wie möglich. Auch ist die Empfehlung vielleicht nicht schlecht, dass wenn Plugins nicht benötigt werden, sie nicht nur zu deaktivieren, sondern sie dann auch zu löschen. So habe ich angefangen, meine WordPress-Plugins mal wieder ein wenig zu entrümpeln.
Vor knapp zehn Jahren habe ich so zum Beispiel mir das Podlove-Plugin installiert, weil WordPress keine Audiodateien in die Mediathek mit aufnehmen und auch nicht wiedergeben konnte. Für einen Blog-Artikel habe ich diese Funktionalität aber benötigt. Vor gut fünf Jahren wurde WordPress dann endlich um die Funktion der Audiowiedergabe erweitert. So brauchte ich nun nur den Beitrag etwas anpassen und konnte wieder ein Plugin einsparen und deinstallieren.
Eins anderes Beispiel ist das Duplicator-Plugin für Backups von WordPress-Blogs. Lange Zeit habe ich es für Backups und Migrationen des Web-Servers verwendet. Aber spätestens seit ich die Piwigo-Bildergalerie als Unterverzeichnis im Web-Server habe, ist die Größe des httpdocs-Verzeichnisses so stark gestiegen, dass es nur noch funktionieren wird, wenn ich die Bezahloption des Plugins in Anspruch nehme. Aber mal ganz ehrlich: Schon bevor es Plugins für Backups von Content-Management Systemen gab, mussten ganze Web-Verzeichnisse und Datenbanken auf andere Instanzen hin und her migriert werden.

Links:

Kobo Hacking Teil 3 – Der fertige, digitale Bilderrahmen

Neulich habe ich mal durch meine alten Blog-Beiträge durchgeblättert um zu schauen, worüber ich alles so bisher geschrieben habe. Dabei bin ich im Konkreten wieder auf zwei Artikel gestoßen, in denen ich beschreiben habe, wie sich der eBook-Reader Kobo Mini Touch „hacken“ ließ, um Zugang zum Linux unter der Kobo-Software zu bekommen. Damit bot sich dann die Möglichkeit, den kleinen eBook-Reader mit seinem e-Ink Touch-Display für die eigenen Basteleien zu missbrauchen.
In meinem ersten Blogartikel vom 26. Oktober 2014 bin darauf eingegangen, wie man den nötigen Telnet-Zugang auf den Kobo erlangt und die WiFi-Einstellungen auf die eigenen umbiegt. Im zweiten Artikel – erst neun Monate später am 19. Juli 2015 verfasst und veröffentlicht – habe ich geschildert, wie die Verfahrensweise ist, um beliebige Bilder oder Fotos als Bitmap-Grafikdatei in Dateien so umzuwandeln, dass der kleine Kobo mit seinem beschränkten schwarz-weiß Display diese wieder darstellen kann. Soweit hatte ich alles beschrieben, damit der Kobo Mini auch als digitaler Bilderrahmen funktioniert. Woran ich aber vor sechs Jahren nicht mehr gedacht habe, ist, dass ich Bilder mit den Ergebnissen mit in den Blogartikel einzubinden, sodass ein Leser den Wandlungsprozess der von mir verwendeten Fotos nachvollziehen kann. Dabei habe ich damals im Sommer 2015 sogar extra für die Fotostrecke des Bilderrahmens ein paar Fotos im Regenstaufer Lindenpark mit meiner Kamera geschossen. Das hole ich mit diesem Artikel nun doch mal nach.

Original JPEG-Fotos:

Portätmodus
Landschaftsmodus

Link: Vollständiges Fotoalbum „Campus Eckert und Sonnenuntergang“

Mit GIMP erstellte PNG-Bilder (800×600 px, 4 Bit Graustufen):

Porträtmodus
Landschaftsmodus

Link: Campus Eckert und Sonnenuntergang (schwarz/weiß)

Darstellung mit dem Kobo Mini Touch:

Digitaler Bilderrahmen - vertikal
Gehackter Kobo Mini Touch als digitaler Bilderrahmen umfunktioniert
Digitaler Bilderrahmen - horizontal
Gehackter Kobo Mini Touch als digitaler Bilderrahmen umfunktioniert

Allerdings muss ich aber auch dazu sagen, dass der kleine Kobo Mini kein Gyroskop wie Smartphones und Tablet-Computer hat. Um wirklich ungetrübte Freude beim Betrachten der Bilder zu haben, ist es dazu leider nötig, sich beim Zusammenstellen der Bilderstrecke gleich zu entscheiden, ob sie vertikal in einem Porträtmodus oder horizontal dargestellt werden sollen. Er kann nun mal nicht ein Bild automatisch neu ausrichten.

Links:

Emulation einer PDP-11/70 unter SIMH mit Unix Time-Sharing System Seventh Edition (V7)

Vor knapp einem Jahr habe ich den Beitrag über den Sanos PDP-11 Simulator mit dem Time-Sharing System Seventh Edition verfasst. Bei dem Sanos PDP-11 Simulator handelte es sich nur um eine Live CD-Demo, die man in das CD/DVD-Laufwerk des eigenen PCs – oder als ISO-Datei in eine virtuelle Maschine – einlegt und von ihr startet. Technisch wird dabei wahrscheinlich ein sehr keines Linux-Live System gebootet, welches direkt den SIMH-Emulator mit der nachgebildeten PDP-11 startet. Für den allerersten Eindruck von dem Time-Sharing System V7 ist dieser ganz in Ordnung, aber außer ein paar Verzeichnisse erstellen, Dateien manipulieren oder ein kleines C-Programm schreiben, kompilieren und Ausführen wird da nicht mehr möglich sein. Dieser Emulator ist nämlich auf mehreren Ebenen ziemlich beschränkt. Dies fängt schon bei der emulierten Hardware an.: Der nachgebildeten PDP-11 wird nur verhältnismäßig wenig Speicher gestellt. – 512 KiB. Die späteren Modelle konnten bis zu 4 MiB RAM adressieren. Außerdem ist das Time-Sharing System V7 nur auf einem emulierten DEC RL02 Wechselplattenlaufwerk vorinstalliert, welches eine formatierte Gesamtkapazität von nur 10 Megabyte hat. Aus der recht wenig vorhandenen Festspeicherkapazität resultiert natürlich auch der geringe Umfang an Software und Programmquellen des Time-Sharing Systems. So fehlen bestimmt eine Reihe an Kommandos, sowie der Quellcode des Kernels. Da der Sanos PDP-11 Simulator am PC von einer CD – also einem Read-only-Medium gestartet wird, kann der veränderte Zustand nicht gespeichert werden, beziehungsweise es gibt keine Möglichkeit ein beschreibbares Medium an dem Emulator zu koppeln. Somit gehen alle Änderungen in der ausgeführten Emulation nach dem Neustart des PCs verloren. – Das ist schade!

Nun ist klar, dass mit dem SIMH prinzipiell auch eine individuelle Hardware-Konfiguration der PDP-11 möglich ist. So bin ich neulich beim Durchstöbern des ‚Computer History Wiki!‘ auf eine Installationsanleitung vom Time-Sharing System V7 auf eine DEC PDP-11/70 gestoßen. Diese emulierte PDP-11/70 ist mit 2 MiB RAM konfiguriert und besitzt als Systemfestplatte ein DEC RP06 Disk Drive mit 176 Megabyte Speicherkapazität, deren Plattenstapel im Original auch entfernbar, beziehungsweise wechselbar ist. Hinzu kommt noch ein DEC TU10 Magnetband-Laufwerk. Dies ist nötig, da die Installationsquelle von einem 1/2″ Magnetband kommt. Abgerundet wird dies durch ein DC11 Serial Interface für erst einmal bis zu 4 seriellen Terminals, damit die Installation auch echt Multiuser-fähig wird. Allerdings kann der Kernel das DC11-Interface nicht von Haus aus ansprechen, sondern das System muss nach vollendeter Installation erst neu konfiguriert und ein neuer Kernel erstellt werden.
Bei dem Time-Sharing System V7 kommt das Installations-Magnetband zum Einsatz, welches Keith Bostic von der Unix Heritage Society zur Verfügung gestellt hat. Ein Gimmick dieser Installationsquelle ist der vorhandene Account ‚dmr‘ des inzwischen 2011 verstorbenen Unix-Entwicklers Dennis MacAlistair Ritchie.

Unix Time-Sharing System V7
Research Unix Version 7 from 1979

Was mit dem Ende der Installation als Erstes auffällt, ist, dass es keine Befehle für den Halt des Systems, Shutdown und Reboot gibt. Man ist eher angehalten, das Dateisystem zu pflegen, in dem vor dem Abschalten oder Reset der Hardware der Befehl sync ausgeführt wird, damit die Superblöcke der Dateisysteme auf die Datenträger geschrieben werden. Auch wird stattdessen empfohlen, wenigstens einmal täglich jedes Laufwerk oder auf alle Fälle nach jedem Systemabsturz alle Dateisysteme mit den Kommandos icheck und dcheck auf ihre Konsistenz zu prüfen.
Ein Programm oder einen expliziten Befehl zum Anlegen eines weiteren Benutzers existierte unter dem Time-Sharing System V7 noch überhaupt nicht. Stattdessen heißt es Dateien editieren, Verzeichnisse erstellen, die Verzeichnisse den entsprechenden Eigentümern zuordnen und Zugriffsrechte erteilen. – Oder man schreibt sich am Ende selber ein Programm zum Anlegen der Benutzer als Shellscript. Wie bereits erwähnt, enthält diese Unix-Version den Login-Namen ‚dmr‘, der sein Heimatverzeichnis unterhalb von /usr besitzt. Diese Anordnung der Benutzerverzeichnisse war dann noch sehr lange gängig. Der Ordnung halber habe ich für meinen eingeschränkten Account erst das Verzeichnis /home angelegt, in dessen mein Heimatverzeichnis untergeordnet wird, so wie es inzwischen bei den modernen BSDs und unter Linux üblich ist.
Für das Bearbeiten von Dateien musste man sich Ende der 1970er Jahre immer noch mit dem Zeilen-orientierten Texteditor ed zufriedengeben. Der vi war zu diesem Zeitpunkt zwar schon geboren, fristete aber noch derzeit unter BSD sein Nischendasein, gab es doch schon für die PDP-11 neben den Druckerterminals bereits das eine oder andere Videoterminal mit einem Röhrenbildschirm. Und bedingt durch die Druckerterminals gab es auch sonst noch keinen Komfort auf der Bourne Shell.

Für den normalen Multiuser-Betrieb habe ich den SIMH mit der emulierten PDP-11 in einer GNU Screen-Session gestartet. Danach die Sitzung trennen und sich mit Telnet auf einer der seriellen TTY-Schnittstellen anmelden. Im Gegensatz zum Terminalfenster unter Screen bleiben so die Rollback-Zeilen des Terminals erhalten. – Was nötig ist, denn die Ausgabe der Shell unter Unix V7 findet quasi auf einem emulierten Druckerterminal statt, welches nichts von einer Seitenweisen Darstellung versteht.

Anleitung Installation und Einrichtung im eigenem DokuWiki

Links:

MacPorts macOS Big Sur clang Error Code 77

Nach meinem Upgrade von macOS 10.15 Catalina auf macOS 11 Big Sur und der darauffolgenden Installation der aktuellen MacPorts habe ich bei einem Paket vom Compiler folgenden Fehler bekommen.:

% sudo port install gd2
Warning: The macOS 11.0 SDK does not appear to be installed. Ports may not build correctly.
Warning: You can install it as part of the Xcode Command Line Tools package by running `xcode-select --install'.
Computing dependencies for gd2
Fetching archive for gd2
Attempting to fetch gd2-2.3.0_0+x11.darwin_20.x86_64.tbz2 from https://kmq.jp.packages.macports.org/gd2
Attempting to fetch gd2-2.3.0_0+x11.darwin_20.x86_64.tbz2 from http://jog.id.packages.macports.org/macports/packages/gd2
Attempting to fetch gd2-2.3.0_0+x11.darwin_20.x86_64.tbz2 from https://packages.macports.org/gd2
Configuring gd2<br>Error: Failed to configure gd2, consult /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_gd2/gd2/work/libgd-2.3.0/config.log
Error: Failed to configure gd2: configure failure: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_gd2/gd2/main.
Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port gd2 failed

Dem Log-File war zu entnehmen, dass der Compiler mit dem Error-Code 77 den Kompiliervorgang abgebrochen hatte. Was mich aber verwundert hatte, war, dass obwohl das aktuelle macOS 11.0 SDK und die Xcode Command Line Tools installiert waren, mir der Lösungsvorschlag präsentierte wurde, die Xcode Command Line Tools zu installieren. Nach etwas Recherche im Internet bin ich auf einen einfachen wie effektiven Lösungsvorschlag gekommen. Einfach die löschen und erneut installieren.

sudo rm -rf /Library/Developer/CommandLineTools
sudo xcode-select --install

Links: