Das Open Web Application Security Project® (OWASP) ist eine Dachorganisation mit mehreren Projekten unter den Fittichen. Das OWASP ModSecurity Core Rule Set (abgekürzt CRS) ist eines seiner
Vorzeigeprojekte. CRS ist eine Reihe generischer Regeln zur Erkennung von Angriffen für die Verwendung mit ModSecurity oder kompatibler Web Application Firewall (WAF). Das Core Rule Set zielt darauf ab, Webanwendungen mit einem Minimum an falschen Sicherheitsrisiken vor einer Vielzahl von Sicherheitsrisiken zu schützen. Dazu gehören die in den OWASP Top Ten beschriebenen Risiken.
Das Core Rule Set läuft auf der äußerst beliebten ModSecurity WAF Engine. Die ModSecurity-Engine ermöglicht es Administratoren, ihre eigenen Regeln zu schreiben oder auf bekannte kommerzielle Angebote von Atomicorp, Comoro oder Trustwave Spiderlabs zurückzugreifen. Im Gegensatz zu den kommerziellen Angeboten sind die OWASP CRS eher allgemeiner Natur und decken eine viel größere Anzahl von Anwendungen mit einer breiteren Angriffsfläche ab. Das bedeutet, dass die OWASP CRS Sie eher vor allgemeinen Angriffen schützen als vor individuellen, bekannten Exploits. So gibt es beispielsweise keine Regeln für alle bekannten SQL-Injection-Angriffe, sondern eine kleine Gruppe von Regeln, die Ihre Anwendung vor jedem Angriff schützen, der wie ein SQL-Injection-Angriff aussieht. Dadurch wird der Schutz vor Zero-Day- und anderen unbekannten Angriffen erheblich verbessert.
Dieser generische Ansatz hat das CRS zu einem der beliebtesten WAF-Regelsätze im Internet gemacht. Durch seine Installation werden weltweit über 100 TBit/s an Datenverkehr geschützt. Dies haben wir mit Hilfe großer Integratoren erreicht: Amazon AWS, Microsoft Azure, Google Cloud, Verizon Media, Akamai, Cloudflare, Fastly usw. - sie alle verfügen über ein CRS-Angebot in irgendeiner Form. Kemp befindet sich also in sehr guter Gesellschaft, wenn es die Priorität darauf legt, Ihnen einen LoadMaster mit einer vorinstallierten ModSecurity / CRS Web Application Firewall zu liefern.
Der größte Vorteil ist, dass eine generische SQL-Injektionsregel Sie auch vor neuen und unbekannten SQL-Injektionen schützt - oder zumindest mit einer sehr hohen Wahrscheinlichkeit. Das bedeutet, dass Sie sich nicht immer beeilen müssen, wenn ein neuer Exploit auftaucht oder ein neues CVE veröffentlicht wird. Um einen vollständigen Schutz zu gewährleisten, empfiehlt Kemp, dass die Sicherheitsupdates für die Anwendung so angewendet werden, wie es vom Eigentümer der Anwendung empfohlen wird.
Die Chancen stehen gut, dass CRS Sie abdeckt und Sie Zeit haben, Ihre Software zu aktualisieren / zu patchen. Das bedeutet, dass ModSecurity und CRS als erste Verteidigungslinie dienen, die Ihnen Zeit und guten Schlaf verschafft. Es ist keine Überraschung, dass die "erste Verteidigungslinie" auch das Motto von CRS ist.
Werden Sie jetzt nicht faul und vergessen Sie die Sicherheit! Dies ist keine Wunderwaffe. Aber CRS entfernt das Rauschen aus Ihrem Datenverkehr und blockiert die meisten Sicherheitsscans und alle eklatanten HTTP-Angriffe. So können Sie sich auf die wahren Feinde Ihrer Internetpräsenz konzentrieren. Tuning ist der Schlüssel. Und das ist vielleicht der Hauptunterschied zu den kommerziellen und mehr auf Exploits ausgerichteten Regelsätzen: Der generische Ansatz führt zu falsch positiven Ergebnissen. Selbst bei der Standardinstallation, bei der wir wirklich versuchen, sie zu vermeiden. Dieses Phänomen der Falschmeldungen macht es erforderlich, die Fehlalarme zu beseitigen.
Die generische Natur von CRS ermöglicht es, dass die Installation mit relativ wenigen Regeln auskommt: etwa 200, abhängig von der genauen Konfiguration. Vergleichen Sie dies mit den Tausenden von Regeln der oben genannten kommerziellen Angebote. Dies weist in die Richtung einer tiefgreifenden Geschwindigkeits- und Konfigurationsvorteil, da es sehr schwierig ist, den Überblick über 200 Regeln zu behalten, geschweige denn über 5.000. Ich habe über allgemeine Regeln gesprochen, aber wie funktioniert das in der Praxis? Hier ist ein Beispiel: Regel 942430 prüft auf Sonderzeichen in einem Parameter, der über HTTP übermittelt wird. Alles, was ein Dutzend oder mehr Sonderzeichen enthält, wird nach dieser Regel als Angriff betrachtet. Es weiß nichts über webbasierte Angriffe; Es weiß sehr gut, dass ein gutartiger Parameter selten 12 Sonderzeichen enthält. 12 Sonderzeichen und diese Regel riecht wie eine Ratte. 942430 ist eine starke Regel, die viele Angriffe gestoppt hat.
Aufgrund des generischen Charakters von CRS ist die Installation mit relativ wenigen Regeln möglich: etwa 200, je nach genauer Konfiguration. Vergleichen Sie dies mit den Tausenden von Regeln der oben genannten kommerziellen Angebote. Dies deutet auf einen erheblichen Geschwindigkeits- und Konfigurationsvorteil hin, denn es ist sehr schwer, den Überblick über 200 Regeln zu behalten, geschweige denn über 5.000. Ich habe von generischen Regeln gesprochen, aber wie funktioniert das in der Praxis? Hier ist ein Beispiel: Regel 942430 prüft auf Sonderzeichen in einem über HTTP übermittelten Parameter. Alles, was ein Dutzend oder mehr Sonderzeichen enthält, wird von dieser Regel als Angriff betrachtet. Sie weiß nichts über webbasierte Angriffe; sie weiß sehr wohl, dass ein harmloser Parameter selten 12 Sonderzeichen enthält. 942430 ist eine starke Regel, die schon viele Angriffe verhindert hat.
Aber natürlich ist die Grenze von 12 Sonderzeichen sehr willkürlich. Es hängt wirklich von Ihrem Sicherheitsbedürfnis ab oder davon, wie viel Sie bereit sind, in die Abstimmung des Regelsatzes zu investieren. Wenn Sie eine höhere Sicherheitsstufe als die Standardinstallation konfigurieren möchten, können Sie die so genannte Paranoia-Stufe anheben. Dadurch werden zusätzliche Regeln aktiviert. Unter diesen Regeln befindet sich ein Geschwisterchen von 942430. Diese Geschwisterregel hat die gleiche Idee, aber sie setzt die Grenze auf acht Sonderzeichen. Und dann gibt es noch ein weiteres Geschwisterchen, das die Grenze auf zwei setzt.
Je höher Sie Ihre Paranoia-Stufe einstellen, desto mehr Fehlalarme werden Sie erhalten. Falschmeldungen sind der Preis, den Sie für eine strengere Sicherheitsvorkehrung durch eine höhere Paranoia-Stufe zahlen müssen. Es ist, als würde man sich einen tollwütigen Hund halten: Ein solcher Hund macht es für Einbrecher immer schwieriger, in Ihr Haus einzudringen. Aber Sie sollten Ihren Hund besser im Zaum halten, wenn der Pizzabote an der Tür klingelt.
Die Einstellung der Paranoia-Stufe ist zwar wichtig, aber nicht das wichtigste Merkmal des CRS. Diese Funktion ist die Anomalie-Bewertung. Anomalie-Bewertung bedeutet, dass CRS eine Anfrage nicht sofort blockiert. Stattdessen trennt es die Erkennung von der Entscheidung über die Blockierung. Wenn eine Regel ausgelöst wird, weil sie auf ein bestimmtes Muster in einer Anfrage gestoßen ist, erhöht sie den Anomalie-Score der Anfrage. Eine separate Regel, die ausgeführt wird, prüft dann die Gesamtpunktzahl der Auffälligkeit. Diese separate Regel führt die Blockierungsentscheidung auf der Grundlage des Schwellenwerts für Anomalien durch.
Das klingt vielleicht übermäßig kompliziert, aber es verleiht dem CRS-Betrieb eine große Flexibilität. Neue Installationen können zunächst einen sehr hohen Schwellenwert erhalten - und daher von Anfang an mit aktiviertem Blockiermodus laufen. Und dann kann man den Schwellenwert für den Anomalienmodus über mehrere Iterationen nach unten verschieben, während man die falsch-positiven und die gutartigen Anfragen im Auge behält.
Bei einem Regelsatz, der sofort blockiert (wie die erwähnten kommerziellen Regelangebote), müssen Sie im Überwachungsmodus arbeiten, bis Sie zu 100 % sicher sind, dass alles perfekt ist. Sie tun dies, während Sie auf den großen Tag warten, an dem Sie in den Blockiermodus wechseln. Und dieser Tag kommt bei vielen Webanwendungsinstallationen nie.
Bei der Bewertung von Anomalien ist ein schrittweiser Ansatz möglich. Man beginnt vom ersten Tag an im Blockiermodus und wird dann immer strenger, wenn man mehr über das System erfährt und es schafft, die Fehlalarme zu beseitigen. In die neueste Version von Kemp sind wertvolle Verbesserungen gegenüber der vorherigen WAF-Implementierung eingeflossen, was zu einer verbesserten Erfahrung für die Administratoren der LoadMaster WAF führt.
Nachdem wir nun den grundlegenden Hintergrund des Core Rule Sets vorgestellt haben, werden wir in der nächsten Woche einige praktische Beispiele für diese Erweiterungen und den Wert, den das Core Rule Set mit sich bringt, wenn sie auf dem LoadMaster ausgeführt werden, zeigen.
Wenn Sie derzeit die Web Application Firewall (WAF) verwenden möchten, sollten Sie sich die Kemp WAF hier ansehen...
Teil 1: Einführung in OWASP CRS Teil 2: Wie führt man OWASP CRS auf dem Load Master aus? Teil 3: Bereitstellen von benutzerdefinierten Regeln Teil 4: Falsch-Positiv-AnalyseTeil 5: Berichterstattung