Login
Newsletter
Werbung

Thema: Sam Hartman neuer Debian-Projektleiter

3 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
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.

[
| Versenden | Drucken ]
  • 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.

    [
    | Versenden | Drucken ]
    • 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.

      [
      | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung