1&1 RootServer hat "seltsame" Log Einträge

[paul_kuhn]

Hallo liebe Gemeinde,

Vor nicht allzu langer Zeit wurde unser in die Jahre gekommener RootServer beim grossen Anbieter 1und1 trotz iptables-Firewall und RootKit Checker gehacked.
Dieser hatte seinerzeit noch SuSE 9.1 an Bord. Bekanntlich gibt es ja keine weiteren Hotfixes für diese 2.4er Kernel System mehr.

Kurzum: es erfolgte ein Upgrade über eine sog. "Reinitialisierung" auf SuSE 10.1 mit Plesk 8.x

wir sind unlängst zwei "Phänomenen" auf der Spur...

Seitdem tanzen wir Samba (nein, nicht SMB ;-)

- als erstes Phänomen lief ständig das /dev/hda6 voll (5GB) in /var/lib/psa/dumps/1/1/; erstaunlicher Weise mit riesigen Dateien die laut crontab -L alle 30min laufen und namentlich alle mit katja*.datum beginnen

- doch das wirklich interessantere Zweite Phänomen ist: alle x Uhr 30 wird eine Mail an katja.f*******n@1und1.de übermittelt mit ominösen Inhalten (Info aus /var/log/messages und mail)

Nach einer intensiven Systemanalyse ist KEIN Script oder MySQL Einträg im Plesk zu finden, was dieses anzustossen vermag.
Daher die Vermutung: hart verdrahtet oder ins aktuelle 2.6er Kernel mit rein kompiliert...

1und1 hält sich übrigens äußerst geschlossen zur genannten Thematik...

Nun unsere Frage/Bitte:
Gibt es RootServer Betreiber unter Euch die Ihr ebenfalls bei 1und1 gehostetes System was idealerweise auch mit SuSE 10.1 läuft, auf diese /var/log/messages einträge überprüfen können?!


Vielen Dank im Voraus.

mit nettem Gruß,
Paule

[flo]

... trotz iptables-Firewall und RootKit Checker ...
... SuSE 9.1 ... keine weiteren Hotfixes für diese 2.4er Kernel System ...

iptables-Firewall? Wenn Du weißt, wovor die schützen soll, hast Du für Dich eine sinnvolle Anwendung, wenn nicht, dann ist da auch kein Schutz da.

SuSE 9.1 wird nicht mehr gepflegt, das heißt aber nicht, daß man den Rechner deswegen so im Netz laufen muß - wenn Dienste upgegradet werden sollen, kann man dies auch so tun.

The latest 2.4 version of the Linux kernel is: 2.4.35 2007-07-26 22:34

So alt ist das gar nicht - SuSE 9.1 hat nichts mit dem verwendeten Kernel zu tun.

Zurück zur Werbung: Auch SuSE 10 hat ungepatcht Lücken und ist nicht mehr aktuell, von Plesk mal ganz angefangen - Du wirst um den reinit nicht herumkommen, wie sich das andeutet.

[paul_kuhn]

Moin flo,

zunächst vielen Dank für Deine prompte Antwort!

ich vermute allerdings ich habe mich nicht klar ausgedrückt und somit mussest Du mich zwangsläufig missverstehen:

Zurück zur Werbung: Auch SuSE 10 hat ungepatcht Lücken und ist nicht mehr aktuell, von Plesk mal ganz angefangen - Du wirst um den reinit nicht herumkommen, wie sich das andeutet.

Der SuSE 10.1 Reinit ist ja bereits gelaufen; nicht zuletzt wegen einer "Unterlassungserklärung" die dem Kunden von 1und1 in solchen Fällen aufoptruiert wird... somit ist der SuSE 9.1 RootServer eh Geschichte...

Die aufgeführten Phänomene beziehen sich also nur auf das nagelneue, jungfräuliche und zudem durch YOU auf den aktuellen Stand gebrachte SuSE 10.1 System das durch 1und1 über den Re-Init neu installiert (geimaged ?!) wurde.

Somit sind wir auf der Suche nach RootServer Admins die ähnliche Feststellungen machen könnten/werden wie oben beschrieben (Thema: katja).

Mit nettem Gruß,
Paule

[flo]

Daß der Kernel mysqldumps macht und Mails verschickt ist wohl doch eher unwahrscheinlich.

was kriegst Du denn raus, wenn Du nach der Mailadresse mal über die komplette Platte grep'st und nach und nach die schon bekannten Files (mail.*, psa-dumps) ausschließt?

Hast Du einen User, der katja heißt, der evtl. einen cron-Eitnrag hat?

[Joe User]

Da hat 1&1 offentsichtlich das falsche Image released. Support informieren und auf das neue Image warten...

[paul_kuhn]

Hey da nochmals,

Daß der Kernel mysqldumps macht und Mails verschickt ist wohl doch eher unwahrscheinlich.

was kriegst Du denn raus, wenn Du nach der Mailadresse mal über die komplette Platte grep'st und nach und nach die schon bekannten Files (mail.*, psa-dumps) ausschließt?

Hast Du einen User, der katja heißt, der evtl. einen cron-Eitnrag hat?

somit mal die reinen Fakten zum besagten RootServer:

uname -a liefert:
Linux 2.6.16.33-061227b #1 SMP Wed Dec 27 11:49:29 CET 2006 i686 i686 i386 GNU/Linux
cat /etc/issue liefert:
Welcome to SUSE Linux 10.1 (i586) - Kernel r (l).
in der /etc/shadow ist keine Benutzereintrag zu finden, der verdächtig erscheint... ich denke das wäre auch zu einfach und wir hätten dies im Zweifel auch schon festgestellt

unser "Mega-Grep" schaut so aus (shell script):

#!/bin/bash
for i in $(find)
do
grep -n $1 $i 2> /dev/null && echo -e "Gefunden in Datei $i n"
done

... und liefert ab / bis in alle Verzeichnistiefen nur "katja" aus den bekannten Log Files zurück; daher auch die "hard-wired Vermutung"...

MnG,
Paule

[paul_kuhn]

Hey Joe,

(Jimmy H. lässt Dich übrigens grüssen ;-) )

Da hat 1&1 offentsichtlich das falsche Image released. Support informieren und auf das neue Image warten...

1und1 IST informiert und läßt uns unverrichteter Dinge hängen bzw. reagiert auf mehrfache Nachfragen nicht (mehr)...

Von daher die Suche nach "Leidensgenossen" die auch bei 1und1 auf 10.1 fahren...

MnG,
Paule

[bernsteinkater]

- als erstes Phänomen lief ständig das /dev/hda6 voll (5GB) in /var/lib/psa/dumps/1/1/; erstaunlicher Weise mit riesigen Dateien die laut crontab -L alle 30min laufen und namentlich alle mit katja*.datum beginnen

Das sind die Plesk-Backups. Du hast entweder eine Domain oder einen Client in Plesk angelegt und entsprechend definiert, dass dieser gebackupt werden soll.

Die Backups werden ueber das "backupmng"-Tool von Plesk durchgefuehrt und es wird alle 30 Minuten gecheckt ob ein Backup geplant ist.

Wenn Plesk wirklich alle 30 Minuten dasselbe Backup versucht, dann liegt dies entweder daran, dass die Platte jedesmal vollaeuft und Plesk daher jedesmal den Job neustartet, da der nicht erfolgreich beendet wurde oder ein Backupjob hat sich aufgehangen, so dass kein "OK" in die Plesk-DB zurueckgegeben wird.

- doch das wirklich interessantere Zweite Phänomen ist: alle x Uhr 30 wird eine Mail an katja.f*******n@1und1.de übermittelt mit ominösen Inhalten (Info aus /var/log/messages und mail)

Die Email-Adresse ist mutmasslich die des Clients, die Du in Plesk angelegt hast und informiert diesen ggf. ueber das nicht-erfolgreiche Backup oder andere Dinge. Genau kann ich es Dir sagen wenn Du den Body der Mail postest.

1und1 hält sich übrigens äußerst geschlossen zur genannten Thematik...

Ist ja ein super Hoster... Ich kenne da einen der haette Dir innerhalb von wenigen Minuten sagen koennen worans liegt ;-)

[paul_kuhn]

Hallo bernsteinkater,

vielen Dank für Deine detaillierten Infos; wir werden Plesk bzgl. der selbst erstellten unbekannten ;-) Benutzer überprüfen...

1und1 hält sich übrigens äußerst geschlossen zur genannten Thematik...

Ist ja ein super Hoster... Ich kenne da einen der haette Dir innerhalb von wenigen Minuten sagen koennen worans liegt ;-)

Für Anregungen zum Wechsel zu einem Hosting Anbieter mit weit aus positiveren Erfahrungen als die Unseren wären wir ebenfalls äußerst dankbar (Achtung: Bordregeln = vergleichende Werbung etc.).

MnG,
Paule

[dtdesign]

Wer sagt eigentlich, dass die E-Mail die an "@1und1.de" versendet wird, auch tatsächlich jemals bei 1&1 ankommt? Bekanntlich gibt es genügend Methoden, einen DNS-Eintrag zu fälschen, nicht zuletzt die Bind9-Lücke.

Hast du die passwd komplett nach Einträgen gesucht und dann bei jedem User die Crontabs aufgerufen? Im Rescue-System mal gesucht? Wenn dein System tatsächlich kompromittiert ist, dann wirst du es nirgendwo finden.

Die Verallgemeinerung und Übertreibung von bernsteinkater kann ich nicht gut heißen. Auch wenn =2 nicht immer der schnellste ist, die Lösung die sie dir bieten sind meist sehr hilfreich (Ausnahmen bestätigen die Regeln).

Gruß
dtdesign

[paul_kuhn]

Hallo auch dtdesign,

Hast du die passwd komplett nach Einträgen gesucht und dann bei jedem User die Crontabs aufgerufen? Im Rescue-System mal gesucht? Wenn dein System tatsächlich kompromittiert ist, dann wirst du es nirgendwo finden.

Die Verallgemeinerung und Übertreibung von bernsteinkater kann ich nicht gut heißen. Auch wenn =2 nicht immer der schnellste ist, die Lösung die sie dir bieten sind meist sehr hilfreich (Ausnahmen bestätigen die Regeln).

Danke auch Dir für Deine Infos.

die crontabs jedes einzelnen Benutzers können/sollten wir natürlich noch gezielt überprüfen.

Was den Provider Support von =2 ;-) betrifft, haben wir natürlich keine grossen Vergleichsmöglichkeiten; dennoch können wir auf drei Jahre "Support" im Sinne von 1und1 zurückblicken der wenn er denn notwendig war wannimmer wir nicht mehr weiterkamen durchaus inkompetent und in unseren Augen somit mehr schlecht als recht war. Dies ist aber lediglich ein subjektiver Eindruck!


Aber zum Kern der Sache: wie gesagt - das System ist jungfräulich neu aufgesetzt = re-init; woher kommen also diese bereits vorhandenen Phänomene?!

MnG,
Paule

[paul_kuhn]

Auf der anderen seite macht auch der Ton die Musik.

Ich denke ich habe diesen Wink verstanden 8)

Danke euch allen fürs Feedback und die damit verbundenen Tipps.

[bernsteinkater]

Die Verallgemeinerung und Übertreibung von bernsteinkater kann ich nicht gut heißen.

Wollte keine Hosterdiskussion lostreten, sorry :)

@Paul_Kuhn:
Nur zum Verstaendnis: Nach dem Reinstall mit SUSE 10.1 habt Ihr _gar nichts_ in Plesk gemacht, keine Clients angelegt, keine Domains, kein (Plesk-)Backup eingespielt, etc?!

Wenn ja: Dann ist das Image von 1und1 wohl wirklich fehlerhaft.
Wenn nein: Du kannst so checken ob lokale Backups geplant und aktiv sind:

Code: Select all

mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa -e "select repository,active from BackupsScheduled;"

P.S.:

die crontabs jedes einzelnen Benutzers können/sollten wir natürlich noch gezielt überprüfen.

Kannst Du ganz fix mit

Code: Select all

cat /var/spool/cron/tabs/*

ueberpruefen.

[paul_kuhn]

@bernsteinkater:

mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa -e "select repository,active from BackupsScheduled;" liefert:

+------------+--------+
| repository | active |
+------------+--------+
| local | true |
+------------+--------+

cat /var/spool/cron/tabs/* liefert:

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (- installed on Wed Aug 8 16:51:31 2007)
# (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/cronBa6644 installed on Mon Jul 23 19:20:57 2007)
# (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.psa installed on Mon Jul 23 19:20:45 2007)
# (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.psa installed on Mon Jul 23 19:20:45 2007)
# (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.psa installed on Mon Jul 23 19:20:45 2007)
# (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/nicht-fuer-kunden/crontab installed on Mon Jul 23 17:15:48 2007)
# (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)
14 5 * * * /usr/local/psa/bin/mysqldump.sh >/dev/null 2>&1
7 4 * * * /usr/local/psa/admin/sbin/statistics >/dev/null 2>&1
30 * * * * /usr/local/psa/admin/sbin/backupmng >/dev/null 2>&1
17 7 * * * /usr/local/psa/admin/bin/php /usr/local/psa/admin/plib/report/autoreport.php --auto daily >/dev/null 2>&1
17 7 * * 1 /usr/local/psa/admin/bin/php /usr/local/psa/admin/plib/report/autoreport.php --auto weekly >/dev/null 2>&1
17 7 1 * * /usr/local/psa/admin/bin/php /usr/local/psa/admin/plib/report/autoreport.php --auto monthly >/dev/null 2>&1
19 4 * * * /usr/local/psa/bin/run-parts.sh /etc/psa/plesk-cron.daily
13 1 * * 7 /usr/local/psa/bin/run-parts.sh /etc/psa/plesk-cron.weekly
37 5 1 * * /usr/local/psa/bin/run-parts.sh /etc/psa/plesk-cron.monthly
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab-tmp-Xfxaq4J installed on Sun Mar 18 19:29:41 2007)
# (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)


@matzewe01:

der Server stand ca. 5 Tage still; bis zum Eingang der "UNterlassungserklärung" wurde dieser von =2 vom Netz genommen!

naja, 1und1 bietet halt den re-init im Moment nur mit SuSE 9.3 oder 10.1 an. das Upgrade würde auf eigene Verantwortung geschehen: schon getestet -> danach geht die serielle Konsole nicht mehr und Plesk 8.2 scheint tot zu sein...

Danke euch nochmals.

MnG,
Paule

[Roger Wilco]

der Server wurde aufgesetzt, stand 5 Tage rum und dann wurde der Server wegen DOS Attacken etc. vom Netz genommen?

So wie ich den OP verstanden habe, wurde die Reinitialisierung mit SuSE 10.1 erst danach vorgenommen.
Und ganz so schlimm ist der Einsatz von SuSE 10.1 sowie dem Providerimage sicherlich nicht. Immerhin wird beides noch supportet.

Ich denke, wie Joe User, dass auf der Kiste versehentlich ein Image installiert wurde, das in der Form sicherlich nicht an die Öffentlichkeit gelangen sollte. Ich würde die Kiste einfach nochmal reinitialisieren und falls das dann tatsächlich immer noch so sein sollte, eine kurze Mail an den Support schreiben oder dort anrufen.

[paul_kuhn]

So wie ich den OP verstanden habe, wurde die Reinitialisierung mit SuSE 10.1 erst danach vorgenommen.

Ich sollte evtl. noch an meinen nicht verständlichen Veranschaulichungen arbeiten... :roll:

Es war genau so wie Roger Wilco vermutet:
SuSE 9.1 wurde nach drei Jahren Laufzeit gehacked; Server für 5 Tage vom Netz; Re-Init mit SuSE 10.1 (dies zudem zweimal in Serie)

...eine kurze Mail an den Support schreiben oder dort anrufen.

... dazu muss ich jedoch wirklich nichts mehr hinzufügen, oder?! (siehe bitte Eröffnungsbeitrag; daher ja auch die Frage nach einer Provider Alternativ Empfehlung)

MnG,
Paule

[paul_kuhn]

Hallo nochmals,

Da hat 1&1 offentsichtlich das falsche Image released. Support informieren und auf das neue Image warten...

Nach einigen Stunden weiterer Recherche verhält es sich ganz genau so wie Joe User es anfangs bereits vermutete:

wir haben die besagten "katja*"Eeintrage und noch einiges mehr (!) in den Tiefen der Plesk 8.x Config aufdecken können. Diese wurde aller Vermutung nach aus der 1und1 "Spielwiese" als Kunden Image SuSE 10.1 mit Plesk 8.1 zur Verfügung gestellt.

Ergo: da unser System durch die besagten Phänomene für einige Tage teilweise nicht nutzbar war (hauptsächlich wegen des "Zumüllens" von /dev/hda6) werden wir dies aufgrund keiner Unterstützung durch 1und1 in diesem Thema zum Anlass nehmen, uns einen neuen RootServer Anbieter zu suchen...

Habt vielen Dank für die zahlreichen Infos! :)

MnG,
Paule

p.s.: der Support in diesem Forum hat wesentlich mehr Erfolg zu verbuchen!!
p.p.s.: und ich denke der Ton zur Musik war auch okay, oder?

[dtdesign]

..., uns einen neuen RootServer Anbieter zu suchen...

[rant]
Tja, mal wieder (Heul-)SuSE, mit Debian wäre dir das so nicht passiert *g*
[/rant]

[codc]

Ich weiss schon warum ich den Provider-Images nicht vertraue wenn ich das hier lese und mir die Arbeit mache das Ding sauber zu partionieren und aufzusetzen.
Meiner war vom Provider aus mit Suse ausgestattet und ich hätte das Ding so noch nicht mal als Desktop betrieben und geschweige denn als öffentlichen Server. Heute läuft Etch darauf.

[paul_kuhn]

Da hat 1&1 offentsichtlich das falsche Image released. Support informieren und auf das neue Image warten...

eat this (auf mehrfaches Nachfragen schrieb 1und1):

Sehr geehrter Herr Kuhn,

vielen Dank für Ihre Supportanfrage.

Nach längerer Klärung des Sachverhaltes ist aufgefallen, dass es sich bei dem von Ihnen beschriebenen Problem um ein Fehleinstellung in dem installierten Image handelt. Dieses wurde im aktuellen Image behoben, bitte Initialisieren Sie Ihren Server erneut.

Mit freundlichen Grüßen

1und1
Technischer Support

p.s.: wir haben ja sonst nichts zu tun - aber damit wären jegliche Zweifel endgültig ausgeräumt

[Joe User]

War an Hand der eMail-Adresse eindeutig zu verifizieren, da @1und1.de ausschliesslich 1&1-Intern genutzt wird ;)