dbBotTrap

[Ralf (Berlin)]

Unter http://www.bot-trap.de ist ein Tool zum Schutz vor Webspam (Content Grabber, Web Spam, Sauger, Hijacker, Duplicate Content etc.) verfügbar. Der erste Eindruck ist sehr positiv.

Für einen einfachen Zugriff auf das Logfile der page.restrictor.php habe ich ein Admin-Tool geschrieben: dbBotTrap.

Anregungen, Verbesserungsvorsch läge usw. sind wie immer herzlich willkommen!

Gruß
Ralf

[WebBird]

Erklär doch mal bitte genauer, wie man das mit WB nutzen kann. Danke.

[Ralf (Berlin)]

Hallo Bianca,

ich bin mittlerweile ziemlich abgenervt von dem permanenten Hagel durch Bots, Spider usw. - siehe hierzu bitte auch den Thread Schutz vor Spidern, das war der Anfang des Ganzen...

Auf Grund des Hinweis auf das Bot-Trap Projekt, dessen Ziel der Schutz vor Webspam ist, habe ich mir das dort erhältliche Tool page.restrictor.php genauer angesehen und habe es z.Zt. auf einem Server laufen. Bis jetzt erfüllt das Tool meine Erwartungen, unerwünschte Spider und Bots bleiben draußen.

Das Tool schreibt auch ein LOG, das allerdings nicht sehr übersichtlich ist und nur per FTP oder SSH eingesehen werden kann. Um das bequemer zu haben, gibt es dbBotTrap, das als Admin-Tool einen Zugriff auf das aufgehübschte LOG gibt.



Um das Bot-Trap Tool einsetzen zu können, muss man sich dort anmelden und vorstellen. Danach erhält man einen Zugangscode und kann sich die page.restrictor.php herunterladen. Diese benötigt keinen Datenbankzugriff und führt auch keine Fernabfrage durch, alle erforderlichen Daten befinden sich in der Datei, die sich selbst aktualisiert. Die Einbindung erfolgt recht einfach: page.restrictor.php in das Wurzelverzeichnis kopieren und über die config.php einbinden:

Code:

// init Page Restrictor first...
if (file_exists($_SERVER["DOCUMENT_ROOT"].'/page.restrictor.php')) {
  $logfile = $_SERVER['DOCUMENT_ROOT'].'/logs/'.date('Ymd').'.log';
  define('PRES_LOG_FILE', $logfile);

  require_once($_SERVER["DOCUMENT_ROOT"].'/page.restrictor.php');
}

Für das LOG file noch ein Verzeichnis anlegen und fertig.

Greift jetzt ein Bot, Spider etc. auf die Website zu, der mit einem Sperrvermerk registriert ist oder von einer gesperrten IP kommt, wird der Zugriff verweigert.

Ist der Besucher menschlich   kann er eine Rechenaufgabe lösen um eine evtl. irrtümliche Sperrung aufzuheben.



Wie gesagt: bislang habe ich den Eindruck, dass es gut funktioniert und den Versuch lohnt  

Gruß
Ralf

[iradj]

Hallo Ralf,

ich betreue mehrere Website alle mit WB erstellt. Musste ich für jede Website eine neu page.restrictor.php herunterladen? oder kann ich es auf mehrere Website verwenden?

Vielen Dank
Iradj

[Ralf (Berlin)]

Hallo Iradj,

du kannst die php.restrictor.php auf allen Seiten einsetzen, die von dir betreut werden.

Gruß
Ralf

[WebBird]

Ralf, vielen Dank für die Erklärung. Das wird vielen Leuten helfen, ihre Seiten besser zu schützen. Der Log-Viewer macht einen guten Eindruck und ist mit Sicherheit eine große Hilfe.

Das wäre doch ein schönes Thema für die Tutorials. 

[Hans>NULL]

Gerade in einem anderem Forum gelesen:
In Web 2.0-Zeiten helfen Fruchtzwerge auch gegen Schuppen.

In meinen Systemen kommt so ein Unfug nicht rein, weil kontraproduktiv.
(Schon jetzt im Anfangsstadium gibt wg dyn. Adressen reichlich false positive,
von nicht dokumentierten Verfahren, Sicherheitsfragen und möglichen Fehlern bei Unicode/BOM ganz abgesehen)
Wenn Server und CMS sicher sind, braucht es derartige Angebote nicht.
Die Serveranfragen bleiben  trotzdem, irgendwie sieht das nach ABM aus  

Wer als Admin unterbeschäftigt ist kennt noch Referrer-Spam. Da weiß man was man hat.
Eine Liste mit ein paar IP4-Blöcken(CIDR) reichen für diese bekannten Dauernerver, falls die wirklich zur Last werden sollten (Nerven und Traffic+), die aber außer vom Admin von niemandem bemerkt würden. Wer keine Arbeit hat macht sich welche.
Gruß, Hans>NUL
Edit: Wer grundsätzlich "Spamer-Länder" draußen haben will, kann ja das WB-Modul  GEOIP dafür einspannen.

[Ralf (Berlin)]

Hans,

manchmal bis du richtig anstrengend. Anstatt das du uns deine Weisheiten in dem Thread mitteilst, wo es genau um dieses Thema ging, schweigst du dich aus und behälst deine Weisheiten für dich um uns dann hier was von Fruchtzwergen zu erzählen.

Danke.

Gruß
Ralf

[Stefek]

... behälst deine Weisheiten für dich um uns dann hier was von Fruchtzwergen zu erzählen.

Hallo Ralf,
interessante Sache.
Wie wirkt es sich auf die sonstigen Anti-Spam Versuche von Seiten WB CMS aus?
Ich meine Captcha und ASP.
Kann man auf die dann getrost verzichten, oder sollten sie weiterhin beibehalten werden?

Eine Schritt-für-Schritt Anleitung, wie oben von Bianka vorgeschwärmt, würde auch mir helfen, dieses Teil besser zu verstehen. 

Gruß,
Stefek

[Ralf (Berlin)]

Hallo Stefek,

natürlich wäre ein Tutorial eine feine Sache, ich mag's im Moment aber einfach nicht versprechen - im Moment gibt's noch genug andere Baustellen... 

Auf Captcha und Antispam solltest du auf keinen Fall verzichten. Ein Filter kann niemals perfekt sein, er wird immer angepasst werden müssen, weil er zu locker oder zu straff ist. Positiv am page.restrictor.php ist, dass er sich immer wieder aktualisiert.

Gruß
Ralf

[Hans>NULL]

@Ralf (Berlin)
Ob nun anstrengend oder nicht. Nach einigen "Erlebnissen" hier war mein Mitteilungsbedürfnis nicht so groß, deshalb verspätet.
Aber zur Sache. An Deinem Modul gibts nix auszusetzen; wie denn auch? Es ist nicht Dein Modul was nicht stimmt.

B-trap.de will bei einem Problem behilflich sein, das eigentlich keines ist, ähnlich der Pharmaindustrie, wo Krankheiten erfunden werden. Wenn Server und WB sicher sind gibt es kein/e Einfallstor/Störung. Einfallstor/Störung? Eben, das kann uns damit egal sein. Die Versuche bringen trotzdem eine Serverantwort, diesmal aber mit unnötiger Verzögerung durch einen externen Dienst. Die Handhabung der "page.restrictor.php" ist wg. Rechte zudem für Laien unzumutbar, und auch noch individuell vom Server abhängig. Bei meinen Servern setze ich einen weiteren FTP-User drauf und dann war's das.

Also, vor was will uns der Dienst schützen, und wo hat WB bisher gezeigt, daß er Probleme mit speziellen "Besuchern" hat? Schon irgendwo eine Präsenz abgekackt wegen "sowas"? Ich weiß, das Verbrechen lauert immer und überall...  

Will man die Versuche von "Dauerstörern" verhindern, hilft die schnelle Antwort aus der htaccess. Nicht jeder Chinese liest die Homepage des Schützenvereins in Wanne-Eickel.

Gruß, Hans>NUL

Edit: Wer den Verdacht auf Kundschafter hat, kann z.B. vorübergehend php-ids einschalten. So kann man die Neugier anderer sogar für sich nutzen. 

[Waldschwein]

Hallo!

Hans, was willst du uns eigentlich genau mitteilen?
Bitte wirft nicht alles durcheinander!
Bot-Trap ist ein Spamschutz, der auf ausschließen bekannter Spam-IP-Adressen basiert.
Also im Prinzip nichts anderes als ein Virenscanner, nur eben für IP-Adressen.
Wenn du wissen willst, ob WebsiteBaker Probleme mit "bestimmten" Benutzern hat, kannst du dir gerne einmal den letzten Thread von der-schutzhund ansehen, da ist das ziemlich deutlich.
WB selbst hat damit keine Probleme, es sind die Spambot-Netzwerke. WB liefert seit Version 2.7 eine ziemlich zuverlässige Spamabwehr mit, mit WB 2.8 noch einmal verbessert.
Es geht aber darum, dass es gar nicht zur Spamabwehr kommen muss, sondern schon vorher diejenigen "bösen" ausgeschlossen werden.
Die schnelle Antwort aus der .htaccess ist ganz sinnvoll, aber auch nur dann, wenn die Person sich damit auskennt, und der Server es zulässt, also genauso eine Krücke wie auch Bot-Trap.
Letztendlich ist die Beste Spamabwehr immer noch Individualität, und gerade da ist WB vielen anderen Systemen um einiges vorraus. Aber es geht darum ja gar nicht.

Und: Spambots sind in der Regel nicht an Sicherheitslöchern interessiert, dafür gibt es wiederum spezielle Bots. Die werden aber erst dann von den Hackern geschrieben, wenn es sich auch rentiert - zum Beispiel der FCKeditor der in WB 2.7 ausgeliefert wird wäre hierfür ein Kandidat.
Die meisten Sicherheitseinfälle sind aber manueller Natur - und da hilft auch kein Bot-Trap und sonst etwas, soll es ja auch gar nicht.
Der Virenscanner ist auch keine Firewall.

Gruß Michael

[maverik]

moin
genau diese diskussion habe ich mir gewünscht als ich den link zu bot-trap postete und auch wenn es mir schwerfällt, ich gebe diesmal hans>null recht.

warum?

ich kenne bot-trap von der ersten stunde an und erst als bot-trap seine domain reggte und die seite mit wb erstellte bin ich auf wb gestoßen. vorher verteilte sich bot-trap auf verschiedenen einzelnen seiten bzw subdomains etc.

im anfang war das ganze noch gut überschaubar aber die sperrliste wurde zusehends größer und länger. bot-trap an sich entwickelte sich weiter und wenn man nicht täglich im forum mitgelesen hat verlor man schnell den überblick.

da man aber nicht immer genau wußte was nun wie in der sperrliste steht und wie es sich draussen und auf der eigenen seite auswirkt, war und ist man eigentlich gezwungen täglich seine logfiles zu checken um zu sehen ob nicht eventuell doch vermeintliche besucher draussen bleiben. nicht jeder der vor die verschlossene türe läuft löst noch die rechenaufgabe um zutritt zu bekommen.

insgesamt hatte ich bot-trap 2 jahre auf www.nrbw.de im einsatz bis ich es wieder rausgeschmissen habe. zum einen war mir das tägliche checken der logfiles zu anstrengend und zum anderen stellte ich immer mehr geblockte adressen fest die von ganz normalen usern kamen. meine genannte seite wird viel von firmen, hochschulen, teilweise aus der ganzen welt, besucht und davon hing einiges in den logfiles.

ohne bot-trap gab und gibt es aber keinerlei verschlechterung.

Also, vor was will uns der Dienst schützen

genau diese frage habe ich mir gestellt und stelle sie mir heute noch.

deshalb finde ich die diskussion gut, hoffe das sie weiterhin sachlich bleibt und das uns ralf noch ein wenig zu seinen beweggründen schreibt warum er so etwas einsetzen will bzw warum man so etwas einsetzen sollte.

[Waldschwein]

Hallo!

Ja, das ist einleuchtend. Es ging mir vorher nur darum, dass man sauber trennt von Spam und Sicherheitseinfällen, das wird gerne durcheinander geworfen.

Ich hatte selbst so ein IP-Adressen basiertes Script auf einer meiner Foren, und habe immer wieder festgestellt, dass es mich selbst gesperrt hat, auch andere Benutzer haben sich beschwert.
Daher sind leider alle IP-Adressen-Basierte Scripte nicht Benutzerfreundlich, und letztendlich erreichen sie nicht nur, dass Spams (selten zuverlässig) außen vorgehalten werden, sondern zudem, dass die normalen Benutzer auch gleich mit wegbleiben. 
Das hat aber alles, was IP-Adressen und Sicherheitsscript in Einklang bringt an sich, egal wer das erstellt und für welche Software.

Gruß Michael

[Hans>NULL]

Naja, Spamer zähle ich zu den Störern, ich denke eher ein Mißverständnis, als eine Verwechslung.
(Edit z.B, Captcha: Störer=Manuelle Eingabe // Sicherheit= Injection/Scriptlücke)
Der äußerst flexible Captcha in WB scheint mir sicher. Für diesen Fall wäre der Dienst überflüssig.
Deshalb auch mein Schwerpunkt auf generelle Sicherheit.

Man sollte hier einfach auf Ursache und Wirkung schauen. Habe ich z.B. ein Sicherheitsproblem im CMS, kann ich das im CMS lösen oder aber alle auf diesem Erdenball versuchen auszusperren, die sich an der Ausnutzung versuchen.

Vielleicht macht das deutlich worum es mir geht.

Edit Noch einer: IPSafer! Unter Example ist auch WB 2.8.1 aufgeführt. Ohne Anmeldung einbauen und loslegen.
Gruß, Hans>NUL

[Ralf (Berlin)]

Vorweg: ich finde es zum ko... dass diese Diskussion jetzt hier im Module & Snippets Forum stattfindet und nicht dort, wo darum gebeten und nachgefragt wurde.

Warum Bot-Trap? Es geht nicht darum irgendwelche Sicherheitslöcher zu stopfen, es geht auch nicht darum den permanenten Hagel durch Bots zu verhindern (das geht sowieso nicht). Mir geht es insbesondere darum - ähnlich wie beim SPAM Filtern von E-Mails - die Spreu vom Weizen zu trennen.

Da ich etliche redaktionelle Seiten betreue sind für mich die E-Mail Benachrichtigungen durch Fehlerseiten eine wichtige Quelle um auf durch Redakteure verschobene Seiten, umbenannte Seiten, nicht vorhandene Bilder etc. zu reagieren und die Seiten auf Stand zu halten. Wenn die Fehlermeldungen - wie das mittlerweile der Fall ist - praktisch nur noch aus Reaktionen auf Bots bestehen sind sie für mich wertlos.

Ich kann mir natürlich das Leben auch leicht machen und - wie Hans - Fehlerprotokolle ignorieren oder die Benachrichtigung einfach ausschalten. Dann muss ich aber auch akzeptieren, dass Fehler, die Google u.a. registrieren, mein Ranking drücken - Ranking aufzubauen ist allerdings sehr viel anstrengender, als ein bestehendes Ranking zu stabilisieren...

Darum geht's und genau das erreiche ich offensichtlich mit Bot-Trap, deshalb bin ich es am testen.

Nachtrag: Es gibt natürlich auch noch die Möglichkeit, den Bot-Trap ausschließlich auf den Fehlerseiten einzusetzen und damit die Wahrscheinlichkeit einen unbedarften Besucher versehentlich auszusperren praktisch auf Null zu setzen.... <GRÜBEL>

Gruß
Ralf

[WebBird]

Vorweg: ich finde es zum ko... dass diese Diskussion jetzt hier im Module & Snippets Forum stattfindet und nicht dort, wo darum gebeten und nachgefragt wurde.

Wäre gut, wenn ein Admin den Thread aufteilen könnte.

[Hans>NULL]

1.) Ich meine deutlich gemacht zu haben, daß es nicht vornehmlich um Sicherheitslöcher geht, manchmal ist aber das eine mit dem anderen verbunden.
2.) Die Filterung von Mailservern und Webservern geschieht auf gänzlich unterschiedliche Art
3.) Wenn E-Mail-Benachrichtigungen durch Botanfragen gestört (Systemstörung oder sich nur genervt fühlen ist wohl ein Unterschied) werden ist die "falsche" Reaktion des Filters oder des Systems  höchstwahrscheinlich ein hausgemachtes Problem. (Du guckst ja selbst schon nach Alternativen)
4.) Mache ich mir das Leben nicht leicht durch Ignoranz. Habe vor Jahren ein Verlagsprojekt (mit STATISCHEN Seiten [aber mit SSI]) erfolgreich gesichert. Das Ranking wurde nie schlechter. IP-basierte Ausperrung war schon damals nicht der Hit, und keine Angelegenheit, die man in fremden Händen wissen wollte.  Dazu kommen noch rechtliche Aspekte (ja, richtig gelesen).
Gruß, Hans>NUL
p.s.

Vorweg: ich finde es zum ko...

Das war, wie schon angemerkt, keine böse Absicht. Man könnte, wie von "WebBird" vorgeschlagen, die Diskussion verschieben.

Edit: Wenn nur die "nervigen" Bot-Meldungen stören, helfen RegEx Filter.