Login
Newsletter
Werbung

Thema: Sam Hartman neuer Debian-Projektleiter

33 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Ghul am Mi, 24. April 2019 um 15:53 #

von Prüfsummen für alle Dateien die über die deb Pakete installiert werden.

Damit man auch nach der Installation herausfinden kann, ob noch alle Dateien so sind, wie sie zum Zeitpunkt der Installation waren.
Das würde auch das Auffinden von rootkits und vernderten Dateien wesentlich erleichtern.

So wie ich das verstanden habe, müssen bei debsums nämlich die Prüfsummen auf dem System erstellt werden bzw. wird, sofern diese vorhanden sind, aus den Dateien in /var/lib/dpkg/info/*.md5sums ausgewertet.
Die Dateien darin könnte aber bei root Zugriff manipuliert worden sein. Deswegen gehören solche Prüfsummendateilisten online deponiert.

Das ganze sollte man dann noch mit einem Live System kombinieren, dass man booten kann, sich die Prüfsummenlisten von den Debian Servern holt und dann mit denen auf dem System vergleicht.

  • 0
    Von 1ras am Mi, 24. April 2019 um 18:42 #

    Woher willst du denn wissen, welche Debian Pakete auf deinem System überhaupt installiert sind, die DPKG-Datenbank der installierten Pakete kann doch genau so vom Angreifer manipuliert worden sein?

    Und gegen ein Backup der /var/lib/dpkg/info/*.md5sums kannst du jetzt auch schon prüfen.

    • 0
      Von Ghul am Mi, 24. April 2019 um 20:13 #

      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.

      • 0
        Von Tamaskan am Mi, 24. April 2019 um 20:31 #

        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.

        • 0
          Von Ghul am Do, 25. April 2019 um 08:33 #

          Dafür ist das System ja auch gedacht.

          Willst du das wirklich machen? Warum?

          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.

          • 0
            Von klopskind am Do, 25. April 2019 um 11:58 #

            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.

            • 0
              Von Ghul am Do, 25. April 2019 um 15:07 #

              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.

              • 0
                Von klopskind am Fr, 26. April 2019 um 00:04 #

                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.

                • 0
                  Von Ghul am Fr, 26. April 2019 um 10:24 #

                  ...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.

                  • 0
                    Von klopskind am Fr, 26. April 2019 um 13:34 #

                    Was verstehst du an:

                    "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.

        0
        Von 1ras am Mi, 24. April 2019 um 23:50 #

        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.

        • 0
          Von Ghul am Do, 25. April 2019 um 08:41 #

          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.

          0
          Von Ghul am Do, 25. April 2019 um 08:43 #

          Um es also kurz zu machen.

          Der Ansatz funktioniert.

          Die händisch zu prüfende Datenmenge wird damit auf jeden Fall maßgeblich reduziert.

          • 0
            Von Ghul am Do, 25. April 2019 um 08:46 #

            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.

            • 1
              Von Ghul am Do, 25. April 2019 um 08:49 #

              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.

              • 1
                Von klopskind am Do, 25. April 2019 um 12:02 #

                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!

                • 1
                  Von Ghul am Do, 25. April 2019 um 15:13 #

                  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.

                  • 0
                    Von klopskind am Fr, 26. April 2019 um 09:54 #

                    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?

                    • 0
                      Von Ghul am Fr, 26. April 2019 um 10:29 #

                      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.

                      • 0
                        Von klopskind am Fr, 26. April 2019 um 11:58 #

                        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.

          0
          Von Ghul am Do, 25. April 2019 um 08:44 #

          Mit anderen Worten, man kann somit /var und /etc prüfen.
          Verändertes wird ausgespruckt und kann nochmal ganz genau angesehen werden.

          • 0
            Von 1ras am Do, 25. April 2019 um 12:50 #

            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.

            • 0
              Von Ghul am Do, 25. April 2019 um 15:17 #

              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.

              • 0
                Von 1ras am Do, 25. April 2019 um 16:14 #

                * 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.

                • 0
                  Von Ghul am Fr, 26. April 2019 um 10:37 #

                  * 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.

    0
    Von klopskind am Do, 25. April 2019 um 11:22 #

    1. Bereitstellung einer "Whitelist"

    Debian benötigt eine online verfügbare Whitelist von Prüfsummen für alle Dateien die über die deb Pakete installiert werden.
    Falls ich Sie richtig verstehe, sollte es keinen großen Aufwand darstellen, eine solche Liste bereitzustellen.

    Erstellen ließe sich eine solche Liste auf einem nicht kompromittiertem oder frisch installiertem Debian-System mittels apt-get(8) (z.B. mit den Argumenten update und download * [/ target-release] oder -d install * [/ target-release]), debsums(1) (z.B. via debsums --generate) und ggf. diverser Werkzeuge zur Nachverarbeitung der Liste(n).

    Die Verbreitung dieser Liste(n) ist eine andere Geschichte. Nach einer eventuell nötigen Vorverarbeitung der Liste(n) könnte man diese irgendwo hochladen, z.B. hier, und die URL(s) geeignet verteilen.
    Eine gewisse "Permanenz" der Daten ließe sich mittels Diensten wie archive.org oder archive.is erzielen.
    So wäre(n) die Liste(n) "jederzeit" online verfüg- und abrufbar.

    Die nötigen Werkzeuge stehen also bereit. Was hindert Sie daran, eine solche Liste bereitzustellen?


    2. Verifikation

    Damit man auch nach der Installation herausfinden kann, ob noch alle Dateien so sind, wie sie zum Zeitpunkt der Installation waren.
    Zur Verifikation eines Zielsystem könnte man diese Liste(n) kopieren und debsums -cm nutzen.
    Allerdings bräuchte man dazu zusätzlich den beabsichtigten Konfigurationszustand des Zielsystems, inbesondere eine unkompromittierte Liste der zu installierenden (und der abwesenden) Pakete. Ein weitere Voraussetzung ist, dass die Verifikationsumgebung selbst nicht kompromittiert ist. D.h. zur Durchführung einer Verifikation bräuchte man in der Regel - es sei denn, man weiß Näheres über die Art der Kompromittierung des Zielsystems - ein Live-System, wie Sie bereits vorschlugen.

    Zur Verifikation der vom Administrator des Zielsystems individuell angepassten Konfigurationsdateien unter /etc sind andere Maßnahmen nötig. So könnte man diese in Eigenregie separat, z.B. mittels eines Kontrollsystems (z.B. eines Konfigurationsverwaltungssystems), abgleichen.

    Live-Systeme gibt es für diesen Zweck wie Sand am Meer und ließen sich mittels fertiger Werkzeuge zwar schnell erstellen, aber diese Methode der Kontrolle ist generell sehr aufwändig, und bedarf neben den nötigen Vorbereitungen auch eines manuellen Eingriffs je Maschine.
    Es stellt sich daher die Frage, wie häufig diese Maßnahmen ergriffen werden sollten und können, und ob stattdessen eine regelmäßige Neuinstallation samt einer Wiederherstellung eines gesicherten Konfigurationszustand (nicht kompromittiert!) nicht einfacher wäre.


    3. Das Bedrohungsmodell
    Was ist eigentlich die Bedrohung, von denen Sie hier ausgehen und vor denen Sie sich mit diesen Maßnahmen schützen wollen?

    Das würde auch das Auffinden von rootkits und vernderten Dateien wesentlich erleichtern.
    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. Aufgrund der Komplexität nehme ich an, dass die MAC-Einschränkungen roots hinreichend schwach sind. (Verwendet Debian standardmäßig MAC?)

    Wenn ein Angreifer also die nötigen Rechte besitzt, ein Rootkit zu installieren, so grenzt es an sicherer Wahrscheinlichkeit, dass dieser auch genügend Rechte hat (oder in Kürze haben wird), um die Installation des Rootkits hinreichend zu verschleiern, sodass Punkte 1 und 2 und alle anderen Maßnahmen einer Entdeckung ebenfalls quasi nutzlos werden. So werden Kernel-Rootkits meines Erachtens nach nicht von einer Umsetzung Ihrer Ideen und Vorschläge erfasst. In so einem Fall hilft höchstens die Neuinstallation des Zielsystems.
    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.


    tl;dr:
    Die Erstellung und Verbreitung einer "Whitelist" ist schon heute unter geringem Aufwand möglich. Allerdings ist das nur der erste Schritt.

    Die Verifikation/Entdeckung ist mit hohem manuellen Aufwand verbunden. Ich halte es für daher fraglich, wie groß der effektive Nutzen Ihrer Vorschläge tatsächlich ist, insbesondere im Verhältnis zum hierfür nötigen Aufwand.
    Das erklärt möglicherweise auch, warum eine "Whitelist" bisher nicht (online) angeboten wird.

    Die Entdeckung eines Rootkits ist beliebig kompliziert.
    Es wirkt einfacher, den Konfigurationszustand des Systems gesondert vorzuhalten (ähnlich eines Konfigurationsverwaltungssystems) und regelmäßige/gelegentliche Neuinstallationen durchzuführen. Dabei sollten stets Vorkehrungen getroffen werden, um Infizierungen vorzubeugen.

    Falls die Firmware selbst befallen wird, bleibt lediglich der Ersatz des/der befallenen Hardware(-Chips) und die Neuinstallation.

    • 0
      Von Ghul am Do, 25. April 2019 um 15:33 #

      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?

      • 0
        Von klopskind am Fr, 26. April 2019 um 11:27 #

        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.

0
Von klopskind am Mi, 24. April 2019 um 22:19 #

Informativ und auf den Punkt! Besten Dank an den Verfasser des Artikels.

Trotzdem ein kleiner Einwand! Im Artikel las ich:

Die Wahlbeteiligung bei den 1003 wahlberechtigten Debian-Mitgliedern lag etwas höher als im letzten Jahr, aber dennoch nur knapp über einem Drittel. Das spiegelt weiterhin einen langjährigen Trend abnehmender Beteiligung wider.
Letzteren Satz kann ich anhand der Statistik aus der im Artikel verlinkten Mail des Sekretärs des Debianprojekts nicht ganz nachvollziehen.

Bis (einschließlich) 2007 lag die Wahlbeteiligung tatsächlich signifikant höher als in diesem Jahr. Nach einer kurzen Talfahrt in den Jahren 2008/2009 stieg sie 2010 wieder stark an und fiel schließlich bis 2016 steil ab. Seitdessen ging der Trend der Wahlbeteiligung allerdings wieder aufwärts, sodass diese dieses Jahr nun ganze zehn Prozentpunkte höher liegt als noch 2016.

Jedenfalls finde ich die Formulierung im Artikel für meinen Geschmack etwas unpräzise.

Mein Formulierungsvorschlag, Text in Klammern ggf. entfernen:
"Die Wahlbeteiligung bei den 1003 wahlberechtigten Debian-Mitgliedern lag etwas höher als in den letzten vier Jahren (bei nahezu konstanter Anzahl wahlberechtigter Entwickler), aber dennoch nur knapp über einem Drittel. Dennoch spiegelt sich in der inzwischen 20-jährigen Statistik der alljährlichen Wahlen insgesamt (vielleicht besser: im Mittel) ein langjähriger Trend abnehmender Beteiligung wider."

--
Beste Grüße

0
Von Janko Weber am Sa, 27. April 2019 um 21:48 #

Ich bin ja Desktop-User. Und stelle Fragen wie: Warum sollte ich von Debian 8 auf 9, 10 oder 11 wechseln?
Ich habe gestern mal die 32-bit CD-Verrsion Debian 9.5 installiert: Mandrake hatte vor 20 Jahren schon einen besseren Installer! Und wenn ich dann eine Software-Auswahl bekomme die noch nicht einmal ein einziges Spiel und keinen Audio-Player enthält weiß ich nicht ob ich lachen oder weinen soll. Die Installation auf Festplatte hat 3x solange gedauert wie die Installation von meinem MX15(Debian8-Remaster.) Und ich kann mich im Ergebnis nicht wirklich darüber freuen daß ich es hinbekommen habe...


MfG Janko Weber

  • 0
    Von Verfluchtnochmal_5987109 am So, 28. April 2019 um 01:48 #

    Was ist das für eine brunzdumme Frage?

    Um neuere Programmversionen zu bekommen und weil der Support irgendwann aufhört, der installer interessiert keine Sau und Spiele auch nicht

    • 0
      Von Janko Weber am So, 28. April 2019 um 22:09 #

      Neuere ProgrammVersionen installiere ich manuell wenn ich mit der derzeit verwendeten Version Probleme habe; und wenn nicht dann nicht: ich bin noch nicht dem Update-Wahn verfallen! Und was meint Support? Was soll ich damit?


      MfG Janko Weber

Pro-Linux
Unterstützer werden
Neue Nachrichten
Werbung