Modsecurity Core Rule Sets und Eigene Regeln

ModSecurity ist eine plattformübergreifende Open-Source-WAF-Engine (Web Application Firewall) für Apache, IIS und Nginx, die von SpiderLabs von Trustwave entwickelt wurde. Sie verfügt über eine robuste, ereignisbasierte Programmiersprache, die Schutz vor einer Reihe von Angriffen auf Webanwendungen bietet und die Überwachung des HTTP-Verkehrs, Protokollierung und Echtzeitanalyse ermöglicht.

ModSecurity ist nur die Engine selbst, sie benötigt Regeln, um nützlich zu sein. Diese Regeln sind Anweisungen darüber, was in Anfragen zu suchen ist und was zu tun ist, wenn eine Anfrage einer Regel entspricht.

Da Regeln mit anderen Regeln zusammenarbeiten müssen, um eine breite Sicherheitsabdeckung zu gewährleisten, werden Regeln in Gruppen, den sogenannten “Rulesets”, zusammengefasst. Darüber hinaus unterstützt ModSecurity Version 3 Regeln, die die Verarbeitung zukünftiger Regeln beeinflussen, sodass Regeln nicht immer allein agieren und für die Zusammenarbeit konzipiert werden müssen.

Core rules set

Core Rule Set (CRS) ist ein Satz generischer Angriffs-Erkennungsregeln zur Verwendung mit ModSecurity oder kompatiblen Web Application Firewalls. Das CRS zielt darauf ab, Webanwendungen vor einer breiten Palette von Angriffen zu schützen, einschließlich der OWASP Top Ten, mit einem Minimum an Fehlalarmen.

Benutzerdefinierte Regeln

Grundsätzlich wird empfohlen, Änderungen an den Dateien des Kernregelsatzes so weit wie möglich einzuschränken. Je mehr Sie die einzelne, bereits vorhandene Regeln selbst ändern, desto unwahrscheinlicher wird es, dass Sie auf neuere Versionen aktualisieren möchten, da Sie Ihre Anpassungen neu erstellen müssten. Wir empfehlen, dass Sie versuchen, Ihre Änderungen auf die Datei(en) mit den benutzerdefinierten Regeln zu beschränken, die speziell für Ihre Website gelten. Hier sollten Sie neue Signaturen hinzufügen und auch Regeln erstellen, um False Positives aus den normalen Core Rules-Dateien auszuschließen.  

Regel IDs

Für benutzerdefinierte Regeln müssen Sie eigene Regel-IDs erstellen, welche eindeutig sein müssen. Die “id:” Felder beinhalten die IDs der Regeln. Für benutzerdefinierte Regeln sollten Sie den lokalen (internen) Verwendungsbereich verwenden (siehe unten für die reservierten ID-Bereiche). Verwenden Sie keine zugewiesenen Bereiche.

 

ID’sVerwendung
1-99.999Reserviert für den lokalen (internen) Gebrauch. Verwenden Sie diesen Bereich nach eigenem Ermessen, aber nicht für Regeln, die an andere verteilt werden.
100.000-199.999Regeln von Oracle
200.000-299.999Regeln von Comodo
300.000-399.999Regeln von gotroot.com
400.000-419.999Ungenutzt (zur Reservierung verfügbar)
420.000-429.999Regeln von ScallyWhack
430.000-439.999Regeln von Flameeyes
440.000-599.999Ungenutzt (zur Reservierung verfügbar)
600.000-699.999Regeln von Akamai
700.000-799.999Regeln von Ivan Ristic
900.000-999.999Regeln des OWASP ModSecurity Core Rule Set Projektes
1.000.000-1.009.999Regeln des Redhat Security Team’s
1.010.000-1.999.999Ungenutzt (zur Reservierung verfügbar)
2.000.000-2.999.999Regeln des SpiderLabs Research Teams von Trustwave
3.000.000-3.999.999Regeln von Akamai
4.000.000-4.099.999Regeln von AviNetworks
 4.100.000-4.199.999 Regeln von Fastly
4.200.000 und mehrUngenutzt (zur Reservierung verfügbar)

Regel Syntax

Eine ModSecurity-Regel wird manchmal auch als SecRule bezeichnet, weil jede Regeldefinition mit dem Wort “SecRule” beginnt, das am Anfang der Regeldefinition steht.

Nach dem Wort “SecRule” folgen die vier verwendbaren Teile der Regel:

Variablen zur Definition, welche Teile der Anfrage untersucht werden sollen.
Operatoren legen fest, wann eine Regelübereinstimmung ausgelöst werden soll.
Transformationen bestimmen, wie die Daten der Variablen zu normalisieren sind.
Aktionen definieren, was zu tun ist, wenn eine Regel zutrifft.

Diese werden wie folgt zu einer Regel zusammengefasst:

				
					SecRule VARIABLEN "OPERATOREN" “TRANSFORMATIONEN,AKTIONEN“

				
			

Variablen

VariableVerwendung
ARGSIst eine Sammlung, d. h. alle Argumente einschließlich der POST-Nutzlast.
ARGS_GETEnthält nur Query-String-Parameter.
ARGS_POSTEnthält Argumente aus dem POST-Body.
FILESEnthält eine Sammlung von Originaldateinamen. Nur bei inspizierten multipart/form-data-Anfragen verfügbar.
FULL_REQUESTEnthält die vollständige Anfrage: Anforderungszeile, Anforderungskopfzeilen und Anforderungstext.
QUERY_STRINGEnthält den Query-String-Teil einer Anfrage-URI. Der Wert in QUERY_STRING wird immer im Rohzustand bereitgestellt, ohne dass eine URL-Dekodierung stattfindet.
REQUEST_BODYEnthält den Rohkörper der Anfrage. Diese Variable ist nur verfügbar, wenn der URLENCODED-Anfragekörperprozessor verwendet wurde, was standardmäßig der Fall ist, wenn der Inhaltstyp application/x-www-form-urlencoded erkannt wird, oder wenn die Verwendung des URLENCODED-Anfragekörperparsers erzwungen wurde.
REQUEST_HEADERSDiese Variable kann entweder als Sammlung aller Header einer Anfrage oder zur Überprüfung ausgewählter Header verwendet werden.
REQUEST_METHODDiese Variable enthält die in der Transaktion verwendete Anfragemethode.
REQUEST_URIDiese Variable enthält die vollständige Anfrage-URL einschließlich der Query-String-Daten (z. B. /index.php? p=X).

Operatoren

Hier wird eine “regular expression” (regex), ein Muster oder ein Schlüsselwort angegeben, das in der/den Variablen geprüft werden soll. Die Operatoren beginnen mit dem Zeichen @. Die vollständige Liste der Operatoren finden Sie hier.

Transformationen

Transformationsfunktionen werden verwendet, um Eingabedaten zu verändern, bevor sie für den Abgleich (d. h. die Ausführung des Operators) verwendet werden. Die Eingabedaten werden nie verändert, wenn Sie die Verwendung einer Transformationsfunktion anfordern. ModSecurity erstellt eine Kopie der Daten, transformiert sie und führt dann den Operator mit dem Ergebnis aus.
Mehr Informationen hier.

Aktionen

AktionVerwendung
DisruptiveWird verwendet, damit ModSecurity eine Aktion durchführen kann, z.B. erlauben oder blockieren
Non-disruptiveEtwas tun, aber dieses Etwas hat keinen Einfluss auf den Ablauf der Regelverarbeitung. Das Setzen einer Variablen oder das Ändern ihres Wertes ist ein Beispiel für eine nicht-unterbrechende Aktion. Nicht-unterbrechende Aktionen können in jeder Regel vorkommen, einschließlich jeder Regel, die zu einer Kette gehört.
FlowDiese Aktionen wirken sich auf den Regelablauf aus (z.B. skip oder skipAfter).
Meta-dataMetadaten-Aktionen werden verwendet, um weitere Informationen über Regeln bereitzustellen. Beispiele sind id, rev, severity und msg.
DataHierbei handelt es sich nicht wirklich um Aktionen, sondern lediglich um Container, die Daten enthalten, die von anderen Aktionen verwendet werden. Zum Beispiel enthält die Status-Aktion den Status, der für die Sperrung verwendet wird (wenn sie stattfindet).

Regeln Schreiben

Hier ist ein Beispiel für eine einfache Regel, die eine Anfrage blockiert, wenn der Anfragepfad (nach der Normalisierung in Kleinbuchstaben) gleich /index.php ist.

				
					SecRule REQUEST_URI "@streq /index.php” “id:1,phase:1,t:lowercase,deny"
				
			
AktionVerwendung
SecRuleJede Regeldefinition beginnt mit dem Wort “SecRule” als Anfang der Regeldefinition.
REQUEST_URIDiese Variable enthält die vollständige Anfrage-URL einschließlich der Query-String-Daten (z. B. /index.php? p=X). Sie enthält jedoch niemals einen Domänennamen, selbst wenn dieser in der Anfragezeile angegeben wurde.
“@streq /index.php”Führt einen Stringvergleich durch und gibt true zurück, wenn der Parameterstring mit dem Eingabestring identisch ist. In unserem Fall /index.php.
“id:1,phase:1,t:lowercase,deny”Konvertiert alle Zeichen in Kleinbuchstaben, stoppt die Regelverarbeitung und fängt die Transaktion ab.

In der Praxis sind die meisten Vorschriften nicht so einfach. Im Folgenden finden Sie ein Beispiel für eine aktuelle Vorschrift aus dem CRS.

				
					SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "@rx (?i)union.*?select.*?from" \
    "id:942270,\
    phase:2,\
    block,\
    capture,\
    t:none,t:urlDecodeUni,\
    msg:'Looking for basic sql injection. Common attack string for mysql, oracle and others',\
    logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
    tag:'application-multi',\
    tag:'language-multi',\
    tag:'platform-multi',\
    tag:'attack-sqli',\
    tag:'paranoia-level/1',\
    tag:'OWASP_CRS',\
    tag:'capec/1000/152/248/66',\
    tag:'PCI/6.5.2',\
    ver:'OWASP_CRS/3.3.0',\
    severity:'CRITICAL',\
    setvar:'tx.sql_injection_score=+%{tx.critical_anomaly_score}',\
    setvar:’tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'"
				
			

Vielleicht haben Sie den „Operator” – Teil in der obigen Regel bemerkt:

				
					@rx (?i)union.*?select.*?from

				
			

Diese seltsam aussehende Zeichenfolge ist eine sogenannte “regular expression”, auch bekannt als Regex. Regex ist eine leistungsfähige Sprache für den Musterabgleich, die in der Informatik und der Softwareindustrie verwendet wird. Dieser spezielle Regex prüft, ob eine Zeichenkette irgendwo in ihr das Wort “union” enthält, gefolgt von einem beliebigen anderen Zeichen, dann gefolgt von dem Wort “select”, wiederum gefolgt von einem beliebigen anderen

 

Zeichen, gefolgt von dem Wort “union”. Dies sind SQL-Schlüsselwörter, die, wenn sie in dieser Reihenfolge vorkommen, bedeuten können, dass ein Angreifer eine SQL-Injection-Schwachstelle in einer Anwendung ausnutzt.

Das ModSecurity-Referenzhandbuch sollte in allen Fällen konsultiert werden, in denen Fragen zur Syntax der Befehle auftreten: GitHub

Du willst Dir die Folgen eines erfolgreichen Hackerangriffs auf
Dein IT-System ersparen?
Teste jetzt deine IT durch einen professionellen Penetrationstest!
Zum Penetrationstest

Regel Installation

Erstellen Sie Ihr eigenes Regelverzeichnis:

				
					mkdir /etc/httpd/modsecurity.custom.d

				
			

Erstellen Sie eine Konfigurationsdatei für Ihre eigenen Regeln im Verzeichnis /etc/httpd/conf.d.

Zum Beispiel:

Navigieren Sie zu /etc/httpd/conf.d und erstellen Sie die Datei 01_modsecurity.conf, und fügen Sie diese Zeile in die Datei 01_modsecurity.conf ein:

				
					Include modsecurity.custom.d/99_PSN_custom.conf
				
			

Installieren Sie Ihre eigenen Regeln im Verzeichnis /etc/httpd/modsecurity.custom.d. Zum Beispiel:

Testen Sie Ihre Apache-Konfiguration.

				
					service httpd configtest

				
			

Wenn Ihr Test erfolgreich war, starten Sie apache neu.

				
					service httpd restart
				
			

Testen Sie Ihre Regel. Zum Beispiel:

				
					curl http://localhost/index.php
				
			
				
					cat logs/access_log
				
			

Umgang mit False Positives

Es ist unvermeidlich, dass Sie bei der Verwendung von Web Application Firewalls auf einige False Positive-Treffer stoßen werden. Dies ist nicht nur bei ModSecurity der Fall. Alle Web Application Firewalls erzeugen von Zeit zu Zeit falsch positive Ergebnisse. Die folgenden Informationen werden Sie durch den Prozess der Identifizierung, Behebung, Implementierung und des Testens neuer benutzerdefinierter Regeln zur Behebung von Fehlalarmen führen.

Jeder Regelsatz kann in neuen Umgebungen false positives verursachen


False Positives treten bei ModSecurity + den Core Rules hauptsächlich als Nebenprodukt auf, aufgrund der Tatsache, dass die Regeln “generischer” Natur sind. Es gibt keine Möglichkeit, genau zu wissen, welche Webanwendung dahinter ausgeführt wird. Aus diesem Grund sind die Grundregeln darauf ausgerichtet, die bekannten bösen Dinge zu blockieren und eine gewisse HTTP-Konformität zu erzwingen. Dadurch wird die große Mehrheit der Angriffe abgefangen.

Nutze den DetectionOnly mode


Bei einer Neuinstallation sollte zunächst die Version “Log only Rule Set” verwendet werden oder, falls keine solche Version verfügbar ist, setzen Sie ModSecurity mit dem Befehl SecRuleEngine DetectionOnly auf Detection only. Nachdem Sie ModSecurity eine Zeit lang im reinen Erkennungsmodus betrieben haben, überprüfen Sie die erzeugten Ereignisse und entscheiden Sie, ob Änderungen am Regelsatz vorgenommen werden sollten, bevor Sie in den Schutzmodus wechseln.

Nicht einfach eine Regel streichen


Nur weil eine bestimmte Regel ein falsches positives Ergebnis auf Ihrer Website erzeugt, bedeutet das nicht, dass Sie die Regel vollständig entfernen sollten. Denken Sie daran, dass diese Regeln aus einem bestimmten Grund erstellt wurden. Sie sind dazu gedacht, einen bekannten Angriff zu blockieren. Wenn Sie diese Regel vollständig entfernen, setzen Sie Ihre Website möglicherweise genau dem Angriff aus, für den die Regel erstellt wurde. Dies wäre das gefürchtete False Negative.

ModSecurity Regeln sind open-source


Da die Regeln von ModSecurity open source sind, können Sie zum Glück genau sehen, worauf die Regel zutrifft, und Sie können auch eigene Regeln erstellen. Bei Closed-Source-Regeln können Sie nicht überprüfen, wonach die Regel sucht, sodass Sie wirklich keine andere Möglichkeit haben, als die beanstandete Regel zu entfernen.

Die logs sind dein Freund


Um zu überprüfen, ob es sich tatsächlich um einen Fehlalarm handelt, müssen Sie Ihre Protokolle überprüfen. Das bedeutet, dass Sie zunächst in der Datei audit_log nachsehen müssen, was in der ModSecurity-Meldung steht. Sie liefert Informationen darüber, welche Regel ausgelöst wurde. Die gleichen Informationen sind auch in der Datei error_log zu finden. Der letzte Ort, an dem man nachsehen sollte und die beste Informationsquelle, ist die Datei modsec_debug.log. In dieser Datei können Sie alles nachlesen, was ModSecurity tut, insbesondere wenn Sie den SecDebugLogLevel auf 9 erhöhen. Beachten Sie jedoch, dass die Erhöhung der Ausführlichkeit des Debug-Logs Auswirkungen auf die Leistung hat. Eine Erhöhung der Ausführlichkeit für den gesamten Datenverkehr ist in der Regel nicht möglich. Sie können jedoch eine neue Regel erstellen, die die Aktion “ctl” verwendet, um den Debugloglevel selektiv zu erhöhen. Wenn Sie z. B. einen False Positive-Fehler nur bei einem bestimmten Benutzer feststellen, können Sie eine Regel wie die folgende einfügen:

				
					SecRule REMOTE_ADDR "^192\.168\.10\.100$" phase:1,log,pass,ctl:debugLogLevel=9

				
			

Hierdurch wird der debugLogLevel nur für Anfragen, die von dieser speziellen IP-Quelladresse kommen, auf 9 gesetzt. Vielleicht erzeugt das immer noch ein bisschen zu viel Verkehr. Sie könnten dies ein wenig einschränken, um die Protokollierung nur für die spezifische Datei oder das Argument zu erhöhen, das den Fehlalarm verursacht:

				
					SecRule REQUEST_URI "^/path/to/script.pl$" phase:1,log,pass,ctl:debugLogLevel=9

				
			

oder

				
					SecRule ARGS:variablename "something" phase:1,pass,ctl:debugLogLevel=9
				
			

Nun, da Sie ausführliche Informationen in der Debug-Protokolldatei haben, können Sie diese überprüfen, um sicherzustellen, dass Sie verstehen, welcher Teil der Anfrage untersucht wurde, als die spezifische Regel ausgelöst wurde. Sie können diese überprüfen, um sicherzustellen, dass Sie verstehen, welcher Teil der Anfrage inspiziert wurde, als die spezifische Regel ausgelöst wurde. Ebenso können Sie auch die Nutzlast anzeigen, nachdem alle Transformationsfunktionen angewendet wurden.

Behebung des false positive

OK, jetzt haben Sie also die spezifische Kernregel identifiziert, die den Fehlalarm verursacht. Positiv verursacht. Nehmen wir an, dass die Regel, die einen Fehlalarm verursacht, die folgende in der Datei REQUEST-901-INITIALIZATION.conf (/etc/httpd/modsecurity.d/activated_rules/) ist.

				
					# Default HTTP policy: allowed_request_content_type (rule 900220)
SecRule &TX:allowed_request_content_type "@eq 0" \
	"id:901162,\
	phase:1,\
	pass,\
	nolog,\
	ver:'OWASP_CRS/3.3.0',\
	setvar:'tx.allowed_request_content_type=|application/x-www-form-urlencoded| |multipart/form-data| |multipart/related| |text/xml| |application/xml| |application/soap+xml| |application/x-amf| |application/json| |application/cloudevents+json| |application/cloudevents-batch+json| |application/octet-stream| |application/csp-report| |application/xss-auditor-report| |text/plain|'"
				
			

Der nächste Schritt besteht darin, die Regel zu kopieren und in die neue Datei 901_customrules.conf einzufügen. Nehmen wir an, dass diese Regel bei der Prüfung eines bestimmten MIME-Typs einer Datei oder in unserem Beispiel einer digital verschlüsselten Nachricht einen falsch positiven Treffer erzielt.

Sie müssen nun einige Änderungen an der Regel vornehmen, um sie zu aktualisieren und den falschen Treffer zu entfernen. Der blau gefärbte Abschnitt des Codes ist die entsprechende Aktualisierung.

Weitere Informationen zu den MIME-Typen von Dateien hier.

				
					# Default HTTP policy: allowed_request_content_type (rule 900220)
SecRule &TX:allowed_request_content_type "@eq 0" \
	"id:901162,\
	phase:1,\
	pass,\
	nolog,\
	ver:'OWASP_CRS/3.3.0',\
	setvar:'tx.allowed_request_content_type=|application/x-www-form-urlencoded| |multipart/form-data| |multipart/related| |text/xml| |application/xml| |application/soap+xml| |application/x-amf| |application/json| |application/cloudevents+json| |application/cloudevents-batch+json| |application/octet-stream| |application/csp-report| 	|application/xss-auditor-report| |text/plain| |application/x-pkcs7-mime|'"
				
			
Als Letztes müssen Sie die Kernregel, die das Problem verursacht hat, mit SecRuleRemoveById deaktivieren.
				
					SecRuleRemoveById	 901162
				
			
Hierfür müssen wir die Datei /etc/httpd/conf.d/default-site.conf bearbeiten.

Testen der neuen Regeln


Der letzte Schritt besteht darin, Ihre neuen Konfigurationen zu testen und zu überprüfen, ob die alte Regel nicht ausgeführt wird und die neue Regel keinen falsch positiven Treffer auslöst. Die einfachste Methode besteht darin, die zuvor beanstandete Anfrage erneut an den Webserver zu senden und dann die Datei audit_log zu überwachen, um zu sehen, ob die Anfrage blockiert oder die ModSecurity-Meldung erzeugt wird.

Implementierung neuer Core Rules


Mit dieser Art von Methodik können Sie benutzerdefinierte Ausschlüsse erstellen und Fehlalarme beheben, und sie ermöglicht auch eine einfache Aktualisierung der Core Rules selbst. Was wir nicht wollen, ist, dass aktuelle Mod-Benutzer die Core Rules-Dateien für ihre Umgebung so stark verändert haben, dass sie nicht aktualisieren wollen, wenn neue Core Rule-Versionen verfügbar sind, weil sie befürchten, alle ihre benutzerdefinierten Konfigurationen neu implementieren zu müssen. Mit diesem Szenario können Sie neue Core Rules-Versionen herunterladen, sobald sie veröffentlicht werden, und dann einfach Ihre neuen benutzerdefinierten ModSecurity-Regeldateien rüberkopieren – und schon sind Sie startklar!

ANDERE BEITRÄGE

Inhaltsverzeichnis

Willst Du Teil unseres Teams werden?

Wir verwenden Cookies, um Ihnen die bestmögliche Erfahrung zu bieten. Wenn Sie unsere Website weiterhin besuchen, stimmen Sie der Verwendung von Cookies zu, wie in unserer Datenschutzerklärung beschrieben.