Netz - Rettung - Recht

Munin hat seine Vorteile und ist insgesamt sehr nett - andererseits hat es aber, wie jede Überwachungsmaßnahme, den Nachteil, daß man so von Dingen erfährt, die man sonst nie erfahren hätte - und sich dann anfängt, Sorgen zu machen. So zum Beispiel über den steilen Anstieg der Temperatur einer gehosteten Maschine. Glücklicherweise handelt es sich aber wohl nur um eine vorübergehende Episode, denn inzwischen wird’s da schon wieder kühler.

Jetzt hat es dieses Wochenende doch geklappt, wenigstens eine der mittlerweile gesammelten neuen Ideen einmal umzusetzen und sowohl auf meiner heimischen Allroundkiste als auch auf den von mir betreuten Servern das Monitoring-Tool Munin, benannt nach einem der Raben des Göttervaters Odin, zu installieren, das mit Hilfe von Plugins aus verschiedenen Quellen Daten sammelt und diese dann in täglichen, wöchentlichen, monatlichen und jährlichen Graphen aufbereitet. Zwar ist das eine oder andere sicherlich noch zu tun, die Darstellung zu optimieren, vielleicht die Menge der Datenquellen nach dem ersten Enthusiasmus etwas zu begrenzen und fortgeschrittene Aufgaben wie das Erstellen von Summenübersichten einmal auszuprobieren, aber bisher gefällt mir das schon sehr, sehr gut - und erfüllt zudem einen lange gehegten Wunsch. Schon seit Jahren hätte ich auch gerne so hübsche Bilder und Statistiken - ganz zu schweigen von der Nutzbarkeit dieser Darstellungen einerseits für einen generellen Überblick über die Be- und Auslastung der Maschinen und andererseits zur Aufklärung sonst ungeklärter Abstürze, Fehler und Probleme:Wie oft läßt sich aus Logfiles nicht wirklich klar erkennen, warum eine Maschine sich weggehäng hat? Wenn das letzte, was man von ihr sieht, bspw. eine steil steigende Kurve bei Load, Speicherauslastung, Temperatur oder sonstwas ist, weiß man zumindest schon einmal, in welche Richtung man suchen kann.

"Servermonitoring mit Munin" vollständig lesen

Sie geht wieder!

Nachdem ich bereits am Dienstag darüber berichtete, daß Seagate jetzt endlich auch weitere Firmware-Updates zur Verfügung gestellt hat, habe ich am Mittwochabend dann erfolgreich gewirkt: erst ein Image der Platte aufs NAS, dann das Update als ISO heruntergeladen und gebrannt, rebootet, beide Platten mit dem Firmware-Update versorgt, und jetzt bin ich mit der Firmware SN06 wieder auf der (hoffentlich) sicheren Seite.

Immer dieser Streß …

Es gibt Dinge, die möchte man eher weniger gerne in Logfiles lesen:

02/04/2009 06:01:52  <Power Failed! The UPS is operating on battery power.>
02/04/2009 06:01:52  <The operating system will be shut down in 5 minute(s) : 0 second(s)!>
02/04/2009 06:06:52  <The UPS will be shutdown in 4 minute(s) : 0 second(s)!>
02/04/2009 06:06:58  <Shutdown OS>
02/04/2009 06:07:29  <Program: upsd was forced to stop!>

Die Maschine ist 5 Minuten später aber gut wieder hochgekommen. Leider kann man das aus - mir immer noch unklaren Gründen - von Netzwerk und Internetanbindung nicht sagen. Besonders unschön, wenn man einige hundert Kilometer vom Orte des Geschehens entfernt und auf die Anleitung eher weniger IT-affiner Hilfe angewiesen ist …

Die DSL-Anbindung ließ sich mit dem einfachsten aller Vorgehen (Router vom Strom trennen - warten - Power on) wiederherstellen; danach litt allerdings das LAN unter völliger Überlastung mit minutenlangen Wartezeiten via SSH und Paketverlusten zwischen 30 und 70 Prozent, sowohl intern als auch extern. Nachdem mich dieses Phänomen schonmal (auch nach dem längeren Ausfall der Internetanbindung) fast einen Tag gekostet hatte, hatte ich auch dafür ein einfaches Rezept: den lokalen Multifunktionsserver, ein Debian Lenny, mal für fünf Minuten durch Abziehen des LAN-Kabels vom Netz trennen. Danach war alles wieder gut. *kopfkratz*

Was genau jetzt dafür verantwortlich ist, daß nach einem Ausfall der Internetanbindung das LAN völig zusammenbricht, und warum sich das nach dem kurzfristigen Abklemmen einer (leider zentralen) Maschine wieder gibt, ist mir als insofern IT-Laien weiter völlig schleierhaft.

Bei der Lektüre meiner Logfiles fiel mir gestern auf, daß sich da jemand wohl einmal durchs Wörterbuch zu raten versuchte, beginnend mit root, dann weiter über ftp, mysql, daemon etc. bis hin zu test, temp, bill, martin, sekretariat, x737 und zzz, insgesamt knapp 1.000 Versuche. Interessanterweise habe ich dasselbe Phänomen auf einer weiteren Maschine feststellen können, die auch im Hostingnetz von Strato steht - Server bei anderen Hostinganbietern waren nicht betroffen. In beiden Fällen gingen die Versuche von ein- und derselben IP aus, nämlich 195.242.98.180, und liefen vom 02.02.2009 21:27 bis 21:42 bzw. 22:05 Uhr. Die IP gehört lt. whois zu

netnum: 195.242.98.0 - 195.242.99.255
netname: INTERNETWORX
descr: InterNetworx Network
org: ORG-IA541-RIPE

mit Sitz - vermutlich - in den Niederlanden; die angegebenen Mailadressen waren aber alle - möglicherweise fehlkonfigurationsbedingt - nicht erreichbar. Erwähnenswert vielleicht noch, daß auf beiden angegangenen Maschinen der sshd auf einem nicht standardisierten Port lauscht, was das Logfile bisher eigentlich angenehm rauschfrei gehalten hat. Dem Wörterbuchangriff muß also ein Portscan vorausgegangen sein.

Wenn wir mal davon absehen, daß das vielleicht doch für die Zukunft irgendwann einmal nach fail2ban und Konsorten schreit: Ist sonst noch jemanden vergleichbares (damit meine ich dieselbe Ausgangs-IP und einen ähnlichen Zeitraum, vielleicht auch gegen eine bei Strato gehostete Maschine) aufgefallen? Oder hat gar jemand einen Verantwortlichen erfolgreich kontaktieren können?

(Disclaimer: Ich weiß, daß solche Aktionen grundsätzlich nichts besonderes sind. Ich finde allerdings, daß der konkrete Fall - Aufsuchen eines ungewöhnlich plazierten sshd, Aktionen vom selben Host aus nahezu parallel gegen zwei Maschinen beim selben Anbieter - zumindest insoweit aus dem üblichen Rahmen fällt, daß mich interessieren würde, ob das bei mir zwei Zufallstreffer sind oder es eine gezielte Aktion gegen den betreffenden Anbieter war.)

Sie geht, sie geht nicht, das geht gar nicht … Seagate machte es seinen Kunden in den letzten Tagen nicht leicht; erst lange Zeit Dementis, dann die Warnung vor Firmwareproblemen bei den verschiedensten Baureihen, Firmware-Updates, danach der Rückruf für die Updates, neue Updates - und für Kunden mit Seagate Barracuda ES.2-Platten war es die ganze Zeit noch schwerer, gab es doch in der Knowledge-Base nur den Hinweis, welche Firmwareversionen betroffen seien, verbunden mit der Bitte, sich an den Support zu wenden. Der dürfte allerdings mit Mails zugeschüttet worden sein, so daß sich eine gute Woche lang nichts regte.

Inzwischen sieht das aber anders aus, und wenn es außer mir weitere Betroffene mit solchen Platten (SATA-Platten mit den Modellnummern ST31000340NS, ST3750330NS, ST3500320NS und ST3250310NS) geben sollte, sei denen gesagt: auf der entsprechenden Knowledge-Base-Seite gibt es jetzt weitere Informationen, allerdings vorerst nur in der englischen Sprachversion! Wer also auf Deutsch weiter den alten Text geboten bekommt, sollte auf die englische Seite umschalten. Dort werden nun die betroffenen Platten anhand ihrer "Part Number" identifiziert und Links zu Firmware-Updates geboten.

Wer seinen Rechner nicht aufschrauben möchte, um auf dem Etikett der Festplatte die "Part Number" festzustellen, dem kann gleichfalls geholfen werden. Zwar kann die von Seagate angebotene Software DriveDetect sinnigerweise nicht die "Part Number" auslesen, sondern nur Modell, Seriennummer und Firmware-Version, aber Seagate kann diese Informationen offenbar zusammenführen. Jedenfalls kann man auf den Supportseiten seinen Garantiestatus überprüfen lassen; und dort erhält man nach Eingabe von Modell- und Seriennummer (die mit DriveDetect ausgelesen werden können) nicht nur die Restlaufzeit der Garantie angezeigt, sondern auch - ha! - die "Part Number". Damit kann man dann auf der bereits genannten Knowledge-Base-Seite prüfen, ob die eigene Platte betroffen ist, und ggf. die richtige Firmware-Version herunterladen.