[Postfixbuch-users] MySQL und Restriction für gefälschtes EHLO

[Christian Roessner]

Hallo Peer,

> Das ist keine gute Idee.

Diese Idee habe ich realisiert und es läuft!

> 
> Und es kann -wenn  man alles durchdenkt und für alles vorbereitet sein 
> will- auch nicht funktionieren. Wirklich nicht. Kann nicht.

So, meine Systeme zeigen, dass es mit Überlegungen geht.

> Spätestens wenn man prüft, ob die Absender- oder Empfänger-Domain 
> überhaupt existiert, hat man remote-Abfragen im Spiel. Schon dieses 
> kleine Beispiel zeigt, daß diese Trennung nicht funktionieren KANN.

Ich weiß nicht, ob Du Dir mal den Mailgraphen angeschaut hast. Bei 
3-400000 REJECTS pro Tag pro Frontend macht eine solche Krümelstruktur 
aber absolut Sinn.

> Und: Sie macht auch keinerlei Sinn. Man spart nichts.

Und ob: Nu noch ca. 25-30 smtpd-Prozesse anstelle von bis zu über 100 
dauerhaft geöffneten (watch -n1 "ps auxc | grep smtpd | wc -l").

> Im Gegenteil: Eine unsinnig angenommene E-Mail kostet mehr als 500 
> DNS-Abfragen. Also nicht versuchen hier irgendein Krümel-Peanut zu 
> sparen, sondern robust, stabil udn vorbereitet sein, damit einen nichts 
> erschüttern kann und man jedes Verhalten per Knopfdruck realisiert kriegt 
> ohne daß Restrictions im Notfall umgebaut werden müssen.
> 
>> smtpd_recipient_restrictions =
>>          permit_mynetworks
> 
> Da geht's ja schon los. Sowas liebe ich ja. Zuerst mal "permit_mynetworks" 
> reinknallen.  Nicht gut.

Und ich liebe Kritik, wenn man überhaupt keine Kenntnisse des 
Einsatzgebietes dieser Server hat. Die Server arbeiten komplett mit 
virtuellen Domains. Ich könnte im Grunde auch vollständig auf 
permit_mynetworks verzichten. Weil ich aber gerne cron und 
uucp-Nachrichten lesen will, steht das eben genau so da drin.

> Warum nimmst Du von Deinen eigenen Nutzern Mails an, die
> -eine nicht-existente Empfänger-Domain haben. Hilfst Du ihnen damit? Nein.
> -eine nicht-existente Absender-Domain haben. Hilfst Du ihnen damit? Nein.
> 
> Wie sperrst Du einen einzelnen Amoklaufenden Nutzer anhand
> -Absender-Mailadresse, Client-IP und/oder HELO?
> 
> Kannst Du nicht. Weil die checks dazu erst nach permit_mynetworks stehen. 
> Gefährlich und nicht hilfreich! Falsche Reihenfolge!

Virtuelle Umgebung. Die User laufen alle über permit_sasl_authenticated.

>>          reject_non_fqdn_recipient
>>          reject_non_fqdn_sender
>>          reject_unknown_recipient_domain
>>          reject_unknown_sender_domain
> 
> Da stehen sie ja. Aber warum gelten sie nicht für Deine eigenen Nutzer?
> 
>>          reject_unverified_recipient
>>          reject_unlisted_recipient
>>          permit_tls_clientcerts
> 
> Warum machst Du einen Unterschied, ob Nutzer A auf seinem Laptop ein 
> Zertifikat hat, oder ob er nur mit der IP-Adresse ankommt?

permit_tls_clientcerts haben nur privilegierte Admins (also ich). Scherz 
:-) Ich verwende x509 Zertifikate, um ohne Benutzernamen und Passwort 
Mails verschicken zu können. Hat hauptsächlich Test-Charakter. Kein 
anderer Benutzer hat ein Client-Cert.

> Ist er in mynetworks darf er Unsinn versenden, ist er mit ein- und 
> demselben Laptop draußen vor Ort beim Kunden darf er es nicht mehr. Macht 
> keinen Sinn.

Dazu brauche ich nichts weiter sagen, oder?

>>          reject_unauthenticated_sender_login_mismatch
>>          reject_sender_login_mismatch
>>          permit_sasl_authenticated
> 
> Auch hier. Ist er in mynetworks darf er Unsinn senden, kommt er per 
> Username daher gelten plötzlich ganz andere Regeln, obwohl User, sein 
> Laptop und seine Konfiguration sich nicht verändert haben.

siehe oben

>>          reject_unauth_destination
>>          check_client_access pcre:/etc/postfix/maps/dynip.pcre
> 
> Vorsicht. Es ist zurecht *SEHR* umstritten um das pauschale Blocken 
> dynamischer IP-Adressen eine gute Idee ist. Kannst Du machen, wenn Du 
> willst, aber es gibt auch gute Gründe dagegen.

Stimme ich komplett überein. Allerdings unterliegt _diese_ dynip.pcre 
genauer Kontrolle und ist nicht ein Copy&Paste Werk ;-)

>>          reject_unknown_helo_hostname
> 
> Damit wirst Du mehr echte E-Mails von schlecht konfigurierten Mailservern 
> verlieren, als daß es Dir Spam vom Hals hängt. Definitiv nicht 
> empfehlenswert und einfach auch sinnfrei. Es schützt nicht, es schadet 
> nur.
> 
>>          check_policy_service unix:private/policyd-spf
> 
> Vor dem Einsatz von SPF kann ich nur warnen. Das System funktioniert nicht 
> und sorgt wenn man es auch zum Blocken einsetzt für Mailverluste 
> (Stichwort: Weiterleitungen, Mailinglisten).

Da danke ich Dir. Das Thema Weiterleitungen hatte ich nicht 
berücksichtigt. Ist wieder draußen. Ich fand nur die grundsätzliche Idee 
prima. Schade, dass es da keine gute Lösung gibt.

>>          check_policy_service inet:127.0.0.1:12525
> 
> Angenommen es gibt einen Dir wichtigen Client, den Du vom Policyd-Weight 
> ausnehmen willst. Wie richtest Du ein whitelisting ein? Das sieht Deine 
> Config nicht vor. Also schneidest Du Dir ohne Notwendigkeit Deine 
> Handlungsmöglichkeiten ab.

Das ist ein gutes Argument. Wie könnte ich das etwas dynamischer 
konfigurieren? Über FILTER in einer extra Datei?

>>          reject_rhsbl_sender dsn.rfc-ignorant.org

Ich betrachte hier den besonderen Charakter dieser RHSBL. Klar ist das 
hart, aber ich denke, wer dort hinein gekommen ist, hat auch kein Recht 
auf Beschwerde, wenn Mails von ihm abgelehnt werden. Aber ich 
akzeptiere, dass das Ansichtssache ist.

> 
> Du hast doch den Policyd-Weight. Der macht das mit mehr Sinn und Verstand, 
> als wenn man das hier hart auswerten läßt. 

Bei allen anderen RBLs, etc. würde ich auch genau das machen.

Was mein Thema angeht: Ich habe heute ca. 10 Stunden dran gesessen und 
mir ein Skript gebaut, was mir Flat-Files aus der MySQL-DB erzeugt. Hat 
auch den Vorteil, dass ich a) den MySQL-Server stark entlaste und b) 
einen Single-Point-of-Failure weniger habe.

Eine Bitte habe ich: Ich habe viele etliche Stunden daran gesessen, 
dieses Setup so aufzubauen. Ich finde es persönlich nicht sehr angenehm, 
wenn ohne weiteren Dialog meine Gedanken vollends in Frage gestellt werden.

Trotzdem vielen herzlichen Dank

Gruß
Christian

-- 
Roessner Network Solutions (R.N.S.)

Licher Str. 19a
35394 Gießen

USt-IdNr.: DE225643613

Fon: +49 641 2097252
Fax: +49 641 2097253
Mobil: +49 171 3611230

URL: http://www.roessner-net.com/
PGP: http://www.roessner-net.com/0x6B929997.asc

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 252 bytes
Beschreibung: OpenPGP digital signature
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20080126/2a350920/attachment.asc>