Vorbeugende Maßnahmen gegen Verschlüsselungstrojaner

[Holzohrwascherl]

Ich überdenke gerade meine Backupstrategie. Dabei beschäftigt mich die Möglichkeit, mir eine Verschlüsselungsschadsoftware einzufangen.

Ich habe ein Netzwerk von 6 Rechnern:

• Notebook mit Windows 10
• QNAP-NAS mit QTS 4.x
• Linuxrechner, der als Backupserver dient, Ubuntu 20.04
• iPad
• Smartphones

Angriffsszenario:

• Aus Unachtsamkeit führe ich auf dem Notebook ein Programm aus, das einen Verschlüsselungstrojaner installiert.
• Der Trojaner beginnt, lokal und in allen freigegebenen Netzwerk-Laufwerken Dateien transparent zu verschlüsseln.

Frage: Was konkret muss ich tun, um herauszufinden, ob bereits Dateien verschlüsselt sind? Einfach auf dem Notebook beliebig Dateien zu laden (Videos und Audiodateien abspielen, Worddateien öffnen etc.) bringt ja wenig, denn solange der Schlüssel nicht gelöscht wurde, ist die Verschlüsselung ja transparent.

Mir schwebt Folgendes vor: Notebook mit einem sauberen Windows oder Linux mit Samba-Client starten und beliebige Dateien laden. Jetzt müssten verschlüsselte Dateien als solche feststellbar sein. Grund: Das OS auf dem USB-Stick ist ja nicht kompromittiert.
Sehe ich das richtig oder ist die Verschlüsselung für alle Rechner, die auf die Samba-Freigabe zugreifen, transparent, d.h. nicht ohne Weiteres feststellbar?

 

[chr1zZo]

1. Ein Offline Backup, was du z.B. immer an einem Tag in einem gewissen Zeitraum backupen lässt, und dann wieder trennst! Daher im Worstcase, max. 1 Woche Datenverlust.
2. Eine Hardware Firewall, die so einen Trojaner schon blockt, bevor er auf deine Endgeräte kommt?
3. Verschlüsselungstrojaner für iOS sind mir derzeit nicht wirklich bekannt. Solange du immer alles aktuell hälst, sollten die Geräte so gut wie nicht betroffen sein.

 

[madmax2010]

Der Trojaner beginnt, lokal und in allen freigegebenen Netzwerk-Laufwerken Dateien transparent zu verschlüsseln.

Dagegen kannst du dich schuetzen, indem du dein backup Ziel nicht schreibbar mountest. S3 targets und $irgendwas ueber SSH und dann Versionierte backups helfen.
Gescheite Backup tools mit denen das geht sind restic und borgbackup

Restic hat auch tools dabei um die Konsitenz deines backups zu verifizieren: https://restic.readthedocs.io/en/la...repos.html#checking-integrity-and-consistency

Frage: Was konkret muss ich tun, um herauszufinden, ob bereits Dateien verschlüsselt sind? Einfach auf dem Notebook beliebig Dateien zu laden (Videos und Audiodateien abspielen, Worddateien öffnen etc.) bringt ja wenig, denn solange der Schlüssel nicht gelöscht wurde, ist die Verschlüsselung ja transparent.

Wenn die checksummen umkippen, wurden die dateien veraendert.

 

[Weedlord]

Frage: Was konkret muss ich tun, um herauszufinden, ob bereits Dateien verschlüsselt sind?

Du erkennst sie daran das die Dateiendung anders ist und/oder du sie nicht mehr einfach öffnen kannst.

Wie du deine Backups schützen kannst? Deine Backup Platten dürfen nicht aktive mit dem Rechner seihs direkt oder übers Netzwerk verbunden sein.

Ich habe meine 4 TB HDD z. B. in so einem externen Laufwerksrahmen den ich immer deaktiviere wenn ich mein Backup erstellt, bzw. aktualisiert habe.

https://smile.amazon.de/gp/product/B078P3DTX1/ref=ppx_yo_dt_b_asin_title_o05_s00?ie=UTF8&psc=1

 

[Picard87]

Doch, sobald sowas verschlüsselt wurde, kannst du nicht mehr drauf zugreifen, d.h. merkst du das ziemlich schnell. Von einem USB-Stick booten ist natürlich eine gute Diagnosemöglichkeit, aber der Schaden ist schnell ersichtlich, v.a. weil dann ja oft eine Meldung kommt, wo "Lösegeld" gefordert wird.
Wirklich etwas tun im Sinne von absoluter Sicherheit kannst du nicht, leider. Am Besten hilft Hirn einschalten, alles aktuell halten und regelmäßig (!) Backups machen, die nicht physisch mit dem Netzwerk/ PCs verbunden bleiben.

 

[Baxxter]

entfernt

Und am besten nichts von Tauschbörsen und Co. runterladen.
Legal fährt man (oft) sicherer.

 

[foo_1337]

Die einzig vernünftige Lösung hier ist die von madmax vorgeschlagene s3 Variante. Diese kann man komplett automatisieren und muss nicht mit irgendwelchen USB Sticks rumhantieren. Angst und schlaflose Nächte im Fall der Fälle braucht man dann keine zu haben.

 

[Holzohrwascherl]

Du erkennst sie daran das die Dateiendung anders ist und/oder du sie nicht mehr einfach öffnen kannst.

Wirklich? Ist das so einfach? Auch bei transparenter Verschlüsselung?

Wie du deine Backups schützen kannst?

Ist mir klar. Backup mit Versionsverwaltung.

Deine Backup Platten dürfen nicht aktive mit dem Rechner seihs direkt oder übers Netzwerk verbunden sein.

Mache ich.

 

[Weedlord]

Wirklich? Ist das so einfach? Auch bei transparenter Verschlüsselung?

Naja, Verschlüsselung heißt doch das die Dateien nicht mehr einfach ohne Schlüssel auslesbar sind. Transparent gibt es da nicht.

 

[Holzohrwascherl]

Dagegen kannst du dich schuetzen, indem du dein backup Ziel nicht schreibbar mountest.

Das Backup-Ziel liegt auf dem Backuprechner. Nur dieser hat Zugriff auf das Backup. Er holt sich die Daten vom NAS. Weder dieses noch ein anderes Gerät hat Zugriff auf das Backup.

S3 targets und $irgendwas ueber SSH und dann Versionierte backups helfen.

Kannst du bitte erklären, was du mit S3 target meinst?

Gescheite Backup tools mit denen das geht sind restic und borgbackup

Setze borgbackup ein, Versionsverwaltung kein Problem …

Restic hat auch tools dabei um die Konsitenz deines backups zu verifizieren: https://restic.readthedocs.io/en/la...repos.html#checking-integrity-and-consistency


Wenn die checksummen umkippen, wurden die dateien veraendert.

Danke für des Tipp.

Ergänzung (1. Januar 2022)

S3-Target ist mir klar …

 

[Konfekt]

Mal eine Verständnisfrage: Wenn eine Datei verschlüsselt wird, entsteht dabei rein von der Logik her eine neue Datei, oder wird die bestehende rein inhaltsbezogen überschrieben? Ich meine mich an Crypto-Trojaner zu erinnern, die man austricksen konnte, indem man die Ursprungsdateien wiederhergestellt hat, da sie einfach nur gelöscht worden waren.

 

[foo_1337]

Kommt darauf an, wie es implementiert wird, es ist im Prinzip beides möglich. Bei Dateisystemen mit Journaling ist jedoch ein exaktes Überschreiben nicht garantiert möglich.

 

[fgordon]

Bei Kuh Dateisystem (COW = Copy on Write) ist es sogar grundsätzlich immer so dass Dateien nie überschrieben werden.

Bei mir laufen die Server mit FreeBSD/ZFS und ich mache immer Snapshots (dauert ja nur 0,1 Sekunden)

ZFS-Snapshots enthalten immer alle Daten und sind immer Read-Only vom Filesystem Design her - also natürlich auch read-only für den root Nutzer - es gibt keine Möglichkeit die veränderbar zu mounten.

Das ersetzt natürlich kein Backup aber es macht ein Verschlüsselungstrojaner, der eher wohl auf meinem Windows Desktop wüten würde doch deutlich schwerer - der müsste ja das root pwd des Servers hacken und die Snapshots löschen.

Mit der "neuen" Crypt Funktion von Open-ZFS hat man zusätzlich ein "dynamisches verschlüsseltes Verzeichnis" das also immer nur so viel Platz einnimmt wie Daten drin sind und der restliche Platz steht dann dem unverschlüsselten Bereich zur Verfügung - das ist echt praktisch im Vergleich zu Crypt mit festen Größen.

 

[andy_m4]

ZFS-Snapshots enthalten immer alle Daten und sind immer Read-Only vom Filesystem Design her - also natürlich auch read-only für den root Nutzer

Ändern kannst Du die Daten zwar nicht so wirklich, aber der Angreifer könnte die Snapshots natürlich einfach löschen (oder direkt aufs Blockdevice schreiben, sofern Du nicht in nem Security-Level >=2 bist). Von daher ist ein "nicht mal root kann die Daten ändern" nur ein schwacher Trost. :-)
Insofern sollte man dafür sorgen, das das System selbst nicht infiziert wird bzw. wenn es dann kein "Durchbruch" zu root und Co. gibt.

Für Dein Szenario ist das aber ohnehin kein wirkliches Problem. So wie ich es verstanden hab, hast Du einen FreeBSD-Server auf dem die Datei liegen und auf die wird per NFS, SMB oder wasauchimmer von den eigentlichen Client-PCs her zugegriffen. Und es geht sozusagen um den Fall, das diese Clients ein Ransomware-Befall haben. Und dann kann bei den Snapshots ja auch nix "anbrennen" :-)

 

[fgordon]

Und der Server hat auch ein Backupsystem das 99% der Zeit aus ist und die Daten und eigene Snapshots hat.

Genau ich habe die Daten auf einem Server - der auch keinen SSH/Telnet etc Zugang hat. Dafür nutze ich PiKVM und logge mich sozusagen "direkt" ein. Einfach weil ich das bequem finde, dass das per Browser geht - und das einfach ein echt cooles Projekt ist xD

Meine ja nur ReadOnly Snapshots auf einem Server, der das unterstützt sind halt eine weitere recht grosse Hürde für so einen Trojaner, selbst wenn man die eigentliche Freigabe auf dem Desktop lesend / schreibend hat.

 

[andy_m4]

dass das per Browser geht

Wobei Zugang per Browser ja jetzt nicht weniger schlimm ist als Zugang per SSH. Im Gegenteil. Denn der Browser wird ja für den Internetzugriff eingesetzt und ist daher auch gleichzeitig recht exponiert.
Und KVM ist noch mal kritischer, weil Du dann Eingriffe ins System machen kannst, die normal nicht möglich sind.

 

[fgordon]

Naja aber der Browser zeigt ja nur das Monitorbild - dann muss man sich ja trotzdem noch ganz normal einloggen.

Zuerst in den KVM und dann noch zusätzlich ganz normal mit dem Login in den Server, denke das ist schon ok. Ich halte das für mindestens so sicher wie einen ssh Zugang zum Server.

Der Videostream des PiKVM ist nur lokal - wenn der Angreifer nicht tatsächlich meinen PC Bildschirm (bzw Browserinhalt zum KVM) sieht UND zusätzlich einen Keylogger bei mir hat wird es sicher schwer.

Ich denke wer sich so eine extreme Mühe macht, kommt eher dann bei mir daheim mit einem langen Messer vorbei xD