Zungangsdaten.txt auf managed (v)Server

Elradon

Member
Es ist schon lange her, dass ich einen Server mit Apache, SQl und dem ganzen Mailkrams selber administriert habe. Aufgrund der sich wiederholenden Mahnungen vor zu wenig Kenntnissen und dem doch hohen Aufwand, hatte ich mich dann irgendwann für managed Server entschieden, auch aus Bequemlichkeit. Ich muss sagen, dass ich soweit auch sehr zufrieden damit bin. Klar, auch wenn man so ein Produkt erwirbt, ist es in der Regel Massenmarkt und nicht sooo individuell, als wenn man seinen eigenen Administrator hat - was auch deutlich teurer wäre.

Jedenfalls bin ich beim Stöbern auf dem Server im Verzeichnis /root auf eine Zugangsdaten.txt gestoßen. Ich rechnete nicht damit, aber konnte sie dann doch tatsächlich öffnen. Neben den erstmaligen Logindaten für Confixx, gab es auch ein SQL Root und SQL Confixx Passwort - beide funktionierten und ich hatte Zugriff auf alle Datenbanken aller Kunden meines managed Servers. Das ist ja nun kein Problem. Allerdings hätte die Datei auch jeder andere Nutzer des Servers öffnen können. Da bei dem Produkt auch damit geworben wird, dass es für Agenturen, Reseller etc. verwendet werden kann und damit nach der Erwartung nicht nur persönliche Bekannte Zugriff haben, war ich etwas bestürzt und bin es nun, fast einen Monat später, immer noch. Das Problem ist zwar behoben, aber ich frage mich, ob so etwas überhaupt passieren darf. Ist es normal eine Datei mit Zugangsdaten auf dem Server zu speichern, unabhängig davon, ob sie nur vom Eigentümer oder der Gruppe gelesen werden kann? Ist das ein so grober Fehler, dass ich an der Sicherheit des gesamten Systems zweifeln sollte?
Ich habe vor geschätzt 6 Jahren schon mal einen CT Artikel zum Thema managed Server gelesen. Die Anbieter wurden soweit alle schlecht bewertet. Meint ihr, dass sich daran etwas geändert hat? Können solche Angebot überhaupt die gleiche Qualität wie selbst administrierte Server haben?
 
Ein managed Server von der Stange (meist als "managed Option" bezeichnet) kostet meist nur einen geringen Aufpreis gegenüber der "unmanaged" Variante. Dass man hier kein perfekt zugeschnittenes System erwarten kann, ist wohl klar.

Hier werden Einstellungen vorgenommen, die für die meisten passen und sich als halbwegs sicher herausgestellt haben, ohne die Funktionsweise von Standardprodukten nicht zu gefährden. Ab diese Punkt werden nur mehr Updates automatisiert eingespielt.

Wenn jetzt so eine Managed-Option im Monat 40 Euro kostet bspw, dann darfst du mit deinem Server vermutlich max. 1 Stunde Support verursachen, um noch gewinnbringend zu sein. So eine Stunde ist schnell rum.

In deinem Fall wurde vermutlich aus Bequemlichkeit eine solche Datei angelegt. Ich kenne keinen prof. Admin, der so etwas tun würde. Entweder hat also ein Lehrling deinen Server aufgesetzt oder aber das Installationsskript hat die Daten dort während der Installation gesammelt und es wurde vergessen die Datei zu sichern/entfernen.

Wie auch immer, nur weil dort eine solche Datei existiert bedeutet es nicht, dass der Server per se unsicher ist. Ich würde allerdings darauf bestehen, alle darin enthaltenen Passwörter zu ändern.

Übrigens ist ein eigene Admin auf Mietbasis gar nicht so teuer wie oft angenommen. Sicherlich nicht lohnenswert für jede Mini-Webseite, aber wenn man etwas mehr vor hat, macht sich ein externer Dienstleister schnell bezahlt.
 
Wenn /root nicht nur für root sondern auch andere Systemuser lesbar ist, dann ist das ein eklatantes Sicherheitsloch und dem ganzen System ist nicht mehr zu trauen. Dieses Sicherheitsloch muss nämlich explizit und vorsätzlich von root geöffnet worden sein und da ich soetwas auch dem dümmsten Anfänger nicht zutrauen möchte, bleibt nur noch Malware als Ursache übrig...

Die Zugangsdaten dort abzulegen ist zwar unschön, aber legitim, sofern dort auch nur root lesen darf.
 
Die Frage ist ob er mit root unterwegs war oder nicht. Geschrieben hat er davon nichts.
 
"Managed Server" schliesst für mich root per Definition aus, andernfalls wäre es ja ein dedizierter Server.
 
Tut es nicht. Es gibt Server die als "managed" beworben werden, wobei der Mieter sich als root anmelden kann.
 
Wie soll ich denn ein System vernünftig managen, wenn mir da irgendein Kunde ständig das System verballert? Das ist schlicht nicht möglich und somit könnte ich das SLA gar nicht erfüllen. Soetwas ist IMHO(!) nicht lauter...

Aber egal, solange wir die näheren Details vom OP nicht bekommen, bleibt das alles Spekulation.
 
Die Frage ist ob er mit root unterwegs war oder nicht. Geschrieben hat er davon nichts.
Dass der Benutzer root Zugriff auf alle Daten eines Systems hat (Späßchen wie SELinux, grsecurity usw. mal außen vorgelassen), ist denke ich jedem klar.

Da der OP jedoch schrieb
Allerdings hätte die Datei auch jeder andere Nutzer des Servers öffnen können.
gehe ich davon aus, dass er nicht als root angemeldet war. In diesem Fall wäre /root für alle Benutzer lesbar, was wiederum zu dem von Joe User geschriebenen Schluss führt.
 
Da ist eben meine Frage: Weiss der TO, dass root mehr Rechte hat oder ist er der Meinung dass jeder in das Verzeichnis /root wechseln/daraus lesen kann?

Wie auch immer, die Erleuchtung naht.
 
Also wenn mein Provider Passwörter im Klartext auf die Platte packt, das Ganze auch noch als .txt, dann wäre das für mich schon ein Grund, deutlich an dessen Kompetenz zu zweifeln. Es gibt bessere und professionellere Wege, seinen Kunden die Passwörter mitzuteilen.
 
Bitte entschuldigt, dass ich erst jetzt zu einer Antwort komme.

Ich war nicht als Root unterwegs und habe es auch mit weiteren Nutzern getestet. Darum auch die Aussage, dass jeder Nutzer des Systems die Datei hätte öffnen können.

Vorgebracht wurde vom Anbieter, dass Debian bei einem Upgrade durchaus mal "vereinzelt falsche Zugriffsrechte" setzen kann. Ich kann das leider nicht beurteilen - das ist übrigens das Schwerste für mich. Ich habe kein Fachwissen [Darum auch Danke für euer Feedback soweit :)]. Wobei ich mich hier nach mancher Aussage hier frage, ob ich nicht selbst das gleiche Leisten kann, wenn ich mir Zeit nehme und nach der "optimalen" Einrichtung apt-get update && upgrade raushaue. Aber grad bei Mailserver wär mir das halt sehr unsicher.

Ein komplett individualisiertes Produkt möchte ich auch gar nicht. Stange reicht mir da - bloß auch da würde ich erwarten, dass die Sicherheit soweit steht, dass der Anbieter auf genau diesem Server auch selbst Shared-Hosting betreiben würden.

Da das alles auch automatisch läuft, würde ich nicht vermuten, dass ein Lehrling da einen Fehler gemacht hat. Müsste ja alles über Images und Massen-Befehl-Absendungen (gibts sowas?) laufen.
 
Da es grade so wunderbar zum Thema passt. Wer einen Root Server bei OVH mietet und ein von OVH installiertes OS nutzt wird auch das PW der Erstinstallation immer in /root/.p vorfinden mit den Rechten
-r-------- 1 root root 9 6. Jul 01:43 .p
Gruß Sven
 
Vorgebracht wurde vom Anbieter, dass Debian bei einem Upgrade durchaus mal "vereinzelt falsche Zugriffsrechte" setzen kann.
Was für eine schlechte Ausrede. Wenn so etwas vorkommen sollte (mir ist das mit Debian noch nie passiert), dann 100% nicht für das /root-Verzeichnis. Und für die Datei selbst kann die Aussage schon mal gar nicht stimmen, weil die nicht von Debian kommt.

Wobei ich mich hier nach mancher Aussage hier frage, ob ich nicht selbst das gleiche Leisten kann, wenn ich mir Zeit nehme und nach der "optimalen" Einrichtung apt-get update && upgrade raushaue. Aber grad bei Mailserver wär mir das halt sehr unsicher.
Nein, ohne Fachwissen wirst du nicht das gleiche leisten können, wie ein seriöser und professioneller Anbieter. Die wichtigere Frage ist hier, ob das für deinen Anbieter zutrifft.

Magst du deinen Anbieter verraten?
 
Meine Einschätzung zu dem Anbieter vielleicht vorweg. Sehr seriös, nicht gerade klein, stark am wachsen. GmbH. Besteht seid etwa 4 Jahren, insofern noch frisch. Sicherlich kein 0815 Anbieter, von dem man so was erwarten würde.

Ich habe den Vorfall soweit gut dokumentiert und auch von anderen Personen beobachten lassen, dass dies gute Aussichten hat vor Gericht stand zu halten. Allerdings wär ein Prozess, sofern es dazu kommt, äußerst unangenehm - man hat schließlich Wichtigeres zu tun.

Ich halte es jetzt erst Mal für wichtig einen technischen Hintergrund zu dem Verhalten zu bekommen. Dass die Erklärung mit dem Update nicht passt, ist ja schon mal gut. Am liebsten würde ich ja jemanden beauftragen einen Sicherheitstest durchzuführen. Das kostet aber (wohl) viel Geld und wäre (wohl) auch nur mit Genehmigung des Hosters möglich.
Ich denke der nächste Schritt wird sein auf die Aufklärung des Vorfalls und Erläuterung des Sicherheitskonzepts zu drängen. Sollte sich dabei nichts ergeben, werde ich den Anbieter allerdings nennen.

Vielleicht hat jemand ja noch eine Idee welche "kleinen" Tests ich auf dem Server machen kann, um herauszufinden, ob dieser "sicher" ist.
 
Vielleicht hat jemand ja noch eine Idee welche "kleinen" Tests ich auf dem Server machen kann, um herauszufinden, ob dieser "sicher" ist.

Nicht ohne die Zustimmung des Providers. Um Sicherheitsmängel zu finden, muss man ja versuchen, in die vermutete Lücke zu treten. Das für deinen Anbieter von einem echten Angriff nicht zu unterscheiden.

Wenn du die Zustimmung hast, dann einfach eine Runde mit Nessus drehen. Das wäre ein "kleiner" Test.
 
Nimm einfach mal Kontakt zu "Heise Security" auf, damit sich auch langfristig die Sicherheit bei dem Anbieter bessert. Für solche Fälle sind die Jungs dort durchaus zu gebrauchen.
 
Wie soll ich denn ein System vernünftig managen, wenn mir da irgendein Kunde ständig das System verballert? Das ist schlicht nicht möglich und somit könnte ich das SLA gar nicht erfüllen. Soetwas ist IMHO(!) nicht lauter...

Das Managed Dienstleistung nicht gleich Managed Dienstleistung ist, haben wir ja schon zu genüge gelernt.
So ist es nur eine Frage der Vertragsdetails, was passiert wenn der Kunde mit seinem Root-Zugriff das Management erschwert oder unmöglich macht. Im schlimmsten Falle könnte das auch Vertragsstrafen für den Kunden nach sich ziehen. ;)
 
Im Prinzip ist das hier Waschsuppe solange nix genaus bekannt ist.
Allerdings muss man als Fazit einfach festhalten das Managed wenn es soweit geht das der Kunde Root wird nimmer viel mit dem eigentlichen Begriff und dessen was man darunter versteht zu tun hat.
Fire Du magst recht haben. Allerdings.... ich genieße immer wieder die deutsche Rechtsprechung. So schlecht stehen die Chancen nicht für den Kunden .... auch wenn er in Absatz 222 Unterziffer 12 evtl etwas überlesen hat.
So Zeug macht richtig Spaß wenn man nicht dabei verarmt ;)
Gruß Sven
 
Hey klar, freue mich ja über Rückfragen :)

Ich benutze zum Verbinden schon immer WinSCP und versuche damit standardmäßig über SFTP zu verbinden. Ob ich nen Fallback auf FTP hatte, müsste ich jetzt noch mal schauen. Jedenfalls kann ich sagen, dass mir eine Shell zur Verfügung steht. Diese ist auch offensichtlich nicht nur auf das eigene Verzeichnis beschränkt - also kein chroot (?) - sondern kann überall hin wechseln. Die Verzeichnisse der anderen Accounts sind über Lese, Schreib, Ausführ-Berechtigungen gesperrt, sodass dorthin kein Zugriff möglich ist.

Vielleicht noch als Hinweis: Auf dem System läuft Confixx.

Heise Security ist doch ne vernünftige Idee. Danke.
 
Back
Top