Wahrscheinlich entführten Spammer meinen VPS- blacklisted

webass

webass

New Member
Hi,
ich habe einige Bouncebacks erhalten. Vor einer Woche kam der erste beim Versand einer Email an eine freenet-adresse.
Heute kam ein detaillierterer Bericht von einer anderen Adresse.
Daraufhin habe ich bei Spamhaus mal die Listen gecheckt und meine IP ist bereits bei 7 oder 8 DNSBL (oder auch RBL, k.A.) eingetragen.
Dann hab ich meinen Provider webtropia angehauen, die mir auch sofort meine Befürchtung bestätigten und mir von ihrer Abuse- Abteilung Auskunft gaben.
So, jetzt sitze ich auf einem Haufen Abuse- Meldungen und der Provider hat mich dringend angehalten das Problem zu lösen.
Leichter gesagt als getan, wo ich von Emailservern grad keine Ahnung habe.
Es könnten aber auch Scripte wie Joomla oder Wordpress, durch das Sendmail oder php- mail (oder was auch immer), verantwortlich sein.
Der Support meinte, ich sollte schnellstmöglich nach einer Sicherung neuinstallieren und den Backup, erst nach Bereinigung des Problems in den gesicherten Daten, wieder einspielen.
Oder, wenn es geht, und falls es der Fall ist, die befallene Anwendung löschen und neu- installieren.
Wenn ich das so aus dem Handgelenk schütteln könnte, hätte ich ja nicht beim Support gefragt oder würde hier schreiben, nicht. ;)
Also, ich steh aufm Schlauch.

Was ich hier schon mal zu einem "kompromittierten" Server gefunden habe, als erste Massnahme so zu sagen, hab ich mal durchgeführt:
Code: 
 ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.1  0.0   1984   688 ?        Ss   12:30   0:35 init [2]
root      1115  0.0  1.4  33504 30868 ?        Ss   12:39   0:01 /usr/sbin/spamd
confixx   1116  0.0  1.9  44264 40332 ?        S    12:39   0:11 spamd child
confixx   1117  0.0  1.3  33504 29332 ?        S    12:39   0:00 spamd child
root      1859  0.0  0.0   8620  1996 ?        Ss   12:53   0:13 sendmail: MTA:
root      4059  0.0  0.0   1696   592 ?        Ss   12:31   0:02 /sbin/syslogd
root      4084  0.0  0.0   5276  1036 ?        Ss   12:31   0:00 /usr/sbin/sshd
root      5155  0.0  0.0   2700  1308 ?        S    12:31   0:00 /bin/sh /usr/bi
mysql     5214  0.1  2.8 165792 60804 ?        Sl   12:31   0:34 /usr/sbin/mysql
root      5216  0.0  0.0   1632   536 ?        S    12:31   0:00 logger -p daemo
nobody    5308  0.0  0.0   2440  1080 ?        S    12:31   0:00 /usr/bin/memcac
root      5342  0.0  0.0   8452  1268 ?        Ss   12:31   0:00 /usr/sbin/sasla
root      5343  0.0  0.0   8452  1200 ?        S    12:31   0:00 /usr/sbin/sasla
root      5352  0.0  0.0   2356   880 ?        Ss   12:31   0:00 /usr/sbin/xinet
root      5408  0.0  0.0   2004   640 ?        Ss   12:31   0:03 /usr/sbin/dovec
root      5413  0.0  0.1   9420  2320 ?        S    12:31   0:03 dovecot-auth
nobody    5422  0.0  0.0   2856  1004 ?        Ss   12:31   0:07 proftpd: (accep
daemon    5425  0.0  0.0   1916   424 ?        Ss   12:31   0:00 /usr/sbin/atd
root      5440  0.0  0.0   2040   872 ?        Ss   12:31   0:03 /usr/sbin/cron
dovecot   5454  0.0  0.0   3656  1932 ?        S    12:31   0:00 pop3-login
dovecot   5455  0.0  0.0   3656  1996 ?        S    12:31   0:02 pop3-login
dovecot   5456  0.0  0.0   3508  1616 ?        S    12:31   0:00 imap-login
dovecot   5457  0.0  0.0   3508  1616 ?        S    12:31   0:00 imap-login
root      5460  0.0  0.7 297408 14952 ?        Ss   12:31   0:07 /usr/sbin/apach
root      5508  0.0  0.2   6576  4704 ?        Ss   12:31   0:00 /usr/sbin/munin
root      5556  0.0  0.0  25044  1436 ?        Sl   12:31   0:00 /usr/sbin/monit
root     25890  0.0  0.2   9284  4412 ?        S    17:13   0:00 sendmail: MTA:
root     26334  0.0  0.1   8988  4096 ?        S    17:23   0:00 sendmail: MTA:
root     27766  0.0  0.1   8988  4096 ?        S    17:33   0:00 sendmail: MTA:
www-data 27931  0.3  3.9 307348 83720 ?        S    17:35   0:01 /usr/sbin/apach
root     28186  0.0  0.1   8668  2568 ?        S    17:43   0:00 sendmail: MTA:
root     28194  0.1  0.1   8020  2676 ?        Ss   17:44   0:00 sshd: root@pts/
www-data 28196  0.0  0.4 297672  8904 ?        S    17:44   0:00 /usr/sbin/apach
www-data 28197  0.0  0.4 297672  8916 ?        S    17:44   0:00 /usr/sbin/apach
root     28199  0.0  0.0   2828  1556 pts/0    Ss   17:44   0:00 -bash
www-data 28203  0.0  0.4 297672  8884 ?        S    17:44   0:00 /usr/sbin/apach
root     28204  0.0  0.0   2300   904 pts/0    R+   17:44   0:00 ps aux
und
Code: 
 netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode       PID/Program name
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      0          343460177   1859/sendmail: MTA:
tcp        0      0 ME.INE.SER.VERIP:2812      0.0.0.0:*               LISTEN      0          335483907   5556/monit
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      107        335478239   5214/mysqld
tcp        0      0 0.0.0.0:587             0.0.0.0:*               LISTEN      0          343460178   1859/sendmail: MTA:
tcp        0      0 127.0.0.1:11211         0.0.0.0:*               LISTEN      0          335480312   5308/memcached
tcp        0      0 0.0.0.0:110             0.0.0.0:*               LISTEN      0          335482367   5408/dovecot
tcp        0      0 127.0.0.1:783           0.0.0.0:*               LISTEN      0          335767319   1115/spamd.pid
tcp        0      0 0.0.0.0:143             0.0.0.0:*               LISTEN      0          335482366   5408/dovecot
tcp        0      0 ME.INE.SER.VERIP:4949      0.0.0.0:*               LISTEN      0          335483677   5508/munin-node
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          335477834   4084/sshd
tcp6       0      0 :::80                   :::*                    LISTEN      0          335482863   5460/apache2
tcp6       0      0 :::113                  :::*                    LISTEN      0          335480909   5352/xinetd
tcp6       0      0 :::21                   :::*                    LISTEN      65534      335482537   5422/proftpd: (acce
tcp6       0      0 :::22                   :::*                    LISTEN      0          335477832   4084/sshd
udp6       0      0 :::517                  :::*                                0          335480907   5352/xinetd
udp6       0      0 :::518                  :::*                                0          335480908   5352/xinetd

Hat jemand netterweise einen Tipp?
Danke. Andre
 
Also, man kann von einem sendmail problem ausgehen.

Ich würde hier mal vorübergehend den php info hinlegen, die URL änder ich dann später wieder --- Kann ich hier gefahrlos eine info-php veröffentlichen?
Magst du mal gucken?


Was ich jetzt schon sehr sehr krass finde und nicht wirklcih verstehe:
sendmail benutzt den Pfad von meinem alten VPS!

da steht einfach der alte web-user vom alten VPS drin.
Seltsam? Ja, sehr.
 
Versuche doch erstmal zu ermitteln, wie die Mails reinkommen. Mit dem Kommando mailq siehst du die Queue. Da suchst du dir mal ein oder zwei Problemfälle raus. Die erste Spalte der Ausgabe ist die Queue-ID (die sieht z.B. so aus p53GUUqL015707). Damit kannst du in den Logfiles normalerweise den Weg der Mail sehen.

Per grep p53GUUqL015707 /var/log/mail.* sollte da was rauskommen. Vom zeitlich ältesten Eintrag ist der Eintrag relay= relevant. Bei localhost wird die Mail auf deinem Server erzeugt und du kannst die üblichen Verdächtigen (PHP, ...) durchgehen. Ansonsten kommt die Mail von einem anderen Server und du hast entweder ein offenes Relay oder da hat jemand Accountdaten, um sich zu authentifizieren.
 
Falls dein Server outgoing Port 25 fuer PHP/CGI offen hat kannst du den Header nicht vertrauen da oftmals direkt mittels fsockopen oder Alternative die Emails rausgeschickt werden.
Ein Hinweis darauf ist dass die Emails mit dieser Log-ID nicht existieren oder an einen komplett anderen Adressenten gingen respektiv die Log-ID auf deinem Host komplett fehlt.
 
Problem Gelöst.
Mit Hilfe von TheBusfreak konnte der Spammer identifziert werden, das Script wurde vom Server genommen und auf allen Webs die CGI/ Perl - Fähigkeit abgestellt.
Ich wüsste auch gar kein Beispiel, wofür ich CGI /Perl oder auch die Standard CGI Skripte brauchen würde, da alle Webseiten auf PHP oder OpenSource CMS laufen.

Aber da sieht man mal wieder was passieren kann, wenn man:
A) Veraltete CMS's auf dem Server frei über URL erreichbar liegen hat (als Demos zum Beispiel oder Portfolio), diese sind immer dringend upzudaten oder von aussen unerreichbar zu stellen oder noch besser gar nicht drauf rum liegen lassen.
B) Funktionen der Serververwaltungssoftware installiert und aktiv hat, die man eigentlich nicht braucht.
C) Man selber keine Ahnung von den ganzen Dingen um einen eignen Server herum hat, sodass man bei einem soclhen Vorkommnis völlig auf dem Schlauch steht, da echtes Fach-Handwerk gefragt ist, um das PRoblem zu lösen.

Ein VPS ist halt wie ein Root- Server, das merkt man in so einer Situation erneut.

Vielen Vielen Dank an TheBusFreak, da er die Situation trotz anderer Widrigkeiten nach einem Tag im Griff hatte.
Denn zum Beispiel lief der Sendmail-Wrapper nicht wie er sollte, er hat die infizierten Confixx- Web- User aber dennoch ausfindig gemacht.

Beim gemeinsamen Durchstöbern des VPS ist dann auch noch etwas Seltsames aufgefallen:
Webtropia hat den Container mit einem Template aufgesetzt, dass einmal mod_php (php5) installiert hat und auf der anderen Seite läuft gleichzeitig mod_suexec, das aber ohne mod_fcgid daher kommt.
Scheinen wohl gegensätzliche Konzepte verfolgt zu werden.
Das Vorgehen scheint, wenn ich seine Erklärung richtig verstanden habe, unsinnig zu sein und das Template ist somit ebenfalls Unsinn.
Naja, jetzt werde ich mich erstmal versuchen wieder zu whitelisten.
Wurde ja noch relativ frühzeitig beseitigt das Problem.
Hoffe, dass jetzt keiner mehr einen Eingang findet, bzw. sucht.

Ciao.
Andre
 
Last edited by a moderator:
d4f said:
Falls dein Server outgoing Port 25 fuer PHP/CGI offen hat kannst du den Header nicht vertrauen da oftmals direkt mittels fsockopen oder Alternative die Emails rausgeschickt werden.
Ein Hinweis darauf ist dass die Emails mit dieser Log-ID nicht existieren oder an einen komplett anderen Adressenten gingen respektiv die Log-ID auf deinem Host komplett fehlt.
Click to expand...
Hi, danke auch für den Tip.

Ich habe mal mit nmap gescannt, so: nmap -PS ip.adre.sse
und die Ports hier sind "nur" offen:
Code: 
Not shown: 1707 closed ports
PORT    STATE SERVICE
21/tcp  open  ftp
22/tcp  open  ssh
25/tcp  open  smtp
53/tcp  open  domain
80/tcp  open  http
110/tcp open  pop3
143/tcp open  imap
587/tcp open  submission
Ist das soweit OKAY?
 
Ein VPS ist halt wie ein Root- Server, das merkt man in so einer Situation erneut.
Click to expand...
No kidding... Ein VPS ist ein Root-Server, oder mit welchem Benutzer loggst du dich ein?

Beachte dass nicht nur CGI sondern auch PHP zum Spammen missbraucht werden kann, aber da PHP eine kurze Default-Lebenszeit hat die Spams meist nur sporadisch rausgehen. Zu erwarten dass das Problem komplett geloest ist wenn mod_cgi abgeschaltet ist, ist Irrglauben. Absicherung mit (funktionierenden) sendmail-Wrapper und Iptables-basierender Port-Sperre ist weiterhin Pflicht.

Um zu kontrollieren ob _ausgehend_ Port 25 offen ist; in meinem Blog hier auf SSF habe ich in der Kategorie Mailserver einen entsprechenden Eintrag welcher auch ein PHP-basierendes Test-Skript beinhaltet.
 
Das war auf VPS= Billig, Root-Server gleich teurer bezogen.
Viele vergessen das.

Und darauf, dass ein Root- Server bei Hostern als solcher angeboten wird und das dann der eigene Platz ist und der VPS bei den Hostern eben als VPS angeboten wird (und nicht als ROOT).
Ich denke, dass es den einen odere anderen gibt der so ein Ding betreibt, und den Unterschied in der Angebotssprache nicht macht, dass ein VPS eben ein virtualisierter Root- Server mit Ressourcenteilung ist und ein Root eben für einen alleine da ist.

Nun gut.
Iptables wollte ich schon längst mal angehen.
Das ist dann also jetzt die richtige Zeit.
 
Dein Kommentar "Ein VPS ist halt wie ein Root- Server, das merkt man in so einer Situation erneut." sowie mehrere andere ebenfalls sehr eindeutige Bemerkungen anderer die ins Fettnaepfchen getreten sind lassen nur eins schliessen; dass die Betreiber einfach nicht realisieren dass beides genau gleich vom Arbeitsaufwand und Risiko her ist.
Korrekt ist uebrigens der Begriff "Rootserver" in diesem Kontext auch nicht, aber "Superuser-Server" klingt einfach **** ;)

Iptables wollte ich schon längst mal angehen.
Click to expand...
Hier wirst du einen der wenigen Unterschiede zwischen isolierten Container und paravirtualisierten/hardware Server entdecken; viele Regeln werden schlichtwegs nicht funktionieren, linux-vserver laesst sogar gar keine Iptables-Regeln im Container zu.
 
You must log in or register to reply here.
Back
Top