RELIANOID Firewall für Webanwendungen #

Die Webanwendungs-Firewall (WAF) fungiert als wichtiges Tool zur Identifizierung und Verhinderung bösartigen HTTP-Verkehrs innerhalb von HTTP(S)-Farmen. Durch die Analyse von Mustern erzwingt es erweiterte Sicherheitsrichtlinien für organisierte Regelsätze, die dann auf HTTP-Farmen angewendet werden. Nach der Entschlüsselung von SSL-Paketen werden die WAF-Regeln geprüft, wodurch die Anwendung von Mustern auf den HTTP-Text innerhalb des SSL-Verkehrs ermöglicht wird.

Die 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.

AktionErlaubte 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 allgemeine Regeln zur Angriffserkennung und bieten ein grundlegendes Schutzniveau für jede Webanwendung.

Betriebsarten #

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

Anomalie-Bewertungsmodus (Standard): Dieser Modus wird aufgrund seiner genauen Protokollinformationen und flexiblen Sperrrichtlinien empfohlen. Er wird auch als „kollaborativer Erkennungsmodus“ bezeichnet und weist jeder übereinstimmenden Regel einen „Anomalie-Score“ zu. Am Ende der Auswertung eingehender und ausgehender Regeln löst der Anomalie-Score Sperraktionen aus, die normalerweise zu einem 403-Standardfehler führen.

Eigenständiger Modus: Dieser Modus wendet Aktionen sofort an. Während der Ressourcenverbrauch reduziert wird, geht die Flexibilität bei Blockierungsrichtlinien und detaillierten Prüfprotokollen verloren (nur die erste erkannte Bedrohung wird protokolliert). Regeln folgen der von Ihnen angegebenen störenden Aktion (z. B. Verweigern, Löschen). Die erste übereinstimmende Regel führt diese Aktion aus, was häufig dazu führt, dass die Auswertung nach der ersten Übereinstimmung beendet wird, ähnlich wie bei vielen IDSs.

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 Set, der ANFRAGE-901-INITIALISIERUNG Regelsatz dient als grundlegendes Element und bietet eine umfassende Palette an Optionen zur Konfiguration des Gesamtverhaltens der Sicherheitsregeln. Er bietet Benutzern die Flexibilität, Einstellungen an spezifische Sicherheitsanforderungen anzupassen und bildet das Rückgrat des Regelkonfigurationsprozesses. Wechseln zu ANFRAGE-949-BLOCKIERUNGS-BEWERTUNG und ANTWORT-959-BLOCKIERUNG-AUSWERTUNG Regelsätze spielen eine entscheidende Rolle bei der proaktiven Sicherheitshaltung, indem sie Blockierungsmaßnahmen auf der Grundlage von Anomaliewerten auswerten und ausführen. Sie tragen wesentlich zur Fähigkeit des OWASP Core Rule Set bei, potenzielle Bedrohungen in Echtzeit zu identifizieren und zu verhindern. Ergänzend dazu ANTWORT-980-KORRELATION Der Regelsatz konzentriert sich auf die Korrelation und Analyse von Antworten und verbessert so die allgemeine Fähigkeit des OWASP Core Rule Set, sich entwickelnde Sicherheitsherausforderungen zu erkennen und effektiv darauf zu reagieren. Zusammen ermöglichen diese Regelsätze Benutzern, ein robustes und anpassbares Sicherheitsframework für ihre Webanwendungen zu implementieren.

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 zu erhöhen Blockieren des Paranoia-Levels, navigiere zum ANFRAGE-901-INITIALISIERUNG Regelsatz, dann Im Raw-Modus bearbeiten und ändern Sie die Regel-ID 901120. Ersetzen setvar:'tx.blocking_paranoia_level=1' mit Ihrem bevorzugten Niveau.

Durch den Einsatz der Erkennungsparanoia-Levelkann man Regeln einer höheren Paranoiastufe ausführen, ohne sie bei der Anomaliebewertung zu berücksichtigen. Diese Flexibilität ermöglicht die Einbindung von Regeln der Paranoiastufe 2 in ein fein abgestimmtes System auf Paranoiastufe 1, wodurch Bedenken hinsichtlich potenzieller falscher Positivwerte gemildert werden, die die Bewertung über den festgelegten Schwellenwert hinaus erhöhen könnten. In der Standardkonfiguration entspricht die Erkennungsparanoiastufe der Blockierungsparanoiastufe. Um die Erkennungsparanoia-Level, navigiere zum ANFRAGE-901-INITIALISIERUNG Regelsatz, dann Im Raw-Modus bearbeiten und ändern Sie die Regel-ID 901125. Ersetzen setvar:'tx.detection_paranoia_level=%{TX.blocking_paranoia_level}' mit Ihrem bevorzugten Niveau (zB. setvar:'tx.detection_paranoia_level=2').

Jeder Regel im CRS wird ein Schweregrad zugewiesen, mit Standard Punkte sammeln zeigt die Auswirkungen auf die Anomaliebewertung wenn eine Regel zutrifft. Die Schweregrade und die entsprechenden Bewertungen lauten 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).

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

Man kann definieren die kumulativer Anomaliewert an dem ein eingehende Anfrage or ausgehende Antwort wird blockiert. Standardmäßig erhalten die meisten erkannten eingehenden Bedrohungen eine kritische Punktzahl von 5, während kleinere Verstöße niedrigere Punktzahlen erhalten. Bei den standardmäßigen Blockierungsschwellenwerten verhält sich das CRS ähnlich wie frühere Versionen und blockiert und protokolliert Anfragen mit einer einzigen kritischen Regelübereinstimmung. Das Anpassen der Blockierungsschwellenwerte auf höhere Werte wie 7 oder 10 kann das CRS weniger empfindlich machen, sodass mehrere Regelübereinstimmungen vor der Blockierung erforderlich sind. Allerdings ist Vorsicht geboten, da durch das Anheben der Schwellenwerte einige Angriffe Regeln oder Richtlinien umgehen können. Alternativ besteht eine empfohlene Bereitstellungsstrategie darin, zunächst hohe Anomaliebewertungsschwellenwerte (>100) festzulegen und diese schrittweise zu senken, wenn das Vertrauen in das System wächst. Dies bietet einen proaktiven Ansatz zur Verbesserung der Sicherheit im Laufe der Zeit.

Standardmäßig ist der Schwellenwert für eingehende Anomalie-Scores auf 5 und der Schwellenwert für ausgehende Anomalie-Scores auf 4 eingestellt. Um den Schwellenwert für eingehende Anomaliebewertung, navigiere zum ANFRAGE-901-INITIALISIERUNG Regelsatz, dann Im Raw-Modus bearbeiten und ändern Sie die Regel-ID 901100. Ersetzen setvar:'tx.inbound_anomaly_score_threshold=5′ mit Ihrem bevorzugten Niveau (zB. setvar:'tx.inbound_anomaly_score_threshold=4′). Dasselbe gilt für die Schwellenwert für die Bewertung von ausgehenden Anomalien mit der Regel-ID 901110 Ersetzung setvar:'tx.outbound_anomaly_score_threshold=4′.

Die Frühzeitige Blockierung des Anomaliebewertungsmodus ermöglicht eine frühzeitige Bewertung der Anforderungs- und Antwortanomaliewerte am Ende von Phase 1 bzw. Phase 3, anstatt bis zum Ende von Phase 2 bzw. Phase 4 zu warten. Das Aktivieren dieses Modus ermöglicht eine sofortige Blockierung, wenn der Anomalieschwellenwert während der frühen Auswertung erreicht wird, wodurch die Ausführung von Phase 2 (bzw. Phase 4) umgangen wird. Um die frühzeitige Blockierung zu aktivieren, aktivieren Sie die Regel-ID 901115 . ANFRAGE-901-INITIALISIERUNG Regelsatz, der die Variable festlegt tx.frühzeitige_blockierung auf 1 (standardmäßig deaktiviert). Es ist wichtig zu beachten, dass eine frühzeitige Blockierung potenzielle Warnungen verbergen kann, da Nutzdaten, die Warnungen der Phase 2 (oder Phase 4) auslösen, bei aktivierter frühzeitiger Blockierung nicht ausgewertet werden. Eine Deaktivierung der frühzeitigen Blockierung in der Zukunft kann neue Warnungen aus Phase 2 aufdecken.

Die Easing-In / Sampling-Prozentsatz Diese Funktion wurde entwickelt, um potenzielle Probleme bei der Integration des CRS in eine bestehende Live-Site zu verringern, 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 Vertrauen in die Einrichtung hergestellt ist, 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.Probenprozentsatz an der Regel-ID 901130 . ANFRAGE-901-INITIALISIERUNG Regelsatz; der Standardwert ist 100, was bedeutet, dass jede Anfrage einer CRS-Prüfung unterzogen wird. 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 Leistungsgründen nicht im Prüfprotokoll eingetragen, es wird jedoch ein Fehlerprotokolleintrag aufgezeichnet. Um den Fehlerprotokolleintrag zu deaktivieren, geben Sie die angegebene Anweisung nach Einbeziehung des CRS ein.