Google SEO Bildersuche am Beispiel des Kommutators

Am Sonntag 10. Juni 2007 hatte ich das Foto eines Kommutators eingestellt, um zum einen das Wesen von Produktfotos etwas zu erklären als auch das Bild für Suchmaschinenoptimierung (seo) zu verwenden. Damals war alles noch nicht so klar wie heute, vieles musste erst durch eigene Tests herausgefunden werden, was die Suchmaschinen, insbesondere Google, so treiben (Man erinnere sich noch an den Wettstreit um „Grüne Tomaten„, bei dem einige Suchmaschinenoptimierer damals mitgemacht hatten). Zu der Zeit im Jahre 2007 war den meisten Web-Menschen noch nicht so klar wie heute (?), dass sie ihre Bilder im Web mit sinnvollen Namen benennen sollen und nicht einfach von der Kamera hochladen.
Sie verschenken wertvolle Suchtreffer.
Nun denn, ich hatte also vor noch längerer Zeit ein Foto eines Kommutators gemacht, der zum einen tiefschwarzen Kunststoff enthält als auch hochglänzendes Kupfer, das jedes Licht reflektieren würde.
Für eine Consumer-Digitalkamera zu der Zeit damals eine hohe Herausforderung, aber nicht für mich, da ich im Optiklabor damals ständig damit zu tun hatte.
Ich gebe zu, ich hatte einen aufwändigen Aufbau hingestellt, um die Lichtspiegelungen auszuschalten, aber wie gesagt, das war damals mein Job (Dunkelfeld, Hellfeld, Diffusor).
Schatten ließen sich trotzdem nicht ganz vermeiden, darum musste ich dennoch den abgebildeten Kommutator noch ausschneiden (wer errät, wie?).

So sieht das Kommutator-Bild nun seit vielen Jahren aus:

Kommutator

Kommutator als Beispiel für SEO in der Bildersuche.

Was aber hat das mit SEO zu tun?

Nun, das Foto hatte ich bewusst kommutator.jpg genannt, weil es einen solchen darstellte und zugleich in der damals noch von Vielen vernachlässigten Bildersuche bei dem Suchbegriff „Kommutator“ auftauchen sollte. So mein Gedanke.
Ja, und was soll ich sagen?
Google hat doch tatsächlich jahrelang mein Kommutatorbild als erstes Bild in den Suchergebnisseiten (SERPS) angezeigt.
Bei der Bildersuche war es meistens auf Platz 1, sogar Wikipedia und manch technische Erklärungsseite konnte dagegen abstinken, später sank es etwas nach unten.
Fein war auch, ich musste kaum etwas tun, sondern einfach nur die Zeit arbeiten lassen, weil Zeit auch für einen arbeitet. Google schien darauf zu vertrauen, dass wenn das Bild schon so lange da stand, es wohl auch so stimmen müsse, dass hier ein Kommutator zu finden sei.
Sicher, manche Besucher landeten auf meinem Blog in der Hoffnung, eine technische Erklärung zu einem Kommutator zu finden oder gar das Produkt selbst. Leider nein, obwohl ich hätte prinzipiell beides gekonnt haben können, dank meiner Elektrotechnischen Ausbildung und meines Diplom Ingenieur Titels, hätte ich wollen.
Aber: Nur Foto, nicht anfassen.

Das hat sich eines Tages geändert, wie ich feststellen musste, weil bis dahin habe ich dieses Kommutator-Foto gerne als Beispiel genommen, wie effektiv sprechende Dateinamen für die Optimierung bei der Bildersuche sind. Diesesmal war das anders, denn mit meinem Foto (!) wurde eine andere Seite verlinkt.
Ja, ich war raus und ein anderer drin.

Wie das?
Das exakt gleiche Foto in der gleichen Größe steht nun (Stand jetzt ) auf einer anderen Webseite und wird von Google wohl schon seither verlinkt bei der Suche nach „Kommutator“, anstelle von meinem schönen Bild.
Zum einen frage ich mich, warum macht der andere Seitenbetreiber das? Nur weil er Hersteller von Kommutatoren ist, hat er das Recht, mein Foto zu nehmen?
Oder war es ein Suchmaschinenoptimierer, der meine Seite gelesen hat und gedacht, da nimmt er gleich das Original?

Aber zum anderen Frage ich mich, warum macht Google das?
Weiß Google nicht, dass meine Seite und mein Foto erheblich älter ist das das was Oma Google nun neu verlinkt?
Gab es da nicht mal was mit doppeltem Content und so?
Wie funktioniert hier die sogenannte KI von Google, dass sie vom Ursprung des Bildes auf eine Kopie wechselt?
Ist es darum, weil auf der anderen Seite mehrere Kommutatoren abgebildet sind und bei mir nur dieser einer?
Würde Google dann auch eher auf eine Raubmordkopiererseite verlinken, weil dort z.B. mehr Blockbuster-Filme zu finden sind als auf der Urheberseite?
Ist es also so leicht, jemandem den guten Platz bei der Suche zu klauen, indem man ein Bild oder Text kopiert?
Wollte nicht Google genau dagegen vorgehen und seine KI verbessern?
Irgendwie erinnert mich das etwas an Schwarzhut-SEO.

Tatsache bleibt, richtige Benennung der Dateinamen wirkt, ob so oder so.
Darum habe ich mein Kommutatorfoto einfach kommutator.jpg genannt.
Mal sehen, wie Google darauf ragiert.
Denn eigentlich belohnen die doch obengenanntes nicht?

Wer helfen will, dass ich meinen Platz bei Oma Google wieder bekomme, kann gerne auf meine Seite mit „Kommutator“ verlinken.
Ein bisschen enttäuscht hat mich Google schon.

Veröffentlicht in Fotografien, Suchmaschinen und SEO | Getaggt , , | Hinterlasse einen Kommentar

Ruhig Blut bei Updates

Neulich war es soweit, ein Update von WordPress mit fatalen Folgen für den einen oder anderen.
Das Gute ist des Besseren Feind, heißt ein Sprichwort, aber neu ist nicht automatisch besser oder gut.
Abgesehen von einigen Wenigen die ständig die neuesten Versionen testen müssen, gibt es für die Meisten wohl keinen Grund, gleich die neueste Version zu installieren. Denn genau genommen betätigt man sich damit als Betatester, wie auch im oben angemerkten Fall.
Und gerade bei Kundenprojekten kann man es sich eigentlich nicht leisten, ohne einen gewissen Abstand die Seiten der Kunden gleich auf die neueste Version upzudaten [schönes Wort]. Erfahrene Admins warten immer, bis sich eventuelle erste Fehler zeigen und diese ausgeräumt sind.

Das ist ein wenig so wie mit den Aktien, bei denen man die Füße still halten muss, wenn sie mal rauf und runter gehen.
Und WordPress hat das zudem schön eingerichtet mit den Sicherheitsupdates, die im Hintergrund automatisch laufen und auch etwas ältere Versionen versorgt. Zur Not greift man manuell ein und löscht, wie in diesem Fall, die benannte Datei aus dem Theme.

Inzwischen ist es so weit, dem WordPress Team kann man dabei vertrauen, gibt es nach sehr kurzer Zeit ein neues Update bei dem alle Fehler bereinigt sind und die Probleme nicht mehr auftauchen [zumindest bei mir nicht].
„Ruhig Blut bei Updates“ half auch hier, sich viel Arbeit und Nervengeld zu ersparen.

Veröffentlicht in CMS | Getaggt | Kommentare deaktiviert für Ruhig Blut bei Updates

Tipps für sichere Usernamen in WordPress

Seit einiger Zeit werden WordPress-Seiten zum Teil sehr massiv mit Brute-Force Methoden angegriffen, um das Passwort „zu erraten“ für den Admin oder andere User.
Meistens laufen die Angriffe auf „admin“, weil das der erfolgversprechendste User in WordPress Installationen ist, denn erstens war „admin“ früher fest als Administrator-Login vorgeschrieben und zweitens handelt es sich dabei um einen User mit Administrator-Rechten (kann auch PHP-Dateien intern editieren, für Einbrecher also sehr interessant und bösen Code einzubauen) und drittens lassen auch viele den „admin“ als User stehen, obwohl WordPress seit einiger Zeit den Admin-Login bei der Installation frei ändern lässt.
Später kann man den Usernamen (Login-Name) nicht mehr ändern.

Das Problem mit dem Standard-Admin:

Es gibt immer wieder zu lesen, dass man doch bitte aus Sicherheitsgründen nicht mehr „admin“ oder „Admin“ also ersten Usernamen nehmen solle, sondern etwas anderes.
Für andere CMS mag das ja einen Sicherheitsgewinn ausmachen, aber nicht für WordPress, denn die Entwickler haben sich gedacht, man könne sich doch den Usernamen über das Web anzeigen lassen mit diesem Link: http://www.123-blog.de/?author=1

/?author=1 zeigt den URL-tauglichen Usernamen des Nutzers mit der ID=1 an, also immer der User, der bei der Installation als erstes eingetragen wird, nämlich der Administrator mit allen Rechten.
Man kann das Spielchen so fort führen indem man einfach alle Nummer durchprobiert und schaut, ob Antworten kommen, und tatsächlich fand ich in den Logfiles die Anfragen mit allen Nummern bis 99 durch die Angriffs-Programme (die Angreifer sind meistens automatische Programme).

Die Antwort vom WordPress-Programm sieht dann z.B. so aus: http://www.123-blog.de/author/admin
Juchhu„, sagt sich das Angriffsprogramm, „ich hab den Usernamen!“ und tatsächlich stimmt es in den meisten Fällen auch, weil der Standard-Username eben „admin“ lautet.

Es mag durchaus Sinn gehabt haben, warum man so einfach den Login-Namen herausfinden kann, denn als WordPress noch jung war, war von solchen Angriffen wie sie heute statt finden, kaum die Rede und WordPress wollte vielleicht eine einfach Möglichkeit bieten, wie man automatisch den Autor herausfinden und auf alle Beiträge dieses Autors verlinken kann.
Inzwischen aber haben sich die Möglichkeiten für die Angreifer erheblich verbessert, dank der schnellen Datenleitungen und Server können die Angreifer tatsächlich einfach alle möglichen und unmöglichen Passwörter durchtesten beim Loginversuch mit dem User „admin“.
Steter Tropfen höhlt den Stein und irgendwann passt vielleicht zufällig ein Passwort und schon ist eine weitere WordPress-Seite gehackt, ganz automatisch und ohne Mühe für den Angreifer.

Der oft gelesene Ratschlag, den „admin“ zu löschen und einen neuen User einzutragen oder bei der Installation einen anderen Namen zu wählen, nützt meistens nichts. Warum?
Weil WordPress automatisch den gewählten Usernamen nimmt und daraus einen URL-tauglichen Namen erzeugt und in die Datenbank speichert. Somit kann das Angriffs-Programm ganz einfach mit dem Author-Link (der mit dem Fragezeichen) den Usernamen wieder heraus finden. Damit ist nicht wirklich viel gewonnen und man wägt sich in trügerischer Sicherheit.

Aber es gibt Unterschiede, die man nutzen kann:

Da WordPress einen URL-tauglichen Namen generiert, dürfen darin keine Sonderzeichen und keine Umlaute vorkommen. So könnte man doch auf den Gedanken kommen, den Usernamen „ädmin“ statt „admin“ zu wählen, mit einem ä am Anfang. Aber WordPress lässt für die Wahl des Usernamen keine solche Sonderzeichen zu, wir ahnen warum (soll ja URL-tauglich werden und hat vielleicht noch historische Gründe und wegen lokaler Unterschiede in der Tastatur usw.) Es wäre zu schön gewesen, hätte WordPress aus dem „ädmin“ einfach ein „admin“ gemacht. Auch z.B. ein # im Namen wird nicht akzeptiert.

Es gibt aber noch mehr, was man ausnützen kann, denn Großbuchstaben werden klein gemacht und Leerzeichen werden mit einem Bindestrich versehen. An dieser Stelle sei vermerkt, dass ein Leerzeichen im Usernamen alleine keine besondere Sicherheit darstellt, weil es für Programmierer leicht ist, beim Antreffen eines Bindestriches auf ein Leerzeichen im Login-Namen zu schließen und das entsprechend zu programmieren.
Aber eine Kombination aus beidem könnte doch deutlich mehr Sicherheit bringen:

  • KlausMaus wird zu klausmaus
  • Klaus Maus wird zu klaus-maus
  • klauS MauS wird auch zu klaus-maus

Wir sehen hier, dass man mit der Kombination von Groß- und Kleinschreibung an verschiedenen Stellen (und vielleicht noch mit Leerzeichen) durchaus einiges zu Rätseln für das Angriffs-Programm aufgibt. Alleine das zu knacken könnte schon dauern, je nachdem wie verschachtelt man das schreibt: KlaUsmAuS-zUhauS und das Angreifer-Programm dürfte alle möglichen Kombinationen durchprobieren müssen, bis der richtige Login-Name mal getroffen wäre.

Und nun stelle man sich das noch in Kombination mit einem langen und sicheren Passwort vor, mit Sonderzeichen, Zahlen, Groß-Kleinschrift. Das dürfte eigentlich kaum noch zu knacken sein, es sind vermutlich zu viele Kombinationen.
Das muss man dann aber für alle User so durchführen, denn es werden auch die anderen User gefunden und darauf angegriffen.

Und dann bitte nicht für den „Angezeigten Namen“ (display name) den original Login-Namen stehen lassen!! Sonst war alles umsonst.

Es geht aber noch besser:

(auf eigenes Risiko* für Datenbankversierte User)

Wer meinen Link oben ausprobiert hat, wird sehen, dass tatsächlich „admin“ angezeigt wird.
Bin ich etwa so leichtsinnig, und habe als Usernamen nur admin oder Admin gewählt?
Nein, bin ich nicht, es ist ein Honeypot (Honigtopf), extra für die lieben, dummen Angriffsprogramme so stehen gelassen.
Einem so leckeren Honigtopf können diese Programme gar nicht widerstehen, sind sie doch vornehmlich auf „admin“ getrimmt.
Was habe ich gemacht?

In der Datenbank gibt es in der Tabelle wp_users (man sollte hier durchaus bei der Installation auch einen anderen Präfix wählen statt „wp“) zweierlei Spalten für Login-Name und eben diese URL-taugliche Version.
In der Spalte user_login steht der tatsächliche Login-Name (Username) und in der Spalte user_nicename steht eben dieser URL-taugliche Name. Den trägt WordPress automatisch ein und den kann man nicht vom Backend aus ändern.
An dieser Stelle noch die Anmerkung: user_nicename ist nicht der Nickname, auch wenn es sich ähnlich liest, es ist eher ein Alias-Name für technische Dinge wie eben die URL.
Da WordPress seit einiger Zeit es ermöglicht, einen Nicknamen einzutragen, könnte man das miteinander verwechseln.
Aber zum einen taucht der Nickname, den man selbst wählen kann, gar nicht in dieser Tabelle auf, sondern in der Tabelle wp_usermeta.  Und zum anderen kann man diesen Namen mit Sonderzeichen und Umlauten verwenden.
Merke: user_nicename ist nicht Nickname.

Nun, da WordPress mir nicht ermöglicht, den user_nicename zu ändern, mache ich es einfach über die Datenbank, aber anders herum.

  1. Ich installiere WordPress mit Usernamen „admin“.
  2. Nach der Installation gehe ich in die Datenbank, und ändere direkt in der Tabelle den Usernamen in user_login (nicht den user_nicename) von „admin“ auf irgendwas anderes (was ich garantiert nicht verrate), ohne Sonderzeichen oder Umlaute.
  3. fertig

Das war’s, mehr ist nicht.
Kann man auch jederzeit nachträglich machen.
Für die dummen Angriffsprogramme bleibt der angezeigt Autor weiterhin „admin“ (was ungemein verlockend ist).
Wordpress scheint trotzdem ganz gut zu funktionieren, obwohl diese beiden Namen ganz unterschiedlich sind.
Und ich logge mich dann unter dem neuen Namen ein statt mit admin, und es funktioniert prächtig,
* (hoffentlich ändert das WordPress nicht irgendwann mal, aus „Sicherheitsgründen“ womöglich, denn dann könnte es schwer werden, sich noch einzuloggen).

Tatsächlich laufen bei mir immer noch täglich sehr viele Angriffe auf den Namen „admin“, aber die Chancen sind gleich Null, weil es einen „admin“ als User eben darum nicht gibt.
So oft ich auch die Login-Fehlversuchs-Statistik ansehe, es lautet fast immer auf „admin“. Tja, mit Honig fängt man nicht nur Fliegen, sondern auch Angriffs-Programme.
Um die Angriffe nicht ins Uferlose treiben zu lassen, habe ich zusätzlich noch ein Plugin installiert, das fehlerhafte Loginversuche begrenzt und eine Zeit lang sperrt. Trotzdem kommen noch täglich 20 bis 100 Sperrungsmeldungen (die Loginversuche sind also viel mehr).

Hatte ich schon erwähnt, dass das Passwort natürlich trotzdem sicher sein sollte?

Um die lästigen Loginversuche abzuwenden, könnte ich auch einfach noch das Admin-Verzeichnis mit Usernamen und Passwort sichern, mittels .htpasswd zum Beispiel. Dann müsste ich mich zwar immer zweimal einloggen um ins Backend zu kommen aber dafür kämen die Angreifer erst gar nicht mehr zum Login-Bereich. Das sei jedem geraten, der seine Seite sicherer haben will.
Ich tue es nur nicht, weil ich auf dem Laufenden sein will, was sich da so tut.

Veröffentlicht in Allgemein, Wordpress anpassen | Getaggt | 4 Kommentare

Was tun gegen die vielen Angriffe auf WordPress-Seiten?

Die Angriffe auf meinen Blog hier reißen nicht ab. Inzwischen nicht mehr nur am Wochenende, sondern jeden Tag die gleiche Leier. Anderen geht es aber auch so ähnlich, wie hier zu lesen ist: http://www.tagseoblog.de/hacker-angriff-auf-tagseoblog-und-was-ich-dabei-gelernt-habe
Inzwischen leite ich alle Benachrichtigungen (per Email) von Angriffen direkt in meinen Junkmail-Ordner. Die Löscherei ging mir auf die Nerven, aber ganz auf die Info was gerade läuft, wollte ich auch nicht verzichten.

Sergej Müller hat inzwischen einen aktuellen Artikel verfasst, was man gegen Angriffe auf die XML-RPC Schnittstelle von WordPress tun kann: http://cup.wpcoder.de/wordpress-xmlrpc-schutz/

Viele wissen vermutlich gar nicht, dass es diese Schnittstelle gibt und noch weniger, wie man sie abschalten könnte. Die Anleitungen von Sergej sind denn auch nicht für Laien gedacht und nicht jeder kann oder darf .htaccess Dateien einbinden. Manche schließen den Rest der Welt vielleicht aus und wundern sich über zu wenig Besuch. Interessant wäre hier vielleicht ein Plugin, das Angriffe auf diese Schnittstelle blockieren könnte.

Hier hat sich auch jemand ganz aktuell Gedanken über die Sicherheit bei WordPress-Seiten gemacht: http://www.netz-gaenger.de/blog/wordpress-tutorials/wordpress-security-masnahmen-erweitern

Man kann mit dieser Anleitung sicher einiges für die Sicherheit seines Blogs tun aber der Autor selbst hat schon erkannt, dass es auch Nachteile gibt.
Nämlich die, dass man zum Arbeiten wieder einiges ausschalten muss.
Das hört sich im ersten Moment noch nicht so wild an, aber tatsächlich blockieren die Sicherheitseinstellungen die Arbeit mit einer Webseite. Wenn man nicht nur eine Seite hat, sondern viele, und alle sind richtig aufwändig abgesichert, dann wird man irgendwann die Seite nicht mehr anrühren, weder etwas schreiben noch daran was ändern, weil es schlicht zu umständlich und aufwändig wurde.

Ich spüre die Umstände schon bei Hostern, die Besitzrechte des wwwrun oder phprun nicht mit dem User des Accounts gleichgeschaltet haben und man bei jeder winzigen Änderung per FTP an Dateien die Besitzrechte umschalten darf und nicht vergessen, wieder zurück schalten, sonst geht vieles WordPress nicht mehr, wie Updates und so. Da man sich dazu bei diesen Hostern einloggen muss, um die Besitzrechte zu schalten und jedesmal Gedenkminuten warten muss bis alles auf dem Server umgesetzt wurde, überlegt man es sich schon zweimal, ob man „wirklich“ etwas verändern muss oder ob es noch warten kann, bis sich genug angesammelt hat.
Schlimmer noch bei abgesicherten Rechenzentren mit zeitlich limmitiertem Account, einzig VPS Zugang zur Datenbank und WebDAV zum Webspace. Da überlegt man es sich seeeehr lange, ob man etwas machen muss.

Die Spontanität geht verloren.
Ohne Zweifel, man kann manches an Sicherheit gewinnen, aber man portiert sich intuitiv wieder zurück in die Steinzeit des WEB, zu rein statischen Seiten die einmal im Jahr eine Änderung erfahren.
Wo liegt die goldene Mitte?
Und auf WordPress zu verzichten ist auch eher unwahrscheinlich.

Veröffentlicht in Allgemein, Wordpress anpassen | Getaggt , , | Hinterlasse einen Kommentar

Brute Force Hacking auf WordPress

Nun heute auch bei mir, bei meinem unbedeutenden kleinen Blog gab es heute den ersten von mir bemerkten Ausfall wegen zu vieler Zugriffe auf die Seite.
Wer hätte das gedacht?

Da nützt es wenig, wenn man den Blog eigentlich abgesichert hat und aber doch so viele Zugriffe statt fanden, dass er nicht erreichbar war. Obwohl, bei Apache-Servern braucht es da manchmal nicht besonders viele gleichzeitige Zugriffe. Vielleicht sollte ich angesichts der gehäuften Hacking Angriffe auf WordPress-Blogs in letzter Zeit, auf ligthtpd oder nginx umsetzen? Dann liefe vielleicht wenigstens der Blog noch, während sich die Angriffe abmühen, das Passwort heraus zu finden. Aber so wichtig ist mein Blog auch nicht, als dass es auffallen würde, wenn er mal für ein paar Stunden nicht erreichbar wäre.

Doch heute habe ich sie mal life erwischt beim Brute-Forcen.  Dank eines Plugins das häufigere ungültige Anmeldeversuche sperrt und protokolliert, bekam ich seit gestern Abend schon wieder häufiger Mail-Nachrichten über diese ungültigen Anmeldeversuche. Und als ich mal nachschauen wollte, ob der Blog noch läuft, konnte er tatsächlich nicht mehr erreicht werden weil er oder der Web-Server meines Hosters überlastet war. Es betraf aber nur die HTTP Web-Ausgabe, denn die Datenbank und der Webspace per FTP waren noch erreichbar.

Also machte ich einfach mal den Laden dicht, indem ich eine index.html hoch ludt und die Verzeichnisse des Blogs umbenannten und die User in der Datenbank verändert hatte.
Dann liefen zwar immer noch die Anfragen an wp-admin ein aber das Verzeichnis gab es dann nicht mehr, und 404 lässt sich vom Server schneller ausgeben als dass WordPress zuerst prüft, ob es den User gibt und ob das Passwort stimmt und ob es einer der vielen Hackingversuche wäre. Ausserdem hatte ich gerade nicht mehr Zeit, schließlich ist Wochenende (…und das wissen die Angreifer auch).
Trotzdem, so hatte ich für eine Zeit lang meine Ruhe und Angriffe liefen völlig nutzlos ins Nirvana.

Natürlich ist es von Vorteil, wenn man nicht mehr den Standardnamen „admin“ als Benutzer hat, aber sicher darf man sich dessen trotzdem nicht sein, denn in der Protokoll-Liste stehen noch einige andere Namen mit denen versucht wird, in WordPress einzudringen. Und man weiß ja, steter Tropfen höhlt den Stein und selbst wenn man einen Login-Blocker drin hat, so gibt es je IP immer einige Anmeldeversuche bis gesperrt wird. Man möchte ja selbst nicht für Stunden oder Tage ausgesperrt werden, nur weil man sich mal vertippt hat (und das geht schneller als man denkt).
Wie in manchen Berichten zu lesen war, hatten die Angreifer am letzten Wochenende bis zu 90.000 verschiedene IPs mit denen sie angreifen konnten. Multipliziert man dann die erlaubten Versuche damit, ergibt sich ein ordentliches Sümmchen an Usernamen und Passwörtern in kurzer Zeit, die die Hacker-Maschine (ja, Maschine, denn da hockt kein Hacker hintendran sondern da läuft eine Software) ausprobieren kann bevor sie alle gesperrt wurden. Es ist wie Lotto spielen, irgendwann könnte ein Treffer dabei sein, auch wenn es unwahrscheinlich ist.
Man probiert es eben mit Gewalt und Masse, darum Brute Force.

Solange man nicht wirklich gehackt wurde, ist es eher unterhaltsam anzusehen aber auf die Dauer kann das auch nerven. Denn was ist, wenn die Angriffe immer mehr werden? Es kämen ja durch Erfolge beim Hacken immer neue IPs dazu und es würde sich wie ein Schneeball-System entwickeln bis gar nichts mehr geht?
Mal sehen wie sich das weiter entwickelt.

Jedenfalls ist nichts mit Freude über die hohe Besucherzahl (eigentlich nur viele Zugriffe von wenigen Besuchern) und die Liste der vergeblichen Anmeldeversuche wird immer länger.Denn wirklich stoppen kann ich die Brute-Force Angriffe mit all den mir zur Verfügung stehenden Mitteln nicht. Das ist wie eine Lawine und die HTTP 500 und 503 Meldungen häufen sich.
Aber eine gewisse Sichtbarkeit muss mein Blog dennoch im Internet haben, sonst wäre da nicht so viele Angriffe drauf. Muss ich mich nun geehrt fühlen, angesichts der Aufmerksamkeit?
Schaun wer mal.

Hier noch ein paar Links, wen’s interessiert,  zur weiteren Information:
http://blog.sucuri.net/2013/04/the-wordpress-brute-force-attack-timeline.html

http://playground.ebiene.de/adminbereich-in-wordpress-schuetzen/

http://wordpress-buch.bueltge.de/wordpress-sicherer-machen/30/

http://t3n.de/news/massive-angriffswelle-457424/

Veröffentlicht in Allgemein | Getaggt , | Hinterlasse einen Kommentar