Kali-VM-Image-Builder

Dies ist das Build-Skript zum Erstellen der Images für Kali-Linux-Virtual Machine (VM).

Derzeit sind zwei Build-Methoden möglich:

• build.sh - direkt von deinem Rechner aus bauen
• build-in-container.sh - aus einem Container heraus bauen (Docker oder Podman)

In beiden Fällen findet der Build tatsächlich in einer virtuellen Maschine statt, die vom Build-Tool debos on-the-fly erzeugt wird. Debos verwendet im Hintergrund fakemachine, das wiederum auf QEMU/KVM basiert.

Voraussetzungen

Stelle sicher, dass das Git-Repository lokal geklont ist:

$ sudo apt install -y git
$ git clone https://gitlab.com/kalilinux/build-scripts/kali-vm.git
$ cd kali-vm/

Benutzereinrichtung

Aufgrund der Anforderungen von QEMU/KVM musst du Mitglied der Gruppe kvm sein. Das kannst du wie folgt überprüfen:

$ # Not apart of the group
$ grep kvm /etc/group
kvm:x:104:
$
$ # In the group
$ grep kvm /etc/group
kvm:x:104:kali

Wenn dein Benutzername nicht in der zurückgegebenen Zeile erscheint, bist du nicht in der Gruppe. Du musst dich dann selbst zur Gruppe kvm hinzufügen:

$ sudo adduser $USER kvm

Melde dich danach ab und wieder an, damit die Änderung wirksam wird.

Build vom Host aus

Wenn du direkt von deinem Rechner aus baust und build.sh verwendest, musst du debos installieren:

$ sudo apt install -y 7zip debos dosfstools qemu-utils zerofree

Verwende dann das Skript build.sh, um direkt auf deinem Rechner ein VM-Image zu erstellen.

Build aus einem Container heraus

Wenn du lieber aus einem Container heraus bauen möchtest, musst du auf deinem Rechner entweder docker oder podman installieren und konfigurieren. Verwende dann das Skript build-in-container.sh, um ein Image zu erstellen.

build-in-container.sh ist lediglich ein Wrapper um build.sh. Es erkennt, welche OCI-konforme Container-Engine verwendet werden soll, kümmert sich darum, das Container-Image zu erstellen, falls es fehlt, und startet schließlich den Container, um den Build darin auszuführen.

Bei docker muss der Benutzer – genau wie oben bei KVM – zur Docker-Gruppe hinzugefügt werden, oder man verwendet das Root-Konto (z. B. $ sudo ./build-in-container.sh). podman wurde sowohl im Rootful-Betrieb (z. B. $ sudo ./build-in-container.sh) als auch im Rootless-Betrieb (z. B. $ ./build-in-container.sh) getestet.

Ein Image erstellen

Verwende je nach Vorliebe entweder build.sh oder build-in-container.sh. Ab hier verwenden wir der Kürze halber build.sh.

Beispiele

Der beste Ausgangspunkt ist, wie immer, die Nutzungsmeldung:

$ ./build.sh -h
Usage: build.sh <options> [-- <debos options>]

Build a Kali Linux VM image

Build options:
  -a ARCH     Build an image for this architecture, default: amd64
              Supported values: amd64
  -b BRANCH   Kali branch used to build the image, default: kali-rolling
              Supported values: kali-dev kali-last-snapshot kali-rolling
  -f FORMAT   Format to export the image to, default depends on the VARIANT
              Supported values: hyperv ova ovf qemu raw vagrant virtualbox vmware
  -k          Keep raw disk image and other intermediary build artifacts
  -m MIRROR   Mirror used to build the image, default: http://http.kali.org/kali
  -r ROOTFS   rootfs to use to build the image, default: none
  -s SIZE     Size of the disk image in GB, default: 86
  -v VARIANT  Variant of image to build (see below for details), default: generic
              Supported values: generic hyperv qemu rootfs virtualbox vmware
  -x VERSION  What to name the image release as, default: rolling
  -z          Zip images and metadata files after the build

Customization options:
  -D DESKTOP  Desktop environment installed in the image, default: xfce
              Supported values: e17 gnome i3 kde lxde mate xfce none
  -H HOSTNAME Set system host name, default: kali
  -K KEYBOARD Set keyboard layout, default: us
              Refer to the README.md for more details
  -L LOCALE   Set locale, default: en_US.UTF-8
  -P PACKAGES Install extra packages (comma/space separated list)
  -T TOOLSET  The selection of tools to include in the image, default: default
              Supported values: default everything headless large none
  -U USERPASS Username and password, separated by a colon, default: kali:kali
  -Z TIMEZONE Set timezone, default: America/New_York

The different variants of images are:
  generic     Image with all virtualization support pre-installed, default format: raw
  hyperv      Image pre-configured for Hyper-V "Enhanced Session Mode", default format: hyperv
  qemu        Image with QEMU and SPICE guest agents pre-installed, default format: qemu
  rootfs      Not an image, a root filesystem (no bootloader/kernel), packed in a .tar.gz
  virtualbox  Image with VirtualBox guest utilities pre-installed, default format: virtualbox
  vmware      Image with Open VM Tools pre-installed, default format: vmware

The different formats are:
  hyperv      VHDX disk image, powershell install scripts
  ova         streamOptimized VMDK disk image, OVF metadata file, packed in a OVA archive
  ovf         monolithicSparse VMDK disk image, OVF metadata file
  qemu        QCOW2 disk image, no metadata
  raw         sparse disk image, no metadata
  virtualbox  VDI disk image, .vbox metadata file
  vmware      2GbMaxExtentSparse VMDK disk image, VMX metadata file

Supported environment variables:
  http_proxy  HTTP proxy URL, refer to the README.md for more details

Most useful debos options:
  --artifactdir DIR   Set artifact directory, default: images
  --memory, -m  SIZE  Limit amount of memory to build VM in GB, default: 4G
  --scratchsize SIZE  Limit amount of HDD to build VM in GB, default: 45G
  --debug-shell       Get a shell on the VM
  --help, -h          See the complete list of options for debos

Refer to the README.md for examples

Die Standardoptionen erstellen ein Kali-rolling-Image mit Standard-Desktop und Standard-Toolset für die Architektur AMD64.

Dies ist ein Raw-Disk-Image, also ein einfaches binäres Abbild des Datenträgers (das mit QEMU gestartet werden kann).

Beispiel:

$ ./build.sh

Um ein Kali-Linux-Image zu erstellen, das auf VMware zugeschnitten ist. Das bedeutet, dass die Open VM Tools vorinstalliert sind und das erzeugte Image unverändert in VMware importiert werden kann.

Außerdem werden wir es aus der letzten stabilen Version von Kali erstellen und GNOME als Desktop-Umgebung verwenden, anstelle des üblichen Standard-Desktops Xfce:

./build.sh -v vmware -b kali-last-snapshot -D gnome

Um ein Kali-Linux-Image zu erstellen, das für VirtualBox konzipiert ist. Es enthält die vorinstallierten VirtualBox-Gasterweiterungen, und das Image kann unverändert in VirtualBox importiert werden.

Darüber hinaus möchten wir eine virtuelle Festplatte mit 150 GB, und wir werden die Tool-Auswahl „everything“ installieren:

./build.sh -v virtualbox -s 150 -S everything

Um ein schlankes Kali-Image zu erstellen, das keine Desktop-Umgebung und kein Standard-Toolset enthält. Dies ist ein generisches Image, das Unterstützung für die meisten gängigen VM-Engines mitbringt. Wir exportieren es in das OVA-Format, das sich sowohl für VMware als auch für VirtualBox eignet.

Mit der Option -P kannst du zusätzliche Pakete installieren. Du kannst die Option entweder mehrfach verwenden (z. B. -P pkg1 -P pkg2 ...), einen durch Komma/Leerzeichen getrennten Wert angeben (z. B. -P "pkg1,pkg2, pkg3 pkg4") oder beides kombinieren. Installieren wir außerdem das Paket metasploit-framework:

./build.sh -v generic -f ova -D headless -P metasploit-framework

Beim Erstellen mehrerer Images kann es praktischer (und schneller) sein, den Build in zwei Teile aufzuteilen: Zuerst ein Rootfs erstellen und dann die Images bauen, indem dieses Rootfs als Ausgangspunkt wiederverwendet wird.

Im folgenden Beispiel haben wir zuerst ein kali-rolling-Rootfs erstellt und anschließend eine Reihe von Vagrant-Images gebaut:

./build.sh -b kali-rolling -v rootfs
./build.sh -r images/rootfs-rolling-amd64.tar.gz -f vagrant -v hyperv
./build.sh -r images/rootfs-rolling-amd64.tar.gz -f vagrant -v qemu
./build.sh -r images/rootfs-rolling-amd64.tar.gz -f vagrant -v virtualbox
./build.sh -r images/rootfs-rolling-amd64.tar.gz -f vagrant -v vmware

Um die keyboard settings festzulegen, verwende die Option -K. Die Einstellung hat die Form <layouts>/<models>/<variants>/<options>. Jede Einstellung kann weggelassen werden (in diesem Fall wird der Standardwert verwendet) oder mehrere, durch Kommas getrennte Werte enthalten. Im einfachsten Fall möchtest du vielleicht nur das Tastaturlayout ändern. Du würdest also us für ein US-Tastaturlayout, de für ein deutsches Tastaturlayout usw. setzen. Ausführlichere Erklärungen und Beispiele findest du auf der Manual-Seite keyboard(5). Eine Liste der unterstützten Werte findest du in der Datei /usr/share/X11/xkb/rules/xorg.lst (bereitgestellt vom Paket xkb-data auf Debian und Debian-ähnlichen Systemen). Diese Datei enthält verschiedene Abschnitte (! layout, ! model, !variant und !option), in denen die möglichen Werte für jede Einstellung aufgelistet sind. Du kannst auch mit prüfen, was auf deinem System konfiguriert ist. Es gibt außerdem die Abkürzung , um das Host-System zu übernehmen (d. h. das, was in der Datei gesetzt ist).

Um die locale festzulegen, verwende die Option -L. Wähle einen Wert aus der 1. Spalte von /usr/share/i18n/SUPPORTED, oder prüfe mit grep -v ^# /etc/locale.gen, was auf deinem System konfiguriert ist, oder verwende einfach echo $LANG. Es gibt auch die Abkürzung -L same, um das Host-System zu übernehmen.

Um die timezone festzulegen, verwende die Option -Z. Sieh in /usr/share/zoneinfo nach und wähle ein Verzeichnis und ein Unterverzeichnis. Im Zweifelsfall führe tzselect aus, um dich führen zu lassen, oder schau mit realpath /etc/localtime nach, was auf deinem System konfiguriert ist. Es gibt auch die Abkürzung -Z same, um das Host-System zu übernehmen.

Um Name und Passwort für den unprivilegierten Benutzer festzulegen, verwende die Option -U. Der Wert ist eine einzelne Zeichenkette, und der Doppelpunkt : trennt den Benutzernamen vom Passwort.

Hier bauen wir ein Kali-Image und konfigurieren es so, dass es dem Host-System entspricht: gleiche locale, gleiche timezone und gleicher Benutzername (mit dem Passwort password):

./build.sh -K same -L same -Z same -U $USER:password

Varianten und Formate

Je nachdem, in welcher VM-Engine du das Kali-Image ausführen möchtest, können verschiedene Image-Varianten erstellt werden. Die VARIANT definiert hauptsächlich, welches zusätzliche Paket in das Image installiert wird, um Unterstützung für eine bestimmte VM-Engine hinzuzufügen. Das FORMAT definiert dann das Format der virtuellen Festplatte und welche zusätzlichen Metadaten-Dateien erzeugt werden.

Ist das Format nicht gesetzt (Option -f), wird es automatisch entsprechend der Variante (Option -v) festgelegt. Nicht jede Kombination aus Variante und Format ist sinnvoll. Die folgende Tabelle fasst daher die gängigsten Kombinationen zusammen.

Die generic-Images werden mit vorinstallierten Virtualisierungsunterstützungspaketen für QEMU, VirtualBox und VMware ausgeliefert – daher der Name „generic“. Andere Images, die auf eine bestimmte VM-Engine ausgerichtet sind, enthalten dagegen nur Unterstützung für genau diese Virtualisierungs-Engine.

Nur das Format ova definiert einen Container: Das Ergebnis des Builds ist eine .ova-Datei, bei der es sich schlicht um ein tar-Archiv handelt. Bei anderen Formaten erzeugt der Build separate Dateien. Sie können mit der Option -z zu einem 7z-Archiv gebündelt werden.

Es gibt außerdem den Typ rootfs: Dabei handelt es sich nicht um ein Image. Es ist schlicht ein Kali-Linux-Wurzeldateisystembaum ohne Kernel und Bootloader, verpackt in einem .tar.gz-Archiv. Der Hauptanwendungsfall ist die Wiederverwendung als Eingabe zum Erstellen eines OS-Images; es ist nicht dafür gedacht, außerhalb des Build-Systems verwendet zu werden.

Caching-Proxy-Konfiguration

Beim Erstellen von OS-Images ist ein Caching-Mechanismus sinnvoll, um nicht immer wieder alle Pakete aus dem Internet herunterladen zu müssen. Zu diesem Zweck versucht das Build-Skript, bekannte Caching-Proxys zu erkennen, die auf dem lokalen Host laufen könnten. Zuerst bezieht es sich auf die lokale APT-Konfiguration Acquire::http::Proxy. Ist diese nicht gesetzt, versucht es, apt-cacher-ng und squid-deb-proxy zu erkennen, indem es prüft, ob ein Dienst auf deren Standardport lauscht. Dieser Mechanismus funktioniert nicht für approx (einen bekannten APT-Caching-Proxy), da dieser bei Bedarf automatisch gestartet wird.

Um diese Erkennung zu überschreiben, kannst du die Umgebungsvariable http_proxy selbst exportieren. Du solltest jedoch bedenken, dass der Build in einer QEMU-Virtual-Machine stattfindet. localhost in der Build-Umgebung bezieht sich daher auf die VM und nicht auf den Host. Wenn du vom VM aus auf den Host zugreifen möchtest, solltest du wahrscheinlich http://10.0.2.2 verwenden.

Wenn du beispielsweise einen Proxy verwenden möchtest, der auf deinem Rechner auf Port 9876 läuft, verwende: export http_proxy=http://10.0.2.2:9876. Wenn du sicherstellen möchtest, dass kein Proxy verwendet wird, verwende: export http_proxy=.

Weitere Details findest du unter https://github.com/go-debos/debos#environment-variables.

Alternativ kannst du einen lokalen Mirror einrichten.

Erstellen und Wiederverwenden eines Rootfs

Es ist möglich, den Build in zwei Schritte aufzuteilen. Du kannst zuerst mit ./build.sh -v rootfs ein Rootfs erstellen und anschließend mit ./build.sh -r ROOTFS_NAME.tar.gz ein Image auf Basis dieses Rootfs bauen. Das ist zum Beispiel sinnvoll, wenn du mehrere Imagetypen erstellen möchtest.

Fehlerbehebung beim Build

Nicht genügend Speicherplatz

Wenn der Scratch-Bereich voll wird (d. h. der Wert von --scratchsize zu niedrig ist), kann der Build mit Fehlermeldungen dieser Art fehlschlagen:

[...]: failed to write (No space left on device)
[...]: Cannot write: No space left on device

Lösung: Erhöhe den Wert von --scratchsize. Du kannst debos nach dem Sonderzeichen -- Argumente übergeben. Wenn du zum Beispiel 50G benötigst, kannst du ./build.sh [...] -- --scratchsize=50G verwenden.

Eine Shell in der VM erhalten, wenn der Build fehlschlägt

Beim Debuggen von Build-Fehlern ist es praktisch, in einer Shell innerhalb der VM zu landen, in der der Build stattfindet. Das ist möglich, indem man debos die Option --debug-shell übergibt: ./build.sh [...] -- --debug-shell.

Fehlerbehebung zur Laufzeit

ovf nicht mit VMware ESXI kompatibel

Dies ist ein bekanntes Problem. Einen Workaround findest du unter https://gitlab.com/kalilinux/build-scripts/kali-vm/-/work_items/25#note_1301070132.