Ransomware: TeslaCrypt 4.0

[jahlives]

ich habe bei mir in der Regel genau einen Folder r/w gemountet und der wird auch versioniert gesichtert. Die anderen werden vom Betriebssystem automatisch lesend gemountet und wenn ich die schreibend brauche dann hänge ich die bei Bedarf ein und gebe dafür halt mein Passwort von Hand ein. Aber als Linuxer bist du es eh gewohnt, oft was erst nach Passwort Eingabe zu tun.

und wenn die Malware genügend intelligent ist selber nach Freigaben zu suchen? Wenn dein User Schreibrechte darauf hat (und das muss er ja wenn du die Freigabe schreibend einbinden können willst), kann die Malware trotzdem schreibend auf die Freigabe zugreifen. Dazu muss sie nicht unbedingt eingebunden sein. Nur der mount wird eine Passwort Abfrage auslösen, wobei auch nicht zwangsläufig: sobald dein lokaler User und der SMB User identisch sind geht das ohne PW Abfrage. Und wenn dein mount.cifs das suid Bit gesetzt hat, was es muss wenn man automatisch beim Booten als User eine Freigabe einbinden will (z.B. via fstab), dann braucht man noch nichtmal sudo dazu. Der direkte Zugriff via UNC Pfad braucht auch kein sudo

Oder die Malware Entwickler gehen einen Schritt weiter und greifen über andere Protokolle auf die Daten zu? Z.B. via scp oder sftp?
Du hast richtig gesagt, dass nur möglichst restriktive Filesystemrechte davor schützen können, aber das heisst, dass damit nicht die Rechte auf eine Freigabe gemeint sind sondern die effektiven Userrechte im Dateisystem des Servers. Und genau da wird es extrem unkomfortabel mit dieser zusätzlichen Sicherheit
Nur die Rechte direkt im Dateisystem des Servers können dich vor Übergriffen über alle Protokolle schützen. Die neusten Versionen von Tesla zeigen sehr anschaulich wie die Entwickler gelernt haben: so werden keine speziellen Dateiendungen mehr verwendet, was den Schutz durch fail2ban totschiesst. Heutige Malware ist sehr modular aufgebaut und das ermöglicht es den Ganoven die Verbreitungswege recht einfach anpassen zu können.

Das vielgehörte Mantra: Backup, Backups und nochmals Backups hat leider seine Gültigkeit. Dazu kommen möglichst restriktive Filesystemrechte, sowohl auf dem Client als auch auf dem Server. Und zum Schluss ein aktiviertes SeLinux bzw Apparmor, welches im Modus enforce läuft. Denn dies ist die einzige Barriere, welche einer Malware z.B. den Zugriff auf deinen private Key verbieten kann und somit einen allfälligen Zugriff via ssh (scp oder sftp) abwürgen kann

 

[Iarn]

und wenn die Malware genügend intelligent ist selber nach Freigaben zu suchen? Wenn dein User Schreibrechte darauf hat (und das muss er ja wenn du die Freigabe schreibend einbinden können willst), kann die Malware trotzdem schreibend auf die Freigabe zugreifen. Dazu muss sie nicht unbedingt eingebunden sein. Nur der mount wird eine Passwort Abfrage auslösen, wobei auch nicht zwangsläufig: sobald dein lokaler User und der SMB User identisch sind geht das ohne PW Abfrage. Und wenn dein mount.cifs das suid Bit gesetzt hat, was es muss wenn man automatisch beim Booten als User eine Freigabe einbinden will (z.B. via fstab), dann braucht man noch nichtmal sudo dazu. Der direkte Zugriff via UNC Pfad braucht auch kein sudo

Ich gebe in der Regel die Freigaben meiner NASen im Netzwerk per NFS lesend frei. Diese Freigaben werden auch permanent per fstab gemounted. Wenn ich was schreibend brauche dann muss ich mich mit dem Adminstratoruser der NAS manuell verbinden (SMB oder FTP). Das Passwort auf der NAS entspricht nicht dem lokalen User Passwort.
Ansonsten hat jede meiner NASen einen Transfer Folder in dem jeder schreiben darf. Die Daten von dort müssen noch sortiert werden aber ganz ehrlich da ist selten was drin, dem ich nachtrauern würde. In der Regel ungeschnittene Filme aus der Satbox.
Meinen Dokumente Ordner synchronisiere ich versioniert auf die NAS. Sollte sich hier ein Crypto Schädling eingeschlichen habe, kann ich die File Versionen zurück rollen.

Soweit zu dem Thema wie ich mit Hilfe von OS und Rechten Risiken minimiere. Ich denke jeder sollte sich sein eigenes Konzept machen und ja ein solches Konzept sollte auch Backups beinhalten. Nur sind Backups meiner Ansicht nach ein Puzzelstein und nicht die universell glücklich machende Lösung. Zudem auch hier wie bei allem die größte Fehlerquelle auf OSI Level 8 liegt.

 

[phuture303]

Ich hab mal eine DAU-semi-OT-Frage zu diesen Verschlüsselungstrojanern: Wenn sich ein Windows-Laptop, das über eine Fritzbox über das Gast-WLAN ins Netz geht, so ein Teil einfängt –*sind die anderen Geräte im Netzwerk sicher? Der Gästezugang ist doch innerhalb der Fritzbox abgeschottet – oder doch für den Trojaner "durchlässig"?