Netcup Webspace und PHP mail()

[infinitnet]

Gestern Abend rief mich mein Vater ganz verzweifelt an und erzählte, sein Webspace bei Netcup wäre gesperrt worden, da davon Spam versendet wurde und Netcup verlange ein Statement sowie eine Unterlassungserklärung per Post. Heute morgen habe ich mir das Ganze mal angesehen und der Sample Header, den Netcup zur Verfügung gestellt hat, sieht stark danach aus, als wäre der Spam per PHP-Skript versendet worden. Also das übliche Szenario - wohl ein altes Joomla! oder WordPress, worüber Spam-Skripte eingeschleust wurden.

So weit, so gut. Nun stellt sich mir aber die Frage, warum PHPs mail() Funktion auf einem Webspace-Server überhaupt standardmäßig aktiviert ist. Ich kenne mich mit Netcups Webspace überhaupt nicht aus, weiß also nicht, ob es möglich gewesen wäre, eigene php.ini-Einstellungen zu verwenden. Da gerade unerfahrene Kunden gerne auf Webspace zurückgreifen, frage ich mich aber, warum gerade eine solche Funktion nicht standardmäßig deaktiviert ist, wie ich es von jedem anderen x-beliebigen Webspace-Anbieter kenne. Es kommt in solchen Umgebungen doch andauernd vor, dass über veraltete Skripte "eingebrochen" und Spam versendet wird, weshalb ich es als grobe Fahrlässigkeit des Anbieters erachten würde, in keiner Weise dagegen vorzubeugen. Selbst wenn alle Skripte up2date sind, kann es immer wieder 0day-Exploits oder Sicherheitslücken in Templates geben, wovor man sich mit einem Webspace nur schwer selbst schützen kann, abgesehen von ein paar .htaccess-Regeln, was aber auch nicht gerade das Gelbe vom Ei ist. popen() und shell_exec() lässt man auf einem Webspace-Server doch auch nicht aktiviert.

Ich frage mich nun, ob ich das zu eng sehe, da ich das in diesem Fall aus der Sicht des Kunden sehe. Wie seht ihr das?

Anmerkung: Dies soll keineswegs ein "Netcup-bash-Thread" werden - ich hatte bis dato nur gute Erfahrungen mit Netcup. Mich interessiert lediglich eure Meinung, da ich mir nicht sicher bin, ob meine angemessen ist.

 

[infinitnet]

Update: Auf das Problem wird vom Support nicht weiter eingegangen. Auf Nachfrage, warum PHPs mail()-Funktion standardmäßig auf dem Webspace-Server aktiviert ist, wurde mir mitgeteilt, dies sei auch bei anderen Anbietern wie Strato und 1&1 der Fall. Auf einen entsprechenden Vermerk auf das hier und hier das gelbe Feld unter "Schritt 1" wurde dann nicht weiter eingegangen.

Also, wie seht ihr das? Uneingeschränkter Zugriff durch Skripe auf PHP mail() auf einem Shared-Webspace-Server fahrlässig, in Ordnung oder gar Standard?

PS: Natürlich steht es außer Frage, dass der Kunde dafür verantwortlich ist, seine Skripte sicher zu halten. Ich vertrete aber die Meinung, dass der Anbieter auch Vorkehrungen treffen sollte, das Schlimmste zu unterbinden, soweit das möglich ist, ohne die Funktionen des Webspace zu sehr einzuschränken. Ich finde den Ansatz von 1&1 recht sinnvoll, also den Versand von Mails über PHP mail() nur zu gestatten, wenn ein bestimmtes verstecktes Forumlarfeld mit übermittelt wird. Veraltete/Unsichere Skripte gehören auf einem Shared-Webspace-Server nun mal leider zum Alltag.

 

[d4f]

Nun stellt sich mir aber die Frage, warum PHPs mail() Funktion auf einem Webspace-Server überhaupt standardmäßig aktiviert ist

Mir ist kein Webspace bekannt wo das NICHT der Fall ist. Sogar auf Freespace ist das generell aktiv, da es sonst keinerlei Möglichkeit gibt um Emails zu versenden... und das ist nun mal eine Standardfunktion.

Da gerade unerfahrene Kunden gerne auf Webspace zurückgreifen

Unerfahrene Kunden greifen auch gerne auf Rootserver zurück, der Provider kann und will sie trotzdem nicht am Händchen nehmen. Wenn man ein Produkt mietet das einen hohen Missbrauchrisiko mit sich bringt muss man verantwortungsbewusst handeln und/oder das Resultat in Kauf nehmen. Versuchen die Schuld auf jemand anders, also den Provider, zu schieben ist einfach nur... *kopfschüttel*
Es gibt nicht grundlos den "Titel" eines Webmasters, der sich vom Systemadministrator unterscheidet.

popen() und shell_exec() lässt man auf einem Webspace-Server doch auch nicht aktiviert.

Auf sehr vielen kostenpflichtigen Webspaces ist dies aber aktiv. Schlicht weil sehr viele Webanwendungen, angefangen beim populären Typo3, dies voraussetzen.

Es kommt in solchen Umgebungen doch andauernd vor, dass über veraltete Skripte "eingebrochen" und Spam versendet wird

Nicht weniger oft kommt es vor dass Kunden gesperrt und für den Schaden (Blacklisting, Arbeitszeit, ...) zur Kasse gebeten oder zur Tür gebeten werden.
Wieder mal: Risiko und Verantwortung.

Auf einen entsprechenden Vermerk auf das hier und hier das gelbe Feld unter "Schritt 1" wurde dann nicht weiter eingegangen

Da wird keineswegs von einer Blockierung der PHP mail()-Funktion geredet (gegen welche Kunden Sturm laufen würden) sondern davon dass ein PHP-Skript nicht OHNE die mail()-Funktion mit externen Mailserver reden kann. Dies ist ein bedeutend höheres Risiko und von vielen Webhoster entsprechend blockiert da es weder richtig erkennbar noch drossel- oder filterbar ist.

Uneingeschränkter Zugriff durch Skripe auf PHP mail() auf einem Shared-Webspace-Server fahrlässig, in Ordnung oder gar Standard?

Standard, jedoch sollte der Anbieter ein Maximalwert je Zeitintervall setzen/verwenden respektive ausgehende Mails auf Spam überprüfen. Auch dies kann aber nur einen Bruchteil der Spammer nennenswert stören.

 

[GwenDragon]

Eine Unterlassungserklärung ist schon happig! Aber da will sich der Hoster wohl absichern.

Es ist kein Problem mail() aktiviert zu lassen, auf einem Webhost, auf dem auch PHP läuft. Es kann ja kein fremder Websapce das mail() des laufenden PHP-Prozesses kapern.

Irgendwie musst du doch einfach Mails versenden können bei PHP-Webanwendungen oder sollen die Leute sich mit einer Pipe an sendmail abkaspern, was noch viel risikoreicher sein kann für Unerfahrene.

 

[infinitnet]

Danke für eure Antworten. Eventuell reden wir aneinander vorbei - es geht darum, dass Skripte ohne Authentifizierung am SMTP Mails versenden können, was bspw. bei Strato laut FAQ nicht der Fall ist und bei 1&1 nur mit einem speziellen Forumlarfeld.

 

[d4f]

bei 1&1 nur mit einem speziellen Forumlarfeld.

Nein, das Formularfeld soll laut Quelltext nur davor schützen dass Spambots dieses Formular verwenden. Dass das absoluter Humbug ist und entweder der Autor von einer Spambot-Intelligenz auf dem Niveau Anno 2000 ausgeht oder selber nicht versteht wie Spambots funktionieren ist offensichtlich. Der Code muss aber nicht enthalten sein - im vom Spammer hochgeladenen Skript wird sowas sicherlich nicht zu finden sein und trotzdem 1a funktionieren.

bei Strato laut FAQ nicht der Fall ist

Nach einem 2. Überlesen dieses Artikels stimme ich zu dass das tatsächlich so da steht. Allerdings wird das mit der absoluten Mehrzahl (geschätzt deutlich jenseits 90% aller PHP-Skripte) Probleme machen da diese sich auf mail() verlassen.
Falls dies bei Strato aktuell helfen soll, dann einzig und allein nur weil sonst kein Anbieter solch aberwitzige und idiotische Einschränkungen hat.
Dass es einfach sinnlos ist, erkennt man schon wenn man bedenkt dass die Zugangsdaten in einer Konfigurationsdatei liegen müssen und der Angreifer zu dem Zeitpunkt bereits vollen Zugriff auf den Webspace hat und somit nur die Datei lesen muss um Benutzername + Passwort zu kennen. Wie DRM also: eine Gängelung der Kundschaft ohne sinnvollen Schutz gegen Missbrauch.

 

[infinitnet]

Nein, das Formularfeld soll laut Quelltext nur davor schützen dass Spambots dieses Formular verwenden. Dass das absoluter Humbug ist und entweder der Autor von einer Spambot-Intelligenz auf dem Niveau Anno 2000 ausgeht oder selber nicht versteht wie Spambots funktionieren ist offensichtlich. Der Code muss aber nicht enthalten sein - im vom Spammer hochgeladenen Skript wird sowas sicherlich nicht zu finden sein und trotzdem 1a funktionieren.


Nach einem 2. Überlesen dieses Artikels stimme ich zu dass das tatsächlich so da steht. Allerdings wird das mit der absoluten Mehrzahl (geschätzt deutlich jenseits 90% aller PHP-Skripte) Probleme machen da diese sich auf mail() verlassen.
Falls dies bei Strato aktuell helfen soll, dann einzig und allein nur weil sonst kein Anbieter solch aberwitzige und idiotische Einschränkungen hat.
Dass es einfach sinnlos ist, erkennt man schon wenn man bedenkt dass die Zugangsdaten in einer Konfigurationsdatei liegen müssen und der Angreifer zu dem Zeitpunkt bereits vollen Zugriff auf den Webspace hat und somit nur die Datei lesen muss um Benutzername + Passwort zu kennen. Wie DRM also: eine Gängelung der Kundschaft ohne sinnvollen Schutz gegen Missbrauch.

Zu 1&1: Ich habe mir den Code gar nicht genau angesehen - du hast Recht, es handelt sich dabei ja echt nur um ein Formular. Anscheinend ist es bei 1&1 so, dass mail() bei den kleineren Paketen auch deaktiviert ist oder war (s. http://www.flashforum.de/forum/1678951-post11.html).

Beim Deaktivieren der Funktion geht es nur darum, die vollautomatisierten Angriffe auf veraltete CMSs zu unterbinden, bzw. die Auswirkungen, sollten diese erfolgreich sein. Wenn es sich um einen manuellen Angriff handelt, hast du natürlich Recht und der Angreifer könnte einfach die für den Mailversand zuständige Datei auslesen und somit den SMTP-Login. Was aber bei Websites, die gar keine Mails versenden, auch nicht passieren kann.

 

[kasimir]

Bei Strato ist die Angabe des SMTP-Servers nicht notwendig.
Die FAQ bezieht sich darauf, dass falls man ein SMTP-Server angeben muss (z.b. bei fertigen Mail-Skripten) nur der von Strato genutzt werden kann und keinen externen.

 

[Alderon]

IMO kann man jetzt ewig über die Schuld des Hosters diskutieren, Fakt ist aber, dass ein CMS immer aktuell gehalten werden muss. Selbst wenn nicht Spam versendet wird, können da noch ganz andere Sachen passieren. Da hilft dann eine deaktivierte mail() Funktion auch nichts mehr.

Die meisten CMS bieten heutzutage sogar one click oder sogar auto updates an, was das Updaten zu einem wahren Kinderspiel macht.
Ich weiß, Autovergleiche hinken immer aber IMO passt es ganz gut, wenn man Patchen als Inspektion ansieht. Der Kunde muss keine Ahnung von den technischen Details haben, darum kümmert sich auch weiterhin der Hersteller.
Der Kunde sollte aber regelmäßig zur Inspektion (aka patchen/updaten), damit sein Auto (aka CMS) auch weiterhin gut benutzbar bleibt und keine Gefährdung für Dritte darstellt.

So erspart sich Dein Vater vor allen Dingen etwaigen Ärger in der Zukunft.

 

[infinitnet]

Bei Strato ist die Angabe des SMTP-Servers nicht notwendig.
Die FAQ bezieht sich darauf, dass falls man ein SMTP-Server angeben muss (z.b. bei fertigen Mail-Skripten) nur der von Strato genutzt werden kann und keinen externen.

Die FAQ sind dann aber mehr als misverständlich formuliert.

IMO kann man jetzt ewig über die Schuld des Hosters diskutieren, Fakt ist aber, dass ein CMS immer aktuell gehalten werden muss. Selbst wenn nicht Spam versendet wird, können da noch ganz andere Sachen passieren. Da hilft dann eine deaktivierte mail() Funktion auch nichts mehr.

Die meisten CMS bieten heutzutage sogar one click oder sogar auto updates an, was das Updaten zu einem wahren Kinderspiel macht.
Ich weiß, Autovergleiche hinken immer aber IMO passt es ganz gut, wenn man Patchen als Inspektion ansieht. Der Kunde muss keine Ahnung von den technischen Details haben, darum kümmert sich auch weiterhin der Hersteller.
Der Kunde sollte aber regelmäßig zur Inspektion (aka patchen/updaten), damit sein Auto (aka CMS) auch weiterhin gut benutzbar bleibt und keine Gefährdung für Dritte darstellt.

So erspart sich Dein Vater vor allen Dingen etwaigen Ärger in der Zukunft.

Das steht natürlich außer Frage! Ich habe bereits mehrfach erwähnt, dass ich die Schuld hier keinesfalls auf Netcup schieben möchte. Ich habe mich lediglich gefragt, was eure Meinung bezüglich der Deaktivierung von mail() auf Shared-Servern ist, was auch schon relativ deutlich geworden ist.

 

[killerbees19]

Wie netcup damit umgeht, lasse ich mal so stehen. Für reinen Webspace finde ich es fast schon übertrieben

Ich frage mich nun, ob ich das zu eng sehe, da ich das in diesem Fall aus der Sicht des Kunden sehe. Wie seht ihr das?

Wenn es Dinge wie mail() nicht geben würde, wäre ich (als Kunde) irritiert
Das ist einfach Standard und muss meiner Meinung nach überall verfügbar sein!

Wir sprechen hier nicht von einer gefährlichen Funktion, sondern genau vom Gegenteil. Willst du stattdessen alles (vorallem die Firewall) für den SMTP-Zugriff freigeben, wo ich später vielleicht gleich andere Kundenaccounts knacke, weil ich die Passwörter der Mail-Accounts errate? Da ist mir ein schöner interner Zugriff über mail() deutlich lieber. Das lässt sich im Bedarfsfall sogar noch schöner filtern als alle anderen Methoden zusammen.

Und wie bereits angemerkt wurde: Wenn ich eigenen Code einmal ausführen kann, kann ich wahrscheinlich auch die SMTP-Zugangsdaten auslesen, worüber die Mails ohne mail() versendet werden. Oder falls die Firewall es erlaubt auch gleich direkt SMTP-Verbindungen zu fremden Servern aufbauen.


MfG Christian

 

[d4f]

Da ich es bislang vergessen habe zu erwähnen und es eigentlich auch mit der Hauptfrage des Thema nicht zusammenhängt: ich finde aus Sicht eines Systemadministrators die Forderung Seitens Netcup auf Unterlassungserklärung doch etwas hoch gegriffen und sinnfrei. Ich muss auch keine Unterlassungserklärung unterschreiben wenn ein Ziegelstein vom Dach fällt, höchstens Schadensersatz leisten sofern er denn nennenswert und bezifferbar ist...

Am Rand: es gibt Webhoster welche die Anzahl an maximalen Emails je Stunde pro Kunde individuell einstellen und auch warnen können, falls du dir unsicher bist wäre eine solche Funktion ein sinnvolles Feature. Bei bspw 50 versandten Spams und danach Blockierung ist generell der "Schaden" vernachlässigbar und damit auch der Schlaf gerettet.

 

[Elradon]

Der Vorschlag von d4f im letzten Absatz scheint mir sehr sinnvoll zu sein. Die komplette Abschaltung nicht. Wie oft gesagt, benötigen das sehr viele Skripts. Man muss sich dann vorstellen, dass sich die meisten Kunden an den Support werden, der wiederum dann Arbeit damit hat das manuell freizuschalten. Zudem sind die Kunden dann sicherlich auch ein Stück verärgert, dass "etwas nicht geklappt" hat, was auch nicht im Interesse eines Unternehmens ist.

 

[infinitnet]

Da ich es bislang vergessen habe zu erwähnen und es eigentlich auch mit der Hauptfrage des Thema nicht zusammenhängt: ich finde aus Sicht eines Systemadministrators die Forderung Seitens Netcup auf Unterlassungserklärung doch etwas hoch gegriffen und sinnfrei. Ich muss auch keine Unterlassungserklärung unterschreiben wenn ein Ziegelstein vom Dach fällt, höchstens Schadensersatz leisten sofern er denn nennenswert und bezifferbar ist...

Am Rand: es gibt Webhoster welche die Anzahl an maximalen Emails je Stunde pro Kunde individuell einstellen und auch warnen können, falls du dir unsicher bist wäre eine solche Funktion ein sinnvolles Feature. Bei bspw 50 versandten Spams und danach Blockierung ist generell der "Schaden" vernachlässigbar und damit auch der Schlaf gerettet.

So wie es aussieht wurde auf die Unterlassungserklärung inwzischen verzichtet und es wird nur noch ein Statement gefordert. Malware war keine vorhanden, zumindest keine bekannte und aufgrund mangelnder Logs war es mir nicht möglich, das Einfallstor in der von Netcup zur Verfügung gestellten "Entsperrzeit" (30 Minuten) genau zu bestimmen, bzw. überhaupt herauszufinden, worüber die Mails versendet wurden. Übrig bleibt ansich nur das CMS selbst bzw. dessen PHP Mailer, also ggf. ein geknacktes Administrationspasswort o.Ä., jedenfalls war kein einziges Skript zu finden, was Mails versenden kann und nicht zum CMS gehört. Ich habe mich heute Abend dem Problem angenommen und die Websites von meinem Vater auf einen vServer von IP-Projects verschoben, welcher entsprechend vorbeugend eingerichtet wurde und überwacht wird. Da Netcup sich weigerte PHP mail() in der User-php.ini zu deaktivieren, war es mir viel zu unsicher auf gut Glück die Websites dort weiterlaufen zu lassen, ohne alles überwachen zu können und selbst unter Kontrolle zu haben, zumal ich immer noch nicht genau weiß, was da vor sich gegangen ist. Bis jetzt hat sich noch nichts gerührt.