Ebenso Spamangriff - wwww-data account ausgenutzt

[passbreak2001]

Hallo,

habe das gleiche Problem wie gigi66. Vermutlich auch die gleiche Hacker Crew. Ursache bei mir war ein veraltetes PHP Script (Wie bei ihm). Habe Postfix abgeschlatet bis das Problem geklärt ist.

Mein Problem aus dem ich nicht schlau werde: auch nach dem löschen des PHP Dokuments ging das Mailing nach einigen Stunden weiter. Habe sofort alle s offline geschickt. Während dem versenden von Massenmails wurde kein Webdokument angesprochen. Finde nicht heraus wie die die Mails verschicken

Merkwürdig ist das mail.log/mail.info & syslog die gleichen Einträge beeinhalten. Das versenden der Mails erfolgt über den www-data user von apache (aber ohne eine Webdatei anzusprechen?!?!!?).

Hier mal ein kurzer Auszug aus der Maillog:

Aug 18 21:14:54 vsxxx postfix/qmgr[27298]: B3FE5162BC: from=<www-data@vsxxx.vserver4free.de>, size=4293, nrcpt=1 (queue active)
Aug 18 21:14:54 vsxxx postfix/qmgr[27298]: E65F71A3FE: from=<www-data@vsxxx.vserver4free.de>, size=2773, nrcpt=1 (queue active)
Aug 18 21:14:54 vsxxx postfix/pickup[27297]: 9E1B522E77: uid=0 from=<root>
Aug 18 21:14:54 vsxxx postfix/cleanup[27403]: 9E1B522E77: message-id=<20060818160908.9E1B522E77@vvsxxx.vserver4free.de>
Aug 18 21:14:54 vsxxx postfix/cleanup[27408]: A1F2922E78: message-id=<20060818191454.A1F2922E78@vsxxx.vserver4free.de>
Aug 18 21:14:54 vsxxx postfix/qmgr[27298]: B76E1190B1: from=<www-data@vsxxx.vserver4free.de>, size=5293, nrcpt=1 (queue active)
Aug 18 21:14:54 vsxxx postfix/qmgr[27298]: E54DD1A67D: from=<www-data@vsxxx.vserver4free.de>, size=1140, nrcpt=1 (queue active)
Aug 18 21:14:54 vsxxx postfix/smtp[27393]: connect to pavo.pa.msu.edu[35.9.70.10]: No route to host (port 25)

Kann mir bitte einer Erklären was das hier soll:
(Access Log von Confixx selbst)

62.75.214.243 - - [13/Jun/2006:22:50:53 +0200] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 226 "-" "-"
81.169.176.15 - - [14/Jun/2006:01:43:24 +0200] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 226 "-" "-"
83.14.208.50 - - [14/Jun/2006:10:18:22 +0200] "SEARCH /\x90\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H\x04H
...
x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90
(so geht das seitenweise)
...


84.16.119.105 - - [28/Jun/2006:17:26:49 +0200] "GET / HTTP/1.0" 302 - "-" "-"
84.16.119.105 - - [28/Jun/2006:17:39:15 +0200] "GET / HTTP/1.0" 302 - "-" "-"
84.16.119.105 - - [28/Jun/2006:19:17:32 +0200] "GET / HTTP/1.0" 302 - "-" "-"
201.18.140.196 - - [28/Jun/2006:22:15:01 +0200] "POST http://www.alexander-hain.de/kontakt.php HTTP/1.1" 404 1277 "http://www.alexander-hain.de/" "-"
201.18.140.196 - - [28/Jun/2006:22:15:03 +0200] "POST http://www.alexander-hain.de/kontakt.php HTTP/1.1" 404 1277 "http://www.alexander-hain.de/" "-"
201.18.140.196 - - [28/Jun/2006:22:15:07 +0200] "POST http://www.mailshop.de/contact_us.php HTTP/1.1" 404 1259 "http://www.mailshop.de/" "-"
201.18.140.196 - - [28/Jun/2006:22:15:09 +0200] "POST http://online.mydpi.com.tw/contact_us.php?action=send&osCsid=94cdda63438f8842b9df50105ad41e86 HTTP/1.1" 404 1271 "http://online.mydpi.com.tw/" "-"
201.18.140.196 - - [28/Jun/2006:22:15:12 +0200] "POST http://www.Adar.cz/cs/zpracuj_dotaz.php HTTP/1.1" 404 1247 "http://www.Adar.cz/" "-"
201.18.140.196 - - [28/Jun/2006:22:15:17 +0200] "POST http://www.Adar.cz/cs/zpracuj_dotaz.php HTTP/1.1" 404 1247 "http://www.Adar.cz/" "-"
201.18.140.196 - - [28/Jun/2006:22:15:23 +0200] "POST http://www.kredietgids.com/tellafriend.php HTTP/1.1" 404 1271 "http://www.kredietgids.com/" "-"
201.18.140.196 - - [28/Jun/2006:22:15:26 +0200] "POST http://www.kredietgids.com/tellafriend.php HTTP/1.1" 404 1271 "http://www.kredietgids.com/" "-"
201.18.140.196 - - [28/Jun/2006:22:15:29 +0200] "POST http://oh-bebe.net/amailzing/amailzing.php HTTP/1.1" 404 1247 "http://oh-bebe.net/" "-"
201.18.140.196 - - [28/Jun/2006:22:15:32 +0200] "POST http://oh-bebe.net/amailzing/amailzing.php HTTP/1.1" 404 1247 "http://oh-bebe.net/"

Im unteren Teil werden lauter Adressen zu PHP Kontaktmailern angegeben. Was haben Die in der Accesslog zu suchen? Was bedeutet das Zahlenwirrwar oberhalb?

Kann ich irgendwie verhindern das über den www-data user Emails nach aussen verschickt werden? Wie kann ich darauf schliessen wie die Emails versendet werden, da ja kein Dokument auf dem Server dazu verwendet wird?

DANKE FÜR INTERESSE UND HILFE !!!

Problematisch ist für mich das der Anbieter auf den Vservern IPtables und IPchains kernelseitig ausgeschlossen haben.

 

[phrenicus]

Hallo,

der Server ist gehackt.
Das "Zahlenwirrwarr" hat eine Schwachstelle in einem PHP-Skript ausgenutzt und vermutlich einen Buffer Overflow erzeugt. Wenn Dein apache als root lief, sind die Angreifer jetzt root, wenn er als www-data lief, sind sie als www-data unterwegs.
Es kann sein, dass sie jetzt ein Shell-Account haben. Insofern muss zum Versenden von Mails keine Webseite aufgerufen werden.
Schau Dir mal mit netstat alle Netzwerkverbindungen an. Wenn die Angreifer root sind, kannst Du das allerdings vergessen, weil dann wohl bereits ein rootkit drauf ist und Du mit ls die Dateien der Angreifer nicht mehr siehst, und mit ps keine Prozesse der Angreifer und mit netstat keine Netzwerkvebindungen der Angreifer. In den Logs siehst Du dann auch nichts.
Ansonsten würde ich mal das Account des Users www-data überprüfen und den interaktiven Zugang sperren und alle Prozesse killen, die dieser User laufen hat.
Ansonsten insgesamt mal ein bisschen mehr Wert auf Sicherheit legen.

Gruß

 

[passbreak2001]

Total Gehackt glaube ich nicht

Hallo, danke für deine konstruktive Hilfe. Das der komplett gehackt wurde glaube ich nicht. Apache laüft mit user www-data. Das mit der Shell(script) glaube ich auch. Seitdem ich Postfix abgeschaltet habe versuchen die mit Bruteforce den Root account via ssh zu knacken. Das ist echt übel, den Port zu ändern bringt nichts, dauert nicht lange dann wissen die Ihn auch, IPs auschliessen (über sshdconfig) nützt auch nichts, die benutzen immer andere -vermutlich- Opferrechner um darauf zuzugreifen.

Hätte schon längst das gesamte Asiatische Netz ausgeschlossen wenn ich IPtable Befehle ausführen könnte, wird aber kernelseitig nicht unterstützt.

Für weitere Ideen bin ich dankbar. Das Handtuch schmeissen möchte ich nicht.

 

[mcas]

Hmm versuch erstmal deinen sshd so abzusichern, dass du dich nur noch mit einem public-key anmelden kannst. So können die Cracker schon nicht mehr mit bruteforce weiterkommen. Verbiete auf jeden Fall die direkte root Anmeldung (PermitRootLogin No). Guck mal nach ob du mit last siehst, ob der Benutzer www-data angemeldet ist. Hast du mal geguckt ob irgendwo ein neues Skript liegt mit owner www-data? Hast du den Rechner mal rebootet? Wenn du dann den apache abgeschaltet lässt hast du sie vll erstmal ausgesperrt. Desweitern könntest du versuchen den apache in einer chroot laufen zu lassen. Das mit der Firewall ist übel und ich wüsste im Moment nicht was dir da helfen könnte.
Ich hoffe ich konnte dir etwas helfen.

 

[phrenicus]

Hallo nochmal,

das ist tatsächlich der beste Weg, dass Du erstmal Schlüssel erzeugst und dann (wenn es funktioniert) den Passwort-Login abschaltest. Wenn Du dazu Fragen hast, frag. Ich erkläre es gerne, es sollte auch in diesem Fall schnell gehen.

Sollte das aus irgendeinem Grund unmöglich sein (weil Du von zu vielen unterschiedlichen Rechnern aus arneiten musst und den Private Key nicht mit Dir rumschleppen kannst), gibt es auch andere Möglichkeiten, die Bande auszusperren. Hier ist bei einem Server, auf den Du keinen physischen Zugriff hast, allerdings höchste Vorsicht geboten. sshdfilter beispielsweise ist da sehr extrem und sperrt Dich selbst eventuell stunden- oder tagelang aus, wenn Du das root-Passwort dreimal falsch eingibst. Wenn Du es fehlkonfigurierst, kann es auch sein, dass sshd gar nicht mehr läuft, was Deinem Ziel extrem abträglich wäre.

sshdfilter ist aber ansonsten ein ausgezeichnetes kleines Tool. Ich habs hier mal auf dem gateway installiert, weil mich die ständigen ssh-Brute-Force-Versuche nerven (nicht dass die was bringen würden).

Gruß

 

[Bâshgob]

Gehackte Systeme gehören grundsätzlich weg vom Netz[1]. Nach der Post-Mortem-Analyse und Beweissicherung neu aufsetzen.

[1] Gute Haftpflichtversicherung vorhanden? Dann lass weiterlaufen.

 

[passbreak2001]

Super Idee mit SSH. Danke. Nein ein Script gibt es nicht. Es war niemand fremdes auf dem Server. Devinitiv nicht. Es ist eine (so glaube ich fest) authentifizierungsschwachstelle in postfix. Es gibt auch kein offenes Relay; das Versenden ist bei den Pennern anscheinend auch nur mit dem www-data account möglich. DANKE!

 

[phrenicus]

Hallo,

ich würde dem Frieden noch nicht so ganz trauen. Beobachte die Maschine lieber noch eine ganze Weile ganz genau und miss mal den Traffic mit, der so rein und raus geht. Ich tendiere bei solchen Vorfällen eigentlich IMMER dazu, den Rechner neu aufzusetzen...
Wenn das also geht, mach es. Und überleg DIr genau, ob DU wirklich einen Vserver willst, der kein iptables unterstützt. Für mich wäre das ein klares Ausschlusskriterium.

Gruß

 

[theton]

Kann phrenicus hier nur zustimmen. Wobei ich nicht nur dazu tendieren wuerde, eine gehackte Kiste plattzumachen, sondern das eher als Grundregel ansehe. Nur so kann man ausschliessen, dass die nicht noch eine Hintertuer im System haben (LKM-Trojaner, per Elf-Injection eingeschleuster Code in Programmen usw.). Und einen Server ohne iptables wuerde ich prinzipiell nicht nutzen.

 

[sono]

Und einen Server ohne iptables wuerde ich prinzipiell nicht nutzen.

Es gibt Gigabyteweise Texte dazu warum iptables auf nem Server nichts bringen.
Das ist zwar umstritten ob nun, und wenn ja dann wie und was auch immer, aber in den meisten Fällen schützen Iptables auf dem Server dann doch nur so oder so verschlossenen Ports. Jeder Dienst der nicht erreichbar sein soll, sollte nicht auf nem Server laufen, und der Rest muss dann trotz iptables erreichbar sein. Fazit der Schutz durch Iptables ist wie der Schutz einer Mauer mit offener Tür.
Es ist sogar eher negativ da das vorhandensein von IPtables ein Pseudosicherheitsgefühl geben, die verwundbaren Punkte die Dienste aber weiter für jeden ereichbar sind und sein müssen.

Bei Netzwerkfirewalls ist das was anderes. Die machen dann mit richtiger Konfiguration doch wieder Sinn. Aber das ist ein anderes Thema.


Gruß Ich

 

[theton]

Es ist sogar eher negativ da das vorhandensein von IPtables ein Pseudosicherheitsgefühl geben, die verwundbaren Punkte die Dienste aber weiter für jeden ereichbar sind und sein müssen.

Dann erklaere mir doch bitte mal, wie man ohne iptables auf einem Server eine spezifische IP (z.B. eines Spammers) auf die schnelle sperren soll, wenn es mal notwendig wird. Die hosts.allow und hosts.deny greifen ja nunmal nicht bei allen Services. Weiterhin kann man iptables dazu nutzen die wahren Ports zu verschleiern (z.B. laeuft der SSH-Server wie gewohnt auf Port 22 aber per iptables wird er auf einen beliebigen anderen Port gelegt). Und man kann die iptables dazu nutzen bestimmte ICMP-Nachrichten auf Anfragen an einen bestimmten Port zurueckzugeben. Nicht zu vergessen, dass ein Server mit mehreren IPs ohne iptables einfach wesentlich umstaendlicher zu verwalten ist (Webserver auf IP 123.123.123.123, Mail auf 123.123.123.124, 2. Webserver auf 123.123.123.125 usw laesst sich am schnellsten ueber iptables hinbiegen).

 

[slasher]

Es gibt Gigabyteweise Texte dazu warum iptables auf nem Server nichts bringen.
Das ist zwar umstritten ob nun, und wenn ja dann wie und was auch immer, aber in den meisten Fällen schützen Iptables auf dem Server dann doch nur so oder so verschlossenen Ports. Jeder Dienst der nicht erreichbar sein soll, sollte nicht auf nem Server laufen, und der Rest muss dann trotz iptables erreichbar sein. Fazit der Schutz durch Iptables ist wie der Schutz einer Mauer mit offener Tür.
Es ist sogar eher negativ da das vorhandensein von IPtables ein Pseudosicherheitsgefühl geben, die verwundbaren Punkte die Dienste aber weiter für jeden ereichbar sind und sein müssen.

Bei Netzwerkfirewalls ist das was anderes. Die machen dann mit richtiger Konfiguration doch wieder Sinn. Aber das ist ein anderes Thema.


Gruß Ich

erschütternd :-). Viele Jahre der Erfahrung einfach hinweggespühlt mit deiner Behauptung.
Jemand, der keine Ahnung von sowas hat, denkt sich jetzt "toll, ohne Firewall reichts auch" und das ist bei diesen vielen Rootserverangeboten wirklich suboptimal, da meines Wissens nur Hosteurope seinen Mainstreamkunden die Option der Hardwarefirewall ala ASTARO und Konsorten anbietet, die aber auch erst einmal administriert werden möchte.

 

[phrenicus]

Hallo,

Es gibt Gigabyteweise Texte dazu warum iptables auf nem Server nichts bringen.
[...]
Es ist sogar eher negativ da das vorhandensein von IPtables ein Pseudosicherheitsgefühl geben,[...]

sono, ich fürchte, Du stehst mit dieser Meinung ziemlich alleine da. Wo steht geschrieben, dass man iptables nicht dazu nutzen sollte, den Server selbst zu schützen? Wer einen Server im Internet administriert, sollte ein Sicherheitskonzept für diesen Server haben, dessen Bestandteile unbedingt auch iptables umfassen. Dass Dienste, die nicht benötigt werden, nicht laufen dürfen (und am besten gar nicht erst installiert werden) versteht sich von selbst. Aber das zügige Aussperren von IPs und IP-Ranges (aus gegebenem Anlass) ist nunmal ohne iptables schwierig. Dass man (siehe thetons Antwort) von TCP/IP eine gewisse Ahnung haben sollte, setze ich dabei voraus, wenn man einen Internet-Server administriert. Mit steigender Komplexität werden iptables dabei unabdingbar.
Ist jedenfalls meine Erfahrung in jetzt sieben Jahren Linux-Administration.

Gruß