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 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.
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.
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’s | Verwendung |
| 1-99.999 | Reserviert 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.999 | Regeln von Oracle |
| 200.000-299.999 | Regeln von Comodo |
| 300.000-399.999 | Regeln von gotroot.com |
| 400.000-419.999 | Ungenutzt (zur Reservierung verfügbar) |
| 420.000-429.999 | Regeln von ScallyWhack |
| 430.000-439.999 | Regeln von Flameeyes |
| 440.000-599.999 | Ungenutzt (zur Reservierung verfügbar) |
| 600.000-699.999 | Regeln von Akamai |
| 700.000-799.999 | Regeln von Ivan Ristic |
| 900.000-999.999 | Regeln des OWASP ModSecurity Core Rule Set Projektes |
| 1.000.000-1.009.999 | Regeln des Redhat Security Team’s |
| 1.010.000-1.999.999 | Ungenutzt (zur Reservierung verfügbar) |
| 2.000.000-2.999.999 | Regeln des SpiderLabs Research Teams von Trustwave |
| 3.000.000-3.999.999 | Regeln von Akamai |
| 4.000.000-4.099.999 | Regeln von AviNetworks |
| 4.100.000-4.199.999 | Regeln von Fastly |
| 4.200.000 und mehr | Ungenutzt (zur Reservierung verfügbar) |
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“
| Variable | Verwendung |
| ARGS | Ist eine Sammlung, d. h. alle Argumente einschließlich der POST-Nutzlast. |
| ARGS_GET | Enthält nur Query-String-Parameter. |
| ARGS_POST | Enthält Argumente aus dem POST-Body. |
| FILES | Enthält eine Sammlung von Originaldateinamen. Nur bei inspizierten multipart/form-data-Anfragen verfügbar. |
| FULL_REQUEST | Enthält die vollständige Anfrage: Anforderungszeile, Anforderungskopfzeilen und Anforderungstext. |
| QUERY_STRING | Enthä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_BODY | Enthä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_HEADERS | Diese Variable kann entweder als Sammlung aller Header einer Anfrage oder zur Überprüfung ausgewählter Header verwendet werden. |
| REQUEST_METHOD | Diese Variable enthält die in der Transaktion verwendete Anfragemethode. |
| REQUEST_URI | Diese Variable enthält die vollständige Anfrage-URL einschließlich der Query-String-Daten (z. B. /index.php? p=X). |
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.
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.
| Aktion | Verwendung |
| Disruptive | Wird verwendet, damit ModSecurity eine Aktion durchführen kann, z.B. erlauben oder blockieren |
| Non-disruptive | Etwas 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. |
| Flow | Diese Aktionen wirken sich auf den Regelablauf aus (z.B. skip oder skipAfter). |
| Meta-data | Metadaten-Aktionen werden verwendet, um weitere Informationen über Regeln bereitzustellen. Beispiele sind id, rev, severity und msg. |
| Data | Hierbei 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). |
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"
| Aktion | Verwendung |
| SecRule | Jede Regeldefinition beginnt mit dem Wort “SecRule” als Anfang der Regeldefinition. |
| REQUEST_URI | Diese 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
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
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.
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.
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.
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.
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.
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.
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|'"
SecRuleRemoveById 901162
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.
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!
