Einen Einbruch erkennen, bevor der Anbieter anruft

Die Vorstellung, ein Einbruch mache sich bemerkbar, hält sich hartnäckig. Tatsächlich ist das Gegenteil das Ziel des Angreifers: Der Dienst läuft weiter, die Webseite antwortet, nichts stürzt ab. Die Maschine arbeitet nur zusätzlich für jemand anderen.

Gegenüberstellung: erwartete Signale wie Warnmeldung oder Virenscanner gegen tatsächliche Signale wie ausgehender Verkehr auf Port 25, neue Cronjobs, nächtliche CPU-Last und Beschwerden des Anbieters. — Die linke Spalte kommt in der Praxis nicht. Die rechte schon.

Warum hoch

Nicht weil ein Einbruch wahrscheinlich ist, sondern weil die Zeit bis zur Entdeckung darüber entscheidet, wie teuer er wird. Wer die Signale kennt und einmal im Monat zehn Minuten investiert, verkürzt diese Zeit von Monaten auf Tage.

Der Prüfdurchlauf#

Einmal im Monat, oder sofort bei Verdacht. Wichtig: Diese Befehle einmal auf einer gesunden Maschine laufen lassen und die Ausgabe aufheben. Ohne Referenz weiß man nicht, was normal ist.

1. Ausgehende Verbindungen#

sudo ss -tnp state established

Jede Zeile sollte erklärbar sein. Ein Prozess, den du nicht zuordnen kannst, mit einer dauerhaften Verbindung zu einer fremden Adresse, das ist der wichtigste Einzelbefund. Warum die ausgehende Richtung die aufschlussreichere ist, steht in Ausgehend begrenzen.

2. Was startet regelmäßig?#

# Cronjobs aller Benutzer
for u in $(cut -f1 -d: /etc/passwd); do
  crontab -l -u "$u" 2>/dev/null | grep -v '^#' | sed "s/^/$u: /"
done

ls -la /etc/cron.d/ /etc/cron.{hourly,daily,weekly,monthly}/
systemctl list-timers --all

Persistenz ist das erste Ziel nach einer Übernahme. Cronjobs und systemd-Timer sind der bequemste Weg dorthin.

3. Wer hat Zugang?#

# Schlüssel, die du nicht kennst
sudo find /home /root -name authorized_keys -exec sh -c \
  'echo "== $1"; cat "$1"' _ {} \;

# Konten mit Shell und UID 0
awk -F: '$3==0 || $7 ~ /sh$/ {print $1, $3, $7}' /etc/passwd

# Kürzlich geänderte Passwörter
sudo awk -F: '{print $1, $3}' /etc/shadow | head -20

Ein zweites Konto mit UID 0 ist kein Konfigurationsstil, sondern ein Befund.

Drei Stufen: Dienstkonto ohne sudo, eigenes Konto mit sudo und Passwort, root ohne direkten Login. Dazwischen die Wege der Rechteausweitung. — Jede NOPASSWD-Zeile in der sudoers-Datei verkürzt diese Kette auf einen Schritt.

Dazu passend die andere Hälfte der Frage, nicht nur, wer sich anmelden kann, sondern wie weit es von dort bis root ist:

# Wer darf per sudo was, und ohne Passwort?
sudo grep -rE 'NOPASSWD|ALL=\(ALL' /etc/sudoers /etc/sudoers.d/ 2>/dev/null

# Dateien mit gesetztem SUID-Bit außerhalb der üblichen Pfade
sudo find / -xdev -perm -4000 -type f -not -path '/usr/bin/*' -not -path '/usr/sbin/*' -ls 2>/dev/null

4. Veränderte Systemdateien#

sudo apt install -y debsums
sudo debsums -c 2>/dev/null

debsums -c vergleicht installierte Dateien mit den Prüfsummen der Pakete. Ausgaben zu Konfigurationsdateien sind normal; eine veränderte Datei unter /bin, /sbin oder /usr/bin ist es nicht.

5. Ungewöhnliche Prozesse und Dateien#

# Prozesse, deren Programmdatei gelöscht wurde — klassisches Muster
sudo ls -l /proc/*/exe 2>/dev/null | grep deleted

# Ausführbare Dateien an untypischen Orten
sudo find /tmp /var/tmp /dev/shm -type f -executable -ls 2>/dev/null

# Zuletzt geänderte Dateien in Systempfaden
sudo find /etc /usr/local/bin -type f -mtime -7 -ls 2>/dev/null | head -20

Ein laufender Prozess mit gelöschter Programmdatei ist selten harmlos.

6. Anmeldungen#

last -20                       # erfolgreiche Anmeldungen
sudo lastb -20                 # fehlgeschlagene
sudo journalctl -u ssh --since "7 days ago" | grep "Accepted"

Interessant sind nicht die vielen fehlgeschlagenen Versuche, die sind Grundrauschen. Interessant ist eine erfolgreiche Anmeldung, die du nicht warst.

Wenn etwas anschlägt#

Die Reihenfolge ist wichtig, und der erste Punkt fällt schwer:

Nicht sofort aufräumen. Wer die Schadsoftware löscht, vernichtet die Spur, über die man den Weg hinein findet und ohne den bleibt die Lücke offen.
Netz trennen, Maschine laufen lassen. Über die Konsole des Anbieters, nicht über SSH. Der Arbeitsspeicher enthält Informationen, die ein Neustart vernichtet.
Sichern: Snapshot der Maschine, Kopie der Protokolle auf ein anderes System.
Zugangsdaten als kompromittiert behandeln. Alle Schlüssel, alle Passwörter, alle API-Token, die auf der Maschine lagen.
Neu aufsetzen, nicht säubern. Bei einer Maschine mit unklarem Umfang der Übernahme ist Neuinstallation aus einem bekannten Zustand plus Daten aus dem Backup der einzige Weg, dem man trauen kann.

Backups prüfen, bevor man sie einspielt

Wenn unklar ist, seit wann die Maschine übernommen war, kann das Backup die Hintertür enthalten. Vor dem Zurückspielen datieren: Wann traten die ersten auffälligen Einträge auf? Das Backup davor ist der Kandidat. Wie ein belastbares Backup aussieht, steht auf der Schwesterseite unter Backup-Strategie 3-2-1.

Automatisch statt monatlich#

Der Prüfdurchlauf oben ist Handarbeit. Zwei Dinge lohnen sich zu automatisieren:

Dateiintegrität mit AIDE, legt eine Referenzdatenbank an und meldet Abweichungen:

sudo apt install -y aide
sudo aideinit                                   # dauert, einmalig
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
sudo aide --check | head -40

Die Referenzdatenbank gehört auf ein anderes System, sonst passt ein Angreifer sie einfach mit an.

Auffällige Ereignisse in den Alarmweg. Welche das sind und wie man sie so einstellt, dass sie nicht ignoriert werden, steht in Protokolle, die den Angreifer überleben.

Was nicht hilft#

Virenscanner auf Linux-Servern finden Windows-Schadsoftware in Dateiablagen. Gegen eine ausgenutzte Anwendungslücke helfen sie nicht.
„Der Server ist doch unwichtig.“ Ein übernommener Server wird für Spam, Portscans und als Zwischenstation genutzt. Der Wert der eigenen Daten ist dafür ohne Bedeutung.
Panische Vollprüfungen ohne Referenzwerte. Ohne zu wissen, wie die Maschine im Normalzustand aussieht, ist jede Ausgabe verdächtig und keine belastbar.