Mich fröstelt's gerade ein bisserl... [Update]

12.12.2015 16:47 von /cbx, derzeit 6.37836 Kommentare

Send to Kindle

…und das natürlich nicht aufgrund der enorm winterlichen Temperaturen her bei uns.

Nein, es geht viel mehr um ein Thema, das derzeit geradezu inflationär in der “IT-Szene” herumspukt – so inflationär, dass sich sogar Heise zu einem mittelschweren Captain Obvious hinreißen lässt. Ist die Geschichte von Amok laufenden Verschlüsselungstrojanern im Firmennetz an sich schon gruslig genug, so bereiten mir die
in den Forenbeiträgen zwischen den obligaten Trollposts versteckten Praxisberichte durchaus ernste Bauchschmerzen.

Im G’schäft betreiben wir derzeit einen Server, der zentral und für alle rund 2TBytes an Daten zur Verfügung stellt – darunter alle Konstruktionsdaten, Spezifikationen, Korrespondenz und Maschinendokumentation (i.e. Bilder, Serviceberichte usw) – so wie man das in einer 10 Mann-Klitsche halt so macht. Der Großteil unserer Workstations ist relativ sehr sicher, weil dort nur unser eigenes ziemlich gut gewartetes Gentoo Linux Derivat läuft, aber zusätzlich haben wir da zwei gigantische Scheunentore offen.

Einerseits müssen die beiden CAD-Workstations unter Windows 7 laufen (→SolidWorks) und andererseits haben auch wir das allseits beliebte BYOD adoptiert, sodass quasi jeder seinen verranzten Laptop bei uns ins Netzwerk bringen kann. Und sobald der dann Zugriff auf unser Share-Laufwerk hat, ist der GAU mit hunderttausenden unknackbar verschlüsselten Unternehmensdaten nur mehr einen unüberlegten Mausklick entfernt.

Hinzu kommt, dass ich aus diversen Gründen (Kosten, Bandbreite, Faulheit, Inkompetenz – nicht notwendigerweise in dieser Reihenfolge) zwar eine örtlich hochgradig diverse Datensicherung (mit 3 Standorten) betreibe, aber nur eine ziemlich schwache (hm, eher “nicht vorhandene”) Versionierung.

Es gibt zwei tägliche, nondestruktive (rsync-) Backups auf ferne Rechner, die selbst keine Verzeichnise exportieren und zumindest den sehr häufigen Fall “Ich habe da versehentlich einen Ordner mit 100MBytes Baugruppen gelöscht” erschlagen. Dann gibt es noch eine tägliche Spiegelung des RAID im Hauptserver und eine externe Festplatte, direkt am Server, die ich monatlich einschalte und mit alternierenden Backups befülle. Keine dieser Methoden allerdings wäre eine Hilfe, wenn ein Bösewicht massenhaft Dateien verschlüsseln würde ohne sie dabei auch (wie derzeit üblich) umzubenennen (→Verbesserungsvorschlag an den geneigten Blackhat).

Weil mich das in den letzen Nächten echt hat schlecht schlafen lassen, bin ich nun gerade dabei, zumindest ein paar erste Notmaßnahmen zu ergreifen, um den GAU etwas weniger wahrscheinlich zu machen.

Weil ich jetzt nicht mal eben auf die Schnelle eine fein granulierte Armada unterschiedlicher Server-Exporte (“Laufwerke”) erzeugen kann, muss eine Interimslösung (woraus dann üblicherweise ein so genanntes “permanentes Provisorium” wird…) her. Also – genau genommen könnte ich an einem normalen Abend die Client- und Serverseite dieser Laufwerksaufdröselung locker stemmen – allein die Aufteilung und insbesondere die organisatorischen Implikationen wären jedoch wohl ein mittlerer Albtraum. Ja – auch in einer 10 Mann Bude. Wahrscheinlich ist das dort sogar noch schwieriger, weil wir alle über ein sehr breit gestreutes Kompetenzspektrum verfügen und damit verdammt viele Daten im Zugriff haben müssen.

Die beiden nondestruktiven Backups würden bei der bisherigen Vorgehensweise der Schadprogramme, die verschlüsselten Daten umzubenennen die Originale am Backupmedium intakt lassen. Die Spiegelung allerdings wäre natürlich hinüber. Außerdem bleibt noch die Aufgabe zu lösen, das Problem selbst zu verhindern oder – wenn’s dann doch pasiert – zu erkennen.

Das geschieht ab Montag nun dadurch, dass alle außer unseren Konstrukteuren per SMB nur mehr ein einziges Verzeichnis zu sehen bekommen – nämlich das (bei uns) legendäre /share/TEMP, das jeden Samstag gelöscht wird und als zentrale Austauschplattform für Daten des täglichen Gebrauchs dient. Damit kann per Definitionem ein infizierter BYOD-Rechner nur mehr die transienten Daten einer Woche vernichten.

Sollte hingegen einer unserer offiziellen Rechner krank werden, so hoffe ich darauf, dass die Bösewichte hinter der Schadsoftware ihr wenigstens genug schwäbische Tugend mitgegeben haben, sodass die im Falle eines Falles auch ordentliche Mengen an Daten in kurzer Zeit verschlüsselt. Dann nämlich greift meine zweite Hürde, die vor dem Backup prüft, wie viele Files sich geändert haben. An einem normalen Arbeitstag sind das bei uns so zwischen 5000 und 15000 (sic!). Wenn sich mehr als 25000 Files geändert haben sollten, wird das Backup nicht durchgeführt und die IT (das wäre dann ich) benachrichtigt. Dann kann ich ja immer noch zu Fuß und per Hand nach dem Rechten sehen.

Damit versuche ich nun, meinen Schönheitsschlaf bis Weihnachten sicherzustellen, Und dann muss ich mir wohl etwas gründlichere Gedanken machen…

Update: Weil einige Informatiker hier in den Kommentaren einen sehr nahe liegenden Tipp hinterlassen haben, wie man verschlüsselte Daten erkennen könnte, habe ich mal schnell etwas zusammengehackt, wie man den Kompressionstest automatisieren könnte (das file /tmp/stats.txt wird von “rsync -i …” generiert):

#!/bin/bash
cat /tmp/stats.txt |grep ">f"|cut -c 13- > /tmp/files_changed.txt
IFS=$'\n'
for fname in $(cat /tmp/files_changed.txt)
do
  rawsize=`stat --printf="%s" "/share/$fname"`
  if [ $rawsize -gt 1024 ]
  then
    if [ $rawsize -lt 26214400 ]
    then
      echo -n "File $fname: raw $rawsize "
      cat "/share/$fname" | gzip > /tmp/compressed.gz
      compsize=`stat --printf="%s" /tmp/compressed.gz`
      echo "compressed: $compsize"
      if [ $compsize -gt $rawsize ]
      then
        echo "WARNING! $fname does not compress!"
      fi
    else
      echo "File $fname: too big"
    fi
  else
    echo "File $fname: too small"
  fi
done

Was dann passierte, ist der klassische Unterschied zwischen Theorie und Praxis:

File amadyne.ics.bz2: raw 75868 compressed: 75770
File encrypted.des3: raw 714424 compressed: 714552
WARNING! encrypted.des3 does not compress!
File Lieferantenlieferscheine/2015/Doll2_14-12-15.pdf: raw 558181 compressed: 554163
File kalender/amadyne.ics: raw 829311 compressed: 117262
File kalender/amadyne.ics~: raw 829311 compressed: 117255
File EMU/0xx_-_BASIS/ZB_EMU-0xx-xxx-05_BASIS.easm: raw 10149270 compressed: 10150162
WARNING! EMU/0xx_-_BASIS/ZB_EMU-0xx-xxx-05_BASIS.easm does not compress!
File 040_-_AXIS/ZB_EMU-040-xxx-02_AXIS.easm: raw 3022878 compressed: 3023175
WARNING! 040_-_AXIS/ZB_EMU-040-xxx-02_AXIS.easm does not compress!
File FESTO/DGC-8/FESTE_DGC-8-60-KF-YSR-A.sldasm: raw 428485 compressed: 413248

Bei einer winzigen Stichprobe treten schon zwei false positives auf. Und so wirklich verwunderlich ist das eigentlich nicht. Einerseits weil die meisten Applikationsdaten inzwischen schon im Original komprimiert sind (→false positive) und andererseits, weil schon ein mittelgroßer Header vor dem Chiffrat (z.B. zur Anzeige der Drohmeldung) genügt um es komprimierbar zu machen.

Tja, schade eigentlich…

/cbx, Kategorie: Netz Dschungelcamp - Linux LeidenSchaf(f)t

 

Eigener Senf dazu?

  1. The Angry Nerd gab am 12. Dezember 2015, 20:28 folgenden Senf dazu:

    An der Stelle möchte ich gerne nochmal die Werbetrommel für ZFS rühren. Damit ist die Versionierung nämlich kinderleicht. (Außerdem löst ZFS das Welt-Hunger-Problem und wirkt gegen den IS. Und seit ich ZFS benutze verbraucht auch mein Auto weniger Benzin!)

    Danach möchte ich mich darüber beklagen, dass mir die Zeit dazu fehlt, aus dem Folgenden einen ordentlichen Blogartikel zu zimmern. Also rotze ich es Dir in die Kommentarspalte…

    Die Frage ist, was genau Du erkennen willst. Was unterscheidet eine vom Kryptotrojaner durchgenudelte Datei von einer normalen Datei?
    Es gibt genau einen Kernunterschied, der in der Methode selbst liegt: die eine Datei ist verschlüsselt, die andere nicht. Umbenennen, Datum ändern etc sind alles Dinge, die der Trojaner machen kann – oder auch nicht.

    Ja gut, jetzt klatschst Du Dir an die Stirn und sagst mir, dass man eben doch merkt, dass ich schwatzhafte Schwester der Informatik studiert habe und Du DAFÜR nun wirklich keinen “Consultant” brauchst. Aber gut…

    Was folgt nun aus der Tatsache, dass die Datei verschlüsselt ist – außer, dass Du sie nicht mehr lesen kannst?
    Eine Eigenschaft praktisch jeder ansatzweise tauglichen Verschlüsselung, die ich kenne, ist, dass das Chiffrat pseudozufällig aussieht. Und Kompressionsalgorithmen können damit überhaupt nicht umgehen. Typischerweise ist die komprimierte Datei marginal groesser (!) als die pseudozufällige Ausgangsdatei. Normale Dateien hingegen lassen sich praktisch immer noch ein bisschen komprimieren. Selbst JPEGs, MP3s und MP4s haben, einmal durch bspw. Gzip gejagt, eine minimal kleinere Größe.

    Man probiere es aus:
    - Wahllos Officedokumente, Musik und Tittenbildchen wohinkopieren
    - Alles einmal mit bspw. Gzip komprimieren
    - Dann Ausgangsdaten verschlüsseln (Für alle, die nicht jeden Artikel hier gelesen haben: openssl aes-128-cbc -salt -in tittenbild.jpg -out tittenbild.jpg.enc -k TittenAlsPasswort)
    - Dann die verschlüsselten Sachen nochmal komprimieren.

    Ergebnis:
    Die Ausgangsdateien sind durch Kompression vielleicht nicht all zu viel, aber messbar kleiner geworden. Die verschlüsselten Ausgangsdaten sind durch die Kompression größer geworden!

    Man könnte natürlich auch wesentlich kürzer proklamieren, dass die Inkompressibilität mit den Standardalgorithmen eine notwendige Bedingung einer irgendwie tauglichen Verschlüsselung ist.
    Sie ist aber natürlich nicht hinreichend.

    Trotzdem könntest Du Dir auf der Basis etwas bauen, was die typische Kryptotrojanerinfektion sehr schnell erkennt, wenn maximal komprimierte oder verschlüsselte Dateien auf den Fileservern die Ausnahme sind. Man müsste nur die den Tag über (oder in der letzten Stunde) geänderten Dateien versuchen zu komprimieren und Alarm schlagen, wenn irgendeine der normalerweise verwendeten Typen, Officekram, Sourcecode, CAD Files, sich gar kein bisschen komprimieren lässt. Oder vielleicht mehr als 5 Stück davon.
    Man kann das natürlich auch nur mit einer zufälligen Auswahl tun, wenn der Server kaum Rechenzeit über hat.

    Das ist natürlich alles andere als eine perfekte Lösung. Man müsste bspw. bei Archiven überlegen, was man tut. Wenn man bspw. den Inhalt auflisten kann, sind die nicht verschlüsselt, und so viele verschiedene Typen dürftest du ja nicht auf dem Fileserver haben. Und verschlüsselte Dateien? Ja nun, ähm, keine perfekte Lösung…
    Mein Vorschlag dürfte aber besser sein, als sich auf Annahmen (“wird schon ein Schwabe programmiert haben”) zu verlassen. Zumindest, wenn es nicht nur von, von außen nicht durch Pfad oder Namen als solche zu erkennenden, verschlüsselten Dateien auf Deinen Fileservern wimmelt.

    /cbx meint dazu:

    Schade. Ich hätte darauf wetten sollen, dass von Dir genau so ein Kommentar kommt. Ach ja, wie viele Hundert GB RAM brauche ich denn für ein 5TB ZFS Volume? ;-)

    Erst mal vielen Dank. Ich werde bei einer guten Flasche Wein darüber nachdenken...

  2. The Angry Nerd gab am 13. Dezember 2015, 21:13 folgenden Senf dazu:

    Ahja, die alte Mär vom RAM Hunger. Wenn man keine Deduplikation braucht, wird das Thema viel heißer gekocht, als gegessen. Natürlich ist eine genaue Antwort schwierig. Dateianzahl, Organisation der Platten, Zugriffsmuster, Größe des aktiven Sets, geforderte IOPS, L2ARC, Farbe der Schuhe des Geschäftsführers…

    Die Faustregel sagt 1GB pro 1TB, aber die ist sehr, sehr dehnbar. Andererseits kostet RAM ja fast nichts. Ein Hunni (netto) reicht ja für 16GB registered ECC.

    Und ja, ich weiß, dass Du DAS vermutlich NICHT hören wolltest :p

    Genieß die Flasche Wein und die Feiertage :)

    /cbx meint dazu:

    Gut, 16GB hätte ich ja schon drin - das wär's also nicht mal. Was mich da eher etwas feucht werden lässt (an den Handflächen...), ist die Tatsache, dass das immer noch ein wackliges externes Kernelmodul ist. Mir hat schon mal ein externer Netzwerktreiber (von Realtek) mit chirurgischer Präzision 100% der empfangenen Daten per falsch initialisiertem DMA in Daten in Computerkotze verwandelt. Und das hat durchaus ein paar Stunde gedauert, bis das aufgefallen ist...

    Sogar das alt-ehrwürdige XFS (das ich derzeit einsetze) ist mir da nicht immer geheuer. Ich glaube, ich habe da eh schon mal was darüber geschrieben - in diesem Fall ist mir ein grob bekanntes Übel doch lieber als ein mächtiger Totschläger, den ich hinten und vorne nicht verstehe. Auch, weil ich in unserer Bude ja nicht ausschließlich IT-Bastler bin...

  3. Alex gab am 13. Dezember 2015, 23:05 folgenden Senf dazu:

    ZFS war auch meine erste Idee. Sooo viel RAM braucht das gar nicht, wenn man kein Dedupe benutzt. Bei mir laufen zwei 3TB Mirrors (also vier Platten) mit 8GB RAM bestens.
    Die Idee mit der Kompressibilität finde ich gut. Vielleicht könnte man ja in jedes Verzeichnis (keine Ahnung ob ihr mit vielen Verzeichnissen oder vielen Dateien je Verzeichnis arbeitet) eine Art Köder-Datei ablegen, deren Komprimierbarkeit man genau kennt und die man dann recht zuverlässig testen kann.

    PS: Ich kann schwere, satte, rote Cuvées von der Rhone sehr empfehlen (z.B. GMSs) :)

    /cbx meint dazu:

    Die Idee mit der Kompression ist durchaus reizvoll, aber auch recht teuer. Ich müsste also ein Skript an den Output von rsync flanschen, das nur die geänderten Files in einem definierten Größenbereich checkt und dann ab einer gewissen Schwelle Alarm schlägt. Sonst würde ich wohl nur den Serverraum, unnötig heizen. Mal sehen, ob mich das in den nächsten Tagen mal anspringt...

    Ich habe noch einige Cote du Rhone im Keller, die letzt gerade ihre Mindestlagerzeit erreicht haben. Ansonsten aber kann ich mich auch auf einen guten Chianti Classico (z.B. Villa Antinori) oder einen Blaufränkisch DAC von Rennhofer freuen.

    Prost!

  4. The Angry Nerd gab am 14. Dezember 2015, 23:37 folgenden Senf dazu:

    Ja nun, dass es nicht mit einem Zweizeiler getan sein würde war mir klar. An irgendwelche (komprimierten) Firmwarebinaries hatte ich auch explizit gedacht.

    Wenn das mein Problem wäre, dann würde ich das Skript mal über Nacht laufen lassen und für jedes File eine Zeile in einem Log erzeugen, in dem alles mögliche drin steht.
    Dann würde ich das in R importieren und schauen, bei welchen Dateien das im Moment anschlägt. Wenn abzusehen ist, dass man zwanzig Typen von Endungen ignorieren muss (und dann noch Dateien übrig hat) und alle false positives los wäre, dann wäre die ganze Sache einen Versuch wert.

    Und was einen eventuellen Header angeht:
    Natürlich hast Du hier ein echtes Problem, wenn die Methode üblich wird. Man kann auch einfach einen Batzen Nullen hinten dran hängen. Selbes Ergebnis und der Kompressionsfaktor wird einstellbar.
    Man kann auch die Positivprobe sabotieren. Wenn Du jede Datei auf Validität prüfst, indem Du bspw. die ersten paar Bytes anschaust oder sie programmatisch öffnen lässt, wird man sicher einen Weg finden, für bspw. die typischen Officeformate, Folgendes zu tun:
    Man schreibt ein leeres, valides Dokument, hängt den Payload dran und füllt mit Nullen so weit auf, dass gzip für die Standardkompression denselben Faktor liefert. Statt einfach Nullen könnte man natürlich auch…

    Unterm Strich kann man das Problem nicht trivial und generisch lösen. Auf der Ebene der Beobachtung von außen, gilt, dass man “ahead of the curve” bleiben muss. Und so weit ich weiß, greifen die bisherigen Trojaner recht gezielt bestimmte Dateiformate an.

    Die Variante mit dem Köder ist auch nicht schlecht, hat aber natürlich eigene Nachteile. Wenn einer der Trojaner mal so schlau wird, zuerst alte Dateien zu verschlüsseln, oder bei N Monaten vor heute anfängt, musst Du hoffen, dass der Köder der richtige war. Und natürlich sieht jeder die Dinger in den Verzeichnissen rumliegen, was nicht so hübsch ist.

    Wenn’s einfach wäre, wäre es kein Problem mehr…

    Deine Bedenken hinsichtlich ZFS, sein Dasein als Kernelmodul etc:
    Ja. XFS ist da erprobter und die defensivere Wahl. Ich verstehe auch durchaus, warum Du nicht einfach mit den Schultern zuckst und halt ‘ne ZFS Büchse aufsetzt. Man will ja wenigstens die Illusion haben halbwegs zu verstehen, was man da tut. Und wenn das FS mehr kann als manche Dokumentenversionierung, wird das alles sehr schnell sehr komplex.
    Es ist halt wie mit Designerdrogen: Der Flash ist total krass. Bei Bier ist er das nicht, dafür weiß man da, dass man das sehr lange trinken kann und kann abschätzen, wie groß die Schadwirkung ist.

    /cbx meint dazu:

    Zum Kompressionstest: Wenn ich nicht vermutet hätte, dass das nicht so billig zu kriegen ist wie das in Deinem Kommentar klang, hätte ich diesen Kurztest ja gar nicht gemacht. Mir ging es nur darum, ein Gefühl zu bekommen, wie nah man da um welchen Preis der Wahrheit kommen kann. Und das Ergebnis war. Zu teuer / zu unsicher.

    Zu ZFS: Danke für die Unterstützung. Sollte es hier mal wieder ein bisserl langweiliger werden, werde ich mal eine toybox damit installieren. Nur so kann man's lernen...

  5. The Angry Nerd gab am 16. Dezember 2015, 02:49 folgenden Senf dazu:

    Zu ZFS:
    Bitte. Wenn sich Fragen auftun, schreib ‘ne Mail.

    /cbx meint dazu:

    Danke für das Angebot. Wenn ich mich traue, damit anzufangen, wirst Du es sicher als Zweiter erfahren...

  6. bitwuzler gab am 14. Januar 2016, 15:09 folgenden Senf dazu:

    Wir benutzen für Backups von Linux-Server seit Jahr(zehnt)en rsnapshot.
    Du bekommst damit sehr einfach ein platzsparendes Backup-Archiv (benutzt rsync mit Hardlinks) ohne groß etwas installieren zu müssen.
    Auf ein paar neueren Debian-Servern haben wir alternativ auch ZFS mit Snapshots laufen, ist natürlich schöner/schneller/konsistenter …
    Installation dank ZFS on Linux nun auch kein Beinbruch mehr und wirklich ultrastabil.

    /cbx meint dazu:

    Danke für die Anregung. Rsnapshot werde ich mir mal ansehen. Bisher hatte ich da nicht die geeignete Backup-Hardware, aber das hat sich inzwischen geändert. Und ZFS - Das würde ich wohl vorher für ein halbes Jahr auf unserem "Medienserver" probelaufen lassen...

Kommentarfunktion für diesen Artikel geschlossen.