Die eigene Abwehr hat Besucher ausgesperrt

Ein Besucher meldete sich: Die Kartenansicht meines Netzwerks lässt sich einmal öffnen, danach kommt gar nichts mehr. Kein Fehler, keine Seite, nichts.

Der Klassiker wäre gewesen, das auf seinen Anschluss zu schieben. Es war meine eigene Abwehr.

Die Ursache

Ich habe eine Regel, die Anschlüsse sperrt, die in kurzer Zeit auffällig viele Anfragen auf nicht existierende Adressen stellen. Das ist eine übliche Maßnahme gegen automatisierte Scanner, die Systeme nach bekannten Schwachstellen absuchen.

Und jetzt die Eigenschaft, die alles erklärt: Ein Kartenserver legt Kacheln nur für erkundete Bereiche an und antwortet für alles andere planmäßig mit „nicht vorhanden".

Wer über die Karte schwenkt, erzeugt dutzende bis hunderte solcher Antworten — völlig normal, kein Fehler, so ist das System gebaut. Nach der fünfzehnten war sein Anschluss gesperrt.

In der gemessenen Sitzung: mehrere hundert erfolgreiche Anfragen, gut zweihundert Anfragen auf nicht vorhandene Kacheln, dazu Antworten aus dem Zwischenspeicher. Das Erkennungszeichen im Protokoll der Abwehr: ein Dutzend Treffer in derselben Sekunde.

Warum das ein Denkfehler war

Meine Regel hing an einem Statuscode. Und Statuscodes haben keine feste Bedeutung im Sinne von „das ist ein Angriff" — sie haben eine Bedeutung im Kontext des Dienstes.

Für eine normale Webanwendung ist eine Serie von Anfragen auf nicht existierende Adressen ein starkes Signal. Für einen Kachelserver ist es der Normalbetrieb.

Die Lehre: Bevor man eine Abwehrregel baut, sollte man wissen, welche Statuscodes der Dienst im gesunden Zustand erzeugt. Ich hatte eine Regel für „meine Webdienste" gebaut und sie auf alles angewendet, was über denselben Eingang läuft.

Die Behebung

Eine Ausnahme, eng gefasst: Anfragen auf den Kartenhost unterhalb des Kachelpfads zählen nicht.

Wichtig war mir dabei, die Ausnahme so schmal wie möglich zu halten. Nicht „dieser Host ist ausgenommen", sondern „dieser Pfad auf diesem Host". Ein Scanner, der andere Adressen auf demselben Host probiert, wird weiterhin erkannt.

Und danach die Gegenprüfung mit dem Werkzeug, das die Regeln gegen Beispielzeilen testet: Kachelzeilen null Treffer bei voller Ausnahmezahl, echte Scannerzeilen weiterhin volle Trefferzahl. Das ist der Schritt, den man nicht auslassen darf — eine Ausnahme, die zu breit greift, hebt die ganze Regel auf.

Der zweite Fehler am selben Tag

Parallel dazu lieferte die Karte für einen der Server keine Live-Daten mehr — die Anzeige, wer gerade online ist. Zwei Ursachen, beide lehrreich.

Erstens: Der Webserver löst Containernamen nur beim Start auf. Mein Kartenserver spricht die einzelnen Spielserver über ihre Namen an. Als einer davon neu gestartet wurde, bekam er eine andere interne Adresse — und der Webserver zeigte weiterhin auf die alte.

Das Symptom ist ein Fehler, obwohl sich an der Konfiguration nichts geändert hat. Genau diese Formulierung sollte einen aufhorchen lassen: Wenn etwas kaputtgeht, ohne dass jemand etwas geändert hat, hat sich etwas anderes geändert.

Die Behebung ist eine Konfigurationszeile, die eine Auflösung zur Laufzeit erzwingt, mit einer kurzen Gültigkeit. Danach wird pro Anfrage neu aufgelöst, und ein Neustart eines Zieldienstes ist folgenlos.

Zweitens: ein falscher Port in einem der Einträge. Unspektakulär, schnell behoben, und der Grund, warum ich zuerst an der falschen Stelle gesucht habe — zwei gleichzeitige Fehler mit ähnlichem Symptom sind die unangenehmste Konstellation überhaupt.

Wie ich Abwehrregeln jetzt aufsetze

Nach diesem Fall gehe ich bei jeder neuen Regel drei Schritte durch, bevor sie scharf geschaltet wird.

Erstens: Welche Statuscodes erzeugt dieser Dienst im gesunden Zustand? Ein Kachelserver antwortet planmäßig mit „nicht vorhanden". Eine Anwendung mit Anmeldung erzeugt regelmäßig „nicht berechtigt". Ohne diese Kenntnis baut man Regeln gegen den Normalbetrieb.

Zweitens: Gegen echte Protokollzeilen prüfen. Es gibt Werkzeuge, mit denen man eine Regel gegen eine Protokolldatei laufen lässt und sieht, was sie treffen würde. Zehn Minuten, und man weiß, ob die Regel das trifft, was sie soll.

Drittens: erst beobachten, dann sperren. Eine Regel, die zunächst nur meldet statt zu sperren, zeigt in ein paar Tagen, wen sie erwischen würde. Bei mir hätte das genügt.

Und ein vierter Punkt, den ich mir aufgeschrieben habe: Die eigene Adresse gehört in die Ausnahmeliste. Interne Prüfungen laufen bei mir über den öffentlichen Weg, und dabei können sie dieselben Muster erzeugen wie ein Scanner.

Was ich über Fehler in Doppelform gelernt habe

An diesem Tag lagen zwei unabhängige Fehler mit ähnlichem Symptom nebeneinander: die Fehlsperre und die kaputten Live-Daten.

Das ist die unangenehmste Konstellation überhaupt, weil jede Teilbehebung nichts zu bewirken scheint. Man behebt A, das Symptom bleibt, und schließt daraus, dass A nicht die Ursache war — dabei war es eine von zweien.

Was dagegen hilft, ist eine Disziplin, die schwer durchzuhalten ist: Nach jeder Änderung genau prüfen, was sich verändert hat, statt nur zu prüfen, ob das Problem weg ist.

Bei mir hieß das konkret: Nach der Ausnahme in der Sperrregel war der Besucher nicht mehr gesperrt — die Karte funktionierte trotzdem nicht vollständig, weil die Live-Daten aus einem anderen Grund fehlten. Zwei Symptome, die sich wie eines anfühlten.

Die Trennung gelingt am ehesten, wenn man beide Beobachtungen getrennt aufschreibt, bevor man anfängt zu suchen.

Was ich mitnehme

Abwehrregeln sind Teil des Dienstes und nicht davor. Eine Regel, die ohne Kenntnis des Dienstes gebaut wird, sperrt irgendwann echte Nutzer aus. Und das merkt man nur, wenn sich jemand meldet — die allermeisten melden sich nicht, die kommen einfach nicht wieder.

„Beim ersten Mal ging es, danach nicht mehr" ist ein Fingerabdruck. Dieses Muster bedeutet fast immer: Etwas hat mitgezählt und irgendwann zugemacht. Sperrlisten, Ratenbegrenzungen, Kontingente. Es ist kein Netzwerkproblem und kein Browserproblem.

Vor jeder Ausnahme die Gegenprobe. Eine Ausnahme, die man nicht getestet hat, ist ein Loch, dessen Größe man nicht kennt.