• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Server sendet Spam?!

Hi Huschi,
Danke für die Hilfe! :)

Habe seit gestern Sendmail ausgeschaltet und nur periodisch wieder eingeschaltet um zu sehen, ob es Spam auslöst. Bin also momentan wenigstens keine Spam-Schleuder mehr.
Habe einen Sendmail Wrapper gestern für die PHP Mail() Funktion installiert (resp. über php.ini das sendmail-Prog ausgetauscht). Leider werden da keine Logs aufgezeichnet, resp. Tests waren schon erfolgreich, aber Spam scheint nicht von da zu kommen.
Es gibt ja aber auch noch andere Möglichkeiten mit PHP Mails zu versenden, evtl. direkt mit Sockets, das muss ich noch überprüfen.

Evtl. könnte es auch sein dass ein User ein Virus geladen hat. Habe nämlich auch diese Zeilen in der sysLog entdeckt:
Code:
Aug 25 04:34:40 39197 PAM-warn[20371]: function=[pam_sm_authenticate] service=[smtp] terminal=[<unknown>] user=[web13p4] ruser=[<unknown>] rhost=[<unknown>]
Aug 25 04:34:40 39197 PAM-warn[20371]: function=[pam_sm_acct_mgmt] service=[smtp] terminal=[<unknown>] user=[web13p4] ruser=[<unknown>] rhost=[<unknown>]
Aug 25 04:34:46 39197 PAM-warn[20374]: function=[pam_sm_authenticate] service=[smtp] terminal=[<unknown>] user=[web13p1] ruser=[<unknown>] rhost=[<unknown>]
Aug 25 04:34:46 39197 PAM-warn[20374]: function=[pam_sm_acct_mgmt] service=[smtp] terminal=[<unknown>] user=[web13p1] ruser=[<unknown>] rhost=[<unknown>]
Aug 25 04:34:53 39197 PAM-warn[20374]: function=[pam_sm_authenticate] service=[smtp] terminal=[<unknown>] user=[web13p1] ruser=[<unknown>] rhost=[<unknown>]
Aug 25 04:34:53 39197 PAM-warn[20374]: function=[pam_sm_acct_mgmt] service=[smtp] terminal=[<unknown>] user=[web13p1] ruser=[<unknown>] rhost=[<unknown>]
Aug 25 04:34:59 39197 PAM-warn[20374]: function=[pam_sm_authenticate] service=[smtp] terminal=[<unknown>] user=[web13p1] ruser=[<unknown>] rhost=[<unknown>]
Hab web13p1 und web13p4 mal vorübergehend deaktiviert und User informiert. Vielleicht wars das auch schon im Moment werden keine Mails versandt.

Gibt es auch einen generellen Mail-Wrapper für Sendmail? Resp. gibt es eine Möglichkeit zu sehen, durch welchen User die Mails im Log verschickt werden? Denn ich hab ja SMTP_AUTH aktiviert... Das heisst falls es von aussen kommt (durch einen User-Account) wie seh ich da durch welchen?
Muchos gracias!

added:
Du hast recht, bin in dnsbl.cyberlogic.net geloggt (über http://networktools.nl geprüft). Zum glück nicht in allen den Listen....

Die erhöhten Netzwerkzugriffe machen mir auch noch etwas sorgen (wie gestern wieder mit 4 MB/s). Evtl. von Brute-Force Attacke? Leider finde ich dazu nichts in den Logs...
 
Last edited by a moderator:
Mit tcpdump oder iftop kannst du erst einmal ermitteln welcher Art der Traffic ist.
 
Ein Mailbox-Account-Missbrauch ist statistisch gesehen seltener als ein Webscript, aber ich war selber vorhin Blind. Denn es steht doch schon dort:
Aug 24 17:53:23 39197 sendmail[28232]: o7OFr7as028232: from=<noreply@netlogmail.com>, size=2562, class=0, nrcpts=50, msgid=<201008241553.o7OFr7as028232@meinserver@domain.com>, proto=ESMTP, daemon=MTA, relay=[82.114.70.90]
Die Mails kamen also über den Server 82.114.70.90 mit einer langen BCC-Liste.
Du musst leidglich rausfinden ob (!!!) und mit welchem User die sich eingeloggt haben.
Das sollte relativ leicht sein, da ja die PAM-Warnungen geschrieben werden. Du musst nur die passende Warnung zum Maillog-Eintrag vom Aug 24 17:53:23 suchen.

huschi.
 
Immer diese falsche Panik mache!!! :mad:
- "Server gehackt! ... Nicht mehr unter Deiner Konrolle!"
- "Update überfällig!"
- Apache veraltet...
- Sendmail veraltet (aber immer noch aktueller als ein Qmail).
- etc.

Sorry, aber dafür habe ICH kein Verständnis.
Statt dem User wirklich zu helfen wird hier lediglich Panik-Mache geschoben und auf ihn eingedroschen.



Nichts gegen dich aber diese Kleinigkeit ist Dir wohl entgangen.

Was komisch ist: Laut Logs wurde der Server heute 14:14 neu gestartet (keine Ahnung wieso). Es wurde auch eine krasse (unnatürliche) Datenmenge auf den Server gesandt so um 14:05. Logfiles um diese Zeit (Apache/PAM/FTP/...) zeigen aber nichts aussergewöhnliches...?


Mag ein Zufall gewesen sein.
Halte es aber für einen sehr unwahrscheinlichen Zufall.

Oder was ist Deine Vermutung dazu?
Starten sich Deine Hosts einfach mal so bei einer Brutoforceattacke bzw. dem Versuch eine Mailformular zu Missbrachen einfach neu? Deine Vermutung mag ja ggf. richtig sein,

Aber seine Probleme mit erhöhtem Traffic gingen schon um ca. 14:00 los nicht erst um 17:00 da wird er nicht mehr viel finden.
Wie kommt der Angreifer an das Passwort oder hat er eine andere Lücke genutzt um sich einen Account zu hacken?

Und Opensuse 10.3 und davor , ist dir vermutlich auch entgangen, haben nunmal ausnutzbare Lücken.
Fahrlässig ist es einem solchen Benutzer halblebig zu helfen und Ihn weiterhin mit einem offen Scheunentor im Netz zu lassen.
"Bis es dann wieder heisst, Huch mein Server verschickt Spam" oder schlimmeres...

Es mag ja sein, dass Du hier Deine "Kompetenz" beweisen willst. Aber übelege Dir mal, ob es gut ist jemandem zu helfen, der zwingend andere Dinge zu beheben hat. z.B. seine alte Distribution.


Und nun die Masterfrage zu Schluss,
Wenn Jemand / ein Angreifer es geschafft hat einen reboot zu iniitieren (ohne ein zutun des Admins), wie aufwändig wird es dann den gestoppten Sendmail wieder zu starten?
Ich denke nicht, dass er den Reboot bzw. Apache Restart. über den Sendmail initiiert hat.

Denk mal ganz scharf drüber nach, ob ein herunterfahren des Sendmails an der Stelle wirklich ausreichend ist.
 
Last edited by a moderator:
Matze danke das du mich darauf aufmerksam machst dass ich unbedingt meine Distro aktualisieren muss. Werde ich ja auch tun! Es scheint aber dass der Ursprung des Problems langsam gefunden ist und dass dieser evtl. mit meiner Distro gar nichts zu tun hat!

Erklärung für Server-Restart könnte der Provider sein, der bei Spam-Versand auch irgend ein Analyse Tool hat und dann den Server rebootet. Ist leider kein Rootserver sondern VM, da können die schon eher den Server neustarten. (Support-Anfrage diesbezüglich erstellt)

Sendmail läuft nun seit einer Stunde wieder mit normalem Mail-Versand (hab vor Neustart alle Queues gelöscht). Scheint die Deaktivierung der 2 Accounts mit übermässigen PAM-Logs hat geholfen.
Hab den User angeschrieben ob er einen Virus hat.
Wie hoch stehen die chancen, dass ein Client gehackt wurde, und ein Trojaner oder so verwendet z.B. sein in Outlook hinterlegten E-Mail Account? Falls das passiert kann ja auch ein sehr sicherer gut konfigurierter Server zur Spam-Schleuder werden....

Nur noch eine Erklärung für den sehr hohen Traffic in 3 kurzen Zeitfenstern such ich... Evtl. hat der Mailserver genau dann massig E-Mails versandt, resp. zu diesere Zeit den Befehl erhalten, Viele Mails mit unzähligen BCCs zu versenden. Bin jetzt daran die Logs ganz genau zu untersuchen...
Mit tcpdump oder iftop kannst du erst einmal ermitteln welcher Art der Traffic ist.
Dazu müsste ich ja einen live-mitschnitt machen, wenn das mit dem erhöhten Traffic erneut passiert...?

Denk mal ganz scharf drüber nach, ob ein herunterfahren des Sendmails an der Stelle wirklich ausreichend ist.
Dank meinen Graphs und verknüpfter E-Mail-Benachrichtigung merke ich den erhöhten Mailversand sofort und kann Sendmail sofort wieder stoppen, falls es wieder kommt...
 
Last edited by a moderator:
Erklärung für Server-Restart könnte der Provider sein, der bei Spam-Versand auch irgend ein Analyse Tool hat und dann den Server rebootet. Ist leider kein Rootserver sondern VM, da können die schon eher den Server neustarten. (Support-Anfrage diesbezüglich erstellt)

Eher, dass er Überlast erkannt hat und den Host neu gestartet hat.
-> Eventuell eine Reaktion auf Beschwerden.
Ein Provider der lediglich einen Host neustartet wenn er diesen als "SPAM" Host erkennt ist eher unwahrscheinlich. Diese nehmen sowas i.d.R. vom Netz.

Wie hoch stehen die chancen, dass ein Client gehackt wurde, und ein Trojaner oder so verwendet z.B. sein in Outlook hinterlegten E-Mail Account? Falls das passiert kann ja auch ein sehr sicherer gut konfigurierter Server zur Spam-Schleuder werden....

Diese Möglichkeit besteht sowie z.B. dass sich eine Spyware die Passworte gegriffen haben.

Nur noch eine Erklärung für den sehr hohen Traffic in 3 kurzen Zeitfenstern such ich... Evtl. hat der Mailserver genau dann massig E-Mails versandt, resp. zu diesere Zeit den Befehl erhalten, Viele Mails mit unzähligen BCCs zu versenden. Bin jetzt daran die Logs ganz genau zu untersuchen...

Dazu müsste ich ja einen live-mitschnitt machen, wenn das mit dem erhöhten Traffic erneut passiert...?

tcpdump, (alternativ auch erstmal netstat)

zu klären wäre auch, ob die Mails tatsächlich durch einen Trojaner von Deinem "Kunden" kommt oder ob das Passwort weiter gereicht wurde.

-> Klären welchen DSL Anschluss der "Kunde" hat und wo hoch der eingehende Traffik war und das mit dem upstream des "Kunden" zusammen passen kann.
(Wenn dieses eine 100Mbit Bandbreite ausgelastet hat, also eingehend z.B. 30 MBit und mehr kann das fast nicht mehr von einer typischen DSL Leitung stammen. Man muss aber auch dazu sagen, dass es eine Kleinigkeit ist, einen gringen Upstream an Maildaten durch unzählige Empfänger einen sehr hohen Out Traffik zu verursachen.)
Zusätzlich, sofern es die Logs her geben, prüfen wer (IP) unter dem Account eingeliefert hat.

Dein "Kunde" kommt vermutlich nicht aus dem Kosovo.

Also entweder Spyware beim Kunden oder Brute Force Attacke, oder schlimmer...
 
Last edited by a moderator:
Nichts gegen dich aber diese Kleinigkeit ist Dir wohl entgangen.
Nein, natürlich nicht gegen mich... :D
Und nein, ist mir nicht entgangen. Aber meiner Meinung nach auch nicht wesentlich für das eigentliche Problem.
Ein Reboot eines VServers ist nichts wirklich Ungewöhnliches. Neben den oben genannten Gründen, kann es der Kernel selbst ausgelöst haben oder auch das ganze Hostsystem wurde neu gebootet. Bei einem SuSE 10.3 ist das Hostsystem wahrscheinlich genauso alt und kann die VMs für einen Reboot nicht in einen Suspend-Modus legen. Auch ein anbieterseitiges Monitoring wäre eine Erklärung.

Zum hohen Traffik:
Große Frage: Incoming oder Outgoing?
Hält der Traffik noch an oder ist er abgeflacht?
Informationen die hier nicht erwähnt sind, auf die Du aber Deine Argumentation baust. :confused:

Mögliche Erklärung:
Nach einem Reboot werden alle auf Halde liegenden Emails neu versendet.
Es wird zwar nirgends explizit genannt wieviel Mails in der Queue sind/waren, aber das kann eine ganze Menge an Outgoing-Traffik erzeugen.

Fahrlässig ist es einem solchen Benutzer halblebig zu helfen und Ihn weiterhin mit einem offen Scheunentor im Netz zu lassen.
Sehe ich anders. Denn ein offenes Scheunentor ist so ziemlich jeder Server. Allein schon durch den letztlich aufgetauchten Kernel-Bug der alle 2.4er und 2.6er Kernels betrifft.

Denk mal ganz scharf drüber nach, ob ein herunterfahren des Sendmails an der Stelle wirklich ausreichend ist.
Was zu überprüfen wäre...
Dazu braucht man nicht "scharf" nachdenken. Ein einfaches "Mitdenken" oder gar "Lösungsorientiertes Denken" halte ich für angebrachter.

Aber dennoch geht es in erster Linie hier im Forum den Usern zu helfen statt sie zu beschimpfen.

huschi.
 
Die Erfahrung hat (sicherlich auch schon Dir) gezeigt, dass jeder sein eigenes Empfinden hat, ab wann Formulierungen "provozierend", "Kompetenzen aberkennend" oder "beleidigend" sind.
Eins ist jedenfalls sicher: Wie hier teilweise mit lukelukeluke umgegangen wurde ist nicht die "feine Englische Art".

huschi.
 
Eins ist jedenfalls sicher: Wie hier teilweise mit lukelukeluke umgegangen wurde ist nicht die "feine Englische Art".
Komm mal wieder runter! Wir bewegen uns hier in einem technischen Bereich, da gibt es kein Gruppenkuscheln und die "feine Englische Art" wurde der Zielgruppe entsprechend eingehalten.
Wenn Du Weichspülgefasel und rose Wattebäuschchen haben willst, dann suche Dir nicht-technische Bereiche...
 
Eins ist jedenfalls sicher: Wie hier teilweise mit lukelukeluke umgegangen wurde ist nicht die "feine Englische Art".

Du kennst ja die "Sandbox" um das ggf. näher zu betrachten.
Dann kannst Du etwaige Formulierungen ja mal dazu und dort nennen.
 
@Joe:
Für das interne Protokoll:
Diese Äußerung empfinde ich z.B. provozierend, erniedrigend und fast schon beleidigend.
Und genau dieser Ton ist es, den wir hier im SSF nicht wollen und weshalb ich überwiegend das RF meide.

Und ich brauch nicht "runter kommen". Denn ich stehe mit beiden Beinen auf dem Boden und kann daher die Fakten sachlich betrachten ohne auf irgendwelchen ungenannten, mysteriösen Lücken wegen alter Software rumzustampfen. Das Stichwort "veraltete Versionen" vernebelt offenbar einige Sinne.

Denn Fakt ist: Bisher gibt es keine Hinweise darauf, dass der Server wirklich gehackt wurde.
Aktuell sieht es eher nach einem gehijakten Mailbox-Account aus.
Die Fakten deuten dies bereits seit Beitrag #3 an.
Inzwischen sind wir wegen dem überflüssigen Gefasel bereits bei 32 Beiträgen.
Das sind meiner Meinung nach mind. 20 zu viel. Es stehen also 20 Postings einem wirklichen Lösungsansatz im Wege.
Und das ist das Faktum, wegen dem ich mich hier im Thread eingeschaltet habe.
Und schon fühlte sich der erste RF-User hier auf die Füße getreten und beginnt (mal wieder) eine unnötige Diskussion... :cool:

huschi.
 
Um zum technischen zurückzukommen :) :

Der Sendmail ist nun seit 5 Stunden sauber seid ich die fraglichen Mailboxen deaktiviert habe und es ist wohl wirklich nicht aufgrund von Software-Sicherheitslücken passiert sondern der Benutzer dieser Mailboxen hat offensichtlich ein Virus (bin ich am abklären). Dies hätte aber auch einem Server mit völlig aktuellen Softwarepaketen passieren können.

Der erhöhte Traffic war sowohl ein- als auch ausgehend. Kann mir schon vorstellen das dieser vom Abarbeiten der BCC-Listen stammt, resp. Kommunikation mit vielen anderen Mailservern auf einmal. Hab noch die aktuellen Graphen angehängt (Monatsansicht zum Vergleich mit der "Normalität", resp. dem Backup das regelmässig raus geht.)
 

Attachments

  • network-day.png
    network-day.png
    2 KB · Views: 104
  • network-month.png
    network-month.png
    1.9 KB · Views: 106
Und schon fühlte sich der erste RF-User hier auf die Füße getreten und beginnt (mal wieder) eine unnötige Diskussion... :cool:

Du kennst ja die "Sandbox" um das ggf. näher zu betrachten.
Du hättest also die Diskussion durchaus woanders weiter führen können.
Hätte man viel Post sparen können und zum gunsten des Hilfesuchenden, darf dieses Post auch gern wieder entfernt werden...
 
So, letzter Off-Topic von mir in diesem Thread:
Huschi, warst Du schonmal in Linux-Newsgroups unterwegs? Solltest Du mal tun, dann weisst Du, was unfreundlich und beleidigend ist. Dagegen war und ist hier wirklich Alles noch hab-dich-lieb-Geblubber.
Ansonsten können wir das auch wieder Intern klären.

/me EOD
 
Um zum technischen zurückzukommen :) :


Konntest Du heraus finden, was zu dem Neustart geführt hat?
BTW: Wenn das neue System aufgesetzt ist, erkläre Ich dir auch, wie Du Änderungen zuverlässig ermitteln und auswerten kannst, so dass Du in einem "anderem" unklaren Fall binnen weniger "Minuten"* Gewissheit hast, ob das System kompromitiert wurde oder nicht.

*Hängt von der Datenmenge ab.
 
Last edited by a moderator:
Achja abhängig vom MTA kann man die Anzahl der BCC, CC etc. empfänger limitieren. Das dürfte den "Schaden" durch einen "Angreifer" erstmal geringer halten. Zumindest macht es sein vorgehen nicht ganz so leicht und entlastet Dein Mailsystem.

Sofern möglich (aus Kundensicht) kann man auch die Anzahl, zu versendender Mails / Account und Zeit etc. limitieren.
Ob das jeder MTA untersützt weiss ich nicht.
Das wäre zumindest mal eine Anfang einen potentiellen Schaden geringer zu halten.

-> Man sollte allerdings dann auch sein System genauer im auge behalten weil solche Spamaktionen dann auch nicht mehr so offensichtlich auffallen.

Hattest Du die Gelegenheit eine der Mails im Spoolordner zu besorgen und zu prüfen, was da verschickt wurde?
 
BTW: Wenn das neue System aufgesetzt ist, erkläre Ich dir auch, wie Du Änderungen zuverlässig ermitteln und auswerten kannst, so dass Du in einem "anderem" unklaren Fall binnen weniger "Minuten"* Gewissheit hast, ob das System kompromitiert wurde oder nicht.

*Hängt von der Datenmenge ab.

Kannst Du das bitte schon erklären, bevor er sein System neu installiert hat? Oder zumindest ein Stichwort nennen?
 
md5sum über alle Dateien.

Das Ergebnis extern speichern.
Vorzugsweise erstellt man die Prüfsumme mit dem Rescue System des Providers.
Den Vorgang wiederholt man regelmässig und wertet die Änderungen aus.
Die Daten extern vorhalten.

Im Falle eines Falles, muss man sich ggf. antichronologisch Änderungen verfolgen.
Generell kann man aber damit schon schnell abschätzen ob typische Binaries ausgetauscht wurden und ob das mit Deinem Einverständis passiert ist.

Ein passendes Script hat keine 10 Zeilen.
 
md5sum über alle Dateien.

Das Ergebnis extern speichern.
Vorzugsweise erstellt man die Prüfsumme mit dem Rescue System des Providers.
Den Vorgang wiederholt man regelmässig und wertet die Änderungen aus.
Die Daten extern vorhalten.

Okay, hab mir schon sowas gedacht. ;) Dankeschön!

Wieso erstellt man das im Rescue-System des Providers? Nur damit man es von einem garantiert "sauberen" (vertrauenswürdigen) System macht?
Ich frage, weil es sich doch dann eher anbieten würde, das Ganze automatisiert (nachts) von einem Zweitsystem zu erledigen und so eine Downtime (noch dazu wg. manueller Arbeit zu Bürozeiten!) zu vermeiden.
 
Back
Top