1. Die nötigen Werkzeuge stehen also bereit. Was hindert Sie daran, eine solche Liste bereitzustellen?
Das muss in der Debian Infrastruktur umgesetzt werden, da man auch die vielen Patch- und Updatepakete berücksichtigen muss.
Also sollte es Teil des Buildprozesses sein und auch Teil des "Dateien müssen immer gleiche Binaries erzeugen" Projekts (im Kommentar einer der älteren Newsbeiträge habe ich das angesprochen) sein.
3. Aufwandsvermeidung der Neuinstallation. Und ab und zu wenigstens mal prüfen können, was wirklich los ist. Zum die Neuinstallation ja keinerlei Sicherheit bietet. Schon 3 min später könnte das System wieder kompromitiert sein, wenn der Schadcode auch im Netzwerkdrucker hockt und neue Systeme gleich befällt. Mit den Prüfsummen könnte man so etwas aber zumindest bemerken.
Ein Angreifer benötigt für die Installation eines Rootkits Social-Engineering oder eine bestehende Sicherheitslücke, die einer Eskalation zu root-Rechten mit hinreichend schwachen MAC-Einschränkungen oder vergleichbaren Administratorenrechten genügt.
Keine Ahnung wofür MAC stehen soll, aber der Rest ist richtig.
Ja, es ist immer wieder dumm, wenn man Abürkzungen einführt, ohne sie vorher wenigstens einmal auszuschreiben.
Oder meinen sie jetzt MAC Adressen?
um die Installation des Rootkits hinreichend zu verschleiern, sodass Punkte 1 und 2 und alle anderen Maßnahmen einer Entdeckung ebenfalls quasi nutzlos werden.
Solange er sein rootkit nicht bspw. im Flashrom der TV Karte hinterlegt, wird sein rootkit anhand der Hahs aufgespürt werden können. Zumindest wird man definiert sagen können, wo das rootkit schon einmal nicht versteckt sein kann und welche Dateien nicht manipuliert wurden.
Den übrig verbleibenden Rest guckt man sich dann gründlich an und trifft dann Entscheidungen wie man sie immer bei solchen Sicherheitsthemen trifft.
Falls das Rootkit jedoch die Firmware befällt, hilft nur noch der Ersatz der befallenen Hardware/Chips (und die Neuinstallation). Alles andere wäre Quacksalberei und Schlangenöl.
Richtig, aber was ist bisher anders?
Schmeißen sie ihr System in vorauseilender Maßnahme nach alle 3 Monate weg, wenn sie auch die Neuinstallation durchführen? Und kaufen sie dann auch sichere Hardware nach, die nicht schon ab Händler manipuliert wurde?
Das muss in der Debian Infrastruktur umgesetzt werden, da man auch die vielen Patch- und Updatepakete berücksichtigen muss.
Die Liste können Sie wie oben erwähnt jederzeit erneut erstellen, d.h. also für jeden Patch und jedes Update aktualisieren.
Daher erschließt sich mir Ihre Begründung für eine Umsetzung innerhalb der Debian-Infrastruktur nicht. "Nice to have" wäre es allemal. Also Ärmel hochkrempeln und loslegen!
Also sollte es Teil des Buildprozesses sein und auch Teil des "Dateien müssen immer gleiche Binaries erzeugen" Projekts (im Kommentar einer der älteren Newsbeiträge habe ich das angesprochen) sein.
Warum genau ist das nötig, wenn es auch nach der Generierung der Pakete geht?
Meiner Meinung nach sollte man während der Erzeugung der Pakete nur die dafür nötigen Aufgaben erledigen. Alles andere sollte man separat erledigen, falls möglich, was hier ja der Fall ist. Das nennt man, glaube ich, KISS oder gute Ingenieursarbeit oder so.
--
3. Aufwandsvermeidung der Neuinstallation. Und ab und zu wenigstens mal prüfen können, was wirklich los ist.
Genau das tut man mit den vorgeschlagenen Maßnahmen mittels einer "Whitelist" an Prüfsummen eben nicht, denn man weiß nach einer Durchführung eben nicht, "was wirklich los ist", falls dabei nichts entdeckt wurde. Das Risiko falsch-negativer Ergebnisse ist zu groß.
Zu[de]m die Neuinstallation ja keinerlei Sicherheit bietet.
Sie bietet jedenfalls mehr Sicherheit als keine Konsequenzen aus dem nicht unwahrscheinlichen Fall eines falsch-negativen Ergebnisses einer Whitelist-Überprüfung, wie sie hier vorgeschlagen worden ist, zu ziehen.
Schon 3 min später könnte das System wieder kompromitiert sein, wenn der Schadcode auch im Netzwerkdrucker hockt und neue Systeme gleich befällt.
Das selbe kann nach einer erfolgreichen Desinfektion in Folge einer Prüfsummenüberprüfung geschehen. Es handelt sich um ein klassisches Strohmann-Argument.
Mit den Prüfsummen könnte man so etwas aber zumindest bemerken.
Die Betonung liegt auf könnte. Es gibt keine Garantie. Das Risiko falsch-negativer Ergebnisse einer Infektionsüberprüfung anhand von Prüfsummen ist signifikant. Ganz unabhängig vom Aufwand einer solchen Überprüfung.
--
Keine Ahnung wofür MAC stehen soll, aber der Rest ist richtig.
Ja, es ist immer wieder dumm, wenn man Abürkzungen einführt, ohne sie vorher wenigstens einmal auszuschreiben.
Oder meinen sie jetzt MAC Adressen?
Nein, ich meinte mit der Abkürzung MAC Mandatory Access Control. Unter Linux wird das z.B. von SELinux (Red Hat), AppArmor (Novell, SUSE, Canonical), TOMOYO oder SMACK implementiert, und erweitert und verfeinert das traditionelle DAC (Discretionary Access Control).
--
Solange er sein rootkit nicht bspw. im Flashrom der TV Karte hinterlegt, wird sein rootkit anhand der Hahs aufgespürt werden können. Zumindest wird man definiert sagen können, wo das rootkit schon einmal nicht versteckt sein kann und welche Dateien nicht manipuliert wurden.
Im Falle eines Kernel-Rootkits (gängige Variante) müsste man dafür aber vor jedem Neustart die Prüfsummen des initramfs zum späteren Abgleich auf einem nicht kompromittiertem System erstellen und sichern, denn das initramfs ist in der Regel spezifisch für die Hardware- und Softwarekonfiguration und editier-/aktualisierbar. Also wie gedenken Sie, diese Maßnahme ohne großen Aufwand umzusetzen?
Außerdem könnte ein Kernel-Rootkit bei seiner Verschleierung schlau genug sein, und das kompromittierte initramfs platzieren bevor die Prüfsummen erstellt werden, oder es möglichst bald nach dem Start mit dem nicht-kompromittierten initramfs ersetzen. Die genauen Details sind für das Argument unerheblich, wenn der Angreifer hinreichend einschätzen kann, wann und wie die Prüfsummen erstellt und überprüft werden. Es kommt nur auf das richtige Timing an. Will man sich für die eigene Sicherheit auf die Inkompetenz des Angreifers verlassen?
Den übrig verbleibenden Rest guckt man sich dann gründlich an und trifft dann Entscheidungen wie man sie immer bei solchen Sicherheitsthemen trifft.
Ich sagte ja bereits: großer manueller Aufwand.
--
Falls das Rootkit jedoch die Firmware befällt, hilft nur noch der Ersatz der befallenen Hardware/Chips (und die Neuinstallation). Alles andere wäre Quacksalberei und Schlangenöl.
Schmeißen sie ihr System in vorauseilender Maßnahme nach alle 3 Monate weg, wenn sie auch die Neuinstallation durchführen?
Nein, ich nutze Verstand und Vernunft, und beuge vor so gut ich kann, gehe Indizien gewissenhaft nach, und schätze meine Attraktivität als Angriffsziel einer solchen Attacke so gering ein, sodass zu vermuten ist, dass das Risiko, Opfer einer solchen Attacke zu werden, verschwindend ist.
Außerdem handelt es sich hier um ein Strohmann-Argument. Ich habe nie behauptet, dass man Hardware vorbeugend und ohne Verdachtsmoment in regelmäßigen Abständen ersetzen sollte.
Und kaufen sie dann auch sichere Hardware nach, die nicht schon ab Händler manipuliert wurde?
Falls ich in die Situation kommen sollte, mich dazu gezwungen zu sehen, Hardware wegen einer Infizierung der Firmware zu ersetzen, werde ich mein Bestmögliches tun, diese nicht mit ab Werk manipulierter Hardware zu ersetzen. Allerdings bin ich mir bewusst, dass meine Möglichkeiten hier stark begrenzt sind. Es ist ein Spiel um Wissen, Macht und Einfluss, dass ich nicht gewinnen kann. Aber ich werde hingehen und kämpfen.
Das muss in der Debian Infrastruktur umgesetzt werden, da man auch die vielen Patch- und Updatepakete berücksichtigen muss.
Also sollte es Teil des Buildprozesses sein und auch Teil des "Dateien müssen immer gleiche Binaries erzeugen" Projekts (im Kommentar einer der älteren Newsbeiträge habe ich das angesprochen) sein.
3.
Keine Ahnung wofür MAC stehen soll, aber der Rest ist richtig.Aufwandsvermeidung der Neuinstallation.
Und ab und zu wenigstens mal prüfen können, was wirklich los ist.
Zum die Neuinstallation ja keinerlei Sicherheit bietet.
Schon 3 min später könnte das System wieder kompromitiert sein, wenn der Schadcode auch im Netzwerkdrucker hockt und neue Systeme gleich befällt.
Mit den Prüfsummen könnte man so etwas aber zumindest bemerken.
Ja, es ist immer wieder dumm, wenn man Abürkzungen einführt, ohne sie vorher wenigstens einmal auszuschreiben.
Oder meinen sie jetzt MAC Adressen?
Solange er sein rootkit nicht bspw. im Flashrom der TV Karte hinterlegt, wird sein rootkit anhand der Hahs aufgespürt werden können.Zumindest wird man definiert sagen können, wo das rootkit schon einmal nicht versteckt sein kann und welche Dateien nicht manipuliert wurden.
Den übrig verbleibenden Rest guckt man sich dann gründlich an und trifft dann Entscheidungen wie man sie immer bei solchen Sicherheitsthemen trifft.
Richtig, aber was ist bisher anders?Schmeißen sie ihr System in vorauseilender Maßnahme nach alle 3 Monate weg, wenn sie auch die Neuinstallation durchführen?
Und kaufen sie dann auch sichere Hardware nach, die nicht schon ab Händler manipuliert wurde?
Daher erschließt sich mir Ihre Begründung für eine Umsetzung innerhalb der Debian-Infrastruktur nicht.
Warum genau ist das nötig, wenn es auch nach der Generierung der Pakete geht?"Nice to have" wäre es allemal. Also Ärmel hochkrempeln und loslegen!
Meiner Meinung nach sollte man während der Erzeugung der Pakete nur die dafür nötigen Aufgaben erledigen. Alles andere sollte man separat erledigen, falls möglich, was hier ja der Fall ist. Das nennt man, glaube ich, KISS oder gute Ingenieursarbeit oder so.
--
Genau das tut man mit den vorgeschlagenen Maßnahmen mittels einer "Whitelist" an Prüfsummen eben nicht, denn man weiß nach einer Durchführung eben nicht, "was wirklich los ist", falls dabei nichts entdeckt wurde. Das Risiko falsch-negativer Ergebnisse ist zu groß.Sie bietet jedenfalls mehr Sicherheit als keine Konsequenzen aus dem nicht unwahrscheinlichen Fall eines falsch-negativen Ergebnisses einer Whitelist-Überprüfung, wie sie hier vorgeschlagen worden ist, zu ziehen.Das selbe kann nach einer erfolgreichen Desinfektion in Folge einer Prüfsummenüberprüfung geschehen.Es handelt sich um ein klassisches Strohmann-Argument.Die Betonung liegt auf könnte. Es gibt keine Garantie. Das Risiko falsch-negativer Ergebnisse einer Infektionsüberprüfung anhand von Prüfsummen ist signifikant. Ganz unabhängig vom Aufwand einer solchen Überprüfung.
--
Nein, ich meinte mit der Abkürzung MAC Mandatory Access Control. Unter Linux wird das z.B. von SELinux (Red Hat), AppArmor (Novell, SUSE, Canonical), TOMOYO oder SMACK implementiert, und erweitert und verfeinert das traditionelle DAC (Discretionary Access Control).--
Im Falle eines Kernel-Rootkits (gängige Variante) müsste man dafür aber vor jedem Neustart die Prüfsummen des initramfs zum späteren Abgleich auf einem nicht kompromittiertem System erstellen und sichern, denn das initramfs ist in der Regel spezifisch für die Hardware- und Softwarekonfiguration und editier-/aktualisierbar.Also wie gedenken Sie, diese Maßnahme ohne großen Aufwand umzusetzen?
Außerdem könnte ein Kernel-Rootkit bei seiner Verschleierung schlau genug sein, und das kompromittierte initramfs platzieren bevor die Prüfsummen erstellt werden, oder es möglichst bald nach dem Start mit dem nicht-kompromittierten initramfs ersetzen.
Ich sagte ja bereits: großer manueller Aufwand.Die genauen Details sind für das Argument unerheblich, wenn der Angreifer hinreichend einschätzen kann, wann und wie die Prüfsummen erstellt und überprüft werden. Es kommt nur auf das richtige Timing an.
Will man sich für die eigene Sicherheit auf die Inkompetenz des Angreifers verlassen?
--
Nein, ich nutze Verstand und Vernunft, und beuge vor so gut ich kann, gehe Indizien gewissenhaft nach, und schätze meine Attraktivität als Angriffsziel einer solchen Attacke so gering ein, sodass zu vermuten ist, dass das Risiko, Opfer einer solchen Attacke zu werden, verschwindend ist.Außerdem handelt es sich hier um ein Strohmann-Argument. Ich habe nie behauptet, dass man Hardware vorbeugend und ohne Verdachtsmoment in regelmäßigen Abständen ersetzen sollte.
Falls ich in die Situation kommen sollte, mich dazu gezwungen zu sehen, Hardware wegen einer Infizierung der Firmware zu ersetzen, werde ich mein Bestmögliches tun, diese nicht mit ab Werk manipulierter Hardware zu ersetzen.Allerdings bin ich mir bewusst, dass meine Möglichkeiten hier stark begrenzt sind. Es ist ein Spiel um Wissen, Macht und Einfluss, dass ich nicht gewinnen kann. Aber ich werde hingehen und kämpfen.