Dein Ansatz alles zu prüfen funktioniert nicht, denn du kannst /etc nicht prüfen, da diese Dateien durch den Nutzer verändert werden und /var kannst du nicht prüfen, da diese Dateien zur Laufzeit angelegt und verändert werden. Dein Rootkit muss sich also nur in den Systemstart (/etc) hängen und seine Scripte und Executables unter /var ablegen, um von dir nicht entdeckt zu werden.
Es geht auch nicht um /etc, sondern um Programmdateien wie top, lsof und Co, bzw, eigentlich alle, wenn man das schon macht. Die Executables sind binaries und kann man somit aufspüren. Außerdem soll das Programm auch wie der Process Explorer für Windows, laufende Processe mit den Hashs abgleichen.
Der Process Explorer tut das unter Windows bspw. mit der Hashdatenbank von virus total.
Bezüglich den Scripten und Konfigurationsdateien kann man sich alles anzeigen lassen, was verändert wurde. Vieles, was bei einer Distri nach /etc kommt, ist schon so wie es ist, ausreichend vorkonfiguriert und muss somit nicht umkonfiguriert werden, diese Dateien kann man also auch in die whitelist setzen.
Alles was übrig bleibt, unbekannte Prozesse, unbekannte Dateien einschließlich aller veränderter Configs und Programme die verändert wurden, die werden dann ausgegeben. Und dann kann man sich das noch einmal ganz genau ansehen.
Die händisch zu prüfende Datenmenge wird damit auf jeden Fall maßgeblich reduziert.
Und ganz wichtig. Man findet damit vor allem die manipulierten Binaries.
Ohne so eine Infrastruktur hast du praktisch keine Chance veränderte Programme aufzuspüren. Also gehen tut das schon, aber der manuelle Aufwand ist enorm.
Dank der Einführung von systemd ist es sogar wesentlich einfacher geworden. Weil die Anzahl an komplexen Scripte durch systemd deutlich kleiner wurde und systemd besteht aus einer Sammlung vieler kleiner Helferlein, die sich eben, abgesehen von Updates nicht verändern. Die kann man also gut hashen und vergleichen.
Meine Argumentation ist jedenfalls schlüssig, was ich sagte trifft zu. systemd Dateien sind statische Binaries die gut hashbar sind und die xml Konfigurationsdateien enthalten keinen ausführbaren Code. Die Skriptdateien sind dagegen recht veränderliche Dateien in denen jeder selbsternannte Admin rumpfuschen und den hash kaputt machen kann.
Bei Windows geht das mit der White List und den Hashs auch sehr gut. Da weiß man dank White List immer, welche svchost.exe von Microsoft ist und welche nicht.
Nunja, Sie kommentierten Ihre eigenen Kommentare und stießen ganz plötzlich auf das Thema systemd.
Es ist ein Faktum, dass dieses Thema kontrovers ist, und häufig zu hitzigen Diskussionen und Flamewars ausartet. Das gefundene Fressen eines jeden Trolls, oder nicht?
Außerdem (auf der inhaltlichen Seite) bildet bei systemd das Konzept der 'unit'-Dateien das Analogon zu den Initskripten unter SystemV. Diese lassen sich sehr wohl editieren. Dieses Verhalten ist sogar beabsichtigt.
Somit ist Ihr Argument zudem auch noch widerlegt. Tut mir wirklich Leid, wenn da alle meine Alarmglocken schrillen und die gut geeichten Trollmessgeräte ausschlagen.
Wer andere als Troll beleidigt ist ein Idiot.
Sätze wie dieser machen es nicht gerade besser und lassen meine Messgeräte nur weiter ausschlagen. Wenn Sie sich beleidigt fühlen, ist an meiner Bezichtigung vielleicht ein Funken Wahrheit gewesen.
Meine Argumentation ist jedenfalls schlüssig, was ich sagte trifft zu.
Nein, ist sie nicht. Die Widerlegung Ihres Arguments finden Sie oben.
systemd Dateien sind statische Binaries die gut hashbar sind und die xml Konfigurationsdateien enthalten keinen ausführbaren Code.
Falls Sie mit den "xml Konfigurationsdateien" die 'unit'-Dateien meinen, so muss ich Sie leider enttäuschen: Es handelt sich um ini-Dateien. siehe Punkt 17
systemd verwendet XML meines Wissens nur für die Handhabung von DBus und die Generierung beim Kompilieren der eigenen manpages. Ich könnte mich auch täuschen. Mein Einwand zählt in jedem Fall.
Außerdem hat die Änderbarkeit einer rein deklarativen Konfigurationsdatei nicht automatisch geringere Auswirkungen auf die Systemsicherheit als die einer Konfigurationsdatei, die ausführbaren Code enthält. Konkret betrifft das hier bspw. die Zeilen, die mit Exec= beginnen.
Die Skriptdateien sind dagegen recht veränderliche Dateien in denen jeder selbsternannte Admin rumpfuschen und den hash kaputt machen kann.
Wieso sollte das nicht auch auf die Konfigurationsdateien von systemd zutreffen?
Bei Windows geht das mit der White List und den Hashs auch sehr gut. Da weiß man dank White List immer, welche svchost.exe von Microsoft ist und welche nicht.
Kann gut sein. Wie/Wo kann man diese "Whitelist" abrufen?
Bei Windows geht das mit der White List und den Hashs auch sehr gut. Da weiß man dank White List immer, welche svchost.exe von Microsoft ist und welche nicht.
Kann gut sein. Wie/Wo kann man diese "Whitelist" abrufen?
virustotal hat die hashs. Der Process Explorer macht das abrufen und prüfen auf Wunsch automatisch.
Achso, und ich dachte, Sie meinten ein richtige Liste innerhalb der Microsoft-Infrastruktur.
zu Virustotal: Okay, das muss man also manuell je Datei ausführen und begrenzt sich auf (laufende?) Prozessdateien und deren geladene Bibliotheken, soweit ich das richtig verstanden habe.
Eine "Whitelist" ist das jedenfalls nicht. Sondern eine Datenbank, die über eine spezifizierte Schnittstelle nur beschränkt abfragbar ist.
Außerdem begrüßt da einen erstmal die Terms of Service und die Privacy Policy.
Danke für den Hinweis, aber ich halte von diesem Dienst nichts. Da nehme und traue ich lieber Microsofts MSRT und Windows Defender.
Ich kann dir nur dringend debsums und rkhunter empfehlen damit du einen Eindruck davon bekommst, was "die veränderten Dateien prüfe ich händisch" in der Praxis bedeutet.
Von den veränderten Dateien wirst du dann ganz schnell ebenfalls Prüfsummen anfertigen und durch getrennte Aufbewahrung vor Manipulationen schützen, um diese nicht jedesmal erneut manuell prüfen zu müssen. Aber Moment, jetzt hast du genau die Infrastruktur geschaffen mit welcher du das komplette System prüfen kannst, ohne einen Onlinedienst zu benötigen.
Die Dateien, die in /etc liegen und die ich selber verändert habe, die kann ich an einer Hand abzählen.
Zusätzlich eigene Prüfsummen anlegen kann man natürlich immer noch machen. Wichtig wäre aber erst einmal, die statischen Dateien auch nach der Installation noch prüfen zu können. In Windows ist das eine feine Sache, da geht das.
Aber Moment, jetzt hast du genau die Infrastruktur geschaffen mit welcher du das komplette System prüfen kannst, ohne einen Onlinedienst zu benötigen.
Das ist Blödsinn. rkhunter hält keine Prüfsummen und wenn die lokal gespeichert werden, dann können die manipuliert werden. debsums kann man selbst manipulieren, ist also auch keine Lösung.
* in /etc werden nicht nur Änderungen von dir vorgenommen * in /var liegen nahezu ausschließlich Änderungen welche nicht von dir vorgenommen wurden * MD5 Prüfsummen sind in den Debian-Paketen bereits enthalten, du musst sie nur nutzen * rkhunter legt Prüfsummen der installierten Dateien ab und erkennst so Veränderungen * debsums kann auch ein offline genommenes System prüfen
Du scheint entweder ahnungslos zu sein oder ein Troll.
* in /etc werden nicht nur Änderungen von dir vorgenommen
Und da ändert man bekanntlich auch nicht alles. Das bisschen, was man ändert, kann man manuell sichten. Siehe dazu die anderen Threads.
* MD5 Prüfsummen sind in den Debian-Paketen bereits enthalten, du musst sie nur nutzen
md5 Prüfsummen gewährleisten zwar mit ausreichender Gewissheit, dass die Datei fehlerfrei downgeladen wurden, sie gewährleisten aber nicht, dass sie verändert wurden. Dafür reicht md5 nicht mehr aus.
* rkhunter legt Prüfsummen der installierten Dateien ab und erkennst so Veränderungen
Das muss der User manuell machen.
Steve Jobs sagte mal zu seinem Apple Entwickler, als der es geschafft hatte, dass der Rechner in n Minuten bootet, dass er die Zeit um 20 Sekunden reduzieren soll, denn dann sind Millionen Nutzet dankbar, dass sie in der Summe keine Jahre fürs Booten verlieren. Das gilt hier auch.
Wenn Debian die SHA256 Prüfsummen anlegt und online als Teil des Buildsystems zur Verfüggung stellt, so dass man auf die hash aller unveränderten Dateien eines Debian Systems zugreifen kann, dann hat jeder etwas davon, der Debian nutzt. Und die Arbeit muss dann auch nicht Zuhause n-mal doppelt gemacht. Ökos werden jetzt dazu auch noch sicher anmerken, dass es ein paar Bäume rettet und den Klimawandel verhindert, aber so weit möchte ich jetzt nicht gehen.
* debsums kann auch ein offline genommenes System prüfen
Mit md5 hashs, die hier nicht genügen. Außerdem sind die offline hintelegten debsums nicht fälschungssicher hinterlegt.
Meine Lösung wird also weder durch rkhunter, noch durch debsums erfüllt.
Du scheint entweder ahnungslos zu sein oder ein Troll.
Ich kann nichts dafür, wenn du es nichts verstehst und glaubst, dass unsichere md5 Prüfsummen, die offline auf dem System drauf sind, sichere Quellen für Prüfsummen wären.
Dein Ansatz alles zu prüfen funktioniert nicht, denn du kannst /etc nicht prüfen, da diese Dateien durch den Nutzer verändert werden und /var kannst du nicht prüfen, da diese Dateien zur Laufzeit angelegt und verändert werden. Dein Rootkit muss sich also nur in den Systemstart (/etc) hängen und seine Scripte und Executables unter /var ablegen, um von dir nicht entdeckt zu werden.
Es geht auch nicht um /etc, sondern um Programmdateien wie top, lsof und Co, bzw, eigentlich alle, wenn man das schon macht.
Die Executables sind binaries und kann man somit aufspüren.
Außerdem soll das Programm auch wie der Process Explorer für Windows, laufende Processe mit den Hashs abgleichen.
Der Process Explorer tut das unter Windows bspw. mit der Hashdatenbank von virus total.
Bezüglich den Scripten und Konfigurationsdateien kann man sich alles anzeigen lassen, was verändert wurde.
Vieles, was bei einer Distri nach /etc kommt, ist schon so wie es ist, ausreichend vorkonfiguriert und muss somit nicht umkonfiguriert werden, diese Dateien kann man also auch in die whitelist setzen.
Alles was übrig bleibt, unbekannte Prozesse, unbekannte Dateien einschließlich aller veränderter Configs und Programme die verändert wurden, die werden dann ausgegeben.
Und dann kann man sich das noch einmal ganz genau ansehen.
Um es also kurz zu machen.
Der Ansatz funktioniert.
Die händisch zu prüfende Datenmenge wird damit auf jeden Fall maßgeblich reduziert.
Und ganz wichtig.
Man findet damit vor allem die manipulierten Binaries.
Ohne so eine Infrastruktur hast du praktisch keine Chance veränderte Programme aufzuspüren.
Also gehen tut das schon, aber der manuelle Aufwand ist enorm.
Ach noch etwas.
Dank der Einführung von systemd ist es sogar wesentlich einfacher geworden.
Weil die Anzahl an komplexen Scripte durch systemd deutlich kleiner wurde und systemd besteht aus einer Sammlung vieler kleiner Helferlein, die sich eben, abgesehen von Updates nicht verändern.
Die kann man also gut hashen und vergleichen.
Netter Köder, den Sie da ausgelegt haben. Ich hoffe, dass niemand anbeißen wird.
Und nun zurück in deine gestankerfüllte Höhle, Troll!
Wer andere als Troll beleidigt ist ein Idiot.
Meine Argumentation ist jedenfalls schlüssig, was ich sagte trifft zu. systemd Dateien sind statische Binaries die gut hashbar sind und die xml Konfigurationsdateien enthalten keinen ausführbaren Code.
Die Skriptdateien sind dagegen recht veränderliche Dateien in denen jeder selbsternannte Admin rumpfuschen und den hash kaputt machen kann.
Bei Windows geht das mit der White List und den Hashs auch sehr gut.
Da weiß man dank White List immer, welche svchost.exe von Microsoft ist und welche nicht.
Nunja, Sie kommentierten Ihre eigenen Kommentare und stießen ganz plötzlich auf das Thema systemd.
Es ist ein Faktum, dass dieses Thema kontrovers ist, und häufig zu hitzigen Diskussionen und Flamewars ausartet. Das gefundene Fressen eines jeden Trolls, oder nicht?
Außerdem (auf der inhaltlichen Seite) bildet bei systemd das Konzept der 'unit'-Dateien das Analogon zu den Initskripten unter SystemV. Diese lassen sich sehr wohl editieren. Dieses Verhalten ist sogar beabsichtigt.
Somit ist Ihr Argument zudem auch noch widerlegt.
Sätze wie dieser machen es nicht gerade besser und lassen meine Messgeräte nur weiter ausschlagen. Wenn Sie sich beleidigt fühlen, ist an meiner Bezichtigung vielleicht ein Funken Wahrheit gewesen.Nein, ist sie nicht. Die Widerlegung Ihres Arguments finden Sie oben.Falls Sie mit den "xml Konfigurationsdateien" die 'unit'-Dateien meinen, so muss ich Sie leider enttäuschen: Es handelt sich um ini-Dateien. siehe Punkt 17Tut mir wirklich Leid, wenn da alle meine Alarmglocken schrillen und die gut geeichten Trollmessgeräte ausschlagen.
systemd verwendet XML meines Wissens nur für die Handhabung von DBus und die Generierung beim Kompilieren der eigenen manpages. Ich könnte mich auch täuschen.
Mein Einwand zählt in jedem Fall.
Außerdem hat die Änderbarkeit einer rein deklarativen Konfigurationsdatei nicht automatisch geringere Auswirkungen auf die Systemsicherheit als die einer Konfigurationsdatei, die ausführbaren Code enthält.
Wieso sollte das nicht auch auf die Konfigurationsdateien von systemd zutreffen?Kann gut sein. Wie/Wo kann man diese "Whitelist" abrufen?Konkret betrifft das hier bspw. die Zeilen, die mit
Exec=beginnen.virustotal hat die hashs.
Der Process Explorer macht das abrufen und prüfen auf Wunsch automatisch.
Achso, und ich dachte, Sie meinten ein richtige Liste innerhalb der Microsoft-Infrastruktur.
zu Virustotal:
Okay, das muss man also manuell je Datei ausführen und begrenzt sich auf (laufende?) Prozessdateien und deren geladene Bibliotheken, soweit ich das richtig verstanden habe.
Eine "Whitelist" ist das jedenfalls nicht. Sondern eine Datenbank, die über eine spezifizierte Schnittstelle nur beschränkt abfragbar ist.
Außerdem begrüßt da einen erstmal die Terms of Service und die Privacy Policy.
Danke für den Hinweis, aber ich halte von diesem Dienst nichts.
Da nehme und traue ich lieber Microsofts MSRT und Windows Defender.
Mit anderen Worten, man kann somit /var und /etc prüfen.
Verändertes wird ausgespruckt und kann nochmal ganz genau angesehen werden.
Ich kann dir nur dringend debsums und rkhunter empfehlen damit du einen Eindruck davon bekommst, was "die veränderten Dateien prüfe ich händisch" in der Praxis bedeutet.
Von den veränderten Dateien wirst du dann ganz schnell ebenfalls Prüfsummen anfertigen und durch getrennte Aufbewahrung vor Manipulationen schützen, um diese nicht jedesmal erneut manuell prüfen zu müssen. Aber Moment, jetzt hast du genau die Infrastruktur geschaffen mit welcher du das komplette System prüfen kannst, ohne einen Onlinedienst zu benötigen.
Die Dateien, die in /etc liegen und die ich selber verändert habe, die kann ich an einer Hand abzählen.
Zusätzlich eigene Prüfsummen anlegen kann man natürlich immer noch machen.
Das ist Blödsinn.Wichtig wäre aber erst einmal, die statischen Dateien auch nach der Installation noch prüfen zu können.
In Windows ist das eine feine Sache, da geht das.
rkhunter hält keine Prüfsummen und wenn die lokal gespeichert werden, dann können die manipuliert werden.
debsums kann man selbst manipulieren, ist also auch keine Lösung.
* in /etc werden nicht nur Änderungen von dir vorgenommen
* in /var liegen nahezu ausschließlich Änderungen welche nicht von dir vorgenommen wurden
* MD5 Prüfsummen sind in den Debian-Paketen bereits enthalten, du musst sie nur nutzen
* rkhunter legt Prüfsummen der installierten Dateien ab und erkennst so Veränderungen
* debsums kann auch ein offline genommenes System prüfen
Du scheint entweder ahnungslos zu sein oder ein Troll.
Siehe dazu die anderen Threads.md5 Prüfsummen gewährleisten zwar mit ausreichender Gewissheit, dass die Datei fehlerfrei downgeladen wurden, sie gewährleisten aber nicht, dass sie verändert wurden.
Dafür reicht md5 nicht mehr aus.Das muss der User manuell machen.
Steve Jobs sagte mal zu seinem Apple Entwickler, als der es geschafft hatte, dass der Rechner in n Minuten bootet, dass er die Zeit um 20 Sekunden reduzieren soll, denn dann sind Millionen Nutzet dankbar, dass sie in der Summe keine Jahre fürs Booten verlieren.
Das gilt hier auch.
Wenn Debian die SHA256 Prüfsummen anlegt und online als Teil des Buildsystems zur Verfüggung stellt, so dass man auf die hash aller unveränderten Dateien eines Debian Systems zugreifen kann, dann hat jeder etwas davon, der Debian nutzt.
Mit md5 hashs, die hier nicht genügen.Und die Arbeit muss dann auch nicht Zuhause n-mal doppelt gemacht.
Ökos werden jetzt dazu auch noch sicher anmerken, dass es ein paar Bäume rettet und den Klimawandel verhindert, aber so weit möchte ich jetzt nicht gehen.
Außerdem sind die offline hintelegten debsums nicht fälschungssicher hinterlegt.
Meine Lösung wird also weder durch rkhunter, noch durch debsums erfüllt.
Ich kann nichts dafür, wenn du es nichts verstehst und glaubst, dass unsichere md5 Prüfsummen, die offline auf dem System drauf sind, sichere Quellen für Prüfsummen wären.Gib uns Bescheid, wenn du einen funktionsfähigen Proof of Concept erarbeitet hast. Dabei kannst du nur an der nötigen Erfahrung gewinnen.