Alarmmüdigkeit: 82 E-Mails an einem Tag von meinem Security-Monitor

Wie viele Alarme sollte ein Security-Monitor für eine einzelne Person verschicken? Nach meinen Zahlen etwa eine E-Mail pro Tag, dazu die seltene, die mich tatsächlich zum Handeln auffordert. Am 1. November übergab mein Monitor zwischen Mitternacht und 13:32 Uhr pazifischer Zeit 74 E-Mails an den Maildienst: 55 zu Sperren, die er bereits gesetzt hatte, 16 kritische Alarme, zwei stündliche Volumenalarme und einen vom Scanner auf meinem Mac.¹² Meine Lesart an jenem Nachmittag war, dass jede davon routinemäßiges Scannen beschrieb, das die Edge bereits gestoppt hatte;³ für die kritischen Fluten zeigt Abschnitt 6, dass diese Lesart zu großzügig war. Die Lösung war eine Richtlinie, kein Schwellenwert: ein täglicher Digest, der zugleich als Heartbeat dient, Sperren in den Chat statt ins Postfach, ein kritischer Alarm, der in den Digest umgeleitet wird, wenn die Edge ihn bereits erledigt hat, und das Ergebnis, das auf jedem kritischen Cloud-Alarm vermerkt wird. Am nächsten Tag löste ein Scanner auf meinen Websites in weniger als sechs Minuten vier kritische Alarme aus, und mein Monitor schickte dazu null E-Mails.⁴ Der Tag brachte trotzdem 19 E-Mails, nicht eine, und der Grund dafür ist der nützlichste Teil der Geschichte.⁵

Ich bin der einzige Leser der Post meines Monitors. Als das Postfach 74 anzeigte, fragte ich, ob das Routine oder ernst sei, und die ehrliche Antwort lautete: Der Monitor konnte es mir an den Betreffzeilen nicht sagen, weil jeder Betreff dasselbe sagte, nur in anderer Lautstärke.¹ Ein Monitor, dessen einziger Leser aufhört, ihn zu lesen, hat aufgehört zu überwachen, ganz gleich, was seine Detektoren noch erfassen. Es folgen die Zählung, die Richtlinie, die sie ersetzt hat, ein Testfall und die drei Stellen, an denen die saubere Version der Geschichte bricht.

Kurzfassung

• 74 E-Mails bis 13:32 Uhr, 82 bis Mitternacht. Meine eigene Tabelle und die aus den Logs abgeleitete Zählung stimmen für die Zeit vor meiner Beschwerde bei 74 überein (55 pro Sperre, 16 kritisch, zwei stündlich, eine lokal); der gesamte 1. November kam auf 81 protokollierte E-Mails plus einen Digest, den ich von Hand verschickte.¹²⁵
• 22 der 74 sind unbelegt. Sie stammten aus Code, der „sent“ (gesendet) protokollierte, ohne die Antwort des Maildienstes zu prüfen; das Log belegt also einen Übergabeversuch, nicht, dass eine Nachricht angekommen ist.²⁶
• Die Fachliteratur kannte die Regel längst. Googles SRE-Buch lässt drei Ausgaben zu (Alerts, Tickets und Logging), sagt „Every page should be actionable“ (auf jede Alarmierung muss man handeln können) und nennt E-Mail-Alarme „alert spam“; das Alert der Joint Commission (The Joint Commission, die US-Akkreditierungsstelle für Krankenhäuser) zitiert eine Schätzung, wonach „between 85 and 99 percent of alarm signals do not require clinical intervention“ (85 bis 99 Prozent der Alarmsignale kein klinisches Eingreifen erfordern).⁷⁸⁹¹⁰
• Der Testfall hat funktioniert. Am 2. November löste eine einzige Adresse eines niederländischen Hosting-Anbieters auf meinen Websites in 5 Minuten und 51 Sekunden vier kritische Alarme aus; der Monitor sperrte sie einmal, postete die Sperre in den Chat, leitete jeden kritischen Alarm in den Digest um und schickte keine E-Mail.⁴¹¹¹²
• Der nächste Tag brachte trotzdem 19, nicht eine. Vierzehn waren kritische WAF-Flut-Alarme, bei denen für einige Ereignisse weder eine Sperre noch eine Challenge verzeichnet war, und ihre Betreffzeilen sagten „WAF blocks“ (WAF-Sperren), selbst wenn die Edge keines der Ereignisse gesperrt hatte (zweimal an jenem Tag; am Abend davor sagte eine „104 WAF blocks“, obwohl die Edge nichts gesperrt oder herausgefordert hatte); meine erste Umformulierung, am Tag der Zählung, vermischte noch immer zwei Zählungen in einer Zeile, und die Prüfung dieses Beitrags hat das aufgedeckt.⁵¹³¹⁴
• Zwei Signale waren falsch. Eine Codesignatur-Prüfung auf meinem Mac hielt Apples eigenen Spotlight-Daemon für einen unsignierten Krypto-Miner, und das „RUNS SHORT 162/207“ (zu wenige Läufe) des Digests erwies sich als teils Ruhezustand, teils als langsamerer realer Takt und teils, dem Timing nach, als drei vom Watchdog beendete Läufe.¹⁵¹⁶¹⁷
• Was sich geändert hat: Ein Digest pro Tag trägt den Heartbeat, jede Sperre und das Ergebnis jedes kritischen Cloud-Alarms, während nur ein kritischer Alarm, den keine der beiden Umleitungen abdeckt, der stündliche Volumenalarm und der lokale Scanner weiterhin sofort mailen; aus 82 E-Mails am 1. November wurden 19 am 2. November.¹⁸⁵

1. Das Postfach am 1. November

Um 13:32 Uhr pazifischer Zeit am 1. November schrieb ich an die Agenten-Session, die meine Infrastruktur betreibt: Die E-Mails des Monitors fluteten mein Postfach; gab es etwas zu ändern, und war das Routine oder echte Bedrohung?¹ Die Tabelle, die ich an jenem Nachmittag führte, zählte seit Mitternacht 74 E-Mails nach Absender: 55 Benachrichtigungen pro Sperre, 16 kritische Alarme, zwei stündliche Volumenalarme und einen kritischen Alarm vom Scanner auf meinem Mac.¹

Die Zählung beruht auf einer Regel, deshalb steht sie hier vor den Zahlen. Eine E-Mail ist in diesem Beitrag eine Zeile im Log des Monitors, die eine Übergabe an den Maildienst verzeichnet. Ein Skript ging die sechs Logdateien vom 31. Oktober bis 2. November durch und ordnete jede solche Zeile nach Strom und Ergebnis ein.⁵ Bis 13:32 Uhr ausgewertet, stimmt das Skript Strom für Strom mit meiner Tabelle überein: 55, 16, zwei und eine, zusammen 74.² Der gesamte lokale Tag bis Mitternacht kam auf 81 protokollierte E-Mails (55 pro Sperre, 22 kritisch, drei stündlich, eine lokal), plus einen Digest, den ich um 13:48 Uhr von Hand verschickte und der im Log des Monitors keine Versandzeile hat, macht 82.⁵¹

Zwei Details innerhalb dieser Übereinstimmung sind wichtig. Meine Tabelle sagte zu den kritischen Alarmen „9 before the fold went live at 00:30 PT; the 7 after“ (9 vor dem Start der Umleitung um 00:30 Uhr PT, 7 danach); das Log hat 11 kritische „sent“-Zeilen vor 00:30 Uhr und fünf danach, und der erste in eine Sperrbenachrichtigung umgeleitete kritische Alarm erscheint um 00:54:43 Uhr, nachdem die Änderung für die Umleitung um 00:46 Uhr PDT eingespielt war, nicht um 00:30 Uhr, wie meine Tabelle angab.²¹⁸ Die Summen stimmen; meine handschriftliche Aufteilung lag um zwei daneben. Das zweite Detail wiegt schwerer. Von den 74 kamen 22 (10 pro Sperre, 11 kritisch, eine stündlich) von Absendern, die die Antwort des Maildienstes verwarfen und danach „sent“ protokollierten, ganz gleich, was zurückkam.²⁶ Eine Korrektur um 01:04 Uhr PDT an jenem Morgen, bevor die Uhren zurückgestellt wurden, ließ die Absender der Cloud-Hälfte den HTTP-Status des Dienstes protokollieren und „sent“ nur bei einem 2xx schreiben; der Absender des lokalen Scanners schreibt eine schlichte Zeile „Critical email sent“, und zwar nur, wenn die Anfrage keinen Fehler auslöste.⁶ Die 22 früheren Zeilen belegen, dass der Monitor es versucht hat; sie belegen nicht, dass der Maildienst irgendetwas angenommen hat. Mein Log vom 31. Oktober urteilte, die Cloud-E-Mails seien „most likely were“ (höchstwahrscheinlich) zugestellt worden, eine vernünftige Vermutung, aber eben eine Vermutung.¹⁹

Selbst ein 2xx belegt weniger, als das Wort „sent“ nahelegt. Die Dokumentation von Resend definiert ihr Ereignis email.sent als „Occurs whenever the API request was successful. Resend will attempt to deliver the message to the recipient’s mail server“ (tritt ein, sobald die API-Anfrage erfolgreich war; Resend versucht dann, die Nachricht an den Mailserver des Empfängers zuzustellen), und führt die Zustellung als separates, späteres Ereignis.²⁰ Der Versandaufruf selbst antwortet mit einer id.²¹ Jede Zahl im Folgenden zählt Übergaben, die der Maildienst angenommen hat, oder, für die 22 am 1. November und die 10 am 31. Oktober, zusammen 32, Übergaben, die der Monitor versucht hat.⁵ Keine davon zählt Nachrichten, die ich gelesen habe.

Nach Stunden betrachtet sieht der Tag aus wie eine Klippe und ein Plateau.

1. November, Ortszeit: E-Mails pro Stunde gegenüber Alarmen, die keine E-Mail wurden, mit markierter Richtlinienänderung um 13:50 Uhr.²²

Die erste Stunde brachte 22 E-Mails, alle aus dem unverifizierten Code (10 pro Sperre, 11 kritisch, eine stündlich).²² Danach liefen die Benachrichtigungen pro Sperre mit einer bis fünf pro Stunde weiter, weil die Edge laufend Scanner sperrte und jede Sperre mir einen Brief schrieb. Die letzte E-Mail pro Sperre ging um 13:25:57 Uhr hinaus; die erste stattdessen in den Digest umgeleitete Sperrbenachrichtigung erscheint um 14:20:35 Uhr.²² Nach der Änderung um 13:50 Uhr fallen die E-Mails auf null bis zwei pro Stunde, während die umgeleiteten und unterdrückten Alarme auf bis zu 23 pro Stunde steigen.²² Der Traffic ging nicht zurück. Die E-Mails schon.

Der Vortag ist ein schlechter Vergleichswert. Mein Log vom 1. November sagt „Yesterday had 10“ (gestern waren es 10), und das Skript stimmt zu, aber das Log vom 31. Oktober beginnt um 22:31 Uhr, an dem Abend, an dem ich den Monitor wieder scharf schaltete; diese 10 E-Mails decken also 89 Minuten ab.¹⁵ Nach meiner Lesart maßen die 74 einen Detektor, der einen vollen Tag Hintergrundrauschen des Internets verarbeitete, keine Veränderung im Verhalten der Scanner.

2. Wofür die Alarme gedacht waren

Der Monitor hat zwei Hälften. Die Cloud-Hälfte läuft per Zeitplan alle fünf Minuten auf meinem Mac und fragt bei Cloudflare die Firewall-Ereignisse und die gruppierten Anfragezahlen für jede meiner Zonen ab: welche Adressen welche Pfade aufrufen, wie oft und welche Aktion die Edge bei jedem Ereignis ausgeführt hat.¹⁸²³ Cloudflares eigene Beschreibung der Daten ist der richtige Rahmen dafür: „Security Events displays information about requests actioned or flagged by Cloudflare security products, including features such as Browser Integrity Check.“ (Security Events zeigt Informationen über Anfragen, die von Cloudflare-Sicherheitsprodukten bearbeitet oder markiert wurden, einschließlich Funktionen wie Browser Integrity Check.)²⁴ Die lokale Hälfte ist ein Scanner, der den Mac selbst alle 10 Minuten in Stufen prüft: Prozesse und ihre Codesignaturen, die Agenten-Hooks auf der Maschine, Werkzeuge, die im Suchpfad Systembinärdateien überdecken, und dergleichen.¹²

Was die Cloud-Hälfte mit den Daten macht, ist schnell gesagt. Sie erzeugt Befunde nach Schweregrad (critical, high, medium) und Kategorie, und bei einem kritischen Befund versucht sie zu handeln, bevor sie irgendwen benachrichtigt: Steht eine Adresse hinter genügend Ereignissen, setzt sie diese Adresse für sieben Tage auf eine kontoweite Sperrliste, die jede Zone an der Edge durchsetzt.¹²⁴ Bis zu den Änderungen vom 1. November erzeugte jede dieser Aktionen auch eine E-Mail, ebenso jeder kritische Alarm, den ein Zwei-Stunden-Limit pro Website und Kategorie nicht unterdrückte, das Ende jeder Session und jede Stunde mit vielen Sperren.¹⁸⁵ Der lokale Scanner erzeugt eigene Befunde und mailt seine kritischen Alarme selbst.²⁵ Cloudflares eigene Alerts gibt es in zwei Arten, „Monitors that you define yourself, and Platform Notifications“ (selbst definierte Monitors und Platform Notifications): zeitgesteuerte SQL-API-Abfragen und vorkonfigurierte Produktalarme, beide im Dashboard eingerichtet.²⁶ Meiner ist keins von beiden: ein Skript auf meinem Mac, das die Firewall-Ereignisse selbst liest, was auch heißt, dass ich das Rauschen selbst beheben muss.

3. Was die Fachliteratur längst gesagt hatte

Nichts von dem Folgenden ist neu, und genau das ist das Unangenehme. Das meiste davon hatte ich gelesen und den Monitor mit einer E-Mail pro Ereignis trotzdem gebaut.

Drei Ausgaben, und E-Mail gehört nicht dazu. Die Einleitung von Googles Site Reliability Engineering (Googles Standardwerk zum Betrieb von Produktionssystemen) sagt „There are three kinds of valid monitoring output“ (es gibt drei Arten gültiger Monitoring-Ausgaben): Alerts, die „Signify that a human needs to take action immediately“ (anzeigen, dass ein Mensch sofort handeln muss); Tickets, die „Signify that a human needs to take action, but not immediately.“ (anzeigen, dass ein Mensch handeln muss, aber nicht sofort); und Logging, bei dem „No one needs to look at this information, but it is recorded for diagnostic or forensic purposes.“ (niemand diese Informationen ansehen muss, sie aber für Diagnose oder Forensik aufgezeichnet werden).⁷ Dieselbe Seite ist unverblümt, was mein damaliges Design angeht: „a system that requires a human to read an email and decide whether or not some type of action needs to be taken in response is fundamentally flawed.“ (Ein System, bei dem ein Mensch eine E-Mail lesen und entscheiden muss, ob irgendeine Reaktion nötig ist, ist grundlegend fehlerhaft.)⁷ So sortiert waren meine 55 E-Mails pro Sperre Logging, das als Alarm zugestellt wurde. Die Edge hatte gehandelt; für einen Menschen blieb nichts zu tun.

Auf jede Alarmierung muss man handeln können. Rob Ewaschuks Kapitel über Monitoring im selben Buch definiert einen Alert als „A notification intended to be read by a human and that is pushed to a system such as a bug or ticket queue, an email alias, or a pager“ (eine Benachrichtigung, die ein Mensch lesen soll und die an ein System wie eine Bug- oder Ticket-Queue, einen E-Mail-Verteiler oder einen Pager geschickt wird), und seine Fußnote zur E-Mail-Variante lautet „Sometimes known as “alert spam,” as they are rarely read or acted on.“ (manchmal „Alarm-Spam“ genannt, weil sie selten gelesen oder bearbeitet werden).⁹ Die Regeln des Kapitels für Pages passen in drei Zeilen: „Every page should be actionable.“ „I can only react with a sense of urgency a few times a day before I become fatigued.“ „If a page merely merits a robotic response, it shouldn’t be a page.“ (Auf jede Alarmierung muss man handeln können; ich kann nur ein paar Mal am Tag mit Dringlichkeit reagieren, bevor ich ermüde; verdient eine Alarmierung nur eine mechanische Reaktion, sollte sie keine Alarmierung sein.)⁸ Meine mechanische Reaktion auf eine E-Mail pro Sperre war, sie zu löschen. Das Kapitel benennt auch die Kosten des Rauschens: „When pages occur too frequently, employees second-guess, skim, or even ignore incoming alerts, sometimes even ignoring a “real” page that’s masked by the noise.“ (Kommen Alarmierungen zu häufig, zweifeln Mitarbeitende sie an, überfliegen oder ignorieren sie, manchmal sogar eine „echte“, die im Rauschen untergeht.)²⁷ Und es beschreibt ein Team, das „spent significant amounts of time triaging the alerts to find the few that were really actionable“ (viel Zeit mit der Triage der Alarme verbrachte, um die wenigen wirklich handlungsrelevanten zu finden), was meinen Nachmittag des 1. November ziemlich genau trifft.²⁸

Symptome vor Ursachen, und ein Test für eine Alarmierung. Ewaschuks früherer Essay, der nach seinen Worten die Grundlage für jenes Kapitel bildete, verdichtet den Test auf einen Satz: „Pages should be urgent, important, actionable, and real.“ (Alarmierungen sollten dringend, wichtig, handlungsrelevant und echt sein.)²⁹ Zu Ursachen heißt es dort „Include cause-based information in symptom-based pages or on dashboards, but avoid alerting directly on causes“ (ursachenbezogene Informationen in symptombasierte Alarmierungen oder Dashboards aufnehmen, aber nicht direkt auf Ursachen alarmieren), unter einer Abschnittsüberschrift „Cause-based alerts are bad (but sometimes necessary)“ (ursachenbasierte Alarme sind schlecht, aber manchmal nötig).²⁹ Ich lese eine Firewall-Sperre als Tatsache auf Ursachenebene: Ein Scanner hat eine Regel getroffen. Das Symptom, das mich interessiert, ist ein sensibler Pfad, der ausgeliefert wurde, oder eine Website, die ausgefallen ist, und nach meiner Lesart meldete keine der 74 eines von beiden; die Anfragen auf Probe-Pfade jenes Tages zeigten kein 2xx auf einem sensiblen Pfad.³ Der Essay nimmt auch den Digest vorweg: „A daily (or more frequent) report can work too“ (ein täglicher oder häufigerer Bericht kann auch funktionieren), mit der Warnung, dass „without a system of accountability this amounts to less-spammy email alerts“ (ohne ein System der Verantwortlichkeit läuft das auf weniger spammige E-Mail-Alarme hinaus).³⁰ Sein Gegenmittel ist eine Person: „make sure the oncall person (or someone else) is designated to triage these every day“ (sorgen Sie dafür, dass die Person in Rufbereitschaft oder jemand anderes dafür bestimmt ist, diese täglich zu sichten).³⁰ Bei einem Monitor für eine einzelne Person kann das nur ich sein. Das Ergebnisfeld in Abschnitt 4 ist mein eigener unterstützender Mechanismus, nicht seiner: Es gibt der täglichen Triage etwas zu prüfen, nämlich was aus jedem kritischen Alarm geworden ist, aber es erledigt die Triage nicht.

Precision und Recall. Das Kapitel über Alarmierung in The Site Reliability Workbook (dem praktischen Begleitband zum SRE-Buch) liefert das Vokabular für das, was schiefging. Precision ist „The proportion of events detected that were significant.“ (der Anteil der erkannten Ereignisse, die bedeutsam waren). Recall ist „The proportion of significant events detected.“ (der Anteil der bedeutsamen Ereignisse, die erkannt wurden).³¹ Den Recall meines Monitors habe ich nicht gemessen, dafür bräuchte es eine Zählung der bedeutsamen Ereignisse, die er verpasst hat, und Abschnitt 5 beschreibt eines, das er verpasst hat. Als Mailstrom lag seine Precision nahe null: 74 E-Mails, und nach meiner Lesart forderte mich keine davon auf, irgendetwas zu tun. Dasselbe Kapitel benennt die Reset-Zeit, „How long alerts fire after an issue is resolved. Long reset times can lead to confusion or to issues being ignored.“ (wie lange Alarme nach Behebung eines Problems weiter auslösen; lange Reset-Zeiten können zu Verwirrung oder ignorierten Problemen führen).³¹ Die Reset-Zeit ist für Alarme definiert, die weiter auslösen; eine E-Mail pro Sperre löst einmal aus und bringt danach keine Entwarnung mehr: Sie sagt nie, dass der Scanner wieder weg ist.

Die Krankenhausversion desselben Versagens. Das SRE-Kapitel selbst verweist über die Software hinaus, auf das Alarmmanagement in der Kardiologie, „for an example of alert fatigue in another context.“ (als Beispiel für Alarmmüdigkeit in einem anderen Kontext).²⁸ Das Sentinel Event Alert der Joint Commission zur Sicherheit von Medizingeräte-Alarmen, herausgegeben am 8. April 2013, liefert die Zahlen dazu: „The number of alarm signals per patient per day can reach several hundred“ (die Zahl der Alarmsignale pro Patient und Tag kann mehrere Hundert erreichen), und „It is estimated that between 85 and 99 percent of alarm signals do not require clinical intervention“ (Schätzungen zufolge erfordern 85 bis 99 Prozent der Alarmsignale kein klinisches Eingreifen).¹⁰ Das Alert ist auf eine Weise sorgfältig, die nachahmenswert ist: Die 85 bis 99 Prozent umfassen Alarme, die kein Eingreifen erfordern, nicht nur falsche, und das Alert trennt die beiden nicht. Die Folge, die es festhält, ist die, in der ich schon halb steckte: Klinisches Personal werde „become desensitized or immune to the sounds“ (gegenüber den Tönen abgestumpft oder immun) und „may turn down the volume of the alarm, turn it off, or adjust the alarm settings outside the limits that are safe and appropriate for the patient“ (dreht den Alarm leiser, schaltet ihn ab oder stellt ihn außerhalb der für den Patienten sicheren und angemessenen Grenzen ein).¹⁰ Es zählt 98 alarmbezogene Ereignisse von Januar 2009 bis Juni 2012, von denen 80 „resulted in death“ (tödlich endeten), und nennt über die an seine Datenbank gemeldeten Faktoren hinaus die Alarmmüdigkeit „the most common contributing factor.“ (den häufigsten beitragenden Faktor).¹⁰ Bei mir steht weit weniger auf dem Spiel. Der Mechanismus ist derselbe: Wer lernt, dass Alarme ihn nicht brauchen, lernt das auch für den nächsten echten.

NIST, damals und heute. Die Revision von 2012 des NIST-Leitfadens zur Behandlung von Vorfällen, SP 800-61r2, warnte, dass „it is not uncommon for an organization to receive thousands or even millions of intrusion detection sensor alerts per day.“ (es nicht ungewöhnlich ist, dass eine Organisation täglich Tausende oder gar Millionen Alarme von Intrusion-Detection-Sensoren erhält).³² Die Revision vom April 2025, SP 800-61r3, die „supersedes SP 800-61r2“ (SP 800-61r2 ersetzt), streicht diesen Satz; am nächsten kommt ihm eine Empfehlung: „The volume of potentially adverse events to be analyzed is generally quite high, so organizations should rely on technical solutions that filter large event datasets down to a subset that is suitable for human viewing and analysis.“ (Das Volumen potenziell schädlicher Ereignisse ist in der Regel hoch; Organisationen sollten daher auf technische Lösungen setzen, die große Ereignismengen auf eine für Menschen sichtbare und analysierbare Teilmenge filtern.)³³ Ich nehme den Filter als Anweisung und den Digest als einen solchen.

Eine Herstellerumfrage, als solche gekennzeichnet. Die Umfrage 2023 von Vectra AI, durchgeführt von Sapio Research unter 2.000 Sicherheitsanalysten, berichtet: „SOC teams receive an average of 4,484 alerts per day, and over two-thirds (67%) of them are ignored.“ (SOC-Teams erhalten im Schnitt 4.484 Alarme pro Tag, und über zwei Drittel, 67 Prozent, davon werden ignoriert.)³⁴ Es ist eine vom Hersteller beauftragte Meinungsumfrage, und die 67 Prozent sind das, was die Befragten angaben, keine Messung. Ich zitiere sie nur für einen Punkt: Das Versagen skaliert auch nach unten. Analysten sagen, sie ignorierten zwei Drittel von 4.484 Alarmen am Tag, und ein einzelner Leser ohne Team hörte bei 74 auf zu lesen.

4. Die Neugestaltung, als Regeln

Die Änderung ging am 1. November um 13:50 Uhr live, 18 Minuten nach meiner Nachricht, und eine zweite Änderung um 14:00 Uhr verschärfte eine ihrer Bedingungen.¹⁸ Ich habe sie als Regeln aufgeschrieben, jede mit ihrem Daseinsgrund.

Regel 1: ein Digest pro Tag, und er ist der Heartbeat. Der erste Lauf des Monitors nach 07:00 Uhr Ortszeit verschickt eine E-Mail, die das Zeitfenster seit dem vorigen Digest abdeckt.¹⁸³⁵ Die Beschreibung des Digests sagt selbst, was diese E-Mail ersetzt: „One email a day … in place of an email per auto-block and per WAF-handled CRITICAL.“ (eine E-Mail pro Tag … anstelle einer E-Mail pro automatischer Sperre und pro von der WAF erledigtem kritischen Alarm).³⁵ Er beginnt mit dem Laufzustand (aufgezeichnete Läufe, gestartete und beendete Läufe, Fehler, versandte und unterdrückte Alarm-E-Mails), dann folgen die automatischen Sperren mit Zone, Grund und Netzbetreiber, jeder kritische Alarm und was aus ihm wurde, die Befunde nach Schweregrad und Kategorie, die angefragten Probe-Pfade und die offenen Befunde des lokalen Scanners.¹² Der Grund für den Digest ist das Postfach. Der Grund, ihn täglich zu schicken, steht in derselben Beschreibung: „The digest is also the heartbeat: it goes out on a quiet day too“ (der Digest ist auch der Heartbeat, also das Lebenszeichen: Er geht auch an einem ruhigen Tag hinaus).³⁵ Ein Alarmstrom, der sich nur meldet, wenn etwas passiert, kann mir den Unterschied zwischen einem ruhigen Tag und einem toten Monitor nicht zeigen. Ein Digest, der immer ankommt, kann es: Stille bedeutet Defekt, nicht Ruhe. Die Notizen des Programms halten fest, warum mir das wichtig ist: Früher im Jahr 2026 lief der Monitor monatelang tot, und nichts bemerkte es.³⁵

Regel 2: Sperren gehen in den Chat, nicht ins Postfach. Die Design-Notizen brauchen dafür vier Wörter: „Per block: Slack only.“ (pro Sperre: nur Slack).³ Eine Sperre ist die Edge, die in meinem Auftrag handelt. In den Begriffen des SRE-Buchs ist sie Logging: aufgezeichnet, später nützlich und nichts, worauf ein Mensch reagieren muss.⁷ Der Chat behält den Livestrom für die Momente, in denen ich einen verfolgen will, und der Digest behält die Aufzeichnung.

Regel 3: einen kritischen Alarm umleiten, wenn die Edge ihn bereits erledigt hat. Ein kritischer Alarm versucht weiterhin zuerst zu sperren; danach entscheidet der Monitor, ob er eine E-Mail verdient.³ Zwei Bedingungen leiten ihn stattdessen in den Digest um, geprüft in dieser Reihenfolge. Die erste: Die eigene Adresse des Befunds und jede darin enthaltene Adresse, die für eine automatische Sperre infrage kommt, steht bereits auf der aktiven Sperrliste, die Edge hält diese Adressen also gerade auf.³¹⁴ Diese Prüfung betrachtet keine anderen Adressen und läuft, bevor die Stichprobe untersucht wird; eine Flut, die sie umleitet, kann also noch Ereignisse ohne verzeichnete Sperre oder Challenge enthalten, von Adressen unterhalb der Sperrschwelle; dieser Zweig sagt, dass die Ziele des Responders gesperrt sind, nicht, dass jedes Ereignis entschärft wurde. Die zweite gilt für eine WAF-Flut, eine Häufung von Firewall-Ereignissen auf einer Zone: Sie leitet nur um, wenn für jedes Ereignis in der Stichprobe, ob Bot oder nicht, eine Sperre oder Challenge verzeichnet ist und die Stichprobe vollständig ist. „A solved or bypassed challenge, log, allow and skip all count as unmitigated.“ (Eine gelöste oder umgangene Challenge, log, allow und skip zählen alle als nicht entschärft.)³ Cloudflares Definitionen erklären, warum diese vier gegen die Umleitung zählen: Nach einer Challenge gilt „If successful, Cloudflare accepts the matched request“ (bei Erfolg akzeptiert Cloudflare die betroffene Anfrage), und eine log-Aktion „Records matching requests in the Cloudflare Logs.“ (zeichnet passende Anfragen lediglich in den Cloudflare Logs auf).³⁶ Ein Befund des Persistent-Scanner-Checks, der nur Ereignisse zählt, die die Edge gesperrt oder herausgefordert hat, wird aus diesem Grund über die WAF-Umleitung umgeleitet, oder über die Sperrlisten-Umleitung, wenn seine Adresse bereits auf der Liste steht, wie es beim Befund vom 2. November der Fall war.³ Alles andere geht sofort per E-Mail hinaus.

Regel 4: Das Ergebnis steht auf dem Befund. Die Richtlinie lautet, dass jeder kritische Alarm der Cloud-Hälfte genau ein aufgezeichnetes Ergebnis trägt: umgeleitet, weil die Adresse auf der Sperrliste steht; umgeleitet, weil die Edge jedes Ereignis der Stichprobe gesperrt oder herausgefordert hat; gemailt; unterdrückt (innerhalb des Limits von einer E-Mail pro Website und Kategorie alle zwei Stunden); oder E-Mail fehlgeschlagen.³³⁷ Die Aufzeichnung bleibt hinter der Richtlinie zurück. Von den kritischen Alarmen mit UTC-Datum 1. November tragen 118 kein Ergebnis: 117 entstanden, bevor es das Feld gab, und ein kritischer Cloud-Alarm um 14:13 Uhr PST kam danach; sein Lauf war einer der drei aus Abschnitt 7, die etwa vier Minuten nach dem Start endeten, und er brach während der automatischen Sperre ab, bevor ein Ergebnis geschrieben wurde. Die kritischen Alarme des lokalen Scanners tragen nie eines; die drei vom 2. November haben keines.³⁷³⁸ Seit dem 3. November schreibt der Monitor „pending“ (ausstehend) auf einen kritischen Alarm, bevor die automatische Sperre läuft, sodass ein mittendrin abgebrochener Lauf einen sichtbaren Zustand hinterlässt statt einer Lücke.¹⁴ Der Digest druckt das Ergebnis neben jeden kritischen Cloud-Alarm, unter einer Überschrift, die das verspricht: „Every CRITICAL and what became of it“ (jeder kritische Alarm und was aus ihm wurde).¹² Das Ergebnisfeld ist mein Mechanismus, nicht Ewaschuks. Seine Bedingung für einen täglichen Bericht ist eine Person, die dafür bestimmt ist, ihn täglich zu sichten, und hier bin das ich; das Feld gibt dieser Triage etwas zu prüfen.³⁰ Mit dem Ergebnis auf jeder Zeile beantwortet der Digest die Frage, die ich am 1. November stellte, Routine oder ernst, einen kritischen Alarm nach dem anderen, wobei „emailed“ (gemailt) oder „folded“ (umgeleitet) sagt, wohin ein kritischer Alarm ging, nicht, dass etwas gelöst wurde.

Regel 5: Der stündliche Volumenalarm bleibt. Wieder die Notizen: „Hourly volume alert (responder): still immediate, at most once an hour“ (stündlicher Volumenalarm des Responders: weiterhin sofort, höchstens einmal pro Stunde).³ Eine einzelne Sperre ist Routine; ein plötzlicher Stapel davon in einer Stunde ist das, was einem Symptom in der Cloud-Hälfte am nächsten kommt, eine Veränderung in dem, was das Internet mit mir macht. Er löste am 2. November einmal aus.⁵

Regel 6: Die kritischen Alarme des lokalen Scanners mailen weiterhin sofort. Die Design-Notizen halten sie sofortig, weil sie selten sein sollen.³ Ich behalte sie aus einem zweiten Grund: Zwischen meinem Mac und einem lokalen Befund steht nichts so, wie die Edge zwischen meinen Websites und einem Scanner steht. Eine Sperrliste kann eine Adresse stoppen; nichts außerhalb des Macs stoppt einen Prozess darauf. Die Kosten dieser Regel zeigen sich in Abschnitt 7.

Am Tag, an dem die Regeln live gingen, senkten sie den Mailstrom von 74 E-Mails vor 13:32 Uhr auf sieben protokollierte im Rest des Tages (sechs kritische Alarme und ein stündlicher Alarm), plus den Digest, den ich von Hand verschickte.⁵² Die Prognose, die ich an jenem Nachmittag schrieb, lautete „Under today’s traffic that would have been 0 immediate emails instead of 16.“ (Beim heutigen Traffic wären das 0 sofortige E-Mails statt 16 gewesen.)¹ Sie hielt nicht, und Abschnitt 6 erklärt, warum.

5. Der Testfall: 2. November, 11:03 bis 11:21 Uhr

Der erste echte Test der Regeln kam am nächsten Morgen: Eine Adresse, die zu einem niederländischen Hosting-Anbieter gehört, ließ einen Schwachstellenscanner über meine Website laufen.¹² Hier steht, was der Monitor schrieb, wörtlich aus seinem Log in lokaler pazifischer Zeit, die Adresse ersetzt durch „[the address]“ und die Zeilen dazwischen ausgelassen.⁴

[2026-11-02 11:03:53] [INFO] New finding [critical]: Request flood from [the address] on blakecrosley.com
[2026-11-02 11:04:02] [RESPOND] [INFO] Block notification: Slack posted, email folded into the daily digest
[2026-11-02 11:04:03] [INFO] Critical alert folded into the daily digest (IP on the block ledger): Request flood from [the address] on blakecrosley.com
[2026-11-02 11:04:04] [INFO] New finding [critical]: Scanner from [the address] on blakecrosley.com
[2026-11-02 11:04:05] [RESPOND] [INFO] Skip: [the address] already has active real block in blakecrosley.com (dedup)
[2026-11-02 11:04:05] [INFO] Critical alert folded into the daily digest (IP on the block ledger): Scanner from [the address] on blakecrosley.com
[2026-11-02 11:09:22] [INFO] New finding [critical]: 726 WAF blocks in 5 minutes
[2026-11-02 11:09:23] [INFO] Critical alert folded into the daily digest (IP on the block ledger): 726 WAF blocks in 5 minutes
[2026-11-02 11:09:44] [INFO] New finding [critical]: Persistent scanner: [the address] blocked 743 times today
[2026-11-02 11:09:47] [RESPOND] [INFO] Block notification: Slack posted, email folded into the daily digest
[2026-11-02 11:09:47] [INFO] Critical alert folded into the daily digest (IP on the block ledger): Persistent scanner: [the address] blocked 743 times today

Minute für Minute:

• 11:03:53. Der Detektor für Anfragefluten erzeugt einen kritischen Alarm gegen die Adresse. Acht Sekunden später, um 11:04:01, setzt der Responder sie auf die Sperrliste, und um 11:04:02 geht die Sperrbenachrichtigung in den Chat, ihre E-Mail in den Digest umgeleitet.⁴
• 11:04:03. Der kritische Alarm selbst wird umgeleitet: Die Adresse steht jetzt im Sperrregister, die Edge erledigt also bereits die Arbeit, zu der mich eine E-Mail auffordern würde.⁴
• 11:04:04. Ein zweiter Detektor, die Scanner-Prüfung, erzeugt einen eigenen kritischen Alarm für dieselbe Adresse. Die Sperranfrage des Responders wird als Duplikat übersprungen, und der kritische Alarm wird eine Sekunde später umgeleitet.⁴
• 11:09:22. Der WAF-Flut-Detektor erzeugt einen dritten kritischen Alarm für die Zone. Ihr Verursacher steht im Register, und der Alarm wird umgeleitet.⁴¹¹ Entscheidend ist allein die Sperrlisten-Umleitung: Für acht der Ereignisse in der Stichprobe war weder Sperre noch Challenge verzeichnet, und die Stichprobe war gekappt; die WAF-Umleitung allein hätte ihn also gemailt.¹¹
• 11:09:44. Die Persistent-Scanner-Prüfung, die zählt, welche Ereignisse einer Adresse die Edge über alle meine Zonen hinweg gesperrt oder herausgefordert hat, erzeugt den vierten, verzeichnet auf einer anderen meiner Websites: 743 gesperrte oder herausgeforderte Ereignisse von der Adresse an diesem Tag.¹² Der Responder schreibt die Adresse ein zweites Mal auf die Liste (ein Defekt, siehe unten), postet in den Chat und leitet den kritischen Alarm um 11:09:47 um.⁴¹¹
• 11:14:58 und 11:20:40. Zwei weitere kritische WAF-Flut-Alarme für dieselbe Zone; beide werden auf dieselbe Weise umgeleitet.¹¹

Vier kritische Alarme in 5 Minuten und 51 Sekunden, sechs bis 11:20 Uhr, alle auf ihren Befunden als umgeleitet verzeichnet, weil die Adresse gesperrt war.¹¹ Eine Adresse gesperrt, ihr Listeneintrag zweimal geschrieben, weil die Duplikatprüfung damals pro Website arbeitete (behoben am 3. November), vier weitere Sperranfragen als Duplikate übersprungen.⁴¹⁴ E-Mails: null. Das Log verzeichnet zwischen 11:03 und 11:21 Uhr keine versandte E-Mail; der eine kritische Alarm in diesem Fenster, der weder umgeleitet noch gemailt wurde, unterdrückt um 11:03:13, war eine Flut auf einer anderen Website von einer anderen Adresse.⁴

Der nächste Digest führte das als zwei Zeilen in der Tabelle der automatischen Sperren (die erste Sperre mit Zone, Grund und Netzbetreiber sowie die erneute Aufnahme durch den Persistent-Scanner-Check) und sechs Zeilen in der Tabelle aller kritischen Alarme, jede markiert mit „blocked“ (gesperrt) oder „blocked earlier“ (früher gesperrt).¹² Nach meiner Lesart ist das das richtige Gewicht für einen Scanner, den der Monitor acht Sekunden nach seinem ersten Befund und acht Minuten nach Beginn des Scans gesperrt hat: ein paar Zeilen, die ich beim Kaffee lesen kann, keine Alarmierung, die mich aus dem Schlaf holt.⁴

Eines zeigt der Testfall nicht, entdeckt am 3. November. Derselbe Scanner schickte auch Einträge an das Kontaktformular meiner Website, Einträge, auf die meine App mit 200 antwortete, die mir also höchstens 31 eigene E-Mails einbrachten und die Thema des Begleitbeitrags sind, und die Formularflut-Prüfung des Monitors erzeugte live keinen Befund; über vollständige Daten für die fünf Minuten bis 11:03:23 Uhr nachgespielt, erzeugt dieselbe Prüfung den Befund, mit Schweregrad high (eine Zeile im Digest, keine E-Mail und keine Sperre), aus 39 Einträgen, von denen 23 abgewiesen wurden.³⁹ Der Live-Lauf hatte Cloudflare nach einem Fenster gefragt, das im Moment der Anfrage endete, 37 Sekunden nach dem Start des Laufs, bevor die neuesten Ereignisse vollständig eingetroffen waren: Er zählte in diesem Fenster 1.914 Anfragen von der Adresse, wo die Wiederholung über vollständige Daten 2.143 zählt.⁴³⁹ Diese Verzögerung ist an allen Anfragen der Adresse gemessen, nicht an den Formulareinträgen, die die Prüfung zählt; nach meiner Lesart hielt dieselbe Verzögerung diese Einträge live unter der Schwelle der Prüfung. Zudem blickte jeder Lauf genau fünf Minuten zurück, während die Läufe im Abstand von etwa 5,6 bis 5,8 Minuten starteten, sodass ein Teil jedes Intervalls nie erfasst wurde.³⁹¹⁷ Die Korrektur ging am selben Tag live: Jedes Fenster beginnt jetzt dort, wo das vorige endete, und endet 90 Sekunden vor dem Lauf, es sei denn, der vorige Eintrag fehlt, ist jünger als eine Minute oder älter als 15 Minuten, wie nach dem Ruhezustand des Macs; dann fällt der Lauf auf einen schlichten Rückblick von fünf Minuten zurück.³⁹ Das Fenster vom 2. November durch den geänderten Code nachgespielt ergibt dieselben Befunde; die Änderung hat die Erkennung auf einem festen Fenster also nicht beeinträchtigt. Eine Wiederholung kann das lückenlose Aneinanderreihen der Fenster oder die Verzögerung nicht prüfen, weil beide nur in Live-Läufen wirken; die Live-Läufe ab dem 3. November sind ihr Test.³⁹

6. Was weiterhin mailt, und warum

Der 2. November war der erste volle Tag unter den neuen Regeln, und er brachte 19 E-Mails, nicht eine: 14 kritische Alarme, einen stündlichen Volumenalarm, einen Digest und drei vom lokalen Scanner.⁵ Keine E-Mail pro Sperre ging hinaus; 108 Sperrbenachrichtigungen wurden stattdessen in den Digest umgeleitet, 177 kritische Alarme umgeleitet und 37 weitere durch das Zwei-Stunden-Limit unterdrückt, alles nach lokalem Tag gezählt; die Ergebniszahlen weiter unten in diesem Beitrag richten sich nach dem UTC-Datum, weshalb diese Zahlen abweichen.⁵

E-Mails pro lokalem Tag nach Strom; der 31. Oktober umfasst nur die 89 Minuten nach Beginn des Logs.⁵

Jeder kritische Cloud-Alarm, der nach der Änderung um 13:50 Uhr bis zum Ende des 2. November gemailt wurde, insgesamt 20 (sechs im Rest des 1. November, vierzehn am 2. November), war eine WAF-Flut auf resumegeni.com oder blakecrosley.com, bei der für mindestens ein Ereignis weder Sperre noch Challenge verzeichnet war.¹³ Die WAF-Umleitung lehnte jeden davon nach ihrer eigenen Regel korrekt ab: In der Stichprobe lag ein nicht entschärftes Ereignis, also konnte der Monitor nicht behaupten, die Edge habe es erledigt.³ In diesen Fluten hatte keine Adresse genug Ereignisse, um für eine automatische Sperre infrage zu kommen, sodass die Sperrlisten-Umleitung keine Adresse zu prüfen hatte.¹³ Der Digest benennt die Gruppe genauso: „a CRITICAL that was neither blocked nor already handled by the WAF“ (ein kritischer Alarm, der weder gesperrt noch bereits von der WAF erledigt wurde).¹²

Die Betreffzeilen dieser E-Mails erzählten eine andere Geschichte, und das war ein Defekt. Die Flut-Zusammenfassung lautete „N WAF blocks in 5 minutes“ (N WAF-Sperren in 5 Minuten), aber N zählte jedes Nicht-Bot-Firewall-Ereignis im Fenster, gleich welche Aktion die Edge darauf ausführte.¹³ Zwei Beispiele aus den Befunden, in Ortszeit:

Die erste E-Mail behauptete 104 Sperren, obwohl die Edge nichts gesperrt hatte.¹³ Nach meiner Lesart ist ein Betreff, der bei Ereignissen ohne verzeichnete Sperre „blocks“ sagt, schlimmer als Rauschen: Er teilt dem einzigen Leser mit, das System habe erledigt, was es womöglich nicht erledigt hat. Meine erste Korrektur am 3. November, dem Tag, an dem diese Zählungen entstanden, war selbst falsch. Sie behielt die Nicht-Bot-Zahl für N und zählte gesperrt, herausgefordert und den Rest über alle Ereignisse, sodass der Ausbruch um 16:51 Uhr 104 WAF events in 5 minutes: 0 blocked, 0 challenged, 117 through gelautet hätte, zwei Grundgesamtheiten in einer Zeile. Die Prüfung dieses Beitrags hat das aufgedeckt, und ich habe es am selben Tag noch einmal korrigiert.¹⁴ Die Flut-Zusammenfassung und mit ihr der E-Mail-Betreff zählen jetzt eine Grundgesamtheit, jedes Firewall-Ereignis der Stichprobe, und lauten N WAF events in 5 minutes: B blocked, C challenged, U unmitigated (S from non-bot user agents); eine JavaScript-Challenge zählt als herausgefordert, und der Grund der automatischen Sperre lautet N WAF events from this address in 5 min.¹⁴ Für den Ausbruch um 16:51 Uhr ergibt das 117 WAF events in 5 minutes: 0 blocked, 0 challenged, 117 unmitigated (104 from non-bot user agents).¹³¹⁴ Die WAF-Umleitung richtete sich bereits nach nicht entschärften Ereignissen, also zählen Betreff und Entscheidung jetzt dasselbe. Die Korrektur ändert, was die 14 Betreffzeilen sagen. Sie ändert nicht, wie viele verschickt wurden, und 19 bleibt die ehrliche Zahl für den 2. November.

Die Prognose, die ich am 1. November schrieb, verfehlte ihr Ziel, weil ihre Prämisse falsch war. Sie besagte, die neuen Regeln „would have been 0 immediate emails instead of 16“ (hätten 0 sofortige E-Mails statt 16 bedeutet), in der Annahme, dass für die sieben kritischen Alarme nach 00:30 Uhr an jenem Morgen „Cloudflare had already blocked every one of those requests.“ (Cloudflare jede dieser Anfragen bereits gesperrt hatte).¹ Die Befunde sagen auch für diese etwas anderes: Die fünf, die laut Log nach 00:30 Uhr gemailt wurden, verzeichnen jeweils höchstens eine Sperre und neun Challenges, gegenüber 76 bis 89 Ereignissen in ihren Zusammenfassungen.¹³ Und bei jedem der sechs kritischen Alarme, die an jenem Nachmittag und Abend gemailt wurden, hatte die Edge nur einen Teil der Ereignisse gesperrt oder herausgefordert (beim Ausbruch um 16:51 Uhr gar keines), sodass selbst die Regel von 13:50 Uhr, die nur umleitete, wenn Sperren und Challenges jedes Nicht-Bot-Ereignis abdeckten, jeden davon gemailt hätte.¹³¹ Zehn Minuten nach der Änderung um 13:50 Uhr ließ eine zweite Änderung die WAF-Umleitung jedes Ereignis zählen, mit oder ohne Bot-User-Agent, und nur einer vollständigen Stichprobe vertrauen; sie machte die Regel strenger, ist aber nicht der Grund, warum die Prognose danebenlag.¹⁸³ Die Prognose zählte die Sperren, an die ich glaubte; die Regel zählte die Ereignisse, die tatsächlich da waren.

Was ich nicht weiß, ist, ob diese 14, die kritischen Alarme vom 2. November, die gemailt wurden, eine E-Mail verdient hatten. Die Befunde verzeichnen, wie viele Ereignisse nicht entschärft waren, also ohne verzeichnete Sperre oder Challenge, aber nicht, welche Aktionen sie trugen: eine log-Regel, ein skip, ein allow oder eine Challenge, die ein Client gelöst hat.¹³ Ein nicht entschärftes Ereignis ist auch keine Anfrage, die meine Website erreicht hat. Cloudflare schreibt „A single HTTP request can generate one or more security events when it triggers security features“ (eine einzelne HTTP-Anfrage kann ein oder mehrere Sicherheitsereignisse erzeugen, wenn sie Sicherheitsfunktionen auslöst), und führt log und skip als Aktionen, die die Regelauswertung nicht so beenden wie eine Sperre; nach meiner Lesart kann also eine andere Regel noch auf dieselbe Anfrage reagieren.²⁴³⁶ Cloudflares GraphQL-Tutorial zeigt das Feld action und Beispielwerte wie "log" und "block", listet aber nicht alle Werte auf, die das Feld annehmen kann.²³ Auch Cloudflares Security-Events-Dashboard arbeitet mit Stichproben: „For large volumes of traffic, Cloudflare uses sampling to return results faster.“ (Bei großen Trafficmengen verwendet Cloudflare Stichproben, um Ergebnisse schneller zu liefern.)²⁴ Solange der Monitor nicht die Aktionen hinter jedem nicht entschärften Ereignis aufzeichnet und Ereignisse mit Anfragen verknüpft, kann ich nicht sagen, welche dieser E-Mails Traffic beschrieben, den die Edge durchgelassen hat, und genau diese Antwort entscheidet, ob sie eine E-Mail verdienen.

Die drei lokalen E-Mails vom 2. November sind der andere offene Punkt. Sie melden um 13:50 Uhr eine „Browser -> shell chain“ (Kette vom Browser zur Shell), in der eine Shell curl startete, und sie stehen unerledigt in den Befunden.⁴⁰ Ich habe nicht verifiziert, ob es das Agenten-Tooling war, das ich an jenem Nachmittag laufen ließ, oder etwas anderes, also zähle ich sie nicht als Fehlalarme.

7. Zwei falsche Signale

Der Krypto-Miner, der Spotlight war

Am 1. November um 10:03 Uhr erzeugte der lokale Scanner einen kritischen Alarm, „High CPU unsigned process - possible crypto miner“ (unsignierter Prozess mit hoher CPU-Last, möglicherweise ein Krypto-Miner), gegen spotlightknowledged, Apples eigenen Spotlight-Daemon, bei 74,9 Prozent CPU, und protokollierte zwei Sekunden später „Critical email sent.“¹⁵ Der Fehler lag bei mir. Die Prüfung suchte die Wendung „valid on disk“ in der Ausgabe des Befehls zur Anzeige der Codesignatur, codesign -d. Die Notizen des Scanners halten den Fehler inzwischen in einem Nebensatz fest: Die Wendung sei eine, „which only codesign -v prints, so every process read as unsigned“ (die nur codesign -v ausgibt, sodass jeder Prozess als unsigniert galt).²⁵ Eine Ausnahmeliste hatte den Fehler verdeckt, bis ein Daemon aus einem Apple-Framework hochschnellte, und mein Log jenes Tages sagt das auch.¹ Der Befund trägt jetzt seine Auflösung: „false positive, Apple platform binary“ (Fehlalarm, Apple-Plattformbinärdatei).⁴¹

Es kostete eine E-Mail, die einzige lokale E-Mail des 1. November.⁵ Die 16 lokalen kritischen Alarme davor, am 31. Oktober und 1. November, markierten Xcode, das Python von Homebrew, meine eigenen App-Builds, Hook-Änderungen, Shims von Versionsmanagern im Suchpfad, ein KI-Wurm-Muster, das auf die Agentenanweisungen eines anderen Projekts passte, und eine Event-Tap-Prüfung, die auf ihre eigene Abfrage passte; sie erzeugten 15 Versandversuche, und jeder davon schlug fehl.^5251915 Der Maildienst sitzt hinter Cloudflare, das auf Pythons Standard-User-Agent mit dem Fehler 1010 antwortete, bevor der Schlüssel gelesen wurde; ich habe das mit einem absichtlich falschen Schlüssel reproduziert.¹⁹ Cloudflares Seite zu diesem Fehler nennt genau diesen Client in ihrem Hinweis zu Pages- und Workers-Hosts: „a User-Agent header that Browser Integrity Check treats as a non-browser client (for example, the default Python urllib user agent).“ (ein User-Agent-Header, den Browser Integrity Check als Nicht-Browser-Client behandelt, zum Beispiel der Standard-User-Agent von Python urllib).⁴² Ein kaputter Absender ersparte mir 15 E-Mails über meine eigenen Werkzeuge und meine eigenen Änderungen.¹⁵ Die Notizen des Scanners formulieren die größere Lehre unverblümt: „most of the CRITICALs it raised in its first live days were its own noise.“ (die meisten kritischen Alarme seiner ersten Live-Tage waren sein eigenes Rauschen).²⁵ Ich halte die lokalen kritischen Alarme trotzdem sofortig und behebe jeden falschen an seiner Prüfung, statt den Strom stummzuschalten.

RUNS SHORT 162/207

Der erste planmäßige Digest, am Morgen des 2. November, trug den Betreff „Mon Nov 2: 71 blocks on 15 zones, 11 criticals emailed, RUNS SHORT 162/207“ (Mo., 2. Nov.: 71 Sperren auf 15 Zonen, 11 kritische Alarme gemailt, zu wenige Läufe 162/207).¹⁶ Die Regel des Digests war simple Arithmetik: Die erwartete Zahl der Läufe ist die Zahl der Minuten im Fenster geteilt durch fünf, und der Betreff markiert eine Unterschreitung.³⁵ Das Fenster reichte vom 1. November 13:48 Uhr bis zum 2. November 07:05 Uhr, 1.036,5 Minuten, also 207 Fünf-Minuten-Slots; das Log verzeichnete 162 Läufe.¹⁷

Mein Log vom 2. November erklärte die Lücke in einer Zeile: „The RUNS SHORT line is the Mac asleep“ (die RUNS-SHORT-Zeile ist der schlafende Mac), ohne Fehler im Monitor.⁴³ Diese Zeile hat recht damit, dass der Monitor nicht versagt hat (kein Lauf am 2. November blieb unbeendet), und unrecht mit der Ursache, sowohl am 2. November als auch über das Fenster, das die Zahl beschrieb. Die Analyse der Laufabstände teilt die 45 fehlenden Slots näherungsweise auf: etwa 25 gingen an den Takt verloren, etwa 16 an den Ruhezustand, etwa einer mehr an eine lange Lücke nach einem vorzeitig beendeten Lauf, und drei Läufe haben sich nie selbst verzeichnet.¹⁷

Das Power-Log zeigt Idle Sleep um 23:21:30 Uhr und vollständiges Aufwachen um 00:30:05 Uhr, und erneut Idle Sleep um 06:01:20 Uhr und vollständiges Aufwachen um 06:30:28 Uhr.⁴⁴ Die drei Läufe starteten am 1. November um 14:09, 14:19 und 23:10 Uhr; jeder endete etwa vier Minuten später ohne protokollierte Endzeile, was nach meiner Lesart der 240-Sekunden-Watchdog ist. Ein vierter Lauf endete 28 Sekunden nach dem Start ohne erkennbare Ursache.¹⁷³⁸ Am Kalendertag 2. November starteten 242 Läufe gegenüber 288 Fünf-Minuten-Slots, 46 zu wenig, und keiner blieb unbeendet; nur zwei Abstände überschritten 10 Minuten, insgesamt 35,8 Minuten, sodass auch an diesem Tag der Großteil der Unterschreitung auf den Takt zurückging, nicht auf den Ruhezustand.¹⁷

Die falsche Annahme war meine, im Digest: Ein auf fünf Minuten eingestellter Scheduler lieferte selbst bei wachem Mac etwa alle 5,6 bis 5,8 Minuten einen Lauf, sodass die Fünf-Minuten-Arithmetik einen gesunden Tag als zu kurz einstufen würde.¹⁷ Warum der Takt im Wachzustand langsamer läuft, habe ich nicht geklärt. Die Arithmetik habe ich am 3. November ersetzt. Der Laufzustand meldet jetzt die verzeichneten Läufe, den Median der Minuten zwischen ihnen und die längste Lücke mit ihrer Uhrzeit, und der Betreff markiert nur eine Lücke von mehr als 20 Minuten. Die Vorschau an jenem Morgen lautete „about one every 5.6 min“ (etwa einer alle 5,6 Minuten), und ihr Betreff endete mit „RUN GAP 31 min at 05:56“ (Laufpause von 31 Minuten um 05:56 Uhr).¹⁴ Eine Lücke ist ein Symptom, auf das ich reagieren kann: Der Mac schlief, oder der Monitor stand still. Ein Verhältnis gegenüber einem Takt, den der Scheduler nie geliefert hat, war keins von beiden.

Die Regeln, die ich behalten habe

1. Zählen Sie die Post, bevor Sie sie ändern, nach Strom und mit einer festgelegten Regel. Meine Tabelle und die Logzählung stimmten bei 74 nur überein, weil ich zuerst aufgeschrieben hatte, was als E-Mail zählt.¹²
2. Protokollieren Sie „sent“ nur, wenn der Maildienst Ja sagt. Für 22 meiner 74 E-Mails kann ich einen Versuch belegen und nichts weiter.²⁶
3. Eine Sperre, die die Edge bereits gesetzt hat, ist eine Logzeile, kein Alarm. Die drei Ausgaben des SRE-Buchs ordnen sie dort ein, und das Verschieben von 55 E-Mails pro Sperre in den Chat kostete nichts, worauf ich je reagiert hätte.⁷⁵
4. Schicken Sie einen täglichen Digest, auch wenn nichts passiert ist. Ein Digest, der immer ankommt, ist der Heartbeat; sein Ausbleiben ist der Alarm.³⁵
5. Leiten Sie einen kritischen Alarm nur unter einer Bedingung um, die die Edge belegt. Meine sind: die sperrbaren Adressen des Befunds stehen bereits auf der Sperrliste, und eine vollständige Stichprobe, in der für jedes Ereignis eine Sperre oder Challenge verzeichnet ist; die zweite ist der Grund, warum am 2. November noch 14 gemailt wurden.³¹³
6. Schreiben Sie das Ergebnis auf jeden kritischen Cloud-Alarm. Ein täglicher Bericht, für den niemand verantwortlich ist, ist in Ewaschuks Worten „less-spammy email alerts“ (weniger spammige E-Mail-Alarme); das Ergebnis auf jeder Zeile ist das, was meine tägliche Triage prüft.³⁰¹²
7. Lassen Sie den Betreff sagen, was die Edge getan hat. „104 WAF blocks“ bei einem Ausbruch mit null Sperren war meine schlechteste Zeile der Woche.¹³
8. Melden Sie Lücken, keine Verhältnisse gegenüber einem Zeitplan. Ein Fünf-Minuten-Timer lieferte etwa alle 5,6 Minuten einen Lauf, also sah 162/207 nach einem Ausfall aus und war größtenteils eine Uhr.¹⁷
9. Beheben Sie einen Fehlalarm an seiner Prüfung, nicht im Postfach. Eine falsch gelesene Befehlsausgabe machte Apples Spotlight-Daemon zum Krypto-Miner; die Korrektur ging in die Prüfung.²⁵

Was sich ändern könnte

• Falls sich die nicht entschärften Ereignisse als gelöste Challenges herausstellen, würde das allein die kritischen WAF-Flut-Alarme, die weiterhin mailen, nicht zu Rauschen machen. Besteht ein Client eine Challenge, gilt „Cloudflare accepts the matched request“ (Cloudflare akzeptiert die betroffene Anfrage): Die Anfrage läuft weiter, und das zeigt weder, dass sie harmlos war, noch, dass keine Reaktion nötig ist. Um diese kritischen Alarme umzuleiten, bräuchte es Anfragebelege, die an dieselben Ereignisse gebunden sind und zeigen, dass darin nichts einen Menschen erforderte, und das Bestehen einer Challenge allein ist kein solcher Beleg. Stellen sie sich als log- oder skip-Regeln heraus, lautet die Frage, ob diese Regeln tun, was ich beabsichtigt habe, und jede E-Mail ist lesenswert, bis ich es weiß. Der Monitor verzeichnet noch nicht, was davon zutrifft.¹³³⁶
• Falls die kritischen E-Mails eines Tages wieder in Richtung Dutzende klettern, erledigt das Zwei-Stunden-Limit pro Website und Kategorie die Arbeit, die eine Regel erledigen sollte, und die Regel braucht einen neuen Blick.³
• Falls der Digest nicht mehr ankommt, ist zwischen dem Monitor und meinem Postfach etwas stehen geblieben: der Monitor, der Mac, auf dem er läuft, der Absender oder der Zustellweg, denn ein angenommener Versand ist noch kein zugestellter. Das ist die eine Stille, die das Design als Anlass zum Nachsehen behandelt.³⁵²⁰
• Falls der lokale Scanner einen kritischen Alarm erzeugt, den ich nicht mit meinem eigenen Tooling erklären kann, war die sofortige E-Mail die richtige Entscheidung; die drei ungeklärten Shell-Ketten-Befunde vom 2. November sind der offene Test dafür.⁴⁰
• Falls ich einen Leser hinzunehme, sind Alarmierungen und Tickets nicht mehr dieselbe Person, und die Trennung des SRE-Buchs zwischen Alerts und Tickets bräuchte eine Ticket-Queue, nicht mein Postfach.⁷

Zentrale Erkenntnisse

Wenn Sie einen Monitor für sich selbst betreiben

• Ich habe irgendwo unterhalb von 74 E-Mails in einem halben Tag aufgehört zu lesen, einer Zahl, die mein Postfach am frühen Nachmittag erreichte.¹
• Ein täglicher Digest, der auch an ruhigen Tagen ankommt, ist ein Heartbeat zum Nulltarif; ein Monitor, der sich nur bei Ereignissen meldet, kann Ihnen nicht sagen, dass er gestorben ist.³⁵
• Ihre Logs sagen womöglich „sent“ für Post, die nie hinausging. Prüfen Sie den Code, bevor Sie der Zählung trauen.⁶¹⁹

Wenn Sie einen bauen

• Erst handeln, dann entscheiden, ob Sie Bescheid geben: sperren, dann den Alarm umleiten, wenn die Sperrliste oder die Edge ihn bereits abdeckt.³
• Verzeichnen Sie das Ergebnis jedes kritischen Alarms auf dem Befund und drucken Sie es im Digest, damit die Person, die laut Ewaschuk einen täglichen Bericht sichten muss, etwas zu prüfen hat; bei meinem Monitor bin das ich.³⁰¹²
• Benennen Sie Ereignisse nach dem, was die Edge für sie verzeichnet hat (gesperrt, herausgefordert, nicht entschärft), zählen Sie eine Grundgesamtheit pro Zeile, und benennen Sie sie nie nach dem, was die Edge hoffentlich getan hat.¹³¹⁴
• Messen Sie den Scheduler, den Sie tatsächlich haben. Meiner lief alle 5,6 Minuten mit einem Fünf-Minuten-Timer.¹⁷

Wenn Sie derjenige sind, der das Postfach liest

• Fragen Sie bei jedem Alarm, ob er „urgent, important, actionable, and real“ (dringend, wichtig, handlungsrelevant und echt) ist; was durchfällt, gehört in einen Digest oder ein Log.²⁹
• Meine Prognose vom ersten Tag lag daneben: Sie sagte null sofortige kritische Alarme voraus, und der nächste Tag schickte 14.¹⁵

Häufige Fragen

Was ist Alarmmüdigkeit?

Alarmmüdigkeit ist das, was Menschen widerfährt, die zu viele Alarme empfangen, die nichts von ihnen verlangen: Sie werden, in den Worten der Joint Commission, „desensitized or immune to the sounds“ (gegenüber den Tönen abgestumpft oder immun) und beginnen, Alarme leiser oder ganz abzuschalten.¹⁰ Googles SRE-Buch beschreibt dasselbe im Betrieb, wo Menschen „second-guess, skim, or even ignore incoming alerts, sometimes even ignoring a “real” page that’s masked by the noise.“ (eingehende Alarme anzweifeln, überfliegen oder ignorieren, manchmal sogar eine „echte“ Alarmierung, die im Rauschen untergeht).²⁷ Mein eigener Fall dauerte einen Tag: 74 E-Mails bis 13:32 Uhr, von denen nach meiner Lesart an jenem Nachmittag keine mich zum Handeln aufforderte.¹

Wie viele Sicherheitsalarme pro Tag sind zu viele?

Für einen Menschen lautet die ehrliche Antwort des SRE-Kapitels: wenige. „I can only react with a sense of urgency a few times a day before I become fatigued.“ (Ich kann nur ein paar Mal am Tag mit Dringlichkeit reagieren, bevor ich ermüde.)⁸ Vectras Herstellerumfrage berichtet, dass Teams im Schnitt 4.484 Alarme am Tag erhalten und nach eigener Aussage 67 Prozent davon ignorieren.³⁴ Für meinen Ein-Personen-Monitor lautet die Arbeitsantwort: ein Digest pro Tag plus die Alarme, die jetzt einen Menschen brauchen; am 2. November waren das immer noch 19, und die 14 kritischen WAF-Flut-Alarme darunter behandle ich als offene Frage, nicht als ausgemachte Kosten.⁵¹³

Sollten Sicherheitsalarme als täglicher Digest oder in Echtzeit kommen?

Beides, aufgeteilt nach dem, was der Mensch tun muss. Alles, was der Monitor als bereits erledigt einstuft (eine Adresse, die er auf die Sperrliste gesetzt hat, oder eine Flut, in der jedes Ereignis der Stichprobe gesperrt oder herausgefordert wurde), kommt in den Digest; der Rest geht sofort hinaus, innerhalb des Zwei-Stunden-Limits.³ Ewaschuk räumt ein, dass ein täglicher Bericht „can work too“ (auch funktionieren kann), mit einer Bedingung: Ohne Verantwortlichkeit „amounts to less-spammy email alerts“ (läuft er auf weniger spammige E-Mail-Alarme hinaus), und er will jemanden, der „designated to triage these every day“ (dafür bestimmt ist, sie täglich zu sichten).³⁰ Bei meinem Monitor bin das ich, und mein Digest druckt, was aus jedem kritischen Cloud-Alarm wurde, damit die Triage etwas zu prüfen hat.¹²

Was ist ein Heartbeat-Alarm?

Ein Heartbeat ist eine Nachricht, die nach Zeitplan ankommt, ob etwas passiert ist oder nicht, sodass ihr Ausbleiben bedeutet, dass etwas kaputt ist. Mein täglicher Digest ist der Heartbeat: „it goes out on a quiet day too“ (er geht auch an einem ruhigen Tag hinaus), daher zeigt sich ein Monitor, der nicht mehr läuft, als fehlende E-Mail.³⁵ Ebenso ein fehlgeschlagener Versand oder eine verlorene Zustellung; ein fehlender Digest ist also ein Anlass, den Monitor, den Host, auf dem er läuft, den Absender und den Zustellweg zu prüfen.²⁰ Sein Abschnitt zum Laufzustand meldet außerdem die längste Lücke zwischen Läufen und markiert eine Lücke von über 20 Minuten im Betreff.¹⁴

Warum fluten Cloudflare-WAF-Alarme mein Postfach?

Meins wurde geflutet, weil jede Sperre und jeder kritische Alarm zu einer eigenen Nachricht wurde und das Internet jede öffentliche Zone den ganzen Tag scannt.⁵ Cloudflares eigene Alerts, „Monitors that you define yourself, and Platform Notifications“ (selbst definierte Monitors und Platform Notifications), lassen sich per E-Mail zustellen und werden im Dashboard eingerichtet; ein Monitor, den Sie wie ich selbst gegen die API bauen, ist keins von beiden und erbt jede Mail pro Ereignis, die Sie hineingeschrieben haben.²⁶ Prüfen Sie auch, was ein Alarm zählt: Zu Cloudflares Aktionen gehören log und skip, die die Regelauswertung nicht so beenden wie eine Sperre, und eine Challenge, die ein Client löst, endet damit, dass Cloudflare die Anfrage akzeptiert; „WAF events“ (WAF-Ereignisse) und „WAF blocks“ (WAF-Sperren) sind also verschiedene Zahlen.³⁶ Meine Betreffzeilen haben die beiden bis zum 3. November verwechselt.¹³¹⁴

Bedeutet ein 2xx der E-Mail-API, dass der Alarm zugestellt wurde?

Nein. Das Ereignis email.sent von Resend „Occurs whenever the API request was successful. Resend will attempt to deliver the message to the recipient’s mail server“ (tritt ein, sobald die API-Anfrage erfolgreich war; Resend versucht dann, die Nachricht an den Mailserver des Empfängers zuzustellen), und die Zustellung ist ein separates Ereignis.²⁰ Ein 2xx bedeutet, dass der Dienst die Nachricht angenommen hat. Protokollieren Sie den Statuscode und behandeln Sie die Zustellung als eigene Frage.⁶

Verwandt auf dieser Website: Warum Spam mein ratenbegrenztes Kontaktformular besiegte verfolgt denselben Scanner vom 2. November aus Sicht des Kontaktformulars; Was ich vor dem Schlafengehen ausführe ist der nächtliche Produktionscheck, die andere Routine, die läuft, während ich nicht hinsehe; Was wirklich kaputtgeht, wenn KI-Agenten unbeaufsichtigt laufen benennt die Fehlermodi unbeaufsichtigter Agenten-Sessions, jeden mit einem Erkennungssignal; Jeder Hook ist eine Narbe führt jeden meiner Agenten-Hooks auf das Versagen zurück, das ihn hervorgebracht hat, dieselbe Gewohnheit wie das Beheben eines Fehlalarms an seiner Prüfung; Der Auto-Modus von Claude Code ist keine Sicherheitsgrenze argumentiert, dass die Mauer um einen Agenten mehr zählt als sein Klassifikator; und Observability für KI-Agenten begründet, warum man sehen sollte, was Agenten mit Festplatte, CPU und Netzwerk anstellen.

Quellen

Alle Zeiten in den eigenen Daten des Autors sind lokale pazifische Zeit, sofern nicht als UTC gekennzeichnet; am 1. November wurde um 02:00 Uhr von PDT auf PST zurückgestellt. Öffentliche Seiten wurden am 3. November 2026 zu den angegebenen UTC-Zeiten abgerufen.