Hallo!
Ich möchte gerne diverse Daten-Staubsauger und Spam-Bots von meiner Homepage ausschliessen.
Zur Verfügung stehen mir z.Zt. nur die Möglichkeiten von
.htaccess/.htpasswd
SSI (Server Side Includes - ohne Perl/CGI)
JavaScript (eventuell, aber eigentl. nicht wünschenswert)
Wie würdet Ihr das machen, ohne die Funktionalität für „normale Web-Besucher“ einzuschränken??
Danke im voraus für jeden konkreten Hinweis…
DannyFox64
Du kannst im Quelltext das @ maskieren, evtl. erkennen die Bots das dann nicht mehr.
Anstatt @ einfach & # 6 4 ;
(Ohne Leerzeichen) schreiben. (Und Raute 6 4 Semikolon)
@
Du kannst im Quelltext das @ maskieren, evtl. erkennen die
Bots das dann nicht mehr.
Anstatt @ einfach & # 6 4 ;
(Ohne Leerzeichen) schreiben. (Und Raute 6 4 Semikolon)
Hallo,
mag sein, dass man 1 oder 2 dadurch ausschliesst, allerdings bin ich mir sicher, dass die Mehrzahl der Bots sich davon nicht beeindrucken lässt.
Ciao
Kaj
Hallo!
Ich möchte gerne diverse Daten-Staubsauger und Spam-Bots von
meiner Homepage ausschliessen.
Um die eMail-Adressen zu schützen und Olafs Vorschlag etwas auszubauen, schlage ich Dir folgende JavaScript-Lösung vor:
Eine Funktion in JavaScript:
function no\_spam(name,user,domain) {
document.location.href="mailto:"+name+" ";
}
Folgender HTML-Code:
[Realname](javascript:stuck_out_tongue:arent.no_spam('Realname','user','domain.de');)
[\<user](javascript:stuck_out_tongue:arent.no_spam('RealName','user','domain.de');)
[@domain.de\>](javascript:stuck_out_tongue:arent.no_spam('RealName','user','domain.de');)
Der Code erzeugt einen klickbaren mailto-Link der Form
Realname
CU
Markus
Hallo Ihr’s!
Ihr habt mich nicht ganz verstanden.
Die JavaScript- und, ich sag’s mal unfachmännisch, Maskierungsmethoden, kenne ich schon und wende sie auch an… Dass ich an Robots grundsätzlich keine Mail-Adressen ausliefere, ist für mich heute normal. Trotzdem kann’s in der ein oder anderen Konfiguration nicht funktionieren.
Es geht jetzt viel mehr darum, solche Suchmaschinen auszuschliessen, die nicht wie „Google“ oder „Fast/Alltheweb“ reelle Contents liefern wollen - sondern:
solche, die Seiten abspidern, um Mail-Adressen einzusammeln (z.B. „EmailCollector“)
solche Leute ab einer gewissen Verzeichnistiefe (sagen wir mal tiefer als 2) auszuschliessen, die einem 100% der Web-Site mit einem Offline-Reader „aussaugen“ (wollen).
Dafür braucht man bestimmte Skripte, damit „die“ erst gar keine Seite ausgeliefert bekommen. Beispiel:
Aha! Wieder ein Standard-User!
Oha! Endlich mal jemand, der keinen MS-Browser verwendet
An den Stellen „Aha!/Oha!“ lassen sich auch andere Funktionen einbauen. Wesentlich ist, dass der Server NUR den Text ausliefert, der zum Zuge kommt.
Das grösste Prob. ist die Unmenge von Robots, die mit der #if-/#elif-Abfrage geregelt werden müsste. Ausserdem: Wie kann man einen mit Browser-Kennung daherkommenden Spam-Bot enttarnen?
Dank & CU DannyFox64
PS: Seid Euch einfach darüber im Klaren, dass ein Spider, so er sich nicht an die robots.txt hält, jede Seite zum Greifen kriegt, die in einem ungeschützten Verzeichnis liegt, selbst dann, wenn kein Link auf das Verzeichnis (oder Seiten/Struktur unterhalb) zeigt.
Dafür braucht man bestimmte Skripte, damit „die“ erst gar
keine Seite ausgeliefert bekommen. Beispiel:
> Aha! Wieder ein Standard-User!
Es spricht ja nichts dagegen, bei dem Spam-Harvester etwas Entsprechendes zu senden…
Gruß,
Sebastian
Die Variante „Aussperren auf Basis der User-Agent Strings“ geht auch ohne SSIs,
dies ist schon mit dem SetEnvIf (Apache) Befehl in .htaccess moeglich (auch bei Strato.
Das Problem ist halt, dass „ehrlich“ und Spammer irgendwie Wiedersprüche in sich sind und diese sich in zunehmendem Unfang nicht mehr mit ihren „wirklichen“ Namen, sondern einfach als Mozilla oder IE ausgeben.
Hat man mehr Kontrolle über den Webserver, scheint „Robocop“ eine feine Idee zu sein, da dieses Programm anhand von Honeypots, Verhaltensanalyse etc. Bots erkennt. Dies setzt aber leider ein zustandsbehaftetes Verhalten seitens des
Webservers voraus.
Allerdings (Spekulation, muss ich erst austesten) koennte es moeglich sein,
das unter Verwendung von cookies in Verbindung mit SetenvIf und Mod_ASIS (beide scheinen weitlaeufig verbreitet zu sein) auch so hinbekommt:
Der Benutzer muss ueber eine Einstiegsseite rein, die ihm via asis einen Cookie verpasst. Alle weiteren Seiten darf nur sehen wer den Cookie hat. (SetenvIf kann
theoretisch alle http-header auswerten also auch Cookie: ?!?). Das duerfte schon viele Bots ausschliessen. Zusaetzlich bringt man auf den seiten ein paar
unsichtbare Links an, die zu Seiten fuehren, die man mit Robots.txt gesperrt hat. Es ist also eine realistische Annahme, das nur boese Bots diese aufsuchen.
Hier wird der Freigabe-Cookie durch einen Sperr-Cookie ersetzt.
Habe jetzt leider keine Zeit, das auszutesten…
MfG
ML
Danke, Martin,
das ist ja alles in allem zirka 100% eines solchen Sicherheitskonzepts.
Dies zur Anregung fliesst nun garantiert in meines Sache/Arbeit ein.
Dank & MfG
DannyFox64 