Ihr WAF, getunt und produktionsreif getestet.
Ein WAF-Regelsatz (Web Application Firewall) auf Basis von OWASP CRS, dem branchenüblichen Core Rule Set, kuratiert, auf der echten Coraza-Engine getestet, mit technologiespezifischen Tuning-Plugins (WordPress, Drupal, phpBB, phpMyAdmin, Nextcloud) zur Reduzierung von False Positives. Kompatibel mit ModSecurity, Coraza und Nginx (seclang-Format), vom produktionssicheren Paranoia-Level (PL1) bis zum strikten (PL4). Blockiert nahezu alle aktiv ausgenutzten Web-Schwachstellen (CISA KEV). Dazu 700+ Virtual-Patches, die den exakt blockierten CVE benennen (60+ in KEV), für SOC-Reporting und Compliance bis auf CVE-Ebene. Ed25519-signiert.
What we added recently
A living feed: here is the coverage added to it, dated.
- +4 règles
- +1 règles
Ladefertige Bundles, nach Technologie und Level.
700+ CVE-spezifische Regeln, generiert aus Schwachstellen-Scan-Intel: Sie blockieren den Exploit eines konkreten CVE, noch bevor Sie gepatcht haben, und sie benennen den exakt blockierten CVE, für SOC-Reporting und Compliance. Nach CISA KEV priorisiert (60+ aktiv ausgenutzte CVEs), jede auf der echten Coraza-Engine gate-validiert und ohne False Positives getestet.
Die CRS-Basis + das WordPress-Tuning-Plugin: die Ausnahmen, die verhindern, dass die WAF das WordPress-Admin, Uploads und legitime APIs blockiert. Das häufigste Deployment, ohne die False-Positive-Welle des rohen CRS.
Ein Profil für JSON-/API-Backends und Headless-Frontends: SQLi, RCE und Injection bleiben, was eine legitime REST- oder GraphQL-API bricht, wird gelockert.
Die kritischen Angriffskategorien: SQL-Injection, Cross-Site-Scripting und Remote Code Execution (RCE), dazu LFI/RFI und PHP-/Java-Injection. Der Kern der OWASP-Abdeckung.
Paranoia-Level 1 (PL1): die empfohlene Produktionseinstellung, kalibriert, um echte Angriffe mit minimalen False Positives zu blockieren. Zuerst ausrollen.
Paranoia-Level 4 (PL4): die strikteste Erkennung, für ein Audit, einen Monitoring-Modus oder eine Umgebung mit hoher Sensibilität. Mehr Rauschen, mehr Abdeckung.
Die Regeln zur Scanner- und Bot-Erkennung: identifiziert automatisierte Angriffstools (sqlmap, nikto, Schwachstellen-Scanner) und verdächtigen nicht-menschlichen Traffic.
Regeln aus OWASP CRS (dem Standard-Core-Rule-Set) und technologiespezifischen Tuning-Plugins aggregiert, dedupliziert, auf der echten Coraza-Engine validiert (jede Regel wird geladen und kompiliert) und dann in Bundles nach Technologie und Paranoia-Level organisiert. Hinzu kommen 700+ CVE-Virtual-Patches, generiert aus Schwachstellen-Scan-Intel (Exploit-Signaturen), nach CISA KEV priorisiert und auf der Engine gate-validiert. seclang-Format, kompatibel mit ModSecurity, Coraza und Nginx. Herkunft und Apache-2.0-Lizenz erhalten.
Kuratierung + Tuning, nicht Rohmaterial.
Das OWASP Core Rule Set ist der Branchenstandard für WAFs. Wir starten von dieser bewährten Basis, nicht von einer ungetesteten Eigenliste.
Jede Auslieferung wird auf der echten Coraza-Engine geladen, Regeln, die nicht kompilieren, werden entfernt. Kein defektes seclang in Produktion.
Technologiespezifische Tuning-Plugins (WordPress, Drupal, phpBB, phpMyAdmin, Nextcloud), die die für jede Anwendung typischen False Positives neutralisieren. Das ist der eigentliche Burggraben: rohes CRS blockiert legitimen Traffic, unseres nicht.
seclang-Format, kompatibel mit ModSecurity, Coraza und Nginx (ModSecurity). Derselbe Feed schützt Ihren Reverse Proxy, Ihre containerisierte WAF oder Ihr Gateway.
Der Feed ist signiert; Sie prüfen die Integrität vor jedem Deployment.
OWASP CRS steht unter Apache-2.0, mit Namensnennung weitergebbar. Die Kuratierung, der Engine-Test und das Technologie-Tuning bleiben der proprietäre Wert von ThreatClaw.
Was ist Virtual Patching?
Eine Virtual-Patching-Regel blockiert den Exploit eines konkreten CVE auf WAF-Ebene, noch bevor der Hersteller-Fix ausgerollt ist, während Sie den Patch testen und einspielen, ist der Angriff bereits gestoppt. Da jede Regel auf einen benannten CVE zielt, wissen Sie genau, welcher blockiert wurde, praktisch für SOC-Reporting und Compliance. Unsere 700+ Virtual-Patches werden aus Schwachstellen-Scan-Intel (Exploit-Signaturen) generiert, nach der CISA-KEV-Liste priorisiert (60+ aktiv ausgenutzte CVEs), dann auf der echten Coraza-Engine geladen und getestet, sodass sie keine False Positives erzeugen.
Wie nutze ich es?
Das Pack liefert einen `crs/`-Ordner (die Regeln), einen `plugins/`-Ordner (das Technologie-Tuning) und eine `crs-setup.conf`. Laden Sie sie in ModSecurity, Coraza oder Nginx (ModSecurity): richten Sie Ihre Engine auf crs-setup + crs/ aus, aktivieren Sie die Plugins der von Ihnen gehosteten Apps (WordPress, Drupal…) und wählen Sie Ihr Paranoia-Level (PL1 in Produktion, bis PL4 strikt). Erst im Detection-Modus fahren, dann auf Blocking umstellen.
Warum zahlen, wenn OWASP CRS kostenlos ist?
Sie zahlen nicht für die Regeln, OWASP CRS ist kostenlos. Sie zahlen für die Kuratierung, den Test auf der echten Coraza-Engine, das technologiespezifische Tuning, das False Positives beseitigt (die Arbeit, die eine WAF angeschaltet lässt, statt beim ersten Ticket deaktiviert zu werden), und die ladefertigen Bundles. Rohes, schlecht abgestimmtes CRS blockiert legitimen Traffic; unsere Kompilierung ist auf Produktion kalibriert.
Welche Lizenzen, und darf ich weiterverkaufen / MSSP?
OWASP CRS steht unter Apache-2.0: mit Namensnennung weitergebbar (Herkunft und Lizenz bleiben im Pack erhalten). Die Kompilierung, der Engine-Test, das Technologie-Tuning und die Bundles sind hingegen der proprietäre Wert von ThreatClaw. Für MSSP-Nutzung oder Weiterverkauf sprechen Sie uns an.
Bereit, Ihre Webanwendungen zu schützen?
Jahresabo. Sofort-Schlüssel. Jederzeit kündbar.