Beste WAF für Kong Gateway
Fügen Sie Kong Gateway einen Web-Application-Firewall-Schutz hinzu. Vergleichen Sie Kongs eigene Enterprise-Security-Plugins (Injection Protection, JSON/XML Threat Protection, Request Validator) mit Drittanbieter-Engines, die sich in Kong einklinken, darunter open-appsec, Coraza (OWASP CRS) und ModSecurity.
Kong Gateway ist eines der am weitesten verbreiteten Open-Source-API-Gateways, aufgebaut auf OpenResty und NGINX, und steht bei Großunternehmen vor APIs und Microservices. Da es den Client-Verkehr terminiert und routet, bevor er Ihre Dienste erreicht, und bereits Authentifizierung, Rate-Limiting und Request-Transformation ausführt, ist Kong ein naheliegender Ort, um Sicherheitsrichtlinien auf Anwendungsebene durchzusetzen.
Eines sollte vorab klar sein: Kong hat kein einzelnes Plugin, das buchstäblich "WAF" heißt. Kongs eigene WAF-Anleitung beschreibt, Web-Application-Firewall-Abdeckung aus einer Reihe von Security-Plugins zusammenzusetzen, statt aus einem monolithischen WAF-Modul. Mehrere der relevantesten, darunter Injection Protection, JSON Threat Protection und XML Threat Protection, sind Enterprise-exklusiv; andere wie Bot Detection, IP Restriction und Rate Limiting sind im Open-Source-Kong enthalten. Keines von Kongs nativen Plugins führt den OWASP Core Rule Set aus; für CRS-Abdeckung binden Sie eine Drittanbieter-Engine über die Plugin-Architektur von Kong an.
Dieser Leitfaden vergleicht die realistischen Wege, eine WAF auf Kong zu bringen: Kongs native Enterprise-Security-Plugins, die Machine-Learning-Engine open-appsec (die ein dediziertes Kong-Plugin mitbringt), Coraza, das den OWASP CRS über Community-Integrationen für Kong/OpenResty ausführt, und ModSecurity über das zugrunde liegende NGINX oder einen Sidecar. Er behandelt außerdem, was Kong nativ leisten kann und was nicht, damit Sie entscheiden können, wo die WAF in Ihrem API-Stack gehört.
Top WAF-Anbieter für Kong Gateway
Coraza Web Application Firewall
Open-Source-OWASP-CRSCoraza ist der Open-Source-Weg, den OWASP Core Rule Set vor Kong auszuführen. Es ist eine moderne, ModSecurity-kompatible Engine, in Go geschrieben und ohne C-Abhängigkeiten, und führt CRS v4 (SQLi, XSS, Code-Injection, Scanner-Erkennung und mehr) sowie beliebige mitgebrachte SecLang-Regeln aus. Beachten Sie, dass es kein offizielles Kong-Plugin gibt: Coraza erreicht Kong über Community-Lua-Plugins oder eine proxy-wasm/Sidecar-Schicht auf OpenResty, validieren Sie also die konkrete Integration und pinnen Sie Versionen vor dem Produktiveinsatz. Am besten, wenn Sie transparente, branchenübliche CRS-Regeln wollen, die Sie vollständig kontrollieren.
Hauptvorteile:
- Führt den OWASP CRS v4 und ModSecurity-SecLang-Regeln aus
- Reine Go-Engine, ohne C-Abhängigkeiten, leicht zu containerisieren
- Kostenlos und Open Source (OWASP-Projekt, Apache 2.0)
- Bindet über Community-Integrationen für Kong/OpenResty an
ModSecurity Open Source WAF
Branchenstandard-RegelnModSecurity ist die langjährig etablierte, praxiserprobte WAF-Engine und der Ursprung der Regelsprache SecLang und des OWASP-CRS-Ökosystems. Es gibt kein offizielles Kong-Plugin; da Kong auf NGINX/OpenResty aufbaut, betreiben Teams libmodsecurity typischerweise über den NGINX-ModSecurity-Connector auf dem zugrunde liegenden Proxy oder stellen ModSecurity als Sidecar vor Kong bereit. Es ist eine solide Wahl, wenn Ihr Team bereits SecLang-Regeln pflegt, mit dem Kompromiss, dass die Kong-spezifische Integration selbst verwaltet wird statt eines unterstützten, sofort einsatzbereiten Plugins.
Hauptvorteile:
- Ausgereiftes Ökosystem aus SecLang- und OWASP-CRS-Regeln
- Läuft auf dem zugrunde liegenden NGINX/OpenResty oder als Sidecar
- Kostenlos und Open Source, keine Lizenzkosten
- Vertraut für Teams, die bestehende ModSecurity-Regeln migrieren
Worauf Sie bei einer WAF für Kong Gateway achten sollten
Beim Auswählen, wie Sie Kong Gateway eine WAF hinzufügen, sollten Sie diese Faktoren abwägen:
- Native Plugins vs. eine Drittanbieter-Engine - Kongs eigene WAF-artige Plugins laufen in-process und integrieren sich sauber mit Routing und Auth, aber die stärksten (Injection Protection, JSON/XML Threat Protection, Request Validator) sind Enterprise-exklusiv. Drittanbieter-Engines wie open-appsec oder Coraza binden über die Plugin-Architektur an und können kostenlos und Open Source sein.
- Unterstützung für den OWASP Core Rule Set - Kongs native Plugins führen den OWASP CRS nicht aus. Wenn Sie CRS-Abdeckung benötigen, planen Sie Coraza oder ModSecurity ein, die CRS-/SecLang-Regeln direkt ausführen. Prüfen Sie die CRS-Version (v4 ist aktuell) und wie Regel-Updates ausgeliefert werden.
- Enterprise-Lizenzierung - Das Injection Protection-Plugin erfordert Kong Gateway 3.9+ und eine Enterprise-Lizenz; JSON Threat Protection erfordert 3.8+ und XML Threat Protection 3.1+, beide Enterprise. Prüfen Sie, welche Stufe Ihre Plugins benötigen, bevor Sie ein Design darauf aufbauen.
- Signatur/Regex vs. maschinelles Lernen - Injection Protection und Bot Detection sind regex-basiert; open-appsec ist ML-basiert; Coraza/ModSecurity sind CRS-Regel-Engines. Jede hat andere Tuning- und Fehlalarm-Eigenschaften, passen Sie die Engine also an Ihr Bedrohungsmodell an.
- Natives Rate-Limiting und Zugriffskontrolle - Kong erledigt bereits viel, bevor überhaupt eine WAF greift: Rate Limiting (und das Enterprise-Plugin Rate Limiting Advanced), IP Restriction und Bot Detection bewältigen Missbrauch und Zugriffskontrolle effizient im Gateway. Entscheiden Sie, was Sie damit lösen und was tatsächlich eine Payload-Inspektion benötigt.
- Echte Client-IP - Wenn Kong hinter einem CDN oder Load Balancer sitzt, konfigurieren Sie vertrauenswürdige IPs und die X-Forwarded-For-Behandlung, damit die WAF, IP Restriction und Rate-Limits die echte Client-Adresse sehen und nicht die des vorgelagerten Proxys.
Kong Gateway-Überlegungen
Kong-spezifische Überlegungen beim Bereitstellen einer WAF:
- Open-Source-Kong hat kein WAF-Plugin auf Anwendungsebene - Das kostenlose Gateway bringt Bot Detection, IP Restriction, Rate Limiting und Request Size Limiting mit, aber die payload-inspizierenden Plugins (Injection Protection, JSON/XML Threat Protection, Request Validator) sind Enterprise-exklusiv. Gehen Sie nicht davon aus, dass Open-Source-Kong Request-Bodies auf SQLi oder XSS inspiziert; ohne eine zusätzliche Engine tut es das nicht.
- Die WAF ist eine Plugin-Kette, kein einzelnes Modul - Kongs Ansatz besteht darin, mehrere Security-Plugins in der Ausführungskette zu kombinieren. Planen Sie die Reihenfolge (zum Beispiel IP Restriction und Bot Detection früh, Injection Protection und Validatoren vor dem Proxying), damit günstige Ablehnungen vor teurer Inspektion erfolgen.
- Kein OWASP CRS nativ - Kongs Injection Protection verwendet eigene vordefinierte und benutzerdefinierte Regex-Muster, nicht den OWASP CRS. Für CRS-/SecLang-Abdeckung binden Sie Coraza an (Community-Integration für Kong/OpenResty) oder betreiben ModSecurity auf dem zugrunde liegenden NGINX oder als Sidecar.
- Aufgebaut auf NGINX/OpenResty - Da Kong auf OpenResty läuft, können Sie Lua-basierte WAF-Plugins wie die open-appsec-Anbindung hinzufügen oder auf den NGINX-ModSecurity-Connector auf der Proxy-Ebene zurückgreifen. Diese Flexibilität ist real, aber die nicht-nativen Wege werden selbst verwaltet.
- Konnect Dedicated Cloud Gateways - Kong bietet keine native WAF für Dedicated Cloud Gateways. Da öffentliche Dedicated Cloud Gateways einen DNS-Hostnamen statt statischer IPs bereitstellen, empfiehlt Kong, eine eigene WAF mitzubringen, indem Sie einen CDN vorschalten, der DNS-basierte Origins unterstützt und WAF-Richtlinien tragen kann (Kongs Leitfaden zum öffentlichen Netzwerk nennt Amazon CloudFront mit AWS WAF, Azure Front Door mit Azure WAF, Cloudflare und Fastly mit Next-Gen WAF) vor das Gateway als erste Layer-7-Verteidigungslinie. Wo der CDN statische Egress-IP-Bereiche veröffentlicht, kombinieren Sie ihn mit dem IP-Restriction-Plugin, um diese IPs auf eine Allowlist zu setzen. Das ist eine vom Kunden bereitgestellte Drittanbieter-Kontrolle, keine von Kong bereitgestellte WAF.
- Bereitstellungsform - Dieselben Plugins laufen über selbst gehostetes Linux/Docker, Kubernetes via Kong Ingress Controller (verwaltet über CRDs), den Hybrid-Modus mit einer Cloud-Control-Plane und selbst verwalteten Data-Planes sowie Konnect. Die WAF-Richtlinie reist mit Ihrer deklarativen Kong-Konfiguration mit.
Häufig gestellte Fragen
Enthält Open-Source-Kong-Gateway eine WAF?
Keine vollständige WAF auf Anwendungsebene. Open-Source-Kong bringt Security-Plugins wie Bot Detection, IP Restriction, Rate Limiting und Request Size Limiting mit, die Bots, Zugriffskontrolle und Missbrauch bewältigen. Die payload-inspizierenden Plugins, die SQL-Injection und XSS abfangen, etwa Injection Protection und JSON/XML Threat Protection, sind Enterprise-exklusiv. Für Open-Source-Payload-Inspektion binden Sie eine Drittanbieter-Engine wie open-appsec oder Coraza an.
Wie füge ich Kong Gateway eine WAF hinzu?
Drei Hauptansätze. Erstens, Kong-Enterprise-Plugins: Aktivieren Sie Injection Protection, JSON Threat Protection, XML Threat Protection und den Request Validator, die im Gateway laufen. Zweitens, ein Drittanbieter-Kong-Plugin: Die ML-Engine open-appsec bringt ein dediziertes, Lua-basiertes Kong-Plugin mit. Drittens, eine OWASP-CRS-Engine: Betreiben Sie Coraza über eine Community-Integration für Kong/OpenResty oder ModSecurity auf dem zugrunde liegenden NGINX oder als Sidecar. Was Sie wählen, hängt davon ab, ob Sie eine Enterprise-Lizenz haben und ob Sie CRS-Regeln benötigen.
Hat Kong Gateway ein Plugin namens "WAF"?
Nein. Es gibt kein einzelnes Kong-Plugin namens "WAF." Kongs eigene WAF-Dokumentation beschreibt, Web-Application-Firewall-Abdeckung aus einer Kombination von Plugins aufzubauen, darunter Injection Protection, JSON und XML Threat Protection, Request Validator, Bot Detection, IP Restriction und Rate Limiting, statt ein monolithisches WAF-Modul auszuliefern. Für öffentliche Konnect Dedicated Cloud Gateways bietet Kong keine native WAF; stattdessen empfiehlt es, eine Drittanbieter-WAF auf CDN-Ebene (etwa AWS WAF, Azure WAF, Cloudflare oder Fastly) vor das Gateway als vom Kunden bereitgestellte Layer-7-Kontrolle zu schalten.
Unterstützt Kongs WAF den OWASP Core Rule Set?
Nein. Kongs natives Injection Protection-Plugin verwendet eigene vordefinierte und benutzerdefinierte Regex-Muster für die Erkennung von SQLi, XSS, SSI, XPath und Java-Exceptions, nicht den OWASP CRS. Um den CRS (v4) auf Kong auszuführen, binden Sie Coraza über eine Community-Integration für Kong/OpenResty an oder betreiben ModSecurity auf dem zugrunde liegenden NGINX oder als Sidecar. Beide führen CRS- und SecLang-Regeln direkt aus.
Was macht das Kong-Injection-Protection-Plugin?
Es ist ein Enterprise-Plugin (Kong Gateway 3.9+), das per Regex nach gängigen Injection-Mustern sucht. Standardmäßig wird nur SQL-Injection geprüft; Cross-Site-Scripting, Server-Side Includes, XPath und Java-Exceptions sowie die weiteren vordefinierten Typen aktivieren Sie über die Einstellung injection_types, zusätzlich zur Unterstützung benutzerdefinierter Regexes. Es inspiziert je nach Konfiguration Request-Header, Pfad- und Query-Parameter sowie den Payload-Body und blockiert einen Treffer, indem es einen 400-Status zurückgibt, während der Injection-Typ und das getroffene Muster protokolliert werden. Die vollständige Konfiguration finden Sie in der Injection-Protection-Referenz.
Kann ich open-appsec, Coraza oder ModSecurity mit Kong verwenden?
Ja. open-appsec bringt ein dediziertes, quelloffenes, Lua-basiertes Kong-Gateway-Plugin (Beta) mit, das Bedrohungserkennung per maschinellem Lernen hinzufügt, installierbar über LuaRocks, Docker Compose oder ein Kong-Container-Image. Coraza führt den OWASP CRS über Community-Integrationen für Kong oder OpenResty aus. ModSecurity läuft auf dem zugrunde liegenden NGINX über seinen Connector oder als Sidecar. Wallarm bietet ebenfalls eine native Kong-Integration für API-Sicherheit. Nur open-appsec und Kongs eigene Enterprise-Plugins sind echte Kong-Plugins; die CRS-Engines sind selbst verwaltete Integrationen.
Kann ich in Kong ohne WAF Rate-Limiting betreiben und bösartigen Verkehr blockieren?
Ja, bis zu einem gewissen Grad. Kongs Rate Limiting-Plugin (und das Enterprise-Plugin Rate Limiting Advanced) drosseln Request-Raten pro Service, Route oder Consumer; IP Restriction erzwingt Allow-/Deny-CIDR-Listen; und Bot Detection blockiert bekannte Bots per User-Agent-Regex und liefert dabei einen 403 zurück. Das bewältigt Missbrauch und Zugriffskontrolle effizient im Gateway. Was diese nicht tun, ist Request-Payloads auf Injection oder XSS zu inspizieren, und genau dafür ist ein WAF-Plugin oder eine WAF-Engine erforderlich.
Kong-Enterprise-Plugins vs. eine Open-Source-WAF-Engine, welche sollte ich wählen?
Kongs Enterprise-Plugins (Injection Protection, JSON/XML Threat Protection, Request Validator) laufen in-process ohne zusätzlichen Hop und werden mit dem Rest Ihrer Kong-Konfiguration verwaltet, erfordern aber eine kommerzielle Lizenz und führen den OWASP CRS nicht aus. Eine Open-Source-Engine, open-appsec für ML-Erkennung oder Coraza für CRS-Regeln, ist kostenlos und gibt Ihnen entweder verhaltensbasiertes ML oder transparente CRS-/SecLang-Regeln, die Sie vollständig kontrollieren, um den Preis einer selbst verwalteten Integration. Wählen Sie Enterprise-Plugins für enge Kong-Integration und Support; wählen Sie open-appsec oder Coraza, wenn Budget, ML-Erkennung oder CRS-Transparenz am wichtigsten sind.