Archiv der Kategorie: Webentwicklung

Angriffe auf WordPress-Blogs minimieren

Seit etwa Februar 2013 finden im diesmal extrem großen Stil Angriffe per Botnetz auf WordPress-Blogs statt. Darüber ist viel geschrieben worden, aber ein paar eigene Erkenntnisse möchte ich noch beisteuern.

IP-Adressen der Angreifer per .htaccess-Datei (im Falle eines Apache-HTTP-Servers) zu sperren hat keinen Sinn, es wurden schon über 90.000 verschiedene mit weltweiter Herkunft gezählt. Oft wird das Plugin »Limit Login Attempts« empfohlen. Diese Erweiterung verhindert Brute-Force-Attacken. Sie ist leicht zu konfigurieren und gehört für mich inzwischen als Muss zu jeder WordPress-Installation.

An vielen anderen Schwachstellen setzt »Better WP Security« an. Was mir besonders gut gefällt, ist eine Verschleierung des Login-Bereiches: über die gewohnten Dateinamen ist das Login nach entsprechender Einstellung nicht mehr erreichbar. Ferner kann man zum Beispiel die Anmelde-Möglichkeit auf bestimmte Tageszeiten begrenzen, das Tabellenpräfix ändern, die Benutzer-ID »1« (= standardmäßige ID des Administrator-Accounts) in eine andere Zahl umschreiben, die wichtigsten Dateien und Verzeichnisse per .htaccess-Einträge gegen Zugriff abriegeln und so weiter. Die Optionen sind wirklich beachtlich, aber man sollte auf jeden Fall vor irgendwelchen Änderungen ein Datenbank-Backup machen. Außerdem kann man sich im schlimmsten Fall selbst vom Blog aussperren. Man muss dann die .htaccess-Datei bearbeiten. Also bitte ein wenig Vorsicht walten lassen!

Es wird von den Angreifern übrigens nicht nur der Benutzername »admin« verwendet, wie man in manchen Blogartikeln lesen kann, sondern auch »Admin«, »administrator«, »Administrator«, »adminadmin« und womöglich noch weitere Variationen. Das Wichtigste ist also, keinen Benutzernamen zu verwenden, in welchem »admin« in irgendeiner Form vorkommt.

Um aber Angreifer gar nicht bis zum Anmeldebereich kommen zu lassen, habe ich mich entschieden, die Datei wp-login.php in Hauptverzeichnis des Blogs nur für meine eigene IP-Adresse freizugeben – genauer gesagt: für den IP-Bereich meines Internet-Service-Providers. Dazu sind nur ein paar Zeilen in die .htacess-Datei einzutragen:

# Adminbereich absichern
<Files wp-login.php>
Order Deny,Allow
Deny from all
Allow from xx.xxx.
</Files>

Anstelle von »xx.xxx.« trägt man natürlich die ersten zwei Bytes des IP-Bereiches seines Providers ein. Hier kann man seine IP-Adresse ermitteln:
www.torstenkelsch.de/deine-ip.php

Weitere Informationen:
t3n.de/news/massive-angriffswelle-[…]
www.heise.de/security/meldung/Botnet-attackiert-Wordpress-[…]
www.golem.de/news/security-angriff-gegen-admin-konten-[…]

Colophon in WordPress-Themes

In manchen WordPress-Themes, zum Beispiel im Standard-Theme Twenty Eleven, findet man die ID colophon in style.css bzw. in footer.php. Es geht offensichtlich um die Angaben im Fußbereich, aber ich hatte das Wort Colophon, oder in deutsch Kolophon, noch nie gehört und recherchierte im Netz und in Wörterbüchern.

Der Begriff stammt aus dem Verlagswesen. Schon im Mittelalter wurde die Druckermarke, also das Signet des Druckers, auf der letzten Buchseite eingedruckt – in der Frühzeit des Buchdrucks war der Drucker oft gleichzeitig der Verleger und auch Buchhändler. Später wurden die Druckermarken durch die Verlagssignete ersetzt. Der Kolophon kann entweder auf der Rückseite des Titelblattes oder ganz am Ende des Druckwerkes stehen. Er enthält heute üblicherweise Informationen über Inhalt, Verfasser, Ort, Zeit, Hersteller, Auftraggeber und Produktionsdetails. Oft sind die Angaben auch aufgeteilt, sodass zum Beispiel Angaben zum Druck vorne platziert sind und hinten Kurzlebensläufe der Autoren oder Dankesworte zu finden sind.

Insofern kann ein Kolophon auch auf einer Website auftauchen. Es ist zu unterscheiden vom Impressum, das Pflichtangaben über den Herausgeber der Website, Kontaktdaten und oft auch weitere gesetzlich vorgeschriebene Angaben enthalten muss. Bei manchen Geschäftsbetrieben oder Freiberufen muss zum Beispiel die zuständige Aufsichtsbehörde genannt werden.

Im Kolophon hingegen findet man manchmal Informationen zu (X)HTML und CSS, Angaben zur Benutzerfreundlichkeit, verschiedene Qualitätssiegel oder einen Hinweis auf das eingesetzte Content-Management-System. Sehr gut eignet sich für all dies der Fußbereich. Der Betreiber der Website oder die Autoren des Blogs stellen sich aber oft auf einer ganzen Seite vor, die etwa Über uns oder About us genannt wird.

WordPress liegt somit nach meinem Verständnis nur teilweise richtig damit, Colophon zu dem Fußbereich zu sagen. Andere Inhaltsverwaltungs-Systeme nennen es allgemeiner Footer.

—

Quellen:
http://blog.templaterie.de/about/
Duden-Wörterbuch
Langenscheidt-Wörterbuch
http://de.wikipedia.org/wiki/Kolophon_(Schriftstück)
http://de.wikipedia.org/wiki/Geschichte_des_Buchdrucks

concrete5: Verlorenes Passwort in der lokalen Testumgebung

Es passiert immer mal wieder und es passiert wohl jedem mal (da schließe ich jedenfalls von mir auf die Allgemeinheit): man verliert oder vergisst ein Passwort und kommt nicht mehr ins entsprechende System hinein. Wie fast alle Content-Management-Systeme bietet auch concrete5 die Möglichkeit, sich einen Link per E-Mail zuschicken zu lassen, mit Hilfe dessen man ein neues Passwort eingeben kann.

Im Falle einer lokalen Installation auf einem Windows-Computer wird das nicht klappen, es sei denn, man hätte einen lokalen Mailserver installiert. Es gibt für diesen Fall verschiedene Lösungen. Als die einfachste erscheint mir die folgende:

1. Das Passwort-»Salz« (Erklärung siehe Wikipedia), das in der Datei [concrete5-Verzeichnis]/config/site.php steht, kopieren.
2. Mit einem Datenbank-Bearbeitungs-Programm (zum Beispiel HeidiSQL oder MySQL-Front) die in MySQL integrierte MD5-Funktion eingeben und als Query absenden:
UPDATE Users SET uPassword = md5('password:salt')
WHERE uName = 'username';

Für password setzt man das gewünschte neue Passwort ein, salt ist eben die Salt-Zeichenfolge aus site.php und username der Name des Benutzers, für den man das vergessene Passwort erneuern will. Das wird natürlich in aller Regel der Superadmin sein.

Danke an okhayat!
http://www.concrete5.org/community/forums/usage/local_install_lost_password/

concrete5: Absender im Kontaktformular (3)

Im gestrigen Artikel schrieb ich, wie man die standardmäßig vergebene Absenderadresse im Kontaktformular ändern kann.
Um den Absender auch für diejenigen Mitteilungen zu ändern, die zum Beispiel bei Registrierungen oder vergessenen Passwörtern übersendet werden, empfiehlt sich folgender Code, den man auch wieder in die Datei [root]/config/site.php einträgt (Beispielangaben bitte durch die echten ersetzen):

define('EMAIL_DEFAULT_FROM_ADDRESS', 'noreply@example.com');
define('EMAIL_DEFAULT_FROM_NAME', 'Maria Musterfrau');

Quellen:
www.concrete5.org/[…]/change-concrete5-noreplyyourdomain-com/
www.concrete5.org/[…]/change-email-for-user-registration/
Danke an alle, die ihre Lösungen im Forum veröffentlicht haben!

concrete5: Absender im Kontaktformular (2)

In einem älteren Artikel hatte ich eine Lösung vorgeschlagen zu einem Problem mit dem Form-Block, mit dem man Kontaktformulare erstellen kann. Standardmäßig wird nämlich immer die E-Mail-Adresse des Superbenutzers als Absenderadresse der Anfragen angegeben. Dies führt manchmal zu Verwunderung und Misstrauen bei den Kunden.

Meine damalige Lösung erforderte Eingriffe in den Block und war umständlich und unelegant. Aber man lernt ja immer dazu, und jetzt kann ich eine bessere Lösung präsentieren:

Fügen Sie eine einzige Codezeile zu [root]/config/site.php hinzu (»example« muss natürlich durch die echten Angaben ersetzt werden):
define('FORM_BLOCK_SENDER_EMAIL','example@example.com');

Danke an Ekko!
http://www.concrete5.org/community/forums/usage/concrete5-forms/#349698

concrete5: Fehlermeldung beim Upload von Blöcken

Neulich setzte ich concrete5 in Version 5.6.0.1 in meiner Testumgebung komplett neu auf, weil das Upgrade von Version 5.5.2.1 fehlgeschlagen war. Eine Neuinstallation war in diesem Fall weniger aufwändig, als den Fehler zu suchen und zu korrigieren.

Als ich aber modifizierte Blöcke (blocks) wieder in den dafür vorgesehenen Ordner [root]/blocks/ hochgeladen hatte, wurden Fehlermeldungen angezeigt, die auf angebliche Fehler im jeweiligen Controller (controller.php) der Blöcke hinwiesen. Ich konnte in den Dateien aber nichts Fehlerhaftes entdecken, außerdem hatte ja auch vorher alles funktioniert. Kurzum, ich konnte mir keinen Reim darauf machen.

Im concrete5-Forum fand ich die Lösung: Man muss zunächst die Blöcke wieder aus dem Verzeichnis löschen, dann (über das Dashboard) das Caching (die Puffer-Speicherung) komplett ausschalten und den Cache leeren. Danach lädt man die Blöcke wieder hoch, und nun funktioniert alles.

Danke an yeetien fürs Veröffentlichen seiner oder ihrer Lösung!
http://www.concrete5.org/index.php?cID=377099

Online das Programmieren von Web-Sprachen lernen

In der Codecademy kann man das Programmieren lernen, zumindest das Programmieren in typischen Web-Sprachen. Als da wären:

  • JavaScript (in den Grundzügen)
  • JQuery (= JavaScript-Bibliothek)
  • HTML und CSS (aber das sind eigentlich keine Programmiersprachen)
  • und alles zusammen, um damit Webseiten zu erstellen
  • ach ja, und auch noch Python (ein Allrounder)

Ich musss gestehen, dass ich noch keinen Kurs davon ausprobiert habe. Bisher habe ich immer mit Hilfe von Büchern gelernt und bei speziellen Aufgabenstellungen mich in Foren nach Lösungen umgesehen. Aber dass bei der Codecadamy Python angeboten wird, reizt mich, denn diese Sprache wollte ich immer schon mal lernen. Ich fand bisher nur keine Zeit. Ob mich so ein Online-Lehrgang dazu bringt, eben doch endlich mal die Zeit zu investieren?

Wir werden sehen.

URL-Rewriting in lokaler Testumgebung

In meiner lokalen Testumgebung auf meinem Windows-Computer läuft als HTTP-Server Apache, natürlich PHP als Programmiersprache und MariaDB – das Datenbank-Management-System, das kompatibel zu MySQL ist. Alle Komponenten sind separat installiert, also nicht als XAMPP-Paket; aber das nur am Rande.

Natürlich betreibt man lokal keine Suchmaschinenoptimierung, und so ist es eigentlich egal, wie der URL geformt ist. Dennoch möchte man gern alles so testen, als liefe es auf einem Produktiv-Server »da draußen«. Als ich in einem CMS, das ich ausprobieren wollte, die »hübschen URLs« einschaltete, wurde auch die .htaccess-Datei korrekt erstellt. Aber die Website war nicht voll benutzbar, weil sich die Unterseiten nicht besuchen ließen. Es wurden Fehlermeldungen ausgespuckt: die jeweilige Seite sei nicht erreichbar.

Ich dachte zunächst an einen Fehler im CMS. Aber in einem Shopsystem, das ich daraufhin zum Testen installierte, trat genau dasselbe Phänomen auf. Also kam mir die Idee: Die .htaccess-Datei wird nicht ausgelesen oder deren Anweisungen werden nicht befolgt. Das Modul mod_rewrite war allerdings installiert. Ich wusste aber nicht, was in der Konfigurationsdatei des Apache-Servers falsch sein könnte.

Bei Stack Overflow fand ich die Lösung (danke an Sidney Veiga und todofixthis): In der httpd.conf muss man im zweiten Bereich Directory (dort, wo das Wurzelverzeichnis, DocumentRoot, angegeben wird) AllowOverride auf All setzen. Bei mir hatte None gestanden.

allowoverride-all.png

Admin-Passwort in osCommerce vergessen

Ich hatte vor einiger Zeit in meiner Testumgebung osCommerce installiert und wollte kürzlich mal daran weiter arbeiten. Doch ich hatte mir das Admin-Passwort nicht notiert, was mir eigentlich selten passiert. Erinnern konnte ich mich auch nicht.

Es gibt aber eine einfache und schnelle Möglichkeit, das Passwort auf einen Standard zurückzusetzen. Anschließend loggt man sich ein und gibt wieder ein sicheres Wort ein.

Man benötigt dazu ein auf dem Webserver installiertes phpMyAdmin, was eigentlich bei jedem Webhosting-Vertrag Standard ist. Man sucht sich die Tablle administrators heraus, die je nach Tabellen-Präfix natürlich zum Beispiel auch osc_adminstrators heißen kann. Die Passwörter sind verschlüsselt gespeichert. Im Passwortfeld überschreibt man den bisherigen Eintrag mit b5eb650d32fc4980284427104829b556:f6, was im Klartext admin heißt, und danach kann man sich wieder einloggen. Der erste Handgriff ist dann, wie gesagt, die Änderung des Passwortes.

Übrigens sollte man in einer Produktivumgebung den Admin-Benutzernamen als kleine Zusatz-Sicherheitsmaßnahme immer in einen möglichst nicht zu erratenden Namen umbenennen.

Einfache Datensicherung in WordPress

Ich habe lange nach einem Datensicherungs-Plugin für WordPress gesucht. Vor einiger Zeit fand ich DBC Backup, mit dessen Hilfe man Datenbank-Backups auf dem Webserver in regelmäßigen Zeitabständen speichern kann. Man kann auch zwischen verschiedenen Kompressions-Methoden wählen, je nachdem, was vom Server unterstützt wird. Und ein Backup lässt sich auch von Hand anstoßen.

Der Nachteil ist allerdings, dass keine direkte Download-Möglichkeit angeboten wird, denn manchmal möchte man ja direkt aus WordPress heraus die Datenbank auf den PC speichern.

Doch kürzlich habe ich ein Datenbank-Backup-Plugin gefunden, das mich rundum zufriedenstellt. Es nennt sich PressBackup und kann auf den Webserver speichern, aber auch nach Dropbox oder Amazon S3. Oder für 10 USD pro Monat nach PressBackup.com. Dies bietet sich an, wenn man sehr große Datenmengen sichern und viele Backup-Versionen gespeichert lassen will (bis zu 50 möglich).

Gefunden habe ich den Tipp zu PressBackup im Blog von Matthias Pabst. Vielen Dank!

Nachträge:

  • Einen weiteren heißen Tipp gab Trickser (siehe Kommentarbereich). Danke dafür!
  • PressBackup ist seit 2018 nicht mehr erhältlich: This plugin has been closed as of November 30, 2018 and is not available for download. Reason: Guideline Violation.