Archiv der Kategorie: zum Blog

Backup-Shellscript für diesen Webserver

Veröffentlicht am von

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

Veröffentlicht am von

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:https://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:

Meine eigene Fotogalerie

Veröffentlicht am von

Eine eigene Online-Bildergalerie ist im Jahr 2019 nun wahrlich keine Wissenschaft mehr. Vor knapp 12 Jahren habe ich angefangen, meine Fotos auf der bereits für Hobbyfotografen etablierten Plattform Flickr hoch zu laden und war über die Jahre hinweg immer sehr angetan von dem Community- und dem sozialen Netzwerk-Aspekt der Nutzer untereinander. Daran wird sich hoffentlich in Zukunft auch erstmal nichts ändern. Auch, und gerade vielleicht deshalb, weil Flickr auf ein für mich – wie für viele andere auch – moderates und annehmbares Finanzierungsmodell bisher setzte.

Als ich vor 8 Jahren davon überging, mein Blog nicht nur als ein Nutzer von vielen bei WordPress.com  direkt zu führen, sondern es stattdessen auch selber zu Hosten, habe ich mich aus mehreren technischen Gründen für eine virtuelle Maschine eines bestimmten – auch in Deutschland nieder gelassenen – Hosters entscheiden. Allerdings ist bei dem für mich ausreichenden Einstiegspaket direkt eine Festspeicherkapazität von 100 Gigabyte im Angebot immer enthalten. Darunter für weniger Geld gibt es leider bei dem Anbieter nichts. Den Anbieter zu wechseln ist für mich aber auch keine Option, da ich mit dem Service, sowie dem Kunden-Support bisher immer recht zufrieden war. So blieben bisher von den pauschal-vertraglichen 100 GB gut über 90 Prozent immer ungenutzt.

Als ich vor zwei Jahren ein 6-monatiges Praktikum bei einem kleinen Datacenter in Frankfurt am Main absolvierte, bestand eine Aufgabe für mich darin, in einem zugewiesenen Web-Space eine Bildergalerie zu erstellen, um einerseits für Neukunden einen optischen Eindruck über das Unternehmen mittels Fotos zu den Unternehmensräumlichkeiten zu präsentieren. Andererseits sollten über diese Bildergalerie mit den bestehenden Kunden die Paketlieferungen der Computerhardware optisch auf Unversehrtheit dokumentiert werden. Im Rahmen der Recherchen für dieses kleine Projekt, habe ich mich für die Piwigo-Bildergalerie entschieden. Als großes Plus für Piwigo steht neben der seit 2002 kontinuierlichen Weiterentwicklung der Software, auch eine stete Weiterentwicklung von Smartphone-Apps sowohl für Android, als auch für Apple iOS.

Leider hat es nicht nur zu viel Zeit bis jetzt gebraucht, bis ich meinen Webserver auf eine neue virtuelle Instanz mit einem aktuelleren Linux migriert habe, sondern ich auch die Chance ergriffen habe, das Thema mit der Piwigo-Fotogalerie selbst auf den bisher ungenutztem Online-Speicherplatz für mich umzusetzen. In den kommenden Wochen werde ich dann alle Fotos, die ich bisher nur auf Flickr veröffentlicht habe, hier in meine eigene Galerie hochladen.

Update 22.12.2019 13:25:

Nun habe ich alle Fotos von meinem Flickr-Account, sowie viele von den inzwischen neuen Fotoalben auf meinem Smartphone in die eigene Piwigo-Galerie hoch geladen.

Links:
– Piwigo (Wikipedia)
– Piwigo Projektseite
– eigenes Flickr-Fotoarchiv
– eigene Piwigo-Gallerie
– Piwigo-App für Apple iOS
– Piwigo-App für Android (Google Play Store)

Jetzt auch mit eigenem DokuWiki

Veröffentlicht am von

Schon seit langem veröffentliche hier in diesem Blog Artikel mit irgendwelchen Beschreibungen und auch gelegentlich Passagen mit Programmcode.
Auf Grund dessen, dass ich vor einiger Zeit wieder mit der Schule begonnen habe, fühle ich mich derzeit motiviert, vieles was mit dem Bereich ‚Erlernen einer Programmiersprache‘ zu tun hat auch noch zusätzlich online zu dokumentieren. Deswegen habe ich mich nun doch endlich mal dazu durchgerungen, zu diesem Zwecke auch ein eigenes DokuWiki auf meinem Server zu installieren.
Aber mal sehen, was ich über dies hinaus noch so alles an Informationen in’s Wiki werfen werde.

Zum schmökern in der Informationshalte geht’s hier entlang.

Still Fishing!

Veröffentlicht am von

Diese kleine Postille hat durchaus damit zu kämpfen, dass zu wenig Content über sie in die große weite Netzwelt kommuniziert wird. Das hat durchaus begründete Ursachen. Zum einen fällt es mir nicht immer einfach, die zusammen getragenen Gedanken durchaus verständlich zu artikulieren. Zumal die Schreibblockade immer zuerst einmal überwunden werden möchte. Des weiteren bin ich nicht jemand, der sein Blog dazu benutzt, um die jeweils aktuellen Themen, die ein Teil der Blogosphäre und andere Kanäle wie zum Beispiel Twitter beschäftigen, noch einmal erneut durch zu kauen. Andererseits möchte ich auch nicht die belanglosesten Albereien von irgendwelchen Video-Portalen unnötig weiter verbreiten.

Da abzusehen ist, dass die Nightline auf you-fm in ein paar Wochen – als zum Jahresende eingestellt wird und damit auch Holger Klein keine weiteren Sendungen beim Hessischen Rundfunk bestreiten wird, habe ich mal die Vermutung, dass irgendwann auch das von Holgi geführte Weblog zu der Sendung gelöscht wird. Dies war neulich Anlass genug für mich, im Blog noch einmal durch die alten Artikel zu schmökern. Sicherlich wäre es ganz schön, wenn man ein komplettes Weblog noch mal auf eine elegante Art und Weise rezipieren oder archivieren könnte. So blieben einem mit Sicherheit die zum Teil entweder amüsanten, informativen oder scharfen – aber auf alle Fälle immer klug durchdachten – Beiträgen zum Zeitgeschehen erhalten. Ausserdem lebt ein Blog erst wirklich durch seine Kommentare. Doch nichts ist oder kann für die Ewigkeit sein. Wenn diese Seite gelöscht wird, so muss sich die Welt dennoch weiter drehen können. Und sie wird es auch tun.

Dennoch habe ich das Blog mal mit den nach YouTube beziehungsweise Google-Video verlinkten Reportagen und alten Filmen in englischer Originalsprache durchsucht und mit der Originalquelle gebookmarked, die Holgi so freundlicherweise aus den Untiefen des Internet heraus gegraben hat. Unter der kleinen Rubrik Still Fishing! werde ich also demnächst die für mich zum größten Teil interessanten Filme mehr oder weniger Kommentarlos als Blogeintrag verlinken.