Benutzer-Werkzeuge

Webseiten-Werkzeuge


stacks:traefik:traefik-catch-all

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
stacks:traefik:traefik-catch-all [21.08.2026 16:04] larsstacks:traefik:traefik-catch-all [21.08.2026 16:31] (aktuell) – [Wichtige Hinweise für zukünftige Suricata-Alarme] lars
Zeile 8: Zeile 8:
 Die Konfiguration ist historisch gewachsen und wurde insbesondere im Zusammenhang mit Nextcloud eingerichtet. Mehrere Middleware-Regeln entstanden nach umfangreicher Fehlersuche, um Probleme mit Redirects, Security-Headern, WebDAV/CalDAV und anderen Nextcloud-Funktionen zu vermeiden. Die Konfiguration ist historisch gewachsen und wurde insbesondere im Zusammenhang mit Nextcloud eingerichtet. Mehrere Middleware-Regeln entstanden nach umfangreicher Fehlersuche, um Probleme mit Redirects, Security-Headern, WebDAV/CalDAV und anderen Nextcloud-Funktionen zu vermeiden.
  
-<WRAP important>+<WRAP round center important 70%>
 Die bestehenden Middleware-Ketten nicht ohne vorherige Tests vereinfachen oder entfernen. Die bestehenden Middleware-Ketten nicht ohne vorherige Tests vereinfachen oder entfernen.
  
Zeile 130: Zeile 130:
 Zusätzlich existieren einige ''.bak''-Dateien. Zusätzlich existieren einige ''.bak''-Dateien.
  
-<WRAP tip>+ 
 +<WRAP center round tip 80%>
 Bei der Fehlersuche immer zuerst prüfen, welche Dateien tatsächlich aktiv geladen werden und welche lediglich Backups sind. Bei der Fehlersuche immer zuerst prüfen, welche Dateien tatsächlich aktiv geladen werden und welche lediglich Backups sind.
 </WRAP> </WRAP>
Zeile 355: Zeile 356:
 Dadurch können bei Suricata-Ereignissen HTTP-302-Antworten sichtbar werden. Dadurch können bei Suricata-Ereignissen HTTP-302-Antworten sichtbar werden.
  
-<WRAP important>+<WRAP round center 80% important>
 Ein HTTP 302 auf einen Exploit-Pfad bedeutet daher nicht automatisch, dass die angegriffene Anwendung diesen Redirect erzeugt hat. Ein HTTP 302 auf einen Exploit-Pfad bedeutet daher nicht automatisch, dass die angegriffene Anwendung diesen Redirect erzeugt hat.
  
Zeile 493: Zeile 494:
 Die Konfiguration wurde nach umfangreicher Fehlersuche eingeführt, da allgemeinere bzw. strengere Middleware-Regeln wiederholt Probleme mit Nextcloud und einzelnen Funktionen verursachten. Die Konfiguration wurde nach umfangreicher Fehlersuche eingeführt, da allgemeinere bzw. strengere Middleware-Regeln wiederholt Probleme mit Nextcloud und einzelnen Funktionen verursachten.
  
-<WRAP warning>+<WRAP round center 80% warning>
 Nextcloud reagiert empfindlich auf Änderungen an Reverse-Proxy-, Header- und Redirect-Konfigurationen. Nextcloud reagiert empfindlich auf Änderungen an Reverse-Proxy-, Header- und Redirect-Konfigurationen.
  
Zeile 607: Zeile 608:
 </code> </code>
  
-ist ein starker Hinweis auf die eigene Errorpage.+HTTP 418 zusammen mit einer Response-Größe um 38 KB ist ein starker Hinweis auf die eigene Errorpage. Die genaue Größe hängt von der aktuellen Version der index.html ab. Die zufällig angezeigten Sprüche verändern die HTTP-Response-Größe nicht, da sie clientseitig per JavaScript ausgewählt werden.
  
  
Zeile 698: Zeile 699:
 ===== Wartungsregel ===== ===== Wartungsregel =====
  
-<WRAP important>+<WRAP round center 80% important>
 **Never change a running system ohne Rückfallplan.** **Never change a running system ohne Rückfallplan.**
  
stacks/traefik/traefik-catch-all.1787321063.txt.gz · Zuletzt geändert: von lars