Mailversand pro User begrenzen

samy-delux

New Member
Hallo Leute,

Ich würde gerne wissen, ob es die Möglichkeit gibt, in sendmail (oder qmail, postfix, exim etc. alles mit sendmail wrapper) jeden Benutzer nur eine bestimmte Anzahl von Mails am Tag senden zu lassen?

Auf dem Debian System gibt es ca. 100 Benutzer die alle normale Benutzerrechte haben, also auf das Mailprogramm zugreifen können. Es sollte doch zunächst einmal Möglich sein, die Benutzer zu unterscheiden, denn sie rufen ja sendmail über ihren eigenen Benutzeraccount auf.

Kann ich jetzt auch sagen, dass jeder Benutzer nur 100 Mails am Tag versenden darf?
Ist das mit qmail, postfix oder exim möglich?

Vielen Dank für eure Hilfe!

so long,
Samy
 
Ich bin mir sicher das man Exim sowas beibringen kann(zumindest kann Exim die Benutzer unterscheiden und SQL Datenbanken abfragen;)), aber wie willst du verhindern das die User ein eigenes E-Mail Programm installieren?
[edit]Sowas gibt's sogar schon fertig 40.*Access control lists , aber mein obiger Einwand bleibt gültig...
Code:
# Keep authenticated users under control
deny authenticated = *
     ratelimit = 100 / 1d / strict / $authenticated_id
[/edit]
 
Last edited by a moderator:
Naja, ich war nicht ganz so genau, damit mir auch jemand antwortet und das Thema nicht als zu komplex abtut.
Die User haben eigentlich nur PHP Zugriff. Doch der PHP Interpreter läuft mit ihren Userrechten....

Exim soll dann als sendmail Alternative fungieren die über die mail()-Funktion von PHP aufgerufen wird!
Oder übersehe ich jetzt etwas und das funktioniert so gar nicht wie ich mir das vorstelle??

Danke schonmal für die Hilfe!
Werde mir das mal genauer anschauen!!!
 
Last edited by a moderator:
Naja, ich war nicht ganz so genau, damit mir auch jemand antwortet und das Thema nicht als zu komplex abtut.
Das Thema ist nicht wirklich komplex und es würde deutlich weniger Spam geben wenn mehr Leute mit solchen Methoden verhindern würden das gehackte PHP Skripte hunderttausende Mails rausjagen.
Die User haben eigentlich nur PHP Zugriff. Doch der PHP Interpreter läuft mit ihren Userrechten....
Um den Usern die Möglichkeit zu nehmen mail() zu umgehen mußt du alle php-Funktionen die exteren Programme aufrufen oder verbindung ins Internet aufnehmen deaktiveren, z.b. exec() und fsockopen(). Weil ich vermutlich diverse Wissenslücken bei PHP habe kann ich dir keine vollständige Funktionsliste geben, dafür gibt's bestimmt genügend Andere hier im Forum die mehr Wissen in dem Bereich haben.

Wenn du eine richtig flexible Lösung haben willst kannst du dir einen eigenen Wrapper für Mails schreiben, irgendwo in der php.ini steht was für ein Programm bei mail() aufgerufen wird und das kann man dann leicht umbiegen :) Dann mußt du zwar dennoch die mißbrauchbaren php Funktionen deaktivieren aber du kannst beliebige Mailprogramme verwenden. Hatten wir auch schon mal hier im Forum ;)
 
Last edited by a moderator:
Um den Usern die Möglichkeit zu nehmen mail() zu umgehen mußt du alle php-Funktionen die exteren Programme aufrufen oder verbindung ins Internet aufnehmen deaktiveren, z.b. exec() und fsockopen().

Apache läuft chrooted und mit jeweils verschiedenen Nutzerrechten.
Sollte doch reichen, oder?
Es handelt sich auch im übrigen um ein Freehosting Angebot. Die User können also eh ihre eigenen Skripte hochladen!

Wenn du eine richtig flexible Lösung haben willst kannst du dir einen eigenen Wrapper für Mails schreiben, irgendwo in der php.ini steht was für ein Programm bei mail() aufgerufen wird und das kann man dann leicht umbiegen :) Dann mußt du zwar dennoch die mißbrauchbaren php Funktionen deaktivieren aber du kannst beliebige Mailprogramme verwenden. Hatten wir auch schon mal hier im Forum ;)

Das wäre natürlich das beste!
Ein Python Programm was eben die Mail-Raten entsprechend verwaltet ist ja nicht schwer zu schreiben. Ich bräuchte nur ein paar anhaltspunkte, wie ich die Argumente die ich von PHP bekomme auch richtig an sendmail weiterleite... Ich werds erstmal einfach ausprobieren ;)

Durch eine eigenen Lösung könnte ich dann auch den Usern im Kontrollcenter bescheid geben, wenn sie zu viele Mails versenden.

so long,
Samy
 
Apache läuft chrooted und mit jeweils verschiedenen Nutzerrechten.
Sollte doch reichen, oder?
IMHO reicht das in den meisten Fällen nicht, überleg dir mal was passiert wenn ein User sowas benutzt: PHP: fsockopen - Manual. Und den Wrapper kann man umgehen wenn man mit exec() das echte Mailprogramm direkt aufruft.
Es handelt sich auch im übrigen um ein Freehosting Angebot. Die User können also eh ihre eigenen Skripte hochladen!
Klar, aber du kannst dennoch gezielt einzelne php Funktionen per php.ini/disable_functions deaktivieren, siehe PHP: Safe Mode - Manual
 
Hallo!

@ samy-delux

Ergänzend zum Thema PHP Absicherung / disable_functions könnte dieser Thread interessant sein.

Gruß flyingoffice
 
IMHO reicht das in den meisten Fällen nicht, überleg dir mal was passiert wenn ein User sowas benutzt: PHP: fsockopen - Manual. Und den Wrapper kann man umgehen wenn man mit exec() das echte Mailprogramm direkt aufruft.

Er kann das System Mailprogramm ja nicht aufrufen, da er im chroot gefangen ist und nur auf seine eigenen Dateien Zugriff hat!
Man kann dann zwar selbst Programme hochladen, diese aber nicht ausführen, falls die Partition mit noexec Mounte...

Klar, aber du kannst dennoch gezielt einzelne php Funktionen per php.ini/disable_functions deaktivieren, siehe PHP: Safe Mode - Manual

Ich würde gerne eine Systembasiert Sicherung durchführen, da der Safe Mode von PHP IMHO richtiger Rotz ist... Außerdem wollen wir auch andere Programmiersprachen später erlauben, die keine internen Absicherungen haben!

so long,
Samy
 
Er kann das System Mailprogramm ja nicht aufrufen, da er im chroot gefangen ist und nur auf seine eigenen Dateien Zugriff hat!
Und wie soll dann dein Wrapper(der notwendigerweise im gleichen chroot ist) das System Mailprogramm aufrufen?

Ich würde gerne eine Systembasiert Sicherung durchführen, da der Safe Mode von PHP IMHO richtiger Rotz ist...
Das disable_functions Zeug hat soweit ich weiß nicht direkt was mit Safe Mode zu tun(auch wenn es auf der gleichen HTML Seite dokumentiert ist:() und wird auch in PHP 6.0 vorhanden sein, zumindest ist es noch in der aktuellen CVS Version von PHP 6.0. Die Implementierung einer disable_functions Funktion ist so einfach das es sehr unwarscheinlich ist das die PHP Entwickler da Lücken übersehen haben. Zumindest als zusätzliche Hürde ist das empfehlenswert.

Außerdem wollen wir auch andere Programmiersprachen später erlauben, die keine internen Absicherungen haben!
Bei den meisten anderen Programmiersprachen wirst du Probleme haben wenn du die Partition mit noexec mountest ;) SCNR

Es gibt diverse allgemeine Lösungen z.b. iptables mit owner Modul, diverse Virtualisierungslösungen (was bei freehosting vermutlich zu aufwendig ist) oder die Möglichkeit den Usern sämtlichen Netzwerkverkehr zu verbieten und die notwendige/erlaubte Komunikation über Unix Sockets laufen zu lassen. Bevor wir noch mehr aneinander vorbeireden wäre es IMHO ganz gut wenn du mal deine gesammte bisherige Planung postest (ganz nebenbei verstehe ich nicht warum du den ganzen Apache und nicht nur fcgid chrootest)
 
Und wie soll dann dein Wrapper(der notwendigerweise im gleichen chroot ist) das System Mailprogramm aufrufen?

Ich werden den Wrapper per Hardlink, im chroot verfügbar machen. Da man ja Hardlinks folgen kann, die aus dem chroot herausgehen, sollte man den Wrapper erreichen können, jedoch nicht das Mailprogramm an sich, oder??

Das disable_functions Zeug hat soweit ich weiß nicht direkt was mit Safe Mode zu tun(auch wenn es auf der gleichen HTML Seite dokumentiert ist:() und wird auch in PHP 6.0 vorhanden sein, zumindest ist es noch in der aktuellen CVS Version von PHP 6.0. Die Implementierung einer disable_functions Funktion ist so einfach das es sehr unwarscheinlich ist das die PHP Entwickler da Lücken übersehen haben. Zumindest als zusätzliche Hürde ist das empfehlenswert.

Wie gesagt, ich würde es gerne gar nicht erst benutzen, da andere Programmiersprachen das nicht unterstützen und ich nach und nach auch noch andere Programmiersprachen erlauben will!

Bei den meisten anderen Programmiersprachen wirst du Probleme haben wenn du die Partition mit noexec mountest ;) SCNR

Mit mod_security chroot sollte das doch gehen. Da Apache und alle Module erst geladen werden und dannach erst gechrooted wird. Dann muss man nur die benötigten externen Programm, wie sendmail für PHP, im chroot vorhanden haben.
ModSecurity - Apache chrooting made simple

Es gibt diverse allgemeine Lösungen z.b. iptables mit owner Modul, diverse Virtualisierungslösungen (was bei freehosting vermutlich zu aufwendig ist) oder die Möglichkeit den Usern sämtlichen Netzwerkverkehr zu verbieten und die notwendige/erlaubte Komunikation über Unix Sockets laufen zu lassen. Bevor wir noch mehr aneinander vorbeireden wäre es IMHO ganz gut wenn du mal deine gesammte bisherige Planung postest (ganz nebenbei verstehe ich nicht warum du den ganzen Apache und nicht nur fcgid chrootest)

Wie ich ja schon sagte, hab ich im ersten Post ein paar Sachen verschwiegen, damit mir überhaupt jemand antwortet ;)
Es handelt sich um eine Freehosting Community mit (zur Zeit) 13.000 Benutzern. Diese laufen auf 4 Servern und wir konzipieren geraden die neue Struktur. Ich bin erst seit 3 Wochen Serveradmin und merke dass ich einen richtigen Flickenteppich vor mir habe und am besten alles neu mache auf neuen und besseren Servern!

Zum FastCGI (fcgi): Bei 3000 bis 4000 Benutzern pro Server, brauchen ebensoviele FastCGI Prozesse ordentlich Arbeitsspeicher... Viel zu Viel um rentabel zu bleiben.
Deshalb werde ich das MPM ITK einsetzen!

so long,
Samy
 
Ich werden den Wrapper per Hardlink, im chroot verfügbar machen. Da man ja Hardlinks folgen kann, die aus dem chroot herausgehen, sollte man den Wrapper erreichen können, jedoch nicht das Mailprogramm an sich, oder??

Ich antworte mir mal selbst: Nein! Der Wrapper würde das Mailprogramm nicht finden, da es ja außerhalb des chroot ist und ein Hardlink ja anders Funktioniert als ein Symlink!

Aber ich habe eine neue Idee:
Ich packe sendmail in das chroot und mache es aber nur für www-data schreib/ausführbar. Den Wrapper gebe ich mit chown auch nur an www-data, gebe ihm jedoch das setuid-bit mit...
So kann man sendmail dann nur über den Wrapper erreichen!!

Und ich nehm nur für die den Unterordner /var/www/users die Partition die mit noexec gemountet ist...

so long,
Samy
 
Ich antworte mir mal selbst: Nein!
Spielverderber :D
Den Wrapper gebe ich mit chown auch nur an www-data, gebe ihm jedoch das setuid-bit mit...
Das setuid-bit funktioniert bei Scripten (also alles was mit #! anfängt) nicht (ist ein Sicherheitsfeature), wenn du das so machen willst muß den Wrapper ein direkt ausführbares Programm sein (für viele Skriptsprachen gibt es ja netterweise Compiler :))

Wenn dein Sicherheitskonzept auf chroot und das experimentelle MPM ITK bassiert wirst du doch vermutlich auch den grsecurity Kernel Patch einsetzten? Damit sollte man den Usern auch den Netzwerkzugriff nehmen können (wobei das wieder nur auf Halbwissen meinerseits bassiert :()

Wie stehst du zu Firewalls auf deinem Server? Ein
Code:
iptables -A OUTPUT -m owner --gid-owner deine_usergruppe -j DROP
lößt ein paar Probleme aber entspricht halt nicht der reinen Lehre :(
 
Spielverderber :D

Tut mir leid :p

Das setuid-bit funktioniert bei Scripten (also alles was mit #! anfängt) nicht (ist ein Sicherheitsfeature), wenn du das so machen willst muß den Wrapper ein direkt ausführbares Programm sein (für viele Skriptsprachen gibt es ja netterweise Compiler :))

Sollte ich hinbekommen ;)

Wenn dein Sicherheitskonzept auf chroot und das experimentelle MPM ITK bassiert wirst du doch vermutlich auch den grsecurity Kernel Patch einsetzten?

Ja, damit sicher ich dann gleichzeitig auch das chroot besser ab. Gibt da ja auch diverse Tricks, wie man da wieder raus kommt... verschachteltes chroot, symlinks etc.

Damit sollte man den Usern auch den Netzwerkzugriff nehmen können (wobei das wieder nur auf Halbwissen meinerseits bassiert :()

Wie stehst du zu Firewalls auf deinem Server? Ein
Code:
iptables -A OUTPUT -m owner --gid-owner deine_usergruppe -j DROP
lößt ein paar Probleme aber entspricht halt nicht der reinen Lehre :(

Wenn ich den Usern Netzwerkzugriff verbiete, dann wird Apache, der sich ja mit setuid/gid auch mit den Rechten eines dieser User ausführt, die Anfragen nicht mehr bearbeiten können, oder?
 
Wenn ich den Usern Netzwerkzugriff verbiete, dann wird Apache, der sich ja mit setuid/gid auch mit den Rechten eines dieser User ausführt, die Anfragen nicht mehr bearbeiten können, oder?
Der Apache der die Verdindung annimmt hat bei MPM_ITK root Rechte, ich habe keine Ahnung ob die bereits aufgebaute Verbindung automatisch den Besitzer wechselt wenn sie zu einem anderen Apache weitergegeben wird :( Einfach mal ausprobieren...
Wenn's nicht funktioniert kannst du ja immernoch alles verbieten was von der benutztergruppe stammt und zu Port 25 gesendet wird.
 
sendmail wird eh nicht über Netzwerk erreichbar sein, denn der Server soll gar kein Mailserver werden. Eben nur die Möglichkeit besitzen über Kommando Mails zu versenden, eben für Foren etc.
Von daher ist Port 25 / SMTP kein Problem!!
 
Kennst Du Policy Daemon?

Damit kann man die Anzahl Mails pro Zeiteinheit beschränken (pro Absender-Adresse, Username oder IP).

Über das sendmail-Kommando kann man die Absenderadresse aber fälschen, die IP ist immer die selbe und einen SMTP-Usernamen hat man auch nicht...

Du könntest den Usern aber evtl. sendmail als Alias von "sendmail -f user@domain.tld" hinterlegen, so wäre der Absender eindeutig.
 
Von daher ist Port 25 / SMTP kein Problem!!
Versteh ich nicht. Du willst doch, soweit ich das verstanden habe, das dein sendmail Mails an beliebige Mailserver Port 25 senden darf aber das deine User nicht direkt Verbinung mit beliebigen Mailserver aufbauen dürfen weil sie sonst deinen Wrapper und somit auch deine Beschränkungen umgehen dürfen? Dafür mußt du alle IP Packete von allen User mit Port 25 als Ziel blockieren. Port 25 ist in beiden Fällen der Zielport, von deinem Server aus gesehen, ob auf deinem eigenen Server irgendwas auf Port 25 lauscht oder nicht ist egal.
Wenn du das noch ausweitest und nicht nur Spam sondern auch diverse DoS und Brute Force Angriffe und was es sonst noch gibt verhindern willst mußt du deinen Usern praktisch jeglichen Netzwerkzugriff verbieten(ggf. mit Ausnahme von ein paar Servern auf einer Whitelist z.b. dem Typo3 Extension Repository Server).
Wer aus Sicht von iptables bei MPM_ITK die IP Packete versendet weiß ich wie schon gesagt nicht, wenn es root ist hast du Glück, wenn nicht hast du ein Problem. Einfach mal ausprobieren...
 
Danke für den Hinweis!
Aber ein eigener Wrapper ist glaube ich besser, da es sehr schlecht wäre, wenn die Mails, die geblockt werden, einfach verschwinden.

Mit meinem eignen Wrapper, werde ich die Mails die geblockt werden, in der Datenbank speichern und dem User zugänglich machen, damit er sie später senden kann und merkt, wenn er über sein Limit geht!
 
Wer aus Sicht von iptables bei MPM_ITK die IP Packete versendet weiß ich wie schon gesagt nicht, wenn es root ist hast du Glück, wenn nicht hast du ein Problem. Einfach mal ausprobieren...

Werde ich tun! Und dann hier schreiben!!
 
Back
Top