Erfahrung mit dem Spamhaus Modul für Apache

[electric.larry]

Ich habe vor kurzer Zeit Apaches mod_spamhaus aktiviert. Heute kam die erste Meldung eines Benutzers, dass er nach dem Login auf seiner Website eine Fehlermeldung bekommt:

Access Denied! Your address is blacklisted. More information about this error may be available in the server error log.

Im Apache error.log File findet sich dazu dieser Eintrag:

[spamhaus:crit] [pid zzzzz] [client xxx:yyy] mod_spamhaus: address 11.22.33.44.sbl-xbl.spamhaus.org is blacklisted. Deny connection to www.xxxxxxx.at/some/script.php, referer: www.xxxxxxx.at/some/other/script.php

Habt ihr Erfahrung mit mod_spamhaus oder irgendwelche Konfigurations-Tips?
Kommt es hier öfter zu False Positives?
Wie geht ihr damit um, genügt ein Eintrag der IP in der Whitelist oder werde ich dann täglich mit Whitelist-Anträgen von Leuten mit dynamischen IP Adressen rechnen müssen?

 

[drfuture]

Die Frage ist was du dir davon eigentlich versprichst?
Die Blacklist listet bekannte Spam-Versender... das sind - wie du schon selber gemerkt hast - sehr häufig Dial-UP IP's wobei man dabei zumeist die falschen trifft da die IP in die Liste kommt wenn der betreffende Benutzer schon wieder eine andere IP hat.

so im allgemeinen erschließt sich mir der Sinn des Moduls gerade insgesamt nicht - warum man beim Webserver user die Spam versenden sperren sollte.. Glaube Spam-Bots die über deinen Server Mails verschicken kommen dort nie rein - weil dann nur die IP deines Servers in den Logs auftaucht - und Spam-Bots die über Sicherheitslücken etc. Werbung auf deiner Seite verbreiten dürften ebenfalls nicht im Bestand der Liste auftauchen.

 

[electric.larry]

Laut http://wiki.ubuntuusers.de/Apache/mod_spamhaus sollte das Modul folgendes machen:

mod_spamhaus ist ein Modul, welches eine DNS-based Blackhole List (DNSBL) verwendet, um Spam-Relay über Web-Formulare zu blockieren, URL-Injektion zu verhindern, DDoS-Angriffe von Bots über das Protokoll HTTP zu blockieren und den Zugang von einer bekannten IP-Adresse, die in der DNSBL von Spamhaus {en} geführt wird, zu verweigern.

Die Frage ist was du dir davon eigentlich versprichst?

Die Hoffnung war, den Spam der über Kontaktformulare an Website betreiber verschickt wird, zu verringern.

 

[drfuture]

Glaube eben weniger das ein solcher Bot je in der Spamhaus-Liste auftaucht - da dein Server die Mails verschickt und nicht der Bot - wird der Bot eher selten irgendwo gemeldet.
Soweit ich die config überflogen habe kann man das Modul wohl auch nicht auf nur eine .php beschränken... damit wenigstens nur das Kontaktformular geschützt wird.
Somit glaube ich das das Modul nur die falschen aussperrt

 

[electric.larry]

Danke fuer deine Einschaetzung. Dass man nicht mehr Konfigurationsmoeglichkeiten hat, ist definitiv ein Nachteil.

Aber ist mein Gedankengang grundsaetzlich falsch? Ein Bot laeuft auf irgendeinem Host, sei es eine gehackte Website oder eine angemietete Box und crawlt von dort aus Kontaktformulare in die er seinen Spam postet.
Ueber einen Honeypot oder wie auch immer landet der Host auf dem der Bot laeuft auf der Spamhaus Liste. Erreicht der Bot danach per Zufall meinen Server und versucht dort ueber Http POST request ein Kontaktformular ab zu schicken, wird er von diesem Modul daran gehindert.

 

[Kugelfisch]

Der Gedankengang ist grundsätzlich korrekt, allerdings können von solchen Blocks leicht auch legitime Benutzer betroffen sein, welche z.B. von ihrem ISP eine IP-Adresse erhalten, hinter welcher am Tag zuvor ein kompromittiertes System Spam verschickte. Sinnvoller wäre deshalb, dein Kontaktformular abzusichern, dass darüber kein Spam-Versand (oder maximal ein Versand an dich selbst) möglich ist. Insbesondere solltest du eine E-Mail-Bibliothek verwenden, welche dich gegen E-Mail-Injection-Schwachstellen schützt. Wenn du selbst über dein Kontaktformular vermehrt Spam erhältst, währe auch ein CAPTCHA eine mögliche Gegenmassnahme.

Generell sämtliche Requests gegen eine DNSRBL zu prüfen, welche ursprünglich dazu gedacht war, Spam-E-Mail zu verhindern, scheint mir keine gute Idee. Einige dieser DNSRBLs enthalten sogar absichtlich diverse DHCP-Blöcke von Internet-Zugangsprovidern für Privatkunden, weil davon ausgegangen wird, dass Endkunden ihre E-Mails über einen Smarthost übertragen und nicht direkt beim Empfänger-MX einwerfen.

 

[electric.larry]

Insbesondere solltest du eine E-Mail-Bibliothek verwenden, welche dich gegen E-Mail-Injection-Schwachstellen schützt.

Kannst du hier etwas konkretes Empfehlen?

Auf dem betroffenen Server laufen verschiedenste Web-Formulare, die von unterschiedlichen Content Management Systemen stammen oder komplett haendisch gestrickt wurden. Welches eingesetzt wird, kann ich in diesem Fall nicht beeinflussen. Gemein haben die Formulare lediglich, dass sie alle die PHP mail(..) Funktion in irgendeiner Art und Weise verwenden.

 

[Kugelfisch]

Ich verwende dazu für komplett eigene Formulare die `Swift Mailer`-Bibliothek; abgesehen davon, dass dadurch E-Mail-Injections verunmöglicht werden und man dennoch die angegebene E-Mail-Adresse des Benutzers als Reply-To-Adresse setzen kann, kann Swift Mailer insbesondere auch gültige MIME-E-Mails erzeugen, was für die korrekte Übertragung deutscher Umlaute notwendig ist, und erlaubt z.B. auch Anhänge oder multipart/alternative-Nachrichten.

Allerdings ist Swift Mailer kein Drop-in-Replacement für PHPs [kw]mail()[/kw]-Funktion. Wenn du die Formulare nicht alle anpassen kannst oder möchtest, solltest du zumindest dafür sorgen, dass Benutzereingaben niemals in den [kw]$additional_headers[/kw]-Parameter eingebaut werden, welcher an mail() übergeben wird. So darf dort z.B. kein From- oder Reply-To-Header mit der vom Benutzer eingegebenen E-Mail-Adresse erzeugt werden, da ansonsten bei falscher oder nicht vorhandener Überprüfung der übergebenen E-Mail-Adresse eine E-Mail-Injection-Schwachstelle aufgerissen wird.

 

[electric.larry]

@Kugelfisch: Danke für den Tip. Leider hilft er mir in diesem Fall nicht wirklich weiter. Ich programmiere diese Seiten nicht, ich versuch nur sicher zu stellen, dass sich keine ungebetenen Gaeste in das Zelt von unserem Indianer setzen

 

[Kugelfisch]

Wenn du den Code nicht verändern kannst, willst oder darfst, bliebe als evasive Massnahme noch die Verwendung von mod_security2 mit einem eigenen Regelsatz. Allerdings darf dieser nicht zu strikt sein, wenn du die Webanwendungen nicht im Detail kennst. Alternativ kannst du in PHP-Suhosin über die suhosin.mail.protect-Direktive verbieten, dass bestimmte, von normalen Webanwendungen selten und von Spammern häufig verwendete zusätzliche Header wie To, Cc oder Bcc gesetzt werden - siehe auch http://suhosin.org/stories/configuration.html#suhosin-mail-protect.