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