Archiv der Kategorie: Virtualisierung

Proxmox VE 3.2 Beta-Version – Was gibts neues?

Wie im Forum angekündigt, ist Proxmox VE 3.2 als Beta-Version verfügbar. Was gibt es neues?

logo_prox

Neuer Kernel

Die größte Änderung besteht im Angebot des RHEL7 basierenden Kernels in Version 3.10, allerdings bisher nur mit Unterstützung von KVM-Virtualisierung und ohne OpenVZ. OpenVZ ist die in Proxmox eingesetzte Paravirtualisierungslösung. Ein Parallels-Entwickler (der Hersteller von OpenVZ) kündigt in seinem Blog die Portierung von OpenVZ für den RHEL7-Kernel an. Der neue Kernel wird darüber hinaus langfristig unterstützt werden. Zuständig für die Unterstützung ist die LTSI, oder kurz Greg Kroah-Hartman.

Die Proxmox-Entwickler haben dem Kernel für die Beta-Version einige Treiber für RAID- und Netzwerkkarten hinzugefügt.

Und natürlich enthält der neue Kernel auch deutliche Verbesserungen der Verschlüsselungs-Infrastruktur; falls der eigene Proxmox-Server verschlüsselt ist.

Neues Dateisystem

Eine weitere interessante Entwicklung ist die Einbindung von Ceph, einem verteilten Dateisystem. Die Vorteile für den Einsatz mit Proxmox finden sich hier.

Weiteres

featured-image
(Quelle: openvswitch.org)

Darüber hinaus bringt die Beta-Version von Proxmox VE 3.2 einen Ersatz für die auf Java basierende Web-Konsole: Spiceterm. Spiceterm wird seit August 2013 von Dietmar Maurer entwickelt. Die README-Datei des Entwicklungs-Repositories enthält weitere Informationen.

Auch Open vSwitch ist in der Beta enthalten, soweit ersichtlich ohne Änderungen gegenüber der Version in Debian wheezy. vSwitch könnte in Zukunft aufgrund des Funktionsumfangs und dem scheinbar besseren Maximaldurchsatz gegenüber den Linux bridge-utils interessant werden.

Danke an Tim R. für den Hinweis zur neuen Beta.

Metasploitable 2 mittels vsftpd 2.3.4 Exploit angreifen

Wie in einigen vorherigen Artikeln beschrieben, ist mein Heimlabor für Penetrationstests in Form eines Virtualisierungsservers endlich fertig. Trotz Klausurstress lasse ich es mir nicht nehmen, abends zur Entspannung virtuelle Maschinen anzugreifen. Den Anfang macht Metasploitable 2, von dem ich bereits viel gelesen habe, es aber noch nie selbst angefasst habe.

Wie der Name bereits andeutet, soll zum Testen Metasploit zum Einsatz kommen. Nach Installation und Einrichtung (unter Kali Linux nicht notwendig), wird Metasploit durch Eingabe des Befehls msfconsole gestartet. Metasploit erlaubt das Verwalten verschiedener Ziele in sogenannten Workspaces. Workspaces erleichtern es, den Überblick zu behalten. Darum wird einer verwendet.

Bildschirmfoto - 30.01.2014 - 22:11:25

Um einen ersten Überblick über die von Metasploitable angebotenen Dienste zu bekommen, wird der Portscanner nmap eingesetzt. Da nur ein einzelner Host zu prüfen ist und die Erkennung des Scans keine Rolle spielt, kann ein kompletter Portscan mit Test aller 65.535 Ports und Versionserkennung gestartet werden. Der Scan wird mit dem Befehl db_nmap -A -p1-65535 metasploitable-ip-adresse gestartet und dauert circa 5 Minuten. Das Ergebnis sieht wie folgt aus und wird automatisch in der an Metasploit angeschlossenen Datenbank gespeichert.

Bildschirmfoto - 30.01.2014 - 22:19:25

Eine kurze Recherche ergibt, dass auf dem Server Ubuntu 8.04 LTS läuft. Da auf vielen Servern der SSH-Port offen ist, lässt sich aus der meist angepassten SSH-Version (hier OpenSSH 4.7p1 Debian 8ubuntu1) schnell ein Ausgangspunkt für die Schwachstellen-Recherche finden.

Die Version 2.3.4 des FTP-Servers vsftpd sticht sofort ins Auge. In 2011 wurden die Projektserver des vsftpd Projekts kompromittiert und eine angepasste Version dort bereitgestellt. Bei Anhängen eines einfachen Smilies wie :) an den Benutzernamen öffnet die kompromittierte vsftpd Version eine Bind-Shell auf Port 6200 mit Rootrechten. Eine angemessene:) Schwachstelle:) um:) das:) Heimlabor:) einzuweihen.

Praktischerweise liefert Metasploit ein Modul für genau diese Schwachstelle mit. Durch Eingabe des Befehls search vsftpd wird Metasploit angewiesen, nach Modulen zu suchen, deren Beschreibung vsftpd enthält.

Bildschirmfoto - 30.01.2014 - 22:40:19

Das Modul wird mit dem Befehl use exploit/unix/ftp/vsftpd_234_backdoor aktiviert. Mit dem Befehl set ohne Argumente werden die möglichen Parameter des Moduls angezeigt. Um das Exploit auszuführen genügt es, die Zieladresse durch Eingabe des Befehls set RHOST ip.des.ziel.hosts zu setzen.

Bildschirmfoto - 31.01.2014 - 10:22:24

Folgend kann das Exploit mit dem Befehl run ausgeführt werden und liefert eine einfache nicht-interaktive Shell auf dem Zielsystem, die wie folgt aussieht.

Bildschirmfoto - 31.01.2014 - 10:21:59

Im folgenden Artikel wird beschrieben, wie durch den temporären Zugang eine permanente Hintertür installiert oder die Kennwörter gebrochen werden können.

OpenVPN mit TUN/TAP in OpenVZ Instanz

Um in einer OpenVZ Instanz das TUN/TAP Gerät /dev/net/tun verwenden zu können sind einige kurze Schritte notwendig. Da die Hersteller-Dokumentation leider nicht fehlerfrei zum gewünschten Ergebnis führt, hier die Zusammenfassung.

Zuerst wird die eindeutige Identifikatiosnummer der OpenVZ Instanz bestimmt. Dann kann wie folgt auf dem Host fortgefahren werden. Um die Befehle erfolgreich absetzen zu können, muss die VM teilweise gestartet und teilweise gestoppt werden.

# Identifikationsnummer, zum Beispiel 106
VZID=106
vzctl stop $VZID
vzctl set $VZID --devnodes net/tun:rw --save
vzctl set $VZID --devices c:10:200:rw --save
vzctl set $VZID --capability net_admin:on --save
vzctl start $VZID
vzctl exec $VZID mkdir -p /dev/net
vzctl exec $VZID mknod /dev/net/tun c 10 200
vzctl exec $VZID chmod 600 /dev/net/tun

Die Fähigkeit net_admin kann zu einer reduzierten Abschottung zwischen Host und Gast führen. Eine Schwachstelle gab es bereits (2).

Proxmox internes Host-only Netzwerk

Um komplexe Netzwerkstrukturen mit einem Proxmox VE Virtualisierungsserver abzubilden, sind interne Netzwerke Host-only notwendig. Das Vorgehen ist einfach.

Im Reiter Netzwerk wird der Menüpunkt Erstellen gewählt.

Bildschirmfoto - 05.01.2014 - 19:02:36
Beispiel Host-only Netzwerkinterface vmbr1

Es muss keine IP-Adresse für die neue Netzwerkschnittstelle gewählt werden. Nach der Einrichtung muss ein Neustart des Virtualisierungsservers durchgeführt werden. Danach kann die neue Schnittstelle zu virtuellen Maschinen hinzugefügt werden und erscheint wie folgt.

Bildschirmfoto - 05.01.2014 - 19:45:06
Erscheinungsbild vmbr1 auf Host

Proxmox VE mit Software-RAID und Full-Disk-Encryption

Wie bereits im Artikel zur voll-verschlüsselten Installation von Kali beschrieben, kann nach der Tauchfahrt-Anleitung jedes Debian basierende System voll-verschlüsselt installiert werden. Der Bare-metal Hypervisor Proxmox VE basiert auf Debian. Was liegt näher, als Virtualisierungsserver zu verschlüsseln?

proxmox_fde_swraid

Folgend wird am Beispiel eines Servers mit vier 2TB Festplatten gezeigt, wie die Partitionierung und Installation im Unterschied zur Anleitung
Debian Colocation/Leased Server Full-Disk-Encryption durchgeführt werden kann.

Es sind die Schritte 3, 5.2 und 6 wie folgt durchzuführen. Die Installation von Proxmox geschieht in Schritt 11.

3. Festplatte partitionieren

Für Proxmox VE wird empfohlen, LVM einzusetzen und in einer Volume-Group pve die zwei logischen Volumes root und data anzulegen. Daraus ergibt sich für die vier 2TB Festplatten (sda,sdb,sdc,sdd) folgendes Endschema.

  • 2x 8GB RAID1 für /boot
  • 2x 8GB RAID1 für swap
  • 4x 1992GB RAID10 für LVM

Um dieses Schema zu erreichen, müssen die Partitionsschemen der einzelnen Festplatten wie folgt hergestellt werden. Der Partitionsmanager muss für jede Festplatte einmal aufgerufen werden.

cfdisk -z /dev/sdX

Gelöscht wird automatisch das komplette Partitionsschema der vorherigen Installation.

Angelegt werden zwei Partitionen. Für die ersten beiden Festplatten muss das Bootflag gesetzt werden. Für die restlichen beiden nicht.

sdX1

  • Größe 8GB
  • Typ FD (Wird unverschlüsseltes /boot– oder swap-RAID1)
  • Bootfähig für 1. und 2. Festplatte

sdX2

  • Größe Rest (1992GB)
  • Typ 8E (wird Teil des LVM)

Folgend werden die beiden RAID1-Verbünde für die /boot Partition und die Auslagerungspartition erstellt. Das alte mdadm Metadaten-Format kommt zum Einsatz, damit der betagte Kernel von Proxmox die RAID-Verbünde beim Systemstart automatisch erkennt.

mdadm --create -e 0.9 --level=1 -n 2 /dev/md0 /dev/sda1 /dev/sdb1
mdadm --create -e 0.9 --level=1 -n 2 /dev/md1 /dev/sdc1 /dev/sdd1

Es folgt das RAID10,f2 für das verschlüsselte LVM-Volume.

mdadm --create --level=10 -p f2 -n 4 /dev/md2 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2

Dann wird das RAID10 für das LVM-Volume verschlüsselt und formatiert. Hier ist es besonders wichtig, ein Passwort auszuwählen, dass länger als 20 Zeichen ist. Je länger und zufäliger das Passwort, desto länger dauert das Brechen. Dieses Passwort ist gemeinsam mit einem folgend erstellten SSh-Schlüssel die Achillesferse des Prinzips und muss geheimgehalten werden. Es ist sehr empfehlenswert, eine Software wie PWGen zu verwenden, um ein sehr langes Passwort (zum Beispiel 200 Zeichen) zu erzeugen.

Wenn das Passwort erzeugt ist, kann wie folgt fortgefahren werden. Bei der Verschlüsselung der Partition muss zuerst die Verschlüsselung mit Eingabe von YES bestätigt werden und dann der Schlüssel zweimal eingegeben werden.

cryptsetup luksFormat /dev/md2
cryptsetup luksOpen /dev/md2 md2_crypt

Jetzt kann das LVM initialisiert und die nötigen logischen Volumes nach Proxmox-Vorgabe erstellt werden. Die Größe des logischen Volumes data ist absichtlich klein gewählt, sodass weitere logische Volumes für Backups erstellt werden können.

pvcreate /dev/mapper/md2_crypt
vgcreate pve /dev/mapper/md2_crypt
lvcreate --name root --size 60G pve
lvcreate --name data --size 500G pve

Folgend werden die Partitionen formatiert. Dabei soll nach Proxmox-Vorgabe das Dateisystem ext3 eingesetzt werden.

mkfs.ext3 /dev/mapper/pve-data
mkfs.ext3 /dev/mapper/pve-root
mkfs.ext3 /dev/md0

Jetzt werden die Partitionen eingebunden, damit im nächsten Schritt das Basis-System installiert werden kann.

mount /dev/mapper/pve-root /mnt
mkdir -p /mnt/boot /mnt/var/lib/vz
mount /dev/mapper/pve-data /mnt/var/lib/vz
mount /dev/md0 /mnt/boot

5.2 Einrichtung der /etc/crypttab,/etc/fstab, Paketquellen und lokale Einstellungen

Zuerst wird die Dateisystem-Tabelle für verschlüsselte Partitionen angelegt.

md1_crypt /dev/md1	/dev/urandom cipher=aes-cbc-essiv:sha256,size=256,swap
md2_crypt /dev/md2	none	luks

Dann die entsprechende Dateisystem-Tabelle für unverschlüsselte und aktive verschlüsselte Partitionen.

/dev/md0		/boot		ext3	relatime		0 2
/dev/mapper/md1_crypt	none		swap	sw			0 0
/dev/mapper/pve-root	/		ext3	relatime,data=ordered 	0 1
/dev/mapper/pve-data	/var/lib/vz	ext3	relatime,data=ordered	0 3
proc			/proc		prox	defaults

Jetzt werden die Paketquellen in der Datei /etc/apt/sources.list wie folgt eingetragen.

# Debian wheezy
deb http://ftp.de.debian.org/debian/ wheezy main non-free contrib
deb-src http://ftp.de.debian.org/debian/ wheezy main non-free contrib
deb http://security.debian.org/ wheezy/updates main non-free contrib
deb-src http://security.debian.org/ wheezy/updates main non-free contrib
deb http://ftp.de.debian.org/debian/ wheezy-updates main non-free contrib
deb-src http://ftp.de.debian.org/debian/ wheezy-updates main non-free contrib

Nach Aktualisierung der lokalen Caches für Pakete kann fortgefahren werden.

aptitude update && aptitude -y upgrade

Jetzt erfolgt die Konfiguration der Sprache des Systems.

aptitude -y install locales && dpkg-reconfigure locales

Hier wird de_DE.UTF-8 gewählt. Die Zeitzone muss auch gesetzt werden, in der Regel auf Europa/Berlin.

dpkg-reconfigure tzdata

6.1 Grundlegende Software installieren

aptitude install -y ssh grub-pc pciutils psmisc cryptsetup dropbear busybox mdadm lvm2

Während der Installation erscheint eine Nachfrage von grub-pc. Es wird nach dem Ort, an dem GRUB installiert werden soll gefragt. Es sind /dev/sda und /dev/sdb anzugeben. Weicht die Festplattenbenennung ab, ist es wichtig zu wissen, dass GRUB nicht in einer Partition (wie /dev/sda1) oder einem Software-RAID-Verbund, sondern auf Festplatten (wie /dev/sda) installiert werden sollte.

11. Debian in Proxmox VE umwandeln

Nach der erfolgreichen Installation von Debian nach den Proxmox-Vorgaben, kann die Installation nach der Anleitung im Proxmox VE Wiki umgewandelt werden. Es sind die Schritte ab Install Proxmox VE durchzuführen.

Intel I217-LM Treiber für Proxmox VE 3.1

293px-Intel-logo.svg

Treiber installieren liegt nicht nahe, wenn ein Linux-Server betrieben wird. Meist werden alle nötigen Treiber mitgeliefert. Nicht so bei Proxmox VE 3.1 und dem Netzwerkchip I217-LM von Intel. Proxmox verwendet noch den angestaubten Kernel 2.6.32, Unterstützung für den Netzwerkchip der Haswell-Generation bietet aber erst Kernel 3.5.

Mit einfachen Befehlen kann der Treiber, wie folgt, nachinstalliert werden.

apt-get install pve-headers-`uname -r` build-essential
cd /usr/local/src
wget http://downloadmirror.intel.com/15817/eng/e1000e-2.5.4.tar.gz
tar xzf e1000e-2.5.4.tar.gz
cd e1000e-2.5.4
make install
modprobe e1000e

OpenVZ Kali Linux Template für Proxmox VE

kali-tm

Wie bereits aus dem letzten Beitrag zu Proxmox VE zu erahnen, entsteht hier gerade ein einfaches Penetrationstest Labor mit Proxmox. Dafür wird eine virtuelle Maschine mit Kali Linux benötigt. Zusätzlich muss ein einfacher grafischer Zugang mittels Linux Werkzeugen (vergleichbar zu Windows Remote Desktop) zur Verfügung stehen. Eine solche virtuelle Maschine gibt es bislang noch nicht für Proxmox und die Herstellung erfordert einige Tricks. Das Ergebnis präsentiert sich wie folgt.

Bildschirmfoto - 21.12.2013 - 20:30:48Bildschirmfoto - 21.12.2013 - 20:29:51

Proxmox bietet sowohl Vollvirtualisierung mittels KVM, wie auch Paravirtualisierung mittels OpenVZ. Das Template wird für OpenVZ erstellt, um ohne große Verluste mehrere Instanzen gleichzeitig ausführen zu können. Der entfernte grafische Zugang wird über X2go eingerichtet. Es stehen bereits Paketquellen für Debian „wheezy“ zur Verfügung, auf dem Kali Linux 1.0 aufbaut. X2go wird dafür sorgen, dass grafische Sitzungen im Hintergrund weiterlaufen, wenn der entfernte Zugang beendet wird (ähnlich zu screen).

Für Die Herstellung des Templates werden Superuser-Rechte benötigt, die zum Beispiel mittels sudo -s erlangt werden können.

1.1 Debootstrap herunterladen und anpassen

mkdir -p ~/Development/proxmox/kali-linux
cd ~/Development/proxmox/
wget http://archive.kali.org/kali/pool/main/d/debootstrap/debootstrap_1.0.48+kali1_all.deb

Sollte die debootstrap Quelle nicht mehr aktuell sein, kann der richtige Link hier eingesehen werden: http://archive.kali.org/kali/pool/main/d/debootstrap/

ar -xf debootstrap_1.0.48+kali1_all.deb
tar xzf data.tar.gz
tar xzf control.tar.gz

Jetzt muss geprüft werden, ob der Inhalt des Pakets unverändert auf dem lokalen System angekommen ist. Jedes Debian Paket liefert eine Datei md5sums mit, die Prüfsummen über die enthaltenen Dateien enthält. Mit dem folgenden Einzeiler lässt sich die Integrität des debootstrap Pakets prüfen.

cat md5sums | cut -d " " -f 3 | xargs md5sum $1 > md5sums.local; diff md5sums md5sums.local

Der Befehl darf keine Ausgabe erzeugen, sonst sind Daten verändert worden. Um jetzt per debootstrap installieren zu können, muss der Quelltext von debootstrap leicht angepasst werden.

nano usr/sbin/debootstrap

Die folgenden Zeilen entsprechend editieren

Suchen:

DEBOOTSTRAP_DIR=/usr/share/debootstrap

und ersetzen mit:

DEBOOTSTRAP_DIR=/tmp/usr/share/debootstrap

1.2 Installation durchführen

Um sicherzugehen, dass nur offizielle Pakete ohne Hintertüren auf dem neuen System installiert werden, müssen die Signaturen aller Pakete geprüft werden. Alle Debian Pakete sind durch öffentliche Schlüssel in einer Public-Key-Infrastruktur gesichert. Damit diese Signaturen geprüft werden können, muss der Hauptschlüssel des Kali Linux Archivs wie folgt importiert werden.

wget -q -O - http://archive.kali.org/archive-key.asc | gpg --import

Mit dem Befehl gpg --list-keys wird geprüft, ob der Schlüssel erfolgreich importiert wurde. Ist das der Fall, kann das Grundsystem wie folgt installiert werden.

usr/sbin/debootstrap --keyring=~/.gnupg/pubring.gpg --arch=amd64 --include=kali-archive-keyring,kali-debtags,kali-defaults,kali-linux,kali-menu,kali-root-login,gnome,openssh-server kali ./kali-linux/ http://archive.kali.org/kali

Bei der Ausführung des Befehls kann es zu einem Fehler mit der Nachricht W: Failure while installing base packages. This will be re-attempted up to five times. kommen. Dieser Fehler kann ignoriert werden. Auch kann es zu einem abschließenden Fehler im Zusammenhang mit dem Paket metasploit kommen. Auch dieser Fehler kann ignoriert werden. Er wird vor der Erstellung des Templates behandelt.

Nach der Installation des Grundsystems erfolgt die Anmeldung über den chrootBefehl, um die weitere Einrichtung durchzuführen.

mount -t proc none ./kali-linux/proc/
mount -o bind /dev ./kali-linux/dev/
mount -t tmpfs none ./kali-linux/tmp/
mount -o bind /sys ./kali-linux/sys
LANG=C chroot ./kali-linux /bin/bash

Erzeugen die Befehle keine Fehlermeldung, wurde erfolgreich in das frisch installierte Kali Linux gewechselt.

1.3 System einrichten und aktualisieren

Um die Signaturen der in Zukunft zu installierenden Pakete prüfen zu können, müssen die Schlüssel der Paketquellen auch im neuen OpenVZ Template importiert werden.

# kali
apt-key adv --recv-keys --keyserver keys.gnupg.net ED444FF07D8D0BF6
# x2go
apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E

Jetzt werden die Paketquellen aktualisiert und das System auf den Stand der den neuen Paketquellen entspricht, gebracht. Neuer Inhalt der Datei /etc/apt/sources.list hat wie folgt zu lauten.

## KALI Main
deb http://http.kali.org/kali kali main non-free contrib
deb-src http://http.kali.org/kali kali main non-free contrib

## KALI Sec
deb http://security.kali.org/kali-security kali/updates main contrib non-free

## X2Go
deb http://packages.x2go.org/debian wheezy main
deb-src http://packages.x2go.org/debian wheezy main

Durchführung der Aktualisierung wie folgt.

apt-get update
apt-get upgrade -f

Jetzt kann X2go installiert werden.

apt-get install x2goserver x2goserver-extensions x2goserver-compat x2goserver-fmbindings

1.4 Anpassungen des Proxmox Templates

Damit jede virtuelle Maschine eigene SSH Host-Schlüssel hat, muss die Datei /etc/rc.local wie folgt vor dem Befehl exit 0 ergänzt werden und danach der Befehl rm /etc/ssh/ssh_host_* ausgeführt werden.

# SSH-Keys bei Erststart erzeugen
test -f /etc/ssh/ssh_host_dsa_key || dpkg-reconfigure openssh-server

Damit der SSH-Dienst im Gegensatz zur Voreinstellung von Kali Linux beim Systemstart gestartet wird, ist das Anlegen der Verknüpfungen aus den Runleveln zu SSH sowie die korrekte Ablegung des start-stop-daemon Skripts notwendig. Folgende zwei Befehle erledigen die Arbeit.

update-rc.d ssh enable 2 3
cp /sbin/start-stop-daemon.REAL /sbin/start-stop-daemon

Jetzt muss das Kennwort des Superusers der virtuellen Maschine mit dem Befehl passwd mit dem bekannten Wert toor initialisiert werden. Daraufhin werden alle lokalen Konsolen (gettys) bis auf das Erste in der Datei /etc/inittab wie folgt auskommentiert.

1:2345:respawn:/sbin/getty 38400 tty1
#2:23:respawn:/sbin/getty 38400 tty2
#3:23:respawn:/sbin/getty 38400 tty3
#4:23:respawn:/sbin/getty 38400 tty4
#5:23:respawn:/sbin/getty 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6

Danach wird die chroot-Umgebung mit dem Befehl exit verlassen. Die temporär eingehängten Systemverzeichnisse müssen jetzt ausgehängt werden.

umount ~/Development/proxmox/kali-linux/proc
umount ~/Development/proxmox/kali-linux/tmp
umount ~/Development/proxmox/kali-linux/sys
umount -l ~/Development/proxmox/kali-linux/dev

1.5 Template erstellen und speichern

Folgend kann das Template erstellt werden.

cd kali-linux
GZIP=-9 tar --numeric-owner -zcf ~/Development/proxmox/kali-1.0.5-standard_1.0.5-1_i386.tar.gz .

Im Anschluss kann das erstellte Template in den Storage-Bereich von Proxmox hochgeladen und provisioniert werden.

Bildschirmfoto - 27.12.2013 - 10:40:09

1.6 Verbindung mittels X2go

Nach der Provisionierung ist die Verbindung zur virtuellen Maschine mittels X2Go mit folgenden Einstellungen möglich (IP-Adresse anpassen!). Das verwendete Icon gibt es hier.

X2Go Kali Linux Einstellung
X2Go Kali Linux Einstellung

Um die Provisionierung abzuschließen, muss in einem Terminal der Befehl apt-get install -f eingegeben werden und ein MySQL-Kennwort vergeben werden. Zuletzt folgt die Konfiguration der lokalen Sprache.

dpkg-reconfigure locales

Hier wird de_DE.UTF-8 gewählt. Die Zeitzone muss auch gesetzt werden, in der Regel auf Europa/Berlin.

dpkg-reconfigure tzdata

Wem die Anpassungen nach der Provisionierung zuviel sind, oder wer das Template nur in einer Sprache benötigt, kann aus dem Verzeichnis /var/lib/vz/private/VZID ein neues finalisiertes Template erzeugen.

Viel Spaß!

KALI LINUX ™ is a trademark of Offensive Security.