jahlives
Benutzer
- Mitglied seit
- 19. Aug 2008
- Beiträge
- 18.275
- Punkte für Reaktionen
- 4
- Punkte
- 0
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 sudoich 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.
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