DNSBL basierenden Spamschutz

[stefan-becker]

Hallo,

wird dieser Test für eingehende Mails oder auch für "ausgehende" Mails durchgeführt?

 

[Huschi]

Wenn Du ein std. Plesk hast, dann nur für SMTP-Eingehende Mails.
Denn die RBL-Aufrufe werden über /etc/xinetd.d/smtp_psa.conf aufgerufen.

huschi.

 

[stefan-becker]

Und was ist, wenn ich dein Greylisting verwende?

Was ist wenn ich diese DB für "abgehende" Mails nutzen möchte? Was sind denn effektive Maßnahmen, den eigenen Mailserver zu schützen?

 

[Huschi]

Und was ist, wenn ich dein Greylisting verwende?

Danke für die Lorbeeren, aber es ist nicht mein Greylisting. Hab lediglich ein Howto mit vielen Detail-Verbesserungen gemacht.

Was ist wenn ich diese DB für "abgehende" Mails nutzen möchte?

Welche DB und für was für "abgehende" Mails?

Was sind denn effektive Maßnahmen, den eigenen Mailserver zu schützen?

Welchen Schutz meinst Du?
Den Schutz des eigenen Postfaches gegen Spam?
Oder den Schutz dagegen als Spam-Server missbraucht zu werden?

huschi.

 

[stefan-becker]

Ich meine wenn ich DNSBL basierenden Spamschutz benutze, funktioniert das dann noch mit deinem HowTo?

Dank Greylisting und Spam Filter sind meine Mailbox so gut wie frei von Spam. Obwohl ja Greylisting langsam auch umgangen werden kann.

Ja ich meine, dass mein Mail Server als Spammer missbraucht wird. Klar auf der einen Seite haben wir Script Sicherheit (PHP), aber wie kann ich sicher stellen das infizierte User über meinen Server SPAM verschicken. Ich kann ja DNSBL auch für einliefernde Host benutzen, die Frage ist wie und ob ich es noch besser machen kann.

 

[Huschi]

Ich meine wenn ich DNSBL basierenden Spamschutz benutze, funktioniert das dann noch mit deinem HowTo?

Warum nicht? Sind zwei getrennte Programme. Siehe Qmail-Ablaufdiagramm; der RBL-Check liegt zwischen relaylock und qmail-smtpd.

Obwohl ja Greylisting langsam auch umgangen werden kann.

Gäääääääään! Gerüchteküche...... und eine schlechte dazu....

Ja ich meine, dass mein Mail Server als Spammer missbraucht wird.

Dann lege ich Dir folgenden Artikel ans Herz: Über meinen Server werden Spam's verschickt! - huschi.net
Und ein RBL hilft Dir hier rein gar nichts.

huschi.

 

[Bierteufel]

Ich hab mal eine (evtl. du**e) Frage.

Bewirkt die AKtivierung im PLESK


-> Spamschutz auf Basis der DNS-Blackhole-Listen aktivieren -> DNS-Zonen für DNSBL-Dienst -> Und hier würde ich dann gerne folgende Liste nutzen

http://www.heise.de/ix/nixspam/nixspam.blackmatches

etwas ?

Bzw. geht das so überhaupt. Greylisting nutze ich nat. auch schon ;-)

 

[marneus]

Hallo Bierteufel!

Ja, es bewirkt was. Hierzu musst Du im Pleskpanel die entsprechende URL angeben.

--marneus

 

[Bierteufel]

Danke für das schnelle Feedback:

Muss ich im PLESK

http://www.heise.de/ix/nixspam/nixspam.blackmatches

oder

www.heise.de/ix/nixspam/nixspam.blackmatches

als URL angeben ?

Die Bsp. in der PLESK Anzeige sind ohne Protokollanagbe (sprich ohne http).

 

[marneus]

Das kann ich Dir nicht genau sagen. Die Doku von Plesk müsste dadrüber Auskunft geben. Ich würde es ohne Protokoll versuchen (bei mir geht es jedenfalls ohne).

 

[Bierteufel]

Welche Liste nimmst Du denn ?


Leider mag PLESK den String nicht

www.heise.de/ix/nixspam/nixspam.blackmatches

 

[akxak]

Hast Du es mit dem Eintrag

ix.dnsbl.manitu.net

mal probiert? Der geht bei mir.

 

[Bierteufel]

Na dann probier ich den mal !

 

[akxak]

Bei mir sieht es unter /etc/xinet.d wie folgt aus:

smtp_psa:

service smtp
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        disable         = no
        user            = root
        instances       = UNLIMITED
        server          = /var/qmail/bin/tcp-env
        server_args     = -Rt0 /usr/sbin/rblsmtpd -v -r ix.dnsbl.manitu.net /var/qmail/bin/relaylock /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/true /var/qmail/bin/cmd5checkpw /var/qmail/bin/true

wobei ich eine modifizierte Version von rblsmtpd verwende, die Logging beherrscht (daher der -v Parameter). In der Standard-Installation muss der weggelassen werden. Die modifizierte Version gibt mir damit aber einen Überblick, was an Rejects erfolgt.

Im smtps_psa habe ich den rbl-Check herausgenommen, um meinen Nutzern (die ja meistens dynamische IPs haben) jederzeit den Versand von Mail zu ermöglichen. SMTPAUTH greift ja erst nach dem rbl-Check und dann wäre es zu spät.

Das lässt sich aber nur durch manuelle Anpassung erreichen, Plesk kann das so nicht.

 

[M:ke]

HAllo akxak,

Vielen Dank, dein Beitrag hilft mir ungemein. Denn ich bin aufgrund des ganzen Spams, die wir über unsere 1und1-Server erhalten ganz schön verzweifelt.

Ich hatte im Plesk als MAPS-Spamschutz die Zone "zen.spamhaus.org" eingetragen, das brachte aber das Problem mit sich, dass dort etliche IP-Adressen gesperrt sind, auch ganze Zonen der dynamischen Telekom-IP-Adressen.

Jetzt bin ich auf die Nixspam-Blackliste gestoßen und versuche es damit. Allerdings habe ich noch ein paar Fragen:

1. Gilt das Blacklisting auch für eingehende Mails?
2. Wenn ja, wo stell ich ab, dass das Blacklisting (der rblsmptd) für von Kunden via SMTP gesendete Mails aktiviert wird.

Ich möchte den Spam-Empfang reduzieren, nicht unsere Kunden als angebliche Spammer markieren.

3. Warum machst du ein Rt0? Die Manpage sagt:

Do not attempt to obtain TCPREMOTEINFO from the remote host.

4. Wie krieg ich Ausgaben zum rblsmtpd aktiviert? Ich möchte halt gern erfahren, wann und warum Mails blockiert werden, bevor es der Kunde erfährt.


Grüße,
M:ke

 

[Huschi]

zu 1) Gerade für die. Aber Du meinst wahrscheinlich die zu verschickenden Mails.

zu 2) Brauchst Du in der Regel nicht extra abstellen.

zu 3) Siehe Qmail: Beim Mail-Versand dauert die Verbindung 30-60 Sekunden

zu 4) Selber kompilieren.

huschi.

 

[akxak]

Jetzt bin ich auf die Nixspam-Blackliste gestoßen und versuche es damit. Allerdings habe ich noch ein paar Fragen:

Hi!

Ich nutze die nixSpam-Liste und ergänzend SORBS.

1. Gilt das Blacklisting auch für eingehende Mails?

Du meinst für Mails, die von berechtigten Usern eingeliefert werden.

Ja, denn das RBL-Blocking ist die allererste Prüfung, die gemacht wird. Zu dem Zeitpunkt kann der Server noch nicht wissen, wer da überhaupt senden will.

2. Wenn ja, wo stell ich ab, dass das Blacklisting (der rblsmptd) für von Kunden via SMTP gesendete Mails aktiviert wird.

Das ist automatisch so, führt aber schnell zu Problemen, denn die Nutzer haben in der Regel dynamische IPs, die sich auf den Blacklists finden. Da Spam in der Regel auf dem Port 25 eingeliefert wird, beschränke ich den RBL-Check auf diesen Port. Auf dem SSL-Port (SMTPS) findet kein RBL-Check statt und meine User wissen das. Zusätzlich kennt Plesk ab der aktuellen Version unter Server->Mail->"Enable message submission" auch die Möglichkeit, den Port 587 für das Einliefern von Mails zu nutzen.

Das habe ich zusätzlich aktiviert, auch dort erfolgt kein RBL-Check.

Ich möchte den Spam-Empfang reduzieren, nicht unsere Kunden als angebliche Spammer markieren.

Lösung: siehe oben, die Nutzer müssen auf einen anderen Port, auf dem Standard-Port ist das Problem nicht lösbar.

3. Warum machst du ein Rt0? Die Manpage sagt:

Siehe die Hinweise zu Qmail in der FAQ von swsoft...

4. Wie krieg ich Ausgaben zum rblsmtpd aktiviert? Ich möchte halt gern erfahren, wann und warum Mails blockiert werden, bevor es der Kunde erfährt.

Dazu musst Du den rblsmtp manuell compilieren (und ich habe ihn auch in einigen Punkten angepasst, damit er das tut, was ich will und ich sehe, was er tut). Dazu sollte man (spätestens beim Anpassen) in C programmieren können und wissen, was man da tut... sonst legt man sich das Mail-System lahm oder schafft sich eine unerwartete Lücke im System.

Grüsse,

akxak

 

[M:ke]

Hallo Leute.

Erstmal vielen Dank für eure Antworten. Für jemanden, der ziemlich neu im Umgang mit Plesk ist, seid ihr eine Rießenhilfe. Ich werde sehen welche Strategie ich in Zukunft einschlage. Ich benötige erstmal einen vernünftigen Spamschutz den ich auf einem unserer Server testen kann, wenn das funktioniert werde ich das schnell auf die anderen Server adaptieren. Allerdings bin ich mit der Lösung entweder SSL oder anderer Port für unsere Kunden nicht wirklich zufrieden, aber letzlich wird uns nichts anderes übrig bleiben.

Zusätzlich kennt Plesk ab der aktuellen Version unter Server->Mail->"Enable message submission" auch die Möglichkeit, den Port 587 für das Einliefern von Mails zu nutzen.

Ich habe Plesk 8.3.0 auf Deutsch. Dort gibt es die Einstellung:

Nachrichtenübermittlung aktivieren (wird für alle IP-Adressen aktiviert)

Ich vermute das ist die, die du meinst. Aber ist dort nach Plesk eine SMTP-Verschlüsselung aktiv?

cat /etc/services |grep 587
submission 587/tcp # Submission [RFC2476]
submission 587/udp

Ich habe aber noch ein anderes Problem: Ich habe Relaying für SMTP nur via SMTP-Auth aktiviert (in Plesk heißt das Authorisierung notwendig für SMTP). Allerdings kann ich auch ohne SMTP-Auth Emails über den Server verschicken. Ist mir ein Rätsel warum.

Hier versende ich von meinem lokalen Rechner eine Mail von einem Account, zu einem anderen Account. Der Empfänger- und Sender-Server ist identisch.

# telnet mail.helt***.com 25
Trying 212.227.***.***...
Connected to mail.helt***.com.
Escape character is '^]'.
220 ***.onlinehome-server.info ESMTP
HELO mail.helt***.com
250 ***.onlinehome-server.info
MAIL FROM: miketest@helt***.com
250 ok
RCPT TO: mike.***@ty***.net
250 ok
DATA
354 go ahead
Subject: Hallo Welt

.
250 ok 1204536966 qp 7609
QUIT
221 ***.onlinehome-server.info
Connection closed by foreign host.

Hier ist der Empfänger-Server ein anderer (mein privater). Aber auch diese Mail wird akzeptiert.

# telnet mail.helt***.com 25
Trying 212.227.***.***...
Connected to mail.helt***.com.
Escape character is '^]'.
220 ***.onlinehome-server.info ESMTP
HELO mail.helt***.com
250 ***.onlinehome-server.info
MAIL FROM: miketest@helt***.com
250 ok
RCPT TO: mike.***@villa***de
250 ok
DATA
354 go ahead
Subject: Bitte antworten.

.
250 ok 1204537078 qp 8043
QUIT
221 ***.onlinehome-server.info
Connection closed by foreign host.

Irgendeine Idee? Nicht das unsere Server als offene Relays fungieren.

Grüße,
M:ke

Nachtrag: Laut huschis geposteter Relay-Test-URL (Anonymous Relay Test) sind die Server keine offenen Relays.

Nachtrag 2:
Ich lese gerade auf Qmail SMTP authentication, folgendes:

Server hide its SMTP AUTH support (in EHLO command) when relay is permitted for remote computer

Wenn ich ein EHLO auf den Server mache, sagt der:

EHLO mail.***.com
250-ty1.***.net
250-STARTTLS
250-PIPELINING
250 8BITMIME

Nichts mit Authentifizierung.

Status: Ich kann weder mit Apple Mail, noch mit Outlook via SMTP (mit Authentifizierung) EMails verschicken, ohne Authentifizierung klappts. Thunderbird verschickt die Mails problemlos (vermutlich hat Thunderbird ein Fallback).


Nachtrag 3:
Ein Blick in die maillog sagt folgendes.

# tail -f /usr/local/psa/var/log/maillog | grep relaylock
Mar 3 16:33:39 s15260829 relaylock: /var/qmail/bin/relaylock: mail from 84.19.***.***:4253 (not defined)

Und die IP-Adresse dort ist meine.


Nachtrag 4:
Nach einer Such nach dem Begriff "relaylock" in den swsoft-Foren (Plesk-Hersteller), bin ich auf diesen Artikel gestoßen:
How to fix relaying while using RBL/MAPS - Parallels Forums
Da das ziemlich einfach umzusetzen klang, wollte ich es gleich mal bei den problematischen Servern einstellen und habe mich nun endlich dafür entschieden, meinen Kunden mitzuteilen ihre SMTP-Verbindungen über Port 587 zu erledigen.
Allerdings stellte ich beim Umbau fest, dass auf allen Servern, auf denen ich bereits das Blacklisting eingeschalten und später wieder ausgeschalten habe, immernoch der "geheime" 587-Port mit qmail geöffnet war.
Also habe ich in meinen Testaccounts den Port umgestellt und siehe da: Der Mailversand funktionierte einwandfrei.
Vermutlich hat Plesk nach dem Deaktivieren der Blacklists seine Einstellungen nicht zurückgenommen.

Aber momentan bin ich ganz zufrieden so, jetzt habe ich einige Telefonate vor mir. Ich hoffe dass diese Lösung auch die Lösung des massiven Plesk-Spam-Problems ist.

Danke und viele Grüße,
M:ke

 

[akxak]

Vergiss den relaylock-Eintrag, der hat keine Bedeutung...

Natürlich nimmt der Server Mails an eine seiner Domains auch ohne Authentication an.. das ist Sinn und Zweck der Sache. Relaying bedeutet ja, dass der Server die Mail an einen anderen Mail-Server weiterleitet und das erfordert eben eine Authentisierung.

Und auf dem Port 587 ist natürlich auch SMTP-Auth aktiv, vergleiche die Einträge unter /etc/xinetd

 

[Rene]

Das ist automatisch so, führt aber schnell zu Problemen, denn die Nutzer haben in der Regel dynamische IPs, die sich auf den Blacklists finden. Da Spam in der Regel auf dem Port 25 eingeliefert wird, beschränke ich den RBL-Check auf diesen Port. Auf dem SSL-Port (SMTPS) findet kein RBL-Check statt und meine User wissen das. Zusätzlich kennt Plesk ab der aktuellen Version unter Server->Mail->"Enable message submission" auch die Möglichkeit, den Port 587 für das Einliefern von Mails zu nutzen.

Hallo,

eine interessante Diskussion, denn ich stehe auch vor solch einem ähnlichen Problem. Nutze Plesk in der Version 8.3.0 und habe mit massivem SPAM-Eingang zu kämpfen. Ein offenes Relay ist mein Server nicht. Ich habe auch versucht mit dem Spamschutz auf Basis der DNS-Blackhole-Listen zu arbeiten. Z.B. mit sbl.spamhaus.org. Hier musste ich, wie oben richtig erwähnt, feststellen, dass diese Blocklisten auch dynamische IPs diverser ISP, Netcologne, Telekom etc. pp. enthalten und es somit Nutzern eines Netcologne-Internetzugangs nicht möglich war meinem Server E-Mails zukommen zu lassen - sehr ärgerlich. Zu diesem Thema habe ich auch schon Netcologne bemüht, warum denn ihre Ranges gelistet werden, aber hier stieß ich auf taube Ohren und die Worte "Da können wir nichts tun".

Nun habe ich mich mit dem kleinen Feld "Nachrichtenübermittlung aktivieren" außeinander gesetzt und dachte, dass wäre die Lösung meines Problems.
Fix die Nachrichtenübermittlung aktiviert und versucht eine E-Mail zu verschicken, über SMTP Port 25 und es funktioniert -> ich hatte es so verstanden, dass es nun nicht mehr möglich sein sollte?

Des Weiteren erhielt ich von meinem System foglende Fehlermeldung:

OSSEC HIDS Notification.
2008 Apr 28 12:54:35

Received From: SERVER->/var/log/syslog
Rule: 1002 fired (level 2) -> "Unknown problem somewhere in the system."
Portion of the log(s):

Apr 28 12:54:34 SERVER xinetd[16238]: inetd.conf - Bad value for wait: nowait/1000 [file=/etc/inetd.conf] [line=3]

--END OF NOTIFICATION

OSSEC HIDS Notification.
2008 Apr 28 12:54:35

Received From: SERVER->/var/log/syslog
Rule: 1002 fired (level 2) -> "Unknown problem somewhere in the system."
Portion of the log(s):

Apr 28 12:54:34 SERVER xinetd[16238]: inetd.conf - Bad value for wait: nowait.1000 [file=/etc/inetd.conf] [line=5]

Wüsste evtl. jemand bescheid warum, wieso, weshalb?

Danke!