Blog von Webmastern für Webmaster
Nov 29th, 2009 by Redaktion
…wünsche ich allen Lesern! Die erste Kerze erinnert mich daran, dass es nicht mehr weit bis Weihnachten ist und somit noch einiges zu erledigen bleibt 
Aber nicht heute, erst einmal gibt es Stollen und Lebkuchen, auf das der Bauchumfang in den nächsten Wochen wachse…
Nov 28th, 2009 by Redaktion
Man kann ja zum Giganten stehen, wie man will, gute Ideen bringen sie auf jeden Fall hervor. So gab Google in seinem Webmaster-Blog bekannt, die Benachrichtigung zu neuen Software-Versionen zu erweitern und diese zum Beispiel auch auf entsprechende Plugins und Komponenten auszudehnen.
Der Webmaster muss dazu ein Konto bei Google Webmaster-Tools anmelden und erhält dann dort die entsprechende Benachrichtigung, wenn sein WordPress, Joomla oder eine andere Webanwendung nicht mehr up2date ist.
Dies gilt auch zum Beispiel für Drupal-Module oder Joomla-Erweiterungen.
In meinen Augen eine sehr coole Sache, gerade für Webmaster, die sonst eher zögerlich einen Blick auf Versions-Updates verwerfen. Somit kann durchaus die Hoffnung bestehen, die Zahl potentiell gefährdeter Webseiten zu verringern.
Nov 27th, 2009 by Redaktion
Es geht doch nichts über einen gemütlichen Freitagnachmittag-Plausch. Heute mit dem Thema zu Kaffee und Stollen “Was ist sinnvoller bei ablehnenden Firewall-Regeln, ein REJECT oder ein DROP?”
Um es bereits vorwegzunehmen, es gibt wohl keine eindeutige Antwort, hier wird jeder Administrator nach eigenen Gutdünken entscheiden.
Bei Firewall-Regeln mit iptables können Pakete mit REJECT oder mit DROP abgelehnt werden. Während REJECT eine Meldung zurückgibt, werden die Pakete mit DROP ohne weiteren Kommentar in das virtuelle Nirvana verwiesen.
Meiner Meinung nach macht es keinen Sinn, einem Angreifer auch noch netterweise eine Meldung zukommen zu lassen. Andererseits kann eine Meldung eventuell weitere Anfragen verhindern, so das Gegenargument.
Das mag soweit stimmen, ich bezweifel aber, das bei einem DDOS-Angriff auf die Meldungen geachtet wird. Sollte man zum debuggen im Netzwerk immer noch aussagekräftige Meldungen benötigen, dann kann man die Regeln auch kurzzeitig auf ein REJECT setzen.
Aber wie bereits am Anfang beschrieben, das dürfte jeder nach seinen Bedürfnissen sehen. Eines sei klargestellt, Traffic spart man allerding mit einem DROP nicht, falls jemand jetzt auf die Idee kommt
Viel Spass beim spielen mit “brennenden Mauern”
Nov 21st, 2009 by Redaktion
Man mag es kaum glauben, dass man heute noch Artikel über Passwörter schreiben muss, aber leider ist dem so.
Ein Passwort soll für Sie einen geschützen Bereich absichern, zu dem nur Sie Zugang haben. Das so etwas natürlich die Begehrlichkeiten von anderen weckt, steht ausser Frage.
Sei es nun Ihr Internetzugang, Ihr Webaccount, Ihr Mailkonto oder auch Ihr Blog oder CMS, Fremde haben in diesen geschützten Bereichen nichts zu suchen. Von daher ist es wichtig, dass dieser mit einem entsprechend starken Passwort geschützt wird.
Was sind nun aber starke oder schwache Passwörter? Oftmals muss man ja zig Passwörter gleichzeitig verwalten und im Kopf behalten. Da ist es naheliegend, ein Passwort in der Form
1234567890
oder
qwertzuiop
oder
Liebling
zu wählen. Alle drei Passwörter sind schwache Passwörter. Sie bestehen nur aus Zahlen, nur aus Kleinbuchstaben oder nur aus einem bekannten Wort. Ein Angreifer setzt sich ja nicht hin und probiert per Hand einzeln Passwörter durch, sondern dies erledigt ein Skript für ihn. Für das erste Skript würde ein Leistungsstarker Computer heute bei 10-Stellen und ausschliesslich Zahlen ca. 15 Minuten benötigen, um das entsprechende Passwort zu berechnen. Beim zweiten Passwort würde dieser Vorgang bereits etwa 160 Tage dauern. Warum aber dieser Unterschied bei diesen beiden 10-stelligen Passwörtern?
Beim Zahlenpasswort (10 verschiedene Zeichen) ergeben sich 10.000.000.000 Kombinationen. Das Alphabet dagegen ist schon etwas umfangreicher (26 verschiedene Zeichen) und somit ergeben sich beim zweiten Passwort, welches ausschliesslich aus Kleinbuchstaben besteht, mögliche 141.167.095.653.376 Kombinationen.
Ist Ihr Passwort eventuell noch kürzer, dann verringern sich die Zeiten dramtisch zu Ihren Ungunsten, zum Beispiel ein 6-stelliges Zahlenpasswort wäre in einigen Sekunden mit einem modernen Rechner zu knacken.
Und das letzte Passwort besteht zwar aus Gross- und kleinbuchstaben, aber es ist ein reguläres Wort und da Passwortknacker auch mit entsprechenden Wortsammlungen bzw. ganzen Wörterbüchern in bestimmten Sprachen arbeiten wäre auch hier kaum ein nennenswertes Zeitfenster vorhanden. In der Regel umfassen diese Wörterbücher für Passwortknacker in etwa 300.000 bis 500.000 Wörter in einer Sprache. Verglichen damit würde ein Durchlauf nicht länger als einige Sekunden benötigen.
Bitte bedenken Sie aber, das wir hier von theoretischen Werten ausgehen, welche je nach Methode und Rechenleistung stark schwanken können! Ein heute handelsüblicher PC schafft mehrere Millionen Schlüssel pro Sekunde zu berechnen.
Was wäre dann aber ein starkes Passwort? Sie haben es sicher schon oft gelesen und vielleicht auch beachtet
Nehmen Sie ein Passwort, welches aus Gross- und Kleinbuchstaben, Zahlen und Sonderzeichen besteht. So bilden Gross- und Kleinbuchstaben sowie Zahlen bereits 62 verschiedene Zeichen. Nehmen wir jetzt noch Sonderzeichen wie * und # dazu, haben wir 64 verschiedene Zeichen. Unser Passwort lautet:
*HiEk09#
Unser erstes Passwort soll aus 8 Zeichen bestehen, also berechnen wir 64 hoch 8 Möglichkeiten:
64 x 64 x 64 x 64 x 64 x 64 x 64 x 64 = 281.474.976.710.656
Diese unglaubliche Anzahl an Kombinationen lassen wir nun von einem Rechner berechnen, der 10 Millionen Schlüssel pro Sekunde berechnen kann.
Ich runde jetzt etwas, um alle Kombinationen zu berechnen bräuchte der Rechner also 28.147.498 Sekunden. Das sind dann rund 469125 Minuten, aufgerundet 7819 Stunden, ca. 325 Tage.
Nehmen wir jetzt die gleiche Anzahl, also 10 Stellen wie oben in den Beispielen, dann ergibt das wieder mit 64 unterschiedlichen Zeichen 64 hoch 10
1.152.921.504.606.846.976 Möglichkeiten
Gleicher Rechner zum Passwort hacken mit 10 Millionen Schlüsseln pro Sekunde, so ergibt sich bei nur 2 Stellen Unterschied:
115.292.150.461 Sekunden oder
1.921.535.841 Minuten oder
32.025.597 Stunden oder
1.334.400 Tage oder
3656 Jahre
Die Werte sind gerundet.
Das sollte wohl ein Recht sicheres Passwort sein
Nun stellt sich die Frage, wie zum Teufel soll man sich denn solche kryptischen Passwörter merken? Meinen Sie jetzt zufällig das hier?
*HiEk09#
Das ist ganz einfach! Glauben Sie nicht? Schauen Sie einmal:
* Heute ist Es kalt 09 #
Na? Geht doch ganz einfach, oder? Unser kleiner Satz wird jetzt noch auf die 10 Stellen erweitert, Zuerst klammern wir ihn wieder mit unseren Sonderzeichen ein, dann kommt innen der Satz und die Jahreszahl 2-stellig:
* Heute ist Es kalt In Berlin 09 #
ergibt (Gross- und Kleinschreibung im Wechsel):
*HiEkIb09#
Voila! Da haben Sie ein Passwort, welches sehr stark ist. Wechseln Sie nun noch regelmässig Ihre Passwörter, dann haben Sie in diesem Bereich schon einmal gute Karten und sind auf der relativ sicheren Seite!
Viel Spass beim Passwörter erfinden!
P.S. Haben sich Rechenfehler eingeschlichen, einfach kurz eine Info
Nov 15th, 2009 by Redaktion
Etwas verspätet, aber hier kommt die deutsche WordPress-Version als APS-Paket für 1-Klick bzw. Plesk-Application Installationen.
Bei Fehlern oder Problemen einfach eine kurze Info! Ansonsten viel Spass mit dem neuen Paket
WordPress 2.8.6-1 DE APS (2.8 MiB)
Nov 14th, 2009 by Redaktion
Die neue WordPress-Version behebt zwei mögliche Sicherheitsprobleme, die durch registrierte User ausgenutzt werden können.
Zum einen handelt es sich im eine XSS-Lücke und zum anderen um ein Problem, das bei bestimmten Apache Konfigurationen Code ausgeführt werden kann, wenn die Datei als Bild “versteckt” wird (z.B. test.php.jpg).
Ein Update ist dringend zu empfehlen. Wordpress-Deutschland stellt die neue Version sowohl als Update- als auch als Komplettpaket zur Verfügung.
Ich werde im Laufe des Abends ein neues Paket als APS bereitstellen.
Nov 6th, 2009 by Redaktion
In seinem Blog veröffentlicht Sascha einen Artikel, der sich mit der Frage der Haftung bei Störung des normalen Betriebes eines Servers anhand einer eigenen php.ini beschäftigt.
Ansich stimme ich mit der Kernaussage des Artikels überein, aber auch nur im Kern. Der Punkt, ein Provider würde
…den eigenen Kopf bei Haftungsfragen aus der Schlinge zu ziehen oder um zumindest einen Teil der Kosten auf den eigenen Kunden zu übertragen…
stimmt so einfach nicht. Nehmen wir einmal ein Beispiel. Hoste ich meine Seite bei einem grossen deutschen Anbieter, dann bin ich von Haus aus schon Restriktionen bei bestimmten PHP-Funktionen (shell_exec usw.) und anderen Einstellungen unterworfen. Warum dies?
Die Erklärung für mich als Kunde ist relativ einleuchtend. Auf einem Shared-Hosting System liegen teilweise mehrere hundert Kunden. Zum einen hat der Provider die Sicherheit des Servers nach aussen als auch nach innen zu sichern, zum anderen hat er dafür Sorge zu tragen, dass die Webseiten seiner Kunden erreichbar sind.
Nehmen wir jetzt einmal das Beispiel einer WordPress-Installation und dort die Option, Feeds einzulesen. Oftmals werden gerade bei solchen Aktionen hunderte von Feeds gleichzeitig eingelesen. Eine Auslastung bis zum maximalen der zulässigen MySQL-Verbindungen ist die Folge. Die Fehlermeldung “Too many connections” wird nicht lange auf sich warten lassen.
In einem solchen Fall gibt es dann die Möglichkeit, die Prozesse des einzelnen Users zu limitieren oder aber das entsprechende Webpaket zu deaktivieren. Beide Varianten sind nicht toll, bei limitierten Prozessen erhält der User eine Fehlermeldung, bei gesperrten Webpaket hat der User keinen Zugriff mehr und in beiden Fällen ist die Webseite nicht mehr erreichbar.
Und noch ein anderes Beispiel, auch aus der Praxis. Drei Domains eines Kunden werden Ziel einer geballten DDOS-Attacke. Das ganze über ein Botnetz von mehreren 10.000 unterschiedlichen IP-Adressen. Insoweit unproblematisch, dazu gibt es Firewallfilter, aber die Wucht des Angriffes nimmt soviel Bandbreite in Anspruch, dass kaum andere Webserver in diesem Netz erreichbar sind. Erst mit der Hilfe und Umstellungen im Rechenzentrum gelingt es nach ca. 1 Stunde, den Angriff auszubremsen.
Solche Störungen sind aber gerade für andere Kunden auf dem Server genauso problematisch, denn auch diese “leiden” unter solchen einzelnen Usern. Die Folge dürfte klar sein, Kündigungen, schlechtes Image usw.
Es entstehen also auch direkte finanzielle Schäden beim Anbieter selbst. Warum sollte diese nicht die Möglichkeit einer Haftung haben? Und wenn man ehrlich ist, man muss eigentlich nur die AGBs der einschlägigen Provider lesen, alle haben irgendwo einen solchen Passus in den selbigen.
Die Frage, die im Raum bleibt, nimmt der Provider wirklichen einen Kunden in Haftung?
Mir persönlich ist kein Fall bekannt, in dem dies so wäre, auch wenn es die Möglichkeit dazu gibt. Was mir bekannt ist, dass aufgrund solcher Probleme und Störungen Kunden für entstandenen Mehrtraffik aufkommen mussten, gerade wenn es sich um “uralt” Skripte handelt, denen die entsprechenden Sicherheitsupdates fehlen. Aber in diesen Fall bekommt der Begriff “Lehrgeld” eine ganz konkrete Bedeutung
Wie kann ich nun also eine solche Haftung umgehen? Eine ganz simple Antwort darauf ist, zu wissen was man tut. Wenn ich Scripte installiere und einsetze, dann sollten diese up2date sein. Wenn ich an der Konfiguration schraube, dann sollte ich über das entsprechende Hintergrundwissen verfügen.
Oftmals, wenn auch nicht immer, ist es hilfreich, vorher solche Anwendungen oder Konfigurationen auf einem lokalen System zu testen.
Im einfachsten Fall hilft eine Anfrage an den Provider selber, gerade viele kleine Provider werden hier helfend auf ihre Kunden eingehen und sicher auch die eine oder andere Option individuell für einen Kunden aktivieren bzw. in der Konfiguration anpassen.
Nov 5th, 2009 by Redaktion
Tools zum administrieren der eigenen Datenbanken gibt es einige. Wenn man einen eigenen Server hat bzw. über Shell-Zugriff verfügt, dann kann man Datenbanken schnell und einfach per Kommandozeile sichern und wieder einspielen.
Dazu wechseln Sie in Ihr MySQL Verzeichnis (meist unter /var/lib/mysql) und geben zum sichern folgendes Kommando ein:
mysqldump -u root -p datenbankname > datenbankname.sql
Sie werden aufgefordert, Ihr Passwort, in diesem Fall für root, einzugeben. Fertig, der Server wird den Auftrag abarbeiten und Ihnen die Sicherung erstellen.
Zurückspielen können Sie die Datenbank dann ganz einfach mit
mysql-u root -p datenbankname < datenbankname.sql
Das war es schon
Nov 4th, 2009 by Redaktion
Die Meldung ist zwar schon einige Tage alt, aber leider komme ich erst heute dazu, mal wieder ausgiebig die einschlägigen “Quellen” zu studieren
Eine feine Sache haben sich die Entwickler von WordPress ausgedacht. Im Pluginverzeichniss gibt es eine weitere Option, dies zeigt, ob ein Plugin in der ausgewählten Version funktioniert. Dazu geben die Nutzer einfach an, ob es läuft oder nicht.
Später soll eventuell diese Option direkt im Adminbereich erscheinen, in meinen Augen eine absolut feine Sache und ein grosser Gewinn für die WordPress-Gemeinde! Allerdings ist eine Anmeldung fällig, was nicht die grösste Hürde sein dürfte
P.S. Was hat meine Lehrerin immer gesagt? “Du sollst immer alles lesen, bevor du anfängst zu schreiben!” Kluge Frau und ich hab es auch 20 Jahre später noch nicht gelernt Auch Wordpress-Deutschland hat einen entsprechenden deutschen Artikel dazu, have fun!
Nov 3rd, 2009 by Redaktion
Die Schlagzeilen um den Quelle-Konzern sind in den letzten Tagen hinreichend durch die Medien gegangen. Der Ausverkauf ist aber zumindestens für Internetnutzer zum Glücksspiel geworden.
Mittlerweile gibt es wenigstens eine Vorschaltseite
Und mal ganz ehrlich, wenn wir uns doch alle über Besucher auf unseren Webseiten freuen, soviele wollte ich dann auch nicht haben Wäre mal interessant zu wissen, was ein Werbebanner auf einer solchen Vorschaltseite bringen würde 
