Die Statusseite war waehrend des Einbruchs die ganze Zeit gruen. Sie waere auch
gruen geblieben, wenn der Miner gelaufen waere. Es fehlte kein Bildschirm, auf
dem man es haette sehen koennen -- es fehlte etwas, das VON SICH AUS Bescheid
sagt. Deshalb kein Frontend, sondern zwei Pruefungen mit Meldeweg.
1. Ports, die auf allen Adressen lauschen, gegen einen hinterlegten Stand.
Port 3000 stand elf Tage offen; das haette am ersten Tag gemeldet werden
koennen. Dazu eine feste Liste heikler Ports, die auch dann warnt, wenn
der Zustand "schon immer so" war -- 3000 war auch schon immer so.
2. Pruefsummen ueber sshd_config, administrators_authorized_keys, beide
Compose-Dateien und Giteas app.ini und .gitconfig. Der Angriff WAR eine
Datei, die sich um 21:13:57 aenderte.
Gemeldet wird nur bei Aenderung, mit Merker in den Einstellungen. Ein Waechter,
der taeglich meckert, wird stummgeschaltet und ist dann schlechter als keiner.
VOR DEM EINRICHTEN AN BEIDEN FAELLEN BEWIESEN statt behauptet:
Testport 45999 geoeffnet -> "NEU offen: 45999"
Datei geaendert -> Meldung raus, HTTP 204
zurueckgestellt -> "Wieder in Ordnung (Merker geleert)"
Und er prueft zuerst, ob er ueberhaupt etwas sehen kann: findet er keine
Objekte, meldet er "ungueltig" statt "sauber". Das ist die Lehre aus zwei
Suchen in dieser Nacht, die genau das verwechselt haben.
Die Statusseite zeigt den Stand mit; meldet der Waechter sich zwei Stunden
nicht, ist DAS der Befund -- er laeuft alle 15 Minuten.
Im Bericht ausserdem nachgetragen: die Inventur von aussen (NPM-Verwaltung und
MariaDB standen offen, beide jetzt gesperrt), die abgeschalteten Ueberbleibsel
von Caddy und cloudflared, und zwei Irrtuemer von mir -- "Docker geht an der
Firewall vorbei" und "der MariaDB-root hat kein Passwort". Beide waren aus
Messungen geschlossen, die die Frage nicht beantworten konnten.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Test-NetConnection vom Heimrechner: TcpTestSucceeded False. Das war der letzte
offene Punkt der Nacht.
Die Messung vom Server aus taugte dafuer NICHT: Verkehr an die eigene
oeffentliche Adresse durchlaeuft die Eingangsregeln nicht und meldete
faelschlich "erreichbar". Zweimal in derselben Nacht in dieselbe Falle getappt,
einmal bei Port 3000 und einmal bei 3389 -- beide Male hat erst die Messung von
DRAUSSEN das Urteil gebracht.
Dazu: sshd nimmt nur noch Schluessel (Passwort UND keyboard-interactive aus,
vor dem ersten Match-Block), RDP per Firewall gesperrt, Zugang ueber
tools/tunnel-einrichten.ps1 als Hintergrundaufgabe.
Seitdem laufen die Angriffe ins Leere: "invalid user root ... [preauth]", und
alle 12 erfolgreichen Anmeldungen kommen von einer einzigen IP.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Kein Ausfall, kein Datenverlust, kein laufender Schadcode -- aber ein echter
Schreibzugriff von aussen.
Um 21:13:56 rief jemand /api/internal/manager/add-logger auf, legte einen
Datei-Logger auf die .gitconfig, liess die Nutzlast als Logzeile hineinschreiben
und entfernte den Logger eine Sekunde spaeter wieder. Eingeschleust war ein
packObjectsHook, der bei JEDEM Klonen einen Monero-Miner nachgeladen und per
crontab verankert haette.
WARUM TROTZDEM NICHTS LIEF: die Nutzlast beginnt mit "[uploadpack]\n", wobei
das \n als TEXT in der Datei steht statt als Umbruch. Git bricht mit "bad
config line 23" ab, der Hook wurde nie gueltig. Nachgemessen: kein Prozess,
keine Datei, keine crontab-Zeile, nichts in den Repos, kein Docker-Socket im
Container, keine fremden Konten oder Token. Der einzige Schaden war, dass alle
Git-Operationen ausfielen -- daran ist es aufgefallen.
DER WEG HINEIN: Gitea lag mit 0.0.0.0:3000 direkt im Internet, am Proxy vorbei.
Damit war /api/internal/* von aussen erreichbar, geschuetzt nur durch das
INTERNAL_TOKEN. Woher der Angreifer es hatte, liess sich NICHT klaeren -- es
steht in keinem Repo, und RDP war es nicht (2756 Fehlversuche in 14 Tagen, aber
alle 33 erfolgreichen Anmeldungen von der IP des Betreibers). Genau deshalb ist
die Antwort nicht "Token tauschen", sondern den Weg zumachen.
GEAENDERT: .gitconfig gesaeubert; Port 3000 gar nicht mehr veroeffentlicht; NPM
haengt jetzt mit in gitea_default und spricht gitea:3000 an (dafuer musste der
nginx-Resolver auf Dockers DNS 127.0.0.11 umgestellt werden); INTERNAL_TOKEN
und SECRET_KEY getauscht (gefahrlos: 2FA und Anmeldequellen jeweils 0);
/api/internal/ gibt am Proxy 404; frisches Abbild statt des elf Tage alten.
Gegengeprueft: Port 3000 von aussen 000, /api/internal/ 404, git.d4rkst3r.de
200, LFS-Direktiven alle drei erhalten, Push geht beim ersten Versuch, Repos
identisch mit den lokalen Klonen.
DIE LEHRE: der offene Port war nie noetig -- der Proxy haette von Anfang an
uebers interne Netz gehen koennen. Und aufgefallen ist es nicht, weil etwas
ueberwacht wurde, sondern weil der Angreifer geschludert hat. Haette er sein \n
richtig gesetzt, liefe der Miner noch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
D4rkst3randClaude Opus 5