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

[Peer Heinlein]

Am Samstag, 26. Januar 2008 schrieb Christian Roessner:

> > Das ist keine gute Idee.
>
> Diese Idee habe ich realisiert und es läuft!

Ja, natürlich läuft es. Aber die Frage ist, ob es nicht auch bequemer und 
luxuriöser geht. :-)

> > 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.

Sorry, ich wollte keinesfalls behaupten, Du hättest nicht überlegt. Aber 
wenn man alle Abhängigkeiten und Eventualitäten durchdenkt, so wird man 
vielleicht auf Gründe stoßen, warum man mynetworks nicht pauschal 
freischalten sollte.


> 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").

Ich glaube nicht, daß vier Restrictions-Positionen früher oder später 
soviel Zeit sparen, daß Du 75% Deiner Resourcen freibekommst. Die 
unterschiedliche Positionierung in den Restrictions wird über 100.000 
E-Mails vermutlich so gut wie nicht meßbar sein (kann ja mal messen).

> 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.

Okay, dann mag das in diesem Fall irrelevant sein. Punkt für Dich.

Aaaaaaaaaaber: Ich finde es sehr erstrebenswert, wenn eine 
Restriction-Konfiguration so gebaut ist, daß sie ganz einfach auf allen 
Rechnern und allen Anwendungszwecken funktioniert. Man muß sie sich weder 
im Einzelfall ausdenken, noch jedes mal umbauen. Es gibt eh eine nahezu 
zwingende Abfolge, wenn man optimal alles abdecken will.

Ich finde es nur immer etwas gefährlich, wenn solche Configs die auf 
Besonderheiten basieren, dann so kommentarlos veröffentlich werden. 
Andere nutzen das anders, übernehmen sowas per Cut & Paste und holen sich 
dann Probleme ins Haus -- die Du so ggf. nie hattest, wenn Du mynetworks 
de facto nicht benutzt. Okay, könnte Dir egal sein. Aber andererseits 
stellt sich eben doch die Frage: warum nicht gleich generisch so machen, 
daß es immer für alle geht? Warum nicht so machen, daß auch Du es ggf., 
einfach so für andere Zwecke übernehmen kannst? Man wächst und verändert 
sich ja auch in den Aufgaben.

> > 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.

Nimmst Du gar keine Mails von außen an?! Also von anderen Mailservern?

Wenn nein: Dann kannst Du Dir viel der Restrictions sparen.

Wenn ja: Eben. Dann solltest du die auch beherrschen und blocken können!

> >>          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?

Nochmal zum nachfassen: Ich finde diese Punkte sehr wichtig. Für mich 
müssen/sollten sie auf jeden Fall über dem permit für die eigenen Nutzer 
stehen.

> >>          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

Trotzdem. Oder gerade darum ja. Du beschützt Deine Nutzer durch diese 
Konstellation nicht vor ihren Fehler. Warum?

Und: reject_unverified_recipients vor Deinen tls-authentifizierten Mails? 
Das würde bedeuten, daß Postfix susi at web.de verifizieren muß, bevor du 
versenden darfst. 


> :-) 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.

Ja -- trotzdem!

Warum überhaupt Fehlermöglichkeiten einbauen?

Ziehe das doch einfach sauber zusammen. Es hat KEINE Nachteile und NUR 
Vorteile. Warum also nicht?

> >>          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?

Nein, über die richtige Reihenfolge in den Restricitions.

Ich glaube, ich habe da vor einigen Wochen mal einen längeren 
grundsätzlichen Artikel zur optimalen Restriction hier dazu geschrieben. 
ich schau mal, ob ich den gleich noch wiederfinde, dann muß ich nicht 
alles neu tippen. :-)

> 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.

Jau, lokale Dateien sind aus Sicht der Stabilität und Performance immer 
besser. Wenn man auf Echtzeit-Daten verzichten kann, sind lokale Dateien 
das Mittel der Wahl.

> 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.

Sorry, Entschuldigung. Ich wollte dir damit nicht auf die Füße treten, ich 
akzeptiere gerne, daß ich hier offensichtlich zu brachial reingegangen 
bin. Sorry -- ich erkläre das leider zweimal am Tag irgendwem, da wird 
man irgendwann "hart" in seinen Antworten, gerade wenn man das im Akkord 
alles abarbeitet -- und ich gelobe hiermit Besserung. Auf die Füße treten 
wollte ich Dir keinesfalls, das tut mir ernsthaft leid und war nicht so 
gemeint.

Lieben Gruß

Peer


-- 
Heinlein Professional Linux Support GmbH
Linux: Akademie - Support - Hosting

http://www.heinlein-support.de

*** Secure Linux Administration Conference
*** 6. + 7.12.2007 http://www.heinlein-support.de/slac