Antibot-AI

Ist dir ein Fehler passiert oder mir?

Die­ser ers­te Text­ab­satz ver­schwin­det, sobald die­se Sei­te kom­plett fer­tig­ge­stellt wur­de. Solan­ge du den Text hier liest, ist der Bei­trag noch im Entstehungsprozess.

Hier ent­steht eine Hilf­e­sei­te für “Humans, Bots/Spiders/Crawlers”
Bit­te schaue gele­gent­lich hier vor­bei, wenn dich das The­ma interessiert!

Link: > > > Wei­te­re Infos zum The­ma fin­dest du hier < < < ^*

Es gibt drei Mög­lich­kei­ten wie du die­se Sei­te errei­chen kannst.

1. Du bist ein auto­ma­ti­scher Pro­zess (halt ein Bot, Crawler/Spider), dann bist du auto­ma­tisch außer­halb von Word­Press hier­her geschickt wor­den, weil du dem Link vom HTTP Error 400 oder 403 gefolgt bist.
2. Du bist ein Indi­vi­du­um, aber halt ein Hacker, und hast das­sel­be gemacht wie ein Bot, Crawler/Spider. Du bist dem HTTP Error Link manu­ell gefolgt.
3. Du bist ein gutes Indi­vi­du­um und bist inter­es­se­hal­ber hier.

Wenn du ein Hacker sein soll­test, dann lass es blei­ben. Es bringt nichts. Beschäf­ti­ge dich mit was Sinn­vol­lem. Oder schaue mal hier, ob dich das inter­es­sie­ren würde.

Ein Ein­falls­tor gibt es nicht.

Wenn du also durch einen HTTP Error hier­her gelangt bist, dann gehe mit höchs­ter Wahr­schein­lich­keit davon aus: Du hast was falsch gemacht! 

Lass es blei­ben oder schaue mal hier ! Beschäf­ti­ge dich mit was sinnvollem

Fehlercode 400

Feh­ler­hin­weis: HTTP 400 Error (Bad Request)

Kate­go­rie: Client-Fehler

Gehe pri­mär davon aus, dass du etwas falsch gemacht hast. Wenn eine ungül­ti­ge URL ein­ge­ben wur­de, kann die­se Feh­ler­mel­dung auf­tau­chen. Als ungül­tig gilt eine Inter­net­adres­se, wenn die ent­spre­chen­de Sei­te nicht exis­tiert, unzu­läs­si­ge Son­der­zei­chen ein­ge­fügt wur­den oder die Sei­te zwar exis­tiert, jedoch es kei­nen Grund gibt, dass du die­se Sei­te aufrufst. 

Die Haupt­ur­sa­che ist: Du hast ver­mut­lich ver­sucht unaut­ho­ri­sier­ten Zugrif­fe auf Res­soucen zu bekom­men. Zum Bei­spiel auto­ma­ti­siert als Bot oder manu­ell als Hacker.

Fehlercode 403

Feh­ler­hin­weis: HTTP 403 Error (For­bidden)

Kate­go­rie: Client-Fehler

Gehe pri­mär davon aus, dass du etwas falsch gemacht hast. Du hast ver­mut­lich kei­nen Zugriff auf die­se Ressource. 

Die Haupt­ur­sa­che ist: Hot­lin­king (auch bezeich­net als Inline Lin­king). Du hast ggf. das Ein­bet­ten von Medi­en (Bil­der, Sound, Vide­os. etc.) in eine Web­sei­te durch­ge­führt. Eine wei­te­re Ursa­che kann auch der uner­laub­te Zugriff auf exis­tie­ren­de oder nicht exis­tie­ren­de Datei­en sein. 

Es gibt drei Möglichkeiten

Es gibt drei Mög­lich­kei­ten wie du die­se Sei­te errei­chen kannst.

1. Du bist ein auto­ma­ti­scher Pro­zess (halt ein Bot, Crawler/Spider), dann bist du auto­ma­tisch außer­halb von Word­Press hier­her geschickt wor­den, weil du dem Link vom HTTP Error 400 oder 403 gefolgt bist.
2. Du bist ein Indi­vi­du­um, aber halt ein Hacker, und hast das­sel­be gemacht wie ein Bot, Crawler/Spider. Du bist dem HTTP Error Link manu­ell gefolgt.
3. Du bist ein gutes Indi­vi­du­um und bist inter­es­se­hal­ber hier.

Wenn du ein Hacker sein soll­test, dann lass es blei­ben. Es bringt nichts. Ein Ein­falls­tor gibt es nicht.

Wie Antibot-AI entstand 

Mei­ne Web­sei­te ist inner­halb eines Monats zwei­mal gehackt wor­den. Ich hat­te nur wenig Zeit, als ich das ers­te Mal damit kon­fron­tiert wur­de. Den ein Urlaub stand an, und ich hat­te wirk­lich wenig Zeit zur Behe­bung. Dann, kaum aus dem Urlaub zurück, fand ich wie­der Schad­soft­ware auf dem Server. 

Dies­mal nahm ich mir Zeit für die Ana­ly­se und für die Ursa­chen­for­schung. Ich habe mich umge­se­hen in der Viel­falt der ange­bo­te­nen Fire­wall-Lösun­gen / ‑Plug­ins. Ich habe instal­liert und getes­tet. Nach zwei Mona­ten habe ich ernüch­tert mein Résu­mé gezogen:

5 verschiedene Firewall-Lösungen 

Und kei­ne erklimmt das Siegertreppchen …

1. Die eine Lösung ver­sucht das The­ma inner­halb Word­Press umzu­set­zen. Ein No-Go, denn das zieht Traf­fic im Word­Press Con­tent-Manage­ment-Sys­tem. Das hat doch kein Blog wirk­lich ver­dient! Da wer­den Sta­tis­ti­ken in der Word­Press Daten­bank abge­legt, wer wann ver­sucht hat eine Schwach­stel­le zu fin­den. Es kön­nen tau­sen­de von Zugrif­fen in einer Sekun­de ent­ste­hen! Soll das jedes Mal Word­Press belas­tet und ande­ren seriö­se Besu­chern wer­den dadurch mit einem lang­sa­men Sei­ten­auf­bau konfrontiert?
2. Ande­re Anbie­ter sam­meln böse IP-Adres­sen und spei­chern die­se in der loka­len Daten­bank oder mel­den die­se unlau­te­ren Besu­che dezen­tral. Ach sor­ry, auch das ist ja wie­der eine Lösung, die inner­halb Word­Press statt­fin­det bzw. eine zusätz­li­che Kauf­dienst­leis­tung. Tipp: Wer die­sem Weg gehen will, soll­te sich dem kos­ten­lo­sen Pro­jekt Honey­pot anschlie­ßen. Ein Plus­punkt gene­rell dabei: Die­ser Lösungs­an­satz kann bei einer gro­ßen Ansamm­lung von bösen IP-Adres­sen gegen Bru­te-Force-Angrif­fen sehr effi­zi­ent wirken.
3. Wei­te­re Anbie­ter ver­su­chen eine Misch­form­lö­sung: Lösungs­ver­su­che inner­halb von Word­Press und dem Hin­zu­fü­gen von htac­cess-Regeln außer­halb von Word­Press. Na ja, glei­ches Pro­blem: Wie­der wird Last inner­halb von Word­Press erzeugt. Und nach mei­ner Ana­ly­se konn­te ich fest­stel­len: Nicht alle htac­cess-Regeln sind wirk­lich effek­tiv genug.
4. Die meis­ten Anbie­ter der Fire­wall-Lösun­gen (1 bis 3) bie­ten meist klei­ne­re kos­ten­lo­se Sicher­heits­fea­tures an und freu­en sich über zah­len­de Kun­den. Das ist legi­tim. Die zah­len­den Kun­den erhal­ten dann einen erwei­ter­ten Funk­ti­ons­um­fang, der jedoch die bis­he­ri­gen Résu­mé­punk­te unter 1 bis 3 nicht grund­le­gend verbessert.
5. Dann gibt es noch den Ansatz, nur durch Regeln in einer .htac­cess-Kon­fi­gu­ra­ti­ons­da­tei auf Ser­ver­sei­te böse Zugrif­fe abzu­weh­ren. Das ist zumin­dest ein bes­se­rer Ansatz als das The­ma inner­halb von Word­Press lösen zu wol­len. Der zwei bes­ten Ansät­ze, die ich gefun­den habe ist jedoch ledig­lich das a) Ver­schlei­ern (zum Bei­spiel von Word­Press Core Ver­zeich­nis­na­men) oder b) ein zwei­tes Pass­wort auf das Word­Press Ver­zeich­nis wp-admin zu legen. Und natür­lich nicht uner­wähnt möch­te ich die inter­es­san­ten 6G oder 7G Regeln von Jeff Starr erwäh­nen. Bei nähe­rer Betrach­tung sind die 6G bzw. 7G Regeln ein Sam­mel­su­ri­um, um durch wei­te­re Nachbesserungen/Anpassungen Angrif­fe abzu­weh­ren. Jedoch wirk­lich befrie­di­gend und begeis­ternd fand ich auch die­se Fire­wall-Regeln nicht.

Fazit: Kei­ne der ver­füg­ba­ren Lösungs­an­sät­ze (1 bis 5) ist wirk­lich umfas­send hilfreich.

Wel­che Plug­ins und Dienst­leis­ter fal­len unter Punkt 1 bis 5? Ich erstel­le hier bald noch eine Lis­te für die­je­ni­gen, die das interessiert.

Also was tun? Oder anders for­mu­liert: Was bemän­ge­le ich hier eigentlich?

Ich formuliere das wünschenswerte Ziel

1. Die Per­for­mance: Böse Zugrif­fe auf die Web­sei­te sol­len (mög­lichst) kei­ne Word­Press­code oder Word­Press-Daten­bank Zugrif­fe bedeu­ten. Dabei gilt: Kein ein­zi­ger Zugriff wäre als Ide­al anzusehen.
2. Die SEO Aus­wir­kun­gen durch fal­sche Feh­ler­aus­ga­ben: Fal­sche 404 Feh­ler­aus­ga­ben wegen Bots und Hackern sind (abso­lut) zu ver­mei­den. Qua­si alle erwähn­ten Plug­ins fal­len hier durch. 
3. Unge­wiss­heit erzeu­gen und nicht Trans­pa­renz: Bots und Hacker dür­fen durch ihre Angriffs­ver­su­che mög­lichst nicht dazu­ler­nen kön­nen. Das kön­nen sie jedoch, wenn man sie mit „Datei nicht gefun­den / File not found“ (404) Hin­wei­sen schlau­er macht.
4. Der Zeit­fak­tor: Es geht nicht dar­um, sich immer wie­der „Bad-Access” Zugriffs­sta­tis­ti­ken anzu­se­hen. Du willst dei­nen Blog betrei­ben und viel­leicht dei­nem Geschäft nach­ge­hen. Alles, was dich davon ablenkt, kos­tet dich nur Zeit. Mit der Unsi­cher­heit der Kun­den in Sicher­heits­the­men lässt sich gut Geld ver­die­nen. Sta­tis­ti­ken hel­fen dabei die ver­meint­lich gute Soft­ware „an den Mann zu brin­gen“ (Anmer­kung: Ich darf mich hier „aus dem Fens­ter leh­nen“. Ich war Jahr­zehn­te im Bereich IT-Secu­ri­ty aktiv.

Nach dem erstel­len der Män­gel­lis­te bin ich wei­ter in Klau­sur gegangen:

Lösungsweg angehen

Mer­ke:

Es gibt kei­ne Pro­ble­me, es gibt nur Herausforderungen.

Mana­ger­spruch

Die eigent­li­che Her­aus­for­de­rung ist doch, sich Gedan­ken zu machen über Ursa­che und Wir­kung. In unse­rem Fall: Erken­nen und dann abso­lut die Her­aus­for­de­rung lösen. Nicht mit einem Lösungs­ver­such im „trü­ben Was­ser” zu fischen!

Alle Plug­ins las­sen die Angrif­fe ins Inne­re von Word­Press rein (Stand: Novem­ber 2022). Sie errei­chen also den soge­nann­ten Word­Press Core. Das darf nicht sein!

Fehlender eindeutiger HTTP-Statuscode

Lei­der fehlt unter den HTTP-Sta­tus­codes ein ein­deu­ti­ger Feh­ler­code für unbe­rech­tig­te Zugrif­fe (von bösen Bots und ande­rem Gesin­del). Der 404 Feh­ler ist nicht ide­al, um die­sen wert­vol­len Feh­ler­code für Hacker­an­grif­fe regel­recht zu verschwenden!

Nach lan­gem stu­die­ren ver­schie­de­ner Quel­len habe ich mich für den Bad Request Feh­ler 400 ent­schie­den. Bei uner­laub­ten Zugrif­fen auf wich­ti­ge Medi­en­da­tei­en und ande­re Archi­ve auf den Feh­ler­code 403. Selbst­ver­ständ­lich plat­zie­re ich den Feh­ler­code unge­ach­tet, ob es die ent­spre­chen­de Datei gibt oder nicht gibt 😉

Fort­set­zung folgt!