Hiiilfee - komisches Verhalten seit letzem Onyx 17.8.x Update (#60, 14.7. 6:30)

otto

Die 5k-Labertasche
Lizenzinhaber
Registriert
11. Dez. 2010
Beiträge
5.180
Punkte
448
XF Version
  1. 2.2.15
XF Instanz
Hosting
PHP-Version
8.2.x
MySQL/MariaDB
10.3.x
Provider/Hoster
Strato/Hetzner
Hallo,

mein Server treibt mich aktuell in den Wahnsinn....

Bis gestern Abend war alles OK, alle Seiten schnell bzw. schnell genug ladend. Seit heute morgen ist eine Domain (eine Seite, ein Xenforo 1.5.x) plötzlich Arsch langsam geworden. Seiten Ladezeiten von 20 Sekunden und länger im Vergleich zu 1,5 Sekunden zuvor im Schnitt.

Das einzige was sich mWn. geändert hat, ist ein Update
Anhang anzeigen 8815
von heut morgen, von Plesk - ansonsten wurden weder Foren noch Server aktiv seit 3 Wochen angefasst, nichts geändert.

ALLE Domains außer eine laufen gewohnt schnell. D.h. auch ein weiteres Xenforo 1.5.x rennt wie gewohnt nur das eine lahmt seither mit quälend langsamen Seitenaufbau.

- Redis ist aktiv und wird genutzt (Xon Addon 1.6.0, Redis 3.x)
- Opcache ist aktiv
- alle statischen Cache Settings (expire, etag, etc. wurde nicht geändert sind auf beiden Xenforos gleich) sind gesetzt.

Was mir auffällt, die Weiterleitungen (Root \ zu Verzeichnis \xf bzw. \forum unterscheiden sich erheblich. Beide Domains werden mit identischen Settings (IP, dmarc, ...) beim gleichen Anbieter gehostet und auf den Server geleitet.


Ich weiß mir im Moment keinen Rat - bin für jede Zielführende Idee dankbar.
 
Zuletzt bearbeitet:
Bonusfrage:
Wie kann man die "Umleitung" von http zu https bei einem Aufruf von "domain.de" verhindern? Geht das überhaupt?

Oder ist diese Umleitung unvermeidbar beim Einsatz von https ?

Ich überlege, auch die Foren aus deren Unterverzeichnissen ins root umzuziehen - hat da jemand nen schnellen Link zur Hand was man beachten sollte? Beide Foren nutzen Xenforo und XenPorta sowie Redis Cache um mal die vermutlich relevanten Knackpunkte aufzuzählen.

Auch hier - danke für jeden weiter helfenden Tipp. :)
 
Zuletzt bearbeitet:
Echt seltsam und reproduzierbar. Mein erster Weg wäre der Support des Serverbetreibers, alles andere ist Kaffeesatzleserei.
 
Nun ...
mein Server treibt mich aktuell in den Wahnsinn....
Es ist ein dedicated root server - also muss ich mich selbst kümmern. Aber was mich stutzig macht, das es halt nur eine von rund 20 Domains auf dem Server betrifft und dies nach einem Serverweiten Update von Onyx, was auch Zufall sein kann, aber im Moment mein einziger Anhaltspunkt.
 
Kann dicht gemacht werden, hatte Sonntag dann doch noch die Lösung des Rätsels gefunden...
 
Lass uns doch bitte teilhaben.
 
War am Ende einfach zu einfach um war zu sein.

Ich hab ne recht gut funktionierende Lastverteilung und Quota auf meinem Server eingerichtet, dazu natürlich Firewall, mod_sec etc. Da mod_Sec Anfangs aber Amok lief, hatte ich das erstmal auf "Beobachten und abwarten" gestellt. D.h. es konnte DDoS z.B. problemlos erkennen, aber das wars dann auch.
Und genau das war es. Ein DDoS Versuch über eine chinesische IP - was am Ende kein Chinese gewesen sein muss, wie euch sicher klar ist.

Gegenmaßnahmen:
  1. mod_sec scharf geschaltet
  2. server wide IP-blocking in der Firewall um einen weiteren chinesischen IP-Block erweitert
  3. Lastverteilung angepasst (die arbeitete ne Idee zu gut, mMn. )
Was mich halt anfangs aus dem Konzept brachte, das nur eine Domain betroffen war, die anderen gar nicht und der Server dennoch bei nur niedrigen einstelligen Prozenten ausgelastet wurde.

Das nächste mal dürfte mod_sec je nun selbst eingreifen und dem Treiben eher einen Riegel vor schieben und der Server gibt je Domain auch was mehr Leistung frei, wenns Not tut. Allerdings war es auch schön zu sehen, wie prima man die einzelnen Projekte gegeneinander abgrenzen kann was die Ressourcenauslastung anbelangt. Sprich ein einzelner Angriff auf einen Teilbereich reißt nicht direkt den gesamtem Server ins verderben.

Ach ja, die Angriffe fanden (zufällig?) seit kurz nach dem letzen Update von Plesk statt. Daher lag da mein Anfangsverdacht.
 
Mod_security habe ich bei unserem XF deaktivieren müssen. Ich konnte nicht nachvollziehen warum, aber immer wenn das mitläuft kommt es bei den Nutzern zu unvorhersehbaren Fehlfunktionen. Mal "verlieren" sie Rechte, mal wird das Erstellen von Postings geblockt...
 
Zuletzt bearbeitet:
In der originalen .htaccess gibt es Hinweistexte bei verschiedenen Zeilen. Ich meine die hier:
Code:
#    Mod_security can interfere with uploading of content such as attachments. If you
#    cannot attach files, remove the "#" from the lines below.
#<IfModule mod_security.c>
#    SecFilterEngine Off
#    SecFilterScanPOST Off
#</IfModule>
Hast du mal ausprobiert, ob das auskommentieren hilft? Man muss evtl. Mod_security nicht ganz ausschalten.
 
Meinst du Masetrix oder mich? Weil ich hab mit Mod_sec aktuell keine Probleme, hatte es zuvor halt lediglich nicht komplett scharf geschaltet.

Kommt halt stark auf die verwendeten Filterregeln an, die kann man aber ja einzeln an- und ausschalten sowie bearbeiten. So dass man halt erst schaut welche Regel angesprungen ist (Logs) und diese dann anpasst oder wenn nichts hilft deaktiviert.
 
In der originalen .htaccess gibt es Hinweistexte bei verschiedenen Zeilen. Ich meine die hier:
Code:
#    Mod_security can interfere with uploading of content such as attachments. If you
#    cannot attach files, remove the "#" from the lines below.
#<IfModule mod_security.c>
#    SecFilterEngine Off
#    SecFilterScanPOST Off
#</IfModule>
Hast du mal ausprobiert, ob das auskommentieren hilft? Man muss evtl. Mod_security nicht ganz ausschalten.

Danke, das verwende ich für die Domain bereits. Auf den restlichen Domains ist Mod_sec natürlich aktiv. :) Allerdings verwende ich auch keine .htaccess Dateien mehr sondern habe alle dahingehend relevanten Daten in der vhost_ssl.conf abgelegt. Diese wird immer im Ram gehalten und erzeugt auch nicht - wie das bei der .htaccess der Fall ist - bei jedem Zugriff darauf, einen Suchlauf im Dateisystem/Verzeichnisbaum. Nachteil, Änderungen erfordern einen Neustart des Apachen.
 
Zurück
Oben