Hallo zusammen,
aktuell geistert ja mal wieder ein Schadprogramm Namens Locky durch die Windowswelt.
Natürlich fragt man sich, ob man unter Linux wohl auch betroffen sein könnte. Bisher wurde mir dies an anderen Stellen bejaht, wenn es denn Locky für Linux gäbe.
Nun würde ich gern mein System gegen solche Tools ein wenig härten.
Ich habe unter Fedora schon etwas Erfahrung mit SELinux gesammelt, davon wurde mir aber bisher unter Debian abgeraten, da es angeblich schlechter integriert wäre als z.B. AppArmor.
Gilt das noch?
Nun zum eigentlichen Thema, meine Idee ist es neuen Executables oder allen die nicht dem Repository entstammen die Schreibrechte auf sämtliche Datenträger, mit Ausnahme von tmpfs u.ä. zu verweigern, bis diese mit einer neuen Regel dafür freigeschaltet werden.
Ist dies mit "Standardtool" wie SELinux und AppArmor überhaupt in diesem Umfang möglich? Gibt es Fallstricke die ich nicht bedacht habe?
LG, Frank
Locky, SELInux, AppArmor und die Schreibrechte
-
cosinus
- Beiträge: 3439
- Registriert: 08.02.2016 13:44:11
- Lizenz eigener Beiträge: GNU General Public License
- Wohnort: Bremen
Re: Locky, SELInux, AppArmor und die Schreibrechte
moin
Direkt ne Linux-Version gibt es wohl nicht, aber es gibt ne Variante, die sich auf Webserver stürzt => http://heise.de/-3116470
Und damit ist ja Linxu indirekt betroffen, denn die meisten Webserver nutzen als OS ja nunmal Linux.
Um die Ausführung von Schrott zu verhindern, kann man viele Dateisysteme über die /etc/fstab als noexec einbinden. Macht aber nur richtig Sinn, wenn man /, /var, /tmp usw. alle auf eigene logical volumes (oder meinetwegen auch Partitionen) verteilt und nicht alles auf die root partition geknallt hat
/tmp kannst du als tmpfs (also ramdisk) in der fstab deklarieren und als noexec deklarieren. Gerne auch zusätzlich nosuid und nodev. Beim einspielen von Updates bzw. Installieren von Paketen musst du dann aber etwas beachten, lies mal dazu noch => https://www.debian-administration.org/a ... executable
Wenn du willst kann ich dirmal als Beispiel "meine" fstab posten
Direkt ne Linux-Version gibt es wohl nicht, aber es gibt ne Variante, die sich auf Webserver stürzt => http://heise.de/-3116470
Und damit ist ja Linxu indirekt betroffen, denn die meisten Webserver nutzen als OS ja nunmal Linux.
Um die Ausführung von Schrott zu verhindern, kann man viele Dateisysteme über die /etc/fstab als noexec einbinden. Macht aber nur richtig Sinn, wenn man /, /var, /tmp usw. alle auf eigene logical volumes (oder meinetwegen auch Partitionen) verteilt und nicht alles auf die root partition geknallt hat
/tmp kannst du als tmpfs (also ramdisk) in der fstab deklarieren und als noexec deklarieren. Gerne auch zusätzlich nosuid und nodev. Beim einspielen von Updates bzw. Installieren von Paketen musst du dann aber etwas beachten, lies mal dazu noch => https://www.debian-administration.org/a ... executable
Wenn du willst kann ich dirmal als Beispiel "meine" fstab posten
-
breakthewall
- Beiträge: 507
- Registriert: 30.12.2016 23:48:51
Re: Locky, SELInux, AppArmor und die Schreibrechte
Hallo
Der letzte überaus nützliche Beitrag ist zwar eine Weile her, doch ich glaube ich kann hier noch Sinnvolles hinzufügen.
Zum einen wie bereits angegeben, ist die Aufteilung des Dateisystems überaus nutzbringend, zumal sich hier für jeden spezifischen Bereich individuelle Sicherheits-Kontexe definieren lassen.
Damit wird nicht nur eine Härtung erreicht, sondern auch mehr Flexibilität. Denn dadurch werden ebenfalls Backup-Konzepte effektiver, und durch Separierung der Bereiche, sichert man sich zusätzlich gegen Probleme ab die das System als Ganzes beeinflussen würden. Ein gutes Beispiel hier wäre /var/log, was bei Überlauf auf einem eigenen Volume, niemals das System negativ in Beschlag nehmen kann.
Es ist zwar korrekt das mittels SELinux und AppArmor mehr Sicherheit generiert werden kann. Doch beide Konzepte sind aus meiner Sicht nicht empfehlenswert. Denn einerseits ist SELinux höllisch komplex, ebenso die Konfigurationen, und das ist weder für die Übersicht zuträglich, noch mindert das gravierende Konfigurationsfehler. Dagegen wäre AppArmor eine Art SELinux-Light im weitestens Sinne, was zwar einfach nutzbar ist, aber sicherheitstechnisch sehr zurück bleibt. Eine Sicherheit die maßgeblich auf Pfadnamen basiert ist ungenügend, und die Vergangenheit zeigte bereits, wie AppArmor gezielt angegriffen werden konnte. Ein weiterer Nachteil der beiden Konzepten anhaftet ist, dass beide nur LSM-Kernel-Module sind. Das heißt das die Sicherheit beider Konzepte aufgehoben ist, sobald ein geeigneter Kernel-Exploit existiert.
Nicht dass das nun sonderlich oft eintritt, jedoch zeigt es auf das diese Optionen klare Grenzen haben. Eine deutlich bessere Option wäre auf GrSecurity zu setzen, was als Kernel-Patchset den Linux-Kernel selbst deutlich besser härtet, um diesen weniger empfänglich für etliche Klassen an Fehlern zu machen. Statistiken der Vergangenheit zeigten ebenso auf, dass ein mit GrSecurity gehärteter Linux-Kernel, gegen eine Vielzahl von Problemen immun gewesen ist.
Nur hat das auch einen entsprechenden Preis. Und auch wenn GrSecurity über einen automatischen Lernmodus verfügt, so ist das System bei Installation eines solchen Linux-Kernels erst einmal kaputt, und nach und nach müssen die Programme, insbesondere Bestandteile des Desktops entsprechend einer Whitelist hinzugefügt werden. Hat man dies alles erledigt mithilfe der nützlichen PaX-Tools, kann man sich an einem erheblich sichereren System erfreuen. Sicherheit wird immer mit Arbeit verbunden sein.
Dennoch gibt es nichts was man einfach einrichtet, und ab hier die völlige Sicherheit generiert. Weshalb es wichtig ist mehrere Sicherheits-Schichten zu etablieren. Eine dieser Schichten kann sogar aus einer Browser-Erweiterung wie einem Adblocker, oder erweiterten Optionen wie uMatrix/NoScript bestehen. Alles davon hilft um die Messlatte höher zu setzen, und einen Angriff egal welcher Art weniger rentabel/wahrscheinlich zu machen. Natürlich ist der Browser bekanntermaßen ein Haupteinfallstor, weshab dieser niemals ungesichert laufen sollte.
Diesbezüglich gibt es ein auf Linux-Kernel basierenden Technologien basierendes Programm namens Firejail, was selbst für blanke Anfänger überaus einfach zu nutzen ist, bei zeitgleich hohem Gewinn. Und da der Linux-Kernel hier die Optionen stellt, ist das natürlich besonders komfortabel integriert, wodurch Programme wie z.B. der Browser, wie zuvor genutzt werden können ohne das der Nutzer überhaupt merkt das dieser in einer Sandbox läuft. Solche Lösungen sind Gold wert, und helfen besonders unerfahrenen Nutzern ohne dabei lästig zu sein. Nützlich ist auch die Möglichkeit Firejail als Shell zu definieren, wodurch schädliche Eingaben im Terminal erheblich weniger anrichten können, oder gänzlich wirkungslos bleiben. Eine Steigerung dessen wäre die konsequente Nutzung von VMs, was selbstredend recht performante Hardware erfordert, wenn es in der VM an nichts mangeln soll.
Alles in allem ist man mit diesen Möglichkeiten ziemlich gut bedient. Und sofern man nur Pakete aus dem Repository lädt, und wenig fahrlässig handelt, wird das außerordentlich schwierig mit Krypto-Trojanern unter Linux. Zu bemängeln wäre eher, dass Viele kaum Gebrauch davon machen, und nicht selten noch das Betriebssystem als unsicher abstempeln.
Der letzte überaus nützliche Beitrag ist zwar eine Weile her, doch ich glaube ich kann hier noch Sinnvolles hinzufügen.
Zum einen wie bereits angegeben, ist die Aufteilung des Dateisystems überaus nutzbringend, zumal sich hier für jeden spezifischen Bereich individuelle Sicherheits-Kontexe definieren lassen.
Damit wird nicht nur eine Härtung erreicht, sondern auch mehr Flexibilität. Denn dadurch werden ebenfalls Backup-Konzepte effektiver, und durch Separierung der Bereiche, sichert man sich zusätzlich gegen Probleme ab die das System als Ganzes beeinflussen würden. Ein gutes Beispiel hier wäre /var/log, was bei Überlauf auf einem eigenen Volume, niemals das System negativ in Beschlag nehmen kann.
Es ist zwar korrekt das mittels SELinux und AppArmor mehr Sicherheit generiert werden kann. Doch beide Konzepte sind aus meiner Sicht nicht empfehlenswert. Denn einerseits ist SELinux höllisch komplex, ebenso die Konfigurationen, und das ist weder für die Übersicht zuträglich, noch mindert das gravierende Konfigurationsfehler. Dagegen wäre AppArmor eine Art SELinux-Light im weitestens Sinne, was zwar einfach nutzbar ist, aber sicherheitstechnisch sehr zurück bleibt. Eine Sicherheit die maßgeblich auf Pfadnamen basiert ist ungenügend, und die Vergangenheit zeigte bereits, wie AppArmor gezielt angegriffen werden konnte. Ein weiterer Nachteil der beiden Konzepten anhaftet ist, dass beide nur LSM-Kernel-Module sind. Das heißt das die Sicherheit beider Konzepte aufgehoben ist, sobald ein geeigneter Kernel-Exploit existiert.
Nicht dass das nun sonderlich oft eintritt, jedoch zeigt es auf das diese Optionen klare Grenzen haben. Eine deutlich bessere Option wäre auf GrSecurity zu setzen, was als Kernel-Patchset den Linux-Kernel selbst deutlich besser härtet, um diesen weniger empfänglich für etliche Klassen an Fehlern zu machen. Statistiken der Vergangenheit zeigten ebenso auf, dass ein mit GrSecurity gehärteter Linux-Kernel, gegen eine Vielzahl von Problemen immun gewesen ist.
Nur hat das auch einen entsprechenden Preis. Und auch wenn GrSecurity über einen automatischen Lernmodus verfügt, so ist das System bei Installation eines solchen Linux-Kernels erst einmal kaputt, und nach und nach müssen die Programme, insbesondere Bestandteile des Desktops entsprechend einer Whitelist hinzugefügt werden. Hat man dies alles erledigt mithilfe der nützlichen PaX-Tools, kann man sich an einem erheblich sichereren System erfreuen. Sicherheit wird immer mit Arbeit verbunden sein.
Dennoch gibt es nichts was man einfach einrichtet, und ab hier die völlige Sicherheit generiert. Weshalb es wichtig ist mehrere Sicherheits-Schichten zu etablieren. Eine dieser Schichten kann sogar aus einer Browser-Erweiterung wie einem Adblocker, oder erweiterten Optionen wie uMatrix/NoScript bestehen. Alles davon hilft um die Messlatte höher zu setzen, und einen Angriff egal welcher Art weniger rentabel/wahrscheinlich zu machen. Natürlich ist der Browser bekanntermaßen ein Haupteinfallstor, weshab dieser niemals ungesichert laufen sollte.
Diesbezüglich gibt es ein auf Linux-Kernel basierenden Technologien basierendes Programm namens Firejail, was selbst für blanke Anfänger überaus einfach zu nutzen ist, bei zeitgleich hohem Gewinn. Und da der Linux-Kernel hier die Optionen stellt, ist das natürlich besonders komfortabel integriert, wodurch Programme wie z.B. der Browser, wie zuvor genutzt werden können ohne das der Nutzer überhaupt merkt das dieser in einer Sandbox läuft. Solche Lösungen sind Gold wert, und helfen besonders unerfahrenen Nutzern ohne dabei lästig zu sein. Nützlich ist auch die Möglichkeit Firejail als Shell zu definieren, wodurch schädliche Eingaben im Terminal erheblich weniger anrichten können, oder gänzlich wirkungslos bleiben. Eine Steigerung dessen wäre die konsequente Nutzung von VMs, was selbstredend recht performante Hardware erfordert, wenn es in der VM an nichts mangeln soll.
Alles in allem ist man mit diesen Möglichkeiten ziemlich gut bedient. Und sofern man nur Pakete aus dem Repository lädt, und wenig fahrlässig handelt, wird das außerordentlich schwierig mit Krypto-Trojanern unter Linux. Zu bemängeln wäre eher, dass Viele kaum Gebrauch davon machen, und nicht selten noch das Betriebssystem als unsicher abstempeln.