Web­sites wer­den immer wie­der gehackt. Dies betrifft nicht nur die Inter­net­prä­sen­zen gro­ßer Fir­men, son­dern lei­der auch sol­che von Pri­vat­per­so­nen und Web­logs. Erst kürz­lich wurde berich­tet, dass eine kri­ti­sche Sicher­heits­lü­cke in der Kom­men­tar­funk­tion von Word­Press Mil­lio­nen von Blogs bedroht. Dazu kom­men täg­lich Ver­su­che, Kommentar- und Link-​Spam zu plat­zie­ren, sowie uner­wünschte Anmel­de­ver­su­che. Doch es gibt Mit­tel und Wege, sich dage­gen zu schützen!

Wer kennt das nicht als E-​Mail-​Nutzer: täg­lich Spam im Post­fach! Aber auch wer ein Web­log betreibt, kennt das: oft schlecht ver­fasste Kom­men­tare, die nur ein Ziel haben, näm­lich Wer­bung und Links auf kom­mer­zi­elle Sei­ten im WWW zu plat­zie­ren. Dies ist zwar höchst ärger­lich, aber noch rela­tiv unge­fähr­lich, es sei denn, man folgt einem sol­chen Ver­weis und gerät dabei auf Sei­ten mit schäd­li­chen Inhal­ten. Viele haben dage­gen Vor­keh­run­gen in Form von Spam-Fil­tern oder Plug-​ins (Erwei­te­run­gen) getrof­fen, die Spam-​Mails oder -Kom­men­tare in einen vir­tu­el­len Papier­korb beför­dern oder gar nicht erst zur Ver­öf­fent­li­chung freigeben.

Schlim­mer wird es, wenn gleich ver­sucht wird, ganze Web­sites oder Web­logs zu hacken. Dies betrifft nicht nur die Inter­net­prä­sen­zen gro­ßer Fir­men, son­dern lei­der auch sol­che von Pri­vat­per­so­nen. Kürz­lich schreck­ten meh­rere Mel­dun­gen über eine kri­ti­sche Sicher­heits­lü­cke in der Kom­men­tar­funk­tion von Word­Press, mit der die Kon­trolle über die Admi­nis­tra­to­ren­rechte über­nom­men wer­den kann, und über das „Spie­geln“ und Umlei­ten gan­zer Inhalte auf eine andere Top-​Level-​Domain beson­ders die Betrei­ber von Blogs.

Zudem ver­su­chen immer wie­der Leute, sich in das Web­log anzu­mel­den, um danach Inhalte ein­zu­stel­len, zu ver­än­dern oder gar zu löschen. Wer in sei­nem Content-​Management-​System ent­spre­chende Plug-​ins wie etwa Limit Login Attempts ein­setzt, erfährt dadurch, wie viele uner­wünschte Anmel­de­ver­su­che durch­ge­führt wer­den, und kann diese tem­po­rär sper­ren. Viele Bedro­her, denn um sol­che han­delt es sich, geben jedoch nicht auf, blei­ben hart­nä­ckig und ver­su­chen immer wie­der, sich erneut anzu­mel­den. Hier­ge­gen hilft nur, sich die IP-​Adressen (IP: Inter­net­pro­to­koll, im Fol­gen­den kurz IP genannt), die aus vier Zah­len­blö­cken bestehen, zu notie­ren, sich eine .htaccess-Datei zu erstel­len bzw. die vor­han­dene zu bear­bei­ten, diese IPs mit dem Ver­merk „Order deny“ in diese ein­zu­tra­gen und diese Datei (wie­der) auf den Ser­ver hoch­zu­la­den. Ver­sucht jemand mit einer die­ser IPs sich erneut anzu­mel­den oder nur auch die ent­spre­chende Web­site auf­zu­ru­fen, erhält er künf­tig die Feh­ler­mel­dung 403 mit dem Hin­weis, dass der Zugriff ver­wei­gert wurde. Eine genaue Anlei­tung zum Erstel­len bzw. Bear­bei­ten einer .htaccess-Datei gibt der Autor auf Anfrage in Form eines freund­li­chen Kom­men­tars gern, sol­che fin­den sich aller­dings auch im WWW!

Statt­des­sen hier eine Liste der vom Autor bis­lang gesperr­ten IPs und wie ein sol­cher Ein­trag in die .htac­cess aus­se­hen kann:

Order deny,allow
Deny from 37.57.200.107
Deny from 64.34.173.227
Deny from 80.54.28.35
Deny from 91.207.7.54
Deny from 103.9.100.191
Deny from 118.172.56.193
Deny from 119.6.144.70
Deny from 141.85.227.117
Deny from 144.76.219.151
Deny from 170.130.179.132
Deny from 177.0.157.151
Deny from 178.47.129.46
Deny from 183.223.82.165
Deny from 212.13.97.196
Deny from 212.82.217.9

Uner­wünschte Anmel­de­ver­su­che? Seit­dem der Autor diese IPs gesperrt hat, blieb er seit nun inzwi­schen meh­re­ren Wochen von sol­chen ver­schont! Sor­gen kön­nen aller­dings die hier frü­her häu­fi­gen, inzwi­schen spär­li­cher wer­den­den Ver­su­che machen, mit­tels der Erwei­te­rung CKE­di­tor (bis 2009 FCKe­di­tor) auf die Inhalte zuzu­grei­fen. Wem aber der WordPress-interne Edi­tor völ­lig aus­reicht und daher diese Erwei­te­rung nicht instal­liert hat, darf sehr hof­fen, dass sol­che Ver­su­che auch in Zukunft schei­tern wer­den, zumal häu­fig nicht das Content-​Management-​System selbst für Sicher­heits­lü­cken ver­ant­wort­lich ist, son­dern (nicht aktua­li­sierte) Erweiterungen!