Host war ausgefallen und OVH läßt uns hängen

OVH Support-Ticket - HOST seit Tagen geblocktLeider ist am Samstag, der 25. April 2015 unser wichtigster und größter Host ausgefallen! Anschließend wurde der Host vom Rechenzentrum OVH wegen angeblichem Hacking gesperrt und seit dem 29.04.2015 – also 4 Tagen warten wir, daß OVH den Host wieder frei gibt, weil wir nun lückenlos klären konnten, daß ein Betriebssystem-Kernel dafür verantwortlich ist! Zuvor hatte uns OVH schon schon den Vorgang um weitere 1,5 Tage  verzögert, um einfach in den Rescue-Modus zu kommen, Aber hier lesen Sie nun die gesamten Zusammenhänge UND wir zeigen das gesamte Ticket und so dumm, wie es gekommen ist, kann keiner denken, daß es kommen kann! In der Nacht zum 26.04.2015 hat es wieder massives Hacking gegeben und normal wird dies auch von der eingesetzten Sicherheitstechnik abgefangen! Was im letzten Moment vor dem „Unfall“, also dem Zeitpunkt passiert ist, als das System freezte und ein Einloggen in den Host nicht mehr möglich machte, ist noch nicht restlos aufgeklärt! In jedem Fall ist es üblich, daß ein Hoster, wenn er den Host nicht erreichen kann, diesen neu startet und damit wurde unwissentlich ein Kernel aktiviert, der ganz offensichtlich mit Bugs behaftet ist und es kommt noch viel schlimmer!

Es ist normal, wenn ein Host „kalt gestartet“ wird, dieser erst einmal das Disk-Array prüft und dann ist der betreffende Host in der Regel zwischen 30 Minuten und 2 Stunden damit beschäftigt. Klar, jetzt rufen dann schon mal eine Menge Kunden an! Keine Minute darf vergehen, um den Host schnell wieder online zu bekommen. Also wird immer wieder versucht, sich in den Host einzuloggen, bis das Betriebssystem Linux Debian Proxmox wieder hochgefahren ist. Dann erst bekommt man Zugriff und gleichzeitig werden dann von Proxmox alle Server hoch gefahren, die auch auch bei Neustart des Hosts gestartet werden sollen!

Beim beobachten dieses Vorgangs knallten aber einige Server gleich bei Start wieder weg. Dann gibt es nur 2 Möglichkeiten, entweder Crash im Raid-System oder Einbruch!

Oft hilft aber ein sauberer „Warm-Start“, also wurden alle Server wieder herunter gefahren, bevor dann der 2. Start durchgeführt wurde. In der Regel kommt dann der Host schneller hoch oder er findet noch Probleme im Raid und prüft erneut zwischen 30 Minuten und 2-4 Stunden.

Und der Host ging wieder in den Raid-Check für wieder einige Stunden! Die Zeit läuft jedem Hoster dann weg! Nachdem nun das 2. mal nach dem „Unfall“, der Host hoch kam, waren nur noch wenige Server nicht funktionsfähig, mehr also also nach dem 1. Start. Also wiederholen wir den Vorgang zur Sicherheit noch mal, denn mit einem defekten Raid kann keiner sauber arbeiten.

Der Host startete über den „Warmstart“ nun so, wie es bei einem Warmstart üblich ist, nämlich in einer Zeit von 5 Minuten. Also hat der Host jetzt keine weiteren Probleme im Raid gefunden! Zum anderen war auch der Hardware-Check vom Raid „100% in Ordnung“ über das Interface angezeigt! Also war nun das Raid sauber und die meisten Server liefen sauber hoch.

Nun konnten wir erst beginnen, zu untersuchen, warum die anderen Server nicht hochliefen und gleichzeitig führten wir bei den gestarteten Servern einen Check durch, ob hier Auffälligkeiten vorhanden sind, ob z.B. Schadsoftware installiert wude etc. aber nichts auffälliges war zu erkennen! Und während der Arbeit „peng“ war der Host wieder weg und wir versuchten uns nun erst mal zu verbinden, was nicht mehr gelang! Wir suchten nach einer Mail und haben tatsächlich eine bekommen mit dem Hinweis, vom Host wurde belastender Traffic via MAC auf einer IP festgestellt! Ok, hier handelt es sich um den einen Server, der mit Confixx läuft und der nur über MAC – Bridging betrieben werden kann. Also haben wir die MAC bei OVH für diese IP gelöscht! Es kann also kein Traffic mehr zwischen dem OVH-Gateway und dem betroffenen Server mehr erfolgen. Die Sache war ganz klar, dieser Server hat ein Problem gemacht und durch dieses Löschen der MAC war der Server nicht mehr erreichbar in beide Richtungen! OK, ansonsten waren die Logs im OS Debian-Proxmox komplett sauber und ohne Auffälligkeiten. Also „Warmstart“ für den Normal-Modus!

Der Host lief normal hoch und der betroffene Server wurde in Proxmox für einen Neustart gesperrt, aber lief dennoch hoch, offensichtlich wird die Liste der Server nur vor dem Start gelesen und Veränderungen während der Starts nicht mehr. Gesehen und gleich wieder den betroffenen Server gesperrt, haben wir unsere Arbeit an den anderen Servern fortgesetzt, diese zu untersuchen – alles sah gut aus und viele Server bekamen wir durch Rücksicherung auch schnell wieder zum laufen! ….und dann war der Host erneut weg – , also am 26.04.2015, 14:21h  und bis dahin, haben wir schon fest gestellt, daß die PVE-Firewall nicht mehr läuft! PANIK!

Wir hatten also schon bis zum diesem Zeitpunkt fest gestellt, daß die PVE-Firewall nicht läuft und haben nun auch an den Problemen gesucht, warum diese nicht startet. Immer stand in den Logs, daß IPv6 nicht zur Verfügung steht, aber nur wenige Server arbeiten über eine IPv6. Wenn auf dem Host offensichtlich IPv6 eingeschaltet ist und der Host mal ohne IPv6 hochfährt, dann startet die Proxmox-PVE-Firewall nicht – ein absoluter Bug, in unseren Augen, aber es kommt noch schlimmer! Uns war unklar, warum IPv6 nicht startet und die 2. Meldung von OVH zeigte auf eine IP (IPv4), die in dem anderen Confixx-Server via MAC verwendet wird! Also war der nächste Schluß, daß irgendwas mit dem MAC-Bridging nicht in Ordnung ist und wir haben dann auch gleich OVH geschrieben, bezüglich das IPv6 fehlt und daß daher die PVE-Firewall nicht läuft und daß wir um mehr Informationen bitten! Gleichzeitig hat man den Host in einen Zustand versetzt, in der noch nicht mal mehr der Rescue-Modus gestartet werden kann und mit FTP kann man bei einem Host nun mal gar nichts anfangen, weil dann noch nicht einmal die LVM-Platten eingehängt sind!

Es vergingen von der Anforderung, bitte doch den Host im Rescue-Modus starten zu können nun 1,5 Tage und als wir nun in den endlich uns einloggen konnten und die LVM-Disks gemappt haben, haben wir den gesamten Host untersucht, da im Panel bei OVH dieser als „gehackt“ gesperrt worden ist! Gleichzeitig kam die Befürchtung auf, es könne sich um einen Einbruch handeln und daher haben wir ALLE Passwörter geändert, denn die Hosts kommunizieren über jeweils andere User und Passwörter (und Schlüssel) und auch die Bestell-Systeme / Abrechnungssysteme wiederrum mit anderen etc. Also ca. 50 Passwörter für alle unterschiedlichen Subsysteme wurden schnell geändert und neu protokolliert! Aber später haben wir festgestellt, daß es sich nicht um einen Einbruch handelt – nur aber wegen der Sicherheit, war diese Entscheidung immer richtig!

Jeder einzelne Server und auch der Host wurden intensiv untersucht. Es gab keine Auffälligkeiten für Einbrüche, aber natürlich eine Latte von „Mails mit schadhaften Anhängen“, die von Kunden nicht gelöscht wurden und so ein paar kleinen Auffälligkeiten in Webspaces, die alle einzeln untersucht werden mußten und jeweils zur Entscheidung für ggf. temporäre Sperrungen geführt haben! Man muß daß mal ganz klar erwähnen: „Auf einen Server gehört kein illegales Material, welcher Art auch immer!“, ansonsten war das System clean! Auch wurde der Host regelmäßig upgedatet verfügt neben der PVE-Firewall über viele weitere Software, die den Host sauber halten, aber die mit in die PVE-Firewall fließen und dann soll und so ist dies bei uns realisiert in den Shared-Hosting-Servern, in den Servern ebenfalls noch eine Firewall und weitere Software, wie fail2ban mit automatischem Blocking etc. laufen. Der Host blockt dann jeden Angreifer normal voll automatisch, allerdings nur wenn die PVE-Firewall auch läuft!

Jetzt mußten wir untersuchen, warum denn die PVE-Firewall nicht läuft. Unsere Frage also, warum hat OVH die IPv6 uns weg genommen? Haben Sie nicht! Was sich dann aber ja erst heraus stelle, daß diese im Rescue – Modus zur Verfügung stand, aber seit dem warten wir ja immer noch, daß im Normal-Modus sehen zu können! Wir haben also im Rescue-Modus weiter geforscht, seit wann denn die IPv6 fehlt und fanden den ersten Eintrag, daß IPv6 fehlt nach dem ersten Neustart am Samstag! Also untersuchten wir alle Einstellungen und scannten alle Dateien durch, ob diese zwischenzeitlich verändert wurden und da war nix, außer den Dingen, die wir probiert haben, um IPv6 wieder aktiv zu bekommen, also in einer einzigen Einstellungsdatei, wir haben daß natürlich immer mit dem anderen Host abgeglichen, denn der andere Host ist identisch eingerichtet! Auffällig war dann aber doch eine Datei, die sich geändert hat, nämlich am 9. April 2015 und die ist zuständig für den Kernel. Aber diese Datei hat sich automatisch am gleichen Tag mit unterschiedlichen Uhrzeiten geändert und nun haben wir die Kernel-Versionen verglichen und tatsächlich lief der durch OVH gesperrte Host, mit einem neuen Kernel, den wir aber selbst nicht aktiviert haben! Kurzes Suchen dann über Internet ergab „Probleme mit IPv6 / Speicherprobleme usw“ und bei den Fehlermeldungen im Log mit fehlendem IPv6 gabs als Zugabe dann auch gleich immer noch zusätzlich INODE-Fehler! Speicher = RAM und INODE = Disk-System!

Was war also passiert und warum trifft es gerade uns und keinen anderen Hoster?

Jedes Host-System ist ein Server, nur mit reichlich viel mehr Power und mit mehr Speicher und ist speziell auf das Hosten von Servern (Virtualisierung) abgestimmt. Egal ob es sich dabei um ein Windows – Host handelt oder Linux – Proxmox oder andere, immer wird bei einem Start, zuerst erst wird das Disk-Array geprüft und dann erst gemounted und dann lädt der Server den Rest des OS hoch. Erst wenn das OS (Betriebssystem) hoch gefahren ist, startet dann der Host die einzelnen Server und daß dauert auch eine ganze Weile pro Server, denn auch der Server startet dann z.B. die Datenbank MySQL und dann geht eine Prüfung der Konsistenz der Datenbanken los etc.

Daher wird ein Host, solange es nicht unbedingt notwendig tut, nie neu gestartet!

Updates laufen auch so in den Host rein und dazu muß in der Regel der Host nicht neu gestartet werden. Und alle 3 Wochen kommt ein Kernel-Update rein und wenn kein Hoster gerade jetzt den Host neu startet, ist das Problem mit dem nächsten Kernel-Update auch schon wieder beseitigt und kein Mensch merkt es, nur bei den Hostern, wo wirklich mal der Host neu gestartet werden muß und wenn dieser es dann macht, ist dann auch die Frage, ob dieser auch IPv6 anbietet!

Viel schlimmer ist, daß wir immer noch darauf warten, daß wir den „gesperrten Host“ nun endlich wieder hochfahren können:

Es handelt sich nicht um ein Hacking und so etwas war auch nicht vorher auffällig! Wir können definitiv nichts dafür, daß hier der OS-Hersteller, Debian oder Proxmox hier einen Fehler gemacht haben und daß von OVH noch nicht einmal eine Antwort kommt. Abschließend hängen wir auch das Ticket noch an, wobei wir hier unsere Kennungen geschwärzt haben und auch die technischen Einzelheiten (also längere Log-Ausschnitte): OVH-Ticket  

5 Gedanken zu „Host war ausgefallen und OVH läßt uns hängen“

  1. Hallo,
    ich habe das gerade mit Interesse gelsen, weil ich meine unwichtigen privaten Server auch bei OVH habe.
    Aber warum vereinbart man für so wichtige Hostsysteme keine SLA (Servicevereinbarungen mit garantierter Reaktions-/Entstörzeit)? Warum spielt man so kritische Sachen wie Kernelupdates automatisch ohne Prüfung ein wenn man nicht mal vorhat die zu aktivieren? Sollte man kritische Sachen nicht voab an einem Testsystem testen und dann wenn notwendig gezielt aktivieren. So wie oben beschrieben ist das doch sowas wie Kamikaze, oder?
    Grüßli
    Jana

    1. Hallo Jana,

      danke für Ihren Kommentar!

      a) Wir daten grundsätzlich ab, um die Sicherheit des Hosts aufrecht zu erhalten. Dabei werden auch neue Kernel installiert, aber nicht aktiviert! Diese werden nur bei einem Neustart aktiv und bisher war dies auch kein Problem! Dennoch war uns daß auch gar nicht bekannt, daß ohne ein Zutun, diese sich aktivieren! Wir waren bisher der Meinung, daß wir so etwas mit grub erst ändern müssen!
      b) Ja, mit den großen Hostmaschinen ist uns fest SLA zugesichert: Eingriff GTI 1 Stunde / Reparatur GTR GTI+2 Stunden / Level 2 GTI 12 Stunden! Wir haben über eine Woche gewartet, daß lediglich ein Flag umgelegt wird! Wir haben auch zig mal OVH angerufen, und diverse Mails an OVH gesendet etc. Auch in Twitter haben diverse OVH-Mitarbeiter mitgelesen und was die gemacht haben, entzieht sich unserer Kenntnis.
      c) Da wir selbst an der gesamten Konfiguation nichts verändert haben, waren auch keine Tests in unserer Test-Umgebung notwendig!
      d) und ja, momentan arbeiten wir auf, was genau bei dem Unfall passiert ist!

      Grüße
      1awww.com – Internet-Service-Provider

      Detlef Bracker

  2. wie kann man einen solchen Anbieter in Stich lassen, eine solchen Support möchten erst mal andere auf die Beine stellen wie man bei 1awww bekommt, ich kann mich nicht beschweren im Gegenteil alle Daumen hoch,
    immer eine freundliche Behandlung, auch wenn man selbst einen Fehler gemacht hat, man sollte dies aber zugeben und man bekommt sofort Hilfe wie man diesen Fehler in Zukunft nicht mehr macht.

    1. Hallo Herr Feßke,

      auch Ihnen vielen Dank für Ihren Kommentar!

      daß ist auch unser Grundprinzip: Fehler kann man machen, man muß aber auch bereit sein, diese zu zugeben!
      Damit haben auch wir kein Problem und es tut uns unbeschreibbar leid, was da passiert ist!
      Auch wenn wir den Gau nicht verursacht haben, insgesamt war dies eine Kette von Ereignissen, die man hätte vorher auch nicht sehen können!
      Wir werden alles mögliche tun, um die Sicherheit und Stabilität weiter zu erhöhen!

      Mit freundlichen Grüßen
      1awww.com – Internet-Service-Provider

      Detlef Bracker

Schreibe einen Kommentar zu Administrator Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert