Albtraum Ransomware

[TErxleben]

Moin,
ich prüfe auf Ransomware mittels dryrun von rsync den Inhalt von Dateiservern. Sobald eine definierte Schwelle überschritten wird, gibt es eine Mitteilung und sicherheitshalber keine Sicherung mehr. Funktioniert trotz manchen Fehlalarms recht gut. Bei entsprechender Meldung muss man eben gegenprüfen, woher der Alarm kam und vielleicht gewollt war. Welche Kiste Schuld war, ist aber leider nicht zu ermitteln.
Darum möchte ich dieses einfache Prinzip auch gerne in den Sicherungsvorgang der leidigen MS-VMs integrieren.
Am besten also eine Regelkette im Sicherungsvorgang, der einfach nur eine auffällige Änderungsrate erkennt und ungewöhnliche Veränderungen meldet. Es geht also nicht darum, mittels schwindeligem Snakeoil eine potentielle Infektion zu erkennen, sondern selbige bei erster Aktivität zu erkennen, um Problembär-VMs einfach zurückzusetzen.
Wie macht ihr das?

 

[Johannes S]

Mehrere Punkte:

• Mit ProxmoxVE hat das nicht wirklich zu tun
• Statt per rsync bietet es sich an explizit für diesen Zweck entwickelte Tools zu nutzen: https://www.my-it-brain.de/wordpres...dvanced-intrusion-detection-environment-aide/
  
  Die Idee ist dass man eine Datenbank mit den ist-zustand aller Dateien hat (Hashes) und das Tool regelmäßig dagegen prüft. Dafür muss natürlich a) die Datenbank selbst außerhalb des Hosts read-only abgelegt werden) und b) (gerade bei Dateiservern) regelmäßig aktualisiert.
• Für Windows habe ich mal gegooglet und folgendes bei Reddit gefunden: https://www.reddit.com/r/sysadmin/comments/1blyp9/audit_and_aidelike_tool_for_a_windows_machine/
  Demnach kann man wohl ein Monitoring ohne Alerting mit den Shadow-Copys von Windows machen, aber da werden auch ein paar Tools genannt
• Wäre es nicht noch besser solche Veränderungen vornerein zu unterbinden? Windows bietet mehrere Mechanismen, die genau das ermöglichen, Stephan Kathak und Christoph Schneegans haben dazu einiges geschrieben (und leider auch zum Microslop-ähnlichen Gefrickel, was man machen muss, damit es wirklich funktioniert):
  • https://skanthak.hier-im-netz.de/appcert.html
  • https://skanthak.hier-im-netz.de/applocker.html
  • https://skanthak.hier-im-netz.de/SAFER.html
  • https://schneegans.de/windows/safer/
  • https://schneegans.de/windows/wdac-policy-generator/
• Um diese Windows-Mechanismen für praktische Zwecke nutzbar zu machen, hat die IT der Uni Rostock was ziemlich cooles gebaut, leider scheinen die das nur für ihre eigenen Windows-Admins zur Verfügung zu stellen, aber vielleicht hilft ja eine nette Email?
  • Auf Basis von WDAC: https://www.itmz.uni-rostock.de/anw...-whitelisting-der-bessere-schutz-vor-malware/
  • Auf Basis von Applocker: https://www.itmz.uni-rostock.de/anw...egeln-von-windows-systemen-mittels-applocker/
• Der Witz daran ist, dass Ransomware unmöglich gemacht wird, weil nur explizit freigegebene Executables auch ausgeführt werden können, die Kehrseite ist, dass viele Software (auch von M$ selbst) damit nicht zurecht kommt, bis man passende Ausnahmen definiert hat.
• Wie man das dann überwacht? Vermutlich auch über das Eventlog, wie man daraus Alerts o.ä. baut wird man dir in einen Windows-Forum beantworten können.

Disclaimer: Ich nutze weder aide noch Windows-Application-Whitelisting produktiv, da ich im Homelab bisher zu faul war und auf der Arbeit ich nicht dazu komme und die Verantwortlichen andere Ansätze (aka Antiviren/Endpoint-Protection/XDR-Enterprise-Schlangenöl) präferieren. Der Tag hat eben leider nur 24 Stunden

Auf einen Windows-Testsystem habe ich aber mal mit WDAC/Code integrity rumgespielt, das hat grundsätzlich wie erwartet funktioniert, da liefen aber keine produktiven Workloads drauf.

 

[Falk R.]

Moin,
ich prüfe auf Ransomware mittels dryrun von rsync den Inhalt von Dateiservern. Sobald eine definierte Schwelle überschritten wird, gibt es eine Mitteilung und sicherheitshalber keine Sicherung mehr. Funktioniert trotz manchen Fehlalarms recht gut. Bei entsprechender Meldung muss man eben gegenprüfen, woher der Alarm kam und vielleicht gewollt war. Welche Kiste Schuld war, ist aber leider nicht zu ermitteln.
Darum möchte ich dieses einfache Prinzip auch gerne in den Sicherungsvorgang der leidigen MS-VMs integrieren.
Am besten also eine Regelkette im Sicherungsvorgang, der einfach nur eine auffällige Änderungsrate erkennt und ungewöhnliche Veränderungen meldet. Es geht also nicht darum, mittels schwindeligem Snakeoil eine potentielle Infektion zu erkennen, sondern selbige bei erster Aktivität zu erkennen, um Problembär-VMs einfach zurückzusetzen.
Wie macht ihr das?

Gar nicht, da der PBS alle neuen Blöcke auch als neue wegschreibt, bleiben die alten Backups ja heile.
Das Monitoring sollte aber schon anspringen wenn zu viele Dateien geändert werden.

 

[bl1mp]

Ransomeware sorgt auch immer dafür, das die Deduprate in den Keller droppt. Das dürfte eine gute Metrik sein.

BG, Lucas

 

[Bu66as]

Was @Falk R. sagt: PBS schreibt deduplizierte Chunks, die alten Backups bleiben intakt. Das ist schon mal die halbe Miete.
Und @bl1mp hat recht, die Dedup-Rate ist genau die Metrik die du willst. In den PBS-Task-Logs siehst du nach jedem Backup wieviel new data vs. deduplicated angefallen ist. Wenn eine VM plötzlich statt 2% neue Chunks 80% hat, brennt der Baum. Das lässt sich relativ easy per API abfragen und überwachen, z.B. proxmox-backup-client task log <upid> parsen oder direkt über die PBS-API die Task-Details ziehen. Da bastelst du dir nen Schwellwert drüber und fertig ist die Alarmierung.
Was ich zusätzlich empfehlen würd: Offsite-PBS per Sync-Job als Pull einrichten, nicht Push. Heißt: der Offsite-PBS holt sich die Backups aktiv, und die Credentials auf der Quellseite haben nur DatastoreBackup (kein Prune, kein Delete). Selbst wenn eine Ransomware den produktiven PBS kompromittiert, kann sie die Offsite-Kopie nicht anfassen. Dazu großzügige Retention auf dem Offsite-Ziel, dann hast du immer saubere Snapshots zum Zurückrollen.

 

[rprengel]

Moin,
ich prüfe auf Ransomware mittels dryrun von rsync den Inhalt von Dateiservern. Sobald eine definierte Schwelle überschritten wird, gibt es eine Mitteilung und sicherheitshalber keine Sicherung mehr. Funktioniert trotz manchen Fehlalarms recht gut. Bei entsprechender Meldung muss man eben gegenprüfen, woher der Alarm kam und vielleicht gewollt war. Welche Kiste Schuld war, ist aber leider nicht zu ermitteln.
Darum möchte ich dieses einfache Prinzip auch gerne in den Sicherungsvorgang der leidigen MS-VMs integrieren.
Am besten also eine Regelkette im Sicherungsvorgang, der einfach nur eine auffällige Änderungsrate erkennt und ungewöhnliche Veränderungen meldet. Es geht also nicht darum, mittels schwindeligem Snakeoil eine potentielle Infektion zu erkennen, sondern selbige bei erster Aktivität zu erkennen, um Problembär-VMs einfach zurückzusetzen.
Wie macht ihr das?

Hallo, wir prüfen hier Windows VMs auf ungewöhliche Datei-Aktivitäten (lesen/schreiben). Bei Auffälligkeiten fährt die VM automatisch runter. Alles weitere ist "Handarbeit" für die Admins anhand einer definierten Vorgehensweise und hängt von den jeweiligen Umständen ab. Alles was man da an Rekationen automatisiert kann komplett nach hinten los gehen.
Gruß

 

[Bu66as]

Guter Punkt, @rprengel. Anomalie-Erkennung auf Backup-Ebene (Dedup-Rate) und direkt in der VM (Datei-Aktivität) ergänzen sich gut. Beim automatischen Reagieren sollte man eher konservativ sein. VM runterfahren ist noch vertretbar, aber alles darüber hinaus (automatisch Snapshots zurückrollen, Netzwerk kappen etc.) kann im Fehlalarm-Fall richtig Spaß machen.