Spambekämpfung mit smtp prompt delay und RBL (spamhaus)

  • Hallo,


    wir leiden derzeit unter wiederkehrenden Spamwellen, die mehrmals täglich die Last des Servers an seine Grenzen bewegen. Nun dachte ich an die Einführung von Greylisting, jedoch hat mir ein Bekannter davon abgeraten und meinte man soll vor dieser Maßnahme eine Reihe anderer Aktionen einführen.


    Dazu gehören unter anderem "smtp prompt delay" und die Gegenprüfung bei RBL's wie Spamhaus.


    Für beides kann ich hier im Forum nichts finden. Hat jemand vielleicht Erfahrungen mit der Installation / Anpassung der beiden Methoden? Es würde mich auch interessieren wie Ihr die Sachlage seht.


    Schöne Grüße
    Dietmar

  • Greylisting tut bei unseren Servern seinen Dienst. Zwar nicht mehr ganz so effektiv wie noch vor einem Jahr. Allerdings ist es ein wichtiger Teil in der Abwehrkette. Ansonsten wird die Spamfilter Möglichkeit IMHO in PD-Admin 4.0 grundlegend überarbeitet. Glaube ich jedenfalls gelesen zu haben. ;) Wir setzen jedoch zur wirklich effektiven Abwehr von Spam auf eigene Mailgateways die nur Filtern und die Mails dann an die Backend-Server(also PD-Admin verwaltete) leiten.


    SMTP-Delay für QMail gibts hier:
    http://www.lewis.org/smtp-delay/

  • Hallo,


    smtp-delay und qmail-rbl tun nun ihren Dienst. In der tat blocken die beiden pro Minute ca. 5 vermeintliche Spammails.


    Greylisting finde ich persönlich als zu umständlich, wenn man dafür port 25 fürs authentifizieren abgeben muss. Da ist der Supportaufwand zu groß.


    Grüße
    Dietmar

  • Gleich vorweg: Ruhm und Ehre gebührt meinem Kollegen Urban Lösch von Raiffeisen Online, der da bei der Implementierung mehr als behilflich war.


    Wir haben folgendes implementiert:


    1) Die Blacklisten in der Reihenfolge:
    - sbl.spamhaus.org
    - xbl.spamhaus.org
    - pbl.spamhaus.org
    - bl.spamcop.net


    Die Blacklisten haben wir vor dem SMTP-Delay geschaltet. Näheres dazu weiter unten.


    2) smtp Prompt Delay. Der Promptdelay funktioniert wie folgt:
    - checkt ob eine eingehende IP einen richtigen Reverse DNS (PTR
    Record) eingetragen hat
    - einen PTR Record like (dialup, dynamic, etc.
    - oder keinen PTR Record hat.


    Warum der SMTP-Delay? Hauptsächlich um Viren zu blokieren und Spammer die nicht auf den SMTP-Pompt warten.
    Viren versuchen sich in der Regel so schnell wie möglich zu verbreiten.
    Wenn ein SMTP-Delay aktiv ist wird der SMTP-Prompt vom eigenen Mailserver um ein paar Sekunden verzögert. Werden innerhalb dieser Verzögerung Daten vom Absender gesendet unterbricht das SMTP-Delay die Connection. Jeder Mailserver der nach RFC arbeitet wartet bis er den SMTP-Prompt erhält, bevor er mit der Datenübermittlung beginnt.


    Biede Impelmetierungen sollten im Prinzip die Last von Server nehmen, da bereits auf Verbindungsebene geblockt wird, was den Spam/Virenfilter und somit die CPU entlasten sollte.


    Als OS nutzen wir Debian Etch.


    Einbau der Blacklisten:


    Wir haben dazu den modifizierten Daemon "rblsmtpd" von http://www.tjsi.com/rblsmtpd/ heruntergeladen. Es gibt auch noch das Original unter http://cr.yp.to/ucspi-tcp/rblsmtpd.html jedoch mit dem Unterschied, dass ersteres die geblockten IPs nach /var/log/mail.log schreibt (für Analysezwecke sehr gut geeignet).


    Der Deaemon ist vorkompilliert und hat bei uns funktioniert. Evtl. kann auch das Original gepatcht und mit der Syslogfunktion erweitert werden.
    Haben wir aber nicht getestet, da der bereits vorkompillierte Daemon bis jetzt bestens funktioniert hat.


    - Den Daemon herunterladen und entpacken.
    - Das .txt File evtl. lesen.
    - Der Daemon kann mit ./rblstmpd -v ausgeführt werden (etvl. zum Test).
    - Auch evtl. mit ldd checken ob die benötigten Bibliotheken installiert sind.
    - Den Daemon nach /var/qmail/bin/ kopieren und mit den richtigen Dateirechten versehen. Wir haben einfach die selben genommen wie bei den qmail Dateien.
    - Das File /service/qmail-smtpd/run editieren (vorher Backup machen) und um folgende Zeilen erweitern.



    Code
    exec .... /tcp-env relaylock /var/qmail/bin/rblsmtpd -v -r sbl.spamhaus.org /var/qmail/bin/rblsmtpd -v -r xbl.spamhaus.org /var/qmail/bin/rblsmtpd -v -r pbl.spamhaus.org /var/qmail/bin/rblsmtpd -v -r bl.spamcop.net /var/qmail/bin/qmail-smtpd .....


    Für jede eingesetzte Blacklist muss der Daemon eingens hintereinander gesartet werden. Die -v Option aktiviert das Logging über Syslog nach "/var/Log/mail.log"


    - Nun noch mit svc den Qmail stoppen und Starten. Der Mailserver sollte ohne Prbleme wieder hochkommen.
    - Sobald das die ersten Connections geblockt werden sieht das im Maillog dann ca. so aus.


    Code
    Jul  6 09:14:20 web1 rblsmtpd: pbl.spamhaus.org blocked 221.120.35.191 - - 
    Jul  6 09:14:25 web1 rblsmtpd: xbl.spamhaus.org blocked 66.66.136.30 - - 
    Jul  6 09:14:37 web1 rblsmtpd: xbl.spamhaus.org blocked 66.66.136.30 - - 
    Jul  6 09:14:50 web1 rblsmtpd: xbl.spamhaus.org blocked 222.106.81.196 - - 
    Jul  6 09:15:12 web1 rblsmtpd: xbl.spamhaus.org blocked 217.91.121.8 - - 
    Jul  6 09:15:23 web1 rblsmtpd: xbl.spamhaus.org blocked 63.225.237.122 - - 
    Jul  6 09:16:00 web1 rblsmtpd: xbl.spamhaus.org blocked 63.225.237.122 - - 
    Jul  6 09:16:39 web1 rblsmtpd: xbl.spamhaus.org blocked 63.225.237.122 - - 
    Jul  6 09:16:47 web1 rblsmtpd: xbl.spamhaus.org blocked 89.243.120.130 - - 
    Jul  6 09:16:48 web1 rblsmtpd: pbl.spamhaus.org blocked 84.57.20.187 - -



    Der Absender erhält übrigens eine kurze Mitteilung dass seine Mail nicht zugestellt werden konnte. Der Link zum RBL Archiv ist darin bereits gesetzt.


    Hier noch ein Kurzes Shellscript dass täglich per Cronjob einen Grep auf das Maillog macht und zusammenrechnet wieviele IPs geblockt wurden.
    Wenn jemand Lust hat das Script zu verfeinern und z.B. Top BLocked IPs usw zu erweitern, dann hätten wir ganz gerne eine Kopie davon :P




    Einbau des SMTP-Delays:


    - Download unter http://www.lewis.org/smtp-delay/
    - Das Teil mus eigens kompilliert werden. Wie das geht steht kann unter oberen Link anchgelesen werden.
    - Wieder nach /var/qmail/bin/ kopiern und nach Dateirechte anpassen.
    - Das File /service/qmail-smtpd/run editieren (voher Backup machen) und um folgende Zeilen erweitern.

    Code
    ...
    #Neue Variablen
    # Server mir Reverse DNS OK werden 2 Sekunden verzögert.
    SMTPDELAYd=2
    # Server mit Dynamic Reverse DNS werden 10 Sekunden verzögert.
    SMTPDELAYD=10
    # Server mit No Reverse DNS werden 20 Sekunden verzögert.
    SMTPDELAYP=20
    ...
    exec ..../var/qmail/bin/rblsmtpd -v -r bl.spamcop.net /var/qmail/bin/smtp-delay -S -d $SMTPDELAYd -D $SMTPDELAYD -P $SMTPDELAYP /var/qmail/bin/qmail-smtpd .....


    Mit svc wiederum stoppen und starten und dann kann mit Telnet getestet werden. Sofern alles klappt und der Test z.B. von einer IP mit dynamischen Reverse DNS kommt wird der SMTP-Prompt vom Mailserver je nach Einstellung um XX Sekunden verzögert. Gbt man vorher was ein wird die Verbindung gekappt.


    z.B. Test mit einer IP ohne Reverse DNS
    ~$ telnet www.domain.com 25
    Trying XXX.XXX.XXX.XXX...
    Connected to Mailserver.
    Escape character is '^]'.
    dfadsf
    451 Rejected due to illegal pipelining
    Connection closed by foreign host.


    Die Zeitwerte können nach belieben angepasst werden.
    Bei Dynamic Reverse DNS wird gewissen Regulären ausdrücken gescannt. Die Ausdrücke sind auf der Homepage aufgelistet.
    Idealerweise sollten IPs ohne Reverse DNS generell abgewiesen werden.
    Leider scheiden sich hier die Geister und wir haben nichts gefunden das umzusetzten. Wenn jemand dafür was weiss kann er es ja hier posten.


    SMTP-Delay hat 2 Nachteile:
    - Leider wird hier nichts geloggt.
    - Clients die über den Mailserver versenden sind ebenfalls vom Delay betroffen. Macht aber laut Erfahrung bei anderen Servern kein Problem.


    Allgemeines:
    Wir haben leider keine Ahnung ob die Anpassungen ein SE Update überleben. Daher umbedingt alles Backupen um nach einem SE Update alles wieder einbauen zu können.


    Update:
    Herr Bradler machte mich darauf aufmerksam dass qmail nicht Bestandteil der SE ist und somit ein SE Update keine Auswirkung auf das hier hat.


    Weiters übernehmen wir keine Garantie/Haftung ob das oben Beschriebene korrekt und für andere Systeme funktioniert.


    Sollte die ganze Geschichte hier HOWTO-tauglich sein dann möge es einer der Admin's dorthinverschieben :)


    Grüße
    Dietmar

  • Ich habe den Part mit rblsmtpd eingebaut. Funktioniert excellent. SpamAssassin wird signifikant entlastet, auch die User haben den Effekt sofort bemerkt.


    Allerdings musste ich beim Einbau die gesamte Geschichte neu kompilieren, das war etwas tricky, läuft aber nun zufriedenstellend.


    Ein möglicher Nebeneffekt der Sache scheint jedoch zu sein, dass bestimmte User mit T-Offline-IPs u.ä. nicht direkt auf Port 25 Mails einliefern können, mglw. auch nicht per SMTP-AUTH sondern dann auf den Port 587 zurückgreifen müssen. Aber das habe ich noch nicht abschließend erforscht, hatte nur ein paar Rückmeldungen dbzgl.

  • Kann es sein dass die sbl.spamhaus.org zu restriktiv ist? Nimm diese mal raus und wahrscheinlich werden die Mails dann wieder eingeliefert. Wir hatten das selbe Problem bei Arcor IP's. Nach dem Entfernen der sbl hatten die Kundenmeldungen dann wieder schlagartig nachgelassen.


    Grüße
    Dietmar

  • Spamhaus.org würde ich nicht einsetzen. Mir persönlich gibt es da zu viele Fehlalarme und die sind auch bekannt dafür schnell mal nen ganzen Netzblock von großen, gerne auch deutschen ISPs auf die Blacklist zu nehmen. Immer mal wieder sind z.b. dabei T-Com, Domainfactory, Arcor usw ... mal von der Geschichte mit der nic.at Erpressung abgesehen. Nix-Spam von Heise finde ich recht nett. ;)

  • Mir gefällt der Ansatz von qgreylistrbl etwas besser, da Greylisting dort nur dann zum Einsatz kommt, wenn eine Blacklist matcht. Sprich "Hey, Du bist auf einer Blacklist, jetzt musst Du erstmal den Greylisting-Test bestehen".


    Gefällt mir persönlich vom Gedankengang her besser als prinzipielles Greylisting bei jedem Host.

  • Ich hatte Greylisting testweise aktiviert. Nach meiner persönlichen Erfahrung hat es sich als wenig wirksam erwiesen. Auf der anderen Seite sind die Nachteile durch die verzögerte Mailzustellung doch bemerkenswert.


    Obwohl eMail nicht den Anspruch erhebt ein Echtzeit-Kommunikationsmedium zu sein, hat man sich an die Geschwindigkeit gewöhnt (z.B. Anmeldung, Passwort-Rücksetzung bei Foren usw.) und so auch die Kunden. Aufgrund der mangelnden Effizienz habe ich Greylisting wieder deaktiviert.


    Einen geradezu durchschlagenden Erfolg hat hingegen rblsmptd erzielt. Die Menge der Mails, die durch SpamAssassin bearbeitet werden müssen, ist um ca. 75% gesunken. Ich setze dabei folgende Blacklists ein:


    - NiX Spam (http://www.dnsbl.manitu.net)
    - The Abusive Hosts Blocking List (http://www.ahbl.org)
    - Spamhaus [SBL, XBL und PBL] (http://www.spamhaus.org)
    - SpamCop (http://spamcop.net)
    - Not Just Another Bogus List (http://www.njabl.org)


    PBL wird mit Absicht eingesetzt, da sehr viel Spam von dynamischen Adressen kommt. Da ich nur "Individualkunden" betreue, habe ich denen das mitgeteilt und sie haben sich an Port 587 zum Mailversand gewöhnt, alternativ wäre auch ein getrennter Maileingangs- und Ausgangsserver denkbar.


    Zusätzlich sollen noch PTR-Checking zum Blocken und SPF zu Verbesserung der Spam-Erkennung eingesetzt werden.


    Spam-Assassin selbst arbeitet dank verschärfter Konfiguration, guten Bayes-Mustern und Einbindung von DCC mit sehr guter Erkennungsrate. Nur bei ganz ganz neuen Ideen der Spammer dauert es manchmal einen Tag, bis diese Mails dann auch zuverlässig erkannt werden. Durch manuell eingebauten MailDirFilter werden die erkannten SpamMails bei den Kunden direkt in ein separates Verzeichnis verschoben.


    Unter dem Strich ist es eigentlich erschreckend, wieviel Arbeit ich in dieses Thema stecken musste, nur um halbwegs ein spamfreies Postfach für meine Kunden und mich selbst zu gewährleisten. Aber ich muss sagen,die Diskussionen zu diesem Thema hier im Forum haben mir sehr viel weitergeholfen.


    Gruß
    Xorp.

  • Zum Thema Greylisting gibt es im aktuellen Linuxmagazin einen Artikel. Die Wirksamkeit hat sicher in der letzten Zeit nachgelassen, aber ist auf jeden Fall ein wichtiger Baustein in der Spam-Abwehr-Kette. "Wenig wirksam" kann ich absolut nicht bestätigen. Und wir betreiben einige Mailserver und große Mailgateways. Nicht nur kleine PD-Admin Server. Spamhaus und SpamCop halte ich für nicht tragbare Listen die viel zu restriktiv für einen produktiv Server mit nur mittelmäßigen Mailaufkommen sind. Ich habe da aus Erfahrung im Endeffekt viel Arbeit in das Forcen von False Positives stecken müssen. SPF gibt es schon lange und wird mittlerweile auch von Spammern "eingesetzt" um ihren Müll durchzubekommen. Mehr dazu im Netz. ;)

  • Im rein unternehmerischen Umfeld mag die Auswahl der DNS-BLs durchaus etwas zu restriktiv sein. Pro Tag werden bei meinem Server etwa 2000 Mailzustellversuche abgewiesen - Stichproben haben ergeben, dass die betreffenden IP-Adressen allesamt nicht "vertrauenswürdig" waren.


    Auf der anderen Seite hat sich bisher niemand bei mir beschwert, wirklich erwartete Mails nicht bekommen zu haben oder das diese von SA zu Unrecht als Spam eingestuft wurden.


    Das muss letztlich jeder mit seinen Kunden ausmachen. Die Problematik mit SPF ist mir bekannt. Bzgl. Greylisting kann ich auf persönliche Erfahrungen zurückgreifen. Ich bekomme tgl. ca. 100 Spam-Mails "persönlich". Mit Greylisting waren immernoch mind. 70.


    Fazit: Es muss halt jeder selbst entscheiden, wie er sein Spam-Aufkommen optimal reduziert ;)

  • Tja, die eierlegende Wollmilchsau gibt es nicht, für den einen Provider mag eine Lösung sinnvoll sein, die für einen anderen Provider aber lange noch nicht sinnvoll ist. Könnte man meinen - ich dagegen tendiere aber immer mehr in die Richtung: was für den einen Kunden klasse ist, kann für einen anderen Kunden katastrophal sein.


    Worauf will ich mit der Aussage nun hinaus? Ganz einfach. Es scheint einfach nicht mehr zeitgemäß bzw. gar praktikabel, Filterungen Providerweit zu tätigen. Filterungen sollten auf Kundenebene ansetzen und hier kommt dann PD-Admin ins Spiel:


    Greylisting pauschal
    Greylisting nur bei Blacklist-Match
    Endkundentaugliche Auswahl der anzuwendenden Blacklisten (z.B. Soft, Medium,Agressive) oder eben die einzelnen Blacklists z.B. im "PD-Admin Professional-Mode"
    SMTP-Delay
    usw.


    Das alles sollte _pro_ Kunde einstellbar sein, wenn nicht sogar _pro_ Postfach, was ja technisch problemlos möglich ist - und zwar noch im smtp-Dialog. Wir wissen bereits im SMTP-Dialog, welches die Zieladresse ist - damit wüssten wir auch, was und wie gefiltert werden soll. Das könnte man nutzen und jedem Kunden eine für ihn optimale Lösung anbieten.


    Im Idealfall kann der Kunde Mailfiltervorlagen erstellen, die festlegen, wie seine Mails gefiltert werden sollen. Davon könnte er dann ein paar anlegen und seinen Postfächern eine Mailfiltervorlage zuweisen. Ähnlich wie wir auch nicht bei jedem einzelnen Kunden auswählen, welche Leistungen der Kunde in seinem Webspace erhalten soll, sondern ihm einfach eine Angebotsvorlage zuweisen - fertig.

  • moin moin,


    ich habe einen server bei firstdedicated. da dieser server lahmgelegt wurde durch eine mailbombe, deren stream nicht aufhört und mir meine hdd binnen kürzester zeit voll müllte, wollte ich euer hotwo herannehmen um qmail etwas resistenter dagegen zu machen. soweit, sogut. die datei "run" im /service/qmail-smtp/ ordner, die modifiziert werden muss gibt es jedoch bei mir nicht, woraufhin ich firstdedicatet ein support ticket schrieb, welches mit folgender antwort zurückkam :"

    Hallo,


    es handelt sich hier um eine spezielle Version von QMail die nicht komplett über die Daemontools arbeitet.


    Daraufhin werden Sie leider keine Lösung finden."


    ich verzweifel hier nochmal, da der mailserver jetzt erstmal down ist, weil die mailbombe noicht aufhört. hat jemand evtl. eine lösung für mein problem? ... weil greylisting , sowie auch die version des schutzes aus diesem howto (spamhaus) geht bei mir nicht, da die "run" datei fehlt.


    ich hoffe ihr könnt mir helfen.


    gruß ... smiley

  • Der gängige Weg, qmail zu starten, ist der über die daemontools. Daher beziehen sich die meisten Anleitungen auf eine solche Installation. Meine Empfehlung ist daher, den Mailserver mit den daemontools+ucspi-tcp neu aufzusetzen.


    Viele Grüße,
    Daniel Bradler

  • danke für die fluxe antwort. aber da kommt die nä. frage ... wenn ich den mailserver neu aufsetze, müssen dann sämtliche e-mail daten via pd-a neu eingegeben werden, oder werden diese übernommen?


    gruss ... smiley