Adventskalender 2014 – Tür 5

Heute beschäftigen wir uns einmal mit der Datenbank, die sozusagen das Gedächtnis von WordPress darstellt. Im Grunde genommen besteht WordPress nämlich aus zwei Teilen, einmal den Dateien auf dem Webspace, die (vereinfacht gesagt) festlegen, wie die Website aussieht und welche Funktionen zur Verfügung stehen, und der Datenbank, in der praktisch alle Einstellungen sowie die Inhalte von Beiträgen, Seiten und Kommentaren gespeichert werden. Auch die registrierten Benutzer werden hier abgespeichert. Im Betrieb fragt WordPress dann die verschiedenen Informationen von der Datenbank ab um dem Besucher Inhalte anzuzeigen, registrierten Nutzern Zugang zum Dashboard zu gewähren, und was sonst noch so auf der Website passiert.

Im Normalbetrieb kümmert sich WordPress um die Kommunikation mit der Datenbank, so dass man als Admin in der Regel selten direkt an der Datenbank arbeiten muss. Ab und zu ist es aber dennoch sehr praktisch, die Inhalte der Datenbank manuell ändern zu können. Allerdings sollte man dazu wirklich wissen, was man tut, sonst kann man auch großen Schaden anrichten. Deshalb ist eine der wichtigsten Regeln: Immer ein Backup anlegen, bevor man Sachen an der Datenbank ändert! Mehr zum Thema Backup gegen Ende dieses Artikels.

Das Standardwerkzeug für den Zugriff auf die Datenbank heißt „phpMyAdmin“ und wird in der Regel vom Webhoster gleich mit angeboten. Oft gibt es aus dem Verwaltungsbereich, wo man Datenbanken neu anlegen kann, auch gleich eine Möglichkeit, auf die einzelnen Datenbanken per phpMyAdmin zuzugreifen. Die Oberfläche zeigt eine Menge Informationen an, hat man den Bogen allerdings erst einmal heraus, ist die Handhabung nicht so kompliziert, wie es anfangs den Eindruck macht.

Der Zugang zur Datenbank ist eine Art Generalschlüssel

Mit phpMyAdmin lassen sich alle Informationen in der Datenbank bearbeiten. So eine Datenbank besteht aus einzelnen Tabellen, die jeweils einen bestimmten Namen haben, der sinnvoll den Zweck der Tabelle beschreiben sollte. Bei WordPress wären das beispielsweise Namen wie „wp_options“ (dort werden die meisten Einstellungen von WordPress, Plugins und Themes abgespeichert) oder wp_users (darin finden sich die Nutzernamen, die zugehörigen Passwörter, E-Mailadressen, das Registrierungsdatum, etc.). Den ersten Teil inklusive Unterstrich nennt man „Tabellen-Präfix“, dieser lässt sich bei der Installation von WordPress frei angeben. Aus Sicherheitsgründen sollte er auch vom Standardwert „wp_“ abweichen, das erschwert Angriffe auf die Datenbank. Für diese Abhandlung verwende ich trotzdem die Standard-Namen, damit stets klar ist, um welche Tabelle es geht.

Bevor es nun ans Eingemachte geht, ein Wort der Warnung: Unbefugte können mit dem Zugriff auf die Datenbank auch eine Menge ärgerliche Sachen anstellen. Das reicht von simplem Vandalismus wie dem Löschen von Beiträgen und/oder Nutzern bis hin zur Verseuchung der Bloginhalte mit Spam-Links oder Malware. Alle Zugangsdaten, mit denen der Zugang zur Datenbank gelingt, sollten deshalb wirklich nur vertrauenswürdigen Personen ausgehändigt werden. Und hier wird auch klar, warum der Webspace selbst gut abgesichert werden muss: WordPress muss selbst ja auch die Zugangsdaten für die Datenbank kennen. Gelingt es also einem Angreifer, WordPress zu überlisten und sich auf dem Webspace einzunisten, kann er praktisch auch auf die Datenbank zugreifen, indem er sich die Zugangsdaten aus der wp-config.php verschafft. Deshalb ist es auch nicht immer damit getan, alle Dateien vom Webspace zu löschen, um eine Infektion komplett zu beseitigen.

Kommen wir nun zum Tipp für heute:

  • Hilfe, meine WordPress-URL stimmt nicht mehr!

Dies tritt immer mal wieder auf, wenn man WordPress von einer Basis-URL auf eine andere umstellen will. Arbeitet man beispielsweise im Hintergrund an einem neuen Design auf einer Subdomain, kann es nach der Umstellung auf die Hauptdomain zu Problemen kommen, wenn zwei Einträge in der Datenbank nicht korrekt sind. Diese finden sich in der Tabelle „wp_options“. In phpMyAdmin zeigt ein Klick auf den Tabellennamen in der Spalte mit der Tabellenauflistung ganz links zum Inhalt der Tabelle. Jede Tabelle besteht aus einer oder mehreren Spalten, die jeweils eine bestimmte Information speichern. Ähnlich wie auf einem Blatt in einer Tabellenkalkulation kann jedes Datenfeld der Tabelle über die Angabe von Spalte und Zeile abgefragt werden. Die Abfrage muss dabei nicht auf die Nummer der Zeile beschränkt sein, man kann auch nach bestimmten Inhalten suchen, oder Daten aus anderen Tabellen als Referenz für die Suche nach Inhalten benutzen.

Für uns sind zunächst einmal zwei Spalten interessant: „option_name“ und „option_value“. Jede Zeile die in phpMyAdmin angezeigt wird, enthält ein Pärchen zusammengehöriger Informationen. In „option_name“ steht jeweils, um welche Information es sich in dieser Zeile handelt, und „option_value“ – leicht zu erraten – steht dann der eigentliche Wert. Um nun die Basis-URL unserer WordPress-Installation zu überprüfen, suchen wir in der Tabelle nach zwei Zeilen in der Datenbank. Für die erste suchen wir nach der Zeile, in der in „option_name“ der Inhalt „siteurl“ steht. Die zweite wichtige Zeile finden wir dort, wo in „option_name“ das Wort „home“ steht. In diesen beiden Zeilen speichert WordPress die Informationen, die im Dashboard unter Einstellungen/Allgemein eingegeben werden können.

Lösung mit phpMyAdmin direkt in der Datenbank

Zur Bearbeitung gibt es je nach Version von phpMyAdmin zwei Wege: Entweder öffnet ein Doppelklick auf das fragliche Feld ein Bearbeitungsfenster direkt dort, oder es ist notwendig, auf das Bearbeiten-Icon (den schreibenden Stift) in der jeweiligen Zeile zu klicken. Ein Tipp: Die allermeisten Icons und Felder liefern hilfreiche Tooltips, wenn man mit dem Mauszeiger auf ihnen stehenbleibt. Die große Bearbeitungsmaske sieht erst einmal verwirrend aus, dort gibt es auch viele Manipulationsmöglichkeiten. Für unseren Zweck reicht es erst einmal aus, den dort angezeigten falschen Inhalt zu korrigieren und dann auf den OK-Button zu klicken, der direkt unterhalb der Liste der einzelnen Datenfelder für die bearbeitete Zeile steht.

PhpMyAdmin zeigt übrigens immer nur eine bestimmte Anzahl Zeilen aus der Tabelle an. Oberhalb der Datenbankzeilen gibt es deshalb Navigations-Buttons, um seitenweise vor und zurück zu blättern und ganz ans Ende beziehungsweise ganz an den Anfang zu springen. Die Bedienung funktioniert eigentlich ganz intuitiv, am besten einfach ausprobieren. Vom reinen Durchblättern geht nichts kaputt. 😉 Wenn die gesuchte Zeile also nicht auf der ersten Seite erscheint, einfach so lange durch die Tabelle blättern, bis man sie gefunden hat. Man kann sich die Suche auch erleichtern, indem man die Tabelle nach dem Inhalt einer Seite sortiert. Dazu reicht es aus, einfach auf den Spaltenkopf zu klicken, wo der Name der Spalte steht. Mit dem ersten Klick wird die Tabelle in der aktuellen Sortierrichtung entsprechend dem Spalteninhalt sortiert angezeigt, ein zweiter Klick kehrt die Sortierrichtung um. Sucht man beispielsweise einen Wert, der mit „t“ beginnt, geht es meist schneller, die Tabelle absteigend zu sortieren, so dass die Zeilen mit „z“ zuerst angezeigt werden. Dann muss man weniger blättern, als wenn man bei „a“ beginnt.

Weitere interessante Sachen in der Tabelle „wp_options“ sind beispielsweise die Liste der aktivierten Plugins („active_plugins“), der Name des aktiven Themes („current_theme“) oder auch die Information, ob Nutzer sich registrieren dürfen („users_can_register“). Bei letzterem bedeutet die Zahl Null, dass die Registrierung abgeschaltet ist, mit dem Wert Eins lässt sie sich aktivieren. Hilfreich ist das beispielsweise, wenn man sich völlig aus dem eigenen Blog ausgesperrt hat und keine Zugangsdaten mehr weiß. Allerdings benötigt man dann noch einige andere Klimmzüge, um Administrator-Zugriff zu erlangen.

Zum Schluss noch ein Tipp in Sachen phpMyAdmin: Ganz am oberen Rand gibt es eine Navigationszeile, in der einem phpMyAdmin anzeigt, wo man sich gerade befindet. Klickt man hier auf den Namen der Datenbank, wird einem kein einzelner Tabelleninhalt mehr angezeigt, sondern eine zusammenfassende Liste der einzelnen Tabellen in der Datenbank. Mit einem Klick auf den Reiter „Exportieren“ kann man nun mit wenigen Handgriffen den Datenbankinhalt in Form einer SQL-Datei (oder auf Wunsch auch in anderen Formaten für besondere Zwecke) exportieren und sich so eine Sicherung der Datenbank anlegen. Das ist natürlich immer anzuraten, bevor man Änderungen daran vornimmt, Vorsicht ist die Mutter der Porzellankiste.

Das Gegenstück zum Export findet sich auf dem Reiter „Importieren“, allerdings sollte so ein Import außer in speziellen Fällen immer nur in eine komplett leere Datenbank erfolgen, damit alle Informationen aus der SQL-Datei auch korrekt in die Datenbank eingespielt werden können. Analog zum Export und Import der ganzen Datenbank lässt sich das auch für einzelne Tabellen durchführen, dazu klickt man einfach auf eine der Tabellen in der Tabellenauflistung. Es gibt Fälle, da ist es sinnvoller, nur eine einzelne Tabelle zu exportieren bzw. importieren, im Laufe der Zeit bekommt man ein Gespür dafür, wann welche Variante sinnvoller ist.

Ein paar Anregungen zum Schluss

Zum Experimentieren ohne Risiko empfehle ich übrigens, einfach eine weitere Datenbank anzulegen. Dann exportiert man aus der „echten“ Datenbank alle Informationen und importiert die erhaltene SQL-Datei in die neu angelegte Datenbank. So kann man gefahrlos die ersten Schritte in der Handhabung von phpMyAdmin üben. Hat man genügend Übung beim Bearbeiten der Datenbank gesammelt, kann man die Experimente-Datenbank ganz einfach mit der WordPress-Installation „verheiraten“, indem man die Zugangsdaten zur Datenbank in der wp-config.php entsprechend ändert. Tipp: Die bestehenden Zeilen einfach jeweils kopieren und erneut einfügen. Danach jeweils eine der Zwillingszeilen auf die Zugangsdaten (meist Datenbankname, -nutzer und -passwort) der Testdatenbank abändern und die Zeilen für die „echte“ Datenbank mit zwei Schrägstrichen (//) als Kommentar markieren. Zum Wechsel zwischen den beiden Datenbanken reicht es dann, die Kommentarzeichen jeweils umzusetzen.

Natürlich kann man auch eine komplette zweite WordPress-Installation dafür verwenden, wer ganz sicher gehen will, wird das sicherlich auch tun. Allerdings ist dann die Einrichtung etwas aufwendiger, bis beide Installationen wirklich komplett identisch sind. Letztlich ist das Resultat praktisch deckungsgleich, nur der Weg dorthin unterscheidet sich.

Wenn ich auf den Wortzähler schaue, dann war das für heute schon wieder eine ganze Menge an Informationen. Morgen geht es auch wieder richtig ans Eingemachte, dann kümmern wir uns um den bequemen Umzug einer WordPress-Installation. Bis dann!

Adventskalender 2014 – Tür 4

Für das Türchen am Barbaratag habe ich mir nochmals ein paar Quickies aus der Praxis rausgesucht, die immer wieder Kopfzerbrechen machen. Ohne lange Vorrede geht es auch schon gleich los:

  • Ich wollte die Adresse ändern, unter der mein Blog erreichbar ist, jetzt geht gar nichts mehr. 🙁

    Dieses Problem tritt relativ häufig auf, meistens ist die Lösung dann aber sehr simpel. In den Einstellmöglichkeiten von WordPress gibt es zwei Eingabefelder, mit denen festgelegt wird, unter welcher URL WordPress zu finden sein soll.Wordpress-Einstellungen-SiteURL Wenn der Inhalt dieser Felder nicht passt, ist WordPress mitunter gar nicht erreichbar, Links führen ins Nichts, oder auch der Login ins Dashboard klappt nicht mehr. Es handelt sich dabei um die beiden im Screenshot rot markierten Felder „WordPress-Adresse“ und „Seiten-Adresse“, mit denen sich beispielsweise dem Besucher vorgaukeln lässt, dass WordPress direkt im Hauptverzeichnis der Domain liegt, statt in einem Unterverzeichnis. So erspart man sich etwa ein störendes „/wordpress/“.

    Wordpress-SiteURL-fixieren Ist die Umstellung nun ins Auge gegangen oder liegt es an etwas anderem? Das lässt sich recht einfach überprüfen. WordPress sieht die Möglichkeit vor, die URL fest einzustellen, die beiden Felder oben werden dann ignoriert. Dazu müssen in der wp-config.php die zwei blau markierten Zeilen eingetragen werden. Wenn nach dem Speichern und Hochladen der wp-config.php die Website wieder erreichbar ist, dann lag es an der Umstellung im Dashboard. Wie diese Umstellung ohne Kopfweh auf Anhieb klappt, verrate ich euch übrigens hinter dem Nikolaus-Türchen.

  •  

  • Hilfe, mein Blog geht nicht mehr. Der Browser lädt und lädt und lädt und zeigt dann eine Fehlermeldung, irgendwas mit „zu viele Umleitungen“ oder so?!

    Wordpress-SiteURL-falsch Auch das ist oftmals auf eine falsche Konfiguration der oben erwähnten beiden Felder zurückzuführen. Trägt man beispielsweise die Adresse so wie im Bild ein, passiert etwas interessantes: WordPress spielt mit dem Browser Ping-Pong, bis es diesem zu dumm wird. Gibt der Besucher www.passwort-retter.de in den Browser ein, würde WordPress ihn zu passwort-retter.de weiterleiten, wo dann schon die nächste Weiterleitung auf www.passwort-retter.de wartet – und so ginge das unendlich weiter. Meistens geht in so einem Fall der Login ins Dashboard auch nicht mehr, so dass der Fehler nicht direkt zu korrigieren ist. Allerdings gibt es einfache Abhilfe: Die oben beschriebenen Einträge in der wp-config.php helfen auch in diesem Fall. Eine schönere Lösung ist es allerdings, die Werte für „siteurl“ und „home“ in der Tabelle wp_options der Datenbank zu korrigieren. Dazu morgen mehr.

  •  

  • Und wie kann ich die wp-config.php nun bearbeiten?

    Dazu braucht man in erster Linie zwei Programme. Zunächst ein FTP-Programm, etwa den kostenlosen Filezilla Client oder das sehr geniale, aber kostenpflichtige FlashFXP. Damit wird die Datei wp-config.php vom Webspace heruntergeladen und nach der Bearbeitung wieder hochgeladen.

    Zur eigentlichen Bearbeitung braucht man dann noch einen ordentlichen Editor. Die von Windows mitgelieferten Bordwerkzeuge wie Wordpad oder der Editor sind dafür leider nicht sehr brauchbar, es gibt aber eine Fülle kostenloser Editoren, die diese Lücke spielend füllen. Ich benutze beispielsweise seit einer gefühlten Ewigkeit Notepad++. Übrigens: Notepad++ lässt sich auch als Editor in FlashFXP integrieren, so dass beispielsweise direkt aus dem FTP-Programm die Bearbeitung gestartet werden kann und nach dem Speichern der Datei der Upload der neuen Version automatisch erledigt wird. Sehr komfortabel!

    Von der Programmwahl abgesehen ist die Bearbeitung der wp-config.php eigentlich recht einfach, da es sich um eine Textdatei handelt. Wichtig ist, dass man die Änderungen sorgfältig einträgt, ohne andere Zeilen versehentlich zu verändern. Sonst kann es zu den verschiedensten Problemen kommen, von einer nicht funktionierenden Datenbankverbindung bis hin zu falsch angezeigten Sonderzeichen. Aber auch wenn etwas schief gelaufen ist, lässt sich der Schaden in aller Regel reparieren. Allerdings braucht es dann meist das Hintergrundwissen des Fachmanns, um alles wieder geradezubiegen.

Sodele, wir sehen uns morgen beim nächsten Türchen, ich wünsche eine gute Nacht!

Adventskalender 2014 – Tür 3

Wie versprochen gibt es heute nach den umfangreichen Texten der letzten Tage mal zur Abwechslung ein paar Quickies, Fragen die immer wieder auftreten, samt Lösungsvorschlägen. Auf geht’s!

  • Frage: Hilfe, Hilfe, mein WordPress geht nicht mehr! Was nun?
    Zunächst einmal: Keine Panik, in wirklich so gut wie allen Fällen lässt sich das Problem beheben, wenn man systematisch vorgeht. Deshalb erst einmal einen kühlen Kopf bewahren. Der erste Schritt ist die genaue Untersuchung, was genau nicht mehr funktioniert. Erscheint einfach nur eine weiße Seite im Browser? Oder erscheint die Website zwar noch, wimmelt aber vor seltsamen Fehlermeldungen? Geht der Login ins Dashboard nicht mehr? Funktioniert die Website noch, wenn man nicht eingeloggt ist, nach dem Login kommt dann aber nur noch eine weiße Seite?

    Der zweite Schritt ist das Sammeln weiterer Informationen. Webserver protokollieren recht viele Informationen mit, je nach Hoster kann es aber kompliziert sein, an diese Informationen heranzukommen. Gängige Fundorte sind der Webspace (z.B. ein Ordner „Log“, „Logs“ oder ähnliches) und der Kundenbereich des Hosters. Meist findet sich irgendwo auf der Website des Hosters ein Hinweis dazu, wie die Logfiles zu erreichen sind. Hilfreich ist dafür auf jeden Fall auch eine Suche bei Google, etwa mit dem Suchwort „errorlog“ und dem Hosternamen.

    Manchmal muss man auch ein paar Tricks anwenden, um an die Fehlerausgabe zu gelangen. Wenn es kein offensichtliches Errorlog gibt, kann diese Methode zum Erfolg führen:
    – Ein Verzeichnis „errorlog“ auf dem Webspace anlegen, und darin eine leere Datei, z.B. „php_errors.log“ erzeugen.
    – In der .htaccess folgende Zeilen aufnehmen:


    # PHP error logging aktivieren

    php_flag log_errors on
    php_value error_log "<absoluter Pfad zum Verzeichnis>/php_errors.log"

    Wichtig ist dabei, dass der Webserver bzw. der PHP-Prozess auf jeden Fall Schreibrechte für die Datei bekommt, im Zweifelsfalle wäre also der Wert 0666 für die Dateirechte richtig. Den absoluten Pfad kann man sich von einer kleinen PHP-Datei ausgeben lassen, die man einfach in das gleiche Verzeichnis wie die php_errors.log legt. Hinein gehören folgende Zeilen:


    <?php
    $dir = dirname(__FILE__);
    echo "<p>Absoluter Pfad zur php_errors.log: " . $dir . "/php_errors.log" . "</p>";
    ?>

    Diese Datei ruft man dann einfach ganz normal im Webbrowser auf und überträgt den angezeigten Pfad in die .htacces. Wenn alles richtig eingestellt ist, sollten PHP-Fehler jetzt in der php_errors.log landen, was besonders hilfreich ist, wenn die Fehlermeldungen nur vorübergehend zu sehen sind, etwa bei automatischen Weiterleitungen. Wer mit der Analyse solcher Errorlogs überfordert ist, sollte sich fachkundige Hilfe holen. Meist ist es nur eine Kleinigkeit, nach der man als Laie aber Stunden und Tage suchen kann – ohne Garantie, etwas zu finden.

  • Frage: Ich möchte gerne ein kleines Bild in die Sidebar einfügen, und es anklickbar machen. Wie geht das?
    Der einfachste Weg dazu – vorausgesetzt, das verwendete Theme hat keine Spezialfunktionen dafür, die noch komfortabler sind – ist ein Textwidget, das per Hand mit den notwendigen HTML-Zeilen gefüttert wird. Lässt man die Titelzeile des Text-Widgets leer, erscheint das Bild meist schön kompakt. Und das muss in den Textteil des Widgets:


    <div style="text-align:center">
    <a href="Hierhin kommt der Link zum anklicken" target="_blank">
    <img src="Hierhin kommt die URL der Bilddatei" width="siehe unten" height="siehe unten" alt="Dieser Text wird angezeigt, wenn der Mauszeiger über dem Bild anhält" />
    </a>
    </div>

    Die Werte für width (Breite) und height (Höhe) sollte man passend für die Breite der Sidebar wählen, soweit das Bild nicht ohnehin schon in der passenden Größe vorliegt. Optimal ist es, wenn das Bild schon in den richtigen Abmessungen vorliegt, so dass der Browser das Bild nicht noch skalieren muss.

  • Frage: Hilfe, mein Theme zeigt seltsame Sachen an, die ich nirgends im Dashboard finden kann?!
    Häufig finden sich solche mysteriösen Blöcke in der Siderbar oder am Fuß der Seite. Des Rätsels Lösung ist dann oft simpel: Wenn eine Widget-Position überhaupt keinen Inhalt zugewiesen bekommt, präsentieren manche Themes stattdessen einen Standardinhalt. Die Abhilfe ist dann auch simpel: Einfach ein komplett leeres Textwidget an der fraglichen Position einfügen und schon sind die seltsamen Inhalte verschwunden.

So, damit sage ich „Gute Nacht“ für heute, morgen gibt es weitere Tipps und Tricks rund um WordPress.

Adventskalender 2014 – Tür 2

Nachdem ich gestern ein paar eher allgemeine Punkte zum Thema WordPress-Sicherheit angesprochen habe, gibt es heute mal ein paar Tipps aus der Praxis. Gleich vorneweg ein wichtiger Hinweis: Ein Sicherheitskonzept besteht immer aus einem ganzheitlichen Maßnahmenkatalog, aus vielen einzelnen Bausteinen, die sich gegenseitig ergänzen. So wie ein Damm ist ein Sicherheitskonzept immer nur so stark wie seine schwächste Stelle.

Die allermeisten Angriffe, denen eine WordPress-Installation ausgesetzt ist, zielen darauf ab, bekannte Lücken auszunutzen oder Zugang zum Blog über das massive Ausprobieren von Zugangsdaten zu erlangen. Speziellere Attacken, die beispielsweise auf den Webserver selbst abzielen, oder auf ein bestimmtes Blog direkt zugeschnitten sind, treten deutlich weniger häufig auf, vor allem weil sie in der Regel wesentlich mehr Aufwand für den Angreifer bedeuten. Massenattacken, wie sie bevorzugt von Botnets oder gekaperten Cloud-Systemen aus durchgeführt werden, leben davon, dass in möglichst kurzer Zeit möglichst viele Ziele abgeklopft werden – dementsprechend allgemein sind die Angriffsmuster gehalten. Alles was übermäßig Zeit braucht, drückt den Ertrag.

Gestern gab es ja schon einige Tipps zur Absicherung gegen erfolgreiche Loginversuche Unbefugter, die mit wenig Aufwand umsetzbar waren. Heute liefere ich ein paar Denkanstöße gegen eine sehr beliebte Sorte von Sicherheitslücken, die allgemein als „RFU“ (Remote File Upload, das Hochladen von Dateien auf den Webserver aus Drittquellen) bezeichnet wird. Eine der bekanntesten Lücken dieser Art wurde vor ein paar Jahren in TimThumb gefunden, einem eigentlich sehr nützlichen Helfer für die Bildbearbeitung (zuschneiden, Größe ändern, etc.). Da es leicht zu benutzen war und unter der GPL v2 freigegeben war, fand es in unzähligen Themes und Plugins Verwendung.

Dann wurde eine Lücke entdeckt, die es einem Angreifer ermöglichte, eine beliebige Datei von einem fremden Server auf den Webspace herunterzuladen. Eigentlich war diese Funktion dazu gedacht, Bilder aus externen Quellen einbinden zu können, ohne sie auf dem eigenen Webspace abzulegen (was aus Urheberrechtsgründen oftmals eine schlechte Idee wäre). Dummerweise fehlten dort aber einige Sicherheitsmaßnahmen, und so konnte ein Angreifer zielsicher Sachen wie eine Remote Shell (eine Art offenes Scheunentor für den Zugriff auf den Webspace und ggf. auch mehr) in die WordPress-Installation einschleusen. Die Zahl der Infektionen erreichte, je nachdem welcher Quelle man glauben mag, fünf- oder sechsstellige Höhe innerhalb kürzester Zeit. Inzwischen hat der Entwickler das Projekt komplett eingestellt und gibt Ratschläge, wie die Aufgabe „Bildbearbeitung“ stattdessen zu lösen ist. Klarer als „Wenn Du heute noch als WordPress-Entwickler Timthumb benutzt, machst Du etwas falsch“ (so der Timthumb-Autor) kann man es wohl nicht formulieren.

Die Abhilfe dagegen erscheint auf den ersten Blick simpel: Auch durch die böseste RFU-Lücke kann nicht auf den Webspace geschrieben werden, wenn der Webserver selbst (bzw. der PHP-Prozess, je nach Serverkonfiguration, mehr dazu später) keinen Schreibzugriff auf den Webspace hat. Logisch, oder? Dummerweise gibt es aber einige Situationen, in denen WordPress, Themes und Plugins durchaus auf den Webspace schreiben möchten. Das reicht von Cache-Plugins, die reichlich temporäre Cache-Dateien erzeugen müssen, über Themes, die Inhalte von Drittwebsites holen und zwischenspeichern, etwa für einen Twitter- oder Facebook-Feed, bis hin zum Update-Mechanismus von WordPress, der mitunter Schreibzugriff auf weite Teile der WordPress-Installation benötigt.

Hinzu kommt noch eine andere Problematik: Bei vielen Webhostern ist es überhaupt nicht möglich, den Webspace effektiv gegen Schreibzugriffe zu schützen. Vielfach sieht die Serverkonfiguration nämlich so aus: Webserver, FTP-Server (und ggf. PHP) laufen nicht unter getrennten Nutzern, haben also alle identische Zugriffsrechte. Das ist für den Webhoster eine einfache Sache, und einfach kostet wenig Geld – freut den Betreiber also. Der Nachteil für den Nutzer: Die Zugriffsrechte lassen sich ebenso einfach wieder zurücksetzen wie sie eingerichtet wurden, der Schutz gegen RFU-Lücken ist also wenig haltbar.

Besser sieht es bei Hostern aus, bei denen FTP-Zugang und Webserver als zwei unterschiedliche Nutzer konfiguriert sind. In diese Kategorie fällt beispielsweise einer meiner Lieblings-Hoster, All-Inkl. Dort gibt es zwei Nutzer, der eine wird für den FTP-Zugang verwendet, und der andere vom Webserver genutzt. Über den Kundenbereich lässt sich auf dem Webspace für jede Datei und jeden Ordner einstellen, ob entweder der Webserver oder der FTP-Server Besitz- und damit Schreibrechte hat. Eleganterweise kann WordPress mit so einer Konstellation sogar recht gut umgehen: Beim Update fragt WordPress bei einer solchen Einrichtung dann nach den FTP-Zugangsdaten, um das Update durchführen zu können. Auch das Problem mit Cache-Plugins, etc. läst sich damit recht gut eingrenzen: Für die absolut notwendigen Verzeichnisse stellt man dem Webserver Schreibrechte ein, der Rest bleibt unter FTP-Kontrolle. Das reduziert die Angriffsfläche auf ein Minimum.

Wie es mit den Schreibrechten bei diversen Hostern aussieht und wie man deren Möglichkeiten jeweils nutzt, hat Ernesto Ruge vor kurzem in geduldiger Kleinarbeit in einem Blogbeitrag zusammengestellt. Wer sich bei einem Hoster wiederfindet, kann außer einem Umzug zu einem anderen Hoster auch einige Maßnahmen ergreifen, um das Risiko zu minimieren:

  • Unbenötigte Plugins und Themes vom Webspace entfernen. Auch wenn sie nicht aktiv sind, können Lücken in ihnen ausgenutzt werden!
  • Per FTP-Client Schreibrechte überall dort entziehen, wo es problemlos möglich ist. Selbst wenn dies relativ leicht rückgängig gemacht werden kann, reduziert es die Angriffsfläche.
  • Per Eintrag in der .htaccess die Ausführung von PHP-Dateien überall dort blockieren, wo üblicherweise keine PHP-Dateien liegen sollten. Dort verstecken sich Schädlinge nämlich nur allzu gern.

Die zuvor bereits angesprochenen Tipps wie „Updates immer möglichst bald durchführen“ erspare ich mir hier nochmal zu wiederholen. 🙂

Die Blockade von PHP-Scripten über .htaccess ist übrigens sehr einfach einzurichten. Es reicht dazu, eine Regel wie im folgenden gezeigt mit aufzunehmen:


<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^(.*)/uploads/(.*).php(.?) - [F]
</IfModule>

Wenn bereits ein Block mit „IfModule mod_rewrite.c“ in der .htaccess besteht, reicht es, den Inhalt der Zeile mit „RewriteRule“ hinter der Zeile mit „RewriteEngine On“ einzufügen. Sobald die geänderte .htaccess wieder hochgeladen ist, können PHP-Scripte, die z.B. durch eine Sicherheitslücke in einem Plugin irgendwo unter /wp-content/uploads/ gelandet sind, dort nicht mehr ausgeführt werden. Analog lässt sich das natürlich auch auf die Verzeichnisse von Themes und Plugins anwenden, in denen nur Grafiken oder CSS-Dateien liegen. Allerdings muss man dann darauf achten, diese Dateien auch wieder zu erneuern, wenn es Updates für das Plugin bzw. Theme gab.

Einen Tipp muss ich zum Thema von gestern übrigens noch nachtragen: Wenn sich ein Angreifer erfolgreich Zugang zum Blog verschafft hat, ist der nächste Schritt oft die Implantation von Schadcode im aktuellen Theme, etwa in der 404.php – diese Datei wird immer dann angesprochen, wenn eine nicht existierende URL aufgerufen wird und kein separates Plugin für eine Umleitung sorgt. Diesen Weg kann man dem Angreifer allerdings erfolgreich versperren, indem man die internen Editoren für Themes und Plugins in WordPress einfach deaktiviert. Dazu reicht ein simpler Eintrag in die wp-config.php:


define( 'DISALLOW_FILE_EDIT', true );

Diese Zeile einfach direkt hinter der ersten Zeile einfügen und die geänderte wp-config.php wieder hochladen. Ab jetzt sind die internen Editoren für Plugins und Themes nicht mehr zugänglich. In Verbindung mit oben Tipps (um zu verhindern, dass der Angreifer einfach ein manipuliertes Plugin oder Theme installiert), lässt sich WordPress auf diese Weise wieder ein Stück sicherer machen. Damit soll es für heute auch genug sein, der Artikel ist wieder viel länger als geplant geworden. Bis morgen, dann gibt es ein paar Quickies aus der Abteilung „Erste Hilfe“.

Adventskalender 2014 – Tür 1

Für das erste Türchen habe ich mir ein Thema ausgesucht, das ein echter Dauerbrenner ist. Es geht um die Sicherheit der eigenen WordPress-Installation. Besser gesagt die gefühlte Sicherheit. Viele hilfreiche Tipps, wie sie beispielsweise mein „Kollege“ Ernesto Ruge auf seinem Blog präsentiert, können nämlich nicht verhindern, dass Blogbetreiber vor Situationen stehen, die sie nicht richtig einschätzen können.

Das kann beispielsweise eine Flut von E-Mails eines Sicherheitsplugins sein, das brav meldet, wenn sich jemand Zugang verschaffen wollte. Das ist an und für sich ja eine gute Sache, wird aber sehr schnell lästig, wenn ein Botnet zu Besuch kommt. Dann prasseln auf eine WordPress-Installation innerhalb kurzer Zeit Hunderte oder Tausende Loginversuche ein. Vorausgesetzt, der Webserver ist in der Lage, diese Massen zu meistern (dazu hinter einem späteren Türchen noch mehr), hat das zur Folge, dass der Blogbetreiber und Flut von Benachrichtigungen über fehlgeschlagene Loginversuche bekommt. Verständlicherweise verursacht dieser Ansturm dann schon ein flaues Gefühl im Magen. Abgesehen von der Frage nach dem Sinn, endlos einzelne Benachrichtigungen zu verschicken, statt Meldungen zusammenzufassen, wird dann unter Umständen als schnelle Maßnahme erst einmal das Plugin abgeschaltet.

Diese Aktion geht natürlich genau in die falsche Richtung (niemals den Boten erschießen, der die schlechte Nachricht bringt!). Stattdessen gilt es, Ruhe zu bewahren und dann einfach zu überprüfen, ob das eigene Blog sicher genug vor solchen Angriffen ist. Die meisten automatisierten Angriffe fallen in zwei Kategorien:

  • Ausprobieren von Logindaten
  • Abklopfen bekannter Sicherheitslücken

Zu Gegenmitteln für Angriffe der zweiten Kategorie komme ich später noch, schauen wir uns erst einmal an, wie das Ausprobieren von Logindaten funktioniert. Technisch ist das sehr simpel: Die Standard-URL für den Login ist bekannt, also ist es leicht, automatisiert fast beliebig viele Paare von Nutzername und Passwort durchzuprobieren. Das wird auch weidlich ausgenutzt, typische Angriffe kommen leicht auf vierstellige und fünfstellige Versuche. Dagegen gibt es mehrere Mittel, die je nach Webhoster mehr oder weniger einfach umzusetzen sind. Einige davon präsentiere ich noch in den nächsten Tagen, heute geht es aber zuerst einmal um das simpelste Mittel, solchen Angriffen zu begegnen: Starke Passwörter und Nutzernamen.

Ein Passwort, das Großbuchstaben, Kleinbuchstaben, Ziffern und Sonderzeichen enthält, und zudem eine gewisse Mindestlänge hat, ist die halbe Miete. Die andere Hälfte ist zum einen ein Username, der sich nicht einfach erraten oder aus der WordPress-Installation abgreifen lässt. Das bedeutet vor allem: Eigennamen, Namensteile und Standardnamen wie „admin“ oder „Administrator“ (auch „wp_admin“ würde dazu zählen!) sind Tabu.

Abgerundet wird die zweite Hälfte durch die sinnvolle Konfiguration der Nutzer in WordPress. Dazu gehört vor allem die Vergabe eines Spitznamens der nichts mit dem Benutzernamen zu tun hat. Der öffentliche Name sollte auf der Profilseite dann ebenfalls auf den Spitznamen umgestellt werden. So lässt sich der Benutzername nicht mehr aus der WordPress-Installation auslesen, wie es etwa durch Ausprobieren von URLs wie
www.example.com/?author=<0, 1, 2, 3, ...>
möglich ist.

Last but not least sollte für die Administration des Blogs ein Administrator-Account vorhanden sein, der auch wirklich nur zu diesem Zweck verwendet wird, während redaktionelle Arbeiten mit einem zweiten Account erledigt werden, der nur den Rang „Redakteur“ hat. Obige Ideen gelten natürlich für alle Nutzer des Blogs, sofern sie nicht nur Abonnenten sind. Denen kann man nur schwer vorschreiben, wie sie ihr Profil gestalten, dafür können diese Nutzer in der Regel aber auch keinen großen Schaden anrichten.

Das soll als Denkanstoß für heute reichen, morgen geht es für die technisch interessierten Leser mehr ans Eingemachte. 🙂 Und natürlich freue ich mich sehr über Fragen und Anregungen, die ich gerne aufgreife und beantworte.

Adventskalender 2014 – Rund um WordPress

Für dieses Jahr habe ich mir mal das Thema ausgesucht, das mich seit geraumer Zeit am meisten beschäftigt: WordPress. Klar, es gibt schon unzählige Seiten, auf denen sich „die 1000 besten Tipps und Tricks“ tummeln, aber dort wird häufig nur der immer gleiche Kram wiedergekäut, der teilweise schon arg veraltet ist. Ein Beispiel: Die wp-config.php manuell zu erstellen, etwa um die geheimen Schlüssel einzutragen, mit denen WordPress Passwörter und Cookies absichert, kann man sich tatsächlich sparen. Die Installationsroutine von WordPress erledigt das seit geraumer Zeit ganz elegant nebenbei mit.

Die enorme Geschwindigkeit, mit der sich WordPress entwickelt, ist einer der Gründe, warum solche Tipps und Tricks immer eine Art Ablaufdatum haben. Irgendwann werden viele dieser Tipps durch den technischen Fortschritt obsolet. Deswegen habe ich für meinen Adventskalender 24 kleine Bonbons zusammengestellt, die auf interessanten und/oder häufig auftretenden Fragen aus der Praxis basieren. Einige dienen lediglich dem Komfort, andere sind aber auch etwa unter dem Aspekt der Sicherheit interessant. Ein infiziertes WordPress kann unangenehme Folgen haben, wobei ein Webhoster, der den Vertrag kündigt, noch zu den kleineren Übeln gehört. Im schlimmsten Fall kann es sogar zu Haftungsansprüchen kommen, die sehr schnell sehr teuer werden. Da ist vorsorgen wirklich besser als heilen.

In diesem Sinne: Viel Vergnügen beim Lesen und Ausprobieren!

P.S. Selbstverständlich bin ich auch an den Feiertagen erreichbar, wenn „es brennt“. Gerade an Tagen, an denen nicht mit schneller Reaktion des Blogbetreibers zu rechnen ist, nehmen Angriffe erfahrungsgemäß deutlich zu.

WordPress 4.0

Nun ist sie da, die neue „major version“. Geändert hat sich vor allem für Pluginautoren einiges, während die Optik gar nicht mal so großartige Unterschiede aufweist. WordPress wird langsam aber sicher erwachsen, so viel steht fest. Ein rasches Update auf die 4.0 ist vor allem aus Sicherheitsgründen angeraten, allerdings sind mir bei meinen Tests relativ viele Plugins aufgefallen, die mit der neuen Version Probleme machten. Offenbar haben vor allem die Updates der externen Bibliotheken (jQuery ist jetzt als Version 1.11.1 an Bord, TinyMCE in Version 4.1.3 und MediaElement hat den Sprung auf Version 2.15 gemacht) so einigen Code zum Stolpern gebracht. Das wird sich sicherlich in den nächsten Tagen erledigt haben, Early Adopter kennen das Spiel ja schon.

Gelungen finde ich auf jeden Fall die neue Mediathek und die Plugin-Suche. Dort sieht man vor allem auf einen Blick, ob ein Plugin zur aktuellen WordPress-Version passt, oder nicht. Zwar gibt es auch viele Plugins, die auch mit 4.0 noch laufen, obwohl sie schon ewig nicht mehr aktualisiert wurden, aber die Luft wird für Alt-Plugins zunehmend dünner. Einiges, was noch vor zwei Jahren in Plugins ausgelagert war, gehört heute für so manches Theme ohnehin zum guten Ton oder wird von anderen Plugins miterledigt, so dass sich dieses Problem mit der Zeit auch mehr oder weniger selbst löst.

Nachtrag: Jetzt haben wir auch „endlich“ eine fette Lücke in den Vorgängerversionen. Ein Update auf die 4.x ist spätestens jetzt dringend angeraten. Wer dabei auf Probleme stößt, dem helfe ich gerne weiter.

Earth Day 2013

Heute ist Earth Day, zu Deutsch „Tag der Erde“. Immerhin 175 Länder der Erde begehen diesen Tag, an dem die Wertschätzung für die natürliche Umwelt im Mittelpunkt stehen soll. Dazu gehört natürlich auch, sein eigenes Konsumverhalten zu überdenken. Schade eigentlich, dass es dazu einen besonderen Tag im Jahr braucht – denn eigentlich ist Nachhaltigkeit eine Aufgabe, die Alle angeht, und zwar jeden Tag.

Gerade bei moderner Elektronik lässt sich viel für die Umwelt tun, das beginnt schon damit, nicht jedes neue Nachfolgemodell zu kaufen. Wenn Geräte erst dann ausrangiert werden, wenn sie endgültig nicht mehr zu reparieren sind, wird der Umwelt damit schon eine Menge Elektroschrott erspart. Wer schon einmal Dokumentationen darüber gesehen hat, wie unser Elektroschrott in Indien oder Afrika „wiederaufbereitet“ wird, weiß worum es geht.

Auch das Thema „geplante Obsoleszenz“ spielt eine wichtige Rolle. Viele Geräte gehen frühzeitig kaputt und lassen sich vom Laien gar nicht erst öffnen, geschweige denn reparieren. Hier kann der Fachmann aber häufig trotzdem kostengünstig helfen. Oftmals ist der Defekt mit dem Austausch eines Pfennigartikels behoben, wenn man nur weiß, wonach man suchen muss. Dass die Reparatur trotzdem nicht für fünf Euro zu haben ist, liegt am Zeitaufwand für die Demontage, Fehlersuche und den anschließenden Zusammenbau. Trotzdem ist die Reparatur beispielsweise bei einem Notebook wesentlich kostengünstiger als die Anschaffung eines Neugerätes.

Unter Berücksichtigung des ökologischen Fußabdrucks rentiert sich auch die Reparatur kleinpreisiger Artikel, beispielsweise bei Tintenstrahlern. Weiteres Einsparpotenzial bietet hier das Wiederauffüllen gebrauchter Tintenpatronen. Den Druckerherstellern ist dies natürlich ein Dorn im Auge, weswegen immer häufiger mit technischen Tricks gearbeitet wird, um das Wiederauffüllen gebrauchter Patronen zu verhindern. Schließlich soll der Kunde doch bitte Original-Verbrauchsmaterial nachkaufen und nicht „fremdgehen“. Immer mehr Menschen lassen sich diese Gängelung nicht mehr gefallen (siehe auch dazu mein Artikel „Kundenbindung heißt nicht Kundenfesselung!„) und stimmen entweder mit den Füßen ab oder ersinnen trickreiche Maßnahmen, um den Herstellern ein Schnippchen zu schlagen.

Mittlerweile organisieren sich die Tüftler und Bastler auch, beispielsweise auf Websites wie iFixit oder als Repair Café – und wenn die Reparatur doch etwas kniffliger wird oder Spezialwerkzeug benötigt wird, findet man so auch Kontakt zu den wenigen noch existierenden Reparaturbetrieben. Die haben sich oft auf eine bestimmte Produktpalette spezialisiert und bieten in ihrem Segment dafür erstklassigen Service und Zugang zu Ersatzteilen, die für „Normalsterbliche“ kaum oder gar nicht erhältlich sind.

In diesem Sinne: Nicht recyclen. Reparieren!

 

 

 

 

Kundenbindung heißt nicht Kundenfesselung!

Im letzten Jahr ist es mir immer häufiger aufgefallen: Kunden kommen auf mich zu und haben vor allem ein Problem: Ihr bisheriger Dienstleister hockt wie eine Glucke auf wichtigen Informationen (Zugangsdaten, Passwörter, etc.) und mag diese nur ungern, oder auch gar nicht, herausgeben. Oftmals verursacht dieses Verhalten Produktivitätsverluste, die anfangs aber noch einfach zu ignorieren sind. Irgendwann fühlt sich jedoch auch der zufriedenste Kunde durch solch ein Verhalten gegängelt – und beginnt nach Alternativen zu suchen. Für den Dienstleister kann diese aggressive Form der Kundenbindung also nur begrenzt funktionieren.

Warum also gängelt der Dienstleister den Kunden?

Diese Frage habe ich mir schon oft gestellt, und so sehr ich mir auch das Hirn zermartere, mir fällt nur eine plausible Antwort ein: Es ist die einfachste Weise, seinen Kunden Geld abzuknöpfen. Gleichzeitig stellt der Dienstleister so zumindest zeitweise sicher, dass der Kunde nicht einfach zu einem Mitbewerber wechselt. Offenbar muss sich erst noch die Erkenntnis durchsetzen, dass dies keine langfristige Strategie sein kann. Solange der Zustrom von Neukunden nicht versiegt, lässt sich der Schwund durch „verbrannte“ Kunden kompensieren, irgendwann ist jedoch der Punkt erreicht, an dem der Ruf des Dienstleisters durch diese Geschäftsmethoden ernsten Schaden erleidet.

Welche Alternativen gibt es?

Meiner Ansicht nach sollte es das Ziel des Dienstleisters sein, mit seinem Kunden auf Augenhöhe zu arbeiten. Kunden mit eigenen Fachkenntnissen werden nach Bedarf unterstützt und beraten, dürfen aber auch gerne selber testen und experimentieren. Wenn einmal etwas schief geht, ist der Fachmann zur Stelle und beseitigt das Problem.

Ist der Kunde weniger erfahren, so fällt dem Dienstleister die Rolle eines Mentors zu, der zusammen mit dem Kunden die Wünsche und Anforderungen ermittelt und umsetzt. Dabei muss sowohl vom Kunden ausgehend (Umsetzung seiner Wünsche), als auch auf den Kunden zugehend gearbeitet werden (Beratung, Wissensvermittlung). So erkennt der Kunde den Wert der Dienstleistung und wird in der Regel zum treuen Stammkunden.

Eine dritte Gruppe bilden Kunden, die sich nicht mit dem „Computerkram“ befassen möchten. Hier ist der Dienstleister besonders gefordert, auf den Kunden einzugehen und seine Bedürfnisse zu ermitteln. Oftmals hat der Dienstleister hier völlig freie Hand, was Segen und Fluch zugleich sein kann. Wichtig ist hier vor allem eine sorgfältige Dokumentation, damit auch später immer vollständig erklärbar ist, warum welche Auswahl getroffen wurde. Nachvollziehbarkeit hat hier eine sehr hohe Priorität.

Übrigens: Meine Kunden erhalten vollständige Listen aller Zugangsdaten ohne Wenn und Aber – aus eigenem Antrieb und mit der Bitte, sich die Listen auszudrucken und sorgfältig abzuheften. Meine Maxime ist: Meine Kunden sollen auch ohne mich stets in der Lage sein, auf alle ihre Daten, Websites, etc. zugreifen zu können. Im Notfall muss die Möglichkeit gegeben sein, dass ein anderer Dienstleister nahtlos dort weitermachen kann, wo ich aufgehört habe. Immerhin ist es ja nicht auszuschließen, dass mir einmal ein Meteorit auf den Kopf fällt 😉

Fazit

Ich kann jedem Dienstleister nur raten, mit seinen Kunden zu reden, einen offenen und ehrlichen Dialog zu führen und auf jegliche Bevormundung seiner Kunden zu verzichten – es ist letztlich in seinem eigenen Interesse. Ansonsten sucht sich der Kunde irgendwann einen Dienstleister, der besser zu ihm passt und ihn auch als gleichberechtigten Partner ernst nimmt. Schließlich erwartet der Kunde für sein gutes Geld auch gute Leistung und keine Gutsherrenart.

 

Wenn die Zugangskontrolle zur Farce wird…

Moderne Geräte zur Zugangskontrolle, die entweder einen Fingerabdruck lesen oder mittels Keycard z.B. via RFID befugte Personen erkennen, tauchen im Alltag immer häufiger auf. Dazu trägt sicherlich auch der immer weiter sinkende Preis solcher Sicherheitstechnik bei. Allerdings bietet so manches dieser Geräte nur eine gefühlte Sicherheit. Grundlegende Designpatzer wie fehlende Sabotagesicherungen oder leicht zu erreichende Relais für den Türöffner sind da nur die Spitze des Eisbergs – so das Fazit nach einem Auftrag, für den mein Kollege Björn Gerber von GEngineering und ich diverse Geräte aus der Kategorie Zugangskontrolle unter die Lupe genommen haben.

Neben den Schwächen in der Konstruktion der Hardware kristallisierten sich auch relativ leicht ausnutzbare Lücken in der Firmware der Geräte heraus. So gab es beispielsweise bei einem Gerät mit Fingerabdruckscanner und RFID-Leser folgende Lücke: Angelernte Fingerabdrücke wurden mit einer ID-Nummer versehen, wurde später ein bestimmter Fingerabdruck erkannt, so wurde per Wiegand26-Protokoll diese ID an das Sicherheitssystem gemeldet. Bei unbekannten Fingerabdrücken erfolgte keinerlei Meldung. Die ID einer per RFID erkannten Zugangskarte wurde jedoch immer per Wiegand26 weitergemeldet, egal ob die Karte im System vorher angelernt worden war oder nicht. Damit war eine erhebliche Lücke geschaffen: Mit einem manipulierten RFID-Tag, das eine der leicht erratbaren IDs für angelernte Fingerabdrücke enthielt, ließ sich für das Sicherheitssystem nicht mehr unterscheiden, ob ein Fingerabdruck oder ein RFID-Tag gemeldet wurde – damit war unbefugten Personen leichter Zugang zu Sicherheitsbereichen möglich.

Der Test brachte noch ein weiteres Fazit: Verwenden Sie niemals solch ein Zugangskontrollsystem direkt als Türöffner – lassen Sie die Tür durch das zentrale Sicherheitssystem von innen öffnen. Im Testfeld war kein Gerät mit integriertem Türöffner, das diesen ausreichend schützte. Natürlich muss ich anmerken, dass dieses Testfeld sicherlich nicht repräsentativ für den Markt war, da es vom Auftraggeber stammte. Trotzdem ist die Bilanz deutlich: Ohne zusätzliche Maßnahmen taugen viele Geräte keinen Cent, obwohl sie mehrere Hundert Euros in der Anschaffung kosten. Mein Kollege hat übrigens motiviert durch diesen Test eine schicke kleine Hardware entworfen, mit der sich kostengünstig das Sicherheitsniveau existierender Installationen verbessern lässt. Neben der reinen Umsetzung zwischen USB und Wiegand-Bus sind im GEngineering Wiegand2USB zahlreiche nützliche Zusatzfunktionen integriert, unter anderem auch die Möglichkeit, einen Türöffner anzusteuern. So kann die Türöffnung sicher aus dem geschützten Bereich heraus erfolgen und eine Manipulation am externen Terminal wie oben beschrieben ist nicht mehr möglich.

Es gilt also auch 2013: Ein Sicherheitskonzept ist nur so stark wie der schwächste Baustein. Erst ein stimmiges Gesamtkonzept bietet die gewünschte Sicherheit, Einzelmaßnahmen sorgen oft nur für vermeintliche Sicherheit.