☰

mod_security RBL - offensichtliches Falsch-Positiv

tag-icon • tag-icon mod-security rbl
mod_security RBL - offensichtliches Falsch-Positiv

Ich kämpfe mit einer RBL-Regel in mod_security unter Apache 2.2, die mir anscheinend ein falsches Positiv liefert. Im Prüfprotokoll sehe ich Folgendes (IP-Adresse redigiert):

Nachricht: RBL-Suche nach 4.3.2.1.sbl-xbl.spamhaus.org war bei REMOTE_ADDR erfolgreich. [Datei "/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_42_comment_spam.conf"] [Zeile "21"] [ID "981138"] [Nachricht "RBL-Übereinstimmung für SPAM-Quelle"] [Schweregrad "KRITISCH"] [Tag "AUTOMATION/MALICIOUS"]

Was mich wahnsinnig macht, ist, dass ich, wenn ich nslookupauf den in der Protokollnachricht angegebenen Namen eine Abfrage ausführe, das Ergebnis erhalte, dass er nicht existiert. Was meines Wissens bedeutet, dass diese Adresse nicht auf der Liste steht. Warum ist mod_security also erfolgreich?

Ich habe außerdem den Nachschlagedienst von Spamhaus genutzt, um zu bestätigen, dass die IP-Adresse nicht auf der schwarzen Liste steht.

Was übersehe ich? Es fühlt sich an, als würde etwas zwischengespeichert, aber ich kann nicht herausfinden, wo.

Ein bisschen mehr Hintergrund: Anfangs verwendete der Host einen DNS-Server, der (hilfreicherweise) Adressen zurückgab, selbst wenn die Suche fehlschlug. Ich habe die Konfiguration auf die Verwendung der Google-Server (8.8.8.8 und 8.8.4.4) umgestellt und jetzt hostfunktioniert nslookupes wie erwartet. Ich habe den Server neu gestartet, sodass theoretisch kein Cache im Arbeitsspeicher vorhanden ist. Ich habe auch sichergestellt, dass die mod_security-Datendateien, die die IP-Adresse bewahren würden, gelöscht sind. Ich weiß, dass das funktioniert, da die erste Suche nach der Adresse wie oben angezeigt wird und nachfolgende nach dem ersten falschen Erfolg die Adresse als bekannte SPAM-Adresse anzeigen.

Die fragliche Regel:

SecRule REMOTE_ADDR "@rbl sbl-xbl.spamhaus.org" \
"phase:1,id:'981138',t:none,pass,nolog,auditlog,msg:'RBL Match for SPAM Source',\
tag:'AUTOMATION/MALICIOUS',severity:'2',setvar:'tx.msg=%{rule.msg}',\
setvar:tx.automation_score=+%{tx.warning_anomaly_score},\
setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},\
setvar:tx.%{rule.id}-AUTOMATION/MALICIOUS-%{matched_var_name}=%{matched_var},\
setvar:ip.spammer=1,expirevar:ip.spammer=86400,setvar:ip.previous_rbl_check=1,\
expirevar:ip.previous_rbl_check=86400,skipAfter:END_RBL_CHECK"

Antwort1

Dieses Problem tritt bei mir nicht mehr auf und ich vermute, dass ich die Ursache kenne.

  1. Der Nameserver wurde so konfiguriert, dass er über die „search“-Einstellung in /etc/resolv.conf nach Namen innerhalb von mydomain.com sucht.
  2. Ich hatte einen Platzhalter-DNS-Eintrag für *.mydomain.com, der eine IP-Adresse zurückgab

(1) bleibt wahr, aber ich habe den Platzhalter-DNS-Eintrag entfernt, so dass eine Suche nach example.com jetzt nicht mehr zu einer Übereinstimmung mit example.com.mydomain.com führt.

verwandte Informationen