Blog

Limit Login Attempts: selbst ausgesperrt

Blogs, die auf dem wohl verbreitetsten Blogsystem WordPress laufen, sind natürlich äußerst beliebte Ziele von Crackern. Bots versuchen, durch wiederholtes Ausprobieren von Benutzernamen und Passwörtern in die Systeme einzudringen. Diese Brute-Force-Attacken sind weit verbreitet.

Es gibt verschiedene Möglichkeiten, sich zu schützen, die ich in diesem Rahmen nicht alle besprechen möchte. Sicherlich fängt der Schutz damit an, dass man keinen Benutzer admin im System hat und natürlich keine Passwörter wie password oder 1234 benutzt.

Ein bekanntes und beliebtes, wenn auch inzwischen veraltetes Plugin ist Limit Login Attempts, das eben diese Brute-Force-Attacken abzuwehren versucht. Wie es das macht, beschreibt Vladimir Simović in seinem Blog perun.net.

Dumm nur, wenn man sich selbst ausschließt. Es ist peinlich, aber ich muss zugeben: mir ist das gestern passiert. Irgendwie habe ich wohl drei- oder viermal ein altes, nicht mehr gültiges Passwort eingegeben, und schon kam ich nicht mehr ins Backend hinein. Vladimir empfiehlt, entweder die Zeitsperre abzuwarten oder eine andere IP-Adresse zu verwenden. Dazu müsste man im Falle eines DSL-Modems die Internet-Verbindung trennen und sich neu einloggen. Im Falle eines DSL-Routers müsste man vermutlich den Router neu starten, um eine andere IP zu erhalten, oder?

Ich schlage eine weitere Möglichkeit vor. Sie setzt allerdings voraus, dass man Zugriff auf die WordPress-Datenbank hat, und den hat man nur bei einem selbst gehosteten WordPress-Blog, nicht aber bei einem Blog auf wordpress.com. Außerdem eignet sich diese Methode auch nur für versierte Anwender. Und zwar löscht man einen Eintrag in der Datenbank (zum Beispiel über phpMyAdmin, falls der Webhoster es zur Verfügung stellt oder man es selbst installiert hat).

Im Detail: Tabelle wp_options, Feld option_name, Eintrag limit_login_lockouts, Feld option_value, und hier den Eintrag aus <MEMO> löschen.

Allerdings gibt es Plugins mit weiteren Möglichkeiten, sein WordPress-Blog sicher zu machen. Mehrere werden auf t3n.de vorgestellt. Welche man einsetzen will, mag jeder für sich entscheiden.

concrete5: Menü-Icons in TinyMCE fehlen

Neulich hatte ich nach einer frischen Installation von concrete5 das Problem, dass dem WYSIWYG-Editor TinyMCE im Content-Block die Menü-Icons fehlten. Auch früher schon einmal hatte ich das erlebt, und in Foren kann man lesen, dass es auch anderen Leuten bisweilen so geht. Dieses Phänomen ist ein bisschen mysteriös, denn es tritt anscheinend sporadisch auf, ohne erklärbare Ursache.

In meinem Fall könnte es daran gelegen haben, dass ich beim Upload der concrete5-Dateien ziemliche Verbindungs-Probleme zum FTP-Server des Kunden gehabt hatte und möglicherweise nicht alle Dateien korrekt hochgeladen worden waren. Nachdem ich die Ordner concrete/js und concrete/blocks gelöscht und neu hochgeladen hatte und außerdem das Verzeichnis files/cache geleert hatte, war wieder alles normal.

Diese Menüleiste fehlte.
(Aufs Bild klicken zum Vergrößern)

TinyMCE in concrete5: CSS anpassen

In einem älteren Artikel hatte ich erklärt, wie man die Schriftgröße des WYSIWYG-Editors TinyMCE in concrete5 anpassen kann, da ich die Schrift in der Standardeinstellung zu klein finde. In jenem alten Tipp wurde die Schriftgröße generell für alle Themes geändert.

Einfacher und schneller ist es jedoch, die Schriftgröße des Editors nur für das aktive Theme anzupassen. Denn der Standardfall dürfte sein, dass man ein einziges Mal ein Gestaltungsthema erstellt und das Erscheinungsbild seiner Website nicht wie die Unterwäsche wechselt. Für diesen Zweck kann man zusätzlich zur Datei main.css eine weitere Stildatei erstellen, nämlich typography.css. Und selbst wenn nach ein paar Jahren die Website neu gestaltet werden muss, kann man diese Datei ja einfach in das neue Theme-Verzeichnis übertragen.

Natürlich lassen sich neben der Schriftgröße auch andere Einstellungen über diese CSS-Datei beeinflussen – in einem schon recht alten, englischsprachigen Blogartikel des concrete5-Kenners Remo Laubacher geht es eher darum, die Textfarbe der Überschriften im Editor gleich aussehen zu lassen wie auf der Website.

Winzig kleine Schrift

Und wieder einmal habe ich durch Zufall eine Website entdeckt, die eine so kleine Schriftgröße aufweist, dass das Lesen einfach keinen Spaß macht. Der Text ist gesetzt in Arial in der Größe 10 Pixel. Hier die Angaben in der CSS-Datei:

.schrift {
	font-family: Arial, Helvetica, sans-serif;
	font-size: 10px;
	font-style: normal;
	font-weight: lighter;
	text-transform: none;
	color: #333333;
	line-height: 13px;
}

Ganz ehrlich, was soll so was? Das ist so, als würde man Bücher und Zeitungen in so winziger Schrift drucken, dass man Papier sparen und die Blattgröße schön klein halten kann. Eine Tageszeitung in DIN A5 oder so. Der Leser soll sich doch gefälligst eine Lupe kaufen.

Standardeinstellung der Schriftgröße ist in allen Webbrowsern, die ich kenne, 16 Pixel, und das sicherlich aus gutem Grund. Dass sich diese voreingestellte Anzeigegröße durch CSS-Angaben verändern lässt, ist grundsätzlich eine sinnvolle Sache, gerade heutzutage. Denn die Menge der heute verfügbaren Webfonts ist gewaltig, und wie auch im Druck, fallen manche Schriftfamilien größer aus, manche kleiner. Die Lesbarkeit wird beeinflusst durch verschiedene Merkmale wie die Breite und Formgebung der einzelnen Buchstaben, die Höhe der Kleinbuchstaben im Verhältnis zu den Großbuchstaben oder die Abstände der Buchstaben zueinander, und da macht es Sinn, die Schriftgröße an die jeweilige Schriftfamilie anpassen zu können (andere Faktoren wie Bildschirmauflösung oder Art des Displays spielen weitere Rollen, aber das ist ein Thema für sich).

Wir Menschen möchten Informationen im WWW finden. Wir möchten sie schnell finden und einfach erfassen können. Also müssen Bilder aussagekräftig, Texte gut formuliert und Schriften auf Anhieb lesbar sein, ohne dass man die Nase an den Monitor drücken muss. Und insofern ist eine 10 Pixel kleine Arial ganz einfach ungeeignet.

Kundenanfragen entgegennehmen mit LiveZilla

Ich habe mal LiveZilla ausprobiert, eine Chat-Software, mit der es Interessenten leicht gemacht wird, Kontakt aufzunehmen. Man lädt das Programm auf den Webserver hoch, integriert einen JavaScript-Code auf der eigenen Website und installiert auf dem Windows-PC den Client. Neuerdings ist auch eine Version für Mobilgeräte erhältlich, die ich allerdings nicht ausprobiert habe.

Das Integrieren auf der Website und das Installieren des Operator Client (für Windows) ist unkompliziert – vorausgesetzt man weiß, wie man Quelldateien bearbeitet, diese zum Server hochlädt und wie man Windows-Programme installiert. Wenn der Client aktiv ist, wird der Webseiten-Besucher unaufdringlich aufmerksam gemacht, dass er oder sie per Chat Kontakt aufnehmen kann, anderenfalls bleibt LiveZilla auf der Webseite ausgeblendet. Der Besucher kann also eine Unterhaltung starten, und beim Operator bimmelt es, sodass er oder sie bemerkt, dass jemand beraten werden möchte. Beide Seiten sehen, wenn der Gesprächspartner gerade etwas eintippt.

LiveZilla macht einen ausgereiften Eindruck. Wenn man Einzelkämpfer ist, kann man es sogar kostenlos verwenden, die Pro-Version kostet allerdings Geld, gestaffelt nach der Anzahl der Operatoren. Diese Investition kann sich lohnen, da ein solcher Echtzeit-Service die Kundenzufriedenheit erhöhen und zu Kaufabschlüssen führen kann. Natürlich müssen dann zu den normalen Geschäftszeiten Mitarbeiter für mögliche Interessenten verfügbar sein. Steht der Dienst die halbe Zeit still, macht das keinen guten Eindruck. Und auch auf schlecht frequentierten Websites, die vielleicht gerade mal fünf Besucher am Tag haben, ergibt so ein Aufwand wenig Sinn. Sehr sinnvoll kann hingegen der Einsatz auf gut besuchten Webshops mit beratungsintensiven Produkten sein.

Leider gibt es auch Nachteile. Die für so einen Dienst nötigen JavaScript-Dateien führen zu erhöhten Server-Anfragen und verlangsamen den Seitenaufbau der Website. Nicht unbedingt spürbar, aber doch messbar. Da die Schnelligkeit einer Website einer der relevanteren Suchmaschinen-Optimierungs-Aspekte ist, sollte man die Vorteile gegen die Nachteile abwägen. Für mich selbst habe ich entschieden, LiveZilla wieder zu entfernen.

Visuelle Aussage

Über visuelle Aussagen oder Erklärungen könnte man sicherlich lange diskutieren. Man könnte erörtern, wie welche Aussage gestaltet sein sollte, um über welche Kanäle welche Zielgruppen zu erreichen. Man könnte auch darüber philosophieren, warum menschliche Wesen überhaupt die Neigung verspüren, jedem nebensächlichen Gedanken gleich eine riesige Bedeutung beizumessen und ihn in die Welt hinaus zu posaunen. Man könnte über Sinn, Unsinn und Aussagekraft von Katzenfotos auf Facebook reden, klar. Aber lassen wir das.

Reden wir über Visual Statements beziehungsweise VS Rocket beziehungsweise create.visualstatements.net. Puh. Ein weiterer Dienst, mit dem man sinnloses Zeug zusammenklicken und munter auf Facebook, Twitter und sonst wo verteilen kann, weil die Welt ja mehr Statements braucht. Oder geht es um virales Marketing? Nun ja, kann sein. Aber ich denke doch, dass dafür mehr Kreativität erforderlich ist als Bildvorlagen mit Textpassagen zu versehen.

Bequem zu bedienen ist VS Rocket ja, keine Frage, und die »Gestaltung« macht auch irgendwie Spaß. Man könnte sogar eigene Fotos hochladen, wenn einem die angebotenen Bilder nicht zusagen. Aber das würde voraussetzen, dass man überhaupt selber gut fotografieren oder illustrieren kann, und dann – ja dann kann man ja gleich ein Bild­bear­bei­tungs­programm zur Hand nehmen.

Trotzdem: VS Rocket, mit dem man seine visuellen Statements in die Welt hinaus schießen kann wie eine Rakete von Cape Canaveral aus zum Mond, ist eine pfiffige Idee. Es ist leicht zu bedienen und man kommt schnell zu Ergebnissen. Ich bewundere jedenfalls die Programmierarbeit, die dahinter steckt – das ist für mich die eigentliche Kunst daran.

MailForge für Eudora-Liebhaber?

Eudora war ein beliebter und leistungsfähiger E-Mail-Client der Firma Qualcomm. Als kommerzielles Produkt wird diese Software seit Herbst 2006 nicht mehr weiterentwickelt, und auch der Open-Source-Nachfolger Eudora OSE ist irgendwann sanft entschlafen. Man kann zwar beide Programme noch herunter laden, sollte sie aber eigentlich nicht verwenden. Eudora OSE basiert auf einem uralten Thunderbird und gilt als unsicher. Da kann man lieber den aktuellen Thunderbird benutzen, zu dem ja nach wie vor Sicherheits-Updates und Bugfixes erscheinen.

Doch ich habe noch etwas anderes entdeckt: und zwar eine Neuentwicklung, die sich stark an dem alten Eudora orientiert. Dieses Ding nennt sich MailForge, ist erhältlich sowohl für Mac OS X als auch für Windows und wird herausgegeben von der Firma Macsimize Software. Der Preis liegt bei knapp 20 Dollar. Als Nostalgiker habe ich diese Software natürlich gleich mal ausprobiert, denn man kann eine zeitlich begrenzte Testversion herunter laden. Getestet habe ich unter meinem ganz normalen alten Büro-PC mit einem 3 GHz starken Intel-Pentium-4-Prozessor, 2 GB RAM und Windows 7 als Betriebssystem.

Und – was soll ich sagen: die Enttäuschung war groß. Zwar kam gleich das alte Eudora-Gefühl auf, aber das Programm ist … nun ja … völlig untauglich (zumindest in der Windows-Version und nach meinen Erfahrungen). Gleich beim Einrichten eines E-Mail-Kontos stürzte das Programm einfach mal grundlos ab. Na gut, egal, neu gestartet und weiter gemacht. Wenn man aber noch nicht mal eine E-Mail abschicken kann, weil man angeblich nichts in den Body der E-Mail geschrieben hat, obwohl man das sehr wohl getan hat, dann … tja, dann fragt man sich, ob die zwanzig Dollar für so ein Gurken-Programm wirklich eine sinnvolle Ausgabe wären. Ich will’s jedenfalls nicht mal geschenkt haben.

MailForge-Fehlermeldung
(Aufs Bild klicken zum Vergrößern)

Weblication

Weblication ist ein kostenpflichtiges CMS (Content-Management-System) des deutschen Herstellers Scholl Communications AG. Ich habe Weblication® CMS CORE in der Version 8 als Demoversion kurz getestet.

Die Installation auf dem eigenen Webserver geht schnell und unkompliziert vonstatten. Sehr bedenklich finde ich die Tatsache, dass ein Benutzername admin mit dem Passwort admin standardmäßig angelegt wird. Besser wäre doch, gleich bei der Installation den Benutzer selbst einen Benutzernamen und ein Passwort eingeben zu lassen, wobei natürlich auch gleich auf eine gute Passwortstärke geprüft werden sollte. Immerhin wird darauf hingewiesen, dass man das Standard-Passwort sofort nach dem ersten Einloggen ändern sollte, und folgerichtig erscheint nach dem Anmelden ein entsprechender Hinweis. Und hier wird tatsächlich die Güte des Passworts geprüft.

Nach dem Einloggen ins Backend muss man zunächst ein Projekt anlegen. Auch das ist ungewöhnlich. Ich kenne es von vielen anderen Inhalts-Verwaltungs-Systemen so, dass man sofort nach der Installation eine Beispiel-Website mit einer Standard-Gestaltung vorfindet. Natürlich ist es legitim, andere Wege zu beschreiten. Nach dem Anlegen des Weblication-Projektes kommt man zu einer Art Baukasten, mit dem sich recht leicht Inhalte erstellen lassen. Wer fit ist, kann auch direkt von hier aus die Template- und CSS-Dateien bearbeiten.

Was mich stört, ist die Unübersichtlichkeit des Systems. Ständig öffnen sich neue Fenster (die zunächst durch meine Browser-Einstellungen blockiert wurden – klar, ich will ja schließlich Werbe-Popups blockieren). Außerdem wirkt die gesamte Verwaltungs-Oberfläche überladen und gestalterisch ziemlich altbacken auf mich. Systeme wie Concrete5 oder WordPress finde ich intuitiver bedienbar und sie machen mir einfach mehr Spaß. Zudem sind sie lizenzkostenfrei, was natürlich den Nachteil hat, dass man dort keinen Anspruch auf professionellen Support hat. Man »wurschtelt« sich bei Problemen also mehr oder weniger gut durch.

Ich muss gestehen: ich habe das Testen ziemlich schnell beendet. Sicherlich hat Weblication seine guten Seiten, und sicherlich sollte man ein geduldigerer Tester sein als ich es bin.

Das Unternehmen selbst macht allerdings einen sehr guten Eindruck auf mich. Auf Fragen und Hinweise wird sehr freundlich eingegangen. Daraus schließe ich, dass man als Anwender bestimmt einen guten Support geboten bekäme, falls man mal »stecken« bliebe. Nach eigenen Aussagen bietet Weblication® Echtzeit-Support direkt vom Hersteller. Das ist ein nicht zu unterschätzender Vorteil.

Weblication® CMS – Das Content-Management-System

Webfonts mittels .htacess-Datei beschleunigen

Die Geschwindigkeit eines Webauftrittes ist ein wichtiges Suchmaschinen-Kriterium, denn Suchmaschinen legen gerade das Wert, worauf auch Menschen Wert legen. Die Seiten sollen sich also möglichst verzögerungsarm aufbauen. Dass man zum Beispiel Bilder klein halten sollte, ist weitläufig bekannt. Wer sich näher mit der Thematik befasst, weiß auch, dass man die Anzahl der Anfragen an den Webserver begrenzen sollte, indem man zum Beispiel CSS- oder JavaScript-Dateien zu jeweils einer einzigen zusammenfasst.

Darüber hinaus gibt es noch die sehr effiziente Möglichkeit, die Daten für die Übertragung zu komprimieren, und zwar mit Gzip bzw. Deflate (Gzip ist ein Wrapper für den Deflate-Algorithmus), falls der Webserver dies unterstützt. So können zum Beispiel auch HTML-Quelltexte verkleinert werden. Nur hatte ich bisher nicht an die Webfonts gedacht – bis ein Online-Prüfprogramm, nämlich WebPagetest, mich darauf aufmerksam machte.

Und bei Page-Speed.net habe ich den Code gefunden, den man (falls die Website auf einem Apache-HTTP-Server läuft) in die Datei .htacess einfügt: Webfonts optimieren. Ich erlaube mir, den Quellcode von der genannten Webseite zu kopieren. Darüber hinaus wird dort ein Code gezeigt, der weitere Dateiformate mit abdeckt.

<IfModule mod_deflate.c>
<IfModule mod_mime.c>
Addtype font/opentype .otf
Addtype font/eot .eot
Addtype font/truetype .ttf
</IfModule>
AddOutputFilterByType DEFLATE font/opentype font/truetype font/eot
</IfModule>

Für andere HTTP-Server gibt es sicherlich adäquate Lösungen.