Gestern mittag, das war der 6. Januar 2010 erreichten uns die ersten Anruf von Kunden, daß wohl unsere Webserver nicht mehr funktionieren, http://pohle.de wäre nicht erreichbar. Eine kurze Störungsanalyse unsererseits ergab, daß die beiden Nameserver unserer Domänen nicht mehr auf PING und NSLookup Anfragen reagierten.

Das wurde per Twitter Meldung kommuniziert:

An dieser Stelle ist wohl eine Erklärung fällig, warum uns dieser Ausfall betroffen hat:

Wir hosten alle unsere Services selbst in unserem eigenen Rechenzentrum in Dorfen. Dieses ist mit einer Standleitung der Deutschen Telekom an das Internet angebunden. Wir verfügen über eine Ersatzleitung ins Internet über das Vodafone UMTS Netzwerk, ich kann manuell das Routing unseres Datenverkehrs umschalten (eine automatische Umschaltung ist wenig sinnvoll, da die Telekom in den letzten Jahren die wenigen Fehler auf der Leitung schneller behoben hat, als ich hätte umschalten können).

Internet Domänen können wir hingegen nicht selbst registrieren, sondern müssen die Dienste eines sogenannten DNS Providers in Anspruch nehmen, das ist in unserem Fall aus historischen Gründen die ehemalige Schlund und Partner AG (ein Webhoster für Geschäftskunden) heute die Schlund Technologies GmbH mit Sitz in Regensburg, deren Geschäft von der InterNetX GmbH durchgeführt wird.

Da wir alle Domänen über Schlund Technologies beziehen und verwalten, ist es am einfachsten, die DNS Server dieses Unternehmens für die Domänen zu verwenden, Schlund bietet eine geclusterte DNS Infrastruktur an, das hat auch viele Jahre sehr zufriedenstellend funktioniert.

Die erste größere Störung gab es im November 2008, da wurde gegen die DNS Server von InternetX eine DDOS (Distributed Denial of Service) Attacke durchgeführt, welche die DNS Server in die Knie gezwungen hat und die Domänen waren nicht mehr erreichbar. DDOS funktioniert recht einfach, man ballert von vielen, damals waren es 40.000, Rechnern ständig Abfragen an die Server, die unter der Last dann nicht mehr verknünftig arbeiten bzw. so überlastet sind, daß sie die “regulären” Anfragen nicht mehr zeitgerecht beantworten können (siehe auch den Artikel in golem.dedazu).

Das hat zur Folge, daß Rechner, die nach der Adresse für http://pohle.de suchen, keine Antwort vom zuständigen Namens-Server erhalten und einfach zurückmelden, daß die Website http://pohle.de eben nicht erreichbar ist. Nun sieht das für den Endanwender so aus, als wären unsere Server down, dabei ist “nur” das Telefonbuch außer Betrieb, das die gängigen Namen in Netzwerkadressen übersetzt (und aus pohle.de die Adresse 87.139.89.37 macht).

Nach der Attacke im November 2008 hat Schlund Technologies / InternetX den Kunden versprochen, daß entsprechende Maßnahmen getroffen werden, so daß so etwas nicht wieder vorkommen wird. Das ist bei DDOS recht schwierig, denn es handelt sich ja um viele Rechner, die über die ganze Welt verteilt sind und mehr oder weniger reguläre Pakete und Anfragen absetzen. Jedenfalls hat das bis gestern funktioniert und dann, ausgerechnet am bayerischen Feiertag (die sitzen in Regensburg), kommt wieder so eine Attacke und es dauerte bis zum frühen Abend, bis man dies im Griff hatte. Nachdem unsere Server wieder errechbar waren, kommunizierten wir dies auch artig:

Wir haben nun unsererseits Maßnahmen ergriffen und heute den sogenannten “Secondary Nameserver” aller unserer Domänen zu uns umgezogen. Das hat nun zur Folge, daß wir zwar die leistungsfähige Infrastruktur von Schlund/InternetX und die einfache Verwaltung für unsere Domänen verwenden, bei einem Ausfall des Nameserver sollten die zugreifenden Rechner aber den Weg zum alternativen Namensserver finden, der bei uns im Rechenzentrum steht. Wir werden bei der nächsten DDOS Attacke auf Schlund/InternetX sehen, ob das so klappt, wie ich mir das vorstelle.

Warum drücke ich mich so vorsichtig aus? Nun eigentlich ist definiert, daß sich ein Rechner immer den Weg zum Secondary Nameserver sucht, wenn der Primary Nameserver nicht verfügbar ist. So richtig nicht verfügbar sind die Nameserver aber auch nicht, wenn ein Angriff stattfindet, sie reagieren nur furchtbar langsam auf die Anfragen, weil sie so viele haben. Das kann man überprüfen, indem man im Browser immer wieder F5 drückte während der Störung – irgendwann hat es dann auch mal geklappt mit der Namensabfrage. Dadurch, daß die Nameserver “ein wenig” funktioniert haben, ist nicht wirklich sichergestellt, daß die Clients sich in so einem Störungsfall wirklich den Weg zu unserm Secondary Nameserver suchen.

Natürlich läßt sich auch der Fall konstruieren, daß ein DDOS Angriff gegen InternetX/Schlund und gegen unseren Nameserver gleichzeitig stattfindet, dann nützt das natürlich alles nichts. Hoffen wir einfach mal das beste.

Die obigen Ausführungen sind übrigens der Grund, warum wir zwar eine Verfügbarkeitsgarantie für die von uns gehosteten Server anbieten, nicht jedoch eine Garantie für den Zugriff über das Internet.

Für die Techniker unter den Lesern: Wir haben auch die Möglichkeit in Erwägung gezogen, den Primary DNS bei uns zu hosten und den Schlund Server als Secondary zu benutzen – da ist uns der Umstellungsaufwand im Augenblick aber zu groß und der Nutzen nicht direkt erkennbar. Auch könnten wir beide Nameserver bei uns hosten – aber auch hier ist Aufwand und ehrlich gesagt: Der Ausfall gestern war “nur” 8 Stunden…

So ein Hüttenausflug ist ja eine Rückkehr zur Natur, zum einfachen, zum ursprünglichen. Heizen mit dem Holzofen, rundrum nur freie Natur – so soll es sein.

Wenn Christian dabei ist, muß aber ein minimaler technischer Standard eingehalten werden… So ist ein Highspeed Internet Anschluß mit WLAN in der Hütte obligatorisch (realisiert mit UMTS/HSDPA im A1 Netzwerk und verteilt über unseren Linksys UMTS Router):

Auch die Sammlung von iPhones, Handies, Laptops und Netbooks wird in der Hütte zwar auf das allernötigste reduziert, aber das füllt immer noch eine Tischplatte:

Schließlich müssen wir ja zeitnah von unserer Pilotreise “Hüttentraum” im Blog und auf Twitter berichten und unsere Verpflichtungen für Rufbereitschaften für unsere Consultingkunden erfüllen.

Selbstverständlich steht auf unserer Hütte unseren Gästen auch ein Netbook fürs Internet zu Verfügung, bzw. kann bei Bedarf auch der eigene Laptop in unser WLAN eingebucht werden.

Vor kurzem habe ich ja den VM Explorer für das Backup von Virtuellen Maschinen auf ESXi Hosts empfohlen, nun bin ich einmal mehr entzückt, denn es geht noch besser. Mit der neuen Version 1.6.008, die heute erschienen ist, wird die Sicherung von VMs um den Faktor 2-4 beschleunigt. Ich habe die Betaversion schon einige Wochen im Einsatz und die Änderungen sind dramatisch:

• Backup zweier VMs vorher 150 Minuten, jetzt 55 Minuten
• Weitere zwei VMs vorher 48 Minuten, jetzt 21 Minuten

Ich habe natürlich auch den Restore gestestet und eine der Maschinen, die ich gesichert habe, zurückgespeichert, unter neuem Namen registriert, in ein anderes Netzwerk gehängt und hochgefahren. Läuft einwandfrei.

Das einzige, was ein wenig unbequem ist, ist daß man auf dem ESXi nun SSH einschalten muß, und nach dieser Änderung leider den ESXi neu starten muß. In der Hilfe des VM Explorer ist genau beschrieben, wie das geht:

Das läßt sich aber sicher nicht umgehen und in Zukunft weiß ich es von vorneherein, wenn ich einen ESXi einrichte, daß ich sofort SSH einschalte, denn der Geschwindigkeitsunterschied beim Sichern ist das wert.

Der Linksys WRT543G UMTS Router hat einige Optionen, die es, zumindest laut Handbuch, ermöglichen, Fehler in der UMTS Verbindung zu erkennen und diese dann automatisch wiederaufzubauen. Aus meiner Erfahrung mit nunmehr 3 dieser Router bewirken diese Optionen aber, aus ungeklärter Ursache, im Laufe der Zeit genau das Gegenteil.

Man kann hier eine Option setzten “Link Check”, da wird, soweit ich verstanden habe, das UMTS Link überprüft und man kann 2 Server im Internet anPINGen lassen. Ist das erfolglos, dann soll, wie hier eingestellt, nach 5 Fehlerversuchen die Verbindung neu aufgebaut werden und nach 10 Minuten mit Fehlerversuchen soll der Router rebooted werden.

Diese Settings führen bei meinen Routern aber über kurz oder lang dazu, daß die UMTS Verbindung, kein “Mobile Network Bearer” und kein “Network Name” mehr verfügbar ist und der Router, ohne, daß man ihn aus- und einschaltet, keine UMTS Verbindung mehr aufbaut.

Schaltet man all die automatische Linküberwachung hingegen aus, dann bleibt die Verbindung des Routers einwandfrei, auch über längere Zeiträume (beste Zeit bisher: 6 Montate) bestehen:

Wenn man nur wenige WYSE XPe Clients im Einsatz hat und den Aufwand gescheut hat, den WYSE Device Manager zu installieren, so kann man dennoch mit recht wenig Aufwand einen WYSE XPe Client auf die Werkseinstellungen zurücksetzen.

Dazu kann man sich auf der WYSE Downloadseite z.B. für den V90L Client das aktuelle Firmware Image herunterladen und ganz am Ende der Seite den “Wyse Simple Imager” und das dazugehörige Handbuch im PDF Format. Letzteres ist unbedingt zu empfehlen, weil man durch reinen Augenschein nicht zurecht kommen wird.

Üblicherweise hat man einen Windows 2003 oder 2008 Server im Netzwerk und einen DHCP Server hat man auch, so daß die Benutzung des WYSE Simple Imager kein Hexenwerk sein wird. Dieser installiert auf dem Windows Server einen TFTP Server und sich selbst und steuert den TFTP Server fern. Genaue Anweisungen gibt es, wie gesagt, im Handbuch.

Ich möchte nur folgendes empfehlen, das steht zwar im Handbuch, aber wir IT Leute meinen ja immer, daß wir alles besser wissen

• Im Handbuch steht, daß der verwendete Server nur ein Netzwerkinterface haben darf. Das heißt genau: Bei der Installation des WYSE Simple Imager müssen alle Netzwerkinterfaces, die nicht an dem Netzwerk angeschlossen, sind, an welchem später der zu ladende Client angehängt wird, disabled sein. Ansonsten möchte der Client beim Booten garantiert das falsche Interface ansprechen und das läßt sich im Nachhinein im WYSE Simple Imager nicht mehr umstellen, sondern nur so: Deinstallieren, Server rebooten, falsches Interface disablen, Installieren.
• Während der WYSE Simple Imager aktiv ist, schlagen Boot Requests per DHCP fehl. In kleinen Netzwerken ist das nicht schlimm, in größeren Netzwerken oder wenn man länger braucht, weil man mehrere Clients neu laden möchte, sollte man die WYSE Clients und den Server in ein extra Segment bringen. Und: WYSE Simple Imager nach Gebrauch beenden.

Wenn man das alles beachtet, dann funktioniert das so: Der WYSE Imager wird gestartet, das heruntergeladene Boot Image wird eingefügt, dann wird der zu ladende Client gestartet, der booted aus dem TFTP heraus, lädt das Boot Image, restarted, führt ein paar Scripten aus und fertig. Nach 10 Minuten ist er wieder frisch. Prima.

Für das Backup unserer VMs auf dem ESXi Host habe ich ein Produkt gefunden, daß perfekt für ein einfaches und gutes Backup geeignet ist: VM Explorer vom Schweizer Hersteller Trilead. VMExplorer verbindet sich, einmal auf einer Windows Station installiert, mit dem oder den ESX Servern und bietet für jeden Server die Möglichkeit, ein Backup durchzuführen. Dabei wird dann von der VM ein Snapshot erstellt und dieser Snapshot auf den Backup Speicherplatz übertragen, dieser ist in unserem Fall eine 2 TB Festplatte, die an der Windows Station angeschlossen ist.

In der Free Edition war’s das auch schon, man braucht dann die Pro Edition, damit man einen Backup Scheduler aktivieren kann. In diesem legt man dann die Backups nach eigenem Gusto und gewünschter Häufigkeit an. In unserem Falle wird die externe 2 TB USB Festplatte jeden Freitag ausgetauscht und so sind die Backup Jobs darauf ausgerichtet, den Exchange, den SQL Server und die Kundensysteme täglich zu sichern und die restlichen VMs im Laufe der Woche jeweils einmal:

Einmal am Tag schickt VM Explorer dann ein E-Mail mit der Nachricht, ob alle Backups gut verlaufen sind:

Die Sicherungen selbst werden standardmäßig in Verzeichnissen abgelegt, die mit dem Namen der VM und Datum und Uhrzeit der Sicherung gekennzeichnet sind. Hier sind die normalen Dateien der VM abgelegt, diese können dann mit VMExplorer auf den ESXi Host zurückgesichert werden, auch unter anderem Namen, so daß die laufende Instanz nicht beeinträchtigt wird.

Es ist auch möglich, aus dem Sicherungsverzeichnis heraus eine VM mit vCenter Converter ins VMWare Workstation Format zu konvertieren – für Notfälle beim Totalausfall des ESXi sicher eine mögliche Option.

Insgesamt macht das Produkt einen runden Eindruck und ist die Lizenzkosten von 490 EUR absolut wert, wenn man regelmäßige Backups anfertigen möchte. Für Einmalbackups oder gelegentliche Backups von Hand genügt die Free Edition, die es glücklicherweise auch gibt.

Ich habe natürlich auch einige Restore Tests gemacht und dabei festgestellt, daß ich die Option “Compress Disk Files” im Tab “Connection” keinesfalls aktivieren darf, da sonst mein ESXi bei der Rücksicherung abbricht. Die Option ist allerdings standardmäßig beim Einrichten eines Backups auch nicht aktiviert.

Wenn man die Handbücher von McAfee studiert, um genaueres herauszufinden, wie man die Einstellungen für Client Tasks im ePolicy Orchestrator optimal setzt, dann wird man nicht wirklich fündig – ich fand in den Handbüchern zum ePolicy Orchestrator nur Hinweise, wie “Make the desired settings” oder “Change as required”.

Aber, was will ich denn eigentlich:

• Der Agent von McAfee soll installiert werden
• VirusScan soll installiert werden
• Aktualisierungen der Virensignaturen sollen möglichst schnell auf die Clients kommen

So kann ich das aber nicht anklicken, daher habe meine Fragen an McAfee adressiert und eine wirklich unglaublich klare und deutliche Antwort von Ravindra Sharma aus dem Support (Thank you for the Clear and precise Answer) erhalten:

1. Die Option “Run at every policy enforcement” meint, daß immer dann, wenn der Agent sich neue Policies zieht, weil diese geändert wurden oder wenn man “Wake Up Agents” durchführt und dort “Force complete policy and task update” markiert, der Task ebenfalls startet.
2. Ein Deployment Task jeglicher Art hat immer ein Detection Script vorweg, welches prüft, ob die Software / die Dateien, die ausgerollt werden sollen, schon drauf sind. Man braucht also keine Sorge haben, daß ein Virus Scan Setup mehrfach ausgeführt wird.
3. “Run Immediately” bedeutet, daß der Task läuft, sobald der Agent von diesem Task erfährt. Das bedeutet für einen Deployment Task für Virus Scan, daß der Agent diesen durchführt, sobald er selbst installiert wurde (wie auch immer) und zum ersten Mal Kontakt zum ePolicy Server aufnimmt.
4. Die DAT Dateien werden einmal täglich von McAfee aktualisiert, es genügt also, diese auf den Clients auch einmal täglich zu aktualisieren, man sollte sich eine Zeit aussuchen, wo die Clients idle sind, weil das Systemressourcen braucht.

Damit ist es dann schon einfacher, meine eigenen “Recommended Settings” zusammenzustellen:

• Ein Deployment Task für die Aktualisierungen des Agent und Virus Scan (man kann mehrere Software in einen Task eintragen mit dem Pluszeichen rechts). Dieser soll “Run at every policy enforcement” und im nächsten Bild “Run Immediately”.
• Ein Task für Update Signatures, der die Engine und die DAT aktualisiert für die in meinem Netzwerk installierten Produkte, der Läuft “Daily”, ist für 30 Minuten randomized und läuft um 12:30 Uhr PM. So sollten alle Clients im Netzwerk zwischen 12:30 und 13:00 Uhr die aktuellen DAT Dateien ziehen, während wir in der Mittagspause sind. Ein Bild zeigt mehr:

• Den Task für die Rogue System Detection setze ich wieder auf “Run at every policy enfocement” und “Run Immediately”.

So sind meine Anforderungen von oben perfekt umgesetzt und die Clients werden rasch mit Software und im Rahmen der Möglichkeiten mit Updates versorgt.

Es gibt Situationen mit Kunden, die mich tatsächlich überraschen. Heute rief ein Kunde an, er hat ein Netzwerk mit 30 Arbeitsplätzen. Ich war zum letzten Mal vor 4 Jahren dort, das war die letzte Reorganisation des Netzes mit neuer Serverhardware und Aktualisierung aller Software und ich habe seit gut 2 Jahren nichts mehr von dort gehört und wähnte den Kunden bereits in den Händen eines anderen Betreuers.

“Guten Tag Herr Pohle, wir müßten mal wieder unser Netzwerk modernisieren, aktuelle Versionen, vielleicht was Virtualisieren, na, Sie wissen ja, was man heute so macht” – “Gerne, schön, daß Sie an mich denken, Sie haben Glück, ich bin nächste Woche bei Ihnen in der Gegend, da komme ich mal zur Istaufnahme vorbei” – Pause – “Wieso Istaufnahme? Sehen Sie einfach in Ihre Dokumentation, Sie wissen doch, was bei uns installiert ist”

Wenn im HP Insight Manager für DL360 und DL380 Server der “Integrated Lights Out” Port degraded gemeldet wird, weil kein Kabel angeschlossen ist und weil man ihn eigentlich auch garnicht benutzt, dann schaltet man die Überwachung des Ports am besten im Control Panel – HP Management Agenst ab. Dort ist der “Remote Insight Information” zu markieren und mit einem Klick auf “Remove” aus der Überwachung zu entfernen:

Dann ist der Gesamtstatus des Systems (hoffentlich) grün:

In einem lokalen Netzwerk ist es zur Fernsteuerung von Windows-PCs und Windows Servern nicht notwendig, extra ein Remote Control Programm zu installieren. Man kann mit OpenSource Programmen bei Bedarf die benötigten Komponenten auf dem Rechner, der fernzusteuern ist, installieren und starten, dann die Fernsteuerung durchführen und anschließend automatisch die Komponenten wieder deinstallieren, so daß auf dem ferngesteuerten Rechner nichts zurückbleibt.

Die Fernsteuerung an sich läuft mit TightVNC, das ist dasjenige VNC, das über RAS Verbindungen in meiner Erfahrung am besten funktioniert. Das übertragene Passwort geht als Hash über die Leitung, die Fernsteuerungssitzung an sich ist aber nicht verschlüsselt, so daß sich dieses VNC nicht für reine Verbindungen übers Internet eignet. Hier geht’s aber um das Fernsteuern im LAN und da setzen wir die Abhörsicherheit einfach mal voraus.

Zum Aufruf benutzt man nun den “System Tools Remote Control Manager“. Dieser kopiert die VNC Dateien auf den Client Rechner, konfiguriert die Registry, startet den Service und startet dann den Viewer. Das alles wird über eine einfache Textdatei konfiguriert:

Zunächst lädt man STRCM herunter und führt die enthaltene SETUP.EXE aus. Im Programmverzeichnis findet man dann die folgenden Dateien:

Als nächstes lädt man sich das aktuelle TightVNC herunter und installiert es ebenfalls. Man erhält folgendes Installationsverzeichnis:

Aus diesem Verzeichnis habe ich die Dateien VNCHooks.dll, vncviewer.exe und WinVNC.exe genommen und in mein Verzeichnis G:\MOBILE\PSAG\RC kopiert, das auf allen meinen Adminrechnern verfügbar ist.

Aus dem STRCM Verzeichnis habe ich die Dateien strcm.exe und vnctight.rcm genommen und auch dort hineinkopiert:

Das Passwort welches in der Config Datei codiert ist, erhält man, indem man im installierten VNC auf dem Rechner ein Kennwort vergibt:

und den gewonnenen Hash dann aus der Registry auslist:

Zu guter Letzt habe ich noch einen Shortcut angelegt auf die Kommandozeile

G:\MOBILE\PSAG\RC\strcm.exe /rcm=G:\Mobile\PSAG\RC\vnctight.rcm

damit die Fernsteuerung einfach zu starten ist. Ruft man nun diesen Shortcut auf, erhält man den Dialog, in den man den Namen des fernzusteuernden Hosts eingibt:

Nach einer Sicherheitsabfrage, wo man zum Beispiel noch ein anderes Kennwort eingeben könnte:

wird TightVNC auf dem fernen Rechner installiert und gestartet:

und es erscheint die Passwort Abfrage vom Viewer:

Nach erfolgter Fernsteuerung, wenn der Viewer geschlossen wird, werden die Dateien wieder vom Zielsystem gelöscht:

So bleibt auf den Rechnern kein Port offen, es muß kein Programm auf allen Rechnern gepflegt oder aktualisiert werden und man kann trotzdem jederzeit zugreifen. Einzige Voraussetzung, daher empfehle ich das nur für’s LAN: Man hat einen Administrativen Zugriff über einen Netzwerkshare auf den Rechner, einfach gesprochen: Sie müssen den Share Admin$ auf dem Zielrechner erreichen können und dort reinschreiben dürfen.

Diese Programme müssen auf jeden Windows Rechner, PC und Server:

• SysInternals Suite
  • von Microsoft herunterladen
  • ZIP Datei nach “C:\Program Files\SysinternalsSuite” auspacken
  • “C:\Program Files\SysinternalsSuite” in den Pfad aufnehmen

• Showman
  • Download von David Taylor
  • ZIP Datei nach “C:\Program Files\SHOWMAN” auspacken
  • Shoman.exe aufrufen
  • Nach dem ersten Aufruf findet sich ein Menüitem “Usage Pie Chart” im Explorer an jedem Laufwerk/Verzeichnis