Shopware auf der Überholspur - Sicherer Betrieb durch Modsecurity mit Elastic und Kubernetes

Lernen Sie in diesem Artikel, wie Ihre Daten und die Ihrer Kunden sicher mit einer internen Web Application Firewall (WAF) geschützt werden können und warum dies sinnvoll ist. Wir zeigen Ihnen Codeauszüge innerhalb einer kurzen Anleitung mit Tipps und Tricks.

Setup

In unserem hier dargestellten Szenario haben wir folgende Komponenten im Einsatz:

• Shopware
• NGINX Webserver
• ModSecurity v3
• Managed Kubernetes (Openstack by OVHcloud)
• ELK Stack

Die spezielle Herausforderung hierbei liegt bei der Trennung der Logs, da das Standardlogging rein über stdout funktioniert.

Warum eine Web Application Firewall sinnvoll ist und was sie genau macht

Das Open Web Application Security Project (OWASP) kategorisiert jährlich die größten Gefahren im Internet mit dem Ziel für mehr Sicherheit in Anwendungen und Diensten des World Wide Webs zu sorgen

Die aktuellen OWSAP TOP 10 besteht aus folgenden Gefahrenquellen:

• Injektion
• Defekte Authentifizierung
• Offenlegung sensibler Daten
• Externe XML Entitäten (XXE)
• Defekte Zugriffskontrolle
• Fehlkonfiguration
• Cross-site-Scripting
• Unsichere Deserialisierung
• Verwendung von Komponenten mit bekannten Schwachstellen
• Unzureichende Protokollierung und Überwachung

Eine Studie von Verizon verdeutlicht einen Anstieg von Angriffen auf Webanwendungen von 48 % auf 80 % innerhalb von 2020 auf 2021. Die Tendenz für 2022 ist steigend.

Aus diesem Grund ist eine Absicherung Ihrer E-Commerce-Plattform essenziell für die Datensicherheit. Folgende Abbildung veranschaulicht diese Absicherung mit einer zweistufigen WAF. Die Abbildung veranschaulicht exemplarisch den Datenverkehr von echten Usern und Angriffszenarien und den Schutz durch eine Web Application Firewall.

Ein echter User geht über ihre Domain zum Shopsystem. Ein Hackangriff kann wahlweise über die Domain URL oder der IP Range vom Hostingprovider stattfinden. Daher ist es ratsam ein zweistufiges WAF-Konzept zu betreiben. Eine externe (bspw. mit Cloudflare) und eine interne, innerhalb des LAN vor der Anwendung (mit modsecurity).  

Wir nutzen in diesem Fall ModSecurity als interne WAF. ModSecurity ist eine regelbasierte Engine, die Webanfragen mit ein Regelwerk filtert. Wenn die Prüfung erfolgreich ist, wird die HTTP-Anfrage an den Shop weitergeleitet. Wenn sie fehlschlägt, blockiert sie die Anfrage.

Über das Regelwerk lassen sich folgende Schwachstellen überwachen: 

• SQL injection and Blind SQL injection.
• Cross Site Scripting (XSS).
• OS Command Injection and remote command access.
• File name injection.
• ColdFusion, PHP and ASP injection.
• E-Mail Injection
• HTTP Response Splitting.
• Universal PDF XSS.
• Trojans & Backdoors Detection

Die externe WAF, welche in der Regel von einem Anbieter gemanaged wird, würde zudem einen erweiterten Schutz bedeuten, mit dem auch beispielsweise Zero-Day Attacken frühzeitig geblockt werden können.

Doch was ist notwendig, um die interne Web Application Firewall aufzusetzen? Im Folgenden zeigen wir dir, wie du es umsetzen kannst!

Konfiguration Modsecurity

Für eine einfache Übermittlung wurde die ModSecurity so eingestellt, dass die Einträge im JSON Format gespeichert werden. Hierdurch wird im weiteren Verlauf die Transformation in die ELK Stack Objekte sehr vereinfacht.

Folgende Annotations müssen am Ingress hinzugefügt werden, damit Modsecurity aktiviert ist:

ModSecurity Config:

Weiterhin muss der Ingress Controller so angepasst werden, dass er zwischen reinen NGINX Logs und denen von Modsecurity unterscheidet. Hierfür muss folgender Auszug integriert werden.

Dem Pod wird ein weiterer Container hinzugefügt, welcher die ModSecurity Logs seperiert:

Konfiguration Filebeat

Für die Überführung der Log Einträge aus dem modsecurity Audit log gibt es 2 Varianten.

• Elastic Agent: ModSecurity Audit log
• File Beat

Da die Realisierung über File Beat für Kubernetes besser geeignet ist, gehen wir im weiteren Verlauf auf diese Variante ein.

Um die zuvor seperierten Logs in den ELK Stack zu übertragen, verwenden wir die filebeat.autodiscover Funktion. 

Wir trennen die Logs über das Label "kubernetes.container.name". Dies ist notwendig, da das Audit File ansonsten mit dem aktuellen Standard NGINX Pipeline von elastic verarbeitet werden würde und dieses mit jedem neuen Release automatisch überschrieben wird. Damit wir die Nachrichten besser von einander trennen können, haben wir zudem, wie oben beschrieben, Modsecurity die Erweiterung "mod-security-logger" in Kubernetes angefügt.

Konfiguration Elastic Pipeline

Da wir, wie oben beschrieben, JSON Formate übermitteln, ist die Pipeline in Elastic rein auf die Transformation dieses Objektes beschränkt. Hierfür bietet elastic eine vordefinierte Methode "json" an. Diese muss zweimal hintereinander ausgeführt werden, um eine automatische Transformation durchzuführen. Warum das so ist, fragen Sie bitte nicht ;).

Folgend dargestellt ein beispielhafter Angriff, der die ".env" Datei versucht zu öffnen.

{"transaction":{"client_ip":"5.147.64.XXX","time_stamp":"Tue Jun 28 20:47:07 2022","server_id":"ffbd70bb61277107b0608c3d2be5824751fecdce","client_port":58758,"host_ip":"10.2.0.XXX","host_port":443,"unique_id":"70b0ae977efcb4521a4795c94bc87c9b","request":{"method":"GET","http_version":2.0,"uri":"/Products/RNA-Extraction/.env"},"response":{"http_code":403},"producer":{"modsecurity":"ModSecurity v3.0.5 (Linux)","connector":"ModSecurity-nginx v1.0.2","secrules_engine":"Enabled","components":["OWASP_CRS/3.3.2\""]},"messages":[{"message":"Restricted File Access Attempt","details":{"match":"Matched \"Operator `PmFromFile' with parameter `restricted-files.data' against variable `REQUEST_FILENAME' (Value: `/Products/RNA-Extraction/.env' )","reference":"o24,5v4,29t:utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase","ruleId":"930130","file":"/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf","lineNumber":"105","data":"Matched Data: /.env found within REQUEST_FILENAME: /products/rna-extraction/.env","severity":"2","ver":"OWASP_CRS/3.3.2","rev":"","tags":["application-multi","language-multi","platform-multi","attack-lfi","paranoia-level/1","OWASP_CRS","capec/1000/255/153/126","PCI/6.5.4"],"maturity":"0","accuracy":"0"}},{"message":"Inbound Anomaly Score Exceeded (Total Score: 5)","details":{"match":"Matched \"Operator `Ge' with parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `5' )","reference":"","ruleId":"949110","file":"/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf","lineNumber":"80","data":"","severity":"2","ver":"OWASP_CRS/3.3.2","rev":"","tags":["application-multi","language-multi","platform-multi","attack-generic"],"maturity":"0","accuracy":"0"}}]}}

Aus diesem JSON Array sind für die weitere Analyse folgende Attribute besonders wichtig:

• modsecurity.transaction.client_ip - Angreifer ip
• modsecurity.transaction.messages.details.file - Angreifer Name
• modsecurity.transaction.messages.details.ruleId <- modsecurity regel
• modsecurity.transaction.messages.details.match: Detailinformationen
• modsecurity.transaction.request.uri - URL Aufruf

Ausnahmen hinzufügen

Nach Aktivierung der WAF kann es vorkommen, dass einige gewollte Zugriffe blockiert werden.
Diese unterscheiden sich je nach Applikation und eingesetzten Erweiterungen und müssen daher individuell ermittelt werden.
Will man Ausnahmen für diese Zugriffe hinzufügen, ist folgendes zu tun:

1. modsecurity.transaction.messages.details.ruleId - aus diesem Feld kann die ID der Regel entnommen werden. Beispiel: "932115"

Nun folgenden Eintrag unterhalb von "nginx.ingress.kubernetes.io/modsecurity-snippet: |" hinzufügen:

SecRuleRemoveById 932115

Konfiguration Elastic Kibana Dashboard

Für die Aufbereitung der Log im ELK Stack stellen wir euch folgendes von uns definiertes Dashboard zur Verfügung: Dieses zeigt eine Gruppierung der Angreifer nach Uhrzeit, Angriffstyp , Angriffsregion sowie die eigentlichen Angriffe.

✔️kostenlos ✔️jede Woche News ✔️Expertenwissen