kompromittierter Server?

[Mordor]

Da hast Du völlig Recht, die mache ich mir auch gerade. Ich kenne aber noch kein passendes Angebot: Root-Zugriff sollte bleiben, aber ich brauche einen Admin, der einen Teil der Systempflege übernimmt. "Managed Root" würde schon passen, aber der Begriff ist mir noch ein wenig zu schwammig. Kennt jemand ein empfehlenswertes Angebot in der Richtung?

Bei einem Managed-Server wirst du keinen Root-Zugang bekommen. Der Server wird von einem Mittarbeiter des Hosters administriert. Die setzen dir den Server so auf, dass er sicher ist, kümmern sich um Updates, und um deine Wünsche, sofern diese nicht Systemgefärdend sind.

Aber daß ein System im Auslieferungszustand derart gravierend unsicher ist, gab es in der Windows-Welt zum letztenmal vor zehn Jahren

Das System an sich, welches du zum Auslieferungszustand zur Verfügung gestellt bekommst, ist mit Sicherheit nicht unsicher. Du machst es unsicher, z.B. durch die unsachgemäse Installation von Software, Skripten usw.
Es ist schon klar, dass man neue dienste installieren muss. Dann muss man sich aber auch um deren absicherung kümmern.
Um das Autobeispiel mal wieder zu bemühen:
Das Auto an sich ist auch sicher, Wenn du aber einen besoffenen Fahrer installierst, ist es das nicht mehr.

Daß ein vorkonfiguriertes (!) OS im Jahr 2010 noch derart gefährlich, chaotisch und unbeherrschbar sein kann, lässt man sich als verwöhnter MS-Admin nicht träumen.

Ist es doch nicht. Wo ist es chaotisch. Chaotisch wird es, wenn man keine Ahnung davon hat.

Der Auslieferungszustand wurde nicht verändert. Woher soll ich das also wissen?

Doch, wurde er!
Du hast doch bestimmt Skripte wie PHP-Anwendungen installiert?! Also hat sich das System doch geändert.

Vernünftigerweise sollte er deaktivert sein, es sei denn, ich hätte ihn manuell aktiviert. Das gleiche sollte auch gelten für FTP sowie den ganzen restlichen Kram, der auf dem System läuft.

Dafür bist du verantwortlich. Du musst nachsehen, was aktiviert ist, und was nicht, welcher Port offen ist, und welcher nicht. Sowas macht man regelmäsig. Selbst wenn ich heute ein vermeintlich sicheres System aufsetze, heißt das noch lange nicht, dass das morgen noch so ist. Ich muss mich drum kümmern, dass das so bleibt. Das ist nicht nur bei UNIX/LINUX so, sondern auch bei Windows. Oder warum glaubst du gibts da Patchdays.

 

[siradlib]

Das kann ich ja so einfach nicht machen. Die Web-Präsenzen zu sichern ist das geringste Problem, aber was ist mit Mailbases, Useraccounts und Einstellungen? Ich weiß ja nicht einmal, wo die alle verstreut sind. Sichern ist damit unmöglich, ich müsste statt dessen "nachher" alles neu konfigurieren. Das einfach so zum Probieren... na, ich danke.

Wie gesagt, Du musst Dein Einfallstor analysieren!
Nicht, dass das Loch durch eine Fehlkonfiguration Deinerseits entstanden ist, Du lustig das System neu installierst und Dir anschließend die Lücke wieder einbaust!
Solltest Du heraus bekommen, dass die Lücke durch ein manipuliertes Binary entstanden ist, unbedingt neu installieren und sofort Updates installieren! Zuvor kannst Du mit Pleskbackup Dein altes System inkl. Mails und Webspaces sichern und nach der Neuinstallation wieder zurückspielen.
Gut wäre wohl auch, sich einen 2. Server zu mieten, diesen zu installieren und aktualisieren und dann die Daten Stück für Stück vom alten zu migrieren.

Davor halt testen nicht vergessen, Pleskbackup hakt wohl gern mal, wenn man div. Beiträgen hier glauben darf. Hab aber keine Erfahrung mit diesem Tool.

 

[CEW4]

Bei einem Managed-Server wirst du keinen Root-Zugang bekommen. Der Server wird von einem Mittarbeiter des Hosters administriert. Die setzen dir den Server so auf, dass er sicher ist, kümmern sich um Updates, und um deine Wünsche, sofern diese nicht Systemgefärdend sind.

Was ich im Grunde bräuchte ist ein root-per-voice: Ich telefoniere den Admin an und sage, was ich brauche, und er macht es. Hat aber einen kleinen Haken: Das bereithalten eines qualifizierten Admins, der sofort springt wenn ich pfeife, dürfte eine Kleinigkeit kosten. Ich kann mir nicht vorstellen, daß dies für nicht-kommerzielle oder private Nutzung bezahlbar ist.

Das System an sich, welches du zum Auslieferungszustand zur Verfügung gestellt bekommst, ist mit Sicherheit nicht unsicher.

Und wo kommt dann der FTP-Deamon her? Der SSH-Zugang? Warum war der bereits aktiv, nicht erst, nachdem ich ihn über ein (imaginäres) Web-Frontend aktiviert habe?

(Daß ich das wahrscheinlich weitgehend kritiklos getan hätte, steht auf einem anderen Blatt.)

Ist es doch nicht. Wo ist es chaotisch.

... bei allem, was auf den Text "login:" folgt.

Das eine Binary liegt unter /bin, das andere unter /usr/bin, das dritte unter /usr/sbin und der Rest verteilt sich gleichmäßig zwischen /var, /sys und /wasweißichnochalles. Konfigdateien liegen mal da, mal dort; ein globales Event-Log gibt es nicht (oder ich habe es noch nicht gefunden) und jede Anwendung verwaltet ihre Konfiguration selbst, abgelegt in ASCII-Dateien quer über das Dateisystem verteilt.

Es ist ja kein Wunder, wenn da Lücken unbemerkt bleiben.

Du hast doch bestimmt Skripte wie PHP-Anwendungen installiert?! Also hat sich das System doch geändert.

Hat das etwas mit FTP- oder SSH-Daemon zutun?

Ich muss mich drum kümmern, dass das so bleibt. Das ist nicht nur bei UNIX/LINUX so, sondern auch bei Windows. Oder warum glaubst du gibts da Patchdays.

Der Unterschied ist ganz einfach, daß ich bei Windows nur wissen muß, was ich will. Wie man es macht, findet sich. Bei Linux kann ich ein vollstudierter Profi-Admin sein, der genau weiß, daß er dieses Bit in jenem Register der siebten Netzwerkkarte setzen muß, aber ich werde Ewigkeiten brauchen um herauszufinden, wie ich das nun dem System begreiflich mache.

Anderes Beispiel: Wenn unter Windows ein Update einen System-Neustart benötigt, dann werde ich darauf hingewiesen. Unter Linux soll ich das selbst wissen. Ich kann nun entweder versuchen zu beurteilen, ob ein Neustart diesmal notwendig ist und dabei u.U. Fehler machen, oder "auf Reserve" nach jedem Mini-Update immer einen Neustart durchführen. Beides dürfte alles andere als optimal sein.

MfG

 

[CEW4]

Wie gesagt, Du musst Dein Einfallstor analysieren! Nicht, dass das Loch durch eine Fehlkonfiguration Deinerseits entstanden ist, Du lustig das System neu installierst und Dir anschließend die Lücke wieder einbaust!

Genau meine Sorge. Wenn ich jetzt einfach alles plattmache, finde ich ja nie heraus, was eigentlich los war.

Zuvor kannst Du mit Pleskbackup Dein altes System inkl. Mails und Webspaces sichern und nach der Neuinstallation wieder zurückspielen.

Was, das geht? Toll, das war mir nicht klar. Das Backup innerhalb Plesk umfasst auch Postfächer (nicht nur die Konfiguration, sondern auch die eigentlichen Mails)?

Puh, mein Problem der Neuinstallation ist gerade schlagartig bedeutend geringer geworden. <g>

Danke für den Hinweis. Bei "Backup" hatte ich immer an eine Kopie auf Dateisystem-Ebene gedacht, die ich nicht selbst hätte zusammensortieren können. Auf den Gedanken, daß mir Plesk diese Arbeit abnehmen könnte, war ich gar nicht gekommen. ;-)

Gut wäre wohl auch, sich einen 2. Server zu mieten, diesen zu installieren und aktualisieren und dann die Daten Stück für Stück vom alten zu migrieren.

Keine schlechte Idee. Wäre wohl auch für ständige Backups nicht ganz falsch.

Darüber muß ich noch einmal intensiver nachdenken.

Davor halt testen nicht vergessen, Pleskbackup hakt wohl gern mal, wenn man div. Beiträgen hier glauben darf. Hab aber keine Erfahrung mit diesem Tool.

Ich such einmal danach. Nochmal danke!

MfG

 

[Mordor]

Was ich im Grunde bräuchte ist ein root-per-voice: Ich telefoniere den Admin an und sage, was ich brauche, und er macht es.

Und du bist dir sicher, dass du nicht mal ein paar Minuten warten kannst, bis der Admin was macht???

Und wo kommt dann der FTP-Deamon her? Der SSH-Zugang?

Den SSH brauchst du um das System zu administrieren. Wer glaub das gehe nur über ein Webfrontend, ist als Admin definitiv falsch. Und der FTP ist wohl deshalb gestartet, weil du ein IMAGE mit LAMP installiert hast. Da wird das wohl dabei sein. Das wird dir dein Provider aber auch mitteilen, wenn du dich darüber informierst, was in den Paketen drin ist.

Das eine Binary liegt unter /bin, das andere unter /usr/bin, das dritte unter /usr/sbin und der Rest verteilt sich gleichmäßig zwischen /var, /sys und /wasweißichnochalles. Konfigdateien liegen mal da, mal dort; ein globales Event-Log gibt es nicht (oder ich habe es noch nicht gefunden) und jede Anwendung verwaltet ihre Konfiguration selbst, abgelegt in ASCII-Dateien quer über das Dateisystem verteilt.

Linux ist eigentlich ziemlich strukturiert. Und wenn du dich einlesen würdest, würdest du das auch herausfinden.
Config-Dateien liegen in der Regel immer unter /etc. Logs in der Regel alle unter /var/log. Wenn jede Anwendung ihre configs selbst verwaltet, ist man einfach flexibler.

Und mit deiner Meinung zu Windows:
Das artet schon wieder in eine Grundsatzdiskussion aus. Genau so könnte ich mich hinstellen und sagen: Apple ist besser, weils bunter ist.
Ich denke, du hast einfach keine Ahnung von dem, was du mit dem System zu tun hast, was nicht, und wie man es vernünftig am laufen hält. Denn wenn du auch nur ein bischen Ahnung hättest, würdest du einige der oben stehenden Kommentare nicht loslassen.

 

[CEW4]

Und du bist dir sicher, dass du nicht mal ein paar Minuten warten kannst, bis der Admin was macht???

So wörtlich brauchst Du mich auch wieder nicht zu nehmen. ;-)

Aber jede "Maßanfertigung" ist teuer. Solange der Provider nur auf meinen Wunsch "Skript Nummer 23" starten muß, ist es kein Problem. Wenn sich der Zuständige aber erst einmal ansehen muß, wie das und das in meinem ganz speziellen Fall angelegt werden muß, dann läuft es auf Handarbeit hinaus. Das kann ich nicht für Preise wie bei den Discount-Hostern erwarten.

Den SSH brauchst du um das System zu administrieren.

Ok, schlechtes Beispiel.

Linux ist eigentlich ziemlich strukturiert. Und wenn du dich einlesen würdest, würdest du das auch herausfinden.

Mich daran zu gewöhnen versuche ich seit der Zeit, als Suse noch auf Disketten ausgeliefert wurde. Ich habe nie begriffen, wo da eine Logik sein soll. Statt dessen finde ich immer nur punktuelle Lösungen, wie man das macht, wie man jenes macht. Ein brauchbares Tutorial "wie beherrsche ich ein Linux-System" aber habe ich noch nie gesehen, nicht als README und auch nicht als Kurs, Seminar oder ähnliches.

Und mit deiner Meinung zu Windows: Das artet schon wieder in eine Grundsatzdiskussion aus.

Hast recht. Aus mir sprechen zwanzig Jahre Linux-Frustration, die aus gegebenem Anlass explodiert sind.

MfG

 

[tomasini]

Zwei Fragen:

1.) Was soll der Server denn konkret alles können bzw. welche Dienste sollen darauf laufen?

2.) Warum nimmst du dir nicht einfach einen Windows-Root, wenn du dich dort mit der Administration besser auskennst?

 

[CEW4]

1.) Was soll der Server denn konkret alles können bzw. welche Dienste sollen darauf laufen?

Die reinen Basics: Ein paar Web-Präsenzen und email (IMAP). Mehr nicht. Die Hosting-Angebote der großen Hoster fallen aber wegen Beschränkungen aus (z.B. PHP SafeMode), und ich hatte ehrlich gesagt nicht den Nerv, mich durch mir völlig unbekannte kleine Hoster durchzugraben.

2.) Warum nimmst du dir nicht einfach einen Windows-Root, wenn du dich dort mit der Administration besser auskennst?

Weil ich dazu bisher nur unanständig teure Angebote gefunden habe. Ein Linux-Server kostet 20-30 E/Monat, einen Windows-Server mit ähnlichen Daten habe ich noch nicht unter 50-70 E/Monat gesehen. Und dann hat der noch nicht einmal einen IMAP-Server on-board, das ginge in aller Regel nochmal extra.

MfG

 

[CEW4]

Guten Morgen allerseits,

ich fürchte, ich kann diesen Thread schließen:

Inzwischen habe ich Logdateien gefunden (Danke an Mordor!) und durchsucht. Viel habe ich nicht gefunden, aber es reicht:

Nov 23	19:16:43  sshd  Accepted publickey for root from 109.111.201.226 port 33705 ssh2
Nov 30	00:00:43  sshd  Accepted publickey for root from 109.111.201.226 port 53746 ssh2

Das war nicht ich. Damit ist dann wohl alles klar.

Danke an alle, die mir geantwortet haben!

MfG,
CEW4

 

[siradlib]

Nur so als Gedankenspiel:
Bei einem vServer habe ich ja immer das Problem, dass ich nicht mit einem sauberen System von außen rankomme, also z.B. das System nicht von einem Zweitsystem aus untersuchen kann.
Das Rescue-System bietet auch nur sehr eingeschränkte Möglichkeiten.

Wäre es nun möglich, eine Kopie des vServers folgendermaßen zu erhalten:
1. boote den vServer im Rescue-System
2. # chroot /rescue
3. # tar cpjf /var/private-backup/system.tar.bz2 *
4. Tarball (system.tar.bz2) auf ein lokales System herunterladen

Nun folgende Schritte z.B. in einer virtuellen Maschine lokal machen:

5. sauberes Linux in der lokalen virtuellen Maschine installieren, dabei dieselbe Linux-Version und Distro wie die des "verdächtigen" Systems verwenden
6. System von (beliebiger Rettungs-) CD starten
7. # tar xpfC system.tar.bz2 /mnt/root-des-sauberen-systems

Nun sollte doch das lokale System in der virtuellen Maschine identisch mit dem aus dem vServer sein, oder?
Vorteil hier wäre jetzt, dass ich das lokale System von außen untersuchen kann, beispielsweise mit einem garantiert "sauberen" rkhunter, ich könnte md5-Prüfsummen vergleichen usw.

Der Kernel ist natürlich davon ausgenommen. Nur frage ich mich, wie groß ist das Risiko eines Kernel-Exploit bei einem vServer überhaupt?

Hinweise auf Denkfehler werden gern entgegengenommen!

Ich zitiere mich ja ungern selbst. Aber wäre jemand so nett, meine Gedankengänge zu kommentieren?

Vielen Dank und schöne Wochenend-Grüße!
siradlib

 

[fme]

Das Problem ist schon der Neustart.
Damit veränderst du das System.

Ganz simples Beispiel:
Ich kann ein Programm über eine Lücke in einem PHP Skript hochladen und ausführen. Danach lösche ich das Binary.
Im aktuellen System läuft dieses Programm noch, nach dem Neustart ist es jedoch verschwunden.
Das macht das alles "so kompliziert", wenn man sich nicht genauer damit beschäftigt.
In diesem Fall würde das System bei der Analyse sauber aussehen wenn man nicht gerade auf das Loch in der PHP App achtet.

Man kann bei so einem infizierten System höchsten den SSH Port umlegen und alle anderen Ports ein und ausgehend sperren und alles loggen lassen. Dazu die System Binaries von iptables, lsof, ps usw mit den Original Distridateien (MD5 Check) ersetzen und hoffen das man damit was sieht. Dann halt Checksummen vergleichen usw.

 

[siradlib]

Okay, soweit hatte ich noch garnicht gedacht. Danke für Deine Antwort!