...in progress...
keywords: WAF, web application firewall, mod_security, modsecurity
Wenn die Website nach Aktivierung der WAF nicht wie gewohnt funktioniert, dann wie folgt vorgehen:
Im Browser die Netzwerkanalyse öffnen
Betr. Seite neu laden
Wenn 403 Forbidden auftaucht, dann wird ein request von der WAF geblockt
tail -f /var/log/apache2/modsec_audit.log
Hier den letzten, neuesten Bereich analysieren, der aus mehreren Abschnitten/Einträgen besteht:
--[id]-A--
...
--[id]-B--
...
--[id]-C--
...
Oben den request prüfen:
Beispiel:
PUT /api/v1/triggers/4 HTTP/1.1
Suche nach "[id"
Dann die IDs der ModSec Core Rules (ids: 900000-900999) prüfen. Eine sollte immer zweimal auftreten:
Einmal zuerst innerhalb der Message: Warning von mod_security (glaube ich).
Danach innerhalb Apache-Error.
Dann die Regel(n) bauen und eigene id(s) vergeben, die sauber hochzählt/hochzählen (sonst startet apache nicht mehr)
In
/etc/modsecurity/user.modsecurity.conf
folgenden eigenen Bereich unterhalb von
# === ModSec Core Rules Base Configuration (ids: 900000-900999)
und oberhalb von
# === ModSecurity Core Rules Inclusion
Include /etc/modsecurity/owasp-modsecurity-crs/rules/*.conf
einfügen und pflegen:
# === ModSec Core Rules: Runtime Exclusion Rules [projekt- oder servername] (ids: 10000-49999)
# ModSec Exclusion Rule: 932130 msg "Remote Command Execution: Unix Shell Expression Found"
SecRule REQUEST_URI "@beginsWith /api/v1/" \
"phase:1,nolog,pass,id:10006,ctl:ruleRemoveById=932130,chain"
SecRule REQUEST_METHOD "PUT"
Abschließend:
apache2ctl configtest
systemctl restart apache2.service
systemctl status apache2.service