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

Danke für den Hinweis. IPV6 hat ja 4 Zeichen pro Sektion und nicht nur 3.

Danke für die beiden letzten Hinweise. Das war mir so nicht bewußt und daher sehr hilfreich.

Habe das sofort umgesetzt und werde es in unseren "Wartungsplan" aufnehmen.

Nach einiger (Leidens-)-Zeit mit Bots und Konsorten eine Zusammenfassung unserer Erfahrungen (voll umfänglich gültig nur für Apache-Server)

• Ursache für die Sperrung war auf jeden Fall die hohe Netzwerkbelastung (bis zu 40 GByte am Tag) und die hohe Zahl der Zugriffe (bis 350.000 pro Tag). Derzeit liegen wir bei ca. 0,2 bis 0,3 GByte und weniger als 30.000 Zugriffen.
• Facebook war zwar der Auslöser (wie wir herausgefunden haben auf Grund eines Fehlers seitens Facebook, der mittlerweile behoben ist), beachtet aber die robots.txt uneingeschränkt, wie auch einige andere (z.B. Applebot, Barkrowler, DotBot, SemrushBot, die mindestens 4 Bots der Hetzner GmBH, . . .). Eine Steuerung über die .htaccess ist hier nicht erforderlich.
• Andere lesen zwar die robots.txt, beachten sie aber nicht, wie z.B. Amazonbot, bingbot, Googlebot oder Bytespider (von Bytedance bzw. TikTok mit Zugriff über Amazon-Server). Hier muss jede auf die Webseite zugreifende IP-Adresse über die .htaccess mittels require not ip einzeln geblockt werden, wenn nur bestimmte Zugriffe unterbunden werden sollen (z.B. nur die, die mit Bots im Zusammanhang stehen).
• Besonders auffällig ist in diesem Zusammenhang Amazon mit Amazonbot und Bytespider, die besinnungslos auf unsere Webseite zugreifen, obwohl sie keine Info bekommen. Das ist insofern besonders lästig, da Amazon derzeit für bis zu 90 % aller Zugriffe - also bis zu 20.000 oder sogar mehr pro Tag - verantwortlich ist. Als wenn uns diese Firma bestrafen wiil, weil wir den Zugriff verweigern. Glücklicherweise sperrt IONOS von sich aus jeden Datenabgriff bereits mit Returncode 429 (zu häufiger Zugriff).
• Mit Require not host kann sogar ein kompletter Server gesperrt werden. Wirkt in vollem Umfang z.B. bei Applebot (zwar nicht erforderlich (s.o.), haben wir aber trotzdem getestet), was aber nicht immer gewünscht ist. Z.B, wollen wir in einigen Fällen nur bestimmte IP-Adressen blockieren, denn viele Internetprovider nutzen lhre IP-Adressen gezielt nur für Bots oder nur für andere Zwecke.
• Abgesehen davon wirkt der Domainname nur in Ausnahmefällen, obwohl es häufig heißt (auch hier im Forum), dass der Domainname angegeben werden soll. Ein Blick in die Apache-Dokumentation zeigt aber, dass der Host gemeint ist (siehe Require not host host.example.com in https://httpd.apache.org/docs/2.4/howto/access.html). Da Apple Server mit Namen *.ns.apple.com einsetzt, wirkt der Domainname apple.com; amazon.com wirkt dagegen nicht, da Amazon verschiedene Server mit Namen wie *.amzndns.com verwendet. Schließlich heißt es ja auch require not host. Wäre schon gut, wenn Begriffe korrekt verwendet werden. Die Hostnamen einer Domain können übrigens über http://www.whois.com ermittelt werden.
• Neben der Sperrung über die IP-Adresse kann auch über andere .htaccess-Anweisungen wie z.B. RewriteCond %{HTTP_USER_AGENT} ^.*bot geblockt werden. Das wirkt aber nur dann, wenn der Bot-, Crawler oder Spider-Name auch offen gelegt wurde, was ebenfalls nicht immer getan wird oder nur mit sehr befremdlichen Namen (z.B. "InternetMeasurement"). Bleiben zunächst also nur Require not ip oder Require not host als Maßname (oder?) für relative Laien wie uns.
• Abgesehen davon ist die Welt des Rewrite für Anfänger recht komplex. Dazu nur ein Beispiel: bereits hier im Forum gibt es verschiedene Empfehlungen für "RewriteCond %{HTTP_USER_AGENT} ^.*bot". Mal so so oder mal einfach nur mit "bot" oder auch mal "^bot". Für Anfänger wäre eine weiterführende Erklärung was wann die richtige Wahl ist schon sehr hilfreich. (Die Hilfesuchenden im Forum sind oft keine Experten und haben auch nicht immer die Zeit sich vorab vollumfassend zu informieren. Auch die Apache-Dokumentationen sind eher von Experten für Experten geschrieben.)
• Am effektivsten und gezieltesten wirkt im Ergebnis - sofern die Robots.txt nicht beachtet wird - require not ip, was allerdings die .htaccess immer weiter aufblähen kann. Um das zu verhindern blocken wir mittlerweile nur die permanenten "Lästlinge" (d.h. momentan Amazon, TikTok und einige andere), da alle anderen nur in relativ begrenztem Umfang (ca. 100 Zugriffe am Tag) temporär zugreifen oder nur alle paar Tage bzw. Wochen. Verschärfend kommt hinzu, dass besonders die großen Telekom-Firmen wegen ihrer vielen Kunden auch sehr viele Zugriffe haben. Ferner gibt es Bots, die sich nicht zu erkennen geben, auch nicht durch einen Zugriff auf die robots.txt. Da müssen dann IP-Adressen mit auffällig vielen Zugriffen erst einmal zurückverfolgt werden, z.B. über http://www.geolocation.com oder http://www.whois.com, um herauszubekommen, welche Zwecke die häufigen Zugriffe haben. Andernfalls werden sehr schnell Webseitenbesucher fälschlich ausgesperrt.
• Das alles ist natürlich Aufwand, kann aus unserer Sicht aber auf eine einmalige Kontolle der wöchentlichen Logfiles beschränkt werden. IONOS stellt uns die zur Verfügung. Ich denke, dass gilt auch für andere Provider.

Und noch eine Auffälligkeit bei ipv6-Adressen. Wir hatten versucht die Adresse 2a00:6020:4700:: zu blocken - ohne Erfolg. Eine Zurückverfolgung über research.domaintools.com (http://www.whois.com funktioniert mit ipv6 nicht) hat dann die vollständige Adresse ergeben: 2a00:6020:4700::/40. Die Sperrung war dann sofort erfolgreich - allerdings mit dem Effekt, dass für einige Besucher unsere Webseite gesperrt war. Letztlich ein guter Reminder mit einer Sperrung sorgfältig umzugehen. Eventuell haben andere dieses ipv6-Problem nicht, denn es könnte auch sein, dass IONOS im log-File die ipv6-Adressen im Gegensatz zu anderen kürzt. Aber schädlich ist dieser Hinweis sicher nicht.

Ferner eine Anmerkung zur aktuellen Apache-Veresion: bereits seit 2017 wird die Vorgängerversion 2.2 nicht mehr gewartet (siehe https://httpd.apache.org/docs/2.2/). Es kann also davon ausgegangen werden, dass mittlerweile alle Apche-Server auf 2.4 umgestellt worden sind. Weshalb werden dann auch im Forum immer noch veraltetet Anweisungen wie order allow oder order deny propagiert obwohl require ip und require host mindestens genauso einfach anzuwenden sind. Ja, die alten Anweisungen funktionieren auch unter 2.4, aber es gibt auch den Hinweis, dass eine Mischung von alt und neu - z.B. mit rewrite - zu Fehlern führen kann.

Abschließend noch eine Anmerkung zu JEvents: ursächlich ist JEvents nicht für einen umfangreichen Traffic verantwortlich. Wenn allerdings alte Events massenhaft nicht gelöscht werden und auf einen "Lästling" wie Amazon treffen, der auf Basis früher erhaltener Infos (Facebook!) jede verfügbare Information mehrfach abgreift, ist eine hohe Zahl von Zugriffen zwangsläufig. Also teilweise auch unser hausgemachtes Problem.