Aus heiterem Himmel: 500 - Whoops, looks like something went wrong

    Ich denke, dass wir die Ursache gefunden habe: Facebook.

    Aufgefallen ist das bei der Durchsicht der Access-Log-Dateien. Offenbar wird der JEvents-Terminkalender intensiv abgescannt. Die Vermutung mit JEvents war also nicht ganz falsch, aber JEvents ist völlig unschuldig. Ursache ist, dass Facebook-Nutzer unseren Kalender verlinkt haben.

    Dazu als Beispiel der Anfang der Log-Datei von heute:

    \x9e/index.php/jeventstestlistbyday-4/icalrepeat.detail/2024/06/09/51846/90/\xe2\x80\x9e/index.php/jeventstestlistbyday-4/icalrepeat.detail/2024/08/10/55958/147/\xe2\x80\x9e/index.php/jeventstestlistbyday-4/icalrepeat.detail/2024/08/10/55958/147/sommerfest\xe2\x80\x9c HTTP/1.1" 200 60858 http://www.tsg-dacapo.de "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" "-"

    Innerhalb einer Woche haben die Log-Dateien bei uns einen Umfang von 50 und mehr MB angenommen.

    Mit der Suche facebook external hit bot finden sich übrigens im Internet viele Beispiele zu diesem Thema mit Aussagen wie z.B. Our website gets hammered every 45 - 60 minutes with spikes of approx. 400 requests per second, from 20 to 30 different IP addresses from the facebook netblocks.

    Kommentar von Facebook dazu: suck it (finde Dich damit ab) - eine totale Frechheit. Bestätigt alle meine negativen Einschätzungen zu dieser Firma.

    Wir suchen jetzt nach der besten Methode, diese Zugriffe zu unterbinden. Das ist wohl nicht ganz so einfach, da die normalerweise angewendeten Methoden von diesem Facebook-Bot umgangen werden.

    Gruß

    Heinz

    "Wer es nicht versucht schafft es auch nicht."

    Eventuell nützlich:

    Keep Facebookbot away from forum via .htaccess
    Hii Folks, How can I deny acces to the forum for Facebook bot via .htaccess? I use Xenforo 2.2.2 Greetings, xXArmestakkerXx
    xenforo.com
    .htaccess redirect facebook crawlers except privacy policy
    I have a SPA app with dynamic content for sharing on Facebook so I am redirecting Facebook crawlers to a nice static page using the following rule in…
    stackoverflow.com

    Und falls du den facebook-Crawler z.B. nur zeitweise aussperren möchtest eventuell nützlich:

    [Servertechnik, quasi] zeitgesteuert .htaccess setzen?
    Sers, ich würde an einem bestimmten Tag gern eine Stunde lang meine .htaccess durch eine andere ersetzen. Wie geht das am einfachsten?
    www.computerbase.de
    Wie macht man eine Rewrite-Regel zeitabhängig?
    Um eine .htaccess Umschreiberegel zeitabhängig zu machen, fügen Sie vor der Umschreibregel, die Sie zeitabhängig machen möchten, die folgende Zeile hinzu:
    de.siteground.com
    Zitat von WM-Loose

    Hallo Heinz,

    versuch mal bitte mit Kubik-Rubik in Kontakt zu treten.

    Vielleicht hat Viktor dafür schon ein Plugin oder etwas geplant.

    Hey Dirk und Heinz!

    Wenn die Blockierung in der Applikationsebene erfolgen soll (also nicht über eine .htaccess-Regel), könnt ihr mein Plugin Intrusion Detection System for Joomla! verwenden:

    Soweit ich weiß, setzt Facebook immer den User-Agent facebookexternalhit für die Botaufrufe bei Verlinkungen, deswegen könnt ihr den Bot so relativ einfach aussperren.

    Viel Erfolg!

    Wir haben uns jetzt die Log-Dateien angesehen. Die hatten vor der Sperrung (mittlerweile wieder aufgehoben) einen Umfang von bis zu 42 Gigabyte und bis zu 350.000 Zugriffen pro Tag. Das hat sich aktuell auf unter 1 GB und um die 80.000 Zugriffe reduziert.

    Grund kann die robots.txt sein. Hier haben wir viele Einträge vorgenommen, die teils auch wirken, teils aber einfach ignoriert werden. Die robots.txt hat halt nur empfehlenden Charakter.

    Einiges wird auch auch durch Einträge in der .htaccess bewirkt über order allow,deny. Beispielsweise kann bingbot oder GPTbot abgehalten werden. Dazu noch eine Anmerkung: gemäß https://httpd.apache.org/docs/2.2/mod/m…host.html#order ist die order-Methode als deprecated charakterisiert und wird durch require ersetzt (siehe https://httpd.apache.org/docs/current/m…re.html#require).

    Die Analyse der log-Dateien hat auch gezeigt, dass Facebook die Aktivitäten deutlich zurückgefahren hat, tritt aber immer noch auf. D.h. die üblichen Abwehrmethoden wirken maximal eingeschränkt. Dafür sind andere Bots auftaucht, die fast ausschließlich auf die gleiche URL zugreifen wie Facebook. Das kann darauf hindeuten, dass Facebook die URL an andere "verkauft" hat, wie z.B. Microsoft, OpenAI, Amazon und verschiedene Marketing-Agenturen.

    Als dominant hat sich dabei Amazonbot gezeigt mit derzeit über 90% der Zugriffe, der leider weder durch robots.txt, noch durch Order noch durch Require abgehalten werden kann. Selbst mit einer Firewall konnten wir diesen Bot nicht in den Griff bekommen (mag natürlich an der Firewall gelegen haben.). Daher wären wir froh über Infos, ob es jemand geschafft hat diesen Bot wirklich abzuwehren.


    In diesem Zusammenhang leistet sich Amazon übrigens den Hinweis, dass die Robots.txt beachtet wird, sofern die zu schützenden Inhalte in einem Verzeichnis /do-not-crawl/ abgelegt sind. Als wenn eine ganze Webseite in dieses Verzeichnis transferiert werden könnte. Es mag sich jeder selbst ausdenken als was er diese "Empfehlung" bezeichnen möchte.

    Gruß

    Heinz

    "Wer es nicht versucht schafft es auch nicht."

    Zitat von hrybak

    Als dominant hat sich dabei Amazonbot gezeigt mit derzeit über 90% der Zugriffe, der leider weder durch robots.txt, noch durch Order noch durch Require abgehalten werden kann. Selbst mit einer Firewall konnten wir diesen Bot nicht in den Griff bekommen (mag natürlich an der Firewall gelegen haben.). Daher wären wir froh über Infos, ob es jemand geschafft hat diesen Bot wirklich abzuwehren.

    Warum sperrst du nicht den UserAgent per .htaccess. Dann wehrt der Server den Bot zuverlässig ab. Eine DB-(Über)Belastung findet dann überhaupt nicht statt. Also ungefähr so:

    RewriteCond %{HTTP_USER_AGENT} ^BadBot1 [NC,OR]
    ......
    RewriteCond %{HTTP_USER_AGENT} ^BadBot-letzter [NC]
    RewriteCond %{REQUEST_FILENAME} !^.*robots\.txt$
    RewriteRule ^.* - [F]

    Die robots.txt wird hierbei von der Sperrung ausgenommen.
    Blöd ist, dass sich der User-Agent gerne auch mal ändert und die Liste dann angepasst werden muss. Bei den seriösen Bots ist das aber eher seltener der Fall.
    Mit dem oder den Bots von Amazon habe ich mich allerdings noch nie intensiv beschäftigt.

    Viele Grüße!
    JoomlaWunder

    Hatte ich vergessen zu erwähnen: auch diese Methode hatte nicht funktioniert Lediglich dieZeile mit robots.text kannte ich noch nicht. Werde ich testen.

    Gruß

    Heinz

    "Wer es nicht versucht schafft es auch nicht."

    Ist das Apache-Module mod_rewrite auf dem Webserver vorhanden und aktiv ?

    Auf welcher Art von Webserver ist die Website gehostet ?

    ( Siehe System -> Systeminformationen -> Webserver )

    In welchem Dateiordner befindet sich die .htaccess mit dem zusätzlichen Code?

    Wie lautet der komplette Code in dieser .htaccess ?

    Zitat von hrybak

    Hatte ich vergessen zu erwähnen: auch diese Methode hatte nicht funktioniert Lediglich dieZeile mit robots.text kannte ich noch nicht. Werde ich testen.

    Diese Zeile erlaubt den Bots mit den gesperrten User-agents lediglich, die robots.txt aufrufen zu dürfen. Dort sollten sie natürlich auch für Disallow eingetragen sein.

    Funktioniert das mit der Sperrung der User-agents denn generell nicht oder nur für den angegeben Bot. Man kann sich im Browser ja selbst einen bestimmten User-agent einstellen, diesen über die .htaccess sperren und dann die Webseite besuchen und schauen, was sich tut.

    Viele Grüße!
    JoomlaWunder

    Zitat von JoomlaWunder

    RewriteCond %{HTTP_USER_AGENT} ^BadBot1 [NC,OR]
    ......
    RewriteCond %{HTTP_USER_AGENT} ^BadBot-letzter [NC]
    RewriteCond %{REQUEST_FILENAME} !^.*robots\.txt$
    RewriteRule ^.* - [F]

    Die RewriteCond mit HTTP_USER_AGENT funktioneren vermutlich wegen dem ^-Zeichen nicht. Das bedeutet nämlich, dass der "BadBot" am Anfang des HTTP_USER_AGENT stehen muss. Das ist meistens nicht der Fall. Also das ^ rausnehmen oder wie bei dem RewriteCond mit der robots.txt darunter ".*" einfügen.

    Gruß kdh

    Zitat von kdh

    Die RewriteCond mit HTTP_USER_AGENT funktioneren vermutlich wegen dem ^-Zeichen nicht. Das bedeutet nämlich, dass der "BadBot" am Anfang des HTTP_USER_AGENT stehen muss. Das ist meistens nicht der Fall.

    Wenn der user_agent vom Bot beispielsweise BackWeb lautet, trägt man einfach folgendes ein, was auch läuft:
    RewriteCond %{HTTP_USER_AGENT} ^BackWeb [NC,OR]

    Viele Grüße!
    JoomlaWunder

    Auf Grund anderer Notwendigkeiten erst heute wieder Info zum aktuellen Stand.

    Mittels robots.txt, order allow, deny, require-Anweisungen und RewriteCond konnten viele Bots und Spider blockiert werden. Dazu nochmals Dank an die vielen Hinweisgeber. Dabei sind Blockaden mehrfach definiert (z.B. order und Require), aber Optimierung kommt später.

    Insgesamt konnte die Zahl der Zugriffe von bis zu 350.000 am Tag auf unter 80.000 und der Umfang der Log-Dateien (im Webspace) von bis zu 20 GB auf unter 1 GB reduziert werden. Dies sind die Summen für eine Domain und zwei Sub-Domains. Verteilung auf die 3 ist annähernd gleich.

    Ungelöst ist allerdings folgender Eintrag mit wechselnden IP-Adressen:

    23.22.35.0 - - [18/Aug/2024:00:00:13 +0200] "GET /index.php/jeventstestlistbyday-4/week.listevents/2022/12/5/136 HTTP/1.1" 503 299 tsg-dacapo.de "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/600.2.5 (KHTML, like Gecko) Version/8.0.2 Safari/600.2.5 (Amazonbot/0.1; +https://developer.amazon.com/support/amazonbot)" "-"

    Die Einträge bzw. die Zahl der entsprechenden Zugriffe haben einen Anteil von mehr als 95%. Auffällig ist, das immer 503 auftaucht und der Zugriff ausnahmslos auf /jeventstestlistbyday-4/ erfolgt. Und da hilft keine einzige der folgenden Maßnahmen:

    Einträge in Robots.txt

    User-agent: *
    Disallow: /jeventstestlistbyday-4/

    User-agent: Amazonbot
    Disallow: /

    Einträge in der .htaccess (nur in Auszügen, die vollständige .htaccess ist als Textdatei angehängt)

    order allow,deny
    allow from all
    dany from 23.22.35.0 (und andere IP-Adressen)

    <RequireAll>
    Require all granted
    Require not ip 23.22.35.0
    Require not host .amazon.com
    </RequireAll>

    RewriteEngine On
    RewriteBase
    RewriteCond %{HTTP_USER_AGENT} ^.*bot [NC]
    RewriteCond %{REQUEST_FILENAME} !^.*robots\.txt$
    RewriteRule ^.* - [R=403,L]

    Wir haben bislang nichts gefunden, womit diese Zugriffe unterbunden werden können.

    Was mir auf den ersten Blick auf die htaccess aufgefallen ist:

    # Amazon
    deny from 3.224.220.0
    deny from 23.22.35.0
    deny from 52.47.201.0
    deny from 52.70.240.0
    deny from 65.2.171.0
    deny from 185.191.171.0

    Hiermit sperrst du nur die einzelne IP-Adressen z. B. 3.224.220.0 aus, nicht aber z. B. 3.224.220.1 - 3.224.220.255.

    Die Adresse 3.224.220.0 ist Teil des großen Amazon-Bereichs 3.128.0.0 - 3.255.255.255. Den ganzen Bereich kann man sperren indem man angibt:

    deny from 3.128.0.0/9

    deny from 2a03:2880:: funktioniert auch nicht, damit würde nur die ipv6-Adresse 2a03:2880:0:0:0:0:0:0 gesperrt. deny from 2a03:2880 würde alle Adressen, die so beginnen, sperren.

    Eine gute Beschreibung habe ich hier gefunden: https://htaccessbook.com/block-ip-address/

    Gruß, kdh

    Warum setzt du die Sperrung der User-agents nach ganz unten? Es wird empfohlen, die nach oben zu setzen, aber natürlich unterhalb von "RewriteEngine on".

    Und mit dem was in #37 steht, sperrst du aber sehr viel, auch den Googlebot & Co. Soll das so sein?

    Viele Grüße!
    JoomlaWunder

    Zitat von JoomlaWunder

    Warum setzt du die Sperrung der User-agents nach ganz unten? Es wird empfohlen, die nach oben zu setzen, aber natürlich unterhalb von "RewriteEngine on".

    Und an anderer Stelle heißt es, dass order allow, deny nach oben soll. Ist schon verwirrend. Oder ist gemeint, dass es von allen Rewrites als erstes unter "RewriteEngine on" aufgeführt werden soll? Habe übgrigens bislang keine entsprechende Emfehlung gefunden - auch nicht in den Apache Dokumentationen (sind für einen LAien eh' nicht besonders verständlich - ein paar mehr Beipiele wären schon hilfreich).

    Und ja, google soll zunindest in unsere Test- und unserer Entwicklungsumgebung ausgesperrt werden. In unserer Liveumgebung darf es bleiben. Was darüber hinaus in der Liveumgebung bleibt, muss noch geklärt werden.

    Zitat von kdh

    Eine gute Beschreibung habe ich hier gefunden: https://htaccessbook.com/block-ip-address/

    Danke übrigens für diesen Hinweis. Das hat wirklich Klarheit gebracht. Und den Hinweis zu deny from 2a03:2880 habe ich dann auch im Kontext von Require angewendet, was prompt zu einem 500er-Fehler führte, aber die Gewissheit brachte, das IONOS Apache 2.4 einsetzt. Habe dann 2a03:2880::/16 vewendet, was offensichtlich funktioniert.

    Auf jeden Fall sind wir jetzt soweit, dass alles ausgeschlossen wird, was wir nicht haben wollen. Die Ausnahme ist nach wie vor Amazon. Alle Regeln, die z.B. bei bingbot oder GPTbot funktionieren, versagen bei Amazon im Zuammenhang mit 503.

    Gruß

    Heinz

    "Wer es nicht versucht schafft es auch nicht."