Spamversand über PHP Scipts

#1
Nachdem wieder einmal ein verseuchtes Web unmengen an Spam versendet hat

https://www.howtoforge.de/forum/threads/spamversand-ueber-welches-konto-feststellen.10117/

würde mich schon interessieren warum dies so einfach möglich ist.

Im Log steht:

Aug 28 03:31:29 srv05 amavis[29936]: (29936-01-32) Passed CLEAN {RelayedOpenRelay}, <genevieve_mills@kundendomain.xyz> -> <banzailacoste@hotmail.fr>, Message-ID: <0b91d6af24332ddadc32c71950d24844@kundendomain.xyz>, mail_id: L3_nFpMwxxeA, Hits: 0.1, size: 1236, queued_as: 891DFC01CA, 5293 ms

Meine Frage:

Warum kann ein PHP Scipt so einfach Emails über den Server versenden und wie kann ich das verhindern?

Danke vorab
 
#5
Ich bin der Hoster nicht der Webdesigner ;-) dafür werde ich nicht bezahlt :-D

Ich will meinen Server absichern damit so ein Script nicht mehr ohne weiteres Spams versenden kann, OK? :)
 
#9
Eigentlich möchte ich nur den unauthorisierten Mailversand unterbinden.
Ein Versand der Email über Benutzername und Kennwort unter Angabe des Mailservers soll erlaubt bleiben ...
 

Till

Administrator
#10
Ein Script welches auf Deinen Server hochgeladen wurde läuft als localhost und ist somit authorisiert. Das problem ist also das gehackte Wordpress und nicht die Emailfunktion, denn woher soll der Mailserver wissen können ob Dein Kunde oder ein Hacker den gerade aufgerufenen Code zum senden der Email gschrieben hat.

Ein Versand der Email über Benutzername und Kennwort unter Angabe des Mailservers soll erlaubt bleiben ...
Das kannst Du zwar machen, geht natürlich nicht mit jedem cms und bei standardsystemen wie WP lesen die Hacker dann halt einfach die Zugansdaten aus den Wordpress Options aus und verwenden sie zum senden und wenn Du pech hast geben sie die auch gleich noch an ein botnet weiter, um noch einfacher mails zu senden. Ich sehe darin also keinen Vorteil es so zu machen da Du damit nur Deinn Mailserver kompromittierst. Aber wenn Du es so machen willst, dann pache die mail() Funktion in der php.ini auf die Liste der nicht erlaubten Funktionen, ersetze /usr/bin/sendmail durch ein fake script und szoppe das komplette mailsystem, das wird aber möglicherweise diverse Nebenwirkungen haben da das mailsystem unter Linux auch zur benachrichtigung des root users verwendet wird.
 
#11
Ja, das ist ein Dilemma aber den Mailserver könnte ich besser kontrollieren. Denke an ein Limit versendeter Email´s pro Tag und Konto, sowie Adminbenachrichtigungen wenn Limits überschritten werden.
 

Till

Administrator
#12
Ja, das ist ein Dilemma aber den Mailserver könnte ich besser kontrollieren. Denke an ein Limit versendeter Email´s pro Tag und Konto, sowie Adminbenachrichtigungen wenn Limits überschritten werden.
Ob Du den mail oder den webserver kontrollierst sollte an sich keinen Unterschied machen. Über den mailserver zu senden hat aber einen riesigen Nachteil, denn wenn darüber SPAM raus geht werden auch die normalen Mailkonten geblacklistet und nicht nur die Emails die über Webseiten versendet wurden. Wenn man über einen zentralen Mailserver versenden will dann sollte es zumindest ein extra relay server sein auf dem keine Mailkonten liegen.
 
#13
Habe tagelang gesucht weil ich rausfinden wollte über was mails versendet werden. Auf einer englischen Webseite fand ich den entscheidenden Hinweis in die /var/spool/postfix/defer und deferred zu sehen. Dort waren auch die ganzen mails versteckt die ISP mit immer noch unter mailwarteschlange anzeigte. In den Einträgen konnt man genau sehen welches Script da verschickt. Hatte schon mal gefragt wie man diese alten Einträge die ISP nach wie vor unter Mailwarteschlange anzeigt gelöscht bekommt.
 
#14
ISPconfig wertet doch nur das Ergebnis von mailq aus. So lange die Mails noch auf dem Server liegen, stehen die halt in der queue. Die kannst Du aber mit postfix-tools löschen
 
#15
Du hast zwar schon das Skript gefunden, aber wenn du in der jeweiligen php.ini "mail.log" definierst, wird in dieser Datei protokolliert wenn über PHP Mails versendet werden. Hilft dir evtl. in der Zukunft oder zur Auswertung von späteren Fällen.
Ganz verhindern lässt sich sowas leider nur indem man den Content immer aktuell hält.
 
#16
Ich halte es in solchen Fällen immer so, dass ich den Kunden über die Verseuchung informiere, ihm 12 Stunden Zeit gebe, das selber zu reparieren bevor das Hosting wg. Mißbrauch komplett gesperrt wird - und biete in gleichem Zuge meine Arbeitszeit zu üblichen Sätzen an.

Die meisten Kunden sind darüber nicht erfreut, verstehen aber, dass ich als Hoster für die Betriebssicherheit aller Kunden verantwortlich bin und damit auf Einzelschicksale nur bedingt Rücksicht nehmen kann. In aller Regel wird dann auch direkt der Auftrag zur Bereinigung erteilt, was beinhaltet, das WP zu bereinigen.

Erstaunlicherweise ist Joomla seit der 3.5 nicht mehr in dem Focus der Angreifer, wie WP... (oder ist das nur meine Wahrnehmung?)
 

Werbung

Top