Sendmail kann von jeder Adresse/Domain Emails verschicken

[NeWsOfTzzz]

Ich hab jetzt schön viel Zeit investiert um meinen Mailserver (Postfix) komplett SSL tauglich zu machen und für mehrere Domains sowie mehrere User einzurichten. Dann habe ich gemerkt, dass man von jeder Adresse Emails verschicken konnte, das habe ich mit
smtpd_sender_restrictions = reject_sender_login_mismatch
und
smtpd_sender_login_maps = mysql:/etc/postfix/vms-email2email.cf
wirksam unterbunden.

Jetzt habe ich aber ein ganz anderes Problem, nämlich mit PHP mail() (welches ja Sendmail benutzt) kann ich immer noch von jeder Domain und jeder Email Adresse Emails verschicken. Mit Google hab ich leider nix gefunden und auch ein paar Versuche in der config, wie das entfernen von "permit_mynetworks" wie das entfernen aller "mynetworks" hat nichts gebracht, offensichtlich arbeitet sendmail da komplett ohne SMTP?

Welche Optionen habe ich nun? Die Funktion "mail" möchte ich nicht unbedingt deaktivieren in PHP. Kann ich vllt irgendwie in der php.ini festlegen, welche Email Adresse ein User nur benutzen darf (ist alles mit CGI und seperaten php.ini eingerichtet pro User). Oder noch besser, kann ich nicht irgendwie bestimmen, dass Sendmail auch nur per Authentifizierung funktioniert?

Völlig abgesehen von PHP: Was ist denn, wenn irgendein Hacker Zugriff auf irgendeinen normalen Systemuser mit Shell kriegt, kann er dann via Sendmail massivst Spam verschicken und dann auch noch mit jeder Adresse die er will?

 

[elias5000]

Das lokale Senden von Mail ist für den Betrieb des Systems wichtig, da viele Vorgänge Mails auslösen (z.B. Cronjobs, Monitoring von Dateisystemen und RAIDs u.s.w.).
Es lässt sich also nicht einfach so abstellen. Also lassen täte es sich sich schon - aber sonderlich sinnvoll wäre das nicht.

mail() zu deaktivieren reicht nicht ganz. Es muss dann auch die Ausführung von sendmail als Shell-Aufruf verboten werden, da man darüber auch Mails verschicken kann.

Den angezeigten Absender kann auch jedes Programm selber bestimmen, da dieser Teil des Inhalts der Mail ist. Ggf. könnte man einen erzwungenen Adress-Rewrite machen.

Gegen den Missbrauch des lokalen Versendens von Mails hilft übrigens am besten, sich den Server nicht hacken zu lassen.

Und gegen den Missbrauch der mail()-Funktion hilft es, keine wurstig programmierten Scripts auf dem Server zu installieren.


Was genau ist eigentlich dein Problem mit dem lokalen Versand von Mails?

 

[NeWsOfTzzz]

Gegen den Missbrauch des lokalen Versendens von Mails hilft übrigens am besten, sich den Server nicht hacken zu lassen.

Jo, sicher.

Den angezeigten Absender kann auch jedes Programm selber bestimmen, da dieser Teil des Inhalts der Mail ist.

Nicht ganz, mit den oben genannten Optionen kann schon kein normaler Email User mehr die Absenderadresse bestimmen, also jeder der sein Email Postfach per Mailclient wie Thunderbird benutzt kann es nicht mehr.

mail() zu deaktivieren reicht nicht ganz. Es muss dann auch die Ausführung von sendmail als Shell-Aufruf verboten werden, da man darüber auch Mails verschicken kann.

[...]

Und gegen den Missbrauch der mail()-Funktion hilft es, keine wurstig programmierten Scripts auf dem Server zu installieren.

Naja, es geht ja gar nicht um mich, sondern ich hoste jetzt auch für "Kunden" Webseiten, da habe ich sowieso shell_exec und den ganzen Kram deaktiviert.

Aber ich muss ja theoretisch sogar davon ausgehen, dass einer dieser "Kunden" böswillig eine andere FROM Adresse in sein Script einträgt, was dann?

Das muss man doch irgendwie verhindern können, ich kann ja in der php.ini den Pfad zu sendmail angeben dabei aber auch Parameter angeben..

 

[elias5000]

Die SMTPd-Restrictions helfen nicht gegen lokal versandte Mails, weil diese ja gerade nicht per SMTP eingeliefert werden.

Du könntest einen Wrapper um sendmail schreiben, der die angegebene Adresse checkt und ggf. einen Fehler schmeißt und diesen dann per php.ini als sendmail-Command eintragen.

Das ist allerdings nicht ganz unproblematisch. Was, wenn man auf der Kiste einen Dienst fahren will, der z.B. von einer Comunity-Seite Mails verschickt, die als Absender die Adresse eines angemeldeten Users trägt. Ein durchaus legitimes Anliegen - mit deiner Restriktion aber nicht umsetzbar.

Man kann nicht alles verhindern, wenn Menschen im Spiel sind. Und man sollte nicht immer davon ausgehen, dass alle immer Unrechtes tun wollen. Bis zu einem gewissen Grad ist das ok, aber irgendwo muss man eine Grenze ziehen oder der Sicherheitsapparat wird ein Monster, das nicht mehr beherrschbar ist.
Du könntest einen Passus gegen Missbrauch in die Nutzungsbedingungen aufnehmen mit der Möglichkeit, bei Verstoß z.B. den Vertrag einseitig zu beenden.

 

[NeWsOfTzzz]

Das ist allerdings nicht ganz unproblematisch. Was, wenn man auf der Kiste einen Dienst fahren will, der z.B. von einer Comunity-Seite Mails verschickt, die als Absender die Adresse eines angemeldeten Users trägt. Ein durchaus legitimes Anliegen - mit deiner Restriktion aber nicht umsetzbar.

Das landet bei GMX z.b. direkt im Spamfilter weil dann die FROM Adresse nicht mit dem SPF Eintrag übereinstimmt, ist also weder legitim noch standardkonform :/
Zusätzlich habe ich ein Thunderbird Addon womit ich die SPFs überprüfe..

Wenn jetzt aber einer mit PHP eine von meinen Domains angibt, dann bringt der SPF nix mehr, da selbe IP Adresse.

 

[elias5000]

Du vermischst den Absender im Envelope und Header.

SPF prüft den Absender im Envelope. Der dem Empfänger angezeigte Absender steht jedoch im Header. Die Header werden von SPF nicht geprüft.

Mein Szenario ist also sehr wohl mit SPF konform. Mit EMail nach RFC2822 sowieso.

 

[NeWsOfTzzz]

Du vermischst den Absender im Envelope und Header.

Nicht wirklich, da der "Kunde" sowohl den FROM setzen kann sowie den Envelope mit '-f<email@domain.de>'

Mein Szenario ist also sehr wohl mit SPF konform. Mit EMail nach RFC2822 sowieso.

Okay, das kann sein, vielleicht hab ich da Mist erzählt mit den SPF Standards.

ABER

SPF prüft den Absender im Envelope. Der dem Empfänger angezeigte Absender steht jedoch im Header. Die Header werden von SPF nicht geprüft.

Das stimmt mit meinem Addon nicht, ich habe das mal durchgetestet mit einer SPF geschützten Domain als FROM und meinen Email Server als Envelope. Dann zeigt mein Thunderbird Addon folgendes an:

Sender Verification: "From" domain unverified. Envelope domain <otserv.de> confirmed.

Siehe Dateianhang...


PS: Ich habe rausgefunden, dass ich in PHP genau diesen Envelope unterdrücken kann, indem ich alle zusätzlichen Parameter in Mail überschreibe in der php.ini...
Bringt mir aber nix, weil der FROM dann immer noch stimmt und nicht per SPF geprüft werden kann. Also habe ich erstmal mail() deaktiviert, sollen die "Kunden" halt mit SMTP arbeiten (Joomla unterstützt das z.B. von Haus aus).



.

 

[elias5000]

Anhand dieser Informationen soll nach RFC 4408 der Empfangs-Server dann sowohl die "MAIL FROM"-Identität als auch die "HELO"-Identität des Senders nachprüfen. Absenderangaben im E-Mail-Header werden nicht überprüft.

Das liest sich für mich recht eindeutig. In der RFC hab ich noch nicht nachgesehen.

Trotzdem bleibt für mich das angeben einer beliebigen Absender-Adresse ein legitimes Anliegen einer Applikation und ich würde ein Hosting-Angebot, welches dies nicht unterstützt meiden.
Meine Meinung dazu ist, dass man es auch übertreiben kann. Es ist nun mal Fakt, dass man den Absendern von Mails nicht vertrauen kann. Das ist keine neue Erkenntnis sondern das war schon immer so.

Edit: Ich habe die RFC mal überflogen und vom From-Header steht da nichts. Es wird sogar explizit darauf hingewiesen, dass über den From-Header trotzdem User getäuscht werden können.

Unless the user or the MUA takes care to note that the authorized identity does not match the other more commonly-presented identities (such as the From: header field), the user may be lulled into a false sense of security.

Edit2: "unverified" bedeutet übersetzt btw "ungeprüft". Es bedeutet _nicht_ "prüfung nicht bestanden".

 

[NeWsOfTzzz]

Edit2: "unverified" bedeutet übersetzt btw "ungeprüft". Es bedeutet _nicht_ "prüfung nicht bestanden".

Richtig, weil das ja offensichtlich nach Standards nicht wirklich "nicht bestanden" sein kann.

Du sagst man kann dem Absender nicht trauen? Kann man jetzt schon. Mit SPF und dem Tool kann man sehen ob die Email von meinem Server kommt, sonst steht da unverified. Bei unverified sollte man nämlich nochmal manuell in den Header schauen. Und wenn sie von meinem Server kommt dann stimmt auch die FROM Angabe, weil ich das eben bei SMTP überprüfe und via Sendmail nicht mehr erlaube

Also ich finde das nicht übertrieben, weil auf die Art und Weise jemand bei Emails von meinem Server sicher sein kann, dass die From Angabe auch stimmt. Übrigens schreibe ich Kunden immer in Anführungszeichen weil das für Bekannte und unkommerziell ist, daher muss ich nicht auf mich meidende Leute achten

 

[elias5000]

Also ich finde das nicht übertrieben, ... für Bekannte ... muss ich nicht auf mich meidende Leute achten

Aha. Bekannt. Nicht übertrieben. Soso.
Ich lass das jetzt mal unkommentiert...

Edit: Doch - ich muss das kommentieren: Den Blick für das Wesentliche muss der Admin eine Servers auch haben.
Du kannst die Zeit, die du gegen Absender-Fälschung durch deine Bekanten aufwendest, garantiert viel besser in wesentlichere Aspekte der Absicherung deiner Kiste investieren.

 

[NeWsOfTzzz]

Aha. Bekannt. Nicht übertrieben. Ich lass das jetzt mal unkommentiert...

Ich glaube du verstehst das Problem nicht. Ich glaube nicht, dass der Bekannte was macht, sondern eher eine Sicherheitslücke in seinem Joomla und den 50.000 Erweiterungen (meist von Anfängern programmiert), die eingebunden werden.

Der andere Bereich des Servers, den ich nutze, ist quasi ein Hochsicherheitsbereich mit gut geschützten Daten und da möchte ich nicht dass jemand über dieses Joomla Emails in meinem Namen verschicken kann.

 

[elias5000]

Bring deinen Bekannten doch bei, sichere Software zu erkennen und unsichere zu meiden. Die Zeit ist besser investiert. Und alle haben was davon.

 

[NeWsOfTzzz]

Bring deinen Bekannten doch bei, sichere Software zu erkennen und unsichere zu meiden. Die Zeit ist besser investiert. Und alle haben was davon.

Zwecklos, besteht auf Joomla und Erweiterungen

Habe mail() jetzt deaktiviert, in vielen Sachen (Joomla selbst, phpBB) kann man SMTP einstellen, für den Rest (falls es einen gibt) habe ich angeboten das ebend umzuprogrammieren von mail() auf Mailversand via SMTP.