restart.sh – Ein Bash Script für zuverlässige Server Restarts

Auf Github ist jetzt ein kleines Bash Script zu finden, welches einen einfachen Zweck verfolgt: Als Teil eines Cronjobs soll es einen Serverprozess zuverlässig neu starten können. Anlass war ein Server, der alle paar Tage eine Instabilität entwickelte, die sich nicht ohne weiteres beheben lies. Der regelmäßige Neustart ‚behebt‘ das Problem, auch wenn er natürlich nur eine Krücke ist. Aber manchmal geht es eben nicht besser…

Ziel des Scripts

Der Script solle in der Lage sein diese Funktion auszuüben:

  1. Den relevanten Prozess finden
  2. Wenn der Prozess läuft das reguläre Stopkommando ausführen
  3. Abwarten, bis sich der Prozess normal beendet. Im konkreten Anwendungsfall brauchte der entsprechende Server für einen regulären Shutdown an die 30 Sekunden
  4. Es darf nicht unendlich lange gewartet werden, um auch bei einem dysfunktional gewordenen Prozess einen Neustart ausführen zu können. Auf der anderen Seite soll der Neustart möglichst rasch erfolgen, sobald sich der Prozess normal beendet hat
  5. Neustart des Prozesses

Implementierung

Das Script restart.sh setzt die Anforderungen mehr oder weniger 1-zu-1 um:

  1. Suchen der PID des Prozesses über ein eindeutiges Muster in der Prozessliste
  2. Wenn die PID gefunden wurde ‚freundliche‘ Beendigung durch das normale Stopkommando (welches vielleicht nur ein „kill $PID“ ist)
  3. Beginn eines Countdowns, bei dem regelmäßig – z. B. jede Sekunde – geprüft wird ob der Prozess noch aktiv ist
  4. Wenn der Countdown eine maximale Laufzeit erreicht wird ein „kill -9 $PID“ abgesetzt und der Prozess damit gewaltsam beendet
  5. Absetzen des Startkommandos und Beendigung des Scripts

Eigentlich eine sehr einfache Funktion, aber ich hatte im Netz nichts gefunden, was mir genau diese Funktion bot.

Inbetriebnahme

Die Implementierung ist unter MacOS erfolgt, auf anderen unixartigen Plattformen sind vielleicht kleine Anpassungen notwendig, insbesondere in Hinblick auf die Verarbeitung der Ausgabe des ps Kommandos. Zusätzlich muss der Prozessname angepasst werden und die Wartezeit, die maximal zulässig sein soll. Siehe dazu die Kommentare in restart.sh.

Um erste Tests ohne Aufwand durchführen zu können wird dummy.sh verwendet. Das ist ein lange laufendes Script, welches sich nicht durch ein einfaches kill beenden lässt. Dazu dummy.sh in einem Terminal starten, restart.sh in einem zweiten und sehen wie sich beide Scripts verhalten.

https://github.com/ihbrune/Restart.sh

Remember my name: Werner Heisenberg

Einer der Podcasts, auf die ich erst kürzlich gestoßen bin, ist Forschergeist. Und über die Folge 34, in der Tim Pritlove mit Ernst Peter Fischer spricht, bin ich wieder an den großen Physiker Werner Heisenberg erinnert worden, dessen Todestag sich in 2016 zum vierzigsten Mal gejährt hat. Was mich nach dem Hören dieser Sendung besonders interessiert hat ist die Frage warum Heisenberg im Vergleich zu anderen Physikern dieser Zeit – insbesondere Einstein, aber auch Schrödinger  – heute einen eher geringen Bekanntheitsgrad hat. Selbst nach dem kurzen Popularitätsschub, der vor einigen Jahren aus einer überraschenden Ecke kam.

Der (etwas) anstrengende, aber inspirierende Podcast

Der Podcast ist hörenswert, er skizziert das Leben und die wesentlichen Stationen von Heisenbergs Wirken in der Zeitspanne zwischen dem Ende des ersten Weltkriegs und dem Ende der Nazizeit. Naturgemäß wird stark auf die entscheidenden Entdeckungen eingegangen (Weiterentwicklung des Atommodells, Unschärferelation), die das Fundament der heutigen Quantenmechanik legten, und die anderen berühmten Personen, mit denen Heisenberg in dieser Zeit in Kontakt steht (Bohr, Pauli, Born, Einstein und viele andere). Tim Pritlove hat mit Ernst Peter Fischer einen Gesprächspartner, der ungeheuer enthusiastisch ans Thema herangeht: Wäre Heisenberg ein heutiger Popstar und Fischer ein 16-jähriger Teenager würde man ihn vermutlich als Groupie oder Fanboy bezeichnen.

Werner_Heisenberg

Fischer – der zahlreiche Bücher zur Wissenschaftsgeschichte geschrieben hat – bemüht sich sehr Heisenberg mit seinen persönlichen Eigenschaften wie der Liebe zur Natur und zur Musik zu zeichnen und ihn so zu ‘vermenschlichen’, also den genialen Physiker, der eine mit anschaulichen Begriffen kaum beschreibbare Theorie entwickelt hat, auf eine Ebene zu holen, auf der man ihn und seine Motivation verstehen kann auch ohne Leistungskurse in Mathematik und Physik besucht zu haben. Dabei zeigt er eine außerordentliche Detailkenntnis.

Was den Podcast dann insgesamt etwas anstrengend macht sind zwei Dinge: Zum einen ist da Peters Fähigkeit ohne Punkt und Komma reden zu können. Selbst Pritlove als im Umgang mit Nerds und Geeks erfahrener Podcaster braucht da etwas bis er wieder in der Lage ist das Thema wo nötig voranzutreiben und die manchmal zu romantisierende Darstellung Heisenbergs zu hinterfragen. Und das ist der zweite Punkt, der zumindest mich beim Hören zunehmend gestört hat:

Peters scheint dem Objekt seiner Bewunderung im Laufe der Zeit so nahe gekommen zu sein, dass es ihm schwer fällt eine kritische Distanz an den Stellen einzunehmen, wo sie vielleicht angesagt wäre. Besonders fällt dies im Teil zu Heisenbergs Verhalten in der Nazizeit auf, bei dem Peters ohne direkten Anlass eine Art ‘Verteidigung’ von Heisenberg vom Stapel lässt, die in der absurden Aussage gipfelt, dass Heisenberg diese Zeit im wesentlichen am schönen Walchensee verbracht habe und dass jeder, der diesen See schon mal gesehen habe, einsehen müsse, dass man da garnicht mehr an Politik (und Krieg und Atombomben und massenhaften Mord) habe denken können.

Das macht den Podcast am Ende etwas unrund, da es den Verdacht weckt hier würde etwas unterschlagen und im Nachhinein hätte man an dieser Stelle sicher einiges mehr unterbringen können, z. B. den ‘Uranverein’, der in der Kriegszeit versuchte die Kernspaltung im Nazideutschland voranzubringen, die Anfeindungen, die Heisenberg von der sogn. ‘Deutschen Physik’ ertragen musste und die gescheiterte Reise zu Bohr nach Kopenhagen, mit der Heisenberg offenbar versuchte die Physiker der Welt zu einem gemeinsamen Verzicht auf eine Forschung an Atomwaffen zu bewegen, und die in einem gründlichen Missverständnis endete.

Aber letztlich haben mich diese Unstimmigkeiten dann dazu gebracht das Thema weiter zu verfolgen:

‘Der Teil und das Ganze’: Heisenbergs Erinnerungen

Der naheliegende Ansatzpunkt um mehr über Heisenberg zu erfahren ist sein Buch ‘Der Teil und das Ganze – Gespräche im Umkreis der Atomphyik’, welches im Jahr 1969 erschien. Dieses Buch ist keine (Auto)Biographie im eigentlichen Sinne, man erfährt daraus z. B. nicht, dass Heisenberg im Jahr 1932 der Nobelpreis verliehen wurde. Auch ist es kein Buch voller Formeln, tatsächlich kommen faktisch keine Formeln vor. Und trotz des Titels, der ja schon von Gesprächen spricht, war die Form dann eine Überraschung für mich: Zumindest anfänglich besteht der Text meist aus fiktiven Dialogen mit verschiedenen Weggefährten, die Heisenberg bis zu vier Jahrzehnte später rekonstruiert um die ihm wichtigen Punkte zu verdeutlichen. Dabei kann ich für mich zwei Schwerpunkte ausmachen:

Über Begriffsbildung in Physik und Philosophie…

Der größte Teil des Buches ist – natürlich – Themen aus der Atomphysik gewidmet. Heisenberg befand sich in jungen Jahren mitten einer Phase der Physik, in der die klassischen Beschreibungsmodelle nicht mehr so recht ausreichten um neu entdeckte Vorgänge in der Nähe des Atomkerns zu erklären. Nicht einmal warum Atome nicht direkt wieder zerfallen und wieso sie sich in den von den Chemikern schon lange beschriebenen Weisen miteinander zu Molekülen verbinden.

Heisenberg gelingt es hier – während eines durch einen Allergieschub erzwungenen Aufenthalts auf Helgoland im Jahr 1925 – die bisherigen Denkmuster abzuschütteln und ein allein an den vorhandenen Versuchsergebnissen orientiertes neues Modell zu entwickeln, welches zu einer der Grundlagen der Quantenmechanik wird. Zwei Jahre später ergänzt er die nach ihm benannte Unschärferelation, die der Genauigkeit von Messungen unterschiedlicher Eigenschaften eines Teilchens eine prinzipielle Grenze setzt, die sich auch nicht durch verbesserte Apparaturen oder Versuchsaufbauten unterschreiten lässt.

Das Jahrzehnt von 1920 bis 1930 nimmt dementsprechend einen großen Raum ein in ‘Der Teil und das Ganze’, wird aber nicht so behandelt, wie man es von einem Physiker vielleicht erwarten würde (wie zumindest ich es erwartet habe): Statt aus Zahlenreihen und Formeln und Verweisen auf wissenschaftliche Arbeiten zu bestehen ist dieser Teil des Buchs eigentlich ein durchgehender philosophischer und erkenntnistheoretischer Diskurs, aufgelockert durch einige persönliche Anekdoten zu den Orten und Umständen, an denen Heisenberg für ihn wichtige Erkenntnisse gewann.

Heisenberg – und seine Dialogpartner, denen er die Worte in den Mund legt, die diese nach seiner Erinnerung vielleicht gewählt hätten – sprechen immer wieder über die Frage inwieweit sich Begriffe aus der anschaulichen Welt, die wir mit unseren Sinnen erfassen können, eigentlich noch tauglich sind um sich über die merkwürdigen Aussagen der Quantenmechanik zu verständigen. Und wenn sie nicht tauglich sind, wie sollen sich dann Physiker untereinander eigentlich darüber verständigen?

Dieser Teil macht auch die intensiven Diskussionen zwischen den Physikern sichtbar, die oft zunächst nur Theorien diskutieren oder Konstrukte, mit denen sich zwar immer besser rechnen und immer mehr Dinge erklären (oder nur errechnen?) lassen, für die aber die menschliche Anschauung keine rechten Bilder liefern will.

…zur Frage der persönlichen Rechtschaffenheit in schwierigen Zeiten

In anderer Hinsicht interessant ist dann der Teil, der sich mit der Nazizeit beschäftigt: Heisenberg bleibt in Deutschland und stellt dies als bewusste Entscheidung dar, die er u. a. durch Gespräche mit Planck gefunden habe. Abgesehen von der politischen Lage sehen sich die Physiker durch Otto Hahn’s Entdeckung der Kernspaltung im Jahr 1938 sehr schnell vor diese Fragen gestellt:

  1. Wie kann damit einen ‘Supersprengstoff’ bauen?
  2. Ist es moralisch vertretbar beim Bau einer Atombombe mitzuwirken?

Beim ersten Punkt unterläuft den in Deutschland verbliebenen Physikern ein merkwürdiger Fehler, der die entsprechenden Forschungen in eine Sackgasse treibt. Beim zweiten Punkt können die Beteiligten vor sich selbst und der Nachwelt zu der Ausrede greifen, dass Nazideutschland im Krieg gar nicht die industriellen Ressourcen gehabt habe, die für den Bau einer solchen Waffe notwendig sind.

Man muss dabei den Punkten, die Heisenberg für sich und andere vorbringt, nicht folgen. Aber man erhält im Buch einen Einblick in diese Zeit, die es einem erlaubt vor einer Verurteilung Heisenbergs und der anderen darüber nachzudenken, wie man sich wohl selbst verhalten hätte.

Auch der letzte Teil des Buches – der die Nachkriegszeit in der noch jungen Bundesrepublik behandelt – widmet sich sehr stark dem Verhältnis von Atomphysik und Politik, dieses Mal zunächst in der Frage der zivilen Nutzung der Kernspaltung, dann aber auch der heute fern wirkenden Diskussion über eine nukleare Aufrüstung der Bundeswehr, in welcher der ‘Atomminister’ eine wichtige Rolle spielt.

Warum ist Einstein so viel berühmter?

Im Podcast beklagt Fischer die – aus seiner Sicht ungerechtfertigte – geringe Präsenz Heisenbergs im öffentlichen Bewusstsein, insbesondere im Vergleich zu Einstein. Diesen Eindruck kann man sich im Netz leicht bestätigen lassen, z. B. über die Google Trends:

Google_Suchetrends_seit_2004_Heisenberg_Einstein_DE

 

Hier zeigt die rote Linie die aus Deutschland kommenden Suchen nach ‘Einstein’ und die blaue nach ‘Heisenberg’. Der Abstand ist immer enorm. Ein ähnliches Bild zeigt sich im Ngram Viewer von Google Books:

Google_Ngram_Heisenberg_Einstein

Diese Anzeige ist auf deutschsprachige Publikationen beschränkt, aber selbst hier kommen die beiden Linien sich nur ein einziges Mal nahe und zwar mitten im 2. Weltkrieg, als Einstein in Nazideutschland zum Feindbild aufgebaut wurde. Als letzter Test mag die Google Bildersuche dienen: Während man beim Suchbegriff ‘Albert Einstein’ etliche Bilder findet, die wohl fast jedem auf Anhieb bekannt sind…

Google_Suche_Albert_Einstein

..ist das bei der Suche nach ‘Werner Heisenberg’ nicht der Fall:

Google_Suche_Werner_Heisenberg

Aber warum ist das so? Sind die Entdeckungen Einsteins wichtiger als die von Heisenberg? Wenn man die Wichtigkeit als Einfluss auf unser heutiges Leben definiert, dann ist die Quantenmechanik – für die Heisenberg entscheidende Grundlagen geschaffen hat – als Basis für die heutige Elektronik möglicherweise wichtiger als die Entdeckungen Einsteins, denn bald wird jeder Mensch über sein Smartphone und das Internet mit den Resultaten in Verbindung stehen.

Allerdings sind die Effekte der Quantenmechanik so kompliziert zu erklären, siehe die langen Diskussionen, die selbst die besten Physiker ihrer Zeit in ‘Der Teil und das Ganze’ darüber führen, dass Normalsterbliche kaum eine Chance haben zu verstehen worum es dabei geht. Am bekanntesten ist da vermutlich noch das Gedankenexperiment von Schrödinger, welches als ‘Schrödingers Katze’ bekannt geworden ist, und das eigentlich ein Lächerlichmachen der Aussagen der Quantenmechanik darstellt, in dem es ihre Ausssagen in die makroskopische Welt überträgt, wo sie nichts verloren haben.

Hingegen haben Aspekte von Einsteins Relativitätstheorie wie die Zeitdilatation vielfältigen Eingang in die Popkultur wie die Science Fiction gefunden: Ganze Romane wie ‘Der ewige Krieg’ bilden ihre Handlung um diesen Effekt ab und machen ihn damit vermutlich für viele Menschen ‘erlebbarer’ als die merkwürdige Welt der Elementarteilchen.

Bei Einstein kommt aber vermutlich noch viel stärker zum tragen, dass er zu einer Art prototypischem Genie stilisiert wurde und das bis heute: Will man jemanden als hochintelligent bezeichnen, so nennt man sie/ihn einen Einstein. Vergleichbares ist mit Heisenberg nie passiert.

Heisenberg und ‘Breaking Bad’

Der Bekanntheitsgrad des Namens ‘Heisenberg’ hat allerdings seit 2009 eine interessante Steigerung erfahren: In diesem Jahr startete in den USA die zweite Staffel der Serie Breaking Bad. Dort legt sich der Protagonist Walter White für seinen Einstieg in den Drogenhandel das Alias ‘Heisenberg’ zu und verbreitet fortan Angst und Schrecken (und erfährt selbst ein gerüttelt Maß davon). Die Serie hat auch in Deutschland großen Erfolg und für einige Zeit einen wesentlichen kulturellen Einfluss, was sich zum Beispiel daran ablesen ließ, dass Breaking Bad Themen damals den regelmäßigen Posterverkauf in der Uni Bielefeld dominierten:

BreakBadPosterverkauf

Es bleibt abzuwarten, ob dadurch der Name ‘Heisenberg’ einen dauerhaft gesteigerten Bekanntheitsgrad erreichen und wenn ja welche Assoziationen er dabei auslösen wird: Drogen oder Quantenmechanik? Das Ergebnis der Google Bildersuche zum Wort ‘Heisenberg’ hat die Serie jedenfalls schon nachhaltig beeinflusst:

Google_Suche_Heisenberg

Sinn und Unsinn von Stagingkonzepten

Der CommitStrip bringt es auf den Punkt:

I’m not sure wether I should feel proud, or worried..
CommitStrip vom 10.02.2017: ‚Proud or worried?‘

Bis zu welchem Grad ist der Aufbau von Staging Umgebungen nützlich, und ab wann ist die Stelle erreicht, ab der der Betrieb und die Komplexität zu viel kosten? Oder umgekehrt: Wann lohnt es sich eigentlich ein Staging einzuführen, wenn man – wie wir – bisher keines hat?

Warum wir (bisher) kein Staging haben

Tatsächlich haben wir in dem umfangreichen Softwareprojekt, welches ich leite, bisher gar kein echtes Staging, faktisch gibt es nur das produktive System und die jeweiligen Entwicklungssysteme. Warum das bei uns so funktioniert würde ich mit diesen Punkten erklären:

Softwarequalität

Das beste Argument gegen ein Staging ist sicher eine hohe Softwarequalität: Wenn (fast) nie Fehler passieren (oder sie niemand bemerkt, weil sie so schnell behoben werden), dann wird auch niemand nach zusätzlicher Qualitätssicherung rufen. Die Softwareentwicklung wird bei uns von einem kleinem Team geleistet, welches teilweise schon sehr lange im Thema ist und dementsprechend erfahren ist. Häufige Releases mit entsprechend kleinen Entwicklungsschritten vereinfachen die Qualitätssicherung, da sie die Komplexität der einzelnen Schritte deutlich reduzieren. Die häufigen Releasezyklen werden durch eine Aufteilung des Produkts (hier ein Campusmanagementsystem) in viele Teilmodule erreicht, die weitgehend unabhängig voneinander sind (trotz einer in weiten Teilen gemeinsamen Codebasis).

Agilität

Bei uns fallen Softwareentwicklung und Serverbetrieb zusammen. Wenn es tatsächlich Fehler in die Produktion schaffen sind wir handlungsfähig und machen meist gar kein Rollback, sondern erstellen direkt eine neue Version mit entsprechender Fehlerkorrektur. Möglich ist dies durch eine Serverstruktur, die es erlaubt zu jeder Zeit für die Benutzer unmerkliche Updates durchzuführen, die nicht lange geplant oder angekündigt werden müssen.

Freigabeprozesse

Die Zuständigkeiten für das Produkt und die inhaltlichen wie technischen Kompetenzen für die Weiterentwicklung sind bisher nahezu komplett im Team gebündelt. Bei neuen Releases müssen daher nur selten Freigaben durch Key User eingeholt werden. Und falls doch, so wird dies auf den Entwicklungssystemen in direktem Kontakt gemacht. Da wir ein hausinterner Dienstleister sind und sich unsere Ansprechpartner in räumlicher Nähe befinden können wir so vorgehen.

Java

Das ‚Java Versprechen‘, wonach eine auf einer Plattform entwickelte Software auch problemlos auf einer anderen laufen wird, hat sich für uns weitgehend erfüllt: Heute findet die Entwicklung unter Windows statt und verwendet eine PostgreSQL Datenbank, während das produktive System unter Solaris und einer anderen relationalen Datenbank betrieben wird. Insgesamt gab es in der langen bisherigen Projektlaufzeit nur extrem selten Probleme, die sich auf den Entwicklungssystemen nicht nachstellen ließen. Diese wenigen Probleme waren so komplex, dass eine Nachstellung in einer Staging Umgebung mit einem enormen Aufwand verbunden gewesen wäre.

Backup

Um das Risiko von fatalen Fehlern, die es in die Produktion schaffen sollten, zu minimieren, ist ein leistungsfähiges und zugreifbares (!) Datenbankbackup essentiell. Mit fatalen Fehlern meine ich dabei solche, die Datenbankinhalte vernichten oder unmerklich korrumpieren. Ein solches Backup muss bei einer komplexen Anwendung in der Lage sein ohne großen Aufwand jederzeit Teildaten in verschiedenen Versionsständen zu liefern.

Unittests

Man kann nie genug automatisierte Tests haben, aber an bestimmten entscheidenden Stellen haben wir sie und können damit auch nach Systemänderungen sicher sein, dass diese Programmierungen noch korrekt funktionieren. 

Was einem das Staging verleiden kann

Es gibt viele Gründe Staging Konzepte einzusetzen, einen guten Teil nennt der Comic Strip bereits: Entwicklungssysteme, Testsysteme mit verschiedenen Zielsetzungen, Demosysteme, Freigabesysteme, etc. Und in den meisten Konstellationen wird man auch nicht ohne Staging auskommen. Was einem an der ganzen Sache den Spaß verderben (oder die Aufwandskalkulation für die entsprechenden IT Abteilungen nach oben treiben) kann, sind dann u. a. diese Punkte:

Wer kümmert sich um die Server?

Auch wenn es ‘nur’ ein interner Testserver ist: Irgendjemand muss ihn warten. Wird er nicht gewartet, so ist er ein zukünftiges Einfallstor für Angreifer, selbst wenn er sich tief in internen Netzen befindet. Mit jeder Stage wächst die Zahl der Server, um die sich irgendjemand kümmern muss. Falls man den Versuch unternimmt Stages aufzubauen, die der produktiven Umgebung sehr nahe sind, kann die Zahl der zusätzlichen Server enorm werden, vor allem wenn für verbundene Systeme wie Datenbanken, Identity Provider etc. ebenfalls entsprechende Staging Umgebung aufzubauen sind. Gut, wenn man hier schon eine Automatisierungslösung im Einsatz hat, die dies vereinfacht.

Echtdaten für Stages

Schnell wird man bei dem Wunsch landen in nicht-produktiven Stages die Daten des Produktivsystems zur Verfügung zu haben. Solche Daten(und ggf. Konfigurations-)kopien anzulegen erzeugt mindestens initial Aufwände für die Inbetriebnahme.

Wenn es sich um personenbezogene Daten handelt wird man sich zusätzlich den Fragen der Datenschutzbeauftragten stellen müssen. Und landet schnell bei einem Schutzbedarf der nicht-produktiven Stages, der dem Schutzbedarf der produktiven Stages in nichts nachsteht, denn auch von solchen Stages können sensible Unternehmensdaten abhanden können. Alternativ müssen Pseudonymisierungsverfahren entwickelt werden, damit die Echtdaten so unkritisch werden, dass sie auch in weniger geschützten Umgebungen genutzt werden können.

Wenn man es irgendwie vermeiden kann (Unittests, Generierung realistischer Testdaten) sollte man die Echtdatenübernahme in andere Stages vermeiden.

Enttäuschte Erwartungen I: Key User

Bei einer starken Aufgabenteilung zwischen IT Betrieb und Key Usern entsteht gelegentlich die Erwartung der IT, dass die Key User neue Versionen einer Software über eine für sie bereitgestellte Stage ausgiebig testen und damit in gewisser Weise die ‘Verantwortung’ übernehmen, dass die Software korrekt funktioniert. Die Frage ist allerdings inwieweit diese Erwartung realistisch sein kann? Key User, die per Definition ExpertInnen in dem fraglichen Themenfeld sein müssen, sind erfahrungsgemäß sowieso in ihren Abteilungen stark belastet und werden Besseres zu tun haben als neue Releases systematisch zu testen. Funktionieren kann so ein Konzept höchstens wenn es darum geht Weiterentwicklungen im Einzelfall abzunehmen. 

Enttäuschte Erwartungen II: Lasttests

Ein weitere Enttäuschung droht im Bereich von Lasttests. Gerade bei neuen, unbekannten Systemen kann der Wunsch entstehen die notwendige Dimensionierung der Infrastruktur vorher durch synthetische Belastungstests ermitteln zu wollen. Hier gibt es zwei grundlegende Schwierigkeiten:

  1. Wie erzeuge ich realistische Lasten? Bei einem schon laufenden System kann ich versuchen in den vorhandenen Protokollierungen Nutzungsmuster zu finden, die mir ein Testdesign ermöglichen. Bei Systemen mit vielen Nutzern kann es trotzdem schwierig sein die gefundenen Nutzungsmuster in realistischer Weise in einem Test auszuführen (wie simuliere ich Zugriffe von tausenden von Clients aus unterschiedlichen Netzen?).
  2. Wie erzeuge ich eine realistische Staging Umgebung? Bei einem System, welches sich im Aufbau befindet, kann ich vor der Inbetriebnahme die produktive Stage für entsprechende Tests verwenden. Nach der Inbetriebnahme ist das natürlich kaum noch möglich. Eine Stage für realistische Lasttests aufzubauen kann eine Duplizierung weiter Teile der unterstützenden IT Infrastruktur erfordern und lässt einen schnell bei der Forderung nach Echtdaten landen.

Im Endeffekt hat man ein hohes Risiko kein angemessenes Ergebnis für den erbrachten, erheblichen Aufwand zu erhalten. In vielen Fällen wird man vermutlich besser fahren, wenn man seine Systemarchitektur so aufstellt, dass auf unerwartete Lasten rasch reagiert werden kann. Dies ist mit heutigen Virtualisierungskonzepten auch normalerweise problemlos möglich.

Warum wir vermutlich doch (irgendwann) ein Staging haben werden

Aber auch für uns wird sich das Thema ‘Staging’ in Zukunft neu stellen. Ein wichtiger Treiber ist dabei die Idee Deployments unseres Produktes in Zukunft automatisieren zu können (CI/CD).

Everyone has a test environment. some are lucky enough to have a production environment too
@stahnma auf Twitter am 22.08.2015

Ein erster Schritt in diese Richtung wäre daher eine ‘Demo- oder Reviewstage’, die automatisiert die jeweils aktuell in der Versionskontrolle befindlichen Versionen unserer Anwendungsmodule verwendet, so dass sie sich schnell vorführen und prüfen lassen. Ggf. könnte man hier auch gleich weiter denken und diese Stage für verschiedene Branches verfügbar machen.

Ein anderer Treiber ist die durch Organisationsveränderungen fortschreitende funktionale Differenzierung im IT Betrieb, die die Serveradministration in andere Hände legen wird. Auch hier ist möglicherweise ein Staging ein Mittel um sowohl die Produktqualität, die Handlungsfähigkeit und die Releasegeschwindigkeit hoch halten zu können.

Google baut eine eigene Root-CA auf

Vor ein paar Tagen hat Google in seinem Security Blog bekannt gegeben selbst zu einer Zertifizierungsstelle (Certificate Authority / CA) zu werden. Diese kann man unter der Adresse https://pki.goog/ erreichen. CAs sind heute entscheidende Stellen in der Public Key Infrastructure (PKI) des Webs, die erst die sichere Kommunikation z. B. zwischen Webbrowser und Webserver ermöglichen.

Welches Problem will Google damit für sich lösen?

Google ist zum einen ein Unternehmen, welches einen enormen Bedarf an Zertifikaten hat, der durch zwei Faktoren bedingt wird:

  1. Die schiere Anzahl der zu sichernden Onlinedienste
  2. Googles schnelle Zertifikatsrotation, die Zertifikate heute nach 3 Monaten auslaufen lässt

Dann hat Google das Thema der IT Sicherheit wie kaum ein zweites Unternehmen im Blick und treibt es an allen Ecken voran, auch im Bereich der Zertifizierungsstellen. Gleichzeitig sind Google Zertifikate oft das Ziel bei Kompromittierungen von Zertifizierungsstellen, da Googles Dienste nun mal von vielen Nutzern besucht und damit für Angreifer besonders wichtig sind.

Google hat hier  in den letzten Jahren über seine Marktmacht mit Chrome als dominierendem Webbrowser und Android als dominierendem Mobilbetriebssystem immer mal wieder kräftig an den Zügeln gezogen, wenn eine CA Mist gebaut hat.

Was stimmt nicht mit mit dem heutigen System der Zertifizierungsstellen?

Das heute existierende System der Zertifizierungsstellen ist in der Lage unsere Webbrowser-Webserver-Kommunikation gegen massenhaftes Abhören zu sichern, wenigstens seit es Initiativen wie Let’s encrypt gibt, die Serverbetreibern die dazu notwendigen Zertifikate kostenfrei und mit geringem Aufwand automatisiert zur Verfügung stellen können. Die Verschlüsselung ist aber nur der eine Aspekt bei einer PKI: Der andere ist die Sicherstellung der Authentizität meines Kommunikationspartners. Damit ist gemeint, dass ich – wenn ich z. B. auf ‘https://www.google.com’ gehe – auch tatsächlich direkt auf einer zu Google gehörenden Webseite lande, und nicht auf einer gefälschten Seite bzw. über einen mithörenden Mittelsmann kommuniziere.

Hier kommen die CAs ins Spiel, die mir garantieren sollen, dass das Zertifikat, welches mir beim Besuch von google.com präsentiert wird, auch tatsächlich Google gehört. Eine CA kann dabei ihre Aufgabe nur erfüllen, wenn sie es schafft mit ihren Wurzelzertifikaten in die gängigen Webbrowser und Betriebssysteme aufgenommen zu werden. Damit ihr das gelingt muss sie ihre Sorgfalt bei der Vergabe von Zertifikaten beweisen.

So weit, so gut. Ein grundlegendes Problem ist dabei allerdings, dass mein Webbrowser danach zunächst jeder der mitgelieferten CAs uneingeschränkt vertraut. Dies sind im Firefox heute mehr als 150 Zertifikate von mehr als 50 Herausgebern und jedes Zertifikat – und sogar davon abgeleitete Unterzertifizierungsstellen – ist in der Lage ein ‘gültiges’ Zertifikat für google.com zu unterzeichnen. Natürlich muss so etwas immer mal wieder schief gehen, Beispiele siehe oben.

Google hat hier in den letzten Jahren in mehreren Schritten versucht diese Probleme zumindest teilweise in den Griff zu bekommen:

  • Certificate Pinning in Chrome: In Chrome ist ein kleines Set von CAs fest einkodiert, die prinzipiell für Google Zertifikate ausstellen könn(t)en. Dadurch hat sich Chrome in den vergangenen Jahren immer wieder als Melder von Verstößen gegen die Sicherheit oder die Regelungen von CAs erwiesen.
  • Dieser Ansatz ließ sich natürlich nicht auf das komplette Web skalieren, von Google kommt daher das inzwischen in einem RFC definierte HPKP, welcher aber noch nicht alle Browser unterstützen. Auch schützt es Benutzer nicht beim ersten Besuch einer Webseite.
  • Abkehr von SHA-1: Die Ablösung von SHA-1 als Signaturalgorithmus für Zertifikate wurde von Google besonders aggressiv vorangetrieben.
  • Certificate Transparency (CT): Dieses Projekt beschreibt wie ein endloses Logbuch aller jemals von CAs ausgegebenen Zertifikate effizient geführt und online zugreifbar gemacht werden kann. Es gibt eine Implementierung von Google, aber inzwischen auch von CAs. Certificate Transparency ermöglicht es Webseitenbetreibern gezielt zu prüfen ob für ihre Webseiten illegitime Zertifikate ausgestellt wurden.
  • Chrome und CT: Google hat für den Herbst 2017 angekündigt, dass Chrome beginnen wird bestimmte Zertifikate nur noch dann zu honorieren, wenn die Certificate Transparency verfügbar ist.

Google hat die CAs hier in den letzten Jahren teilweise vor sich hergetrieben und sich damit durchaus einiges an Kritik eingefangen. Für Google selbst ist der Aufbau einer eigenen CA vermutlich nur ein letzter Baustein in einem System, dass sie bereits mit einem Browser (Chrome), Betriebssystemen (Android, ChromeOS), Protokollen (SPDY und QUIC) und einigen der wichtigsten Internetdienste der Welt nahezu vollständig im Griff haben und weiterentwickeln möchten. Google schafft sich damit nun auch an dieser Stelle ein eigenes Experimentierfeld, in dem sie beweisen können, dass sich ihre Ideen für die Zukunft des Netzes in großem Maßstab umsetzen lassen.

Wird Google Zertifikate frei anbieten bzw. verkaufen?

Abgesehen vom Vorantreiben der Internetsicherheit wird Google seine PKI sicher in Zukunft mit anderen Diensten wie der Domänenregistrierung verknüpfen. Unklar ist allerdings ob sie tatsächlich zu einer CA werden wollen, die jedem Zertifikate anbietet.

Aus dem Policy Dokument der Google PKI kann man nach meinem Verständnis entnehmen, dass Google zumindest zur Zeit nicht mit kostenfreien Angeboten wie Let’s encrypt konkurrieren will. Ich lese das aus der Beschreibung des Verfahrens zur Überprüfung der Identität von Antragsstellern bei der Zertifikatsbeantragung. Hier gibt es u. a. einen Aspekt, der eine Überprüfung der postalischen Adresse fordert. Das ist ein über die Domänenvalidierung der Gratisdienste hinausgehender Schritt, der sich nicht voll automatisieren lässt.

Meine Vermutung ist daher, dass Google zumindest mittelfristig nicht mit den existierenden CAs in direkte Konkurrenz treten, sondern seine CA nur für die eigenen Dienste nutzen wird. Auch damit wird diese CA allerdings schnell zu einer der CAs werden, deren Zertifikate den größten Teil des Internetverkehrs sichern.

Wann werden die Google Root Zertifikate in Webbrowsern auftauchen?

Google selbst weist in seinem Blogpost darauf hin, dass es einige Zeit dauert die Wurzelzertifikate für eine neue CA zu verbreiten. Hier müssen zunächst die großen Browseranbieter überzeugt werden die Zertifikate aufzunehmen. Gleiches gilt für die Betriebssystemhersteller (praktischerweise in einigen Fällen die gleichen Unternehmen). Und es müssen noch viele andere Dinge wie die Updategeschwindigkeiten der jeweiligen Produkte bedacht werden. Vermutlich wird man die Zertifikate zuerst in den Google-eigenen Produkten wie Chrome, ChromeOS und Android finden können, auch wenn Google bei Mozilla den entsprechenden Prozess schon im letzten Dezember angestoßen hat.

Google ist allerdings nicht dafür bekannt Dinge, die sie unbedingt wollen, von den Zeitplänen anderer abhängig zu machen. Daher hat man zwei bereits in Browsern und Betriebssystemen vorhandene Wurzelzertifikate gekauft und kann mit diesen schon jetzt nach eigenem Gutdünken verfahren. Faktisch ist damit Google bereits zur Root CA geworden. Der vorherige Screenshot zeigt eines dieser Zertifikate in Chrome.

Was soll man von der ganzen Sache halten?

“You can now have a website secured by a certificate issued by a Google CA, hosted on Google web infrastructure, with a domain registered using Google Domains, resolved using Google Public DNS, going over Google Fiber, in Google Chrome on a Google Chromebook. Google has officially vertically integrated the Internet.” – aduffy, 27.01.2017 auf ycombinator

Auf ycombinator findet man eine sehr ausführliche und meist gute Diskussion zu der Frage welche Auswirkungen dieser Schritt hat. Natürlich gibt es viele, die das zitierte Szenario eines über alle Ebenen des Internets integrierten Konzerns für bedrohlich / monopolistisch halten. Andere stellen die Frage warum man Google eigentlich so viel Vertrauen entgegen bringen sollte um nun auch noch ihrer CA zu trauen?

Die zweite Frage ist dabei für mich die einfachere: Wenn ich von meinem Android Smartphone über eine Google Suche eine Seite im Chrome Browser öffne vertraue ich Google sowieso schon sehr, sehr weitgehend. Wenn Google dann auch noch die Zertifikate verantwortet, die wenigstens die Google Dienste schützen, fällt für mich eine Stelle weg, der ich bisher auch noch vertrauen musste (die zuvor verwendete CA). Das ist eine Verbesserung.

Die Frage der Machtkonzentration bzw. des Monopols ist da wohl eher eine Gefühlsfrage: Aus meiner Sicht hat Google das Thema der Internetsicherheit in den letzten Jahren sehr vorangebracht und ist dabei in schwierigen Fragen wie z. B. der Bestrafung von versagenden CAs mehr oder weniger auf der richtigen Seite geblieben. Mit einer eigenen CA kann Google im besten Fall demonstrieren wie eine leistungsfähige und sichere PKI aussehen kann. Ich sehe das Ganze also positiv.

Eine andere Frage ist vielleicht die, ob dadurch CAs verschwinden werden? Heute sehen sich die existierenden Zertifizierungsstellen am unteren Ende durch Let’s encrypt bedrängt, welches für viele Webdienste Zertifikate in vollkommen ausreichender Qualität bereitstellt. Am oberen Ende mag es in Zukunft eine Konkurrenz durch die Google CA geben, aber nicht ohne Grund haben viele Länder eigene CAs gegründet und werden die ganz unabhängig von einem Google Angebot betreiben. Wenn dafür einige der kleineren CAs, die möglicherweise Probleme damit haben einen seriösen Betrieb zu leisten, am Ende verschwinden, so ist das für die Sicherheit des Internets dann eher gut.

Anti-DoS Tomcat Valve auf Github veröffentlicht

Auf Github findet sich jetzt unter dem Namen Anti-DoS Valve ein Werkzeug, welches beim Betrieb von Tomcat Servern nützlich sein kann um diese vor Überlastungen durch böswillige Akteure im Netz zu schützen. Dazu implementiert das Valve eine dynamische Zugriffsratenlimitierung, die sich umfangreich konfigurieren lässt. Zur Simulation der Auswirkungen unterschiedlicher Konfigurationen habe ich ein Google Drive Sheet veröffentlicht. Der Code steht unter der Apache Lizenz, kann also frei verwendet werden.

Woher kommt die Idee

Das Valve ist eine verallgemeinerte Version einer kleinen Programmierung, die ich im vergangenen Jahr kurzfristig erstellen musste, nachdem unsere Server immer mal wieder unter Überlastungen litten, die offenbar durch auf gekaperten Rechnern laufende Webcrawler verursacht wurden. Diese Zugriffe waren teilweise so aggressiv, dass sie Auswirkungen auf unsere regulären Nutzer hatten.

Zur Begrenzung dieser unwillkommenen Zugriffe standen zunächst unterschiedliche Optionen im Raum, aber die Option ein Tomcat Valve zu implementieren setzte sich am Ende aus diesen Gründen durch:

  • Ein Valve ist durch seine Verortung im Tomcat Server nahe an der Geschäftslogik bzw. an den Leuten, die wissen was auf dem Applikationsserver läuft. Eine Verortung etwa auf Netzwerkebene hätte einen nicht unerheblichen Wissenstransfer zwischen unterschiedlichen IT Bereichen erfordert
  • Da es sich bei den Angriffen – auch böswillige Webcrawler kann man dabei als Angreifer sehen – nicht um umfangreiche (D)DoS Angriffe handelte war eine Gegenmaßnahme auf Ebene der Applikationsserver ausreichend
  • Der Aufwand für die Programmierung des Valves war auf Grund der vorhandenen Erfahrungen vergleichsweise gering
  • Der Einsatz eines Filters mit identischer Funktion, der innerhalb der Webapplikationen eingesetzt würde, erzeugt im Vergleich zu einem Valve einen höheren Aufwand in der Konfiguration

Was macht das Valve

Ziel ist es unwillkommene Belastungen der eigenen Server so weit begrenzen zu können, dass sie nicht mehr in der Lage sind negative Auswirkungen auf die regulären Nutzer zu entfalten. Dabei soll die Schutzfunktion dynamisch sein, sich also selbstständig auf neue Angreifer einstellen und diese blockieren können. Und schließlich soll der Overhead dieser zusätzlichen Filterung, die zunächst für alle im Tomcat Server eingetreffenden Requests anspringt, möglichst klein sein. In der aktuellen Version arbeitet das Valve dabei auf der Ebene einzelner IP Adressen, für die Limitierungen durchgesetzt werden können.

Für die konkrete Implementierung wurden dann Erfahrungen genutzt, die ich früher bei anderen Programmierungen zu Ratenlimitierungen gemacht hatte, insbesondere beim Aufbau unserer Identity Provider Infrastruktur und der dort durchgesetzten Begrenzung der Anzahl von möglichen Versuchen zum Erraten eines Passworts.

Um die Implementierung ressourcenschonend zu gestalten – insbesondere in einer DoS Situation, wo schnell abertausende von Requests in kurzer Zeit eintreffen können – wird für die Ermittlung der aktuellen Zugriffsrate einer IP Adresse keine gleitende Auswertung gemacht, sondern es wird nur über die Anzahl der Zugriffe innerhalb eines bestimmten Zeitintervalls (in der Programmierung Slot genannt) Buch geführt. Wird innerhalb eines solchen Slots die Anzahl der erlaubten Zugriffe überschritten, so werden alle weiteren Zugriffe bis zum Ende des Slots abgelehnt. Damit nicht mit jedem neuen Slot das Spiel von vorn beginnt kann ein Anteil der in früheren Slots gezählten Zugriffe übernommen werden. Auf diese Weise sind sowohl die Datenhaltung im Valve wie auch Rechenaufwand gering und nehmen auch in einer Hochlastphase nicht wesentlich zu.

Über die Konfigurationsoptionen können dabei nahezu alle Eigenschaften gesteuert werden, neben dem Grenzwert der Zugriffe pro Slot auch die Slotlänge und der Umfang der aus früheren Slots übernommenen Requestanzahlen. Mit diesem einfachen Mittel lassen sich durchaus komplexe Filterungen realisieren.

Es gibt im Valve noch weitere Optionen, über die sich steuern lässt auf welchen Adressen die Ratenlimitierung überhaupt wirksam werden soll (hier kann man z. B. Requests auf statische Inhalte wie JS oder CSS Dateien ausschließen um schärfere Einstellungen zu realisieren) und ob bestimmte IP Adressen oder Adressbereiche generell von einer Filterung ausgenommen werden sollen (z. B. Adressen aus dem Intranet, um interne Nutzer nie zu beeinträchtigen).

Wie legt man los

Während die grundsätzliche Inbetriebnahme des Valves sehr einfach ist (Clone von Github, Ausführen von Maven Install, JAR in Tomcat/lib Verzeichnis kopieren, Valve Konfiguration in server.xml ergänzen), liegt die eigentliche Herausforderung darin die für den eigenen Anwendungsfall passenden Konfigurationsparameter zu finden. Hier gilt es die richtige Balance zu finden zwischen zu engen Einstellungen, die auch die regulären Benutzer beeinträchtigen können, und zu offenen Parametern, die die Angreifer nicht richtig im Zaum halten können und damit auch wieder die regulären Benutzer beeinträchtigen.

In der README findet sich ein eigener Abschnitt dazu, wie man bei der Inbetriebnahme vorgehen kann. Der Kernpunkt ist es hier ein ausreichendes Wissen über die reguläre Nutzung der eigenen Dienste zu haben, also welche Zugriffszahlen OK sind und welche ein böswilliges bzw. störendes Level erreichen. Die Auswertung der Tomcat Access Logfiles ist dabei der Schlüssel. Hat man diese Werte kann man in dem Simulator Sheet vergleichen welche Auswirkungen eine bestimmte Konfiguration hat und damit prüfen, ob sie in der Lage ist die Spreu vom Weizen zu trennen. Diese Knackpunkte gibt es dabei der Erfahrung nach:

  • Wie häufig greifen Suchmaschinen zu? Gutartige Suchmaschinen zeichnen sich meist durch gleichmäßige Zugriffe aus und haben keine Zugriffsspitzen. Je nach Valve Konfiguration kann es aber vorkommen, dass auch solche Zugriffsformen gesperrt werden, die dauerhaft unter den pro Slot erlaubten Zugriffsraten bleiben.
  • Dienen die eigenen Webapplikationen als Service Endpunkt, der von anderen Applikationsservern in großem Umfang genutzt wird? Wenn es sich dabei um gewollte Fälle handelt, so sollte man die entsprechenden Adressen bzw. Adressbereiche grundsätzlich freischalten, damit die Valve Konfiguration nicht auf Grund solcher Einzelfälle zu offen gestaltet sein muss.
  • Wie viele Request löst ein Benutzer beim ersten Besuch (also mit leerem Cache) der eigenen Seiten aus? Hier erreichen moderne Webseiten auf Grund der vielen Komponenten häufig erstaunliche Zahlen, wobei die Masse der Zugriffe auf statische Inhalte entfällt. Um auch hier die Valve Konfiguration nicht zu offen gestalten zu müssen ist es meist sehr sinnvoll die Zugriffe auf statische Inhalte nicht mit in die Zugriffszählungen eingehen zu lassen. Diese Zugriffe sollten sowieso nicht die Hauptlastverursacher in einer dynamischen Webapplikation sein und die böswillige Akteure werden sie sowieso nicht abrufen.
  • Kommen reguläre Benutzer in großer Zahl über Proxies auf den eigenen Server, so dass sich hinter einzelnen IP Adressen faktisch viele Benutzer verbergen?

Auch bei sehr sorgfältiger Vorbereitung ist es aber notwendig zumindest in der ersten Zeit nach der Aktivierung des Valves die Logging Informationen im Auge zu behalten und zu beobachten ob Adressen gesperrt werden, die man eigentlich zulassen möchte.

Ist das Valve richtig konfiguriert kann man es in gewisser Weise ‚vergessen‘, da es danach Angriffe automatisch im Zaum halten kann. Änderungsbedarfe ergeben sich dann nur noch bei Modifikationen an den im Server installierten Anwendungen, die das Lastverhalten beeinflussen. Trotzdem sollte ein Monitoring fortgesetzt werden, schon allein um zu sehen ob Angriffe erfolgen und in welchem Umfang.

Was sind die Grenzen

Das Anti-DoS Valve kann seinem Namen nur in einem Teilaspekt des weiteren Themas (D)DoS gerecht werden. Es wird z. B. nicht bei riesigen Überflutungen helfen, die schon die Netzwerkebene überlasten. Es hat aber seine Daseinsberechtigung in dem Bereich, der unterhalb des Angriffslevels liegt, der sich auf Netzwerkebene einfach erkennen lässt:

Im Fall unserer Server werden heute pro Tag normalerweise mehr als eine Million Requests verarbeitet. Starke Belastungen können aber schon entstehen, ohne das sich diese Zahl insgesamt vervielfacht, sofern die Zugriffe auf die entsprechenden Adressen gebündelt werden. An genau dieser Stelle kann das Valve eingesetzt werden, in dem es insbesondere die Zugriffe auf die Adressen reguliert, die geeignet sind hohe Belastungen zu erzeugen. Dafür ist eine Kenntnis der entsprechenden Applikationen und ihrer sensiblen Punkte notwendig.

Die ursprüngliche Version des Valves hat dabei den angestrebten Zweck bisher erfüllt und sich als sehr stabil erwiesen.

Monitoring per JMX

Das Valve kann sehr weitgehend per JMX administriert und beobachtet werden. In der JConsole präsentiert es sich dabei so:

Auf diese Weise können Konfigurationsänderungen auch am laufenden Server durchgeführt werden und gleichzeitig der aktuelle Status z. B. von blockierten IP Adressen beobachtet werden.

Ideen für die Weiterentwicklung

Die bisherige Implementierung hatte das Ziel möglicht einfach gehalten zu sein und ist auf den bisherigen Einsatzzweck zugeschnitten. Für eine Verallgemeinerung der Funktion bieten sich aber eine Reihe von Erweiterungen an:

  • Testmodus: Ein Option das Valve im Server so zu betreiben, dass nur Loggings über Blockaden erfolgen, aber keine echten Blockaden. Auf diese Weise könnten Konfigurationen zunächst risikofrei getestet werden.
  • Zähler auf Ebene von Subnetzen: Nicht nur echte DDoS Attacken verteilen ihre Zugriffe auf viele Ausgangsrechner, auch bei Webscrapern / böswilligen Crawlern kann dies beobachtet werden. Hier wäre eine Verallgemeinerung der Programmierung interessant, die in der Lage ist Zähler nicht nur auf Ebene von einzelnen IP Adressen zu führen. Die Implementierung des Monitors, der die Zugriffszählung durchführt, ist bereits entsprechend verallgemeinert worden.
  • Möglichkeit mehrere Instanzen des Valves im Server nutzen zu können: Zwar kann man heute das Valve mehrfach in einem Tomcat konfigurieren, aber die Monitor Instanz ist nicht getrennt und per JMX wird nur eine Instanz des Valves gezeigt. Die Nutzung unterschiedlicher Valve-Instanzen in einem Server kann nützlich sei falls unterschiedliche Konfigurationen für verschiedene Webapplikationen gefahren werden sollen.
  • Verbesserungen für den Einsatz in Serverfarmen: Heute müssen Konfigurationsänderungen an allen Servern separat erfolgen, auch gibt es keine Möglichkeit wie sich Instanzen des Anti-DoS Valves auf unterschiedlichen Servern verständigen können. In unserer Serverfarm beeinträchtigt uns das heute nicht, aber bei großen Farmen könnte so etwas nützlich sein.

Falls jemand Lust hat an dem Projekt mitzumachen: Einfach melden 🙂

Die Geschichte des Bielefelder Informationssystems bis zum Jahr 2016

Geschichte wurde zur Legende, Legende wurde Mythos‘

Dieser Satz findet sich am Beginn der Verfilmungen von Tolkiens Herr der Ringe Trilogie und kam mir bei der Erstellung des nun hier veröffentlichten Textes zur Geschichte des BIS Projekts an der Universität Bielefeld in den Jahren 1998 bis 2016 immer mal wieder in den Kopf. Warum? Weil es überraschend aufwändig war diese Geschichte zu rekonstruieren. Und das, obwohl ich heute die einzig verbliebene Person bin, die über die komplette Zeit im und für das BIS gearbeitet hat, ich Zugriff auf alle relevanten Dokumente und eMails habe und mir durch meine Eigenart ein recht umfassendes Arbeitstagebuch zu führen noch jede Menge weiterer Informationen zur Verfügung stehen.

Beim Aufarbeiten von Texten, die vor teilweise mehr als eineinhalb Jahrzehnten von mir erstellt wurden, werden Erinnerungen wieder wach an alte Vorhaben, die so nie realisiert wurden, ’spinnerte‘ Ideen, die sich später in überraschender Weise doch realisieren ließen, Irrwege, die beschritten werden mussten und Menschen, mit denen man viele Jahre intensiv zusammengearbeitet hat, die aber irgendwann verloren gingen. Vieles davon macht einen stolz angesichts der erreichten Ziele, manches wirkt im Rückblick merkwürdig und an anderen Stellen hat sich die eigene Erinnerung inzwischen Legenden und Mythen zurechtgelegt, die nur noch grob mit dem übereinstimmen, was man in den alten Unterlagen wiederfindet.

Eine interessante Erfahrung.

Der Inhalt

‘Das Rektorat hat auf seiner Sitzung am 3.2.1998 über die vom „Arbeitskreis Informationsstrukturierung und Intranet“ erarbeitete Vorlage zur Erarbeitung eines Konzepts zum Aufbau einer Basisinfrastruktur BIS (Bielefelder Informationssystem) beraten und dazu folgenden Beschluss gefasst:

‚Das Rektorat beschließt, eine Projektgruppe einzusetzen mit dem Auftrag, eine Basisinfrastruktur BIS (Bielefelder Informationssystem) zu konzipieren….’’

Die ersten 19 Jahre des BIS (Was ist das BIS?) sind nun in einem ca. 50-seitigen Text dokumentiert. Trotz dieser Länge ist bei weitem nicht jedes Detail aus dieser Zeit enthalten und der Text umfasst auch nur meine eigene Perspektive. Die Kolleginnen und Kollegen, die ebenfalls viele Jahre im BIS gearbeitet haben, würden sicher noch andere Punkte finden, die sie besonders erwähnenswert finden. Das Dokument ist natürlich auch kein offizielles Dokument der Hochschule, sondern beschreibt allein meine eigenen Ansichten und Erinnerungen.

Wer sich den kompletten Text nicht zutraut findet hier ein paar interessante Einstiegspunkte:

  1. Einführung des eKVVs in 2001
  2. Die erste Onlinebedarfserhebung in 2004
  3. Die Gründung der automatischen Mailverteiler in 2004
  4. Aufbau der BA / MA Prüfungsverwaltung in 2005
  5. Definition des Begriffs ‚Campusmanagementsystem‘ in 2007
  6. Die Studieninformation als Alleinstellungsmerkmal in 2010
  7. Studienmodell 2011; Ausbau der Studiengangsmodellierung; Start von BIS3.0 in 2011
  8. Aufbau Identity Provider mit Single Sign-on und 2FA; Start des integrierten eLearning Angebots in 2014
  9. Abbruch des Versuchs zur Einführung einer Standardsoftware im Campusmanagement in 2015
  10. Status des BIS Ende 2016

Unter dem ‚Status des BIS‘ findet sich auch ein Abschnitt mit Details und Umfang der technischen Implementierung des BIS.

Nutzung von Google Drive zur Veröffentlichung

Bei der Veröffentlichung des Textes stand ich vor der Frage welches Verfahren hier wohl das günstigste wäre. Den Text an sich habe ich im Google Drive erstellt, welches schon seit langer Zeit mein Standardwerkzeug für die private Dokumentenhaltung und -erstellung ist.

Die erste Idee den Text nach der Fertigstellung zu exportieren und eine Kopie ins Web zu stellen hätte das Problem mit sich gebracht, dass jede kleine Korrektur – und bei so einem umfangreichen Text ist noch auf lange Sicht immer mal wieder mit Korrekturen zu rechnen – dann an zwei Stellen gepflegt werden müsste. Der Originaltext im Google Drive soll ja nach der Veröffentlichung nicht aufgegeben werden, da er voller Notizen und Quellverweise ist und eine geeignetere Ausgangsbasis ist, falls der Text einmal in anderen Formaten benötigt wird. Auch der Grundaufwand für die Aufbereitung so einer Kopie wäre nicht unerheblich gewesen bei einem Text mit 18.000 Worten, vielen Abschnitten und Bildern.

Die Lösung, die eine Beibehaltung des Originaltextes als Quelle für eine Veröffentlichung bietet und quasi keinen initialen Aufwand erzeugt, stellt die mir bis dahin unbekannte Google Drive Funktion ‚Im Web veröffentlichen‘ dar. Damit wird eine Kopie des Dokuments erstellt, die alle paar Minuten Aktualisierungen aus dem Quelldokument erhält und sich öffentlich abrufen lässt.

Das generierte Dokument hat ein paar Mängel. So ist die Optik nicht außergewöhnlich hübsch, es ist nicht responsive und die Formatierung kann nur begrenzt beeinflusst werden. Trotzdem ist es für diesen Zweck eine nahezu optimale Lösung, die die Hemmschwelle für Korrekturen am Text niedrig hält und ein Auseinanderlaufen verschiedener Versionen des Textes verhindert.

Triangulation Podcast mit Cathy O’Neil

Im letzten Triangulation Podcast (Nr. 275) ist Cathy O’Neil zu Gast, die vor kurzem das Buch Weapons of Math Destruction veröffentlicht hat. Das hatte ich zwar schon auf meiner Leseliste, aber bisher noch nicht angefangen. Der Podcast ist ein ausführlicher Teaser, der die Kernthesen darstellt:

  • Durch die stetig wachsenden Datenhalden, die im Netz über alles und jeden aufgebaut werden, und die sich schnell weitenentwickelnden mathematischen und technischen Verfahren (‚Big Data‘) sind inzwischen gezielte Beeinflussungen in großem Maßstab möglich
  • Ein Beispiel ist vielleicht bereits der gerade gelaufene Präsidentschaftswahlkampf in den USA, bei dem potentielle Wähler auf Facebook genau auf sie zugeschnittene Wahlversprechungen oder Beeinflussungen erhalten haben, die für andere Wähler / Fact Checker unsichtbar und nicht überprüfbar sind
  • Gleichzeitig gibt es eine große Gläubigkeit in ‚die Mathematik‘ oder ‚den Algorithmus‘, der z. B. die für das Schulsystem des Distrikts Washington Verantwortlichen dazu gebracht hat sich ein Scoringsystem für ihre LehrerInnen anzuschaffen, welches diese auf Basis eines niemandem bekannten Verfahrens einstuft und ggf. zu ihrer Entlassung führt. Ohne das irgendeine Überprüfung erfolgt, ob das Verfahren zu einer Verbesserung führt, und zumindest Einzelfälle die Vermutung nahelegen, dass hier gerade die in armen Gegenden liegenden, diesem Scoring unterliegenden Schulen dadurch ihre guten LehrerInnen verlieren

Die Autorin, die unter https://mathbabe.org/ bloggt, ist offenbar ehrlich betroffen (im Sinne von beschämt) von den Einsatzfeldern, auf die die von ihr geliebte Mathematik hier geführt wird.

Auch für uns InformatikerInnen ist dieses Thema relevant um das eigene Gewissen dafür zu schärfen was die Dinge, die man mal als ‚80% Lösung‘ für den ersten Aufschlag gebaut hat, vielleicht anrichten können, wenn sie so auf die Welt losgelassen werden.

Hier ist die Homepage des Buches: https://weaponsofmathdestructionbook.com/

Analyse von Symantec Produkten durch das Project Zero

‚Today we’re publishing details of multiple critical vulnerabilities that we discovered, including many wormable remote code execution flaws‘

aus How to Compromise the Enterprise Endpoint vom 26. Juni 2016

Nicht mehr ganz taufrisch die Meldung, aber man bekommt nicht jeden Tag eine Beschreibung von wormable remote code execution flaws präsentiert, also von Fehlern, die Schadcode von fern ausnutzen und zur selbstständigen Weiterverbreitung auf andere Systeme verwenden kann.

gitter

Und wieder ist es Tavis Ormandy von Google’s Project Zero, der sich ein ‚Sicherheitsprodukt‘ vorgenommen hat und gruselige Dinge entdeckt: Dieses Mal ist das komplette Produktportfolio von Symantec betroffen (bzw. die Endverbrauchermarke ‚Norton‘).

‚Because Symantec uses a filter driver to intercept all system I/O, just emailing a file to a victim or sending them a link to an exploit is enough to trigger it – the victim does not need to open the file or interact with it in anyway.‘

Wie schon bei früheren Fällen ist es wieder die Mischung aus den tiefgreifenden Rechten, die sich solche ‚Sicherheitslösungen‘ in den von ihnen ‚geschützten‘ Systemen nehmen, der Komplexität der dabei zu bewältigenden Aufgaben und eines mangelhaften Qualitätsmanagements, welches eine durchschlagende Wirkung erzeugt. Hier so durchschlagend, dass es einem Angreifer damit möglich gewesen sein sollte ein komplettes Unternehmensnetzwerk zu unterwandern. Und zwar nur, weil dieses Netzwerk mit zusätzlicher ‚Sicherheitssoftware‘ gesichert werden sollte.

Eine Frage der Abwägung

Dementsprechend ist diesem Fazit von Ormandy nicht viel hinzuzufügen:

‚Network administrators should keep scenarios like this in mind when deciding to deploy Antivirus, it’s a significant tradeoff in terms of increasing attack surface.‘

Bei privaten Nutzern ist die Frage ob man eine zusätzliche Sicherheitslösung verwendet gerade unter Windows heute noch schwieriger zu entscheiden. Ich selbst verwende keine entsprechende Software mehr, meine ChromeOS Geräte haben das sowieso nicht nötig und unter Windows reicht mir der von Microsoft kommende ‚Defender‘.

Bei technisch nicht so versierten Nutzern kann so eine Software vielleicht trotzdem einen gewissen Schutz bieten, zumindest wenn diese eMaildienste verwenden, die nicht ausreichend in der Lage sind ihre Nutzer vor schädlichen Anhängen zu schützen, die immer noch ein wesentlicher Verbreitungsweg sind.

Auf der anderen Seite habe ich ein frisches Erlebnis mit dem Kaspersky Produkt, welches sich bei Bekannten als extrem übergriffig und nervig erwiesen hat: Nachdem die Lizenz ausgelaufen war fing diese Software an die Nutzer beim Aufruf von GMail mit einer kaum wegklickbaren, permanent Piepsgeräuche produzierenden und sich über den Browser legenden Warnung zu nerven, wonach sie ’nicht mehr geschützt‘ seien. Offenbar hält man es bei Kaspersky in so einem Fall für den besten Schutz die Nutzer gleich ganz von Nutzung ihres eMailkontos auszuschließen.

Und warum man ausgerechnet Kaspersky brauchen sollte um sein GMail Konto zu sichern und worin die konkrete Gefährdung besteht ist dabei natürlich nicht weiter begründet worden. Eine der ersten Handlungen an diesem Rechner war es daher die entsprechende Erweiterung aus dem Chrome Browser zu entfernen.

Da sich die Bekannten auf Grund der Störungen durch die Kaspersky Software schon dazu hatten bringen lassen eine Lizenz zu kaufen habe ich das Produkt erst einmal auf dem Rechner gelassen. Allerdings gab es dazu ein paar Tage später die Rückmeldung, dass nun auch beim eBay Zugriff plötzlich irgendeine störende Meldung erschien, die eine ’sichere Bezahlung‘ über Kaspersky abwickeln wollte.

Wenn ich das nächste Mal dort bin, dann ziehe ich Kaspersky endgültig den Stecker….

Bericht der taz Redaktion über einen dort erlebten Keylogger-Angriff

‚Es ist wohl reiner Zufall, dass der Keylogger am Ende entdeckt wird. Mindestens ein Jahr lang ist er zuvor im Einsatz‘

In diesem Artikel arbeitet die taz den Anfang letzten Jahres erfolgten Fund eines Keyloggers in der Redaktion umfangreich auf. Das ist aus mehreren Gründen sehr interessant, da es sich nicht nur um eine nochmalige Aufarbeitung des Ablaufs der Ereignisse und der internen Diskussionen, die sich darum entwickelten, handelt:

Was ist ein Keylogger?

Es geht zuerst um die Frage was eigentlich ein Keylogger ist (also ein Keylogger Gerät und nicht eine Software) und wie man sich dagegen schützt. Leider ist das aber ein Angriff, der zum einen von jedem ‚Idioten‘ ausgeführt werden kann, da er keinerlei IT Knowhow erfordert. Zum anderen ist er schwer zu entdecken, da man sich schon einen betroffenen PC vor Ort sehr genau ansehen muss, damit einem so etwas auffällt. Auch hier ist der Fund nur zufällig erfolgt.

pc_von_hinten

Und schließlich ist es schwierig so einen Angriff in Zukunft zu verhindern. Der in dem Text mehrfach auftauchende Rat doch die USB Buchsen zu versiegeln oder abzuschalten geht meiner Meinung dabei in die falsche Richtung: Das Keylogger Gerät wird ja zwischen Tastatur und PC gehängt, und für die Tastatur muss ja nun irgendeine Buchse freibleiben.

Wie kann man seine Nutzer schützen?

Als IT Abteilung kann man eigentlich nur diese Dinge tun:

  • Möglichst viele Dienste auf eine 2-Faktor-Anmeldung umstellen. So kann ein gestohlener Zugang nicht genutzt werden
  • Ein Notlösung ist das Angebot das Passwort per Mausklick (virtuelle Tastatur) eingeben zu lassen. Allerdings werden die meisten Nutzer das hassen
  • Stärkeres Monitoring von Loginvorgängen und Benutzeraktivitäten durchführen um so auf ungewöhnliche Vorgänge aufmerksam zu werden. Das ist ein gutes Mittel, wie die in der taz nachträglich durchgeführten Auswertungen zeigen, aber auch komplex und häufig sicher schwer mit dem Personalrecht zu vereinbaren
  • Bevorzugte Verwendung von Geräten ohne externe Tastatur (Laptop). Das schützt zumindest vor ganz einfachen Angriffen
  • Die Rechte der Nutzer auf den Geräten wenn möglich einschränken, damit nach dem Angriff per Keylogger Hardware nicht anschließend auch noch Schadsoftware installiert wird
  • Regelmäßige Sichtkontrolle aller Geräte (wozu natürlich niemand Zeit hat, aber vielleicht reicht schon die Drohung um einige Angreifer abzuschrecken)

Der Zwang sehr komplexe Passworte und damit einen Passwortmanager zu nutzen kann hingegen kontraproduktiv sein, da das Passwort des Passwortmanagers ggf. auch vom Keylogger mitgeschnitten wird und so alle Passworte verloren sind.

Man sieht: Ein extrem simples Mittel (50€ Gerät) kann einen enormen Aufwand verursachen.

Wie kann man sich selbst schützen

Als Nutzer von IT Systemen kann man ggf. weitere Dinge tun, um sich zumindest teilweise zu schützen:

  • Den Rechner am Arbeitsplatz als faktisch ‚fremden‘ Rechner behandeln, ähnlich wie man es in einem Internetcafe tun sollte. Und z. B. keine privaten Dinge auf dem Rechner tun, damit ein Angriff ggf. ’nur‘ die Firmenkonten betrifft. Ein Angreifer, der wie hier offenbar im wesentlichen private Gründe hat, wird dann vielleicht schnell das Interesse verlieren
  • Ggf. selbst Sichtkontrollen durchführen, dazu z. B. die Anschlüsse von Tastatur und Maus auf die Vorderseite des Gerätes legen
  • Falls es die eigene IT Abteilung nicht schafft eine 2-Faktor-Anmeldung für wichtige Accounts einzuführen kann man sich ggf. so behelfen, dass man einen YubiKey oder ähnliches verwendet, auf dem man den größeren Teil eines sehr komplexen Passworts speichert, welches man dann unter Umgehung der normalen Tastatur in den Rechner schickt. Ggf. gibt man die letzten X Zeichen des Passworts selbst über die normale Tastatur ein, damit ein Finder / Dieb des Keys nicht gleich den vollen Zugriff hat

Grundsätzlich gilt: Wer einmal einen solchen Angriff erlebt hat, der wird schwerlich Grenzen für die eigene Paranoia finden und seinem Rechner nie mehr so vertrauen, wie er es vielleicht zuvor getan hat.

Wie arbeitet man so einen Fund auf?

Interessant ist dann auch die Beschreibung wie mit dem Fund des Keyloggers umgegangen wurde: Angefangen von der erfolgreichen Fallenstellung bis hin zum Sichern, Interpretieren und Aufbereiten der digitalen Beweise. Das man hier erfinderisch und technisch fit sein muss ist dabei der eine Teil, der andere ist es als IT Abteilung eine möglichst nicht anzweifelbare Kette von Indizien zu produzieren, die dann sowohl bei der internen Aufarbeitung wie auch bei der externen Bearbeitung etwa durch die Strafverfolgungsbehörden nicht gleich in sich zusammenfällt und sowohl einen selbst wie auch die größten Zweifler überzeugt. Auch das scheint hier gut gelungen zu sein.

Was wenn es ein Innentäter ist?

Und schließlich gibt es noch die menschliche Komponente, wenn wie hier ein (größtenteils) geschätzter Kollege sich plötzlich als jemand entpuppt, der einen offenbar in großem Stil hintergangen und aus weiterhin unklaren Motiven großflächig ausspioniert hat. Und der dabei so gar nicht dem üblichen Cliche des ‚Hackers‘ entspricht.

Es spricht finde ich dabei für die Offenheit der taz, dass man sich der Hypothese stellt, dass der Täter vielleicht irgendeinem Übel innerhalb der Redaktion auf der Spur war. Aber letztlich bleibt aus meiner Sicht nur die Tatsache, dass hier jemand gegen jede übliche Norm des zwischenmenschlichen Umgangs verstoßen hat, und dabei offenbar letztlich im wesentlichen die Motive eines Stalkers hatte.

Kleines Pwn2Own Fazit – Lehren für Sicherheit im Webbrowser

In dieser Woche hat sich der jährliche Pwn2Own Wettbewerb ereignet, bei dem es schon seit einigen Jahren darum geht aktuelle Browser und Betriebssysteme (und dieses Jahr erstmalig auch VMs) zu hacken.

Einige Änderungen hat es in den letzten Jahren gegeben: Bekam der erfolgreiche Hacker zunächst nur das gehackte (‚pwn‘) Gerät geschenkt (‚own‘), so sind die insgesamt ausgeschütteten Preisgelder inzwischen in den 6-stelligen Bereich gegangen.

Sie vollziehen damit den Trend nach, den man allgemein beobachten kann: Sicherheitslücken sind ein wertvolles Gut geworden, welches sich bei staatlichen Abnehmern bzw. den sie versorgenden Spezialisten wie VUPEN oder HackingTeam für gutes Geld verkaufen lässt. Google, Mircosoft etc. haben daher auch die Prämien ihrer Bug Bounty Programme immer weiter angezogen.

Eine andere Änderung betrifft den Ausrichter, der nun zu Trend Micro gehört. Da die angetretenen Hacker ebenfalls zu großen Teilen zu auf IT Sicherheit spezialisierten Unternehmen gehören ist der Wettbewerb wohl noch stärker zu so etwas wie einem kleinen Familientreffen der Sicherheitsindustrie geworden.

Aber nun zu den Ergebnissen:

Chrome zeigt sich als ’sicherster‘ Browser

Von den Browsern, die die Ausrichter als Ziele genannt haben, sind alle gefallen, auch Chrome. Warum kann man Chrome trotzdem als den sichersten Browser bezeichnen? Weil eine Kombination von 4 Fehlern notwendig war, um ihn zu Fall zu bringen, davon 2 in Flash und einer im Windows Kernel. Der verbleibende Chrome Fehler war Google schon zuvor von anderer Stelle gemeldet worden, daher bekamen die Hacker nur einen Teil der Punkte für diesen Erfolg. Insgesamt zeigt dies wohl die große Robustheit, die Chromes Sandbox erreicht hat.

bugs
Ein Bug bleibt selten allein

Warum setze ist das ’sicherster‘ oben dann trotzdem in Anführungszeichen? Weil Sicherheit kein Zustand ist, sondern ein Prozess, der sich immer weiterentwickelt und morgen schon wieder anders aussehen kann. Da allerdings Google das Thema Sicherheit in Chrome in den letzten Jahren immer aggressiv verfolgt hat, kann man erst einmal davon ausgehen, dass man mit Chrome auf der sicheren Seite ist und bleibt.

Auch Microsofts Edge Browser schlägt sich offenbar viel, viel besser, als es früher dem IE gelang. Anscheinend bringt der Abschied von der alten Codebasis in dieser Hinsicht einiges.

‚Mozilla’s Firefox browser was intentionally dropped from the competition due to its complete lack of a sandbox, a critical security feature which raises the bar for exploitation.‘

Traurig ist hingegen der Stand von Firefox: Zwar ist der freie Webbrowser nach StatCounter immer noch knapp der weltweit zweithäufigst verwendete Browser, aber in Kreisen ernstzunehmender Hacker wird seine Überwindung anscheinend als so lächerlich einfach angesehen, dass man damit keine Anerkennung ernten kann. Man kann wohl eigentlich niemandem mehr raten Firefox zu nutzen, jedenfalls nicht, wenn man auf Sicherheit achtet.

Flash: Gefährlich und zunehmend unnötig

Ein alter Bekannter in Bezug auf Sicherheitsprobleme im Webbrowser ist natürlich das Flash Plugin, welches ja schon beim Chrome Hack eine Rolle spielte und in dem noch weiteren Lücken demonstriert wurden.

Ich habe meinen Chrome Browser schon vor einiger Zeit bei der Pluginausführung auf ‚Click to play‚ umgestellt, so dass Plugins erst gestartet werden, wenn ich es explizit will. Damit ist man auf diesem Wege deutlich weniger verwundbar.

Nach meiner Erfahrung nimmt die Zahl der Flash Einbindungen im Web – zumindest in dem Teil, in dem ich mich bewege – rasch ab. Es ist glaube ich schon Wochen her, dass ich einmal einen Inhalt unbedingt sehen wollte, der nur über Flash erhaltbar war.

Neues Angriffsziel: Die Betriebssystemkerne

Ein interessanter – und besorgniserregender – Trend bei diesem Pwn2Own Wettbewerb war die Konzentration der Hacker auf Fehler in den Betriebssystemen, an Stelle von Fehlern in den Browsern. Dies mag der Tatsache geschuldet sein, dass die Browser in Sicherheitshinsicht stark aufgerüstet haben und die Hacker nun zuerst an anderen Stellen suchen, wo sie einfacher Erfolg haben. Eine Folge davon war dann, dass die erfolgreichen Exploits gleich Systemrechte erlangen konnten, also quasi allmächtig sind im kompromittierten System.

Das kann man als Argument nehmen, dass der grundlegende Ansatz von Googles ChromeOS zumindest nicht falsch ist, nämlich das ein Betriebssystem eher weniger können sollte und dafür besser gehärtet werden kann.

Wer sich die beiden Tage des Wettbewerbs in Filmform ansehen möchte, der findet das hier:

http://ingoogle.com/pwn2own-2016-windows-os-x-chrome-edge-safari-all-hacked/