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

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 🙂