Ich brauch doch nur ne Dateiliste und die wird dann benutzt um die Hashs mit der online Dateiliste und deren Hashs zu prüfen.
Ein Dienst müste also alle Dateien mit Verzeichnisnamen und den dazu gehörigen Hash inkl. aller Versionen bereithalten. Dann könnte man nach die einzelnen Dateien abfragen und die beiden Hashs vergleichen.
Wenn ein Hash falsch ist, wurde er manipuliert. Wenn die Hash stimmt, aber eine ältere Datei ist, dann wurde nur das Paket nicht upgedated. Wenn eine Datei nicht gefunden wurde, die aber auf dem System ist, dann wurde was dazugefügt.
Dann müsstest du aber regelmäßig dein System offline nehmen und deine Festplatten über eine vertrauenswürdige Umgebung (Live-System) untersuchen. Willst du das wirklich machen? Warum? Scheint mir etwas aufwändig zu sein, zumal das Hashen *aller* Dateien doch etwas dauern kann -> Downtime.
Damit ich mich nicht in falscher Sicherheit wiege.
Scheint mir etwas aufwändig zu sein, zumal das Hashen *aller* Dateien doch etwas dauern kann -> Downtime.
Ich habe hier keinen Server, sondern einen oder mehrere Desktoprechner bei denen ich das gerne in regelmäßigen Abständen so machen würde. Da spielt die "Downtime" eine untergeordnete Rolle.
Aber selbst wenn man das am offenen Herzen machen will, so ist das mit Einschränkungen auch möglich.
Denn nicht jede Schadsoftware ist gegen alle Aufspürmethoden gewappnet. Manche verstecken sich vor bestimmten Prozessen wie bspw. top und htop oder Antirootkitsoftware oder es werden diese direkt auf dem System verändert, manche gehen tiefer und verändern den Kernel, aber manche kann man auch mit anderen Programmen aufspüren, die diese nicht auf dem Radar haben.
Unter Windows gab es mal ein Freeware Programm, hijackthis und der process explorer waren es nicht, den Namen habe ich vergessen. Dieses konnte zum Aufspüren von solchen laufenden Schadsoftwareprozessen eingesetzt werden. Es zeigte dabei alle laufenden Prozessen an. Aber da es Schadsoftware gibt, die sich vor solchen Tools versuchen zu verbergen, versuchte es sich durch obfuscation Techniken selbst vor der Schadsoftware zu verstecken.
Das Programm hatte bspw. immer einen anderen recht kryptischen Namen und hieß als laufender Prozess immer anders. Eine Schadsoftware, die sich nur vor bestimmten Prozessen verstecken konnte, konnte sich vor diesem nicht so einfach verstecken und somit aufgespürt werden.
Das gleiche wäre auch für Linux möglich und als Open Source Software sogar noch besser. Da man den Quellcode ändern kann und das Binary immer etwas anders aussehen lassen könnte.
Dieses könnte man dann an einem laufenden System starten und das führt dann den Hashdownload und die Vergleiche durch.
Damit würde man auf jeden Fall Veränderungen von wichtigen Systemprogramme, wie bspw. lsof, top und Co, erkennen.
Der Process Explorer von Sysinternals für Windows macht bezüglich der laufenden Prozesse ähnliches. Er kann sich zwar nicht per Obfuscatormethode verstecken, aber man kann alle laufenden Prozesse mit den Hashs von Virustotal in einem Rutsch vergleichen und somit verdächtigen Prozesse oder Programme, deren EXE manipuliert wurde, schnell erkennen.
So etwas plus den Vergleich aller von der Distribution kommenenden Binaries hätte ich auch gerne für Debian. Machbar wäre es auf jeden Fall, es Bedarf auf Seiten Debian aber gewisser Infrastruktur. Also ein Serverdienst, der die Hashs aller Distributionisspezifuschen Dateien, wie es virustotal auch für bekannte Windows Programme bietet, bereit hält.
Damit ich mich nicht in falscher Sicherheit wiege.
1. Man kann den Ausgaben eines kompromittierten Systems nicht trauen. Damit ist eine verlässliche Entdeckung "am offenen Herzen" nicht möglich.
Sie würden sich in Sicherheit wiegen, aus einer Nichtentdeckung "am offenen Herzen" keine weiteren Konsequenzen zu ziehen.
2. Selbst aus einem nicht kompromittierten System heraus ist die erfolgreiche Entdeckung eines Rootkits oder anderer Malware beliebig kompliziert bis unmöglich, da ein Angreifer in der Regel, aber spätestens mit der erfolgreichen Installation von Malware, die nötigen Rechte besitzt, dies hinreichend zu verschleiern - insbesondere bei Angriffen auf die Firmware selbst (siehe z.B. hier, da oder dort).
3. Sicherheit ist ein Prozess. In jedem Fall muss das Bedrohungsmodell klar formuliert und gerechtfertigt sein.
Der Aufwand möglicher Gegenmaßnahmen steht dem Risiko und potentiellen Konsequenzen einer Infizierung gegenüber und muss abgewogen werden. Der Aufwand ist theoretisch oft so groß, dass alle gängigen Entdeckungsmaßnahmen wie Schlangenöl wirken.
Vorbeugende Maßnahmen und Vorkehrungen für zügige Neuinstallationen samt Wiederherstellung des gewünschten Konfigurationszustands sind in der Regel das Mittel der Wahl.
1. Warum schreibst du so doof, es steht doch bereits da, dass man das auf dem Live System macht. Warum muss ich dir das noch einmal sagen? Nur für den, der jetzt unbedingt das auf dem Laufsystem machen muss, das eh nie booten will und das er links liegen lassen würde, wenn es das nicht geben würde, ist die andere Möglichkeit da und da wurde bereits gesagt, was die Einschränkungen sind.
Damit ist eine verlässliche Entdeckung "am offenen Herzen" nicht möglich.
Er will ja nichts machen, also gar nichts prüfen, ist dass dann die bessere Alternative? Das kannst du dir selber beantworten.
da ein Angreifer in der Regel, aber spätestens mit der erfolgreichen Installation von Malware, die nötigen Rechte besitzt, dies hinreichend zu verschleiern
Deswegen bootet man das unbelastete System und vergleicht ALLE Dateien mit den hashs und dann wird man auch fündig. Die Alternative dazu ist NIEMALS zu wissen, was auf dem System los ist. Diesen Zustand hat dein jetztiges System gerade.
Was du dann noch machen kannst ist regelmäßig das System neu zu installieren. Ich halte das für keine gute Lösung, da die viel zu arbeitsaufwendig ist.
insbesondere bei Angriffen auf die Firmware selbst
Wenn die Hardware kaputt ist, dann kannst du den Rechner eh wegschmeißen. Dann bringt auch eine Neuinstallation nichts. Auch hier könnte dein jetztiges System genau diesen Zustand haben. Überprüfen kannst du es jetzt ja nicht.
3. Sicherheit ist ein Prozess. In jedem Fall muss das Bedrohungsmodell klar formuliert und gerechtfertigt sein.
Eben und zu dem Prozess gehört auch ab und zu das System abzusuchen.
Warum schreibst du so doof, es steht doch bereits da, dass man das auf dem Live System macht. Warum muss ich dir das noch einmal sagen?
...weil genau das Gegenteil als mögliche Herangehensweise beschrieben wurde:
Aber selbst wenn man das am offenen Herzen machen will, so ist das mit Einschränkungen auch möglich. [...]
Nur für den, der jetzt unbedingt das auf dem Laufsystem machen muss, das eh nie booten will und das er links liegen lassen würde, wenn es das nicht geben würde, ist die andere Möglichkeit da und da wurde bereits gesagt, was die Einschränkungen sind.
Ich verstehe nur Bahnhof. a) Was ist ein Laufsystem? b) Woher entstammt die Annahme, dass es nicht startet, bzw. warum ist diese hier relevant? c) Wer ist "er"? d) Was würde es nicht geben? "die andere Möglichkeit"? e) Ist "die andere Möglichkeit" die erwähnte Überprüfung im laufenden Betrieb? f) Wo wurde bereits genau gesagt, was die Einschränkungen sind? Ich lese in obigem Kommentar nur Rechtfertigungen für eine Überprüfung "am offenen Herzen", die im Wesentlichen von der Annahme ausgehen, dass die allermeiste Malware zu große Mängel hätte, die das Verwischen ihrer eigenen Spuren betrifft.
--
Er will ja nichts machen, also gar nichts prüfen, ist dass dann die bessere Alternative?
Sprechen Sie hier von sich selbst in der dritten Person? Wer ist "Er"? Gibt es hier zwei verschiedene Individuen, die das Pseudonym Ghul verwenden?
Zum Inhalt: "Er" will sehr wohl prüfen, weil "Er" schrieb:
Willst du das wirklich machen? Warum?
Damit ich mich nicht in falscher Sicherheit wiege.
und
Ich habe hier keinen Server, sondern einen oder mehrere Desktoprechner bei denen ich das gerne in regelmäßigen Abständen so machen würde.
Die eigentliche Frage lautet, was der effektive Nutzen jener Maßnahmen im Verhältnis zum Aufwand wäre.
--
Das kannst du dir selber beantworten.
Ach, kann ich das? Oder wollen Sie mir einfach nur weismachen, dass ich gefälligst meine Klappe halten soll?
--
Deswegen bootet man das unbelastete System und vergleicht ALLE Dateien mit den hashs und dann wird man auch fündig.
Was bedeutet "ALLE Dateien" in diesem Kontext präzise? Was ist denn mit Dateien, die von Administratoren, Upgrades, Diensten und Nutzern absichtlich editierbar sind? Wie und zu welchem Zeitpunkt erstellt man von diesen Dateien einen Hash, von dem sicher sein kann, dass er nicht kompromittiert ist?
Bspw. betrifft das Dateien in /etc unter Debian - übrigens die einzige Verbindung zum Artikel. Das sind nicht nur einfache Key-Value-Konfigurationsdateien (/etc/passwd, /etc/shadow und /etc/sudo.conf wären auch ein paar heiße Kandidaten.), sondern dort gibt es sogar so einige Dateien (z.B. Shellkripte), die Code als root in unterschiedlichen Fällen und Regelmäßigkeiten ausführen. Wie geht man also - unter Vermeidung eines riesigen Aufwandes - damit um? Falls Sie diese Frage nicht zufriedenstellend beantworten können, sind die vorgeschlagenen Maßnahmen quasi nichts wert. Genau darum ging es mir in meiner Kritik.
Die Alternative dazu ist NIEMALS zu wissen, was auf dem System los ist. Diesen Zustand hat dein jetztiges System gerade.
Nein, die Alternative ist, präzise Bedrohungsmodelle zu beschreiben und sauberen und sinnvollen Sicherheitsprozesse strikt zu folgen, um Infizierungen vorzubeugen. Falls man das erste Indiz (z.B. üblich nach Auswertungen von Firewall-Logs; automatisiert oder nicht) einer Infizierung vorliegt, so hilft nur noch die Neuinstallation.
Ggf. kann man dieses Indiz vor einer Neuinstallation mittels geeigneter Maßnahmen erhärten. Da diese Maßnahmen ihre eigenen Probleme (hohes Risiko einer falsch-negativen Bewertung des Infektionszustands) haben, lautet die einzig korrekte Konsequenz dieser Überprüfung jedoch - unabhänging von ihrem Ausgang - Neuinstallation (und/oder sogar Austausch der Hardware). Eine solche Überprüfung dient also lediglich der Selbstbestätigung einer Vorahnung der Infizierung, mehr nicht.
Was du dann noch machen kannst ist regelmäßig das System neu zu installieren. Ich halte das für keine gute Lösung, da die viel zu arbeitsaufwendig ist.
Der Arbeitsaufwand ist überschaubar, falls die richtigen Vorkehrungen getroffen wurden. Bspw. könnte man fertig vorkonfigurierte Abbilder nutzen, die sich automatisiert einspielen lassen, oder Konfigurationsverwaltungssysteme und Backups der reinen Nutzerdaten verwenden, um den Aufwand vergleichsweise gering zu halten. Das beste ist, dass diese Ansätze sogar skalieren - ganz im Gegensatz zu den hier angedachten Maßnahmen, die auf manuelle Eingriffe je Maschine mit Live-Systemen, die es im Übrigen auch zu warten gilt.
--
Wenn die Hardware kaputt ist, dann kannst du den Rechner eh wegschmeißen.
Ich schrieb und Sie zitierten in diesem Kontext etwaige Angriffe auf die Firmware. Das heißt nicht automatisch, dass die Hardware defekt ist. Bspw. könnte man einen kompromittierten BIOS-Chip auslöten, flashen (oder ersetzen) und wieder einlöten, ohne die ganze Hardware entsorgen zu müssen.
Dann bringt auch eine Neuinstallation nichts.
Das kommt ganz darauf an...
Auch hier könnte dein jetztiges System genau diesen Zustand haben. Überprüfen kannst du es jetzt ja nicht.
Korrekt! Das gilt im Übrigen für jedes nicht völlständig isolierte System.
Derzeit habe ich keine Indizien, dass mein System nach Erstanwendung in dieser Art infiziert worden ist (Firmware). Für mich wäre der Aufwand zu groß, systematisch nach Indizien hierfür zu suchen. Außerdem bewerte ich die Attraktivität für Angreifer, mich oder meine Geräte zum Ziel eines Angriffs solcher Art zu haben, für unzureichend. Damit schätze ich das Risiko der Infektion dieser Art als gering ein. Vermutlich gibt es irgendwo in meiner Hardware eine Wanze oder eine Backdoor ab Werk. Diese hätte dann ihren Entwurfsursprung bei Geheimdiensten und wäre somit dergestalt, dass der nötige Aufwand, den ich als Privatperson und Laie betreiben müsste, um diese zu entdecken, unrealistisch hoch angesetzt wurde.
--
Eben und zu dem Prozess gehört auch ab und zu das System abzusuchen.
In der Tat! Das habe ich auch nicht bestreiten wollen. Jedoch sollte man diese Prozesse und Maßnahmen mit Bedacht wählen und umsetzen, wenn man einen effektiven Nutzen mit vertretbarem Aufwand erhalten will. Das war es, was ich kritisiert hatte.
...weil genau das Gegenteil als mögliche Herangehensweise beschrieben wurde:
Was verstehst du an:
"Aber selbst wenn man das am offenen Herzen machen will, so ist das mit Einschränkungen auch möglich. [...]"
nicht?
Wenn ich sage, die Farbe ist blau, dann brauchst du doch nicht sagen: "Hey, die Farbe ist ABER blau." Da du mich nur wiederholt hast.
Und die Einschränkungen decken schon alles ab, was du kritisiert hast. Da ist nämlich schon im Wort drin, dass damit gesagt ist, dass es nicht 100 % perfekt ist, aber gegen viele Fälle gut genug.
a) er will ja nicht booten. b) er will nicht booten. c) er ist mein Vorposter, guck dir den Kontext an. d) ist alles beantworten, habe jetzt keinen Bock das rauszufrimmeln. Lies selber nach und beachte den gesamten Kontext. Kannst gerne nochmal fragen und den Kontext zitieren, das spart mit die Sucharbeit und dann beantworte ich es vielleicht, wenn ich mir die Sucharbeit nicht machen muss. f) da musst du einfach ein bisschen Mitdenken, dann ist schon alles klar.
Wie und zu welchem Zeitpunkt erstellt man von diesen Dateien einen Hash, von dem sicher sein kann, dass er nicht kompromittiert ist?
Die editierten Dinger guckt man sich manuell an. Es geht darum, die Menge an Daten, die man durchgucken muss, zu reduzieren. Die white list erfüllt dies. Sie erfüllt dies sogar für die Configdateien, die nicht vom User editiert werden.
sondern dort gibt es sogar so einige Dateien (z.B. Shellkripte), die Code als root in unterschiedlichen Fällen und Regelmäßigkeiten ausführen.
Wie schon gesagt, ich kann die von mir in /etc editierten Dateieen an einer Hand abzählen und systemd sorgt dafür, dass ein Großteil der Skripte nicht mehr benötigt wird. Und den Hash von nicht editierten Skripten hat man.
Falls man das erste Indiz (z.B. üblich nach Auswertungen von Firewall-Logs; automatisiert oder nicht) einer Infizierung vorliegt, so hilft nur noch die Neuinstallation.
Firewall Logs nützen hier nichts. Bekanntlich nutzt man die Ports, die eh schon benutzt werden.
Es geht darum dass du nichts merkst, aber trotzdem eine Möglichkeit hast, es doch zu bemerken. Das ist nämlich dann der Fall, wenn der schon im System drin ist, dir das aber nicht auffällt.
Jetzt hast du zwei Möglichkeiten: Es mit dem Hashvergleich und der Eingrenzung auf den Rest mit dessen manueller Durchsicht zu merken. oder einfach mal aufs geradewohl neu zu installieren ohne es je zu merken. Die Wahrscheinlichkeit, dass er beim zweiten mal dann gleich wieder drin ist, ist hoch. Denn wer nicht weiß, das jemand reingekommen ist, der weiß auch nicht, wie er das geschafft hat und damit weiß man auch nicht, wie man dem entgegen steuert.
Eine solche Überprüfung dient also lediglich der Selbstbestätigung einer Vorahnung der Infizierung, mehr nicht.
Falsch. Sie hilft auch auch etwas zu merken, das man vorher nicht gemerkt hat.
Kannst du mir mit Sicherheit sagen, dass dein System jetzt gerade nicht kompromitiert ist? Nein, kannst du nicht. Aber es ist möglich das zu überprüfen, wenn man Prüfsummen hat und sich alles genau ansieht. Erst dann kann man mit Sicherheit sagen ob was los ist, zumindest wenn man die Live USB Variante nimmt, mit der anderen Möglichkeit ist das auch nicht gesichert, aber annähernd gut genug um dann abzuwägen, ob du jetzt heute neu installieren sollst.
Bspw. könnte man fertig vorkonfigurierte Abbilder nutzen, die sich automatisiert einspielen lassen,
Die alle die Lücke haben mit der der Angreifer gleich wieder drin ist. Denn du weißt ja nicht, wie und ob er reingekommen ist.
Ich schrieb und Sie zitierten in diesem Kontext etwaige Angriffe auf die Firmware. Das heißt nicht automatisch, dass die Hardware defekt ist. Bspw. könnte man einen kompromittierten BIOS-Chip auslöten, flashen (oder ersetzen) und wieder einlöten, ohne die ganze Hardware entsorgen zu müssen.
Es ist klar wie es gemeint war. Denn die Lösung skaliert auch nicht mehr und braucht eventuell Spezialtools, Zeit und Know How.
"Aber selbst wenn man das am offenen Herzen machen will, so ist das mit Einschränkungen auch möglich. [...]"
nicht? [...]
Der restliche Kommentar, der die Quelle dieses Zitats ist, handelt nur von einer Überprüfung innerhalb des Zielsystems jener, also während das Zielsystems läuft.
Ja, Sie hatten Einschränkungen erwähnt. Ich erhielt dabei nur den Eindruck, dass Sie das Ausmaß dieser Einschränkungen falsch einschätzen, und daraus falsche Konsequenzen ziehen würden.
--
a) er will ja nicht booten. b) er will nicht booten. c) er ist mein Vorposter, guck dir den Kontext an. d) ist alles beantworten, habe jetzt keinen Bock das rauszufrimmeln. Lies selber nach und beachte den gesamten Kontext. Kannst gerne nochmal fragen und den Kontext zitieren, das spart mit die Sucharbeit und dann beantworte ich es vielleicht, wenn ich mir die Sucharbeit nicht machen muss. f) da musst du einfach ein bisschen Mitdenken, dann ist schon alles klar.
a) Das ist keine Antwort auf meine Frage. Ich kenne den Begriff nicht. Daher meine Frage. Meinen Sie eventuell eine Überprüfung innerhalb des zu überprüfenden Zielsystems, also während dieses läuft? Eventuell wäre es hilfreich, Sie würden sich klarer ausdrücken.
b) ebenfalls keine Antwort meiner Frage
c) Achso, Sie antworten auf einen Kommentar eines Kommentars und verwenden dabei das selbe Pseudonym. Das ist äußerst verwirrend. Es tut mir Leid, aber Sie müssen zugeben, dass dadurch große Verwechslungen und Missverständnisse vorprogrammiert sind.
d) Wer seine Argumente nicht verstanden wissen will, kann sie sich auch sparen. Da verliert man ja direkt die Lust.
e) fehlt
f) Danke, jetzt ist mir alles klar. Dies wird mein letzter Kommentar dazu sein.
--
Firewall Logs nützen hier nichts. Bekanntlich nutzt man die Ports, die eh schon benutzt werden.
Das suggeriert, Sie hätten ein etwas vereinfachtes Verständnis einer Firewall. Wie viel die Firewall oder die Auswertung ihrer Protokolle in diesem Fall nützt, hängt davon ab, wie die Firewall konfiguriert worden ist, also z.B. bzgl. Quelle, Ziel, Stateful Packet Inspection, Deep Packet Inspection etc.
--
Es geht darum dass du nichts merkst, aber trotzdem eine Möglichkeit hast, es doch zu bemerken. Das ist nämlich dann der Fall, wenn der schon im System drin ist, dir das aber nicht auffällt.
Jetzt hast du zwei Möglichkeiten: Es mit dem Hashvergleich und der Eingrenzung auf den Rest mit dessen manueller Durchsicht zu merken. [...]
Ja, aber nur falls dies von einem nicht-kompromittiertem System aus geschieht, und die Prüfsummenliste nicht kompromittiert wurde.
[...] oder einfach mal aufs geradewohl neu zu installieren ohne es je zu merken. Die Wahrscheinlichkeit, dass er beim zweiten mal dann gleich wieder drin ist, ist hoch. Denn wer nicht weiß, das jemand reingekommen ist, der weiß auch nicht, wie er das geschafft hat und damit weiß man auch nicht, wie man dem entgegen steuert.
Eine Neuinstallation bietet jedenfalls eine höhere Sicherheit, als dem (möglicherweise falsch-negativen) Ergebnis einer Infizierungsüberprüfung mittels eines Abgleichs unvollständiger Prüfsummenlisten im laufenden Betrieb blind zu trauen.
Und ich habe auch nicht behauptet, dass eine Neuinstallation in jedem Fall alleinig ausreichen würde, um zukünftige Infektionen sinnvoll zu verhindern. Das ist auch ein ganz anderes Thema, das mit dem bloßen Aufspüren von Malware weniger zu tun hat. Es ist viel eher Teil einer Infektionsanalyse anhand derer man Konsequenzen zieht und Gegenmaßnahmen entwirft und einleitet.
Eine solche Überprüfung dient also lediglich der Selbstbestätigung einer Vorahnung der Infizierung, mehr nicht.
Falsch. Sie hilft auch auch etwas zu merken, das man vorher nicht gemerkt hat.
Außer sie tut es nicht - aus welchem Grund auch immer (Überprüfung im laufenden Zielsystem, kompromittierte oder unvollständige Prüfsummenlisten, Benutzungsfehler, Fehler bei teilweise manueller Prüfung, Logikfehler, und andere menschliche Fehler). Bei einem nicht unwahrscheinlich auftretenden falsch-negativen Ergebnis einer Überprüfung auf Infektion wiegt man sich in Sicherheit, denn man weiß dann nicht, dass das System tatsächlich infiziert ist.
Wir drehen uns hier im Kreis...
--
Kannst du mir mit Sicherheit sagen, dass dein System jetzt gerade nicht kompromitiert ist? Nein, kannst du nicht.
Nun, das kann niemand. Das war auch nicht der springende Punkt.
Aber es ist möglich das zu überprüfen, wenn man Prüfsummen hat und sich alles genau ansieht. Erst dann kann man mit Sicherheit sagen ob was los ist, zumindest wenn man die Live USB Variante nimmt, mit der anderen Möglichkeit ist das auch nicht gesichert, aber annähernd gut genug um dann abzuwägen, ob du jetzt heute neu installieren sollst.
Da mit wir uns nichts vor machen: sicher ist nichts.
Ja, wenn man das in dieser Variante (mit Live-System) durchführt, erhält man relativ verlässliche Ergebnisse. Voraussetzung ist natürlich, dass die Prüfsummenliste nicht kompromittiert wurde und vollständig ist. Den Fall der Infektion der Firmware/Hardware lassen wir hier der Einfachheit halber außer Acht. Sind wir uns da einig?
Um das also wirklich verlässlich umzusetzen, bedarf es eines enormen Aufwandes, der vom Nutzen kaum zu rechtfertigen ist.
Bspw. könnte man fertig vorkonfigurierte Abbilder nutzen, die sich automatisiert einspielen lassen,
Die alle die Lücke haben mit der der Angreifer gleich wieder drin ist. Denn du weißt ja nicht, wie und ob er reingekommen ist.
Das ist aber ein Problem, dass man auch mit anderen Maßnahmen hat. Man benötigt stets eine hinreichende Analyse, um eine gewünschte Sicherheit zu erlangen. Diese lässt sich meisten nicht automatisieren.
Ich habe an dieser Stelle lediglich eine Methode vorgeschlagen, die einen Teil des gesamten Prozesses automatisiert und vereinfacht, und sich damit von anderen Methoden absetzt.
--
Es ist klar wie es gemeint war.
Na dann können wir uns ja mit unseren telepathischen Fähigkeiten weiter unterhalten.
Denn die Lösung skaliert auch nicht mehr und braucht eventuell Spezialtools, Zeit und Know How.
Das selbe gilt ebenfalls für die Lösung, die Sie verteidigen.
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.
Ich brauch doch nur ne Dateiliste und die wird dann benutzt um die Hashs mit der online Dateiliste und deren Hashs zu prüfen.
Ein Dienst müste also alle Dateien mit Verzeichnisnamen und den dazu gehörigen Hash inkl. aller Versionen bereithalten.
Dann könnte man nach die einzelnen Dateien abfragen und die beiden Hashs vergleichen.
Wenn ein Hash falsch ist, wurde er manipuliert.
Wenn die Hash stimmt, aber eine ältere Datei ist, dann wurde nur das Paket nicht upgedated.
Wenn eine Datei nicht gefunden wurde, die aber auf dem System ist, dann wurde was dazugefügt.
Dann müsstest du aber regelmäßig dein System offline nehmen und deine Festplatten über eine vertrauenswürdige Umgebung (Live-System) untersuchen. Willst du das wirklich machen? Warum? Scheint mir etwas aufwändig zu sein, zumal das Hashen *aller* Dateien doch etwas dauern kann -> Downtime.
Dafür ist das System ja auch gedacht.
Damit ich mich nicht in falscher Sicherheit wiege.
Ich habe hier keinen Server, sondern einen oder mehrere Desktoprechner bei denen ich das gerne in regelmäßigen Abständen so machen würde.
Da spielt die "Downtime" eine untergeordnete Rolle.
Aber selbst wenn man das am offenen Herzen machen will, so ist das mit Einschränkungen auch möglich.
Denn nicht jede Schadsoftware ist gegen alle Aufspürmethoden gewappnet.
Manche verstecken sich vor bestimmten Prozessen wie bspw. top und htop oder Antirootkitsoftware oder es werden diese direkt auf dem System verändert, manche gehen tiefer und verändern den Kernel, aber manche kann man auch mit anderen Programmen aufspüren, die diese nicht auf dem Radar haben.
Unter Windows gab es mal ein Freeware Programm, hijackthis und der process explorer waren es nicht, den Namen habe ich vergessen.
Dieses konnte zum Aufspüren von solchen laufenden Schadsoftwareprozessen eingesetzt werden.
Es zeigte dabei alle laufenden Prozessen an.
Aber da es Schadsoftware gibt, die sich vor solchen Tools versuchen zu verbergen, versuchte es sich durch obfuscation Techniken selbst vor der Schadsoftware zu verstecken.
Das Programm hatte bspw. immer einen anderen recht kryptischen Namen und hieß als laufender Prozess immer anders.
Eine Schadsoftware, die sich nur vor bestimmten Prozessen verstecken konnte, konnte sich vor diesem nicht so einfach verstecken und somit aufgespürt werden.
Das gleiche wäre auch für Linux möglich und als Open Source Software sogar noch besser.
Da man den Quellcode ändern kann und das Binary immer etwas anders aussehen lassen könnte.
Dieses könnte man dann an einem laufenden System starten und das führt dann den Hashdownload und die Vergleiche durch.
Damit würde man auf jeden Fall Veränderungen von wichtigen Systemprogramme, wie bspw. lsof, top und Co, erkennen.
Der Process Explorer von Sysinternals für Windows macht bezüglich der laufenden Prozesse ähnliches. Er kann sich zwar nicht per Obfuscatormethode verstecken, aber man kann alle laufenden Prozesse mit den Hashs von Virustotal in einem Rutsch vergleichen und somit verdächtigen Prozesse oder Programme, deren EXE manipuliert wurde, schnell erkennen.
So etwas plus den Vergleich aller von der Distribution kommenenden Binaries hätte ich auch gerne für Debian.
Machbar wäre es auf jeden Fall, es Bedarf auf Seiten Debian aber gewisser Infrastruktur.
Also ein Serverdienst, der die Hashs aller Distributionisspezifuschen Dateien, wie es virustotal auch für bekannte Windows Programme bietet, bereit hält.
Sie würden sich in Sicherheit wiegen, aus einer Nichtentdeckung "am offenen Herzen" keine weiteren Konsequenzen zu ziehen.
2. Selbst aus einem nicht kompromittierten System heraus ist die erfolgreiche Entdeckung eines Rootkits oder anderer Malware beliebig kompliziert bis unmöglich, da ein Angreifer in der Regel, aber spätestens mit der erfolgreichen Installation von Malware, die nötigen Rechte besitzt, dies hinreichend zu verschleiern - insbesondere bei Angriffen auf die Firmware selbst (siehe z.B. hier, da oder dort).
3. Sicherheit ist ein Prozess. In jedem Fall muss das Bedrohungsmodell klar formuliert und gerechtfertigt sein.
Der Aufwand möglicher Gegenmaßnahmen steht dem Risiko und potentiellen Konsequenzen einer Infizierung gegenüber und muss abgewogen werden. Der Aufwand ist theoretisch oft so groß, dass alle gängigen Entdeckungsmaßnahmen wie Schlangenöl wirken.
Vorbeugende Maßnahmen und Vorkehrungen für zügige Neuinstallationen samt Wiederherstellung des gewünschten Konfigurationszustands sind in der Regel das Mittel der Wahl.
1. Warum schreibst du so doof, es steht doch bereits da, dass man das auf dem Live System macht. Warum muss ich dir das noch einmal sagen?
Er will ja nichts machen, also gar nichts prüfen, ist dass dann die bessere Alternative?Nur für den, der jetzt unbedingt das auf dem Laufsystem machen muss, das eh nie booten will und das er links liegen lassen würde, wenn es das nicht geben würde, ist die andere Möglichkeit da und da wurde bereits gesagt, was die Einschränkungen sind.
Das kannst du dir selber beantworten.
Deswegen bootet man das unbelastete System und vergleicht ALLE Dateien mit den hashs und dann wird man auch fündig.
Die Alternative dazu ist NIEMALS zu wissen, was auf dem System los ist. Diesen Zustand hat dein jetztiges System gerade.
Was du dann noch machen kannst ist regelmäßig das System neu zu installieren.
Wenn die Hardware kaputt ist, dann kannst du den Rechner eh wegschmeißen.Ich halte das für keine gute Lösung, da die viel zu arbeitsaufwendig ist.
Dann bringt auch eine Neuinstallation nichts.
Auch hier könnte dein jetztiges System genau diesen Zustand haben. Überprüfen kannst du es jetzt ja nicht.Eben und zu dem Prozess gehört auch ab und zu das System abzusuchen.
a) Was ist ein Laufsystem?
b) Woher entstammt die Annahme, dass es nicht startet, bzw. warum ist diese hier relevant?
c) Wer ist "er"?
d) Was würde es nicht geben? "die andere Möglichkeit"?
e) Ist "die andere Möglichkeit" die erwähnte Überprüfung im laufenden Betrieb?
f) Wo wurde bereits genau gesagt, was die Einschränkungen sind? Ich lese in obigem Kommentar nur Rechtfertigungen für eine Überprüfung "am offenen Herzen", die im Wesentlichen von der Annahme ausgehen, dass die allermeiste Malware zu große Mängel hätte, die das Verwischen ihrer eigenen Spuren betrifft.
--
Sprechen Sie hier von sich selbst in der dritten Person? Wer ist "Er"? Gibt es hier zwei verschiedene Individuen, die das Pseudonym Ghul verwenden?Zum Inhalt: "Er" will sehr wohl prüfen, weil "Er" schrieb:
undDie eigentliche Frage lautet, was der effektive Nutzen jener Maßnahmen im Verhältnis zum Aufwand wäre.
--
Ach, kann ich das? Oder wollen Sie mir einfach nur weismachen, dass ich gefälligst meine Klappe halten soll?--
Was bedeutet "ALLE Dateien" in diesem Kontext präzise? Was ist denn mit Dateien, die von Administratoren, Upgrades, Diensten und Nutzern absichtlich editierbar sind? Wie und zu welchem Zeitpunkt erstellt man von diesen Dateien einen Hash, von dem sicher sein kann, dass er nicht kompromittiert ist?Bspw. betrifft das Dateien in
Nein, die Alternative ist, präzise Bedrohungsmodelle zu beschreiben und sauberen und sinnvollen Sicherheitsprozesse strikt zu folgen, um Infizierungen vorzubeugen. Falls man das erste Indiz (z.B. üblich nach Auswertungen von Firewall-Logs; automatisiert oder nicht) einer Infizierung vorliegt, so hilft nur noch die Neuinstallation./etcunter Debian - übrigens die einzige Verbindung zum Artikel. Das sind nicht nur einfache Key-Value-Konfigurationsdateien (/etc/passwd,/etc/shadowund/etc/sudo.confwären auch ein paar heiße Kandidaten.), sondern dort gibt es sogar so einige Dateien (z.B. Shellkripte), die Code als root in unterschiedlichen Fällen und Regelmäßigkeiten ausführen.Wie geht man also - unter Vermeidung eines riesigen Aufwandes - damit um?
Falls Sie diese Frage nicht zufriedenstellend beantworten können, sind die vorgeschlagenen Maßnahmen quasi nichts wert. Genau darum ging es mir in meiner Kritik.
Ggf. kann man dieses Indiz vor einer Neuinstallation mittels geeigneter Maßnahmen erhärten. Da diese Maßnahmen ihre eigenen Probleme (hohes Risiko einer falsch-negativen Bewertung des Infektionszustands) haben, lautet die einzig korrekte Konsequenz dieser Überprüfung jedoch - unabhänging von ihrem Ausgang - Neuinstallation (und/oder sogar Austausch der Hardware).
Der Arbeitsaufwand ist überschaubar, falls die richtigen Vorkehrungen getroffen wurden. Bspw. könnte man fertig vorkonfigurierte Abbilder nutzen, die sich automatisiert einspielen lassen, oder Konfigurationsverwaltungssysteme und Backups der reinen Nutzerdaten verwenden, um den Aufwand vergleichsweise gering zu halten. Das beste ist, dass diese Ansätze sogar skalieren - ganz im Gegensatz zu den hier angedachten Maßnahmen, die auf manuelle Eingriffe je Maschine mit Live-Systemen, die es im Übrigen auch zu warten gilt.Eine solche Überprüfung dient also lediglich der Selbstbestätigung einer Vorahnung der Infizierung, mehr nicht.
--
Ich schrieb und Sie zitierten in diesem Kontext etwaige Angriffe auf die Firmware. Das heißt nicht automatisch, dass die Hardware defekt ist. Bspw. könnte man einen kompromittierten BIOS-Chip auslöten, flashen (oder ersetzen) und wieder einlöten, ohne die ganze Hardware entsorgen zu müssen.Das kommt ganz darauf an...Korrekt! Das gilt im Übrigen für jedes nicht völlständig isolierte System.Derzeit habe ich keine Indizien, dass mein System nach Erstanwendung in dieser Art infiziert worden ist (Firmware). Für mich wäre der Aufwand zu groß, systematisch nach Indizien hierfür zu suchen.
Außerdem bewerte ich die Attraktivität für Angreifer, mich oder meine Geräte zum Ziel eines Angriffs solcher Art zu haben, für unzureichend. Damit schätze ich das Risiko der Infektion dieser Art als gering ein.
Vermutlich gibt es irgendwo in meiner Hardware eine Wanze oder eine Backdoor ab Werk. Diese hätte dann ihren Entwurfsursprung bei Geheimdiensten und wäre somit dergestalt, dass der nötige Aufwand, den ich als Privatperson und Laie betreiben müsste, um diese zu entdecken, unrealistisch hoch angesetzt wurde.
--
In der Tat! Das habe ich auch nicht bestreiten wollen.Jedoch sollte man diese Prozesse und Maßnahmen mit Bedacht wählen und umsetzen, wenn man einen effektiven Nutzen mit vertretbarem Aufwand erhalten will. Das war es, was ich kritisiert hatte.
Was verstehst du an:
nicht?Wenn ich sage, die Farbe ist blau, dann brauchst du doch nicht sagen: "Hey, die Farbe ist ABER blau."
Da du mich nur wiederholt hast.
Und die Einschränkungen decken schon alles ab, was du kritisiert hast. Da ist nämlich schon im Wort drin, dass damit gesagt ist, dass es nicht 100 % perfekt ist, aber gegen viele Fälle gut genug.
a) er will ja nicht booten.
Die editierten Dinger guckt man sich manuell an.b) er will nicht booten.
c) er ist mein Vorposter, guck dir den Kontext an.
d) ist alles beantworten, habe jetzt keinen Bock das rauszufrimmeln. Lies selber nach und beachte den gesamten Kontext. Kannst gerne nochmal fragen und den Kontext zitieren, das spart mit die Sucharbeit und dann beantworte ich es vielleicht, wenn ich mir die Sucharbeit nicht machen muss.
f) da musst du einfach ein bisschen Mitdenken, dann ist schon alles klar.
Es geht darum, die Menge an Daten, die man durchgucken muss, zu reduzieren. Die white list erfüllt dies.
Sie erfüllt dies sogar für die Configdateien, die nicht vom User editiert werden.Wie schon gesagt, ich kann die von mir in /etc editierten Dateieen an einer Hand abzählen und systemd sorgt dafür, dass ein Großteil der Skripte nicht mehr benötigt wird.
Und den Hash von nicht editierten Skripten hat man.Firewall Logs nützen hier nichts. Bekanntlich nutzt man die Ports, die eh schon benutzt werden.
Es geht darum dass du nichts merkst, aber trotzdem eine Möglichkeit hast, es doch zu bemerken.
Das ist nämlich dann der Fall, wenn der schon im System drin ist, dir das aber nicht auffällt.
Jetzt hast du zwei Möglichkeiten:
Falsch.Es mit dem Hashvergleich und der Eingrenzung auf den Rest mit dessen manueller Durchsicht zu merken.
oder
einfach mal aufs geradewohl neu zu installieren ohne es je zu merken.
Die Wahrscheinlichkeit, dass er beim zweiten mal dann gleich wieder drin ist, ist hoch.
Denn wer nicht weiß, das jemand reingekommen ist, der weiß auch nicht, wie er das geschafft hat und damit weiß man auch nicht, wie man dem entgegen steuert.
Sie hilft auch auch etwas zu merken, das man vorher nicht gemerkt hat.
Kannst du mir mit Sicherheit sagen, dass dein System jetzt gerade nicht kompromitiert ist?
Die alle die Lücke haben mit der der Angreifer gleich wieder drin ist.Nein, kannst du nicht.
Aber es ist möglich das zu überprüfen, wenn man Prüfsummen hat und sich alles genau ansieht. Erst dann kann man mit Sicherheit sagen ob was los ist, zumindest wenn man die Live USB Variante nimmt, mit der anderen Möglichkeit ist das auch nicht gesichert, aber annähernd gut genug um dann abzuwägen, ob du jetzt heute neu installieren sollst.
Denn du weißt ja nicht, wie und ob er reingekommen ist.Es ist klar wie es gemeint war.
Denn die Lösung skaliert auch nicht mehr und braucht eventuell Spezialtools, Zeit und Know How.
Ja, Sie hatten Einschränkungen erwähnt. Ich erhielt dabei nur den Eindruck, dass Sie das Ausmaß dieser Einschränkungen falsch einschätzen, und daraus falsche Konsequenzen ziehen würden.
--
a) Das ist keine Antwort auf meine Frage. Ich kenne den Begriff nicht. Daher meine Frage. Meinen Sie eventuell eine Überprüfung innerhalb des zu überprüfenden Zielsystems, also während dieses läuft?Eventuell wäre es hilfreich, Sie würden sich klarer ausdrücken.
b) ebenfalls keine Antwort meiner Frage
c) Achso, Sie antworten auf einen Kommentar eines Kommentars und verwenden dabei das selbe Pseudonym. Das ist äußerst verwirrend. Es tut mir Leid, aber Sie müssen zugeben, dass dadurch große Verwechslungen und Missverständnisse vorprogrammiert sind.
d) Wer seine Argumente nicht verstanden wissen will, kann sie sich auch sparen. Da verliert man ja direkt die Lust.
e) fehlt
f) Danke, jetzt ist mir alles klar. Dies wird mein letzter Kommentar dazu sein.
--
Das suggeriert, Sie hätten ein etwas vereinfachtes Verständnis einer Firewall.Wie viel die Firewall oder die Auswertung ihrer Protokolle in diesem Fall nützt, hängt davon ab, wie die Firewall konfiguriert worden ist, also z.B. bzgl. Quelle, Ziel, Stateful Packet Inspection, Deep Packet Inspection etc.
--
Ja, aber nur falls dies von einem nicht-kompromittiertem System aus geschieht, und die Prüfsummenliste nicht kompromittiert wurde.Eine Neuinstallation bietet jedenfalls eine höhere Sicherheit, als dem (möglicherweise falsch-negativen) Ergebnis einer Infizierungsüberprüfung mittels eines Abgleichs unvollständiger Prüfsummenlisten im laufenden Betrieb blind zu trauen.Und ich habe auch nicht behauptet, dass eine Neuinstallation in jedem Fall alleinig ausreichen würde, um zukünftige Infektionen sinnvoll zu verhindern.
Außer sie tut es nicht - aus welchem Grund auch immer (Überprüfung im laufenden Zielsystem, kompromittierte oder unvollständige Prüfsummenlisten, Benutzungsfehler, Fehler bei teilweise manueller Prüfung, Logikfehler, und andere menschliche Fehler). Bei einem nicht unwahrscheinlich auftretenden falsch-negativen Ergebnis einer Überprüfung auf Infektion wiegt man sich in Sicherheit, denn man weiß dann nicht, dass das System tatsächlich infiziert ist.Das ist auch ein ganz anderes Thema, das mit dem bloßen Aufspüren von Malware weniger zu tun hat. Es ist viel eher Teil einer Infektionsanalyse anhand derer man Konsequenzen zieht und Gegenmaßnahmen entwirft und einleitet.
Wir drehen uns hier im Kreis...
--
Nun, das kann niemand. Das war auch nicht der springende Punkt.Da mit wir uns nichts vor machen: sicher ist nichts.Ja, wenn man das in dieser Variante (mit Live-System) durchführt, erhält man relativ verlässliche Ergebnisse. Voraussetzung ist natürlich, dass die Prüfsummenliste nicht kompromittiert wurde und vollständig ist. Den Fall der Infektion der Firmware/Hardware lassen wir hier der Einfachheit halber außer Acht.
Sind wir uns da einig?
Um das also wirklich verlässlich umzusetzen, bedarf es eines enormen Aufwandes, der vom Nutzen kaum zu rechtfertigen ist.
Das ist aber ein Problem, dass man auch mit anderen Maßnahmen hat. Man benötigt stets eine hinreichende Analyse, um eine gewünschte Sicherheit zu erlangen. Diese lässt sich meisten nicht automatisieren.Ich habe an dieser Stelle lediglich eine Methode vorgeschlagen, die einen Teil des gesamten Prozesses automatisiert und vereinfacht, und sich damit von anderen Methoden absetzt.
--
Na dann können wir uns ja mit unseren telepathischen Fähigkeiten weiter unterhalten.Das selbe gilt ebenfalls für die Lösung, die Sie verteidigen.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.