RELIANOID Firewall für Webanwendungen #

Die Web Application Firewall (WAF) ist ein entscheidendes Werkzeug zur Erkennung und Abwehr schädlichen HTTP-Verkehrs in HTTP(S)-Netzwerken. Durch die Analyse von Verhaltensmustern setzt sie erweiterte Sicherheitsrichtlinien auf Basis organisierter Regelsätze durch, die anschließend auf die HTTP-Netzwerke angewendet werden. Nach der Entschlüsselung der SSL-Pakete werden die WAF-Regeln geprüft, um die Anwendung der Muster auf den HTTP-Body innerhalb des SSL-Verkehrs zu ermöglichen.

Das RELIANOID IPDS Paket beinhaltet die OWASP ModSecurity Kernregelsatz, vorinstalliert und einsatzbereit, während Benutzer die Flexibilität behalten, benutzerdefinierte Regelsätze für einen umfassenden Systemschutz gegen verschiedene Angriffe zu erstellen. Weitere Einzelheiten zu OWASP-Regeln finden Benutzer im OWASP Modsecurity Project. Darüber hinaus ist es erwähnenswert, dass die RELIANOID Das WAF-Modul erweitert seine Funktionalität über den HTTP-Schutz hinaus und umfasst Erweiterte HTTP-Inhaltsmanipulationeinschließlich Umleitungen und schreibt um.

WAF-Regelsatzansicht #

Die WAF-Regelsatzansicht zeigt eine Übersicht der verfügbaren Regelsätze und der zugewiesenen Farmdienste:

Name. Ein beschreibender Name zur Identifizierung eines Regelsatzes. Klicken Sie darauf, um das Bearbeitungsformular aufzurufen.
Farms. Die Farmen, auf die die Regel angewendet wird. Sie können die Farmliste mit einem nach oben zeigenden Pfeil neben dem FARMEN Spaltenüberschrift rechts. Standardmäßig ist die Zahl auf 20 Zeichen begrenzt.
STATUS. Der Regelsatzstatus wird durch die folgenden Statusfarbcodes dargestellt:

• Grün. Bedeutet AKTIVIERT. Der Regelsatz wird für die Farmen überprüft, die ihn verwenden.
• Rot. Bedeutet GESPERRT. Der Regelsatz ist nicht aktiviert und hat daher keine Auswirkung auf die Farm.

Aktionen . Zulässige Aktionen für den Status der WAF-Regeln:

• Bearbeiten. Ändern Sie bei Bedarf die Regelsatzeinstellungen oder weisen Sie einen Farmdienst zu.
• Wiederaufnahme. Initialisieren Sie eine WAF-Regel erneut.
• Start. Wenden Sie den WAF-Regelsatz an.
• Löschen. Entfernen Sie einen Regelsatz.

Grundlegendes zum OWASP CRS-Regelsatzsystem #

Die OWASP CRS- Regelsätze umfassen generische Angriffserkennungsregeln und bieten ein grundlegendes Schutzniveau für jede Webanwendung.

Betriebsarten #

Die vorinstallierten OWASP CRS-Regelsätze funktionieren in zwei Modi:

Anomaliebewertungsmodus (Standard): Dieser Modus wird aufgrund seiner präzisen Protokollinformationen und flexiblen Blockierungsrichtlinien empfohlen. Er wird auch als „kollaborativer Erkennungsmodus“ bezeichnet und weist jeder übereinstimmenden Regel einen Anomaliewert zu. Nach Abschluss der Auswertung eingehender und ausgehender Regeln löst der Anomaliewert Blockierungsmaßnahmen aus, die in der Regel zu einem Standardfehler 403 führen.

Eigenständiger Modus : In diesem Modus werden Aktionen sofort ausgeführt. Dies reduziert zwar den Ressourcenverbrauch, geht aber auf Kosten der Flexibilität bei Blockierungsrichtlinien und detaillierter Audit-Protokolle (nur die erste erkannte Bedrohung wird protokolliert). Regeln folgen der von Ihnen festgelegten Störungsaktion (z. B. Verweigern, Verwerfen). Die erste passende Regel führt diese Aktion aus, was – ähnlich wie bei vielen Intrusion-Detection-Systemen – häufig nach dem ersten Treffer zum Abbruch der Auswertung führt.

Grundlegende OWASP CRS-Regelsätze #

Diese vorinstallierten Schutzregeln sind nach Präferenzen geordnet. Wenn Sie sich für deren Verwendung entscheiden, beachten Sie sie bitte und wenden Sie sie folgendermaßen an:

ANFRAGE-90-KONFIGURATION ANFRAGE-901-INITIALISIERUNG
# Wenden Sie einen beliebigen anderen OWASP-Regelsatz an, je nachdem, was Sie schützen möchten
ANFRAGE-949-BLOCKIERUNG-BEWERTUNG ANTWORT-959-BLOCKIERUNG-BEWERTUNG ANTWORT-980-KORRELATION # zu Protokollierungszwecken, aktivieren Sie dies nur zur Fehlerbehebung.

Innerhalb des OWASP Core Rule Sets dient das Regelset REQUEST-901-INITIALIZATION als Grundlage und bietet umfangreiche Optionen zur Konfiguration des allgemeinen Verhaltens der Sicherheitsregeln. Es ermöglicht Benutzern, Einstellungen präzise an spezifische Sicherheitsanforderungen anzupassen und bildet so das Rückgrat des Regelkonfigurationsprozesses. Die Regelsets REQUEST-949-BLOCKING-EVALUATION und RESPONSE-959-BLOCKING-EVALUATION spielen eine entscheidende Rolle für die proaktive Sicherheitsarchitektur, indem sie Anomaliewerte auswerten und Blockierungsaktionen basierend darauf ausführen. Sie tragen wesentlich dazu bei, dass das OWASP Core Rule Set potenzielle Bedrohungen in Echtzeit erkennen und verhindern kann. Ergänzend dazu konzentriert sich das Regelset RESPONSE-980-CORRELATION auf die Korrelation und Analyse von Antworten und verbessert so die Fähigkeit des OWASP Core Rule Sets, sich entwickelnde Sicherheitsherausforderungen effektiv zu erkennen und darauf zu reagieren. Zusammen ermöglichen diese Regelsets Benutzern die Implementierung eines robusten und anpassungsfähigen Sicherheitsframeworks für ihre Webanwendungen.

Paranoia-Level, Sampling und Anomalie-Score verstehen #

Mit der Einstellung „Paranoia-Level“ können Sie die Intensität der Regelprüfungen festlegen und so die Anomalie-Scores beeinflussen. Höhere Paranoia-Level erhöhen die Sicherheit, indem sie mehr Regeln aktivieren, können jedoch das Risiko erhöhen, dass legitimer Datenverkehr aufgrund von Fehlalarmen blockiert wird. Empfehlungen für die einzelnen Level:

Paranoia Stufe 1 (Standard): Geeignet für Anfänger, verschiedene Installationen und Standard-Sicherheits-Setups, mit seltenen Fehlalarmen.
Paranoia Stufe 2: Empfohlen für mittelmäßige bis erfahrene Benutzer, die umfassenden Schutz und erhöhte Sicherheit wünschen. Rechnen Sie mit einigen Fehlalarmen.
Paranoia Stufe 3: Richtet sich an erfahrene Benutzer im Umgang mit Fehlalarmen für Installationen mit hohen Sicherheitsanforderungen.
Paranoia Stufe 4: Empfohlen für erfahrene Benutzer, die Installationen mit sehr hohen Sicherheitsanforderungen schützen, aber wahrscheinlich eine große Anzahl von Fehlalarmen produzieren, die vor der Inbetriebnahme behoben werden müssen.

Um die Blockierungs-Paranoia-Stufe zu erhöhen , navigieren Sie zum Regelsatz REQUEST-901-INITIALIZATION , bearbeiten Sie ihn im Rohdatenmodus und ändern Sie die Regel-ID 901120. Ersetzen Sie setvar:'tx.blocking_paranoia_level=1′ durch die gewünschte Stufe.

Durch die Verwendung des Paranoia-Levels für die Erkennung können Regeln eines höheren Paranoia-Levels ausgeführt werden, ohne dass diese in die Anomaliebewertung einfließen. Diese Flexibilität ermöglicht die Integration von Regeln des Paranoia-Levels 2 in ein feinabgestimmtes System des Paranoia-Levels 1 und mindert so Bedenken hinsichtlich potenzieller Fehlalarme, die den Score über den festgelegten Schwellenwert hinaus erhöhen könnten. Standardmäßig entspricht der Paranoia-Level für die Erkennung dem Paranoia-Level für die Blockierung. Um den Paranoia-Level für die Erkennung zu erhöhen , navigieren Sie zum Regelsatz „REQUEST-901-INITIALIZATION “, bearbeiten Sie ihn im Rohdatenmodus und ändern Sie die Regel-ID 901125. Ersetzen Sie „setvar:'tx.detection_paranoia_level=%{TX.blocking_paranoia_level}'“ durch den gewünschten Level (z. B. „ setvar:'tx.detection_paranoia_level=2“ ).

Jeder Regel im CRS ist ein Schweregrad zugeordnet, wobei die Standardpunktzahl die Auswirkung auf die Anomaliebewertung bei Übereinstimmung einer Regel angibt. Die Schweregrade und ihre entsprechenden Punktzahlen sind wie folgt:

KRITISCH: Anomalie-Score von 5, hauptsächlich aufgrund von Anwendungsangriffsregeln (93x- und 94x-Dateien).
ERROR: Anomalie-Score von 4, überwiegend durch Outbound-Leakage-Regeln generiert (95x Dateien).
WARNUNG: Anomalie-Score von 3, hauptsächlich ausgelöst durch bösartige Client-Regeln (91x Dateien).
HINWEIS: Anomalie-Score von 2, hauptsächlich aufgrund von Protokollregeln (92x Dateien).

Im Anomaliemodus werden diese Werte akkumuliert, sodass eine einzelne Anfrage mehrere Regeln auslösen kann. Anpassungen dieser Standardwerte sind im Allgemeinen nicht erforderlich, können aber je nach spezifischen Anforderungen individuell angepasst werden.

Es kann der kumulative Anomalie-Score definiert werden , ab dem eine eingehende Anfrage oder ausgehende Antwort blockiert wird. Standardmäßig erhalten die meisten erkannten eingehenden Bedrohungen einen kritischen Score von 5, während kleinere Verstöße niedrigere Scores nach sich ziehen. Bei den standardmäßigen Blockierungsschwellenwerten verhält sich das CRS ähnlich wie frühere Versionen: Anfragen werden bei einer einzigen kritischen Regelübereinstimmung blockiert und protokolliert. Durch Anpassen der Blockierungsschwellenwerte auf höhere Werte, z. B. 7 oder 10, kann das CRS weniger empfindlich werden, sodass mehrere Regelübereinstimmungen vor einer Blockierung erforderlich sind. Es ist jedoch Vorsicht geboten, da höhere Schwellenwerte es einigen Angriffen ermöglichen können, Regeln oder Richtlinien zu umgehen. Alternativ empfiehlt sich eine Bereitstellungsstrategie, bei der zunächst hohe Anomalie-Score-Schwellenwerte (>100) festgelegt und diese mit zunehmendem Vertrauen in das System schrittweise gesenkt werden. Dies bietet einen proaktiven Ansatz zur Verbesserung der Sicherheit im Laufe der Zeit.

Standardmäßig ist der Schwellenwert für die Anomaliebewertung eingehender Verbindungen auf 5 und der für ausgehende Verbindungen auf 4 festgelegt. Um den Schwellenwert für die Anomaliebewertung eingehender Verbindungen zu ändern , navigieren Sie zum Regelsatz REQUEST-901-INITIALIZATION , wählen Sie „Im Rohdatenmodus bearbeiten “ und ändern Sie die Regel-ID 901100. Ersetzen Sie „setvar:'tx.inbound_anomaly_score_threshold=5'“ durch den gewünschten Wert (z. B. „setvar:'tx.inbound_anomaly_score_threshold=4'“ ). Gehen Sie analog für den Schwellenwert für die Anomaliebewertung ausgehender Verbindungen vor, indem Sie in der Regel-ID 901110 „setvar:'tx.outbound_anomaly_score_threshold=4'“ ersetzen.

Der Modus „Frühe Anomaliebewertung“ ermöglicht eine frühzeitige Beurteilung der Anomaliewerte von Anfragen und Antworten direkt nach Abschluss von Phase 1 bzw. Phase 3, anstatt bis zum Ende von Phase 2 bzw. Phase 4 zu warten. Wird der Anomalieschwellenwert während der frühen Auswertung erreicht, erfolgt eine sofortige Blockierung, wodurch die Ausführung von Phase 2 (bzw. Phase 4) übersprungen wird. Um die frühe Blockierung zu aktivieren, aktivieren Sie die Regel-ID 901115 im Regelsatz REQUEST-901-INITIALIZATION . Dadurch wird die Variable tx.early_blocking auf 1 gesetzt (standardmäßig deaktiviert). Wichtig: Die frühe Blockierung kann potenzielle Warnmeldungen verschleiern, da Nutzdaten, die Warnmeldungen aus Phase 2 (oder Phase 4) auslösen, bei aktivierter früher Blockierung nicht ausgewertet werden. Die spätere Deaktivierung der frühen Blockierung kann neue Warnmeldungen aus Phase 2 aufdecken.

Die Funktion „Einführungsschritt / Stichprobenprozentsatz“ dient dazu, potenzielle Probleme bei der Integration des CRS in eine bestehende Live-Website zu minimieren, wie z. B. Fehlalarme und unerwartete Leistungseinbußen. Um das CRS vorsichtig einzuführen, können Sie es zunächst für eine begrenzte Anzahl von Anfragen aktivieren. Sobald alle Probleme behoben sind und Sie Vertrauen in die Konfiguration haben, können Sie den Anteil der Anfragen, die dem Regelsatz unterliegen, schrittweise erhöhen. Passen Sie den Prozentsatz der von den Kernregeln verarbeiteten Anfragen an, indem Sie `tx.sampling_percentage` in der Regel-ID 901130 innerhalb des Regelsatzes `REQUEST-901-INITIALIZATION` festlegen . Der Standardwert ist 100 %, d. h. jede Anfrage wird einer CRS-Prüfung unterzogen. Die Auswahl der geprüften Anfragen basiert auf einer von ModSecurity generierten Pseudozufallszahl. Wenn eine Anfrage ohne CRS-Prüfung durchgelassen wird, wird sie aus Performancegründen nicht im Audit-Log protokolliert, jedoch ein Fehlerprotokolleintrag erstellt. Um den Fehlerprotokolleintrag zu deaktivieren, geben Sie die angegebene Direktive nach dem Einbinden des CRS ein.