Die dunkle Jahreszeit ist Einbruchszeit - ein Anlass, auch die IT-Sicherheit unter die Lupe zu nehmen. In der Oktober-Ausgabe des IT-Administrator lesen Sie, ... (mehr)

Installation

Die Beispiele in diesem Artikel basieren alle auf einer Installation von Cuckoo-2.0 RC1 unter Fedora 23 und KVM/Libvirt. Das Archiv der Sandboxing-Software steht unter [1] zum Download zur Verfügung. Ist es ausgepackt, müssen Sie den Benutzer "cuckoo" anlegen und in die Gruppe "libvirt" aufnehmen. Da Cuckoo zu jedem Zeitpunkt in der Lage sein muss, eine virtuelle Maschine über das Libvirt-Framework zu erzeugen, sorgt die PolKit-Regel aus Listing 1 dafür, dass der Zugriff auf das Framework für sämtliche Mitglieder der Gruppe libvirt möglich ist.

Listing 1: PolKit-Regel für Zugriff auf libvirt-Framework



polkit.addRule(function(action, subject) {
    if (action.id == "org.libvirt.unix.
        manage" &&
                        subject.isInGroup("libvirt")){
                               return polkit.Result.YES;}
});

Im nächsten Schritt sollten Sie sich die Konfigurationsdateien im Ordner "conf/"" näher ansehen. Hiervon existieren eine ganze Reihe: "cuckoo.conf", "kvm.conf", "auxiliary.conf", "memory.conf", "processing.conf" und "reporting.conf".

Für einen ersten Test sind die Dateien "cuckoo.conf", "auxiliary.conf" und "kvm.conf" am wichtigsten. Kommt statt KVM/Libvirt eine andere Virtualisierungslösung zum Einsatz, stehen passende Konfigurationsdateien zur Verfügung, etwa für VMware und Virtualbox.

In der Datei "cuckoo.conf" sind grundlegende Einstellungen für den Betrieb von Cuckoo definiert. So lässt sich hier beispielsweise festlegen, welche Virtualisierungslösung zum Einsatz kommt (machinery = kvm), an welchen Host die Reporting- und Log-Dateien zu senden sind (ip) und ob beispielsweise ein Speicherabbild der virtuellen Maschine erzeugt werden soll, bevor diese beendet wird (memory_dump). Daneben existieren eine ganze Reihe weiterer Parameter, die allesamt sehr gut dokumentiert sind.

Kommt auf dem Management-System KVM/Libvirt zum Einsatz, müssen Sie als Nächstes die Einstellungen in der Datei "kvm.conf" anpassen. Hier ist unbedingt darauf zu achten, dass der Name (machines), das Label (label), die IP-Adresse (ip) und das eingesetzte Betriebssystem (platform) der virtuellen Maschine korrekt angegeben werden. Natürlich können an dieser Stelle durchaus mehrere Maschinen definiert werden, da sämtliche Anweisungen innerhalb einer eigenen Sektion für eben diese Maschine stehen. Existieren beispielsweise zwei virtuelle Maschinen fed01 und win01, so könnten die Einträge in der Datei "kvm.conf" wie in Listing 2 aussehen.

Listing 2: Beispielkonfiguration



machines = fed01, win01
interface = virbr0
[fed01]
label = fed01
platform = linux
ip = 192.168.122.10
[win01]
label = win01
platform = windows
ip = 192.168.122.110

Über die Datei "auxiliary.conf" lassen sich zusätzliche Services einbinden. So wird hier beispielsweise festgelegt, ob ein Dump des Netzwerkverkehrs der virtuellen Maschine erfolgen soll. Die Services werden dabei über ein eigenes Modul im Ordner "modules/auxiliary/" implementiert und lassen sich bei Bedarf erweitern. Generell gilt dies für sämtliche Konfigurationen in Cuckoo. Dieser Ansatz ist eine der großen Stärken der Software, die sich so leicht individuell anpassen lässt.

Die Datei "memory.conf" definiert, welche Art von Tests auf dem Speicherabbild der virtuellen Maschine durchgeführt werden soll. Beispielsweise können Sie hier festlegen, ob der Speicher nach bestimmten Kernel-Modulen durchsucht werden soll. Wie genau die Analyse von Malware-Samples aussehen soll, lässt sich in der Datei "processing.conf" bestimmen. Unter anderem ist hier eine Integration mit dem Online-Service VirusTotal möglich oder es lässt sich festlegen, dass basierend auf den Malware-Prozess-Speicherdumps dynamisch ein Python-Skript erzeugt wird, das sich zur weiteren Analyse in IDA Pro laden lässt. Welche Form die Cuckoo-Reports haben sollen, bestimmen schließlich die Einträge in der Datei "reporting.conf". Zur weiteren maschinellen Verarbeitung der Ergebnisse bietet sich das JSON-Format an. HTML-Reporte eignen sich prima, um sich einen Überblick über die Ergebnisse einer Analyse zu verschaffen. Wer Cuckoo eine MongoDB zur Seite stellt, kann auch das Django-basierte Webinterface benutzen, um auf die Ergebnisse zurückzugreifen.

Auch wenn noch keine virtuelle Maschine zur Analyse der Malware-Samples erzeugt wurde, so sollte nach diesen Einstellungen Cuckoo bereits starten. Der Aufruf von »./cuckoo.py« aus dem Installationsverzeichnis heraus begrüßt den User mit einer hübschen ASCII-Art (Bild 2). Viel machen können Sie zu diesem Zeitpunkt noch nicht, da im nächsten Schritt noch die virtuellen Maschinen und deren Snapshots zu erzeugen sind, die Cuckoo als Grundlage zur Analyse der eingereichten Malware-Samples verwendet.

Bild 2: Nach der Willkommensmeldung mit jeweils wechselnder ASCII-Art wartet Cuckoo auf eingehende Malware-Analyse-Jobs.

Maschinen-Template erzeugen

Cuckoo bietet keine eigene Prozedur zum Erzeugen von virtuellen Maschinen-Templates an, stattdessen setzt es auf vorhandene Tools und Mechanismen. In diesem Artikel kommt eine einzelne virtuelle Maschine auf Basis von Fedora zum Einsatz. Die Installation kann mit dem grafischen Tool virt-manager oder auf der Shell mittels virt-install erfolgen. Die Anbindung an das Host-System, auf dem das Cuckoo Management-Framework läuft, ist dabei über eine Bridge geregelt. KVM/Libvirt verwendet den privaten IP-Addressraum 192.168.122.0/24, wobei die Adresse 192.168.122.1 dem Host-System zugewiesen wird. Festplatten sollten innerhalb der virtuellen Maschine entweder als LVM- oder QCOW2-Volumes angelegt werden, da sich ansonsten keine Snapshots von der Maschine erzeugen lassen. Eine Beschreibung der kompletten Installation würde den Rahmen dieses Artikels sprengen, weshalb wir an dieser Stelle auf bereits vorhandene Installationsanleitungen verweisen [4]. Es ist zusätzlich darauf zu achten, dass innerhalb der virtuellen Maschine Python 2.7 installiert ist, da die Cuckoo Analyse-Software diese Version voraussetzt.

Hat die Installation der Maschine geklappt, sollten Sie die Konfigurationsdatei "kvm.conf" auf dem Cuckoo-Host-System mit den korrekten Daten der Maschine aktualisieren. Wie bereits erwähnt, zählen hierzu die IP-Adresse, der Name und auch das Label des virtuellen Systems. Schließlich müssen Sie den Cuckoo-Agent auf die Maschine kopieren. Er liegt auf dem Host-System im Cuckoo-Installationsorder "agent/" und heisst "agent.py".

Mit Hilfe des ebenfalls in diesem Ordner vorhandenen Shell-Skripts lässt sich der Agent innerhalb der virtuellen Maschine starten. In welchem Order der Agent dort abgelegt wird, spielt tatsächlich keine Rolle. Der Agent implementiert einen XMLRPC-Server, der auf eingehende Verbindungen vom Host-System wartet. Über diese Verbindungen werden dann die Malware-Samples an das System gesendet. Nach einem Neustart der virtuellen Maschine sollte der Agent au­to­matisch starten. Dies ist unbedingt sicherzustellen, bevor im nächsten Schritt ein Snapshot der Maschine angelegt wird. Einen solchen Snapshot erzeugen Sie mit den Libvirt-eigenen Tools:

# virsh snapshot-create fed01
# virsh snapshot-list fed01
Name                  Creation Time             State
----------------------------------------
1469460006     2016-07-25 [...]         running

Um Problemen vorzubeugen, sollte immer nur ein Snapshot pro virtueller Maschine existieren. Nach dem Anlegen des Snap-shots kann die virtuelle Maschine ausgeschaltet werden. Cuckoo greift von nun an auf das Snapshot des Systems zurück, sobald ein Sample empfangen wird und innerhalb einer virtuellen System-Instanz zu analysieren ist.

An dieser Stelle sei noch erwähnt, dass auch bereits vorhandene virtuelle Systeme als Grundlage für Cuckoo dienen können. Wer bereits ein solches System vorliegen hat und lediglich den Disk-Typen ändern muss, kann ein solches Image leicht mit dem folgenden Befehl konvertieren:

# qemu-img convert -O qcow2 fed01.raw fed01.qcow2

Danach müssen Sie in der XML-Definition der virtuellen Maschine den neuen Disk-Typ (<driver name='qemu' type='qcow2'/> und den Speicherort (<source file='/var/lib/libvirt/images/fed01. qcow2'/>) der Image-Datei angeben. Am einfachsten gelingt dies über den folgenden Befehl:

# virsh edit fed01

Das Label "fed01" ersetzen Sie hier wieder durch das Label ihrer eigenen virtuellen Maschine. Speichern Sie die Datei und starten im Anschluss das virtuelle System, sollte im Anschluss das Anlegen eines Snapshots gelingen.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2020